0% found this document useful (0 votes)
68 views12 pages

Transmission Control Protocol (TCP) : Comparison of TCP Congestion Control Algorithms Using Netsim™

Uploaded by

AhmedElhaj
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
0% found this document useful (0 votes)
68 views12 pages

Transmission Control Protocol (TCP) : Comparison of TCP Congestion Control Algorithms Using Netsim™

Uploaded by

AhmedElhaj
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/ 12

Tetcos Engineering

TETCOS

Transmission Control Protocol


(TCP)
Comparison of TCP Congestion Control
Algorithms using NetSim™

Authors:

1. Sai Rohan BITS-Pilani


2. Shashikanth Suman Tetcos
3. Pranav Viswanathan Tetcos

@2014 Tetcos. This document is protected by copyright, all rights reserved


Tetcos Engineering

Table of Contents

1. Abstract………………………………………………………………………………………..…….. 3

2. Introduction to TCP…………………………………………………………………….........…........ 3

2.1. Problem of congestion…………………………………………………………………………. 3

3. NetSim………………………………………………………………………………………………… 4

4. TCP Variants…………………………………………………………………………………………. 4

4.1. Old Tahoe………………………………………………………………………………………... 4

4.1.1. Slow Start………………………………………………………………………………… 4

4.1.2. Congestion Avoidance………………………………………………………….……… 4

4.1.3. Timer Expiry Event……………………………………………………………….…….. 5

4.2. Tahoe……………………………………………………………………………………………. 5

4.2.1. Fast Retransmit…………………………………………………………………….…… 5

4.3. Reno……………………………………………………………………………………………… 6

4.3.1. Fast Recovery……………………………………………………………………….….. 6

4.4. New Reno……………………………………………………………………………………….. 6

4.4.1. New Reno modification to Fast Recovery………………………………………........ 7

5. Analysis………………………………………………………………………………………………. 7

5.1. Old tahoe………………………………………………………………………………………… 8

5.2. Tahoe…………………………………………………………………………………………….. 9

5.3. Reno……………………………………………………………………………………………… 10

5.4. New Reno……………………………………………………………………………………….. 11

5.5. Throughput………………………………………………………………………………………. 12

6. References……………………………………………………………………………………………. 12

@2014 Tetcos. This document is protected by copyright, all rights reserved 2


Tetcos Engineering

1. Abstract
In this paper we discuss the different congestion control algorithms of the TCP variants of Old Tahoe,
Tahoe, Reno and New Reno. All the algorithms suggest mechanisms for determining when to
retransmit a packet and how it should update the congestion window. In our analysis we create a
network scenario in NetSim and compare the congestion window behavior of all the four variants of
TCP.

2. Introduction to TCP
TCP is a transport layer protocol, part of the TCP/IP suite which defines how to establish and
maintain a connection in a network. It is a connection-oriented, end-to-end reliable protocol designed
to fit into a layered hierarchy of protocols which supports a variety network applications.

TCP‟s design philosophy has evolved considerably from where the goal was to develop an effective
packet switching protocol to a protocol which is fair, robust and reliable. As the internet traffic has
increased substantially over the past few decades it was important for TCP to be fair and take into
consideration the congestion in a network.

2.1 Problem of Congestion

Congestion is a situation in Communication Networks in which too many packets are present in a part
of the subnet and it subsequently leads to performance degradation. Congestion in a network may
occur when the load on the network (i.e. the number of packets sent to the network) is greater than
the capacity of the network.

Congestion Control refers to techniques that can either prevent congestion, before it happens, or
remove congestion after it has happened. TCP does this by maintaining a „congestion window‟, which
indicates the maximum amount of data that can be sent into the network without being
acknowledged. Different variants of TCP use a certain combinations of algorithms which update the
congestion window by sensing congestion in the network and thereby preventing it.

@2014 Tetcos. This document is protected by copyright, all rights reserved 3


Tetcos Engineering

3. NetSim
NetSim is a widely used discrete event, network simulation software developed by Tetcos. NetSim
provides a GUI for users to create network models, and provides various statistical and graphical
outputs for analysis. It also comes with sources C codes for the protocol libraries which users can
edit / modify to develop custom algorithms. In this paper, the various algorithms used by different
TCP variants such as Slow Start, Congestion avoidance, Fast Retransmit and Fast recovery are
explained and compared using NetSim.

4. TCP Variants
The four variants of TCP and the congestion control algorithms used by them are mentioned below.

4.1 Old Tahoe

Old tahoe is one of the earliest variants of TCP. It implements two algorithms called slow start and
congestion avoidance to update the congestion window.

4.1.1 Slow Start

At the start of data transmission the size of congestion window is one. This means TCP can send
only one packet until it receives an acknowledgement. When the ACK is received by the sender the
congestion window increases to two. Now the sender can send two data packets. Upon the arrival of
every new ACK the sender increases its congestion window by one. This phase is known as the slow
start phase where the congestion window increases exponentially.

So on the arrival of a new ACK, cwnd + = MSS;

4.1.2 Congestion Avoidance

TCP will continue the slow start phase until it reaches a certain threshold, or if packet loss occurs.
Now it enters in to a phase called congestion avoidance. Here the congestion window grows linearly.
This means that the congestion window increases from „n‟ to „n+1‟ only when it has received „n‟ new

ACKs. The rate of growth of congestion window slows down because this is the stage where TCP is
susceptible to packet loss. The formula used here is - cwnd += (SMSS*SMSS)/cwnd.

@2014 Tetcos. This document is protected by copyright, all rights reserved 4


Tetcos Engineering

4.1.3 Timer Expiry Event

TCP maintains a timer for every data packet that it has sent into the network. If it doesn‟t receive an
ACK before the timer expires, it assumes that a packet loss has occurred. TCP does the following
when the timer expires

 Threshold value is reduced to half of the congestion window or twice the maximum segment
size, whichever is the maximum. ssthresh = max (cwnd / 2, 2*SMSS).
 The packet which is assumed to be lost is retransmitted.
 Congestion window is reduced to one.
 Slow start is resumed.

4.2 Tahoe

TCP Tahoe implements all the above mentioned algorithms used by Old Tahoe. The Fast Retransmit
algorithm was included in Tahoe to improve the response time of TCP.

4.2.1 Fast Retransmit

One of the major drawbacks of Old Tahoe is that it depends on the timer to expire before it can
retransmit a packet. TCP Tahoe tries to improve upon Old Tahoe by implementing the fast retransmit
algorithm. Fast Retransmit takes advantage of the fact that duplicate ACKs can be an indication that
a packet loss has occurred. So, whenever it receives 3 duplicate ACKs it assumes that a packet loss
has occurred and retransmits the packet.

4.3 Reno

TCP Reno retains the basic principles of Tahoe such as Slow Start, Congestion Avoidance and Fast
Retransmit. However it is not as aggressive as Tahoe in the reduction of the congestion window.
Reno implements the Fast Recovery algorithm which is described below.

4.3.1 Fast Recovery

The congestion window drop to one on the arrival of a 3 duplicate ACK can be considered as an
extreme precaution. Arrival of 3 duplicate ACKs corresponds to light congestion in the network and

@2014 Tetcos. This document is protected by copyright, all rights reserved 5


Tetcos Engineering

there is no need for the congestion window to drop down drastically. The Fast Recovery algorithm
does the following on the arrival of a third duplicate ACK:

 The threshold value is set to half of the congestion window. ssthresh = cwnd/2.
 The congestion window is now set to be threshold plus three times the MSS.
cwnd = ssthresh + 3*SMSS.
 On the arrival of another duplicate ACK the congestion window increases by one MSS. This is
done because an ACK signifies that a segment if out of the network and the sender can pump
in another packet into the network. This is somewhat similar to slow start. cwnd += SMSS.
 TCP remains in fast recovery phase until it receives a higher ACK from the receiver.
 On receiving a higher ACK the congestion window is set to the threshold value. From now
onwards congestion avoidance is followed. cwnd = ssthresh.

4.4 New Reno

Reno doesn‟t improve much upon tahoe if there are multiple packet losses in the same window. This
is because when multiple packet losses occur Reno enters fast recovery multiple times which
decreases the congestion window by half every time. In practical scenarios where multiple packet
loss in the same window is common, Reno doesn‟t increase the throughput significantly. A modified
version of fast recovery algorithm was suggested to overcome this.

4.4.1 New Reno’s Modification to Fast Recovery

In the modified version of Fast Recovery, TCP stores the sequence number of the highest data
packet which is sent when the third duplicate ACK arrives in a variable called „recover‟. New Reno
doesn‟t exit fast recovery unless it has received an ACK which is higher than the recover packet.

If a new ACK arrives which has an ACK number lower than the recover packet, it immediately
retransmits that packet. This ACK is known as a partial ACK. When a partial ACK arrives the
congestion window is reduced by the amount of „new data‟ that has been acknowledged by the partial
ACK (i.e the amount of data that has been acknowledged after the retransmitted packet). To this one
MSS is added. In mathematical terms - cwnd = cwnd – newdata +SMSS.

TCP stays in fast recovery mode until it receives a full ACK i.e. an ACK with a higher sequence
number than recover. Note that if there aren‟t any multiple packet losses in the same window then
New Reno essentially behaves like Reno.

@2014 Tetcos. This document is protected by copyright, all rights reserved 6


Tetcos Engineering

5. Analysis
We have used NetSim to simulate the network scenario. The scenario consists of two nodes
connected by two routers. Wired node C is the sender and Wired node D is the receiver. Packets of
size 1460 bytes are generated by the application layer of the sender every 400 micro seconds of the
simulation. This amounts to 27.84 Mega Bits of data generated per second. This is higher than the
node to router link which is set to 20 Mega Bits per second. This simulates an infinite backlog of
traffic which means that TCP never runs out of data to send.

All simulations were run using NetSim version 8.2

Scenario Properties

Maximum Segment Size (MSS) 1460 bytes


Node – Router propagation delay 5 µs
Router – Router propagation delay 100 µs
Node – Router link speed (both) 20 Mbps
Router – Router link speed 100 Mbps
Advertising window size 32 MSS (46720 bytes)
Bit Error Rate (All links) 10 e(-6)
Packet generation Rate Infinite Backlog

@2014 Tetcos. This document is protected by copyright, all rights reserved 7


Tetcos Engineering

5.1 Old Tahoe

The graph shown above is a plot of Congestion window vs Time of Old Tahoe for the scenario shown
above. Each point on the graph represents the congestion window at the time when the packet is
sent. You can observe that after every congestion window drop (caused by packet loss or timer
expiry) Old Tahoe enters slow start, thereby increasing its window exponentially and then enters
congestion avoidance where it increases the congestion window linearly.

@2014 Tetcos. This document is protected by copyright, all rights reserved 8


Tetcos Engineering

5.2 Tahoe

Tahoe uses the fast retransmit algorithm with which it responds to packet errors faster than Old
Tahoe. Comparing the graphs of Old Tahoe and Tahoe one can observe that the latter drops the
congestion window and retransmits faster than Old Tahoe (when three duplicate ack‟s are received).

@2014 Tetcos. This document is protected by copyright, all rights reserved 9


Tetcos Engineering

5.3 Reno

TCP Reno upon receiving the third duplicate ACK sets its congestion window according to the
formula cwnd = cwnd/2 + 3*MSS. On further arrival of duplicate ACKs it increases its congestion
window by one MSS. If it receives a higher ACK then it drops the congestion window to the new
threshold value. This mechanism is known as fast recovery.

@2014 Tetcos. This document is protected by copyright, all rights reserved 10


Tetcos Engineering

5.4 New Reno

In the New Reno‟s modification to fast recovery, TCP doesn‟t exit the fast recovery phase until it
receives a full ACK (the ACK for the segment which was sent just before the arrival of the third
duplicate ACK). If it receives a duplicate ACK in the fast recovery phase it retransmits the segment
corresponding to the duplicate ACK. It then increases the congestion window by one MSS. Hence we
see a sharper rise in the congestion window size as New Reno doesn‟t exit the fast recovery phase
until it receives the full ACK.

@2014 Tetcos. This document is protected by copyright, all rights reserved 11


Tetcos Engineering

5.5 Throughput
The following table shows the throughput for each of the simulations run on the four TCP variants.
The simulation is run for 100 seconds.

TCP Variant Throughput (Mbps) Packets Received

Old Tahoe 12.93 110715

Tahoe 14.73 126177

Reno 15.61 133651

New Reno 16.42 140595

6. References
1. Information Sciences Institute, “Transmission Control Protocol” RFC 793, September 1981
2. W. Stevens, “TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery
Algorithms,” RFC2001, January 1997.
3. M. Allman, V. Paxson, W. Stevens, “TCP Congestion Control”, RFC 2581, April 1999.
4. S. Floyd, T. Henderson “The New Reno modification to TCP‟s Fast Recovery Algorithm”, RFC
2582, April 1999.

@2014 Tetcos. This document is protected by copyright, all rights reserved 12

You might also like