Dynamic Behavior of Slowly-Responsive Congestion Control Algorithms

This paper attempts to demonstrate through simulations that various slowly-responsive TCP-equivalent protocols (protocols that send at the same rate as TCP given the same steady packet-loss rate, but do not modulate their rate as quickly when the packet-loss rate changes) are safe to deploy alongside TCP. The particular protocols tested are SQRT, TFRC, and TCP with a different window divisor (with special emphasis on TFRC, which was designed by one of the paper's authors).

Under a variety of metrics, including overall stabilisation cost (the number of packets dropped until the steady state has been reached), fairness with TCP, and effective bandwidth utilisation, the authors demonstrate that the alternatives proposed should be safe to deploy. In fact, they generally give more bandwidth to TCP than TCP itself would. Furthermore, the authors demonstrate that even when the TFRC loss event memory is made far larger than the proposed value (6), it can be made safe by the application of simulated self-clocking (restricting sending rate to the ACK rate).

Class discussion

Although the simulations in this paper are a step closer to modeling real internet conditions, several open questions remain:

• Does the new self-clocking feature affect smoothness? If so, is TFRC still useful?
• Most tests were performed against a small fixed number of TFRC streams. How are the results affected when there are a large number of competing streams?
• The smoothness measures were over the granularity of about 200 milliseconds. Is smoothness at that degree even particularly useful? Live video-conferencing probably can't afford more jitter than that end-to-end.
• If these applications aren't suited to live streams with very tight bounds on latency and jitter, what are they useful for? Outside of this realm, a small amount of buffering may be able to accomplish the same thing without the added stabilisation costs, reduced link utilisation, or other unknown risks.