Unicast-Based Rapid Acquisition of Multicast RTP Sessions
RFC 6285

Note: This ballot was opened for revision 17 and is now closed.

(Robert Sparks) Yes

(Jari Arkko) No Objection

Comment (2010-10-28 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I share the concerns that Lars raised.

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2010-10-27 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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." 

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Lars Eggert) (was Discuss) No Objection

Comment (2010-10-26)
No email
send info
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...

(Adrian Farrel) No Objection

Comment (2010-10-28 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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

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

(Russ Housley) No Objection

Alexey Melnikov (was Discuss) No Objection

Comment (2010-10-23)
No email
send info
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.

(Tim Polk) No Objection

(Dan Romascanu) No Objection

Comment (2010-10-28 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I support the issues raised by Lars in his DISCUSS. 

(Peter Saint-Andre) No Objection

Comment (2010-10-27 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Sean Turner) No Objection