Re: [pm-dir] Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-burst-gap-discard-13: (with DISCUSS and COMMENT)

[Benoit Claise <[e-mail]>]

Dear all,

In order to speed up the process, and to avoid exchanging many emails, I 
had a quick call with Qin. An efficient call.
See in line.
> Hi, Benoit:
> Thank for your valuable review, please see my reply inline below.
>
> Regards!
> -Qin
> -----Original Message-----
> From: Benoit Claise [mailto:[e-mail]]
> Sent: Wednesday, April 24, 2013 8:53 PM
> To: The IESG
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-burst-gap-discard-13: (with DISCUSS and COMMENT)
>
> Benoit Claise has entered the following ballot position for
> draft-ietf-xrblock-rtcp-xr-burst-gap-discard-13: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> No problem with the publication of this document.
> However, before doing so, I have 2 points I want to address: I'm missing
> something, and I don't know what.
>
> 1.
> In this sentence, I wonder which jitter calculation you were speaking
> about:
>     The new block type
>     supports the reporting of the proportion of packets discarded by the
>     receiver due to jitter.  The discards during discard bursts are
>     reported, together with the number of bursts.  This block is intended
>     to be used in conjunction with [DISCARD] which provides the total
>     packets discarded, and on which this block therefore depends.
>     However the metric in [DISCARD] may be used independently of the
>     metrics in this block.
>
> I know of the two methods [RFC 5481]
>        4.1. IPDV: Inter-Packet Delay Variation ........................11
>        4.2. PDV: Packet Delay Variation ...............................11
> Or maybe the results are independent of the jitter calculation method, in
> which case you want to clearly mention it.
> Maybe it's explained with this sentence, but I don't know how to
> interpret it:
>
> [Qin]: The reporting results is independent of jitter calculation method.
> We may add this sentence at the end of the second sentence in the paragraph you are referring to.
> However I doubt we need to add something to clarify this, since burst gap discards metrics
> have no any dependency to jitter metrics or packet delay variation metrics and will not be affected by
> jitter metrics or how jitter is calculated. Am I right?
[Benoit] Now understood.
There is a difference between the jitter on the wire (PDV versus IPDV), 
and the de-jitter buffer algorithm.
This draft focuses on the latter.
Here is a proposal.
OLD:

    The new block type
    supports the reporting of the proportion of packets discarded by the
    receiver due to jitter.  The discards during discard bursts are
    reported, together with the number of bursts.

NEW:

    The new block type
    supports the reporting of the proportion of packets discarded by the
    jitter buffer at the receiver, i.e. by the jitter buffer and packet discard logic
    algorithms. The discards during discard bursts are
    reported, together with the number of bursts.



>
>     To accommodate the range of jitter buffer
>     algorithms and packet discard logic that may be used by implementors,
>     the method used to distinguish between bursts and gaps may be an
>     equivalent method to that defined in[RFC3611].
>
> So it "may be an equivalent method to that defined in[RFC3611]."
> What if it's not the case?
>
> [Qin]: In the definition of Burst Gap in the section 2.1, we also said:
> "
>     Bursts and Gaps
>
>        The terms Burst and Gap are used in a manner consistent with that
>        of RTCP XR [RFC3611].
> "
> To make two places consistent, I propose to change the "may be" in the
> place you are referring to "is".
> OLD TEXT:
> "
>     To accommodate the range of jitter buffer
>     algorithms and packet discard logic that may be used by implementors,
>     the method used to distinguish between bursts and gaps may be an
>     equivalent method to that defined in[RFC3611].
> "
> NEW TEXT:
> "
>     To accommodate the range of jitter buffer
>     algorithms and packet discard logic that may be used by implementors,
>     the method used to distinguish between bursts and gaps is an
>     equivalent method to that defined in[RFC3611].
> "

Discussing with Qin, the intend of this paragraph is that any algorithm for jitter buffer and packet discard logic can be used at the condition that the bursts and gaps concepts are equivalent to the ones defined in [RFC 3611].

Proposal:
OLD TEXT:

    To accommodate the range of jitter buffer
    algorithms and packet discard logic that may be used by implementors,
    the method used to distinguish between bursts and gaps may be an
    equivalent method to that defined in[RFC3611].

NEW TEXT:

    Any algorithm for jitter buffer and packet discard logic
    can be used at the condition that the bursts and gaps
    concepts are equivalent to the ones defined in [RFC 3611].

It would even better (up to you) to put this text next to "The definitions of Burst, Gap, Loss and Discard are consistent with definitions in [RFC3611]."
Important note: see the DISCUSS part 2, because this sentence will probably have to changed.

NEW NEW TEXT:
    The definitions of Burst, Gap, Loss and Discard are consistent with
    definitions in [RFC3611]. This implies that any algorithm for jitter buffer
    and packet discard logic can be used at the condition that the bursts
    and gaps concepts are equivalent to the ones defined in [RFC 3611].
  
  
In the introduction, you should add a sentence such as (this was really a source of confusion for me):

    Reporting the specific jitter buffer and/or packet discard logic algorithms is out of scope of this draft.


>
> 2.
> You define "Discarded" as:
>        A packet that arrives within
>        this time window but is too early or late to be played out or
>        thrown away before playout due to packet duplication or redundancy
>        shall be regarded as discarded.
>
> I wonder: what's the point to include the discarded duplicated packet.
> Those don't affect the quality.
> On top of that, it's inconsistent with "Discard" definition of RFC 3611.
> You wrote in the draft:
>     The definitions of Burst, Gap, Loss and Discard are consistent with
>     definitions in [RFC3611].
>
> [Qin]: There was WG consensus to add this use case, I remembered it was proposed
> By Varun and Other proponent are Alan and Colin.
> Here is the pointer to one relevant discussion occured on the list when this draft was in WGLC.
> http://www.ietf.org/mail-archive/web/xrblock/current/msg00572.html
> http://www.ietf.org/mail-archive/web/xrblock/current/msg00573.html
It was discussed and agreed in the WG, fine with me.
See below.
>
>
> And RFC 3611 Discard mentions:
>     discard rate: 8 bits
>           The fraction of RTP data packets from the source that have been
>           discarded since the beginning of reception, due to late or
>           early arrival, under-run or overflow at the receiving jitter
>           buffer.  This value is expressed as a fixed point number with
>           the binary point at the left edge of the field.  It is
>           calculated by dividing the total number of packets discarded
>           (excluding duplicate packet discards) by the total number of
>           packets expected, multiplying the result of the division by
>           256, limiting the maximum value to 255 (to avoid overflow), and
>           taking the integer part.
>
> So you want to report the "Packets discarded in bursts", i.e. "The total
> number of packets discarded during discard bursts."
>
> [Qin]: It was WG consensus to report each discard type rather report any combination of discard type using one discard count metric block.
> See the relevant discussion on the list:
> http://www.ietf.org/mail-archive/web/xrblock/current/msg00617.html

>
> So Discards draft allow reporting any combination of discard types in each
> reporting interval by including several Discard Count Metric
> Report Blocks in a single RTCP XR packet.
> So it will be not problem you want to report the total number of packets discards during discard bursts.
Here is my issue.
One one side, I see

    "The definitions of Burst, Gap, Loss and Discard are consistent with
    definitions in [RFC3611]."

However, this is not correct because you take "duplication" into account 
in the Discard (actually Discarded) definition in this draft

       A packet that arrives within
       this time window but is too early or late to be played out or
       thrown away before playout due to packet_duplication_or redundancy
       shall be regarded as discarded.

What I learned from Qin over the phone is that this draft build on the 
Discard definition from RFC3611, but report multiple Discard counters.
And those multiple counters are actually covered in a different draft: 
http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-12 [DISCARD]

    Discard Type (DT): 2bits

       This field is used to identify the discard type used in this
       report block.  The discard type is defined as follows:

          00: Report packet discarded or being thrown away before playout
          due to packets duplication.

          01: Report packet discarded due to too early to be played out.

          10: Report packet discarded due to too late to be played out.


One way or the other, you want to clearly mention that this draft build 
on the Discard definition [RFC 3611], but extend the concept to take 
into account the duplication, and report different counters 
[draft-ietf-xrblock-rtcp-xr-discard-12]

Regards, Benoit