Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)
draft-ietf-avtext-multicast-acq-rtcp-xr-06

[Ballot discuss]
Revised to accomodate draft-05. One pending issue left.

1. Some of the basic terms for the understanding of this document are being referenced from [I-D.ietf-avt-rapid-acquisition-for-rtp]. It looks to me that this document should be a Normative rather than Informational reference.

[Ballot discuss]
1. Some of the basic terms for the understanding of this document are being referenced from [I-D.ietf-avt-rapid-acquisition-for-rtp]. It looks to me that this document should be a Normative rather than Informational reference.

2. The Specification Required policy defined in Section 7.5 makes the following recommendation.

  The length of the Status field is two octets, allowing 65536 codes.
  However, the status codes have been registered to allow for an easier
  classification.  For example, the values between (and including) 1
  and 1000 are primarily used by the MA method of simple join.  The
  values between (and including) 1001 and 2000 are used by the MA
  method described in [I-D.ietf-avt-rapid-acquisition-for-rtp].  When
  registering new status codes for the existing MA methods or newly
  defined MA methods, a similar classification scheme is encouraged to
  be followed.

However, there are currently 253 unassigned method values, so there is no room for an allocation of 1000 codes for each of them which creates a potential problem in the future. The language should be ammended (something else than 'similar classification scheme') and include some warning to IANA for caution on this issue.

[Ballot comment]
1) in 4.1, "Rsvd. (16 bits): The RTP receiver MUST set this bit to zero. The recipient MUST ignore this bit when received." - MUST ignore these bits or MUST ignore this field.
2) in 7.1, do you want to replcae or supplement the existing RFC#?
3) in 7.4, should 0, 255, and 128-254 be included in the registry with approrpiate notations?

[Ballot comment]
(1) s/one ore more/one or more/

(C2 The constant 11 - I assume that's decimal - probably worth
saying just in case someone interprets it as '11'H or 3 or
whatever.

(C3 I think you want to to s/this bit/this field/g below. 

      o  Rsvd. (16 bits):  The RTP receiver MUST set this bit to zero.  The
      recipient MUST ignore this bit when received.

(4) Suggest rephrasing this in 4.2.1 (how can a time measured
locally be negative?)

OLD

  o  SFGMP Join Time (32 bits):  TLV element that denotes the greater
      of zero or the time difference (in ms) between the instant SFGMP
      Join message has been sent and the instant the first packet was
      received in the multicast session.

NEW
  o  SFGMP Join Time (32 bits):  TLV element
      with the time difference (in ms) between the instant the SFGMP
      Join message was sent and the instant the first packet was
      received in the multicast session.

[Ballot comment]
It would have helped me as a reader to have had some idea of the range
of potential sizes of the random acquisition delay. I suspect that it
can be expressed in packets and extrapolated to a time interval based
on line speeds, etc. Obviously (?) if the range is 0 to < 1ms we might
conclude that this work is not very necessary.

Can you add a short note to help scope the work?

---

Section 3 says:

  This document uses the following acronyms and definitions from
  [I-D.ietf-avt-rapid-acquisition-for-rtp]:

But the definitions presented are somewhat different from those in
the referenced document. Although the intent may be the same, I don't
think it is helpful to have different definitions and I recommend that
you remove all but a list of terms and a pointer to the other I-D.

---

Nit
Abstract                 
s/ore/or/

[Ballot comment]
Additional text describing the assumptions around when you would use a status code of zero would help greatly. The expected use is that the sender of a report would only use that code when it knew from out-of-band methods that the receiver would understand the private TLVs in the report - one of those private TLVs, ostensibly, would replace semantics of the status code. Saying that explicitly would help avoid the situation where a client unintentionally throws away information like "multicast join was successful" by adding a private TLV that the server doesn't understand to a report that it would otherwise have used a status code of 1 on.

[Ballot comment]
In 4:

  It is better to send the MA report block after all the necessary
  information is collected and computed.  Partial reporting is
  generally not useful as it cannot give the full picture of the
  multicast acquisition, and causes additional complexity in terms of
  report block matching and correlation.  The MA report block is only
  sent as a part of an RTCP compound packet, and it is sent in the
  primary multicast session.

Is there a reason 2119 language was not used here? (i.e., SHOULD send
only after all information is collected, MUST send as part of an RTCP
compound packet in the primary multicast session)

In 4.2.1:

  o  SFGMP Join Time (32 bits):  TLV element that denotes the greater
      of zero or the time difference (in ms) between the instant SFGMP
      Join message has been sent and the instant the first packet was
      received in the multicast session.  If the multicast join was
      successful, this element MUST be included.  If no multicast packet
      has been received, this element MUST NOT exist in the report
      block.

and

  o  Size of Burst-to-Multicast Gap (32 bits):  Optional TLV element
      that denotes the greater of zero or the difference between the
      sequence number of the first multicast packet (received from the
      primary multicast stream) and the sequence number of the last
      burst packet minus 1 (considering the wrapping of the sequence
      numbers).  If no burst packet has been received in the unicast
      session or no RTP packet has been received from the primary
      multicast stream, this element MUST NOT exist in the report block.

When could the "greater of zero or" part kick in? That is, when can the
difference possibly be negative?

[Ballot comment]
Sec 4: r/The optional extensions that are/The OPTIONAL extensions that are

Sec 4.2.1: r/Optional/OPTIONAL  x 9. For Types 1 and 2 - are they optional too?

IANA understands that, upon approval of this document, there are five
IANA Actions that must be completed.

First, in 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

the reference to the RTCP XR Block Type with BT value 11 will be updated
to refer to [ 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 SDP Parameter is to be registered as follows:

Parameter: multicast-acq
Reference: [ RFC-to-be ]

Third, a new RTCP registry called the "RTCP Multicast Acquisition Method
Registry" will be created. Management and maintenance of the registry
will be done through "Specification Required" as per RFC5226. The
values of the registry range from 0-255 inclusive. The intial registry
is as follows.

MA Method Description Reference
--------- ------------------------------------ -------------
0 Reserved [ RFC-to-be ]
1 Simple join (No explicit method) [ RFC-to-be ]
2 RAMS [I-D.ietf-avt-rapid-acquisition-for-rtp]
3-254 Specification Required
255 Reserved [ RFC-to-be ]

The MA Method values 0 and 255 are reserved for future use.

Fourth, a new RTCP registry called the "RTCP Multicast Acquisition
Report Block TLV Space Registry" will be created. Management and
maintenance of the registry will be done through "Specification
Required" as per RFC5226. The values of the registry range from 0-255
inclusive. The intial registry is as follows.

Type Description Reference
---- -------------------------------------------------- -------------
1 RTP Seqnum of the First Multicast Packet [ RFC-to-be ]
2 SFGMP Join Time [ RFC-to-be ]
3 Application Request-to-Multicast Delta Time [ RFC-to-be ]
4 Application Request-to-Presentation Delta Time [ RFC-to-be ]
11 Application Request-to-RAMS Request Delta Time [ RFC-to-be ]
12 RAMS Request-to-RAMS Information Delta Time [ RFC-to-be ]
13 RAMS Request-to-Burst Delta Time [ RFC-to-be ]
14 RAMS Request-to-Multicast Delta Time [ RFC-to-be ]
15 RAMS Request-to-Burst-Completion Delta Time [ RFC-to-be ]
16 Number of Duplicate Packets [ RFC-to-be ]
17 Size of Burst-to-Multicast Gap [ RFC-to-be ]

The Type values 0 and 255 are reserved for future use. The Type values
between (and including) 128 and 254 are reserved for private extensions.

Fifth, a new RTCP registry called the "Multicast Acquisition Status Code
Space Registry" will be created. Management and maintenance of the
registry will be done through "Specification Required" as per RFC5226.
The values of the registry range from 0-65536 inclusive. The intial
registry is as follows.

Code Description Reference
----- -------------------------------------------------- -------------
0 A private status code is included in the message [ RFC-to-be ]
1 Multicast join was successful [ RFC-to-be ]
2 Multicast join has failed [ RFC-to-be ]
3 A presentation error has occurred [ RFC-to-be ]
4 An unspecified RR internal error has occurred [ RFC-to-be ]
1001 RAMS has been successfully completed [ RFC-to-be ]
1002 No RAMS-R message has been sent [ RFC-to-be ]
1003 Invalid RAMS-I message syntax [ RFC-to-be ]
1004 RAMS-I message has timed out [ RFC-to-be ]
1005 RAMS unicast burst has timed out [ RFC-to-be ]
1006 An unspecified RR internal error has occurred
during RAMS [ RFC-to-be ]
1007 A presentation error has occurred during RAMS [ RFC-to-be ]

The Status code 65535 is reserved for future use.

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

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)) to Proposed Standard


The IESG has received a request from the Audio/Video Transport Extensions
WG (avtext) to consider the following document:
- 'Multicast Acquisition Report Block Type for RTP Control Protocol
  (RTCP) Extended Reports (XRs)'
  as a 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 2011-04-26. 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.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-avtext-multicast-acq-rtcp-xr/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-avtext-multicast-acq-rtcp-xr/

Shepherd writeup for draft-ietf-avtext-multicast-acq-rtcp-xr-03
"Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP)
Extended Reports (XRs)" as proposed standard.

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

The document shepherd for this document is Keith Drage.

The document shepherd has reviewed the document and believes it is ready for
forwarding to the IESG for publication.

Document history:

- draft-begen-avt-rapid-sync-rtcp-xr-00 was submitted 3rd March
2009 and expired 4th September 2009;
- draft-begen-avt-rapid-sync-rtcp-xr-01 was submitted 13th May 2009
and expired 14th November 2009;
- draft-begen-avt-rapid-sync-rtcp-xr-02 was submitted 10th August
2009 and expired 11th February 2010;
- draft-begen-avt-rapid-sync-rtcp-xr-03 was submitted 22nd October
2009 and expired 25th April 2010;
- draft-ietf-avt-multicast-acq-rtcp-xr-00 was submitted 16th
February 2010 and expired 20th August 2010;
- draft-ietf-avt-multicast-acq-rtcp-xr-01 was submitted 20th May
2010 and expired 21st November 2010;
- with the creation of the AVTEXT working group from the ashes of AVT,
the document moved to AVTEXT, and draft-ietf-avtext-multicast-acq-rtcp-xr-
00 was submitted 5th March 2011 and expires 6th September 2011;
- draft-ietf-avtext-multicast-acq-rtcp-xr-01 was submitted 30th
April 2011 and expires 1st October 2011;
- draft-ietf-avtext-multicast-acq-rtcp-xr-02 was submitted 6th
April 2011 and expires 8th October 2011;
- draft-ietf-avtext-multicast-acq-rtcp-xr-03 was submitted 11th
April 2011 and expires 13th October 2011;

Call for adoption of baseline as WG item was made September 8th 2009 and
acceptance declared 15th February 2010.

Working group last call was initiated on -01 version on 15th June 2010
for completion 29th June 2010 as proposed standard. No reviews were
received. The document was reviewed without comment by Roni Even.
Colin Perkins reviewed, and stated "don't like the encoding, or the
ability to use private extensions, but the metrics look okay".
Prior to working group last call, comments had been received from
Cullen Jennings, Tom van Caenegem. The document has since been reviewed
by Magnus Westerlund, in addition to the document shepherd.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

The document has been adequately reviewed (see 1a above).

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

There are no such concerns from the document shepherd.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues 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. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

There are no concerns from the document shepherd from this perspective with the
document.

No IPR disclosures have been made against this document.

  (1.e) 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? 

From a reviewing perspective, the interest in this specific document has been
relatively small, but it forms an essential part of draft-ietf-avt-rapid-
acquisition-for-rtp which has been well and substantially reviewed. It
is assumed that the interested parties in that document have also reviewed this
document.

  (1.f) 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
        entered into the ID Tracker.)

No appeals or areas of conflict or discontent have been identified.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Version 2.12.09 of ID nits identifies no issues.

No other formal reviews outside of the AVT working group are perceived as
necessary for this document.

  (1.h) Has the document split its references into normative and
        informative? 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
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

The document does split normative and informative references. All the normative
references have been reviewed and are correctly allocated as normative
references. None of these normative references constitute a down reference.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The IANA considerations have been reviewed, the registries are correctly
identified. The document creates two new registries for which the policy has
been appropriately defined.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

One change to an SDP attribute has been defined in ABNF. This is an extension
to the ABNF in RFC 3611. The ABNF has been validated by visual inspection.

  (1.k) 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
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.
    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?
    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

In most RTP-based multicast applications, the RTP source sends inter-
related data.  Due to this interdependency, randomly joining RTP
receivers usually cannot start consuming the multicast data right after
they join the session.  Thus, they often experience a random
acquisition delay.  An RTP receiver can use one ore more different
approaches to achieve rapid acquisition.  Yet, due to various factors,
performance of the rapid acquisition methods usually varies.
Furthermore, in some cases the RTP receiver can (or be compelled to) do
a simple multicast join.  For quality reporting, monitoring and
diagnostics purposes, it is important to collect detailed information
from the RTP receivers about their acquisition and presentation
experiences.  This document addresses this issue by defining a new
report block type, called Multicast Acquisition (MA) Report Block,
within the framework of RTP Control Protocol (RTCP) Extended Reports
(XR) (RFC 3611).  This document also defines the necessary signalling
of the new MA report block type in the Session Description Protocol
(SDP).


The document achieved consensus in the AVT working group.