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. IEEE/ACM Transactions on Networking, August 1999.
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."
Multimedia Transmissions Drive Net Toward Gridlock, Sara Robinson, New York Times, August 23, 1999. "Like a nation's highway system, the Internet has traffic rules that prevent chaos and gridlock. But an increasingly popular type of multimedia traffic is turning out to be a cyber road hog that flouts the rules and creates traffic jams."

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.
Real:
- RealAudio. "RealAudio 3.0 encoding algorithms have four different fixed data rates which can be used depending on the bandwidth requirements." (Audio Bandwidth)
- RealPlayer, Windows MediaPlayer, and Quicktime: S. Hessler and M. Welzl, An Empirical Study of the Congestion Response of RealPlayer, Windows MediaPlayer and Quicktime, 2005.
  "We measured the responsiveness of the three popular streaming media applications RealPlayer, Windows MediaPlayer and Quicktime with a varying amount of cross traffic and present a comparison of the results.... All of the investigated applications were TCP-friendly."
- RealPlayer: Jae Chung, Yali Zhu, and Mark Claypool, FairPlayer or FoulPlayer?--Head to Head Performance of RealPlayer Streaming Video Over UDP versus TCP, Technical Report N. WPI-CS-tr-02-17, Worchester Polytechnic Institute Computer Science Department, May, 2002.
  "In times of congestion, most RealVideo over UDP does respond to Internet congestion by reducing the application layer encoding rate, often achieving a TCP-Friendly rate. In times of severe congestion, RealVideo over UDP gets a proportionately larger share of the available bandwidth than does the same video over TCP."
Duke P. Hong, Celio Albuquerque, Carlos Oliveira, and Tatsuya Suda, The Impact of Emerging Streaming Media Applications on TCP/IP, IEEE Communications, Vol. 39, No. 4, pp. 76-82, April 2001.
"Streaming media UDP traffic can cause two major maladies in the Internet: congestion collapse and unfair allocations of bandwidth among competing traffic flows... This paper presents simulation results and empirical measurements that illustrate the congestion collapse and unfairness maladies, and ATM ABR's effectiveness in addressing those maladies."
Halo 2 heralds traffic explosion, BBC News, December 8, 2004.
"The growing popularity of online gaming could spell problems for net service firms, warns network monitoring company Sandvine."
VoIP:
- L. De Cicco, S. Mascolo, and V. Palmisano, An Experimental Investigation of the Congestion Control Used by Skype VoIP, Wired/Wireless Internet Communication, May 2007.
  "The explosive growth of VoIP traffic poses a potential challenge to the stability of the Internet." ... "We investigate how Skype behaves in the presence of time-varying available bandwidth." ... "We have found that Skype flows are somewhat elastic, i.e. they employ some sort of congestion control when sharing the bandwidth with unresponsive flows, but are inelastic in the presence of classic TCP responsive flows, which provokes extreme unfair use of the available bandwidth in this case. Finally, we have found that when more Skype calls are established on the same link, they are not able to adapt their sending rate to correctly match the available bandwidth, which would confirm the risk of network congestion collapse."

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].
Last modified: March 2009