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

[Jonathan Rosenberg <jdrosen at cisco.com>]

Long note, but some very controversial stuff below, and really important 
for ICE-tcp.

As I mentioned in my previous mail, Saikat's results show that e2e TCP 
connection establishment works much better in cases where port 
prediction is used. The idea behind port prediction is to guess that 
NAT's behavior around mapping properties, and in particular, to guess 
whether the next connection attempt by the host will produce the same 
external mapped address and port, that address and port+1, or something 
else. Saikat's results show many NAT are port+1. Then, when the remote 
endpoint initiates the tcp connection, it does it to the predicted port 
(exchanged through SDP in our case) rather than the actual mapped port 
from talking to the stun server.

There is much to say on port prediction.

Firstly, I believe that it is something that can be done with ICE-tcp as 
defined today, as a matter of local implementation. An agent would 
include candidates for its predicted port in addition to its learned 
mapped address. The regular ICE series of checks would cause the agents 
to try both, and one should work. I'd want to see that tested to be 
certain but I believe it is correct.

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, such that there are no connections from other hosts behind the same 
NAT, between the time the mapped address is learned and the connections 
are established for connectivity checks. This assumption is getting 
worse and worse as people put multiple computers and other IP-enabled 
peripherals in their homes behind a single residential NAT. The days of 
a single computer behind a home NAT are going away. I have something 
like half a dozen devices at home behind my NAT, all of which initiate 
connections through it.

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.

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. From an implementation perspective, this 
would involve porting a tcp stack to user space. However, since it is 
TCP in every sense of the protocol, we still get its main features - 
congestion control, fragmentation, and even path MTU discovery. However, 
we get it in concert with the much better p2p UDP connection 
establishment probabilities. I'll note that, another benefit of this, is 
if ICE-udp ends up connecting through TURN, TCP runs ontop of that, 
transparently THROUGH the TURN server, producing e2e congestion control 
even through TURN. Nice!

That would work really well in concert to ICE-tcp; ICE-tcp would try the 
real tcp candidates first, and then revert to UDP, and if that works, 
then run the tcp handshakes over the UDP shim. This way, we have a nice 
migration path away from this shim as NATs become behave-tcp compliant.

And so my specific proposal is to do the following:

1. do not add port prediction to ICE-tcp. Rather, define a separate 
document, perhaps even experimental, that defines how an implementation 
can choose to do this with ICE-tcp. Make sure that this interoperates 
with endpoints that have not done port prediction, and introduce any 
changes in ice-tcp that might be required for that

2. produce a spec for shimming tcp over udp, and describe how to use 
this as another candidate in conjunction with ice-tcp

Flame on.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen at cisco.com
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
mmusic mailing list
mmusic at ietf.org
http://www.ietf.org/mailman/listinfo/mmusic