Subject: [AVT] comments on draft-ietf-avt-rapid-acquisition-for-rtp-09

From: "Dan Wing" <[email-masked]>
Date: Tue, 11 May 2010 10:34:31 -0700

I mostly reviewed Sections 9 and 10.

-d

-----

1.

Section 9,

   a.  See UDP traffic sent from RTP_Rx (which is on the 'inside' of the
       NAT) to BRS (which is on the 'outside' of the NAT).  This traffic
       is sent to the same transport address as the subsequent response
.......^^^^^^^^^^
.........."has"         (because it needs the same source address,
                         source port, destination address, destination
                         port, and protocol=UDP).  Easiest way is "has
                         same transport address".)

2.

Section 9,

   When RTP_Rx sends a RAMS-R message to FT as unicast feedback in the
.......................^^^^^^^^^^^^^^
   primary multicast RTP session, and the request is received by FT, a
......................................^^^^^^^^^^^

I suppose "RAMS-R message" and "the request" are the same thing.  Can
the same terminology be used?

3.

Section 9,

   When RTP_Rx sends a RAMS-R message to FT as unicast feedback in the
........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This says a message is sent to FT.

   primary multicast RTP session, and the request is received by FT, a
   new unicast burst RTP session will be established between BRS and
   RTP_Rx.

   While the FT and BRS ports on RS are already signaled via out-of-band
.............^^^^^^^^^^^^^^^^^^^^^^
This says a message is sent to the FT ports on the RS.  The highlighted
sentence in the paragraph above is written differently.  Is this 
difference intentional?

4.

Section 9,

   While the FT and BRS ports on RS are already signaled via out-of-band
   means (e.g., SDP), RTP_Rx needs to convey the RTP and RTCP ports it
   wants to use on its side for the new session.  Since there are two
   RTP sessions involved during this process and one of them is
...^^^^^^^^^^^^^^^^^^^^^
Add a paranthetical statement that the two RTP sessions are the
unicast and multicast sessions (which is what I think is intended), 
or that they are the RTP and the RTCP sessions (which is mentioned
in the previous sentence, causing me to ask for clarification).  

5.

Section 9,

   applies to scenarios where the RTP media is multicast in an SSM
   session, and an RTP receiver requests retransmission from a local
...................^^^^^^^^^^^^
            should that be "RTP_Rx"?  If not, why not?

6. 

   Applications using RAMS MUST support this solution both on the RS and
........................................^^^^^^^^^^^^^
                               which solution is "this"?  Is "this"
                   referring to draft-ietf-avt-ports-for-ucast-mcast-rtp
                                   in the previous paragraph?  If
                  so, please reword and make it clearer; "this" could
                  be referring to "this document" (RAMS).

   RTP_Rx side to allow RTP receivers to use their desired ports and to
   support RAMS behind NAT devices.  

7.

Section 6,

   6. Rapid Acquisition of Multicast RTP Sessions

   We start this section with an overview of the rapid acquisition of
   multicast sessions (RAMS) method.

Oh, so this document *defines* RAMS.  How about adding "(RAMS)" to
the end of Section 6's title.  Or the document's title?

8.

Security Considerations:

   First of all, much of the session description information is
   available in the SDP descriptions that are distributed to the media
   senders, retransmission servers and RTP receivers.  Adequate security
   measures are RECOMMENDED to ensure the integrity and authenticity of
   the SDP descriptions so that transport addresses of the media
   senders, distribution sources, feedback targets as well as other
   session-specific information can be authenticated.
.......................................^^^^^^^^^^^^^
                                       protected

9.

Security Considerations:

   To reduce the impact of
   DTLS-SRTP overhead when communicating with different feedback targets
   on the same retransmission server, it is RECOMMENDED that RTP
   receivers and the retransmission server both support TLS Session
   Resumption without Server-side State [RFC5077].

If the retransmission server needs to send a lot of the same information,
unicast, to a lot of RTP_Rx devices, you might also encourage implementors to
consider draft-ietf-avt-srtp-ekt.

-d

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 11 May 2010 10:47:48 -0700

Hi Dan,
 
>        is sent to the same transport address as the subsequent response

OK.
 
>    When RTP_Rx sends a RAMS-R message to FT as unicast feedback in the

Yes, will fix this.

>    When RTP_Rx sends a RAMS-R message to FT as unicast feedback in the

Yes, RAMS-R message goes to the FT port but session is established on the BRS port.
  
>    RTP sessions involved during this process and one of them is

Will do.

>    session, and an RTP receiver requests retransmission from a local

Good catch.
 
>    Applications using RAMS MUST support this solution both on the RS and

Will refer to the cookie solution.

> the end of Section 6's title.  Or the document's title?

Will add it to section 6's title and the short title on page headers.

>    session-specific information can be authenticated.

OK.
 
> consider draft-ietf-avt-srtp-ekt.

Sounds good. 

Thanks,
-acbegen