Introduction
Congestion control is a set of behaviors determined by algorithms that each TCP implements in an attempt to prevent the network from being overwhelmed by too large an aggre- gate offered traffic load.
The basic approach is to have TCP slow down when it has reason to believe the network is about to be congested (or is already so congested that routers are discarding packets).
The challenge is to determine exactly when and how TCP should slow down, and when it can speed up again.
We have already seen in Chapter 15 how a sending TCP can be made to slow down if its peer (receiving) TCP cannot keep up.
This is accomplished by TCP’s procedures for flow control and is realized by a sender adapting its sending rate based on the advertised Window Size field provided by a receiver in its ACKs.
This provides explicit information about the state of the receiver back to the sender and allows it to avoid overrunning the receiver’s buffers.
Consider what happens when the network between a collection of senders and receivers is asked to carry more traffic than it can handle.
Either the senders must slow down or the network must ultimately throw some data away (or some combi- nation thereof).
This situation, when a router is forced to discard data because it cannot handle the arriving traffic rate, is called congestion.
Detection of Congestion in TCP
As we have seen, the primary mechanism TCP has available to combat packet loss is retransmission, induced either by a retransmission timer expiring, or by the fast retransmit algorithm (see Chapter 14). Consider,
for a moment, the consequence of many TCP connections that share an Internet path simply retransmitting more packets while the network is in a state of congestion collapse.
As you can imagine, this only makes the situation worse.
Slowing Down a TCP Sender
This is accomplished by intro- ducing a window control variable at the sender that is based on an estimate of the network’s capacity and
ensuring that the sender’s window size never exceeds the minimum of the two.
In effect, a sending TCP then sends at a rate equal to what the receiver or the network can handle, whichever is less.
W = min(cwnd, awnd)
The new value used to hold the estimate of the network’s available capacity is called the congestion window
The sender’s actual (usable) window W is then written as the minimum of
the receiver’s adver- tised window awnd and the congestion window
With this relationship, the TCP sender is not permitted to have more than W unacknowledged packets or bytes outstanding in the network.
The total amount of data a sender has introduced into the network for which it has not yet received an acknowledgment is sometimes called
the flight size, which is always less than or equal to W.
In general, W can be maintained in either packet or byte units.
Although handling congestion at the TCP sender is our primary area of inter- est, work has been done on handling the cases where congestion occurs on the reverse path, because of ACKs
The Classic Algorithms
This could be accomplished by either sending immediately at the maximum rate it can (subject to the value of awnd), or it could start more slowly.
Because of the detrimental effects on the performance of other TCP connections sharing the same network path that could be experienced when starting at full rate,
a TCP generally uses one algorithm to avoid starting so fast when it starts up to get to steady state.
It uses a different one once it is in steady state.
The operation of TCP congestion control at a sender is driven or “clocked” by the receipt of ACKs.
Following this line of reasoning, the TCP congestion behavior in steady state attempts to achieve a conservation of packets in the network (see Figure 16-1).
We now turn to the main two algorithms of TCP: slow start and congestion avoidance.
These algorithms, based on the principles of packet conservation and ACK clocking.
These algorithms do not operate at the same time—TCP exe- cutes only one at any given time, but it may switch back and forth between the two.