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

[Varun Singh <[e-mail]>]

On Fri, Jul 6, 2012 at 1:51 PM, Alan Clark <[e-mail]> wrote:
> 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.
>

I agree that one of early, late or others or any combination of the
three is a valid reporting case.
Perhaps there needs to be only a clarification on when to use early
and late or combined early and late.

Regards,
Varun

> 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



-- 
http://www.netlab.tkk.fi/~varun/