4

This article explains why TCP-over-TCP could be a performance disaster.

My understanding about the issue is that the 'outer' TCP connection deals with packet loss and congestion of the network and acts accordingly by increasing timeouts (and thus reducing throughputs). However, the 'inner' TCP connection does not see these network conditions because they are 'fixed' by the outer TCP. And therefore, the 'inner' TCP keeps sending packets at previous speed and thus explodes the internal sending buffer of the 'outer' TCP connection.

My questions are:

  1. Is my understanding correct?
  2. It seems that the TCP-over-TCP meltdown is only internal (i.e., it only affects local buffers) but does it also affect the network as well? Does it cause more congestions in the network and does it degrade other connections on the same network?
  3. How does TCP-based VPNs solve this problem? OpenVPN has an article on this but it does not say why it is not a problem in practice (or is it?)

Many thanks for any answer!

diwenx
  • 41
  • 1
  • 2
  • 5
    The OpenVPN article you linked to says: "We therefore instead recommend that you use UDP" – Michael Hampton Dec 11 '20 at 14:19
  • Yes, but for some non technique reason I can't use UDP and OpenVPN over TCP works well for me. The question here is that why TCP-over-TCP doesn't have a noticeable effect on TCP based VPN? – diwenx Dec 11 '20 at 14:25
  • 4
    It does. You just have been very fortunate to not have noticed it yet. – Michael Hampton Dec 11 '20 at 14:28
  • [This](https://networkengineering.stackexchange.com/questions/76925/can-udp-traffic-be-transmitted-over-tcp-ports-on-openvpn-to-avoid-the-tcp-meltdo) discussion on Network Engineering might help. – Zac67 Dec 14 '21 at 20:33

2 Answers2

3

In my understanding, the "tcp meltdown" problem is not difficult to solve: you only need to set a large retransmission timeout for the inner tcp connection.

By greatly increasing the minimum retransmission timeout of the inner TCP connection, we have effectively disabled the timeout retransmission mechanism of the inner TCP. Therefore, the TCP meltdown problem is avoided.

For example, in linux, you can use ip route replace 192.168.168.1/24 via 192.168.168.2 rto_min 12s to increase the minimum retransmission timeout of all internal connections established through OpenVPN from 0.2 seconds to 12 seconds (It is assumed that 192.168.168.1/24 is your OpenVPN network segment).

You can set the above command as OpenVPN's up event callback. In this way, we have actually avoided the tcp meltdown problem in a simple way.

We use this method to optimize the tcp-over-tcp link. Even on the line with high latency (hundreds of milliseconds) and high packet loss, we have not found any adverse effects.

PS: On a line with high latency, high packet loss, and high bandwidth, it is obvious that you need to prepare a large window for the inner tcp connections to take up the full bandwidth.

UPDATE:

The question here is that why TCP-over-TCP doesn't have a noticeable effect on TCP based VPN?

Because on a high-quality line that rarely loses packets, the TCP meltdown phenomenon is not prominent.

ASBai
  • 141
  • 4
  • So, in other words. The inner TCP connection (of the application) does not need a retransmission because retransmission are already handled by the outer TCP connection (of the VPN tunnel). Thus, one can disable the retransmission of the inner TCP connection to avoid the TCP meltdown problem. – Martin Zabel May 19 '22 at 08:28
0

I would argue that this has more to do with the way that TCP works, and not with OpenVPN per se. Here comes a long rant and my few cents:

Is my understanding correct?

Roughly yes, but the inner TCP connection isn't "protected". If the outer drops a packet and the throughput gets lower or latency higher, the inner connection would also be limited by this, notice that it can't use full performance and start to back off.

It seems that the TCP-over-TCP meltdown is only internal (i.e., it only affects local buffers) but does it also affect the network as well?

You will only have one TCP connection to the server, so this will only affect that particular connection and whatever is in it. What the meltdown refers to is what I describe in the previous answer.

Does it cause more congestions in the network and does it degrade other connections on the same network?

No, but I would need to have "network" being defined here. If you have a bad connection to the Internet, then yes, all would suffers from packet drops or other transmission problems. If you mean there is only a problem with your client<=>server connection, then your non-VPN connections wouldn't be affected.

How does TCP-based VPNs solve this problem?

By using a single connection to the server, send the traffic inside that connection and hope for the best.

OpenVPN has an article on this but it does not say why it is not a problem in practice, is it a problem in practice.

Yes. TCP has much higher overhead in terms of packet size than UDP, so you are always paying a size penalty by having two TCP headers (inner plus outer) in your connection. Resends and TCP rampup will also impact your performance. If you have a good connection, i.e. no drops, low latency and high bandwidth, then you won't see much of the rampup/backoff/resends, and hence not notice this. If you have a bad connection, then the first answer comes in to play, the outer connections could ramp down, this will impact the inside traffic which will ramp down, packets can become out of order and being resent and so on, which will definitely impact the tunnel performance.

Long answer is long. I hope this made some sense to someone more than me.

Fredrik
  • 540
  • 2
  • 13