Subject: [MMUSIC] ICE-TCP Issue #1: Will S-O work on various operating systems?

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Feb 2008 12:51:50 -0500

For a background on this issue and related ones around ICE-tcp, I 
encourage folks to read Saikat's paper which analyzes the effectiveness 
of various TCP traversal techniques across around 100 different NAT boxes:

http://saikat.guha.cc/pub/imc05-tcpnat.pdf

The approach described in ICE-tcp is equivalent to the "P2PNAT" solution 
described in that paper, without port prediction. Note that, this 
approach only works about 45% of the time according to Figure 8 in that 
paper (that Figure is the main result of the paper). Adding port 
prediction helps. STUNT#2 works better; that mechanism, however, assumes 
port prediction. Without port prediction, it has a bit better 
effectiveness than P2PNAT (around 50% according to a discussion I had 
with Saikat).

So in reality, we have in front of us a choice about which baseline 
mechanism to use (STUNT#1, #2, P2PNAT, etc.) and whether to add port 
prediction or not, as port prediction is basically an orthogonal feature 
to the tcp connection establishment approach.

One of the concerns around the P2PNAT technique is that it requires the 
host OS to support the TCP S-O handshake. Saikat's paper indicated that 
this was actually problematic in WinXP SP1, but fixed in SP2. In my 
conversation with him recently, he indicated that there has been some 
changes from Microsoft, and this flow no longer works in WinXP SP2. That 
would be a HUGE problem for us given the large installed base of that 
OS. It would mean that ICE-tcp as its defined today couldn't work on XP 
SP2. That would be bad.

We need some recent data here to make a decision on this. Before we 
abandon the P2PNAT flow and try something else (namely the non-TTL 
STUNT#2 approach), I want to get some experimental data on what works. I 
am seeking volunteers to help with this, to run some tests on WinXP SP2, 
SP1, Win2k, Linux, OS-X and whatever else folks have, to see what works.

Volunteers?

-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: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 26 Feb 2008 15:33:16 +0200

> effectiveness than P2PNAT (around 50% according to a discussion I had

It would seem to me that all solutions are bad (compared to ICE-UDP). I am 
keen to believe that TCP will always work better than UDP from NAT to 
non-NAT, and UDP will always work better than TCP from NAT to NAT.

Maybe, we need to look back at the use-cases. As far as I understand there are 
two classes of use-cases for ICE-TCP:
- fallback to ICE-UDP when there is an anti-UDP firewall (e.g. for RTP),
- as a bulk peer-to-peer transport (e.g. for file transfer).

The first scenario is a firewall rather than NAT issue. I don't know if we 
want to venture there. Nevertheless, I expect that, if UDP is black-holed, 
most certainly, so is TCP simultaneous open, i.e. only normal outgoing TCP 
works. If people know of significant counter-examples, I'd like to hear about 
it. Otherwise, specifying TCP-SO for this scenario might be a big waste of 
time, especially considering the big implementation and deployment hurdles.

The second scenario is very different because:
1/ plain UDP cannot be used even if it works,
2/ being a *bulk* transport, relaying (TURN) may be very inadequate.
Under these assumptions, I would suspect that neither 25, 45 nor even 50% 
success rate will "cut it". Lack of support from deployed operating systems 
is a mere aggravating factor at this point. Then, if there is no satisfactory 
TCP-based solution, some UDP encapsulation may be required, though I am not 
very confident whether that will fly in IESG.

-- 
Rémi Denis-Courmont