Re: [AVT] Revised Consensus call - On Token approach for draft-ietf-avt-ports-for-ucast-mcast-rtp

["Van Caenegem, Tom (Tom)" <[e-mail]>]

Hi Colin,

See below,
Tom 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Colin Perkins
Sent: maandag 11 oktober 2010 18:51
To: Roni Even
Cc: DRAGE, Keith (Keith); 'IETF AVT WG'; 'Dan Wing'
Subject: Re: [AVT] Revised Consensus call - On Token approach for draft-ietf-avt-ports-for-ucast-mcast-rtp

On 8 Oct 2010, at 09:47, Roni Even wrote:
> There were some concerns about how we drafted the consensus call so I 
> would like to try and give it another try.  Sorry for the long message 
> which I hope will clarify what are the proposed options. We would like 
> to get feedback by October 18th.
>
>
> The Port Mapping Between Unicast and Multicast RTP Sessions described 
> in 
> http://tools.ietf.org/html/draft-ietf-avt-ports-for-ucast-mcast-rtp-02
>  was discussed for a couple of IETF meeting and on the list. The 
> initial approach that was agreed after we had a breakout session in 
> previous IETF meetings was to use a cookie based solution even though 
> it required more messages and you needed a cookie for every RTP 
> session.
>
> Before the last IETF meeting there were two proposals to update the 
> solution to a token based approach.
>
> In the token approach:
> - Tokens are port-independent (cookies are port-dependent) and only 
> depend on the client's IP. That is, once a client gets its token, it 
> can use it with any of its ports and with any Feedback Target.
> - Tokens address the concern raised by Magnus 
> (http://www.ietf.org/mail-archive/web/avt/current/msg12617.html
> )
> - No need for keep-alives
>
> We had a discussion in Maastricht and the outcome is in the meeting 
> minutes http://www.ietf.org/proceedings/78/minutes/avt.txt (see the 
> section on draft-begen-avt-token-for-portmapping). The token draft has 
> Dan Wing (who is also BEHAVE co-chair) as a co-author and he looked at 
> the solution verifying that it will work well with NATs
>
>
> At the meeting the preference was for a token based solution but there 
> are were two approaches discussed.
>
> 1. Use the token only solution
>
> 2. Use a combination when if the request has only an IP address the 
> response will be a token and if it will have both IP address and port 
> the response will be a  cookie.
>
> According to the minutes the support was for the second approach.  
> The major reason was a concern that carrier grade NATs can allocate 
> more than one IP address as the public address.
>
> The authors of
> http://tools.ietf.org/html/draft-begen-avt-token-for-portmapping-01
> suggest that they addressed the concerns about the token only solution 
> (see section 9 of the draft) and prefer to have a token only solution. 
> This is a change from the meeting minutes and this is the reason for 
> the second question in this consensus call.
>
> So here are two questions for the group !!!
>
> 1. Do the people in the mailing list support the proposal to use a 
> token based solution instead on the cookie one. (this was the 
> preference in the consensus call in Maastricht) and we would like to 
> confirm it on the list.
>
> 2. We have two options for the token approach, please give your 
> preferences.
>
> 2.1 Token only solution as proposed in
> http://tools.ietf.org/html/draft-begen-avt-token-for-portmapping-01
> 2.2 Token + cookie, in this case if the request will include only IP 
> address the response is a token, if it also includes a port it will be 
> a cookie. This approach is for cases were the NAT may use more than 
> one IP address for mapping a local address.
>
>
> Please respond even if you did it on the previous consensus call.


The approach in draft-begen-avt-token-for-portmapping-01 looks to be sufficient to allow a server to determine that multiple requests come from the same client, provided the client isn't multi-homed and isn't sharing an IP address with other clients. The problem statement is not clear enough for me to be sure if that's sufficient.

If it were important to do so, the server could distinguish multiple clients sharing the same IP address if each client supplied a random nonce that was taken into account when generating the token in addition to the client's IP address. This may be an issue with use of fractional IP addresses in future, and so might be something to consider adding.


TOM: I think this is a good idea. The SSRC of the client associated with the SSM RTP session that is present in the portmapping request message could be used for that purpose (hence token is determined by server on the basis of IP address, time stamp  and client SSRC)

Distinguishing multi-homed clients, or clients where requests come from several different IP addresses, is more complex. Is this an issue, or is it sufficient to assume that a client requests a new token when changing the address it uses?

TOM: IMO that will do..I think it is bad practice if a network stack on a host device/ NAT device allocates different IP addresses towards a application/end-host 

I'd also like to note that the port mapping operation is independent of the RAMS drafts. It would be good if the draft the group ends up with is written as a standalone mechanism, with RAMS described as one example use case, rather than being written in a RAMS-specific manner as are the current drafts.

TOM: The text is meant to be (only) applicable to scenarios building on SSM sessions with unicast feedback, no? We wanted a fast -inband- way for a client to communicate the client receive port for a unicast connection that is linked to such a SSM. In that case, the text is sufficiently generic (e.g. RAMS is not even mentioned in the text, whereas the example is about retransmissions). I take it that any other parameter signaling (port, any attributes,..) for any other scenario needs to leverage the SDP offer-answer model.  

Cheers,
Colin


-- 
Colin Perkins
http://csperkins.org/



_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www.ietf.org/mailman/listinfo/avt