TCP Congestion Control(2)

Slow Start 

The slow start algorithm is executed when a new TCP connection is created or when a loss has been detected due to a retransmission timeout (RTO).

It may also be invoked after a sending TCP has gone idle for some time.

The purpose of slow start is to help TCP find a value for cwnd before probing for more available band- width using congestion avoidance and to establish the ACK clock. 

Typically, a TCP begins a new connection in slow start, eventually drops a packet, and then settles into steady-state operation using the congestion avoidance algorithm 

cause:

 

A TCP begins in slow start by sending a certain number of segments (after the SYN exchange), called the initial window (IW). 

Assuming no packets are lost and each packet causes an ACK to be sent in response, an ACK is returned for the first segment,

allowing the sending TCP to send another segment.

However, slow start operates by incrementing cwnd by min(N, SMSS) for each good ACK received

where N is the number of previously unacknowledged bytes ACKed by the received “good ACK.”

A good ACK is one that returns a higher ACK number than has been seen so far. 

For this reason, some TCPs arrange to delay ACKs only after the connection has completed slow start.

In Linux, this is called quick acknowledgments (“quickack mode”) and has been part of the basic TCP/IP stack since kernel version 2.4.4. 

 

Congestion Avoidance 

Slow start increases cwnd fairly rapidly and helps to establish a value for ssthresh.

Once this is achieved, there is always the possibility that more network capacity may become available for a connection.

If such capac- ity were to be immediately used with large traffic bursts, other TCP connections with packets sharing the same queues in routers would likely experience signifi- cant packet drops,

leading to overall instability in the network as many connec- tions simultaneously experience packet drops and react with retransmissions. 

To address the problem of trying to find additional capacity that may become available, but to not do so too aggressively, TCP implements the congestion avoid- ance algorithm.  

Once ssthresh is established and cwnd is at least at this level, a TCP runs the congestion avoidance algorithm,

which seeks additional capacity by increasing cwnd by approximately one segment for each window’s worth of data that is moved from sender to receiver successfully. 

This provides a much slower growth rate than slow start: approximately linear in terms of time, as opposed to slow start’s exponential growth.  

...This function is also called additive increase because a particular value (about one packet in this case) is added to cwnd for each successfully received window’s worth of data. 

 

Selecting between Slow Start and Congestion Avoidance 

What makes TCP somewhat tricky and interesting is that the value of ssthresh is not fixed but instead varies over time.

Its main purpose is to remember the last “best” estimate of the operating window when no loss was present.

Said another way, it holds the lower bound on TCP’s best estimate of the optimal window size. 

The initial value of ssthresh may be set arbitrarily high (e.g., to awnd or higher), which causes TCP to always start with slow start.

When a retransmission occurs, caused by either a retransmission timeout or the execution of fast retransmit, ssthresh is updated as follows: 

ssthresh = max(flight size/2, 2*SMSS) 

This usually results in lowering ssthresh（when retransmission occurs）, but it can also result in increasing ssthresh.

If we examine the congestion avoidance procedure for TCP, we recall that if an entire window’s worth of data is successfully exchanged,the value of cwnd is allowed to increase by approximately 1 SMSS.

Thus, if cwnd has grown large over a considerable amount of time, setting ssthresh to half of the flight size could cause it to increase.

This happens when TCP has discovered more usable bandwidth. 

 

Tahoe, Reno, and Fast Recovery 

One problem with this approach is that for large BDP paths, this can cause the connection to significantly underutilize the available bandwidth while the send- ing TCP goes through slow start to get back to the point at which it was operating before the packet loss.

To address this problem, the reinitiation of slow start on any packet loss was reconsidered.

Ultimately, if packet loss is detected by duplicate ACKs (invoking fast retransmit), cwnd is instead reset to the last value of ssthresh instead of only 1 SMSS.

This approach allows the TCP to slow down to half of its previous rate without reverting to slow start.