CS558a Syllabus & Progress

The Congestion Control Algorithm in TCP

Congestion control algorithm for TCP
- This material is based on the classical paper by Van Jacobson
- Jacobson's paper can be found here: click here

History of Congestion Control in TCP

There have been many (and increasingly sophisticated) congestion avoidance mechanims proposed for TCP since Jacobson's work on Congestion Control in 1982.
The Congestion Control mechanism in TCP is an ever developing process.... (it is still a research topic !)

The most popular versions of TCP - named after cities in Nevada - are:

TCP Tahoe

This is the original version of TCP congestion control as implemented by Jacobson
Congestion detection mechanism is based on packet loss
Techniques employed to control congestion:
- Slow Start
- Congestion Avoidance
- Fast Retransmit

TCP Reno

This is currently the most popular version of TCP congestion control mechanism today.
Techniques employed to control congestion:
- same as TCP Tahoe (Slow Start, Congestion Avoidance and Fast Retransmit), plus
- **** Fast Recovery ****

TCP Vegas

TCP packet size

TCP is a byte oriented protocol
However, TCP would not send every byte in a separate packet since this would result in an enormous overhead...
User data is carried inside a TCP packet which itself is carried inside a IP packet :
Example:
- If no additional options are used (no additional packet header information beside the necessary ones), and each packet carries a single byte of data, the IP packet size will be 41 bytes.
- The efficiency (useful part of the packet) would be 1/41 or 2.4%
- That's equivelent to Uncle Sam taking 97.6% in income taxes !!!
TCP will always try to send multiple bytes in a packet to improve efficient

Sustained transmission:

Since we are dealing with congestion control, we will assume that the TCP sources is transmitting continuously
(Sustained transmission will lead to the worst possible congestion)

In other words:

We assume that every TCP source will transmit a packet if it is allowed to do so
Furthermore, a TCP source will always send the largest TCP segment (for efficiency reasons)
Assumption:

Maximum Segment Size (MSS)

Window size and Transmission Data Rate

The transmission data rate is dependent on the transmit window size...

The following examples willhep you understand the relationship between the data transmission rate and the window size.

Underlying dynamics:

The sender tries to send continously
But the window size will limit the number of packets that the sender can transmit continuously

Example 1:

window size is equal to MSS (Max Segment Size).

The following will happen:

Notes:

Because transmit window size is equal to MSS, the sender can send only 1 packet at a time and must pause (wait for window to slide)
The ACK for the packet will be received in approximately RTT (round trip time) sec
When the ACK is received, the sender sends the next packet.

Example 2: Window size = 2 × MSS, the sender can send faster:

Note:

The transmit data rate caries approximately linearly with the window size
But do not conclude that transmit data rate is perfectly proportional to the window size.
The above examples are "idealized".
Network delays, route changes and other factors can make the relationship very unpredictable and dynamic.

TCP's Congestion Window Size

Facts:

A chain will break at the weakest link
So also, congestion will occur at the output link that receives the most amount of data and/or has the lowest bandwidth
There is a transmission rate above which the output buffer at the "weakest" output link will overflow

We can use the above fact that given an intuitive definition of the Congestion Window Size is:

Congestion Window Size = the number of packets (of MSS bytes of data) that the sender believes that it can transmit into the network without causing congestion in the network.

Main problem:

The congestion window size cannot be accurately determined
The congestion window size varies (changes) over time because it depends on the current network status
In fact, the congestion window size changes faster than the weather and it is highly unpredictable...

Flashback: Advertised Window Size
- Recall that the sender cannot send more than the advertised window size

TCP Transmit Window Size

Transmit window:

Transmit Window = # packets (of MSS bytes in each packet) that sender can transmit without having to wait for acknowledgement
(We used to call this window the send window)

The size of the Transmit Window is computed (determined) as the maximum of these 2 windows:

Notations used in TCP congestion control scheme

Notations:

Advertised Window Size (AWS) = amount of data that the receiver is willing to buffer.
Congestion Window Size (CWND) = window size imposed on TCP by the current network state to avoid congestion (buffer overflow)
Transmit Window Size (TWS) = the transmit (send) window used by the sender

Relationship:

Assumption in TCP congestion control

Fact:

If AWS < CWND, then then the sender will always used a window size AWS
Furthermore, it will not cause congestion in the network
(Because AWS < CWND...)

If the sender will not cause congestion, then the congestion control problem is moot

(We are scientists, and not politicians.

We don't solve non-existing problems)

Assumption:

TCP congestion control: It's like playing a video game :-)

A common video game strategy:

Play as fast as you can, until you get killed....
Remember where (and how :-)) you got killed
Restart the game from the beginning, and play very quickly before the point where you got killed.
From that point on, proceed very carefully.....
Continue to play carefully until you get killed again, and repeat from step 2

TCP congestion control strategy:

TCP will detect congestion (through a packet loss) --- this is equivalent to the event where the video gamer got killed)

At this moment, the congestion window (CWND) is too large !!!
TCP sets a variable SSThresh (Slow Start Threshold) to:
(The rationale is half of the transmit window size is a conservative estimate will hopefully not cause congestion :-) )
TCP will restart by transmitting using CWND = 1 (ONE packet outstanding) and increase CWND exponentially (from 1) to SSThresh
When CWND ≥ SSThresh, (this is the point where TCP believe it is safe), it will enter the careful progress phase
In the careful progress phase, TCP will increase the congestion window size CWND linearly
The congestion avoidance phase ends when TCP detects a packet loss and the TCP repeats from step 2 after setting:
CWND is the value of the congestion window at which the current congestion took place !

Marker between the presumed safe pahse and the unknown territory
- TCP maintains a variable records the assumed safe transmission rate:

Overview TCP modes/phases of operation

TCP operates in two different modes/phases

Slow Start Mode/Phase: CWND < SSThresh

This is the start up mode of operation of TCP
In this mode/phase, TCP is sending below the assumed transmission rate
TCP will try to reach the safe transmission rate as fast as possible
In this phase, TCP will start by transmitting ONE packet in an epoch
At each successfully transmission epoch, TCP will double the transmission rate (resulting in an exponential increase !!! )
Increase/Decrease function used:

Congestion Avoidance Phase:

This is the phase that begins after the slow start phase
(The slow start phase ends when TCP has reached the transmission rate has reached the rate that TCP believed to be safe.)
TCP is now in uncharted territory....
As long as TCP does not detect congestion, it would be a shame not to use the available capacity (and let it go to waste) !!!
But, TCP must be careful not to cause congestion

So:

In this congestion avoidance phase, TCP will increase the transmission rate slower
In this phase, TCP will increase the transmission rate by one packet at each successfully transmission epoch

Increase/Decrease function used:

Graphical illustration of the TCP congestion control operation

TCP transmission rate over time:

(Note: bottle neck can change over time !!!)

Notes:

When TCP starts out, it sets SSThresh = AWS (try to send as much data as the receiver can handle)

If the network can handle this transmission rate, TCP will not need to do any congestion control !!!
(Because the bottle neck is at the receiver...)

Recall that we have assumed that: AWS is the not the limiting factor

The first piece of the graph in the picture above shows a scenario where the sender start losing packets at 50 Kbps

At some point (in the figure, it happens when sender was transmitting at 50 Kbps ), packets are dropped and congestion is detected.
Because the packet drop happens at the moment when the sender was transmitting 50 Kbps , the new target congestion rate is set to:
TCP now restart with CWND = 1 and doubles the transmission rate after each epoch
The transmission rate will increase exponentially until it reaches SSThresh = 25 Kbps
From CWND = 25 Kbps onwards, TCP will increase the transmission rate linearly - until it detects a packet loss
(In the figure, it happens when sender is transmitting CWND = 30 Kbps )
Because the packet drop happens at the moment when the sender was transmitting 30 Kbps , the new target congestion rate is set to:
TCP will again restart with CWND = 1 and doubles the transmission rate after each epoch
The transmission rate will increase exponentially until it reaches SSThresh = 15 Kbps
From 15 Kbps onwards, TCP will increase the transmission rate linearly - until it discover a packet loss
And so on....

Further notes:

Remember: one of the goal of TCP is to achieve the highest possible throughput.
This goal is not achieved by sending as fast as possible, but as fast as the network can handle !!!
The available network bandwidth changes continually....
TCP tries to determine the available capacity by remembering when the data rate at which a packet drop occured the last time and proceeds carefully starting from half way of this capacity level.
When TCP starts transmitting for the first time, it has no idea how much data the network can handle.
It will therefore set SSThres = AWS, i.e., set the transmission rate to what the receiver can handle...