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

"Benoit Claise" <bclaise@cisco.com> Wed, 24 April 2013 12:53 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E65C21F911E; Wed, 24 Apr 2013 05:53:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlEvhYwSJa+F; Wed, 24 Apr 2013 05:53:28 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA77721F90D5; Wed, 24 Apr 2013 05:53:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Benoit Claise <bclaise@cisco.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 4.44.p4
Message-ID: <20130424125328.393.36074.idtracker@ietfa.amsl.com>
Date: Wed, 24 Apr 2013 05:53:28 -0700
Cc: xrblock-chairs@tools.ietf.org, draft-ietf-xrblock-rtcp-xr-burst-gap-discard@tools.ietf.org, "pm-dir@ietf.org" <pm-dir@ietf.org>
Subject: [pm-dir] Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-burst-gap-discard-13: (with DISCUSS and COMMENT)
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Apr 2013 12:53:29 -0000

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.