Matt Mathis <[email protected]> wrote: > > 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.
+1 > 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). ... good to introduce terms for this distinction... > 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. +1 > 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%). 3% is pretty high... :^( > 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. (having wreaked havoc in the meantime...) > 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. +1 > 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. Alas, hardware tunnels frequently do regenerative stuff. :^( > Congestion control helps because it makes throughput maximizing traffic > extremely elastic, which can absorb (offset) other regenerative traffic. "Helps" meaning avoiding congestion-collapse... > It also guarantees that at some scale all traffic will ultimately become > elastic. That sounds overly optimistic. > 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. (having wreaked havoc in the meantime...) > 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? At first blush, any regenerative traffic that doesn't stop repeated transmissions fairly quickly leads to significant damage. > These questions are orthogonal to the presence of congestion control. Yes. We could be in trouble even with "congestion control" on _all_ traffic if the reaction time is too slow. And certainly the presence of congestion control on a subset of the traffic won't remove the issue. -- John Leslie <[email protected]>
