Tuesday, September 9, 2008

Congestion Avoidance and Control

The authors investigated whether "the 4.3 BSD (Berkeley UNIX) TCP was mis-behaving or if it could be tuned to work better under abysmal network conditions" after noticing a series of congestion collapses in the late 1980s. The conclusion to their hypothesis came in the form of seven new algorithms that were added to 4BSD TCP, including round-trip-time variance estimation, exponential retransmit timer backoff, slow-start, and others.

They rationalize their algorithms rather non-rigorously using the conservation of packets to explain a system operating stably (i.e. in equilibrium). Their new slow-start algorithm is meant to help the system conservatively reach equilibrium while their new round-trip-time estimation is meant to keep the system in equilibrium. For their new exponential backoff mechanism they also leverage linear system theory!

In addition, the authors also discuss the dynamic window sizing for congestion avoidance. For this they discuss how to perceive the feedback bit that Jain and Chiu propose and effectively get the same results.

This paper feels much like the the implementation of TCP for BSD ... slightly thrown together, all augmentations of an existing system meant to deal with common case situations appropriately (at least that is kind of how I always felt about the BSD TCP implementation). The paper is an interesting and enjoyable read, however, because it captures how novel and exciting networking was at this time and how rich the area seemed for possible optimizations. And yet, since the late 1980s has there been any new TCP implementations that have been adopted? The robustness argument for Jacobson and Karels seems to be, 'its good enough', which, for the most part, it is. Of course, there are a collection of people redesigning the Internet as we speak, but while operating systems have seen radical changes or additions over the years, the BSD networking stack feels like it has remained fairly consistent. (Moreover, almost every UNIX variation includes the BSD networking stack, including Mac OS X.) So, did this work have any important implications ... as I write this blog I'm leveraging exactly this work now!

1 comment:

Randy H. Katz said...

Ben--I don't disagree fundamentally with your assessment of the paper. It doesn't follow the normal procession from problem identified, solution proposed, solution evaluated, and from a computer science viewpoint, there isn't a clear separation between flow control, congestion control, and error recovery in the way the algorithm is developed. However, the concept of packet conservation is an important one. There are follow-on papers that have attempted to evaluate TCP from a control theoretic perspective, but I have spared you these! There are also rate-based alternatives, like TCP Vegas, but the bottom line is that TCP Reno works and networking people are loath to change it.