We focus on TCP Congestion Control in today's lesson. TCP protocol use an advertised window to ensure that receiver buffer will not overflow. However, buffers at immediate routers may still overflow. As the figure shows, congestion occurs when the total arrival rate from all packet flows exceeds the outgoing bandwidth of the router over a sustained period of time. During congestion, the buffer at the router's multiplexer will fill and the packets may be lost. In general, there are three phase in the traffic load. The first one is called light traffic, where the total arrival rate at a router is far smaller than its outgoing length of bandwidth. Incoming packets experience low delay. The second phase is knee stage. As a total arrival rate keeps increasing, it approached the knee point that it is total arrival rate at a router is close to the outgoing length of bandwidth. Packets experience increase in delay and the total slope begins to saturate. The surface is congestion collapse when the total arrival rate is greater than other outgoing length of bandwidth. Packets experience a larger delay and loss. Effective throughput drops significantly. If the TCP senders are too aggressive by sending too many packets, the network may experience congestion. But if the TCP senders are too conservative, the network will be under utilized. Ideally, the objective of TCP congestion control is to have each sender transmit just the right amount data to keep the network saturated but not overloaded. TCP protocol defines a congestion window, which specifies the maximum number of bytes that a TCP sender is allowed to transmit without triggering congestion. In TCP header, this effective window is the minimum of the congestion window and advertised window. But the problem is the sender doesn't know what its fair share of available bandwidth should be. The TCP solution is probe and adapt dynamically to available network boundaries. Ideally, sending rate stabilize near the optimal point. How does the TCP congestion algorithm attack a congestion window dynamically according to the current status of the network? The rationale is that in light traffic, each segment should be acknowledged quickly so the sender can increase congestion window quickly. Near the knee point, segment acknowledgements arrive, but more slowly. So senders should slow down increase in congestion window. When congestion detected, segments encounter larger delay, so retransmission timeouts occur. And the segments are dropped in router buffers, resulting in duplicate acknowledgements. The sender should reduce transmission rate, then probe again. Accordingly, the operation of the TCP congestion control can be divided into three phase. The first one is called a slow start, that is accomplished by first setting the congestion window to a small value. Usually just one segment. Each time the sender receive an acknowledgement from the receiver before it time out, sender increase congestion window by one segment. Therefore, after sending the first segment, if the sender receive an acknowledgement before timeout, the congestion window is increased up to two segments. Later, if these two segments acknowledge it, the congestion window is increased to four. So as shown in the figure, actually the congestion window size grows exponentially during the slow start phase. The rationale for exponential growth is it needs to fill the pipe as quickly as possible to utilize network resource maximally. After a certain point, it may be unwise to keep increasing the congestion window exponentially, since overshoot can be significant. The algorithm progressively sets a congestion threshold. When congestion window size is greater than the threshold, slow start phrase ends. On phase two, congestion avoidance takes over. It'll increase congestion window linearly by one segment per round-trip-time. The congestion window stops increasing when TCP detects network congestion due to timeout or receipt of duplicate acknowledgement. Algorithm enters the surface congestion and sets the congestion threshold to one-half of the current congestion window for probing the link bandwidth next time. So it aggressively sets the congestion window back to one segment. And it restarts using the slow start technique. The figure shows the dynamics of the congestion window as time progresses. We can observe that initial congestion threshold was set to 16 segments. And later, it got cut to half of the congestion window when the congestion detected. When the congestion was not as severe, cutting the congestion window's size back to one segment might be too aggressive. Indeed, if only one segment is dropped during transmission, the TCP sender can recover more quickly. The reason is that subsequent segments trigger the TCP receiver to transmit duplicate acknowledgements, as shown in the figure. And these triggered acknowledgements usually arrive at the TCP center before the retransmission timer expires. When the TCP center receives the three duplicate acknowledgements, it performs faster to transmit by immediately retransmitting the last segment. The center then performs fast recovery by setting the congestion threshold, as explained earlier. But setting the congestion window size to the congestion threshold plus three segments, instead of cutting back to just one segment. The algorithm then remains in congestion avoidance phase. This figure shows the dynamics of the congestion window as time progresses. So in absence of time-outs, the congestion window size will oscillate around as the optimal value. This concludes today's lesson.
