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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Feb 2008 13:16:37 -0500

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
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
mmusic mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mmusic

---

From: Lars Eggert <[email-masked]>
Date: Tue, 26 Feb 2008 15:32:57 +0200

Hi,

On 2008-2-25, at 20:16, ext Jonathan Rosenberg wrote:
> low (...)
...
> of SP NATting to stave off demand, and thus port prediction will  

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.)

> 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

---

From: "Frank W. Miller" <[email-masked]>
Date: Wed, 27 Feb 2008 09:01:47 -0700

Greetings,

I decided to do a quick review of the document.  Here are my
comments/questions.

1) Overall, the document is structured to reference ICE heavily.  I wonder
whether it would be good to bring in selected portions of ICE to this
document to make going about an implementation easier?  My reasoning is that
there may potentially be a lot of applications that are not SIP related and
by reducing references to ICE, you may reduce the pain of someone having to
deal with understanding SIP to get this to work.

For example, the way it's written now, you basically have to go read ICE
before reading this document.  Wouldn't it be great if I could read this
document and implement to it without having to refer to ICE?

2) An protocol ladder diagram for at least the nominal case would be good.
I know its simple but what I'm really looking for is something that includes
the overall picture, i.e. use of STUN, use of NICE, possibly use of TURN all
wrapped up in a single ladder.

3) Some example messages would be great!  An example of Initiate and Accept
messages would be helpful.  My reasoning here is that since you're
substituting MIME for SDP syntax, some more specifics on the use of the
spec'd BNF would be helpful for implementers.

4) Along those lines, while the BNF for the MIME portion is spec'd the rest
of these messages is not.  Do the Initate and Accept messages have some
header portion like a SIP message with a MIME body?  It wasn't clear from
the text how they are supposed to be structured.

5) It would appear that the subsetting you are doing here really boils this
down to hole-punching for a single connection with the ability to use a
relay server if necessary.  Should there be some reference to the previous
hole-punching work?

6) So now the obvious question, which I'm sure you're anticipating and which
is likely more philosophical.  Why could this protocol not be used with SIP
implementations as well?  I know we have ICE itself but...  I suppose if you
used this for each "connection" in a SIP session the result would be even
chattier than ICE is now but this is certainly somewhat easier to implement
given all the subsetting.  While I have a feeling I know what you think
about this, I'd still be interested in hearing your rationale.

Thanks,
FM

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic