Subject: [xrblock] proposed change to discard draft for the issue: duplication packet discards

From: Qin Wu <[email-masked]>
Date: Thu, 16 Aug 2012 11:26:40 +0800

Hi,
Discard count metric block draft 
(http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-05)
supports reporting discards due to packet duplication.

It was suggested on the list to provide backgound information for duplication packet discards.
In the Vancouver meeting,we re-discussed duplication packet discards issue. It was pointed out
RTP packet duplication is not standard method and may break RTCP rules when we do RTCP 
statistics reporting. 

Combining these comments and incorporated proposed change from Varun earlier on the list, 
I propose the following change to the defintion part of Discard Type.

OLD TEXT:
"
      An endpoint MAY send only one of the discard types (early, late,
      duplication packets discard) in one RTCP report or choose to
      report early (DT=1) and late (DT=2), duplication packets discard
      (DT=0) in separate block.  It MAY also send the combined early and
      late discard type (DT=2) in one RTCP compound packet, but not any
      other combination of the three Discard Types.  The endpoint MUST
      not report the the total number of discarded packets covering all
      three discard types.  Instead, two separate report blocks should
      be used to carry duplication packets discard and the combined
      early and late discard respectively.
"
NEW TEXT:
"
      An endpoint MAY report only one of the above four discard types

 blocks in an compound RTCP report in a reporting interval. It MAY

 also report a combination of discard types in a compound RTCP report

 but not all combinations are valid. The endpoint MAY report 

duplicate packet discard (DT=0) block with any other discard (DT=1,

2, or 3) block. Additionally, an endpoint MUST NOT report combined

discard (DT=3) block with early discard (DT=1) or late discard (DT=2)

report block. Note that duplicating RTP packets using RTP 

replication may lead to breakage of RTP media streams or RTCP rules.

 In order not to disrupt all the RTCP statistics, it is recommended 

to duplicate RTP packets as described in [draft-ietf-avtext-rtp-duplication-00]

 which will not cause breakage.

"

Also in the meeting, Kevin raised we should add some text to clarify the use cases and suggest to put into the section 1.4 applicability section.
I propose the following change to the section 1.4 as follows:
OLD TEXT:
"
1.4.  Applicability

   This metric is believed to be applicable to a large class of RTP
   applications which use a jitter buffer.

"
NEW TEXT:
"
1.4.  Applicability

This metric is believed to be applicable to a large class of RTP

 applications which use a jitter buffer. For example, in one reporting

 interval, when packets were received but dropped from the jitter buffer

due to either buffer underflow or buffer overflow or both, the discard count

 metric can be used to report such packet discards. In some other cases(e.g.,

desktop video conferencing), duplicating RTP packets using RTP replication 

may be used by media receiver for error concealment.

These duplicated packets can be counted as discards when they are not used and 

dropped by application from jitter buffer, in such cases, the discard count 

metric can be used to report such packet discards due to packet duplication.

"
Regards!
-Qin

---

From: Colin Perkins <[email-masked]>
Date: Fri, 17 Aug 2012 15:02:32 +0300

>  which will not cause breakage.

This last sentence might be better written "In order not to disrupt RTCP statistics, systems MUST NOT blindly duplicate RTP packets. If it is essential to use duplication for robustness, the mechanism described in [draft-ietf-avext-rtp-duplication-00] MAY be used since it avoids breakage; however duplication is expensive, and is best avoided."

Colin

> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock

-- 
Colin Perkins
http://csperkins.org/

---

From: Alan Clark <[email-masked]>
Date: Fri, 17 Aug 2012 08:30:33 -0400

Colin

Since this draft is simply reporting measurements it may not be the right
place to make normative statements about the generation of RTP packets,
although it could of course comment on the approach.  The “MUST NOT” should
probably be incorporated in your draft related to RTP redundancy or into the
next rev of RFC3550.

Best Regards

Alan

On 8/17/12 8:02 AM, "Colin Perkins" <[email-masked]> wrote:

> This last sentence might be better written "In order not to disrupt RTCP
> statistics, systems MUST NOT blindly duplicate RTP packets. If it is essential
> to use duplication for robustness, the mechanism described in
> [draft-ietf-avext-rtp-duplication-00] MAY be used since it avoids breakage;
> however duplication is expensive, and is best avoided."
> 
> Colin
> 
> 
> 
>> Also in the meeting, Kevin raised we should add some text to clarify the use
>> cases and suggest to put into the section 1.4 applicability section.
>> 1.4 
>> <http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-05#section-1.4
>> > .  Applicability
>>

---

From: Colin Perkins <[email-masked]>
Date: Fri, 17 Aug 2012 15:49:15 +0300

Alan,

In that case: "It is not appropriate for systems to duplicate RTP packets for robustness, since this disrupts RTCP statistics. If it is essential to use packet duplication for robustness, the mechanism described in [draft-ietf-avext-rtp-duplication-00] can be used since they avoid breakage; however duplication is expensive, and is best avoided."

Colin

On 17 Aug 2012, at 15:30, Alan Clark wrote:
> Colin
> 
> Since this draft is simply reporting measurements it may not be the right place to make normative statements about the generation of RTP packets, although it could of course comment on the approach.  The “MUST NOT” should probably be incorporated in your draft related to RTP redundancy or into the next rev of RFC3550.
> 
> Best Regards
> 
> Alan
> 
> 
> 
>>> 1.4 <http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-05#section-1.4> .  Applicability
>>> 

-- 
Colin Perkins
http://csperkins.org/

---

From: Kevin Gross <[email-masked]>
Date: Fri, 17 Aug 2012 09:11:22 -0600

I don't think it is necessary or appropriate to include this sort of value
judgement. What is expensive? What is necessary? At best, this is getting
tangential. I support the original wording of Qin's note though I think it
should be a separate paragraph and perhaps marked as a note.

As for the applicability discussion, what I'm looking for is: how will this
information be used by the entity or entities receiving it? It is already
clear from the other text in the draft _what_ is being reported. We don't
need to repeat that here. What needs to be clarified and justified is _why_
and to _whom_ this information is useful.

Clearly the information is useful to receivers who may adjust their jitter
buffers based on the information. But they can do this internally and I
don't see a need for them to transmit the raw information on which they're
acting.

Clearly the information is useful to network managers who may wish to tune
or troubleshoot their networks based on this feedback. But isn't SNMP, a
more appropriate reporting channel for these purposes?

To justify RTCP reporting of this information, I think it needs to be
demonstrably useful to the sender(s) and other receivers in the session. I
personally can't think of a direct use for this information by these
entities. If there is one (or two...), that's what I wish to see included
in the applicability discussion. If there isn't one, it calls into question
the need to finish this work.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org

On Fri, Aug 17, 2012 at 6:49 AM, Colin Perkins <[email-masked]> wrote:

> Alan,
>
> In that case: "It is not appropriate for systems to duplicate RTP packets
> for robustness, since this disrupts RTCP statistics. If it is essential to
> use packet duplication for robustness, the mechanism described
> in [draft-ietf-avext-rtp-duplication-00] can be used since they avoid
> breakage; however duplication is expensive, and is best avoided."
>
> Colin
>
>
>
> probably be incorporated in your draft related to RTP redundancy or into
> the next rev of RFC3550.
>
> Best Regards
>
> Alan
>
>
>
> statistics, systems MUST NOT blindly duplicate RTP packets. If it is
> essential to use duplication for robustness, the mechanism described in
> Also in the meeting, Kevin raised we should add some text to clarify the
> use cases and suggest to put into the section 1.4 applicability section.
> *1.4* <
> http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-05#section-1.4>
> *.  Applicability
> *

---

From: Colin Perkins <[email-masked]>
Date: Fri, 17 Aug 2012 19:12:24 +0300

Kevin,

On 17 Aug 2012, at 18:11, Kevin Gross wrote:
> I don't think it is necessary or appropriate to include this sort of value judgement. What is expensive? What is necessary? At best, this is getting tangential. I support the original wording of Qin's note though I think it should be a separate paragraph and perhaps marked as a note.

Qin's original wording seems to me to be encouraging duplication. I do not support that, since it does break RTCP statistics if done in the naïve way implied. I'm happy if someone wants to propose a more neutral wording, part-way between my suggestion and Qin's text.

> As for the applicability discussion, what I'm looking for is: how will this information be used by the entity or entities receiving it? It is already clear from the other text in the draft _what_ is being reported. We don't need to repeat that here. What needs to be clarified and justified is _why_ and to _whom_ this information is useful.
> 
> Clearly the information is useful to receivers who may adjust their jitter buffers based on the information. But they can do this internally and I don't see a need for them to transmit the raw information on which they're acting.
> 
> Clearly the information is useful to network managers who may wish to tune or troubleshoot their networks based on this feedback. But isn't SNMP, a more appropriate reporting channel for these purposes?
> 
> To justify RTCP reporting of this information, I think it needs to be demonstrably useful to the sender(s) and other receivers in the session. I personally can't think of a direct use for this information by these entities. If there is one (or two...), that's what I wish to see included in the applicability discussion. If there isn't one, it calls into question the need to finish this work.

I generally agree, although RTCP is at least potentially appropriate for network management purposes. 

-- 
Colin Perkins
http://csperkins.org/

---

From: Qin Wu <[email-masked]>
Date: Mon, 20 Aug 2012 12:46:58 +0800

Hi,Kevin:
Thank for your feedback. see reply inline.

Regards!
-Qin
  ----- Original Message ----- 
  From: Kevin Gross 
  To: Colin Perkins 
  Cc: [email-masked] 
  Sent: Friday, August 17, 2012 11:11 PM
  Subject: Re: [xrblock] proposed change to discard draft for the issue: duplication packet discards

  As for the applicability discussion, what I'm looking for is: how will this information be used by the entity or entities receiving it? It is already clear from the other text in the draft _what_ is being reported. We don't need to repeat that here. 

[Qin]: Agree. Sorry I misunderstood real concern you raised in the meeting.

  What needs to be clarified and justified is _why_ and to _whom_ this information is useful.

[Qin]: One use case we support when this draft was written earlier is Discard count metric block is sent together with Burst gap discard metric block defined in draft-ietf-xrblock-rtcp-xr-burst-gap-discard to the media sender or RTP based network management system, information carried in the discard count metric block allow them calculate some important bust gap summary statistics,e.g., gap discard rate. 

Another use case is given by Varun and clarified by Alan, is in case of replication being kept "on", Reporting duplicate packets discards can allow the media sender or network management system  to determine what proportion of lost packets are being concealed by the process and calculate the actual loss rate which is helpful to know that there are some network issues that need to be investigated.

So I like to propose the following change to applicability section as follows:
OLD TEXT:
"
1.4.  Applicability

 In case of Discard count metric block sent together with Burst gap
 discard metric block defined in draft-ietf-xrblock-rtcp-xr-burst-gap-discard to the 
media sender or  RTP based network management system, information carried in 
the discard count metric block allow them calculate the important bust gap 
summary statistics,e.g., gap discard rate.

In case of replication being kept "on", reporting duplicate packets discards 
can allow the media sender or network management system  to determine 
what proportion of lost packets are being concealed by the process and 
calculate the actual loss rate which is helpful to know that there are some 
network issues that need to be investigated.
"

[Qin]: SNMP provides useful mechanisms for exporting data on the performance of an RTP session to non-RTP network management systems.
Comparing SNMP, RTCP or RTCP XR provides a best way for in-session monitoring and is in-band means rather than out-band means or third party means.
 Information carried in RTCP XR could be useful for RTP based network management systems to do the inline troubleshoot.

Also I remembered this issue or a debat on using RTCP or SNMP had been discussed in AVTCORE mailing list very long time ago 
(http://www.ietf.org/mail-archive/web/avt/current/msg12514.html).
The result seemed to be that  we see very few successful deployments to use SNMP/MIB technology to do tune or troubleshoot 
for media part of real time applications.

  To justify RTCP reporting of this information, I think it needs to be demonstrably useful to the sender(s) and other receivers in the session. 

[Qin]:Agree.
  I personally can't think of a direct use for this information by these entities. If there is one (or two...), that's what I wish to see included in the applicability discussion. If there isn't one, it calls into question the need to finish this work.

[Qin]:See usages and my proposed change I gave above.

  Kevin Gross

  +1-303-447-0517
  Media Network Consultant

  AVA Networks - www.AVAnw.com, www.X192.org

    Alan,

    Colin

      Best Regards

      Alan

          Hi,

          OLD TEXT:
          "

        Colin

           

          "
          Regards!
          -Qin

    -- 
    Colin Perkins
    http://csperkins.org/

------------------------------------------------------------------------------

---

From: Qin Wu <[email-masked]>
Date: Mon, 20 Aug 2012 12:44:44 +0800

Hi,
  ----- Original Message ----- 
  From: Colin Perkins 
  To: Kevin Gross 
  Cc: [email-masked] 
  Sent: Saturday, August 18, 2012 12:12 AM
  Subject: Re: [xrblock] proposed change to discard draft for the issue:duplication packet discards

  Kevin,

[Qin]: How about rephrasing it as follows:
"
Note that duplicating RTP packets is for robustness or error resilience but may disrupts RTCP statitics.
In order to tackle this, the mechanism described in [draft-ietf-avext-rtp-duplication-00] can be used which
will not cause breakage of RTP streams or RTCP rules.
"
This statement will put as an indepent paragraph as Kevin suggested.

  -- 
  Colin Perkins
  http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Tue, 21 Aug 2012 23:02:17 +0100

Qin,

> This statement will put as an indepent paragraph as Kevin suggested.

The "may disrupt RTCP statistics" is misleading: duplicating RTP packets in the naïve manner _will_ break RTCP. 

-- 
Colin Perkins
http://csperkins.org/

---

From: Qin Wu <[email-masked]>
Date: Wed, 22 Aug 2012 10:52:50 +0800

----- Original Message ----- 
  From: Colin Perkins 
  To: Qin Wu 
  Cc: Kevin Gross ; [email-masked] 
  Sent: Wednesday, August 22, 2012 6:02 AM
  Subject: Re: [xrblock] proposed change to discard draft for the issue:duplication packet discards

  Qin,

      ----- Original Message -----
      From: Colin Perkins
      To: Kevin Gross
      Cc: [email-masked]
      Sent: Saturday, August 18, 2012 12:12 AM
      Subject: Re: [xrblock] proposed change to discard draft for the issue:duplication packet discards

      Kevin,

      Qin's original wording seems to me to be encouraging duplication. I do not support that, since it does break RTCP statistics if done in the naÃ¯ve way implied. I'm happy if someone wants to propose a more neutral wording, part-way between my suggestion and Qin's text.

  The "may disrupt RTCP statistics" is misleading: duplicating RTP packets in the naÃ¯ve manner _will_ break RTCP. 

[Qin]:Okay, how about removing "may" from the proposed text?

  -- 
  Colin Perkins
  http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Wed, 22 Aug 2012 18:35:25 +0100

> [Qin]:Okay, how about removing "may" from the proposed text?

That would improve it, although to my mind a stronger statement would still be desirable.

-- 
Colin Perkins
http://csperkins.org/