Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-metrics

[Qin Wu <[e-mail]>]

Hi,Dan:
Thank for your valuable review to draft-ietf-xrblock-rtcp-xr-discard.
Please see my replies inline.

Regards!
-Qin
----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: "Shida Schubert" <[e-mail]>; "xrblock" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Thursday, June 28, 2012 8:02 PM
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-metrics


> (as contributor)
> 
> I read the documents and they look almost ready for submission to the
> IESG. 
> 
> Here are a few comments on draft-ietf-xrblock-rtcp-xr-discard:
> 
> 1. It would be useful I think to say more about the relation between
> this metric and the discard rate metric defined in section 4.7.1 of RFC
> 3611. Maybe calling the metric here Discarded Packets metric would help,
> as both RFC 3611 and this document refer to 'discard metric' but the two
> are different (one is rate, the other packets). 

[Qin]: Good point, I propose to change 'discard metric' in this document into 'discard count  metric' since
abstract in this draft also uses 'discard count metric'.

To make this consistent with SDP parameter defined in this document, I also like to propose to do the following change
OLD TEXT:
"
   xr-format =/ xr-pd-block

    xr-pd-block = "pkt-dscrd"

"
NEW TEXT:
"
   xr-format =/ xr-pdc-block

    xr-pdc-block = "pkt-dscrd-count"


"

> 2. In Section 3.1 diagram we use NBGD for Block Type, while the text in
> Section 3.2 refers to the ND constant. We should get to a consistent
> representation 

[Qin]: It is a typo and will fix this by changing NBGD into ND.
> 
> 3. 
> 
> Section 2.1: 
> 
>      A packet that arrives within
>      this time window but is too early or late to be played out shall
>      be regarded as discarded.  A packet shall be classified as one of
>      received (or OK), discarded or lost.  The Discard Metric counts
>      only discarded packets.  
> 
> Section 3.1 however includes: 
> 
>         00: packets are discarded due to other reasons than late
>         arrival, early arrival, or both (e.g., duplicate, redundant
>         packets).
> 
> This seems inconsistent. 

[Qin]: Good question. To make them consistent, I propose do the following change to Section 2.1
OLD TEXT:
"
     A packet that arrives within
      this time window but is too early or late to be played out shall
      be regarded as discarded.  A packet shall be classified as one of
      received (or OK), discarded or lost.  The Discard Metric counts
     only discarded packets.  

"
NEW TEXT:
"
A packet that arrives within

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

or is thrown away before playout (e.g., 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.
"

> 4. Is there any reasons for the Interval Metric flag (I) to be 2 bits,
> rather than one bit, with the other one reserved? 

[Qin]: Good question, I remembered we got a suggestion on the list before from Kevin Gross which suggested to 
remove Sampled metric related description from the definition of Interval Metric flag. Since Sampled metric is 
measured only at a particular time instant however metrics defined in this document is 
measured over one or several reporting intervals.To get in line with the defintion 
of the Interval Metric flag in other XR BLOCK drafts and address your comment, 
I propose the following change to the defintion of the interval metric flag:

OLD TEXT:
"
   Interval Metric flag (I): 2 bits

      This field is used to indicate whether the Discard metric is an
      Interval or Cumulative metric, 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).

"
NEW TEXT:
"
   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,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.

"


> 5. number of packets discarded:
> 
>> If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE
>      SHOULD be reported to indicate an over-range measurement.  

> Why is this a SHOULD and not a MUST? Are there any exceptions? 

[Qin]: No,  I will use MUST based on your comment.

> 6. In the IANA Considerations section: 
> 
> s/ The contact information for the registrations is/ The following
> contact information is provided for all registrations in this document/

[Qin]: Okay.

>