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

["Romascanu, Dan (Dan)" <[e-mail]>]

Hi Qin,

Thank you for your response. 

I am fine with your proposed resolutions with the exception of item 3.
The resolution proposed by you suggests including packets 'thrown away
before playout (e.g., packet duplication or redundancy)' in the discard
count metric. This would make the discard count metric inconsistent to
the discard rate metric defined in section 4.7.1 of RFC 3611 which
explicitly excludes duplicate packet discards. 

Am I the only one (exaggeratedly) concerned by this inconsistency? I
would love to hear other opinions. 

Dan
(speaking as contributor)
 


> -----Original Message-----
> From: Qin Wu [mailto:[e-mail]]
> Sent: Friday, June 29, 2012 6:33 AM
> To: Romascanu, Dan (Dan); Shida Schubert; xrblock
> Cc: [e-mail]
> Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-
> discardandxrblock-rtcp-xr-discard-rle-metrics
> 
> 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]>;
<draft-ietf-xrblock-
> [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.
> 
> >