Subject: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discard-06.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 26 Aug 2012 08:41:15 +0200

This is a WGLC for draft-ietf-xrblock-rtcp-xr-discard-06.txt. Please
send your questions, comments or concerns to the WG list before 9/9 COB.
Messages indicating that you have read the document and are comfortable
with it, including with the latest changes are also useful. 

The plain text version of the document is available at
http://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-discard-06.txt. 

The diff between versions 05 and 06 is accessible at
https://www.ietf.org/rfcdiff?url1=draft-ietf-xrblock-rtcp-xr-discard-05&
difftype=--html&submit=Go%21&url2=draft-ietf-xrblock-rtcp-xr-discard-06

Thanks and Regards,

Shiba and Dan

---

From: Kevin Gross <[email-masked]>
Date: Mon, 27 Aug 2012 08:06:03 -0600

I apologize that I was not more responsive to the recent thread (
http://www.ietf.org/mail-archive/web/xrblock/current/msg00704.html) discussing
revisions to this draft. I prepared the following wording
improvements borrowing a bit from draft-ietf-xrblock-rtcp-xr-
burst-gap-discard-05 to address
my concerns about insufficient justification and context and trying to more
comprehensively address Collin Perkins's concerns about
leading implementers astray in duplication discussion.

Section 1.1., paragraph 3:
OLD:

    The metric belongs to the class of transport-related terminal metrics
    defined in [MONARCH].

NEW:

    This block may be used in conjunction with [BGDISCARD] which provides
    additional information on the pattern of discarded packets.  However
    the metric in [BGDISCARD] may be used independently of the metrics in
    this block.

    In case of Discard count metric block sent together with Burst gap
    discard metric block defined in [BGDISCARD] to the media sender or
    RTP based network management system, information carried in the
    discard count metric block and Burst gap discard metric block allows
    them calculate the some bust gap summary statistics, e.g., gap
    discard rate.

    The metric belongs to the class of transport-related terminal metrics
    defined in [MONARCH].

Section 1.4., paragraph 2:
OLD:

    In case of Discard count metric block sent together with Burst gap
    discard metric block defined in [BGDISCARD] to the media sender or
    RTP based network management system, information carried in the
    discard count metric block and Burst gap discard metric block allows
    them calculate the some bust gap summary statistics,e.g., gap discard
    rate.

NEW:

    Discards due to late or early arriving packets affects user
    experience.  The reporting of discards alerts senders and other
    receivers to the need to adjust their transmission or reception
    strategies.  The reports allow network managers to diagnose these
    user experience problems.

Section 1.4., paragraph 3:
OLD:

    In case of replication being kept "on", reporting duplicate packets
    discards allows the media sender or network management system
    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.

NEW:

    The ability to detect duplicate packets can be used by managers to
    detect network layer or sender behavior which may indicate network or
    device issues.  Based on the reports, these issues may be addressed
    prior to any impact on user experience.

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

On Sun, Aug 26, 2012 at 12:41 AM, Romascanu, Dan (Dan)
<[email-masked]>wrote:

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

---

From: Qin Wu <[email-masked]>
Date: Tue, 28 Aug 2012 09:23:06 +0800

Hi,Kevin:
Your proposed improvement looks good to me. 
Thanks for your suggested text.

Regards!
-Qin
  ----- Original Message ----- 
  From: Kevin Gross 
  To: Romascanu, Dan (Dan) 
  Cc: [email-masked] 
  Sent: Monday, August 27, 2012 10:06 PM
  Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discard-06.txt

  I apologize that I was not more responsive to the recent thread (http://www.ietf.org/mail-archive/web/xrblock/current/msg00704.html) discussing revisions to this draft. I prepared the following wording improvements borrowing a bit from draft-ietf-xrblock-rtcp-xr-burst-gap-discard-05 to address my concerns about insufficient justification and context and trying to more comprehensively address Collin Perkins's concerns about leading implementers astray in duplication discussion.

NEW:

 

NEW:

NEW:

  Kevin Gross

  +1-303-447-0517
  Media Network Consultant

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

  On Sun, Aug 26, 2012 at 12:41 AM, Romascanu, Dan (Dan) <[email-masked]> wrote:

    Thanks and Regards,

    Shiba and Dan

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

---

From: Colin Perkins <[email-masked]>
Date: Fri, 31 Aug 2012 17:17:46 +0100

I agree that these changes should be incorporated before the draft goes to the IESG. I'd also suggest changing the following text in Section 3.2:

OLD:
      Note that duplicating RTP packets is for robustness or error
      resilience but disrupts RTCP statitics.  In order to tackle this,
      the mechanism described in [RTPDUP] can be used which will not
      cause breakage of RTP streams or RTCP rules.

NEW: 
      Some systems send duplicate RTP packets for robustness or error
      resilience. This is NOT RECOMMENDED since it breaks RTCP packet
      statistics. If duplication is desired for error resilience, the
      mechanism described in [RTPDUP] can be used, since this will not
      cause breakage of RTP streams or RTCP statistics.

For clarity, I'd also suggest rewriting:

OLD:
   Interval Metric flag (I): 2 bits

      This field is used to indicate whether the Discard Count Metric is
      an Interval or Cumulative metric, Sample metric [MONARCH],that is,
      whether the reported values applies to the most recent measurement
      interval duration between successive metrics reports (I=10) (the
      Interval Duration) or to the accumulation period characteristic of
      cumulative measurements (I=11) (the Cumulative Duration) or is a
      sampled instantaneous value (I=01) (Sampled Value).  In this
      document, Discard Count Metric is not measured at a particular
      time instant but over one or several reporting intervals.
      Therefore Discard Count Metric MUST not be chosen as Sampled
      Metric.

NEW:
   Interval Metric flag (I): 2 bits

      This field indicates whether the reported metric is an interval,
      cumulative, or sampled metric [MONARCH]. The Discard Count Metric
      value can be reported as either an interval metric (I=10) or a
      cumulative metric (I=11). It does not make sense to report the
      Discard Count Metric as a sampled metric, so the value I=01 MUST
      NOT be used. The value I=00 is reserved, and MUST NOT be used.

Otherwise, I have no objection to the draft progressing.

Colin

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