Re: [xrblock] WGLC review ofdraft-ietf-xrblock-rtcp-xr-burst-gap-loss-02 anddraft-ietf-xrblock-rtcp-xr-burst-gap-discard-04

[Qin Wu <[e-mail]>]

Hi,Roni:
Thank for your valuable review. please see my replies inline.

Regards!
-Qin
  ----- Original Message ----- 
  From: Roni Even 
  To: 'xrblock' 
  Sent: Tuesday, July 17, 2012 10:26 PM
  Subject: [xrblock] WGLC review ofdraft-ietf-xrblock-rtcp-xr-burst-gap-loss-02 anddraft-ietf-xrblock-rtcp-xr-burst-gap-discard-04


  Hi,

  I reviewed both drafts and in general they look OK.

  I have a couple of questions/comments for both drafts

   

  1.       In section 2.1 for Received, Lost and Discarded why not use the similar text from draft-ietf-xrblock-rtcp-xr-discard?



[Qin]:Good suggestions. For consistency, we should use the same term in both burst gap drafts and discard drafts.

Also I am aware that in the section 2.1 of discard draft, the discard count metric has no difference from 'number of packets discarded'metric.

Therefore I propose the following change.

OLD TEXT:

"

   Received, Lost and Discarded

      A packet shall be regarded as lost if it fails to arrive within an
      implementation-specific time window.  A packet that arrives within
      this time window but is too early or late to be played out or
      thrown away before playout due to packet duplication or redundancy
      shall be regarded as discarded.  A packet shall be classified as
      one of received (or OK), discarded or lost.  The Discard Count
      Metric counts only discarded packets.  The metric "cumulative
      number of packets lost" defined in [RFC3550] reports a count of
      packets lost from the media stream (single SSRC within single RTP
      session).  Similarly the metric "number of packets discarded"
      reports a count of packets discarded from the media stream (single
      SSRC within single RTP session) arriving at the receiver.  Another
      metric defined in [RFC5725] is available to report on packets
      which are not recovered by any repair techniques which may be in
      use.

"

NEW TEXT:

"

   Received, Lost and Discarded

 

      A packet shall be regarded as lost if it fails to arrive within an

      implementation-specific time window.  A packet that arrives within

      this time window but is too early or late to be played out or

      thrown away before playout due to packet duplication or redundancy

      shall be regarded as discarded.  A packet shall be classified as

      one of received (or OK), discarded or lost. The metric "cumulative

      number of packets lost" defined in [RFC3550] reports a count of

      packets lost from the media stream (single SSRC within single RTP

      session).  Similarly the metric "number of packets discarded"

      defined in [DISCARD]reports a count of packets discarded from the media stream (single

      SSRC within single RTP session) arriving at the receiver.  Another

      metric defined in [RFC5725] is available to report on packets

      which are not recovered by any repair techniques which may be in

      use. 

"



  2.       Section 4 talks about considerations for VOIP and recommends a value for call quality degradation. Can we have something similar for video, at least in the second paragraph which I think is not voice specific. 

[Qin]: We already have. pleas see the 2nd term in the section 2.1 as follows:

"

   Bursts and Gaps

      The terms Burst and Gap are used in a manner consistent with that
      of RTCP XR [RFC3611].  RTCP XR views a RTP stream as being divided
      into bursts, which are periods during which the discard rate is
      high enough to cause noticeable quality degradation (generally
      over 5 percent discard rate), and gaps, which are periods during
      which discarded packets are infrequent and hence quality is
      generally acceptable.

"



  3.       In section 4 the degradation in quality mentioned is when there is no redundancy information like FEC  so maybe mentioned that this value is without any stream repair means.



[Qin]: Good suggestion and will add.

  4.       A nit in section 4 first paragraph "Where the metric is used" maybe say "when the."



[Qin]:Confirmed, yes. Thank for your proposed change.

   

   

  Roni Even



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


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