Scribd
Upload
22 views

Congestion Control Algorithhms

Uploaded by

Md Tauqeer
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
22 views

Congestion Control Algorithhms

Uploaded by

Md Tauqeer
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 26

CONGESTION

CONTROL
ALGORITHMS

Aviral Soni
Md Ashif Jamal
Md Tauqeer Alam
Table of Content

Introduction
TCP Tahoe
TCP Reno
TCP New Reno
TCP SACK
TCP VEGAS
TCP CONGESTION

Congestion refers to a network state where - The message traffic becomes so heavy
that it slows down the network response time. Congestion is an important issue that
can arise in Packet Switched Network. Congestion leads to the loss of packets in
transit.

Congestion is an important issue that can arise in Packet Switched Network.


Congestion leads to the loss of packets in transit.
It is necessary to control the congestion in network
It is not possible to completely avoid the congestion
Slow Start: Exponential Increase

Every RTT, congestion


window doubles.
1->2->4->8->16
Congestion Avoidance: Additive Increase

If an ack arrives, cwnd = cwnd +1/cwnd.


To avoid congestion before it happens, we must slow down
this exponential growth
Start cwnd=i
After 1 RTT: i+1
After 2 RTT: i+2
After 3 RTT: i+3
it will keep increasing until congestion occurs or maximum
receiver capacity is reached.
Congestion Detection: Multiplicative Decrease

If congestion occurs, the congestion window size must be decreased.


The only way the sender can guess that congestion has occurred is by
the need to retransmit a segment.

Retransmission can occur in one of two cases: when a timer times out or
when three Duplicate ACKs are received. In both cases, the size of the
threshold is dropped to one-half, a multiplicative decrease
Fast Recovery
The fast-recovery algorithm is optional in TCP.

The old version of TCP did not use it, but the new versions use it.
It starts when 3 duplicate ACKs arrive, which is interpreted as light
congestion in the network.

Like congestion avoidance, this algorithm is also an additive increase,


but it increases the size of the congestion window when a duplicate
ACK arrives.
TCP TAHOE
Tahoe TCP is an early version of TCP
uses slow start+AIMD+Fast-retransmit

TCP starts the slow-start algorithm and initially threshold value


is set to infinity

Tahoe always set the congestion window to 1 whether it is a case


of timeout or 3 duplicate ACKs.
TCP TAHOE
In the case of 3 duplicate ACKs, fast-retransmit takes place:
send missing packets
threshold=cwnd/2
cwnd=1
starts from slow start phase

In the time out:


cwnd=1
retransmit all the lost packets
starts from slow start phase
TCP Reno
TCP Reno reacts to timout and 3 duplicate acks very differently.
Fast recovery is a new state that is entered when three duplicate ACKs arrive.
In fast recovery, the cwnd grows exponentially, but it starts with the threshold
value plus 3 MSS (instead of 1).

Key differences between Tahoe TCP and Reno TCP:


1) Tahoe cannot detect light congestion .
2) Reno treats timeouts and three duplicate ACKs differently.
3) Reno has a new state called fast recovery.
Why 3 duplicate ACKs?

Since TCP does not know whether a duplicate ACK is caused by a lost
segment or just a reordering of segments, it waits for a small number of
duplicate ACKs to be received. It is assumed that if there is just a
reordering of the segments, there will be only one or two duplicate ACKs
before the reordered segment is processed, which will then generate a
new ACK. If three or more duplicate ACKs are received in a row, it is a
strong indication that a segment has been lost. TCP then performs a
retransmission of what appears to be the missing segment, without
waiting for a retransmission timer to expire.
TCP Reno
Advantages of Reno TCP:

Faster recovery from congestion events: Reno TCP can recover from
congestion events more quickly than Tahoe TCP because it uses the fast-
recovery state.
More efficient use of network resources: Reno TCP can use network
resources more efficiently than Tahoe TCP because it does not restart slow
start from scratch after each congestion event.
Limitation of Reno
can only detect a single packet loss in one RTT.
the information about the second packet which was lost will come
only after the ACK for the retransmitted first segment reaches the
sender after one RTT.

Also it is possible that the CWD is reduced more than for packet losses
which occurred in one window
Another problem is that if the window is very small when the loss occurs
then we would never receive enough duplicate acknowledgements for a
fastretransmit and we would have to wait for a coarse grained timeout.
Thus is cannot effectively detect multiple packet loss.

solutions to Reno’s Problem


TCP New Reno
TCP SACK
TCP FACK
TCP VEGAS
TCP New Reno
The difference from Reno is that New Reno does not halve ssthresh
immediately which may reduce the window too much if multiple
packet losses occur. It does not exit fast-recovery and reset
ssthresh until it acknowledges all of the data.

New-Reno suffers from the fact that its take one RTT to detect
each packet loss. When the ACK for the first retransmitted segment
is received only then can we deduce which other segment was lost.
TCP SACK

It solves the multiple packet lost problem.

SACK retains the slow-start and fastretransmit parts of RENO. It also


has the timeout of Tahoe to fall back on, incase a packet loss is not
detected by the modified algorithm.

Disadvantage of SACK is that it is not very easy to incorporate SACK in


the current TCP. We need fields to acknowledge the selective
segments and this requires changes at the receiver as well.
TCP VEGAS

It does not depend solely on packet loss as a sign of congestion. It


detects congestion before the packet losses occur. However it still
retains the other mechanism of Reno and Tahoe, and a packet loss can
still be detected by the coarse grain timeout if the other mechanisms
fail.

on receiving 1st dup ack check:


if(current timesegment transmission time)> RTT
trigger fastRetransmit without 3 dupACKs.
TCP VEGAS-anticipating congestion

Base RTT=minRTT(measured )
Expected and Actual sending rate
expected=cwnd/BaseRTT
diff=expected-actual
if(diff<a)cwnd=cwnd+1 per RTT
else if(diff>b)cwnd=cwnd-1 per RTT
Cubic
A loss based algorithm

CUBIC is used to optimize long networks, which are networks with


high bandwidth and high latency.

CUBIC modifies the linear window growth function to be a cubic


function.

CUBIC implements schemes of large increments at first, which


decrease around the window size that caused the last congestion.
Loss vs Delay based algorithms

delay based algorithms are


more stable
less packet re-transmission
lower latencies
Hybrid algorithms

Some try to combine two approaches to reap the benefits of both.

Compound TCP is a well-known example, as it is available on all


Microsoft Windows machines by default.

It combines a delay-based window and a loss-based Reno window as


its CWND
M.L. Approaches

TCP Remy and TCP-RL are examples of M.L. based algorithms.


Bibliography
A Survey on Recent Advancesi n Transport Layer Protocols

https://inst.eecs.berkeley.edu/~ee122/fa05/projects/Project2/S
ACKRENEVEGAS.pdf

https://www.geeksforgeeks.org/basic-concept-of-tcp-vegas/

https://www.ripublication.com/acst17/acstv10n6_17.pdf
THANK YOU

You might also like