Unicast-Based Rapid Acquisition of Multicast RTP Sessions
RFC 6285

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

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

(Robert Sparks; former steering group member) Yes

Yes ( for -)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection (2010-10-28 for -)
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
     disclaimer?


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

(Alexey Melnikov; former steering group member) (was Discuss) No Objection

No Objection (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.

(Dan Romascanu; former steering group member) No Objection

No Objection (2010-10-28 for -)
No email
send info
I support the issues raised by Lars in his DISCUSS. 

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection (2010-10-28 for -)
No email
send info
I share the concerns that Lars raised.

(Peter Saint-Andre; former steering group member) No Objection

No Objection (2010-10-27 for -)
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.

(Ralph Droms; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Sean Turner; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Stewart Bryant; former steering group member) No Objection

No Objection (2010-10-27 for -)
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." 

(Tim Polk; former steering group member) No Objection

No Objection ( for -)
No email
send info