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

["Romascanu, Dan (Dan)" <[e-mail]>]

I agree. 

What is important as a result of this discussion is that the each metric
be identified and described in an accurate and detailed manner, and the
differences between what each metric comprises (and what is measured by
the RFC 3611 metric) are clearly articulated. To ensure interoperability
we must avoid confusions. 

Dan




> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Shida Schubert
> Sent: Monday, July 09, 2012 10:31 AM
> To: Qin Wu
> Cc: xrblock
> Subject: Re: [xrblock] WGLC fordraft-ietf-xrblock-rtcp-xr-
> discardandxrblock-rtcp-xr-discard-rle-metrics
> 
> 
> Qin;
> 
>  I was just simply asking a question that came up while I was
reviewing
> the draft
> and I have no position on this.
> 
>  So what you have currently is fine with me.
> 
>  Regards
>   Shida
> 
> On Jul 9, 2012, at 2:59 PM, Qin Wu wrote:
> 
> > Hi,Shida:
> > Yes, currently we have four types. but the the 4 th type has been
> replaced with combine early, late and discarded due to duplication) in
> the current draft.
> > You are right, if we combine discards due to duplication with either
> 1, or 2, we need to have two report blocks.
> > My question, do we have the clear use case for such combinations you
> identify?
> >
> > Regarding the assumption on whether it is used when duplicate packet
> arrives early or late,
> > I think you should also consider one duplicated packet arrives on
> time and how is discareded due to that it is duplicated packet.
> >
> > Regards!
> > -Qin
> > ----- Original Message -----
> > From: "Shida Schubert" <[e-mail]>
> > To: "Varun Singh" <[e-mail]>
> > Cc: "Alan Clark" <[e-mail]>; "Qin Wu"
> <[e-mail]>; "xrblock" <[e-mail]>
> > Sent: Saturday, July 07, 2012 8:13 AM
> > Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-
> discardandxrblock-rtcp-xr-discard-rle-metrics
> >
> >
> >
> > So my question was..
> >
> > From what I can read, currently we have four types.
> >
> > 1. early ony
> > 2. late only
> > 3. both (late / early)
> > 4. other (discarded to duplicate etc.)
> >
> > According to my understanding based on Qin's response.
> >
> > When there is an occurrence of 4 along with 1,2 or 3, you
> > need to have 2 report blocks.
> >
> > 1 and 4, 2 and 4 or 3 and 4.. since we don't have a way
> > to express these combination currently..
> >
> > This is based on my assumption that other is distinguished
> > from early or late Or is it used when duplicate packet arrives
> > early or late?
> >
> > Regards
> >  Shida
> >
> > On Jul 6, 2012, at 8:34 PM, Varun Singh wrote:
> >
> >> 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/
> 
> _______________________________________________
> xrblock mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xrblock