The macroscopic behavior of the TCP congestion avoidance algorithm

Abstract

In this paper, we analyze a performance model for the TCP Congestion Avoidance algorithm. The model predicts the bandwidth of a sustained TCP connection subjected to light to moderate packet losses, such as loss caused by network congestion. It assumes that TCP avoids retransmission timeouts and always has sucient receiver window and sender data. The model predicts the Congestion Avoidance performance of nearly all TCP implementations under restricted conditions and of TCP with Selective A c knowledgements over a much wider range of Internet conditions.We v erify the model through both simulation and live I n ternet measurements. The simulations test several TCP implementations under a range of loss conditions and in environments with both drop-tail and RED queuing. The model is also compared to live I nternet measurements using the TReno diagnostic and real TCP implementations.We also present s e v eral applications of the model to problems of bandwidth allocation in the Internet. We use the model to analyze networks with multiple congested gateways this analysis shows strong agreement with prior work in this area. Finally, w e present several important implications about the behavior of the Internet in the presence of high load from diverse user communities.

TCP is competitive against a limited adversary

“…Most of these make the simplifying assumption that every packet gets dropped with probability p independent of all other packet drops. Under this assumption, several papers [20,18] show that for low values of p, TCP throughput is proportional to 1/ √ p. The same result was proved in [24] for more elaborate models of TCP. [25] showed that throughput decreases faster (roughly proportional to 1/p) at higher values of p. All these papers assume constant round-trip times.…”

Stochastic Hybrid Systems: Application to Communication Networks

“…This behavior is completely different from the one observed for TCP flows that are always on, for which it has been shown that the steady-state average sending rate is approximately given by c RT T √ p drop , where RT T denotes the average round-trip time, p drop the per-packet drop rate, and c a constant ranging from 1.225 to 1.310 depending on the method used to derive the equation [8,20,35,36,40]. This equation is valid at least for simple network topologies, small values of p drop , and one acknowledgments per ACK packet (n ack = 1).…”

“…A great deal of effort has been placed in characterizing the steady-state behavior of these flows [35,36,40,41,46]. In particular, in studying the relationship between the average transmission rate µ, the average round-trip time RT T , and the per-packet drop rate p drop for a single TCP flow.…”

Testing TCP Traffic Congestion by Distributed Protocol Analysis and Statistical Modelling

“…Specifically, if many packets arrive within a short period of time, the buffer may eventually overflow, so that an increase in the network load results in a decrease of useful work done due to: undelivered packets, packets consuming resources that are dropped later in the network, spurious retransmissions of packets still "in flight" (leading to even more load)… In the mid-1980s, the Internet converged to a halt until Jacobson/Karels devised TCP congestion control [3], so that the general approaches to avoiding drops of many packets and the so-called congestion collapse include: pre-arranging bandwidth allocations (with drawbacks of requiring negotiation before sending packets and potentially low utilization, differential pricing, i.e. not dropping packets for the highest bidders, and dynamic adjustment with testing the level of congestion with speeding up when there is no congestion and slowing down otherwise (where drawbacks are: suboptimality, complex implementation) [4].…”

“…Therefore, upon success with the last window of data, the TCP sender load should increase linearly, and decrease multiplicatively, upon packet loss [4]. This becomes a necessary condition for the stability of TCP [5], [6], [7].…”