The basic algorithm incorporated by TCP is Congestion Avoidance [Jac88]. The Congestion Avoidance algorithm probes for available network bandwidth by slowly increasing a congestion window (used to control how much data is outstanding in the network). When congestion is detected (indicated by the loss of one or more packets), TCP reduces the congestion window by half. This rapid backoff in response to congestion is the key to TCP's success in avoiding congestive collapse in the Internet. However, this also makes TCP extremely susceptible to bandwidth stealing by other applications which do not implement any congestion control techniques. The widespread development of new, non-TCP based applications poses two major threats to the Internet. First, these applications could contribute to a new congestive collapse of the Internet. Second, these applications will consume an unfairly large portion of resources when run side-by-side with "good-neighbor" TCP applications.
This leads to guidelines for TCP-friendly rate-based congestion control for unicast UDP traffic.
Most rate-based applications have some latitude in their choice of data rates. In order to implement a TCP-friendly congestion control algorithm, these applications should simply choose to send at a rate no higher than a TCP connection, operating along the same path, would achieve.
In times when there is no congestion (i.e. when the desired bandwidth is less than the bandwidth a TCP connection would achieve under the current network conditions), these applications may send at their desired maximum sending rate. While sending data, the application should monitor for overall packet loss. Such monitoring statistics can, for example, be included in returning acknowledgements to the sender. As long as the overall loss rate is low enough that an equivalent TCP connection would attain at least the same bandwidth, the connection may continue to send at its preferred rate. If the loss rate on the connection rises high enough that an equivalent TCP connection would not be able to attain the same bandwidth, then the rate-based application should reduce its bandwidth (as TCP would) by half. The application should then continue to monitor the packet loss on the link. Continued high levels of packet loss may force the application to perform further reductions in sending rate. If/when the loss level in the network decreases, the application may increase its sending rate, being careful not to exceed the limits a TCP connection would see under the same loss levels.
In order to accurately compute the bandwidth a TCP application would obtain, it is necessary for the application to know the MTU, RTT, and current loss rate. The MTU may be determined using an MTU discovery algorithm [RFC1191], or may be assumed to be the minimum acceptable value for TCP of 576 bytes. Current values for RTT and Loss should be kept by using "recent averages" over the last several round trips. An estimate of the RTT should be made at least once per RTT.
After modifying their sending rate, prior to performing additional increases or decreases to their sending rate, applications should wait for at least one RTT to obtain new RTT and loss rate data at the new sending rate. This will prevent applications from over-reacting in times of congestion.
If the loss rate is high enough that the TCP bandwidth falls below the
minimum rate required by the application, the application should
terminate gracefully, perhaps by informing the user that there is
insufficient network capacity available to support their needs at this
time. Alternately, at very low bandwidths, the application could
alert the user to the situation and offer the option of terminating or
continuing.
IV. Appendix
To give some intuition for Equation 1, in
this appendix we describe a simple steady-state model that gives
Consider a TCP connection with a particular roundtrip time and packet size. Further consider a steady-state model where the network drops a packet from that connection when the connection's congestion size increases to W packets. Assume that the congestion window is then cut in half, then is increased by one packet per roundtrip time until it reaches W packets again, at which point the network again drops a packet and the steady-state model continues as before. For such a simple model, it is easy to derive a formula for the steady state drop rate as a function of the roundtrip time, packet size, and average bandwidth.
Assume that the TCP connection has MTU bytes/packet, and a
roundtrip time of RTT seconds. Assume that, when a packet
is dropped, the TCP connection had a window of W packets,
and was sending at an average rate (over that roundtrip time) of
To derive equation 2, note that Loss, the loss rate for that TCP
connection, is
Loss = 1/ (W/2 + (W/2 + 1) + ... + W) Loss ~ 1/ ((3/8) W^2)
Equation 2 has been verified by simulations in [Floyd97], for loss rates up to 5%. As the loss rate increases, Equation 2 begins to overestimate the bandwidth received by a TCP connection.
Equation 2 clearly does not apply at all for loss rates of 15% or more, for the following reasons. It is clear from this steady-state model that this formula only applies for TCP connections that achieve a value W of at least four packets when a packet is dropped - for TCP connections that send only a small number of packets per roundtrip time, losses are dominated by the delays imposed by retransmit timeouts, and not by the dynamics of this steady-state model. Thus, this model clearly does not apply for W < 4, which corresponds to Loss > 0.16.
Equation 2 also models a TCP connection where the receiver sends an ACK for every packet received. Equation 2 overestimates the bandwidth that would be received by a TCP connection where the receiver only sends an ACK for every two packets received.
[Floyd97] Floyd, S., and Fall, K., Router Mechanisms to Support End-to-End Congestion Control. Technical report, February 1997.
[OM96] Ott, T., Kemperman, J., and Mathis, M., "Window Size Behavior in TCP/IP with Constant Loss Probability", DIMACS Workshop on Performance of Realtime Applications on the Internet, Plainfield NJ, November 6-8, 1996.
[Jac88] Jacobson, V., Congestion Avoidance and Control. Proceedings of ACM SIGCOMM '88. August 1988, p. 314-329.
[RFC1191] Mogul, J. and Deering, S. Path MTU Discovery. Request For Comments 1191. November 1991.