Re: [MMUSIC] ICE TCP Open Issue#2: Port Prediction and a Radical Proposal

[Lars Eggert <lars.eggert at nokia.com>]

Hi,

On 2008-2-25, at 20:16, ext Jonathan Rosenberg wrote:
> However, I am hesitant to rush in and add a description about this to
> the draft. The reason is that I believe port prediction is something
> that will work less and less over time, not more and more. The  
> reason is
> that it only really works when the traffic volume through the NAT is
> low (...)
...
> But more problematic are service provider NATs. Port prediction really
> falls apart there. Saikat's study covers primarily residential NAT, so
> we don't even know what the port allocation behavior is. Even if it  
> were
>  the same as residential, the odds are much higher that there'll be
> intervening traffic that messes up the prediction. As we come closer  
> to
> running out of IP addresses, I believe we'll just see increasing  
> amounts
> of SP NATting to stave off demand, and thus port prediction will  
> become
> increasingly inaccurate.

also, port randomization has become the default on all major end  
system stacks, and it is probably only a matter of time until NATs  
follow suit. (TSVWG is working on a BCP on draft-ietf-tsvwg-port- 
randomization.)

> So, what can be done? Is there no hope? I believe there is, and it
> involves a somewhat radical proposal.
>
> My radical proposal is to define a mode of operation for ICE-tcp which
> involves tunneling TCP over UDP. We'd use ICE's UDP mechanisms to get
> the p2p UDP connection, and then run TCP ontop of it, handshake and  
> all,
> as the 'application' protocol.

Independent of what I think about this on a technical level, MMUSIC is  
not the appropriate WG for this. This is so far in transport-land that  
it would really need to occur in the transport area.

Lars
_______________________________________________
mmusic mailing list
mmusic at ietf.org
http://www.ietf.org/mailman/listinfo/mmusic