Subject: Re: [MMUSIC] TCP SO support on Windows

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 23 Jul 2010 13:12:27 +0300

On Friday 23 July 2010 12:42:26 ext Ari Keränen, you wrote:
> On 07/23/2010 12:08 PM, Rémi Denis-Courmont wrote:
> > On Friday 23 July 2010 10:49:12 ext Ari Keränen, you wrote:
> >> Hi Remi,
> >> 
> >> You had some experience on TCP Simultaneous Open support for Windows,
> >> right? I've read reports (e.g., [1]) that it didn't work in XP prior to
> >> SP2, but in SP2 it was fixed. However, some claim that it doesn't work
> >> with SP2 either.
> >> 
> >> Do you have any experience with the never Windows versions like SP3,
> >> Vista, and 7 you could possible share? I'm working to get the ICE TCP
> >> draft done and how well TCP SO is supported is fairly important for the
> >> current approach.
> > 
> > I don't have any experience with newer Windows version. Sorry.
> 
> OK, no problem. If you still have the code you used for your tests, it
> would be nice to have it. I could then give it a try on my Windows 7
> laptop.
> 
> Also, any comments you may have on the ICE TCP draft are welcome. The
> current plan is to merge it with the framework draft, come up with a new
> version after the meeting, and hopefully get it done sooner rather than
> later.

My opinion is, TCP-SO is useless. The implementation is overly complicated, 
especially with regard to the very low success rate (in absence of TURN 
servers). Indeed, many many NATs and firewalls will never let TCP-SO work. It 
is not just an TCP/IP stack issue.

To make things worse, there is a distinct lack of use cases.
* RTP does not normally run on TCP (except Interleaved in RTSP session).
* MSRP is not used anywhere, and provides its own relay mechanism.

With this two factors, TCP-SO is most likely not be succesfully deployed.

If you need TCP transport semantics through NATs, you should use UDP tunneling 
or pseudo-tunneling instead. There has been a number of proposals already. 
This at least will work as reliably as ICE-UDP and avoid the portability 
problems of TCP-SO.

> By the way, are you coming to the Maastricht IETF? I'll be presenting
> this stuff in the MMUSIC WG meeting.

Unfortunately, I have no budget.

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki

---

From: Ari Keranen <[email-masked]>
Date: Fri, 23 Jul 2010 14:53:10 +0300

> is not just an TCP/IP stack issue.

I assume that you are not referring to just Simultaneous Open (TCP-SO) 
but the ICE-TCP in general? It's true that the success ratio is not 
high, but with the options proposed by the framework draft it can be 
improved to some extent. But yes, direct connectivity probability is 
still gonna be quite a bit lower than with UDP ICE.

But why NATs and firewalls would never let this work? I think the 
recommendations of RFC 5382 make sense and complying to those would make 
TCP SO work and thus substantially increase the direct connectivity 
probability. And while waiting that to happen, relaying still gives us 
close to 100% connectivity.

> * RTP does not normally run on TCP (except Interleaved in RTSP session).

But users behind a (e.g., corporate) NAT or firewall blocking all UDP 
would benefit from running RTP over TCP.

> * MSRP is not used anywhere, and provides its own relay mechanism.

Out of the recent IETF protocols that would really benefit from this 
RELOAD and BFCP come into my mind. In addition there are quite a few 
protocols running on top of TCP that would benefit from NAT traversal.

> This at least will work as reliably as ICE-UDP and avoid the portability 

Tunneling (e.g., Teredo) is one of the options proposed by the framework 
draft and if that is available, it would be used as one of the 
candidates. However, often such options are not available and then it's 
useful to have also other options to try.

> Unfortunately, I have no budget.

OK. We will surely have discussions about this later on the list too.

Cheers,
Ari

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 23 Jul 2010 15:41:27 +0300

On Friday 23 July 2010 14:53:10 ext Ari Keranen, you wrote:
> >>>> right? I've read reports (e.g., [1]) that it didn't work in XP prior
> >>>> to SP2, but in SP2 it was fixed. However, some claim that it doesn't
> >>>> work with SP2 either.
> >>>> 
> >>>> draft done and how well TCP SO is supported is fairly important for
> >>>> the current approach.
> >>> 
> > My opinion is, TCP-SO is useless. The implementation is overly
> > complicated, especially with regard to the very low success rate (in
> > absence of TURN servers). Indeed, many many NATs and firewalls will
> > never let TCP-SO work. It is not just an TCP/IP stack issue.
> 

Yes and no. I do mean TCP-SO, and normal TCP. There were proposals to run ICE-
TCP over Teredo or some hybrid of UDP and TCP that do work pretty much as well 
as ICE-UDP.

> close to 100% connectivity.

There are simply millions of middleboxes that predate the specification, ignore 
the specification, or even deliberately violate it (to block "peer-to-peer" 
traffic, or for some "security" reasons). And then there are millions of hosts 
whose TCP/IP stack don't support SO properly. And even for those that do, some 
rather ugly working around the socket API is required.

> would benefit from running RTP over TCP.

Many of the firewall that block UDP either block TCP (except perhaps on some 
well known ports), or at least block TCP-SO as well.

So basically, TCP-SO is not worth the bother due to low success rate and high 
implementation complexity. There will have to be other (more reliable) 
mechanisms, rendering TCP-SO largelly superfluous

---

From: Ari Keranen <[email-masked]>
Date: Fri, 23 Jul 2010 16:13:09 +0300

> TCP over Teredo or some hybrid of UDP and TCP that do work pretty much as well 

OK.

> rather ugly working around the socket API is required.

Yes, but I think there's a good chance that the situation is improving 
over time. That said, I'm not expecting ICE-TCP ever to get even close 
to UDP's direct connection success ratio and that we need to note in the 
draft.

> well known ports), or at least block TCP-SO as well.

True, but for some it may work and with the framework draft's additions, 
if some middlebox communication method is supported on the other end, 
you may still get direct connection. I think that this is well in line 
with ICE's idea of "testing what ever you get and use the best thing 
that works".

Anyhow, I think RTP over TCP is not the main customer for this draft.

> mechanisms, rendering TCP-SO largelly superfluous

With this point I don't really agree. TCP-SO (assuming that you 
implement the act/pass TCP-ICE anyway) is actually quite easy to 
implement. It does require operating system support, but if the OS 
doesn't support it, simply don't use it. And if it works, it is really 
efficient since you don't need any relaying or encapsulation. If it 
doesn't work, you can fall back to other mechanisms such as tunneling.

Cheers,
Ari