Concerns about End-to-End Congestion Control

This web page has moved. The updated version is now maintained at "http://www.aciri.org/floyd/tcp_unfriendly.html".

Concerns about End-to-End Congestion Control

The need for end-to-end congestion control:

Floyd, S., and Fall, K., Promoting the Use of End-to-End Congestion Control in the Internet. Under submission, February 1998.
B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang, Recommendations on Queue Management and Congestion Avoidance in the Internet, April 1998. Available as RFC 2309 ( text) as an Informational RFC.
Alarm Sounded Over Bandwidth `Greed', James Glave, Wired News, April 9, 1998. "The next time you see the phrase "highly optimized" used to sell an Internet application, give a second thought to what it might be costing the Net."

Less conservative congestion control:

This section contains pointers to protocols that might be more aggressive, in terms of end-to-end congestion control, than the TCP congestion control mechanisms specified in RFC 2001 on TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. Some of these protocols might be intended not for best-effort traffic in the Internet, but only with accompanying mechanisms that provide additional bandwidth guarantees (e.g., diffserv, intserv).

Unicast:

Flash Networks BoosterWare: "For the Internet community at large, NetBooster exploits the capacity of the modem to maintain a constant data flow at its maximum rated speed, regardless of the network traffic load." ( Flash Networks Press Release)
From their White Paper on The BoosterWare Advantage: Enhancing TCP/IP: "BoosterWare, by contrast, abandons the effort to optimize the window size (a key source of bottlenecks) during transmissions; instead, window sizes are fixed according to pre-defined parameters negotiated between the client and the server once a connection has been established. BoosterWare can be viewed as a reliable, "no overhead" UDP (user datagram protocol)..."
RUN Inc. ("RUN Inc. has found a way to squeeze more bandwidth out of existing TCP/IP networks without changing the network protocols or the applications that run over them.... In field tests over the Internet, runTCP has accelerated data transfers by as much four times." - PC Week Online, Sept. 4, 1997.)
Sitara Networks Inc. ("Everyone talks about the "World Wide Wait", but no one does anything about it."). As discussed in IP Acceleration Software: Torquing Up TCP/IP, DataCommunications, January 1998: "Speedseeker can selectively suspend the TCP/IP congestion control mechanism when sending audio and video." See About Sitara in the News.
RealAudio. "RealAudio 3.0 encoding algorithms have four different fixed data rates which can be used depending on the bandwidth requirements." (Audio Bandwidth)

Multicast: (We note that in the current Mbone, the aggregate multicast traffic can be limited by a token bucket rate-limiter.)

the Mbone tools
Reliable Multicast?

Return to [ Sally Floyd].

Maintained by floyd@ee.lbl.gov
Last modified: September 1998