The two goals of Congestion Control are Fairness and Efficiency. Fairness in TCP means that every sender gets their fair share of the network resource. It means that if K TCP sessions share the same bottleneck link of the bandwidth R, each should have an average rate of R/K.
Concept Of Fairness in TCP
If we consider two PCs are connected to the bottleneck link of R bandwidth and both have K TCP sessions, then both should have average bandwidth of R/K. By bottleneck, we mean that for each connection, all the other links along the connection paths are not congested and have abundant transmission capacity compared to the bottleneck’s transmission capacity.
Suppose each connection is transferred in a large file and there is no UDP traffic passing through the bottleneck link, a congestion control mechanism is said to be fair if the average transmission rate for each connection is approximately the capacity divided by the number of connections which means that each connection gets an equal share of the late bandwidth.
Therefore, we can conclude that the TCP is Fair.
Working on TCP Reno
TCP Reno incorporates two new mechanisms:
- Fast Retransmit
- Fast Recovery
Fast Retransmit is very simple. It relies on duplicate acts to figure out that something is lost. If it receives 3 duplicate acts, it concludes that the packet is lost.
The second mechanism that TCP Reno implies is Fast Recovery. This is to avoid the pipe getting empty. Suppose we are entitled to a window size of 25. It is going to drive the network to congestion. We can detect the congestion through the duplicate acknowledgments and then after 3 duplicate acknowledgments we are going to retransmit the particular packet and then we will wait for another acknowledgment.
Now during this time, we will still be receiving packets. Here Fast Recovery does something clever by utilizing these duplicates to ensure that the pipe doesn’t go empty and thereby preventing the need to prevent a slow start. So, this phase where we retransmitted till we get the acknowledgment is Fast Recovery.
Working on TCP Cubic
TCP Cubic is an extension of the normal TCP standard. The TCP Cubic is a congestion control protocol that modifies a standard linear growth window function to cubic. This improves the scalability of TCP over long networks.
When TCP cubic starts off, before any lost event occurs, it registers the congestion maximum window size. In TCP cubic the window size is represented as a cubic function of time since the last congestion event. TCP cubic leverages the coincidental benefit of cubic polynomial properties.
Since it follows a cubic function, there are two different curves associated with window growth. TCP cubic starts off by growing the window size with the fast growth curve on a concave profile where the slope is large initially and decreases with time until the window size with respect to time reaches the window size of that during the previous congestion event.
After this point when the defined max congestion window is passed, the window size initially grows over a convex profile where the slope is small initially but increases with time until another congestion event is detected. In the convex profile, TCP cubic is constantly probing for more bandwidth capability within the link. In the middle, the TCP spends a lot of time which allows for the network to stabilize before probing for more bandwidth.
Since the second half is a convex profile link of a long fat network will be utilized at a greater bandwidth much faster than the other TCP congestion control mechanisms due to the accelerated slope when probing.
Cwnd = C(T-K)3+ Wmax
Open Loop TCP
Open-loop congestion control is applied to prevent congestion before it happens. The congestion control is handled either by source or destination.
If the sender feels that the sent packet is lost or corrupted, the packet needs to be retransmitted.
A good discard mechanism adopted by the routers is that the routers may prevent congestion and at the same time partially discards the corrupted or less sensitive package. Also, able to maintain the quality of a message.
The receiver should send an acknowledgment for N packets rather than sending an acknowledgment for a single packet
Closed Loop TCP
Closed Loop TCP congestion control is there to alleviate the congestion after it happens, unlike the open-loop TCP which stops congestion before it happens.
If we have source and destination and between that, we have 4 nodes connected to it. So, the flow of data is from source to destination. So, stops receive data from intermediate upstream nodes. So, the backpressure is actually the node-to-node congestion protocol that starts with the node and propagates is the opposite direction of data flow towards the source.
In choke, the packet is basically a special packet that is being sent by a node to a source to inform that congestion has occurred.
If there is no communication between source and destination, the source will think about what the possibility of congestion would be if there is no acknowledgment being received.
The node that is experiencing congestion, can explicitly send a signal to the source or to the destination that there is a congestion. This explicit signaling can be forward or backward. In Backward explicit signaling, a bit is sent in opposite direction to the source about the congestion and will ask to slow down the sending rate of packets. In Forward Explicit Signaling, the bit is sent to the destination and it will ask the destination to slow down.