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

[Qin Wu <[e-mail]>]

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

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


  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. 

[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

   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. 

 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.
"



  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?

[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

  [phone]
  Media Network Consultant

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




  On Fri, Aug 17, 2012 at 6:49 AM, Colin Perkins <[e-mail]> 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






    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



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



        On 16 Aug 2012, at 06:26, Qin Wu wrote:


          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.
          "


        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.
          I propose the following change to the section 1.4 as follows:
          OLD TEXT:
          "
          1.4 <http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-05#section-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

          _______________________________________________
          xrblock mailing list
          [e-mail]
          https://www.ietf.org/mailman/listinfo/xrblock









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






    _______________________________________________
    xrblock mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/xrblock






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


  _______________________________________________
  xrblock mailing list
  [e-mail]
  https://www.ietf.org/mailman/listinfo/xrblock