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

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

Thanks, Alan. I agree with you that discarded duplicates should be
reported separately. 

Regards,

Dan



> -----Original Message-----
> From: Alan Clark [mailto:[e-mail]]
> Sent: Monday, July 02, 2012 2:49 PM
> To: Romascanu, Dan (Dan); Qin Wu; Shida Schubert; xrblock
> Cc: [e-mail]
> 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
> 
>