Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why TCP Over TCP Is a Bad Idea (2001)

sites.inka.de

Post reply on HN
Print view View original

11–20 of 45 posts

Re: Why TCP Over TCP Is a Bad Idea (2001)

#11

Post by beagle3 »

minimax wrote: post #3

TCP over TCP is a great idea for end user VPNs because 1) networks are generally pretty reliable and 2) NAT is everywhere . I regularly use an SSL VPN over crappy coffee shop wifi and tethered 3G connections. For the most part it works fine.

> For the most part it works fine.

Only for apps that don't try to utilize maximum throughput. Skype, YouTube, most web browsing, most mail use.

But those that do - like large file transfers over ftp/sftp or a very large email, for example - will cause the meltdown described in this article.

There are some TCP stacks that use RTT rather than packet loss as their congestion metric; Those fair well under a TCP-over-TCP regime (but have other problems)

Re: Why TCP Over TCP Is a Bad Idea (2001)

#12

Post by agwa »

chetanahuja wrote: post #8
agwa wrote: post #4

Earlier quoted context omitted.

NAT is an argument against TCP, not for it, because when your NAT'ed IP address changes, TCP connections break. UDP will drift between NATs without skipping a beat. And I'm very surprised you find crappy coffee shop WIFI and 3G to be pretty reliable - those are exactly the kinds of networks which have occasional sustained periods of high packet loss which wreck havoc with TCP. Edit: the only downside of UDP VPNs is t…

Completely agree with your righteous rage about TCP over bad connections. I allowed myself a bitter chuckle to the GP's "networks are generally pretty reliable" thing. Minor disagreement though: "Edit: the only downside of UDP VPNs is that stateful firewalls can have extremely short timeouts of UDP "connections" (e.g. 30 seconds!)" Plenty of mobile networks will timeout inactive TCP connections in less than 30 second…

> Plenty of mobile networks will timeout inactive TCP connections in less than 30 seconds.

Good grief - that is awful, but sadly believable. Do you happen to know who does that? A couple years ago I tested AT&T's 3G and found that the TCP timeout was 30 minutes, versus 30 seconds for UDP. I'd love to know numbers for other carriers.

Edit: Found an interesting paper from 2011 that tested 73 cellular carriers worldwide and found only 4 with TCP timeouts less than 5 minutes. The majority had timeouts greater than 30 minutes, and 21 had a timeout in the 5-30 minute range. Some of my faith in humanity has been restored. http://www.cs.ucr.edu/~zhiyunq/pub/sigcomm11_netpiculet.pdf (see page 8, table 5)

Edit: A paper from 2012 which measured Verizon and Sprint at 30 minutes, and AT&T at 3 minutes (my tests are more recent, so perhaps AT&T wised up?) http://www.cs.umass.edu/~yungchih/publication/12_mtcp_4g_tec... (see page 11, table VI)

Re: Why TCP Over TCP Is a Bad Idea (2001)

#13

Post by agwa »

chetanahuja wrote: post #9
cbhl wrote: post #6

Earlier quoted context omitted.

In my experience, many NATs just drop UDP packets altogether, but still allow TCP through. Similarly, I find the Internet at my local Starbucks to be some of the fastest, most-reliable networks around; even faster than some local ISPs hooking up to my home.

Note that any NAT that drops UDP packets altogether will basically disable DNS and VOIP type applications or at least degrade the experience in serious ways. I haven't come across many such NATs recently.

Me neither. I have come across networks that filter everything but a few TCP ports (like 80 and 443), but that's a matter of draconian firewall policy rather than a NAT limitation.

Re: Why TCP Over TCP Is a Bad Idea (2001)

#14

Post by minimax »

agwa wrote: post #13
chetanahuja wrote: post #9

Earlier quoted context omitted.

Note that any NAT that drops UDP packets altogether will basically disable DNS and VOIP type applications or at least degrade the experience in serious ways. I haven't come across many such NATs recently.

Me neither. I have come across networks that filter everything but a few TCP ports (like 80 and 443), but that's a matter of draconian firewall policy rather than a NAT limitation.

I have come across networks that filter everything but a few TCP ports (like 80 and 443)

Another point scored for TCP in TCP with an SSL VPN. :-)

Re: Why TCP Over TCP Is a Bad Idea (2001)

#15

Post by agwa »

minimax wrote: post #14
agwa wrote: post #13

Earlier quoted context omitted.

Me neither. I have come across networks that filter everything but a few TCP ports (like 80 and 443), but that's a matter of draconian firewall policy rather than a NAT limitation.

I have come across networks that filter everything but a few TCP ports (like 80 and 443) Another point scored for TCP in TCP with an SSL VPN. :-)

Only if your TCP VPN is listening on one of the allowed ports ;-)

(I do keep a TCP VPN running on port 443 ready to go for these situations, but UDP is always my first choice.)

Re: Why TCP Over TCP Is a Bad Idea (2001)

#16

Post by mordechai9000 »

agwa wrote: post #7
minimax wrote: post #5

Earlier quoted context omitted.

I'm just saying in a previous life I used to spend a ton of time fighting with IPSec NAT traversal issues. With TCP encapsulation (e.g. SSL VPN), you don't have that problem. Most NAT firewalls do a good job dealing with TCP. Other protocols are more questionable. When I'm using wifi at a coffee shop and start getting a bunch of packet loss, I will switch to a tethered 3G connection. When my SSL VPN reconnects, the V…

IPSec is indeed hell with NATs, and an SSL VPN would be much better. But UDP is even better - most NATs do a good job with UDP too, and if done right, it's possible to switch Internet connections without the VPN having to reconnect.

DTLS is a standard protocol for TLS over UDP. It is used by existing commercial products, such as Cisco Anyconnect.

Re: Why TCP Over TCP Is a Bad Idea (2001)

#17

Post by eps »

agwa wrote: post #7
minimax wrote: post #5

Earlier quoted context omitted.

I'm just saying in a previous life I used to spend a ton of time fighting with IPSec NAT traversal issues. With TCP encapsulation (e.g. SSL VPN), you don't have that problem. Most NAT firewalls do a good job dealing with TCP. Other protocols are more questionable. When I'm using wifi at a coffee shop and start getting a bunch of packet loss, I will switch to a tethered 3G connection. When my SSL VPN reconnects, the V…

IPSec is indeed hell with NATs, and an SSL VPN would be much better. But UDP is even better - most NATs do a good job with UDP too, and if done right, it's possible to switch Internet connections without the VPN having to reconnect.

The hell are you fellas smoking? IPsec NAT traversal has been a non-issue since it was standardized about 10 years ago.

Re: Why TCP Over TCP Is a Bad Idea (2001)

#18

Post by beefsack »

agwa wrote: post #4
minimax wrote: post #3

TCP over TCP is a great idea for end user VPNs because 1) networks are generally pretty reliable and 2) NAT is everywhere . I regularly use an SSL VPN over crappy coffee shop wifi and tethered 3G connections. For the most part it works fine.

NAT is an argument against TCP, not for it, because when your NAT'ed IP address changes, TCP connections break. UDP will drift between NATs without skipping a beat. And I'm very surprised you find crappy coffee shop WIFI and 3G to be pretty reliable - those are exactly the kinds of networks which have occasional sustained periods of high packet loss which wreck havoc with TCP. Edit: the only downside of UDP VPNs is t…

TCP over TCP for VPN is pretty useful in places where deep packet inspection blocks UDP by default, eg. GFW in China.

Re: Why TCP Over TCP Is a Bad Idea (2001)

#19

Post by jerf »

minimax wrote: post #3

TCP over TCP is a great idea for end user VPNs because 1) networks are generally pretty reliable and 2) NAT is everywhere . I regularly use an SSL VPN over crappy coffee shop wifi and tethered 3G connections. For the most part it works fine.

Did you read the linked article? (Or did anybody else who is replying?)

It's not about how TCP-over-TCP is somehow aesthetically displeasing or about how people should feel bad about doing it. It's about how TCP-over-TCP is a technically bad idea because stacked TCPs interact poorly. It's never a good idea. TCP-over-TCP is still a profoundly flawed protocol even if you don't happen to tickle its problematic cases.

Re: Why TCP Over TCP Is a Bad Idea (2001)

#20

Post by nickodell »

jerf wrote: post #19
minimax wrote: post #3

TCP over TCP is a great idea for end user VPNs because 1) networks are generally pretty reliable and 2) NAT is everywhere . I regularly use an SSL VPN over crappy coffee shop wifi and tethered 3G connections. For the most part it works fine.

Did you read the linked article? (Or did anybody else who is replying?) It's not about how TCP-over-TCP is somehow aesthetically displeasing or about how people should feel bad about doing it. It's about how TCP-over-TCP is a technically bad idea because stacked TCPs interact poorly. It's never a good idea. TCP-over-TCP is still a profoundly flawed protocol even if you don't happen to tickle its problematic cases.

Ok, so how can we fix this?

Perhaps we could disable retransmission on either the upper or lower layer?

Post reply on HN