Many admins keep perpetuating - on ServerFault and elsewhere - how bad of an idea TCP-over-TCP is, e.g. in VPNs. That even the slightest packet loss will make one suffer from at least severe throughput degradation if not TCP meltdown, and that TCP-over-TCP is therefore strictly to be avoided. And that probably was once all true, e.g. 2001 when this article was written that is still referred to.
But since then we've seen major advances in technology and protocols. Nowadays we have 'Selective ACK' implemented almost everywhere, and Moore's law has given us so much more memory, and with it came large TCP buffers optimized for Gbit uplinks. Also packet loss is much less of an issue these days on non-radio links. All this should alleviate the TCP-over-TCP problem significantly, shouldn't it?
Note that there are real-world scenarios where e.g. TCP-based VPNs are easier to implement and operate than UDP/ESP-based ones (see more below). Therefore my question:
Under what circumstances (link packet loss & latency) is TCP-over-TCP performing significantly worse that TCP alone, assuming SACK support and decently sized TCP buffers on both ends?
It would be great so see some measurements that show the correlations between (outer connection) packet loss/latency, and (inner connection) throughput/jitter - for TCP-over-TCP, and for TCP alone. I found this interesting article, but it seems to be concerned about latency only, and to not address (outer) packet loss.
Also: Are there recommended settings (e.g. TCP options, buffer settings, reducing MTU/MSS, etc) to narrow the performance gap between TCP and TCP-over-TCP?
Update: Our rationale.
This question is still very relevant in some real-world scenarios. E.g. we deploy embedded devices in large buildings that collect sensor data and feed it into our platform via VPN. The problem we are facing is firewalls and improperly configured uplinks that our not under our control, combined with reluctant IT departments. See a detailed example discussed here.
In a lot of such cases, switching from non-TCP to a TCP-based VPN (very easy if you use OpenVPN like us) is a quick fix that allows us to evade uphill finger-pointing battles. E.g. often TCP port 443 is generally allowed (at least via proxy), or we can overcome Path-MTU issues by simply reducing TCP's MSS option.
It would be good to know under what circumstances a TCP-based VPN can be considered a viable alternative, so we can make an informed decision outweighing the pros and cons of either option. For example we know that TCP-VPN is ok for us on non-radio links, but we do have a fair share of remote clients on 3G uplinks with significant packet loss and high latency - how would a TCP-VPN perform there?
I tried to improve the title and the central question accordingly; i hope it makes sense.