Aaron Swartz has created a website for critiquing and commenting on Free Culture, the latest Lessig sermon against capitalism. It could be a fun exercise.
Link via Jarvis.
Month: March 2004
Fixing the Internet
Dean mentions a new, experimental protocol that eases some of TCP’s performance bottlenecks:
Binary Increase Congestion Control for Fast, Long-Distance Networks
Authors: Lisong Xu, Khaled Harfoush and Injong Rhee, North Carolina State University
Presented: March 11, 2004, at Infocom 2004Abstract: High-speed networks with large delays present a unique environment where TCP may have a problem utilizing the full bandwidth. Several congestion control proposals have been suggested to remedy this problem. The protocols consider mainly two properties: TCP friendliness and bandwidth scalability. That is, a protocol should not take away too much bandwidth from TCP while utilizing the full bandwidth of high-speed networks. This paper presents another important constraint, namely RTT (round trip time) unfairness where competing flows with different RTTs may consume vastly unfair bandwidth shares. Existing schemes have a severe RTT unfairness problem because the window increase rate gets larger as the window grows — ironically the very reason that makes them more scalable. RTT unfairness for high-speed networks occurs distinctly with drop tail routers where packet loss can be highly synchronized. After recognizing the RTT unfairness problem of existing protocols, this paper presents a new congestion control protocol that ensures linear RTT fairness under large windows while offering both scalability and TCP-friendliness. The protocol combines two schemes called additive increase and binary search increase. When the congestion window is large, additive increase with a large increment ensures linear RTT fairness as well as good scalability. Under small congestion windows, binary search increase is designed to provide TCP friendliness. The paper presents a performance study of the new protocol.
It sounds like this protocol would be primarily useful for satellite networks (large delays) and for multi-hop paths in wired networks. While TCP’s metrics aren’t tuned to these networks, I don’t think they’re common enough to warrant wholesale replacement of TCP, although the metrics it uses to figure out how much data can be in the pipe without an acknowledgement certainly need some re-examination given the nature of today’s networks.