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

[Shida Schubert <[e-mail]>]

(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?
 
 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.

 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. 
  
 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