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

[Alan Clark <[e-mail]>]

Shida

You could have all three types of discard occurring within a single stream.
For example - if RTP replication is used for resilience then every interval
would have the same number of duplicate/other packets as data packets and if
there is a high level of jitter then there would also be late packets, early
packets or both.

Best Regards

Alan


On 7/6/12 5:07 AM, "Shida Schubert" <[e-mail]> wrote:

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