The story of TCP Reno and TCP Vegas could easily be used as a poster story for the test-driven development camp. TCP Reno implemented an at-the-time new technique for quickly recovering from transient network congestion called fast recovery. However, after people were already convinced to implement and deploy TCP Reno on hosts around the world, researchers discovered a flaw in Reno that resulted in significantly poorer performance than TCP Tahoe, its predecessor, when a consecutive sequence of packets were lost simultaneously.
TCP Vegas, on the other hand, suffered from a related but different problem. The authors of Vegas made claims of serious performance increases to the Internet if their new algorithms were implemented and deployed. Unfortunately, because Vegas was so different in its approach many people had a difficult time believing that these performance enhancements would be observable in a production system. Furthmore, many worried that Vegas would cause currently unforeseen problems with the Internet if deployed and might not play well with existing TCP implementations.
Both of these stories may have had a happer ending if their were a large suite of test cases that any new TCP algorithms or enhancements could be tested against. These test descriptions could be ran on either simulation software, partially-simulated environments, or real hardware. These tests should be broad enough to cover all of the common traffic patterns found on the Internet as well as important edge cases that an algorithm must handle to be sufficiently robust. Furthermore, tests could be used to determine how a new TCP algorithm interacts with existing deployed solutions. Lastly, the test suite would provide a common ground for researchers to communicate with. Not only could a researcher both verify for himself and others the validity of his or her new ideas, but if more questions or concerns arose then the test suite could simply be extended with new tests that explored these concerns.
Having a suite of tests has proved invaluable for many core infrastructure technologies just as compilers. Applying such a philosophy to what is quite possibly the most important infrastructure in the world should lead to increased productivity in researching new ways of improving TCP.
Sunday, October 3, 2010
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment