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)" <dromasca@avaya.com> 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:bill.wu@huawei.com]
>> Sent: Friday, June 29, 2012 6:33 AM
>> To: Romascanu, Dan (Dan); Shida Schubert; xrblock
>> Cc: draft-ietf-xrblock-rtcp-xr-discard@ietf.org
>> 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)" <dromasca@avaya.com>
>> To: "Shida Schubert" <shida@ntt-at.com>; "xrblock" <xrblock@ietf.org>
>> Cc: <draft-ietf-xrblock-rtcp-xr-discard@ietf.org>;
> <draft-ietf-xrblock-
>> rtcp-xr-discard-rle-metrics@ietf.org>
>> 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
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock