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

[Qin Wu <[e-mail]>]

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?

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

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


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.


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

[Qin]: Okay.

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).

[Qin]: Okay.

 

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.

[Qin]: Okay and will fix this.

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

[Qin]: Okay, will move this from section 1.1 to the terminology section.
-

    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.

[Qin]: Okay.

- To finish on the positive note, thanks for the RFC6390 template.