Congestion control in TCP

Congestion control
Congestion control is a technique and mechanism that can prevent congestion either before it happens or after it has happened. We can divide congestion control mechanisms into two broad categories.
1. Open-loop congestion control
2. Closed-loop congestion control

Open-loop congestion control:
Here congestion is prevents before it happens. It handled by either the source or the destination. The policies are

* A good retransmission policy can prevent congestion. Retransmission policy and retransmission timers must be designed to optimize efficiency and at the same time prevent congestion.
* Acknowledgement policy imposed by the receiver may also affect congestion. If the receiver does not acknowledge every packet it receives, it may slow down the sender and help prevent congestion.
* A good discard policy by the routers may prevent congestion and at the same time will not harm the integrity of the transmission.

Closed-loop congestion control:
Here congestion is prevents after it has happened. Different protocols have used several mechanisms. Some of them are-

Back Pressure: When a router is congested, it can inform the previous upstream router to reduce the rate of outgoing packets. The action can be recursive all the way to the router just prior to the source. The mechanism is called back pressure.
Choke Point: A choke point is a packet sent by a router to the source to inform it of congestion. This type of control is similar to ICMP’s source quench packet.
Implicit Signaling: The source can detect an implicit signal warning of congestion and slow down its sending rate.
Explicit Signaling: The router that experience congestion can send an explicit signal, the setting of a bit in a packet. For example to inform the sender or the receiver of congestion.

Congestion Control in TCP:
It can be traffic jam on the way. So how TCP can handle this congestion situation. In January 1984 J. Nagle defines Congestion Control in TCP.

TCP sender starts to send a little amount of data. And increase its send rate. If congestion occurs then it reduces its send rate. And control the congestion. But the questions are

1. How does a TCP sender understand that there is congestion on the path between itself and the destination?
We have learned during Timeout session if sender get same ACK for three times it counts by using Fast retransmit algorithm. If TCP sender get three duplicates ACKs, then sender can understand there must be congestion in the path.

2. If congestion found then how TCP control reduces send rate?
TCP use AIMD (Additive-Increase, Multiplicative-Decrease) algorithm. Now we have to learn what is AIMD

AIMD (Additive-Increase, Multiplicative-Decrease):
The main theme of this algorithm is it start to send data and increase 1 MSS (Maximum Segment Size) after every RTT (Round Trip Time). For an example if MSS=1024 bytes and Congwin (Congestion Window) =10240 bytes then 10 segments are being sent within an RTT. Each arriving of ACK increases the Congwin size by 1/10 MSS. When all ACK of 10 segments received, the value of the Congwin will have increased by MSS

When congestion found the TCP sender reduce its Congwin multiplicatively. For example if Congwin=10240 Bytes then it make the Congwin= 5120 Bytes. If another loss event occur then sender again makes Congwin-2560 bytes.

Now see how TCP follow this algorithm. In TCP at the time of increasing part it has two phases. Slow Start and Congestion avoidance.

Slow Start:
In this Phase, the value of Congwin is typically initialized to 1 MSS. The TCP sender increases its rate exponentially by doubling its value of Congwin every RTT. It continues to increase its sending rate exponentially until there is loss event. The TCP sender begins by transmitting at a slow rate, so this phase is called Slow Start.

TCP sends the first segment into the network and waits for and acknowledgement. If get its ACK before loss events, then increases the congestion window by double and sends out two maximum-sized segments. If these segments are ACKed before loss events, the sender increases the congestion window by 1 MSS for each segment. So for 2 segments it will be double and that is 4. This process will continue until a loss event occurs.

Slow start phase end when the loss event occurs and AIMD saw-toothed patterns begin. This is the close to accurate.

In truth TCP congestion control act different during timeout and three duplicate ACKs. When three duplicates ACKs occurs, then TCP Congwin is cut in half and then increases linearly. Such as 1MSSà 2MSSà 4MSSà 8MSS. Then cut in half and grows linearly such as 4MSSà 5MSSà 6MSSà 7MSS
But after timeout event a TCP senders enters into Slow Start phase and sets its Congwin to 1MSS and grows exponentially. Congwin grows until reach the ½ of the Congwin (the previous Congwin value it had before timeout). Then it grows linearly. This phase is called Congestion Avoidance.

The half of previous value of Congwin or the variable between Slow Start and Congesion Avoidance phases is called Threshold. The threshold value is initially set as a large value (65535 bytes) so that it has no initial effect. When loss event occurs then the threshold value is set half of current value of Congwin.

So we can say after a timeout event, a TCP sender enters the Slow Start phase and increase the value of Congwin exponentially. When it reaches Threshold TCP sender enters into Congestion Avoidance phase and Congwin grows linearly.

The early version of TCP, known as TCP Tahoe, cuts the Conwin to 1 MSS and enters into Slow Start phase in any type of loss event.

The newer version of TCP, know as TCP Reno, cancels the Slow Start phase after Three duplicate ACK.

Why TCP Reno cancels that? The reason is during three duplicates ACK though a packet lost, some segments have been received at the sender. But during timeout event, the network is capable of delivering at least some segments even if other segments are being lost to congestion.
After a three-duplicate ACK, the cancel of Slow Start phase is called fast recovery.

Now we learn a little about TCP. So our data can transfer from one computer to another reliably and accurately. Let’s see what happen in connectionless.


if you like these topics we'll continue later

Back      Next

Click image to go:

to share this page with your friends, select below