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

[Qin Wu <[e-mail]>]

Hi,Shida:
Thank for your comments, please see my replies inline.

Regards!
-Qin
----- Original Message ----- 
From: "Shida Schubert" <[e-mail]>
To: "Qin Wu" <[e-mail]>
Cc: "Alan Clark" <[e-mail]>; "Dan (Dan)" <[e-mail]>; "xrblock" <[e-mail]>; <[e-mail]>
Sent: Friday, July 06, 2012 5:07 PM
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-metrics



(as contributor)

  So does that mean that in a single report block, early and late can co-exist 
when it is described as type "both" but you can't have "other" + early, 
"other" + late or "other" + both?

[Qin]: Report early means reporting overflow, Report late means  reporting underflow.
Therefore it make sense to report underflow + overflow in one measurement interval if in that interval, sometimes overflow, sometimes underflow.
Also you can report "other" +both since report "other" + both means reporting the total discarded packet due to all the reasons.
other+ both can be used to calculate Gap Discard Rate metric in the Burst/Gap Discard Summary Statistics Block defined in  the draft-zorn-xrblock-rtcp-xr-al-stat.
However I think it doesn't make sense to report "other"+ early or "other"+late since we don't have such use case for such combination.
 
 Thus, for the same reporting period, you would have separate reporting 
block for the above discarded packets combination? If that is the case, 
I think this should be explicitly stated in the section where the type is 
described.

[Qin]: Make sense. Do you have any proposed text?

 Also, the draft reads like it is dependent on Measurement Identity based  
on the sub-section "number of packets discarded". If that is the case, the 
Mesurement Identity should become a Normative Reference. 

[Qin]: Just to clarify, as described in the definition of "number of packets discarded",
"
Note that the number of packets expected in the period covered by

the metric (whether interval or cumulative) is available from the

difference between a pair of extended sequence numbers in the

Measurement Information block [MEASI], so need not be repeated in

this block.

"
So it is not ""number of packets discarded" but "the number of packets expected " that depends
on Measurement Identity. I propose to change subsection """number of packets discarded as follows:
OLD TEXT:
"
      Note that the number of packets expected in the period covered by

      the metric (whether interval or cumulative) is available from the

      difference between a pair of extended sequence numbers in the

      Measurement Information block [MEASI], so need not be repeated in

      this block.

"
NEW TEXT:
"
      Note that the number of packets expected in the period associated with

      this metric (whether interval or cumulative) is available from the

      difference between a pair of extended sequence numbers in the

      Measurement Information block [MEASI], so need not be repeated in

      this block.

"
  
 Regards
  Shida

On Jul 3, 2012, at 11:09 AM, Qin Wu wrote:

> That's what I think, thank for your clarification.
> 
> Regards!
> -Qin
> ----- Original Message ----- 
> From: "Alan Clark" <[e-mail]>
> To: "Dan (Dan)" <[e-mail]>; "Qin Wu" <[e-mail]>; "Shida Schubert" <[e-mail]>; "xrblock" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Monday, July 02, 2012 7:49 PM
> Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-metrics
> 
> 
>> Hi Dan
>> 
>> There are some implementations of RTP that send duplicate packets (in some
>> cases every packet) in order to provide a simple form of FEC. Reporting
>> duplicate packets as "duplicates" can allow the user to determine what
>> proportion of lost packets are being concealed by the process.  For example,
>> if I send 1000 packets but duplicate these in order to provide FEC - then
>> knowing that 900 duplicate packets were discarded tells me that the network
>> packet loss rate was 10%.
>> 
>> The reason that RFC3611 excluded duplicates was that the discard count was
>> intended to show what effect late/early arriving packets were having on the
>> quality perceived by the user.  Discarded duplicates have no effect whereas
>> a discarded late packet causes a "hole" in the decoded stream that has to be
>> repaired by PLC
>> 
>> It is useful to report discards of duplicate packets "separately from" the
>> early/late arrival discard count. They should not be combined into the same
>> counter.  This means that the early/late arrival discard count would be
>> consistent with RFC3611 but there is an additional count of discarded
>> duplicate packets
>> 
>> Best Regards
>> 
>> Alan
>> 
>> 
>> On 7/2/12 6:52 AM, "Dan (Dan)" <[e-mail]> wrote:
>> 
>>> 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.
>>>> 
>>>>> 
>>> _______________________________________________
>>> xrblock mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/xrblock
>> 
>> 
>> 
>> _______________________________________________
>> xrblock mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/xrblock