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

[Qin Wu <[e-mail]>]

Hi, Alan and all:
In the current version, we have already supported reporting the total number of discarded packets covering all three types,
i.e.,
(a). report both+ other(i.e.,duplication)

Besides, we also in this version support 
(b). reporting early
(c). reporting late
(d). reporting both early and late

Now the issue raised by Shida is:
Do we need to support other combination including 
(e). report other + early
(f). report other + late
also we may support
(g). report other independently.

My understanding is e, f, g are possible. But my concern is
Do we need to enumerate all the possible combination of all these three types
and support all these cases (i.e., from a to g)?

I think 'a' and 'd' are two most valuable use cases, since they both report 
1. the total number of discarded packet in case discards of duplicate packets are taken into account
2. the total number of discarded packet in case discards of duplicate packets are not taken into account.
Maybe the metric in both 'a' and 'd' can be used to calculate Gap Discard Rate metric, which is currently 
defined in another XR draft.

Regards!

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


> 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
>> 
> 
> 
> 
> _______________________________________________
> xrblock mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xrblock