TCP congestion mechanism reacts very quickly to packet loss, while there is a class of slow congestion control mechanisms that react much slower to packet loss, thereby making sending rate much smoother than that of TCP. A smooth sending rate is better suited for unicast streaming video and audio. These slow-reaction congestion control schemes have been tested for fairness and TCP-friendliness in static environments, but not in dynamic environments like the Internet itself. This paper tests several slow congestion control mechanisms for their behavior under dynamic environment by varying the congestion bottleneck's bandwidth. Four aspects of this environment are studied by this paper:
The testing methodogy uses an ON/OFF CBR source to simulate the different levels of network traffic, thereby creating a dynamic environment. For example, when the CBR source is on, the bandwidth is reduced, while when it's off, the bandwidth returns to normal. This repeating pattern creates a "square-wave" pattern of dynamic bandwidth. Other scenarios used include a "sawtooth" pattern, where the CBR source is turned on gradually, but off suddenly, or vice versa.
The main problem the paper studied is how SlowCC mechanism react to abrupt reduction in bandwidth. The stabilization time is measured. Stabilization time is the number of RTTs before the loss rate returns to 1.5 times the normal rate. The paper argues that self-clocking helps to reduce the stabilization time in TFRC and makes SlowCC mechanisms usable.
Four more scenarios are studied in this paper:
The authors argue that the aboves tests show that SlowCC mechanisms should be safe for deployment in dynamic environments.
I, on the other hand, do not draw the same conclusions from these tests. It seems to me that SlowCC mechanisms have worse performace when compared to TCP in just about every test. Even in the tests on rate smoothness, SlowCC mechanisms do not always perform well. Also, it makes me wonder why the authors focus so much on one type of SlowCC mechanism - TFRC, and much less on all the others. It seems to me that the authors are trying to promote and sell TFRC for some reason. In order to have a more complete view of SlowCC mechanisms, other SlowCC mechanisms should be studied more extensively. Another problem is that the authors argue that since SlowCC algorithms can be safely deployed because they don't compete unfairly with TCP. That is true, but are they aggressive enough to compete, or will TCP simply grab all the bandwidth? So deploying SlowCC mechanisms may still be a problem. One last criticism is that simplicity of the tests. Only one bottleneck is used, as opposed to multiple ones on the real Internet. Competing CBR or other background TCP flows are used to create traffic. This approach does not take into account the behavior of this background traffic that can possibly affect the results. I still don't quite see how the background traffic can be maintained at a steady level, especially because these traffic flows can vary their sending rates as well. Overall, this paper has given us some a good idea of how SlowCC mechanisms behave under dynamic Internet environment. However, I don't think we can say that SlowCC mechanisms are safe for deployment simply based on this paper. I give this paper a rating of 3 - moderate contribution.