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

[Qin Wu <[e-mail]>]

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
>