The ongoing debate about tunnels and congestion control is over the wrong question. The presence of congestion control in the tunnel is neither sufficient nor necessary to protect the network from the tunnel.
Let me define two terms: traffic or applications are "elastic" if increasing loss causes decreasing presented load and "regenerative" if increasing loss causes increased load (from the sender to the loss point). Clearly regenerative traffic is a bad thing because it can cause "latchup
" and congestion collapse like behaviors. You would think that regenerative protocols would be rare, but they are not.
The problem is that it is trivial to construct applications that are regenerative. For example, if you use TCP
to deliver low rate CBR (constant bit rate)
traffic, then the TCP
retransmissions are regenerative until the loss rate is sufficient to cause the system to fail. This sounds like a corner case, but it is not. Suppose you are serving 250 kb
/s flows to forty thousand individual near clients (20 mS RTT
). These flows will do a reasonable job of meeting their target rates at up to several percent loss (I'm guessing 3%). If I vary the load by increasing the number of flows into a fixed 10 Gb
/s shared bottleneck, the total loss rate will suddenly spiral out of control once the aggregate target goodput
exceeds the link capacity. The loss rate will rise until some or all of flows fail to meet the required performance.
I point out that *every* non-throughput maximizing protocol or application using retransmissions to implement reliable delivery has the potential to be regenerative, because the net goodput
is determined by some other part of the system. The presence of CC is not at all sufficient to eliminate pathological behaviors.
As long as the tunnel does not itself do something regenerative (for example by repairing losses to protect its payload) the tunnel does not change the extent to which its traffic is regenerative.
Congestion control helps because it makes throughput maximizing traffic extremely elastic, which can absorb (offset) other regenerative traffic. It also guarantees that at some scale all traffic will ultimately become elastic. However this transition is typically way beyond the point where non-background applications are useful. Furthermore there are other mechanisms that can make traffic elastic, for example by users abandoning applications when they don't work.
We have been asking the wrong question about tunnels and everything else. The real question is "Under what condition is the traffic regenerative?" or alternatively "Is there sufficient elastic traffic to offset the regenerative traffic in the ensemble? Is the regeneration sufficient to cause latchup? These questions are orthogonal to the presence of congestion control.
(There is also a similar set of questions about goodput vs throughput and useless data arriving at the receiver, again related to the strength of the retransmission strategy and not the presence of CC.)
The best way to predict the future is to create it. - Alan Kay
Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are.