Skip to main content

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

Yes

(Robert Sparks)

No Objection

(Gonzalo Camarillo)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Tim Polk)

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

Robert Sparks Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2010-10-28) Unknown
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 IESG member
(was Discuss) No Objection
No Objection (2010-10-23) Unknown
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 IESG member
No Objection
No Objection (2010-10-28) Unknown
I support the issues raised by Lars in his DISCUSS. 
Gonzalo Camarillo Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2010-10-28) Unknown
I share the concerns that Lars raised.
Lars Eggert Former IESG member
(was Discuss) No Objection
No Objection (2010-10-26) Unknown
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...
Peter Saint-Andre Former IESG member
No Objection
No Objection (2010-10-27) Unknown
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 IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection () Unknown

                            
Stewart Bryant Former IESG member
No Objection
No Objection (2010-10-27) Unknown
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 IESG member
No Objection
No Objection () Unknown