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

[Gonzalo Camarillo <[e-mail]>]

Hi Benoit,

I am glad you are happy with the use of the RFC6390 template this time ;-)

I won't be able to join the telechat tomorrow. So, let's try and resolve
your discuss via email (Qin will answer you as soon as he is back online).

Cheers,

Gonzalo

On 24/04/2013 3:53 PM, Benoit Claise wrote:
> 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:
> 
>    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?
> 
> 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].
> 
> 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."
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> EDITORIAL
> -
>    This block provides information on transient IP problems.  Burst/Gap
>    metrics are typically used in Cumulative reports, however they also
>    may be used in Interval reports. 
> 
> Cumulative -> cumulative 
> Interval -> interval 
> 
> Unless those are definitions ... in which case they need a reference.
> Reading further, I understand that you refer to:
>          I=10: Interval Duration - the reported value applies to the
>          most recent measurement interval duration between successive
>          metrics reports.
> 
>          I=11: Cumulative Duration - the reported value applies to the
>          accumulation period characteristic of cumulative measurements. 
> 
> You need a reference
> OLD:
>    This block provides information on transient IP problems.  Burst/Gap
>    metrics are typically used in Cumulative reports, however they also
>    may be used in Interval reports. 
> 
> NEW:
>    This block provides information on transient IP problems.  Burst/Gap
>    metrics are typically used in Cumulative Duration reports, however
> they also
>    may be used in Interval Duration reports (see the Interval Metric flag
> in section 3.2).
> 
>  
> 
> Note: there are many instances of capitalized words, for which I'm not
> too sure if we deal with a definition, or if it's just a bad habit to
> capitalize term in this industry. Example
> 
>   If Voice Activity Detection is used, the Burst and Gap Duration shall
>    be determined as if silence packets had been sent, i.e. a period of
>    silence in excess of Gmin packets will terminate a burst condition.
> 
>    The recommended value for the threshold Gmin in [RFC3611] results in
>    a Burst being a period of time during which the call quality is
>    degraded to a similar extent to a typical Pulse-Code Modulation(PCM)
>    Severely Errored Second.
> 
> Please be consistent.
> 
> -
> "The definitions of Burst, Gap, Loss and Discard are consistent with
> definitions in [RFC3611]."
> This sentence should be in the terminology section, and not section 1.1
> 
> -
> 
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |    BT=NBGD    | I |   resv.   |      block length = 3         |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                        SSRC of Source                         |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |   Threshold   |         Packets Discarded in Bursts           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |       Total Packets expected in bursts        |   Reserved.   |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> Bursts and burst in the same picture. Pick one.
> 
> - To finish on the positive note, thanks for the RFC6390 template.
> 
> 
>