Subject: [AVT] Accpeting the port mapping between unicast and multicast RTP sessions as WG item

From: Roni Even <[email-masked]>
Date: Fri, 19 Feb 2010 19:44:20 +0200

Hi,

The topic of port mapping between unicast and multicast RTP sessions is
required for the unicast based rapid acquisition of multicast sessions
(RAMS).  This work was discussed in the last IETF meetings and there was an
agreement that it is an important for RAMS also on the mailing list.

We would like to accept this topic as a WG item and use
http://tools.ietf.org/html/draft-begen-avt-ports-for-ucast-mcast-rtp-02  as
a the initial document.

Please give any feedback till February 26th.

Thanks

Roni Even AVT co-chair

---

From: David R Oran <[email-masked]>
Date: Fri, 19 Feb 2010 13:30:19 -0500

On Feb 19, 2010, at 12:44 PM, Roni Even wrote:

> Hi,
> The topic of port mapping between unicast and multicast RTP sessions is required for the unicast based rapid acquisition of multicast sessions (RAMS).  This work was discussed in the last IETF meetings and there was an agreement that it is an important for RAMS also on the mailing list.
> We would like to accept this topic as a WG item and use http://tools.ietf.org/html/draft-begen-avt-ports-for-ucast-mcast-rtp-02  as a the initial document.
Please do. And progress it quickly as we already know it will be a gating item for RAMS to pass IESG muster.

> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 19 Feb 2010 14:11:46 -0800

> The topic of port mapping between unicast and multicast RTP 
> sessions is required for the unicast based rapid acquisition 
> of multicast sessions (RAMS).  This work was discussed in the 
> last IETF meetings and there was an agreement that it is an 
> important for RAMS also on the mailing list.
> 
> http://tools.ietf.org/html/draft-begen-avt-ports-for-ucast-mca
> st-rtp-02  as a the initial document.
> 
>  
> 

Please adopt as a WG document.

Comments on the I-D,

Nit:  is it possible to choose 'receiver' or 'client', and use it
consistently?  Or is there a reason the two terms are used?  For example,
Figure 1 uses 'client RTP application' whereas Section 4.3 is titled
"Receiver-Generated Cookie Approach", but the text of 4.3.1 talks about the
client.

Section 3,

   o  Do not try to correlate information from messages that do not
      fate-share.  

Don't fail to not retain the double negative.  :-)  

How about:

NEW:
  o  Try to correlate information from messages that share fate.

(but I don't know what the original message was trying to not say to not
do....)

Section 3,

   o  Do not carry transport addresses explicitly at the application
      layer, which is a layer violation.

SDP is an application.  Can we all go home now?  ;-)

In Section 3,

      Note that the cookies are not meant to be understood by the
      clients or other application-layer gateway devices.  Thus, a
      server may use any method of its choice to make the cookie data
      opaque.

Does that same design consideration apply when the client chooses the cookie,
as done in Section 4.3?  Seems like that design consideration should be
generalized a bit more, so that whatever side generates an opaque cookie.

Section 3,

   o  Be NAT-tolerant [RFC5389] [RFC4787].

Do you want to say anything about IPv6/IPv4 translation?  I think you don't,
because BEHAVE has not even started work on multicast NAT64.  So you probably
want to declare IPv6/IPv4 translation out of scope.

I admit that I don't understand the implications of the Editor's Note of item
#6 in Section 4.2.1.

Nit in Section 4.2.2:

OLD:
   If there is a NAT device between the server and client, the client
   may still acquire the cookies at the beginning, provided that it is
   behind a NAT that assigns the same public IP address and port for the
   messages sent from the same internal IP address and port even when
   ithe client is talking to different destinations.
   However, if this is not true, i.e., the public address(es) and/or
   port(s) of the client changes when the client communicates with a 
   different feedback target on the same server, the client MUST 
   fall back to acquiring a cookie for each distinct 3-tuple of (S, 
   P3, c2) and (S, P3, c3).

NEW:
   If there is a NAT device between the server and client, the client
   may still acquire the cookies at the beginning, provided that it is
   behind a NAT that assigns the same public IP address and port for the
   messages sent from the same internal IP address and port even when
   ithe client is talking to different destinations.
   ^^^^                                            ^
   should be "the"                                 ^
                                                   ^
                        add: "("endpoint-independent mapping" [RFC4787])"

   However, if the NAT has endpoint-dependent mapping [RFC4787], 
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   the client MUST 
   fall back to acquiring a cookie for each distinct 3-tuple of (S, 
   P3, c2) and (S, P3, c3).

Section 4.3.1, are all of those paragraphs after #6 part of #6?  Seems not,
because the last paragraph seems like it should be associated with #3.

Section 4.3.2,

   When there is a NAT device between the server and client, there is a
   risk of a cookie collision, although it is unlikely if the random
   cookies are generated properly.

Please provide better guidance than "generate it properly".  Item #3 in 4.3.1
just says "The client generates a random cookie" and bottom of 4.3.1 says
"generated cookies should be truely random".  But we all know how poorly
people chose random values (date+time+IP address seems pretty random, until
two people with 192.168.1.1 in two houses change channel at same time...).
Based on:

       After the server has established a port mapping for the 2-tuple
       of cookie and public IP address of the client, it discards RTCP
       packets carrying the same cookie coming from the same public IP
       address but from a different public port.

it seems the cookie needs to only be unique for all the clients *behind* a
NAT??

-d

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Mon, 22 Feb 2010 10:11:35 +0100

I am fully supportive of this new WG item, and would like to see it
progress as fast as possible..!
Regards
Tom

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni Even
Sent: vrijdag 19 februari 2010 18:44
To: [email-masked]
Cc: 'Tom Taylor'; DRAGE Keith
Subject: [AVT] Accpeting the port mapping between unicast and multicast
RTP sessions as WG item

Hi,

The topic of port mapping between unicast and multicast RTP sessions is
required for the unicast based rapid acquisition of multicast sessions
(RAMS).  This work was discussed in the last IETF meetings and there was
an agreement that it is an important for RAMS also on the mailing list.

We would like to accept this topic as a WG item and use
http://tools.ietf.org/html/draft-begen-avt-ports-for-ucast-mcast-rtp-02
as a the initial document.

Thanks

Roni Even AVT co-chair

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Mon, 22 Feb 2010 10:04:51 -0600

I strongly support accepting this as a WG item.

Bvs

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni Even
Sent: Friday, February 19, 2010 12:44 PM
To: [email-masked]
Cc: 'Tom Taylor'; 'DRAGE,Keith (Keith)'
Subject: [AVT] Accpeting the port mapping between unicast and multicast
RTP sessions as WG item

Hi,

Thanks

Roni Even AVT co-chair

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 22 Feb 2010 11:06:32 -0800

Hi Dan,

Thanks for the careful review. I noted the nits, they will be fixed in
the next revision. I also put a reference to RFC 4086 for proper random
number generation as you suggested. 

-acbegen

> -----Original Message-----
> From: Dan Wing (dwing)
> Sent: Friday, February 19, 2010 5:12 PM
> To: 'Roni Even'; [email-masked]
> Cc: 'Tom Taylor'; 'DRAGE,Keith (Keith)';
[email-masked];
> Bill Ver Steeg (versteb); Ali C. Begen (abegen)
> Subject: RE: [AVT] Accpeting the port mapping between unicast and
multicast RTP sessions as WG item