RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting
draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14

[Ballot 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."

[Ballot 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.

[Ballot discuss]

There are a couple of things, esp. [DISCARD] that appear like
they ought be normative references here, or am I wrong? If
I'm not wrong, then making [DISCARD] normative will sort this
discuss. Otherwise, I'm concerned that [DISCARD] could
change in ways that break code after we've approved this one,
causing a bit of a mess. For example, see my comment on 2.1
below, where a change to [DISCARD] could cause the numbers
reported by an implementation of this to be wrong if that
implementation was based on [DISCARD] vesion -12.  (The other
things that ought be normative are an RFC and a draft in the
RFC editor queue so aren't a discuss-level problem for me.)

[Ballot comment]

- 1.1, I don't get why [DISCARD] isn't a normative reference
if this extends that. (I think something ought be a normative
reference if I need to read it to implement this.)

- 1.4, I wondered if "contain jitter buffers" would be clear
enough for all readers. Since this is the bit where you say
when this is applicable, maybe its worth being extra-clear
here? (E.g. I'm not entirely sure I know exactly what a
"jitter buffer" might be.)

- 2.1, definition of Discarded: you seem to be saying that a
packet is only counted as discarded if it arrives early or
late, but what if it arrives on-time, but contains crap?
Maybe that ought be fixed in xr-discard as well as or instead
of here? (I'm also a little surprised that we have this on
the telechat before [DISCARD] which this extends. Is that a
good idea?)

- section 3, isn't RFC 6776 also a normative reference?

- 3.1, why do you define what I=01 means, but then say it
MUST NOT be sent and MUST be discarded? That seems odd.

- 3.3 looks to me like [SUMSTAT] is also a normative
reference based on the last sentence here.

- There were a couple of nits found in the secdir review [1]
where the authors seemed to want to tweak things.

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03914.html

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-xrblock-rtcp-xr-burst-gap-discard-10.txt.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA understands that, upon approval of this document, there are two actions which IANA needs to complete.

First, in the RTCP XR Block Type subregistry of the RTP Control Protocol Extended Reports (RTCP XR) Block Type Registry located at:

http://www.iana.org/assignments/rtcp-xr-block-types/rtcp-xr-block-types.xml

a new block type will be registered as follows:

BT: [ TBD-at-Registration ]
Name: Burst/Gap Discard Metrics Block
Reference: [ RFC-to-be ]

Second, in the RTP Control Protocol Extended Reports (RTCP XR) Session Description Protocol (SDP) Parameters Registry located at:

http://www.iana.org/assignments/rtcp-xr-sdp-parameters/rtcp-xr-sdp-parameters.xml

a new parameter will be registered as follows:

Parameter: brst-gap-dscrd
Reference: [ RFC-to-be ]

IANA understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (RTP Control Protocol(RTCP) Extended Report (XR) Block for Burst/Gap Discard metric Reporting) to Proposed Standard


The IESG has received a request from the Metric Blocks for use with
RTCP's Extended Report Framework WG (xrblock) to consider the following
document:
- 'RTP Control Protocol(RTCP) Extended Report (XR) Block for Burst/Gap
  Discard metric Reporting'
  as Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-03-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines an RTP Control Protocol(RTCP) Extended Report
  (XR) Block that allows the reporting of Burst and Gap Discard metrics
  for use in a range of RTP applications.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-burst-gap-discard/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-burst-gap-discard/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard - similar to all the other XRBLOCK documents. Header says ' Intended status: Standards Track '


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document defines an RTP Control Protocol(RTCP) Extended Report
  (XR) Block that allows the reporting of Burst and Gap Discard metrics
  for use in a range of RTP applications.

Working Group Summary

The WG path of this document was reasonably short and efficient.
Several technical comments were made during the reviews and all were
resolved with consensus.


Document Quality

At least one vendor has implemented this draft. It is expected that with
the approval of this  document the number of implementations will increase.

Personnel

Dan Romascanu is the Document Shepherd. Gonzalo Camarillo
is the Responsible Area Director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have performed a detailed review of the document and I consider it
ready.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

This I-D deals with reporting of the proportion of packets discarded
by the receiver due to jitter.. The metrics carried by this
block are consistent with the definitions in RFC 3611.
Although several PM-DIR members participate in the WG, a formal RFC 6390
review could be useful.
An SDP review was already performed by Paul Kyzivat.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been submitted directly on draft-ietf-xrblock-rtcp-xr-burst-gap-discard-10.txt or its predecessors.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

The number of active participants in the Working Group is not very high (around ten). Among the active participants there seems to be solid consensus in support of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No critical issues. There is one reference to a document that has a issued more recent versions since the publication of the I-D, and one warning about [RFC6709] being unused. It is actually used and referred in two places, but the brackets were forgotten. I hope that the RFC Editor can easily fix these.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

I would recommend for another reviewer from the performance metrics directorate to do an RFC 6390 review of the I-D.

(13) Have all references within this document been identified as
either normative or informative?

Yes


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

N/A

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

N/A

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).


The document requires from IANA allocations of values in existing registries which are clearly defined.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.


N/A