Unicast-Based Rapid Acquisition of Multicast RTP Sessions
draft-ietf-avt-rapid-acquisition-for-rtp-17

[Ballot comment]
idnits reports...
  -- The document has a disclaimer for pre-RFC5378 work, but was first
    submitted on or after 10 November 2008.  Does it really need the
    disclaimer?


In the Adbstract:
    However, the proposed method...
Don't be so timid! This is about to become an RFC.

[Ballot comment]
1. I concur with Lars's DISCUSS: what will prevent people from using this technology for purposes other than rapid acquisition (e.g., as a way to bypass normal restrictions)?

2. Section 1 states that "Acquisition Delay" is "the difference between the time an RTP receiver joins the multicast session and the time the RTP receiver acquires all the necessary Reference Information". Section 4 states that three different elements contribute to "overall acquisition delay": multicast switching delay, Reference Information latency, and buffering delays. Which is it? This seems to have an impact on the problem statement and solution space.

[Ballot comment]
1. Section 1 states that "Acquisition Delay" is "the difference between the time an RTP receiver joins the multicast session and the time the RTP receiver acquires all the necessary Reference Information". Section 4 states that three different elements contribute to "overall acquisition delay": multicast switching delay, Reference Information latency, and buffering delays. Which is it?

[Ballot comment]
A well written document.

Just one comments:

What does this sentence mean when it talks about "spare" and is this an equipment resource or a network resource we are considering?

"If there is spare bandwidth, the retransmission server might burst the Reference Information faster than its natural rate."

[Ballot discuss]
(CC'ing Magnus Westerlund, whose tsv-dir review touched on the points I am raising as well.)

Section 1., paragraph 11:
>    A reasonable effort has been made in this specification to design a
>    solution that reliably works in both engineered and best-effort
>    networks.  However, a proper congestion control combined with the
>    desired behavior of this solution is difficult to achieve.  Rather,
>    this solution has been designed based on an assumption that the
>    retransmission server and the RTP receivers have some knowledge about
>    where the bottleneck between them is.  This assumption may not hold
>    unless both the retransmission server and the RTP receiver are in the
>    same edge network.  This solution is not designed to be used across
>    any best-effort path of the Internet.  Thus, a careful consideration
>    should be given when deploying this solution in best-effort networks.

  DISCUSS: This applicability statement is too weak. I really believe
  you need to restrict the applicability of this mechanism to
  managed/engineered networks. RTP streams already give us the huge
  headache of not being congestion controlled. But at least they don't
  consume unlimited amounts of bandwidth, because there is an upper
  bound on the number of bits per time interval they'll result in, since
  were talking realtime playback here. This extension makes it
  potentially MUCH worse - every time a receiver tunes in, this will
  result in a traffic burst of potentially much higher bandwidth than
  the base RTP stream. Folks will want "rapid" to be "as rapid as
  possible", meaning they'll blast at the maximum rate that they can.
  That burst isn't being congestion controlled or rate controlled at
  all, as far as I can see from the document. The only environments we
  can be sure that this won't cause harm to other traffic is
  environments where bandwidth has been provisioned so that these bursts
  can be absorbed. This is not a technology we can recommend for the
  general Internet.


Section 5., paragraph 4:
>    o  Second, providing the rapid acquisition optimizations must not
>      cause collateral damage to either the multicast session being
>      joined, or other multicast sessions sharing resources with the
>      rapid acquisition operation.  In particular, the rapid acquisition
>      operation must avoid interference with the multicast session that
>      might be simultaneously being received by other hosts.  In
>      addition, it must also avoid interference with other multicast
>      sessions sharing the same network resources.  These properties are
>      possible, but are usually difficult to achieve.

  DISCUSS: Unless you limit the applicability of this technology to
  engineered networks, where the only other traffic is other multicast
  sessions, you absolutely also need to minimize (ideally, eliminate)
  the impact on other (i.e., non-multicast) flows.


Section 5., paragraph 5:
>    One challenge is the existence of multiple bandwidth bottlenecks
>    between the receiver and the server(s) in the network providing the
>    rapid acquisition service.  In commercial IPTV deployments, for
>    example, bottlenecks are often present in the aggregation network
>    connecting the IPTV servers to the network edge, the access links
>    (e.g., DSL, DOCSIS) and in the home network of the subscribers.  Some
>    of these links might serve only a single subscriber, limiting
>    congestion impact to the traffic of only that subscriber, but others
>    can be shared links carrying multicast sessions of many subscribers.
>    Also note that the state of these links can vary over time.  The
>    receiver might have knowledge of a portion of this network, or might
>    have partial knowledge of the entire network.  The methods employed
>    by the devices to acquire this network state information is out of
>    scope for this document.  The receiver should be able to signal the
>    server with the bandwidth that it believes it can handle.  The server
>    also needs to be able to rate limit the flow in order to stay within
>    the performance envelope that it knows about.  Both the server and
>    receiver need to be able to inform the other of changes in the
>    requested and delivered rates.  However, the protocol must be robust
>    in the presence of packet loss, so this signaling must include the
>    appropriate default behaviors.

  DISCUSS: This comes back to the first part of my DISCUSS: Unless we
  can specify such a mechanism for the general Internet - and I think we
  all agree that we can't - we cannot permit deployment of this
  extension there. In other words, we need to limit it to engineered
  walled-garden networks (such as intra-ISP IPTV rollouts) where such a
  mechanism can be cobbled together with OAM information.


Section 6.4., paragraph 1:

>    This section provides informative guidelines about how the BRS can
>    shape the transmission of the unicast burst and how congestion can be
>    dealt within the RAMS process.  When the RTP_Rx detects that the
>    unicast burst is causing severe congestion, it can prefer to send a
>    RAMS-T message immediately to stop the unicast burst.

  DISCUSS: Why is this section only informative? It describes techniques
  that I'd consider essential (or at least, very, very useful), such as
  requiring to monitor packet loss and react to it (and it uses RFC2119
  language to do so...)

[Ballot comment]
Section 5., paragraph 6:
>    A second challenge is that for some uses (e.g., high-bitrate video)
>    the unicast burst bitrate is high while the flow duration of the
>    unicast burst is short.  This is because the purpose of the unicast
>    burst is to allow the RTP receiver to join the multicast quickly and
>    thereby limit the overall resources consumed by the burst.  Such
>    high-bitrate, short-duration flows are not amenable to conventional
>    admission control techniques.

  You should investigate the work of the PCN working group.


Section 6.4., paragraph 12:
>    o  When using RAMS in environments as described in (g), the BRS MUST
>      transmit the burst packets at an initial bitrate higher than the
>      nominal bitrate, but within the engineered or reserved bandwidth
>      limit.

  Right. This is feasible in engineered networks.


Section 6.4., paragraph 13:
>    o  When the BRS cannot determine a reliable bitrate value for the
>      unicast burst (using a through g), it is desirable that the BRS
>      chooses an appropriate initial bitrate not above the nominal
>      bitrate and increases it gradually unless a congestion is
>      detected.

  This is what we'd need to allow use on the general Internet. I note
  that you're halfway down the path of using TFRC here...

[Ballot discuss]
Section 1., paragraph 11:
>    A reasonable effort has been made in this specification to design a
>    solution that reliably works in both engineered and best-effort
>    networks.  However, a proper congestion control combined with the
>    desired behavior of this solution is difficult to achieve.  Rather,
>    this solution has been designed based on an assumption that the
>    retransmission server and the RTP receivers have some knowledge about
>    where the bottleneck between them is.  This assumption may not hold
>    unless both the retransmission server and the RTP receiver are in the
>    same edge network.  This solution is not designed to be used across
>    any best-effort path of the Internet.  Thus, a careful consideration
>    should be given when deploying this solution in best-effort networks.

  DISCUSS: This applicability statement is too weak. I really believe
  you need to restrict the applicability of this mechanism to
  managed/engineered networks. RTP streams already give us the huge
  headache of not being congestion controlled. But at least they don't
  consume unlimited amounts of bandwidth, because there is an upper
  bound on the number of bits per time interval they'll result in, since
  were talking realtime playback here. This extension makes it
  potentially MUCH worse - every time a receiver tunes in, this will
  result in a traffic burst of potentially much higher bandwidth than
  the base RTP stream. Folks will want "rapid" to be "as rapid as
  possible", meaning they'll blast at the maximum rate that they can.
  That burst isn't being congestion controlled or rate controlled at
  all, as far as I can see from the document. The only environments we
  can be sure that this won't cause harm to other traffic is
  environments where bandwidth has been provisioned so that these bursts
  can be absorbed. This is not a technology we can recommend for the
  general Internet.


Section 5., paragraph 4:
>    o  Second, providing the rapid acquisition optimizations must not
>      cause collateral damage to either the multicast session being
>      joined, or other multicast sessions sharing resources with the
>      rapid acquisition operation.  In particular, the rapid acquisition
>      operation must avoid interference with the multicast session that
>      might be simultaneously being received by other hosts.  In
>      addition, it must also avoid interference with other multicast
>      sessions sharing the same network resources.  These properties are
>      possible, but are usually difficult to achieve.

  DISCUSS: Unless you limit the applicability of this technology to
  engineered networks, where the only other traffic is other multicast
  sessions, you absolutely also need to minimize (ideally, eliminate)
  the impact on other (i.e., non-multicast) flows.


Section 5., paragraph 5:
>    One challenge is the existence of multiple bandwidth bottlenecks
>    between the receiver and the server(s) in the network providing the
>    rapid acquisition service.  In commercial IPTV deployments, for
>    example, bottlenecks are often present in the aggregation network
>    connecting the IPTV servers to the network edge, the access links
>    (e.g., DSL, DOCSIS) and in the home network of the subscribers.  Some
>    of these links might serve only a single subscriber, limiting
>    congestion impact to the traffic of only that subscriber, but others
>    can be shared links carrying multicast sessions of many subscribers.
>    Also note that the state of these links can vary over time.  The
>    receiver might have knowledge of a portion of this network, or might
>    have partial knowledge of the entire network.  The methods employed
>    by the devices to acquire this network state information is out of
>    scope for this document.  The receiver should be able to signal the
>    server with the bandwidth that it believes it can handle.  The server
>    also needs to be able to rate limit the flow in order to stay within
>    the performance envelope that it knows about.  Both the server and
>    receiver need to be able to inform the other of changes in the
>    requested and delivered rates.  However, the protocol must be robust
>    in the presence of packet loss, so this signaling must include the
>    appropriate default behaviors.

  DISCUSS: This comes back to the first part of my DISCUSS: Unless we
  can specify such a mechanism for the general Internet - and I think we
  all agree that we can't - we cannot permit deployment of this
  extension there. In other words, we need to limit it to engineered
  walled-garden networks (such as intra-ISP IPTV rollouts) where such a
  mechanism can be cobbled together with OAM information.


Section 6.4., paragraph 1:

>    This section provides informative guidelines about how the BRS can
>    shape the transmission of the unicast burst and how congestion can be
>    dealt within the RAMS process.  When the RTP_Rx detects that the
>    unicast burst is causing severe congestion, it can prefer to send a
>    RAMS-T message immediately to stop the unicast burst.

  DISCUSS: Why is this section only informative? It describes techniques
  that I'd consider essential (or at least, very, very useful), such as
  requiring to monitor packet loss and react to it (and it uses RFC2119
  language to do so...)

[Ballot comment]
7.1.2.  Private Extensions

  The structure that MUST be used for the private extensions is
  depicted in Figure 6.  Here, the enterprise numbers are used from
  http://www.iana.org/assignments/enterprise-numbers.  This will ensure
  the uniqueness of the private extensions and avoid any collision.

      0                  1                  2                  3
      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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Type    |  Reserved    |            Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Enterprise Number                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                            Value                            :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Pedantic remark: I don't believe that Enterprise Numbers are limited to 32bits,
although I don't think IANA will bypass the 32bit mark any time soon.

[Ballot discuss]
This is a fine document, but I have a small list of issues I would like to discuss before recommending approval of this document:


  For the purpose of gathering detailed information about RTP_Rx's
  rapid acquisition experience, [I-D.ietf-avt-multicast-acq-rtcp-xr]
  defines an RTCP Extended Report (XR) Block.  This report is designed
  to be payload-independent, thus, it can be used by any multicast
  application that supports rapid acquisition.  Support for this XR
  report is, however, OPTIONAL.

The reference looks Normative to me.

7.3.  RAMS Information

  o  Message Sequence Number (8 bits) :  Mandatory field that denotes
      the sequence number of the RAMS-I message for the particular media
      sender SSRC specified in the message header.  The MSN value SHALL
      be set to zero only when a new RAMS request is received.  During
      rapid acquisition, the same RAMS-I message MAY be repeated for
      redundancy purposes without incrementing the MSN value.  If an
      updated RAMS-I message will be sent (either with a new information
      or an updated information), the MSN value SHALL be incremented by
      one.  In the MSN field, the regular wrapping rules apply.

When the MSN overflows, is the next one going to have the value 0 or 1?

IANA understands that, upon approval of this document, there are six
IANA actions that need to be completed.

First, in the SDP names subregistry of the Session Description Protocol
(SDP) Parameters located at:

http://www.iana.org/assignments/sdp-parameters

the following addition should be made to the att-field Registration type
for Media level only:

Type SDP Name Reference
---- ------------------ ---------
att-field rams-updates [RFC-to-be]
media level only

Second, in the "ack" and "nack" Attribute Values subregistry of the
Session Description Protocol (SDP) Parameters located at:

http://www.iana.org/assignments/sdp-parameters

the following addition should be made to the registry:

Registry:
Value Name Long Name Usable with Reference
---------- --------------------------------------- ----------- ---------
rai Support for Updated RAMS Request Messages nack [RFC-to-be]

Third, in the FMT Values for RTPFB Payload Types subregistry of the
Real-Time Transport Protocol (RTP) Parameters registry located at:

http://www.iana.org/assignments/rtp-parameters

the following registration must be added:

Registry:
Value Name Long Name
-------- ------------- --------------------------------------------
TBD RAMS Rapid Acquisition of Multicast Sessions

The reference for this registration will be [RFC-to-be].
The authors suggest a value of 6 for TBD.

Fourth, a new registry is to be created in the Real-Time Transport
Protocol (RTP) Parameters registry located at:

http://www.iana.org/assignments/rtp-parameters

SFMT Values for RAMS Messages Registry
Registration procedure: specification required
The registry contains SFMT field in the RAMS messages which are single
octet, allowing 256 values (the values 0 - 255).
The reference for this new registry is to be [RFC-to-be].

There are initial registrations in this new registry:

Value Name Reference
----- -------------------------------------------------- -------------
0 Reserved [RFC-to-be]
1 RAMS Request [RFC-to-be]
2 RAMS Information [RFC-to-be]
3 RAMS Termination [RFC-to-be]
4-254 Unassigned
255 Reserved [RFC-to-be]

Fifth, a new registry is to be created in the Real-Time Transport
Protocol (RTP) Parameters located at:

http://www.iana.org/assignments/rtp-parameters

RAMS TLV Space Registry
Registration procedure: specification required
The Type field in the TLV elements is a single octet, allowing 256
values (0 - 255).
The reference for this new registry is to be [RFC-to-be].

There are initial registrations in the newly created registry:

Type Description Reference
---- -------------------------------------------------- -------------
0 Reserved [RFCXXXX]
1 Requested Media Sender SSRC(s) [RFCXXXX]
2 Min RAMS Buffer Fill Requirement [RFCXXXX]
3 Max RAMS Buffer Fill Requirement [RFCXXXX]
4 Max Receive Bitrate [RFCXXXX]
5 Request for Preamble Only [RFCXXXX]
6 Supported Enterprise Number(s) [RFCXXXX]
7-30 Unassigned
31 Media Sender SSRC [RFCXXXX]
32 RTP Seqnum of the First Packet [RFCXXXX]
33 Earliest Multicast Join Time [RFCXXXX]
34 Burst Duration [RFCXXXX]
35 Max Transmit Bitrate [RFCXXXX]
36-60 Unassigned
61 Extended RTP Seqnum of First Multicast Packet [RFCXXXX]
62-127 Unassigned
128-254 No IANA Maintenance
255 Reserved [RFCXXXX]

Sixth, a new registry is to be created in the Real-Time Transport
Protocol (RTP) Parameters located at:

http://www.iana.org/assignments/rtp-parameters

RAMS Response Code Space Registry
Registration procedure: Specification required
The length of the Response field is two octets (0-65535). The response
codes have been classified and registered following an HTTP-style code
numbering in this document.

As follows:

Code Level Purpose
---------- ---------------
1xx Informational
2xx Success
3xx Redirection
4xx RTP Receiver (RTP_Rx) Error
5xx Burst/Retransmission Source (BRS) Error

The reference for this new registry is to be [RFC-to-be].

There are initial registrations in the newly created registry:

Code Description Reference
----- -------------------------------------------------- -------------
0 A private response code is included in the message [RFC-to-be]

100 Parameter update for RAMS session [RFC-to-be]

200 RAMS request has been accepted [RFC-to-be]
201 Unicast burst has been completed [RFC-to-be]

400 Invalid RAMS-R message syntax [RFC-to-be]
401 Invalid min buffer requirement in RAMS-R message [RFC-to-be]
402 Invalid max buffer requirement in RAMS-R message [RFC-to-be]
403 Insufficient max bitrate requirement in RAMS-R
message [RFC-to-be]
404 Invalid RAMS-T message syntax [RFC-to-be]

500 An unspecified BRS internal error has occurred [RFC-to-be]
501 BRS has insufficient bandwidth to start RAMS
session [RFC-to-be]
502 Burst is terminated due to network congestion [RFC-to-be]
503 BRS has insufficient CPU cycles to start RAMS
session [RFC-to-be]
504 RAMS functionality is not available on BRS [RFC-to-be]
505 RAMS functionality is not available for RTP_Rx [RFC-to-be]
506 RAMS functionality is not available for
the requested multicast stream [RFC-to-be]
507 BRS has no valid starting point available for
the requested multicast stream [RFC-to-be]
508 BRS has no reference information available for
the requested multicast stream [RFC-to-be]
509 BRS has no RTP stream matching the requested SSRC [RFC-to-be]
510 RAMS request to acquire the entire session
has been denied [RFC-to-be]
511 Only the preamble information is sent [RFC-to-be]
512 RAMS request has been denied due to a policy [RFC-to-be]

IANA understand that these six action are all that are required upon
approval of this document.

Shepherd writeup for draft-ietf-avt-rapid-acquisition-for-rtp-11 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?

Keith Drage is the document shepherd for this document.

The document has been reviewed and is ready for forwarding to IESG for
publication.

Document history:

There were two predecessor drafts to the WG drafts in

- draft-versteeg-avt-rapid-synchronization-for-rtp-00 was
submitted 7th July 2008 and expired 8th January 2009;
- draft-versteeg-avt-rapid-synchronization-for-rtp-01 was
submitted 3rd November 2008 and expired 7th May 2009;
- draft-versteeg-avt-rapid-synchronization-for-rtp-02 was
submitted 9th March 2009 and expired 10th September 2009;
- draft-versteeg-avt-rapid-synchronization-for-rtp-03 was
submitted 16th April 2009 and expired 18th October 2009;
- draft-levin-avt-rtcp-burst-00 was submitted 27th October 2008
and expired 30th April 2009;

Resulting from a breakout session in IETF 73 the parties decided to go
offline and bring a single proposal which was progressed in the WG as
follows:

- draft-ietf-avt-rapid-acquisition-for-rtp-00 was submitted 12th
May 2009 and expired 13th November 2009;
- draft-ietf-avt-rapid-acquisition-for-rtp-01 was submitted 16th
June 2009 and expired 18th December 2009;
- draft-ietf-avt-rapid-acquisition-for-rtp-02 was submitted 25th
August 2009 and expired 26th February 2010;
- draft-ietf-avt-rapid-acquisition-for-rtp-03 was submitted 4th
September 2009 and expired 8th March 2010;
- draft-ietf-avt-rapid-acquisition-for-rtp-04 was submitted 8th
October 2009 and expired 11th April 2010;
- draft-ietf-avt-rapid-acquisition-for-rtp-05 was submitted 16th
November 2009 and expired 20th May 2010;
- draft-ietf-avt-rapid-acquisition-for-rtp-06 was submitted 4th
February 2010 and expires 8th August 2010;
- draft-ietf-avt-rapid-acquisition-for-rtp-07 was submitted 18th
February 2010 and expires 22nd August 2010;
- draft-ietf-avt-rapid-acquisition-for-rtp-08 was submitted 8th
March 2010 and expires 9th September 2010;
- draft-ietf-avt-rapid-acquisition-for-rtp-09 was submitted 26th
April 2010 and expires 28th October 2010;
- draft-ietf-avt-rapid-acquisition-for-rtp-10 was submitted 29th
May 2010 and expires 30th November 2010;
- draft-ietf-avt-rapid-acquisition-for-rtp-11 was submitted 9th
July 2010 and expires 10th January 2010;

As a result of the discussion of this draft, the following issues have
been split out into separate documents:
- draft-begen-avt-rtcp-port-for-ssm
- draft-ietf-avt-rtp-cnames
- draft-ietf-avt-ports-for-ucast-mcast-rtp
There is also specific work related to MPEG2TS preambles for rapid
acquisition for which a solution is still under discussion in the
working group.

Working group last calls were held on the document as follows:

- 22nd November 2009 on -05 version to complete 23rd December 2009.
Reviews were received from Colin Perkins.
- 5th May 2010 on -09 version to complete 26th May 2010. Reviews
were received from Dan Wing, Roni Even, Keith Drage, Colin Perkins.

Magnus Westerlund has also performed an extensive review of the
document.

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

Apart from two working group last calls, the document has been reviewed in
depth by a number of members of the WG.

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

The document does not need specific wider review. The appropriate expertise has
existed within the AVT WG.

  (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 multiple IPR disclosures in respect of the draft. After one member of
the WG expressed concern, these were explicitly brought to the attention of the
working group to see if there were other concerns. There were none.

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

The document has working group consensus. It has been widely worked on by a
significant number of people within the working group.

  (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 have been threatened.

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

The document passes ID NITs. The document has been thoroughly reviewed for
editorial consistency by the document shepherd. Additionally, RFC 2119 language
has been checked (and as part of this check a number of the requirements
rewritten) and a number of SHOULD statements revised.

There is one area of the document where RECOMMENDED has been used in section
6.2. This has been extensively discussed and has been considered to be the best
compromise wording to reflect differing opinions on what the strength of this
requirement should be.

  (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 has split its references into normative and informative references.
The normative references have been assessed by the document shepherd and are
considered to be normative references. There are no downward references (all
the normative references are proposed standard).

  (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 document does contain an IANA considerations section, and this is
consistent with the body of the document. The proposals for existing registries
and new registries have been checked for consistency with the existing
registration material.

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

The document contains one small portion of ABNF in section 8.1. This has been
verified visually to be conformant.

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

Technical summary.

When an RTP receiver joins a multicast session, it may need to acquire
and parse certain Reference Information before it can process any data
sent in the multicast session.  Depending on the join time, length of
the Reference Information repetition (or appearance) interval, size of
the Reference Information as well as the application and transport
properties, the time lag before an RTP receiver can usefully consume
the multicast data, which we refer to as the Acquisition Delay, varies
and can be large.  This is an undesirable phenomenon for receivers that
frequently switch among different multicast sessions, such as video
broadcasts.

In this document, we describe a method using the existing RTP and RTCP
protocol machinery that reduces the acquisition delay.  In this method,
an auxiliary unicast RTP session carrying the Reference Information to
the receiver precedes/accompanies the multicast stream.  This unicast
RTP flow can be transmitted at a faster than natural bitrate to further
accelerate the acquisition.  The motivating use case for this
capability is multicast applications that carry real-time compressed
audio and video.  However, the proposed method can also be used in
other types of multicast applications where the acquisition delay is
long enough to be a problem.

Working group summary

The document is a product of the AVT working group. The document has
working group consensus.

Document quality

It is understood that there are existing implementations of the
specification from a number of vendors.