Why TCP Over TCP Is a Bad Idea (2001)

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

UDP (and datagrams in general) are not the only alternative to TCP-over-TCP. My sshuttle VPN uses TCP but avoids the TCP-over-TCP problem. <a href="https://github.com/apenwarr/sshuttle" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;apenwarr&#x2F;sshuttle</a>

&gt; Because the timeout is still less than the lower layer timeout, the upper layer will queue up more retransmissions faster than the lower layer can process them. This makes the upper layer connection stall very quickly and every retransmission just adds to the problem - an internal meltdown effect.<p>Intuitively, this is obvious at an organizational level. If your boss is constantly micro-managing each piece of work (segment), and <i>his</i> (or her) boss is doing the same, you are going to have a meltdown.

TCP does what it&#x27;s designed for: Reliable, ordered, stream connection with fixed end-points. UDP is the other extreme of this permutation. Wonder why no one explores the spectrum in between?

Perhaps I&#x27;m missing something obvious, but isn&#x27;t this trivial to solve by just having a deduping filter at the lower level? When the higher level starts keeps sending duplicate packets, just ignore them. Duplicate packets at this layer will always be useless, because your lower layer is already implementing reliability semantics. Then, when you get ACKs from the other side, translate those packets to match the sequence numbers that the higher level is expecting (i.e. the most recent sequence number that was sent out corresponding to a packet with those contents).