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]>]

Hi Qin,
>
> Hi,Benoit:
>
> Thank for your calling and proposed changes, I like to make additional 
> rewording based on your proposed text.
>
> Please see my reply below.
>
> Regards!
>
> -Qin
>
> *From:*Benoit Claise [mailto:[e-mail]]
> *Sent:* Thursday, April 25, 2013 5:58 PM
> *To:* Qin Wu
> *Cc:* The IESG; [e-mail]; 
> [e-mail]; 
> [e-mail]
> *Subject:* Re: Benoit Claise's Discuss on 
> draft-ietf-xrblock-rtcp-xr-burst-gap-discard-13: (with DISCUSS and 
> COMMENT)
>
> 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]  <mailto:[e-mail]>;[e-mail]  <mailto:[e-mail]>;[e-mail]  <mailto:[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 tohttp://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.
>
> [Qin]: Agree, I think jitter buffer algorithms and packet discard logic are still two different things, packet discard logic can be part of jitter buffer, so I made a little bit rewording as follows:
> OLD TEXT:
> “
>     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 TEXT:
> “
>     The new block type
>     supports the reporting of the proportion of packets discarded by the
>     jitter buffer at the receiver, using packet discard logic according to the jitter buffer algorithms.
>     . The discards during discard bursts are
>     reported, together with the number of bursts.
>   
> ”
>   
[Benoit] Perfect.
>   
>     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].
>   
> [Qin]: Just to clarify, you ask me what the equivalent method is in the call, I revisited the first two paragraph of section  4.7.2 of RFC3611,
>   
> "
>     A burst is a period during which a high proportion of packets are
>     either lost or discarded due to late arrival.  A burst is defined, in
>     terms of a value Gmin, as the longest sequence that (a) starts with a
>     lost or discarded packet, (b) does not contain any occurrences of
>     Gmin or more consecutively received (and not discarded) packets, and
>     (c) ends with a lost or discarded packet.
>   
>     A gap, informally, is a period of low packet losses and/or discards.
>     Formally, a gap is defined as any of the following: (a) the period
>     from the start of an RTP session to the receipt time of the last
>     received packet before the first burst, (b) the period from the end
>     of the last burst to either the time of the report or the end of the
>     RTP session, whichever comes first, or (c) the period of time between
>     two bursts.
>   
> "
> I think the equivalent method are referring to the first two paragraph of section 4.7.2 of RFC3611 on what the burst is and what the gap is.
> In the draft-ietf-xrblock-rtcp-xr-burst-gap-discard-13, section 2.1, it said:
> “
>     Bursts and Gaps
>   
>        The terms Burst and Gap are used in a manner consistent with that
>        of RTCP XR [RFC3611].  RTCP XR views a RTP stream as being divided
>        into bursts, which are periods during which the discard rate is
>        high enough to cause noticeable quality degradation (generally
>        over 5 percent discard rate), and gaps, which are periods during
>        which discarded packets are infrequent and hence quality is
>        generally acceptable.
>   
> ”
> So draft-ietf-xrblock-rtcp-xr-burst-gap-discard-13 didn’t change what burst is and what gap is, which(Term Burst and Term Gap) are defined
> In RFC3611 and just use burst and gap defined in RFC3611.
> So maybe we can do the following change to the paragraph you are referring to:
> 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 *shall use* an
>
>    equivalent method to that defined in the section 4.7.2 of [RFC3611].
>
>   
> ”
> It is equivalent to what your proposed and also emphasize this draft use the burst and gap definition in the RFC3611.
>   
>   
> 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.*
>   
> [Qin]: Make sense, in this case, I suggest we don’t move  the sentence “The definitions of Burst, Gap, Loss and Discard are consistent with
>     definitions in [RFC3611].” from the introduction to the terminology section.
>        And I propose the following change to section 1.1 with your proposed text:
> OLD TEXT:
> “
> Section 1.1:
>     The definitions of Burst, Gap, Loss and Discard are consistent with
>     definitions in [RFC3611].  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:
> “
> Section 1.1:
> The definitions of Burst, Gap, Loss and Discard are consistent with
>    definitions in [RFC3611]. 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 shall use an
>     equivalent method to that defined in the section 4.7.2 of [RFC3611].
>     *Note that Reporting the specific jitter buffer algorithms and/or*
> *    packet discard logic is out of scope of this draft.*
[Benoit] perfect.
> **
>   
> ”
>
>       
>
>       
>
>     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]
>
> [Qin]: Agree, I propose to add the following at the end of  the definition of “ Received, Lost and Discarded”
> OLD TEXT:
> “
> Section 2.1
>     Received, Lost and Discarded
>   
>        A packet shall be regarded as lost if it fails to arrive within an
>        implementation-specific time window.  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.  A packet shall be classified as
>        one of received (or OK), discarded or lost.  The metric
>        "cumulative number of packets lost" defined in [RFC3550] reports a
>        count of packets lost from the media stream (single SSRC within
>        single RTP session).  Similarly the metric "number of packets
>        discarded" defined in [DISCARD] reports a count of packets
>        discarded from the media stream (single SSRC within single RTP
>        session) arriving at the receiver.  Another metric defined in
>        [RFC5725] is available to report on packets which are not
>        recovered by any repair techniques which may be in use.
> ”
> NEW TEXT:
> “
> Section 2.1
> Received, Lost and Discarded
>   
>        A packet shall be regarded as lost if it fails to arrive within an
>        implementation-specific time window.  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.  A packet shall be classified as
>        one of received (or OK), discarded or lost.  The metric
>        "cumulative number of packets lost" defined in [RFC3550] reports a
>        count of packets lost from the media stream (single SSRC within
>        single RTP session).  Similarly the metric "number of packets
>        discarded" defined in [DISCARD] reports a count of packets
>        discarded from the media stream (single SSRC within single RTP
>        session) arriving at the receiver.  Another metric defined in
>        [RFC5725] is available to report on packets which are not
>        recovered by any repair techniques which may be in use.
> *       Note that the term discard defined here build on the Discard*
> *       definition in [RFC 3611], but extend the concept to take into*
> *       account the packet duplication, and report different types of discard count  metrics*
> *       [draft-ietf-xrblock-rtcp-xr-discard-12].*
> ”
>
>
Great.

Post and I'll clear my DISCUSS.

Regards, Benoit
>
>
> Regards, Benoit
>