–

Changing TCP Variants On The Fly

Aishwarya K.R. MT2010008 [email protected]

Hrishikesh Murali MT2010048 [email protected]

Pradeep S. MT2010106 [email protected]

Pragnya Paramita MT2010108 [email protected]

Sujata Jha MT2010152 [email protected]

International Institute Of Information Technology-Bangalore

www.iiitb.ac.in

Technical Report IIITB-OS-2011-11A

April 2011
Acknowledgements

We would like to express our deep-felt gratitude to our guides, Prof. Shrisha Rao and
Prof. Debabrata Das, International Institute of Information Technology Bangalore,
for their advice, encouragement, enduring patience and constant support. They have
always provided us with clear explanations when we were lost, constantly driving us
with energy, giving us their valuable time. We are indebted to both of our guides for
the unparallel support that they have lent to make this project a huge success.

2
Abstract

This project aims at automatically detecting the link type being used and changing
the congestion control algorithm appropriately so that the connection does not timeout
by detecting congestion in the network incorrectly and applying the commonly used
congestion control algorithm. In normal systems a common TCP congestion control
algorithm is used irrespective of the active channel type, but depending upon the chan-
nel type the real time congestion scenario in the network varies to a very large extent.
Every channel can be described by their own characteristics, so the parameters that
affect congestion also vary. For example, a satellite connection takes a very long round
trip time so RTT is greater in case of SAT-COMM. But in wireless and wired connec-
tions long RTTs are considered to be a deciding factor for congestion in the network.
When a common congestion algorithm is used for all scenarios then a long RTT of
SAT-COMM will mislead to a congestion which actually never happened and it will
then start decreasing the window size, which results a more delayed network. This is
just an example of one parameter. Similar problems may take place in case of wireless
and wired network misinterpreting some other parameter. Therefore one common algo-
rithm may not work efficiently for all kind of channels. Rather, finding the best one for
each channel will suffice the need well. One proposed solution to the above discussed
problem is what the problem statement of the project states. To implement the same,
basic requirements are detecting the type of channel, deciding the best suited TCP
congestion control algorithm for that and then setting that algorithm in the system for
that channel type. Approach follows for that is channel types like SAT-COM, wireless
and ethernet are simulated in a local environment using the NS-2 program for different
algorithm to observe the trace files for details like number of bytes/sec, number of pack-
ets/sec etc. For example, it has been shown[1] that the cubic algorithm works best with
a reliable SAT-COM channel with link-level FEC. To confirm the results a literature

3
survey through papers discussing TCP congestion control algorithm have been carried
out. Then a look up table is created which defines a mapping between the type of
channel and the congestion algorithm in use. The next step can be represented as a
way to find the type of channel to which the system is connected. For that, program
is written in the C language which runs in user space, monitors the network interfaces
present in the system and derives similar heuristics based on data flow through the
interface. The channel type is decided from the heuristics derived. It then looks up the
table, and changes the congestion control algorithm being used in the system accord-
ingly to improve throughput. Hence it solves the above discussed problem by setting
appropriate algorithm for the connected channel.

http://sourceforge.net/projects/congestionmonit/

c 2011 Aishwarya K.R., Hrishikesh Murali, Pradeep S., Pragnya Paramita and Sujata

Jha. This material is available under the Creative Commons Attribution-Noncommercial-

Share Alike License.
See http://creativecommons.org/licenses/by-nc-sa/3.0/ for details.

4
Contents

1 Introduction 6
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Goal and Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Congestion Monitor 10
2.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Working with NS-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Wired Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Wireless Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 Observation of accuracy of NS2 from simulated results . . . . . 17
2.3 SAT-COM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.1 Description Of The Satellite Nodes . . . . . . . . . . . . . . . . 21
2.3.2 Simulation Of Iridium And Teledeisic Satellite Network . . . . . 22
2.3.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Testing and Experimental Results 26

4 Conclusion 30

5
1 Introduction

1.1 Background

Network congestion occurs when a link or node over a network has too much of data to
process/transmit resulting in deterioration of QoS (Quality of Service). This is often
characterized by phenomena such as packet loss or queuing delay. This subsequently
results in timeouts and retransmissions from the hosts.

To avoid such situations, network congestion control algorithms were designed. Typ-
ically, the rate of flow of data over the congested link is reduced by each host using
the link. Techniques such as exponential back off or window size reduction in TCP are
used to tackle the situation.

Examples of congestion control algorithms include Reno, Veno, Westwood, Cubic, Hybla.
Each congestion algorithm was designed to tackle congestion in specific types of net-
works. Reno works well in ethernet channels whereas BIC (Binary Increase Congestion
Control) works well in high-speed channels with high latency.

The best variant among the different available TCP protocols for wired, wireless and
sat-com are decided based on the simulation results of NS2[2] and by literature study.
The algorithms are required to ensure spontaneous connectivity and reliability.

TCP maintains a congestion window and uses a mechanism called slow start which
will increase the window size every time after the connection is initialized and even
after a timeout. Congestion avoidance is a state where the congestion window exceeds
ss thresh which is a threshold value. When a packet is lost, duplicate ACKs will be

6
received and this will degrade the efficiency of the network. The behavior of different
congestion control algorithms differ in how they detect the packet loss and the way they
react to packet loss.

Reno: When three duplicate ACKs are received, this algorithm will halve the con-
gestion window and it will perform a ”fast retransmit”. If there is a time out, slow start
is used. This algorithm is best for wired network.

Cubic: The performance limitations of TCP variants are due to delays and proba-
bility of errors. These factors are mostly found in satellite communication (sat-com)
systems. The throughput of a channel is mainly dependent on the congestion window
size. In most of the algorithms (Reno, Tahoe, NewReno) the initial threshold is set to a
default value and this will affect the performance of the system. In Cubic, the window
is a cubic function of time since the last congestion event. This is less aggressive and
is used as a default in Linux kernels. This is the best algorithm for satellite communi-
cation.

TCP Westwood (TCPW)[3]: This algorithm is a modification of TCP NewReno. The

main intention of this algorithm is to handle large bandwidth-delay product paths. The
performance of this algorithm is measured and can be concluded that it is highly effi-
cient, stable and fair. TCPW is also shown to have consistent performance. Westwood
is the most significant in wireless networks with lossy links as it relies on end-to-end
bandwidth estimation.

7
1.2 Goal and Gap Analysis

Build a system that can automatically switch its choice of TCP variants on the fly, to
allow it to work in at least three environments (such as standard ethernet, SAT-COM
and wireless). In communication links such as SAT-COM, TCP results in irregular
timeouts. This is because the transmission time via the satellite is longer. Hence, the
host times out and detects congestion in the network. Previous studies[4] show that
channels with high latency and low error rate, such as SAT-COM links with link-level
forward error correction(FEC), cubic performs better than hybla; but if raw satellite
links were to be used, the channel would have high error rate and latency, and hybla
plays a better role in congestion control in this case.

Further, it is observed that TCP Westwood also works well in SAT-COM[5]. But,
algorithms such as TCP compound, TCP cubic and H-TCP cannot work well in SAT-
COM[6]. Hence in safety-critical situations such as combat, which uses SAT-COM
extensively and where reliable data transfer is crucial, changing the congestion algo-
rithm according to the channel being used is essential.

Congestion algorithms can be dynamically used at will in a linux system using the
sysctl command provided by the linux kernel. This program requires super user priv-
ileges, and can be invoked anytime. sysctl changes the congestion algorithm being
used for the entire system, and not each TCP connection. Sadly, linux does not provide
a mechanism where we can change the congestion algorithm per TCP connection.

In situations such as defense, changing the congestion control algorithm manually is

not practical. Automating the process of switching over congestion control algorithms
accordingly would make communication in link types such as SAT-COM comparatively

8
better, with lesser timeout.

9
2 Congestion Monitor

congestionmonit is a tool which changes the TCP congestion control algorithm on

the fly based on the type of interface which is being used for communication. It uses the
vnstat tool for monitoring the various network interfaces of the system and sysctl
command available in linux systems to change the algorithm being used.

2.1 System Architecture

For the problem statement the designed system architecture is represented below.

Figure 1: Architecture Diagram.

10
 System: System represents the user system in which the implementation of prob-
lem statement will take place.
Network Interface: Network Interfaces are the part of the system, but shown
independently to make an easier visualization of the interaction of congestionmonit.c
program with the network interface.
congestion monitor: It is the main working code of the system. The main
purpose is to monitor network interface.
Look Up Table: It contains the mapping of type of connection to correspond-
ing TCP congestion control algorithm.
congestion monitor and Look Up Table interacts with each other to set the algorithm
as soon as the type of connection channel varies.
Description: A user space process monitor is used to monitor the network
interfaces of the system. It calculates different network parameters such as average
packet delay, average packet loss, etc. It compares the values with the lookup table
created, and changes the congestion control algorithm on the fly. This process monitors
in the transport layer of the network protocol stack. Linux provides an easy-to-use
module called sysctl which enables super users of the system to interact with the kernel.
Using this, the congestion control algorithm can be changed.

2.2 Working with NS-2

NS2 is a discrete event network simulator which is an object oriented program written
using C++/OTCL[7]. This can simulate the existing network protocols over wired,
wireless and sat-com networks. In order to verify the observations made through the
literature survey, we have run simulations using the network simulator (NS2). For this
ns-allinone-2.34 is used.
The basic ns2 Otcl script contains:

11
 • set ns[new simulator] #definition of the object

• $ns at simul-time "exit 0"

• $ns run; #At the end of the script to execute the simulation

Simulation steps:

• Scenario definition.

• Write the Otcl script.

• Execute the script.

• Extract the results.

xgraph of the NS2 simulator is used to generate graphics. A data text file file.dat will
contain two columns, time and throughput/congestion window.
NSG2: NS2 Scenarios Generator 2 (NSG2) is a JAVA based ns2 scenarios generator.
NSG2 can generate wired and wireless TCL scripts for ns2.
Function of NSG2: Creating wired and wireless nodes, connection between nodes, links,
agents, applications and node movement.

2.2.1 Wired Simulation

Wired simulation represents a network topology where nodes are considered to be con-
nected via cable.
For simulation of a simple wired network :

• Network topology and parameters have to be decided first. It includes number

of nodes, type of link between nodes (two way or one way), bandwidth of each
link, delay included at each link, type of queue build, type of traffic agent, type

12
 of congestion algorithm, type of packets, packet length and any other condition
of network if specifically required.

• Simulation of the network is developed using TCL script.

• Nodes are created first depending upon number of nodes.

set n0 [$ns node]
set n1 [$ns node]

• Then link between them is established using type of link and delay at each link
and type of queue.
$ns duplex-link $n0 $n1 5Mb 100ms DropTail

• The network topology is written.

$ns duplex-link-op $n0 $n1 orient right-up

• Then traffic agents(CBR,UDP,TCP)are created and attached to nodes.

set tcp0 [new Agent/TCP/Linux]
$tcp0 set timestamps true
$ns at 0 "$tcp0 select ca Reno"

• Type of packets specified are created.

• Trace files for network animator and xgraph are opened and at the end, files
are closed. Relevant piece of code is written for respective activity like plotting
throughput vs time, congestion window vs time, bandwidth vs time etc. All the
relevant information for plotting the graphs and to initialize network animator is
stored in these trace file. Start and end time of simulation are mentioned.

• To start the simulation ns <file.tcl> command is invoked from command

prompt.

13
 • To visualize the network topology and traffic flow network animator is used and
invoked with command nam <file.nam>.

Simulations

• Simulation for a simple network of 4 nodes connected in duplex link, having

bandwidth of 5MB for two links and 1.5 MB for another link with 2ms and 10
ms link for respective links having droptrail queue pattern is done. Here all UDB
CBR and TCP traffic for three different links are used. For TCP connection FTP
packets are generated. The network animation of simulation is shown in figure 2.

Figure 2: Nam visualization for wired network

• The above screen shot represents the network for four nodes. Nodes 1,2 0,2 and
2,3 are connected via links. To start viewing the simulation, play button is clicked.
It simply shows the movement of packet from one node to another depending on

14
 the way the network is designed. Link 2,3 supports a queue and figure shows the
building up of the queue when number of packets are increased.

• Simulation for different congestion control algorithm has been done and corre-
sponding congestion window and throughput are plotted.

• From the NS2 trace file results Reno is decided to be the best one for wired
network.

2.2.2 Wireless Simulation

In case of wireless simulation it is assumed that the nodes are mobile and can move
within a particular range.
For simulation of a simple wireless network:

• Network topology is decided first. As mentioned in wire network section along

with those parameters in case of wireless network position of each node has to
be represented in terms of coordinates to support mobility. Later, to provide
mobility new position of nodes are decided. This holds true for all the nodes.

• Simulation of the network is developed using TCL script.

• First channel type, radio propagation model, network interface type, MAC type,
interface queue type, link layer type, antenna model, maximum packet in queue,
number of mobile nodes, routing protocol are set.

• Then network rage is set in terms of dimension.

• Agent named GOD is created which provides mobility feature in the network. It
is the observer which stores number of nodes and their positions. The syntax for
the same is mentioned below. A procedure in the name create-god is created with

15
 nodes as the parameter. god is an inbuilt object of ns2 to support the above
mentioned features.
proc create-god { nodes } {
global ns god tracefd
The inbuilt object needs memory allocation for which the following line is executed
to make the god object active for the program.
set god [new God]
Then the god object needs to be attached to all the pre created nodes passed as
an argument to the function. Following line fulfils that purpose.
$god num nodes $nodes }

• Node configuration is done with initial position and mobility is set for every few
seconds with new position.

• Like-wired network agents and type of packets, starting and end time of simulation
is calculated.

• The same piece of code is written for generating trace files.

Simulations

• Simulation for simple network of 2 nodes is completed.

• Simulation for 50 nodes with mobility is completed. The screenshot for the same
is shown figure 3.

• The above screenshot represents the topology for 50 mobile nodes. The mobility of
nodes cannot be visualized because it is a screenshot. When simulation is done all
the nodes move from their positions and simultaneously transmit packets. Packet

16
 Figure 3: Nam visualization for wireless network

flow unlike wired network cannot be visualized here because the nodes are not
static.

• Simulation for different congestion control algorithm has been done and so also
throughput from trace file is analyzed.

• From the NS2 trace file results Westwood is decided to be the best one for wired
network[8].

2.2.3 Observation of accuracy of NS2 from simulated results

From the plotted congestion window graph for different congestion algorithm which
comes accurate to real time plots, it is concluded that NS2 has over 90% accuracy[9]
with real time scenario.
The simulation is done for a single flow (RTT=128ms, BW=100Mbps, buffer=220pkt)for
all type of congestion algorithms. Few among them which are relevant to our project

17
are displayed below.
Reno: The following graph represents how congestion window varies for Reno algo-
rithm with respect to time if there is congestion in the network.

Figure 4: Plot for Variation of congestion window vs time for RENO algorithm

Description:

• In the graph X-axis represents time and Y-axis represents variation in congestion
window which basically represents the no of packets per window.

• The graph shows how the number of packets increase and once congestion is
detected, it suddenly decreases to a specific threshold value.

• The simulation is carried out for 900 seconds and for every 0.5 second number
no of packets transmitted is measured. It can be seen from the graph for Reno

18
 that every moment the number of packets reaches nearly upto 1300 per sec it
suddenly drops to a value nearly to 700 packets/sec. Again it starts from that
point increases to touch that point and the same process is repeated.

Westwood: The following graph represents how congestion window varies for West-
wood algorithm with respect to time if there is congestion in the network. Description:

Figure 5: Plot for Variation of congestion window vs time for WESTWOOD algorithm

• In the graph X-axis represents time and Y-axis represents variation in congestion
window.

• The simulation is carried out for 900 seconds and for every 0.5 second number of
packets transmitted is measured. It can be seen from the graph that for Westwood,
when the number of packets reaches around 1300, it suddenly drops to a value of

19
 1100 packets.
Cubic: The following graph represents how congestion window varies for Cubic
algorithm with respect to time if there is congestion in the network. Description:

Figure 6: Plot for Variation of congestion window vs time for CUBIC algorithm

• In the graph X-axis represents time and Y-axis represents variation in congestion
window.

• In Cubic, the moment number of packets reaches 1300, the congestion window
drops to around 1050 packets window suddenly drops to a value nearly to 1050
packets.

• This happens because congestion window allows a maximum number of packets

after which it decreases to avoid congestion therefore allowing less number of

20
 packets.

It is clear from the graph that all three follow different methods for varying the window
because the shapes of the curve are different.

2.3 SAT-COM

The modeling of communication in an efficient way has been a standard requirement

for years within the communication systems world. Simulation and analysis are very
important to create satellite networks. For this very purpose, we have used Network
simulator (NS-2) which offers a solution where we can do simulation of a satellites net-
works, because it enables exact simulation with a detailed modeling of radio frequency
characteristics (interference, fading), protocol interactions (e.g., interactions of resid-
ual burst errors on the link with error checking codes) and second-order orbital effects
(precession, gravitational anomalies, etc.).
The key metrics for characterizing simulation scenarios are the end-to-end delay, bit
error rate, and average system throughput.

2.3.1 Description Of The Satellite Nodes

Types of satellite nodes:

• Geostationary

• Non-geostationary

• Terminal

There are basically 5 parameters which these satellites include: altitude (specified in
kilometers above the Earth’s surface), inclination (0 degrees to 180 degrees), longitude
of ascending node (-180 degrees to 180 degrees), alpha (define the initial position of

21
the satellite along the orbit, and has range from 0 degrees to 360 degrees) and plane
(depending on type of satellite network).

2.3.2 Simulation Of Iridium And Teledeisic Satellite Network

In our work, we made use of tcl (tool command language) script and simulated two of
the possible satellite network models: Iridium and Teledesic with the help of Network
Simulator. Here, we have basically taken Iridium and teledesic like satellite constella-
tion. We performed our simulation in 3 ways. Following is the description of these 3
satellites networks.
a) sat-aloha.tcl : Simple script with a geostationary bent-pipe (repeater) satellite and
one hundred terminals using unslotted (pure) Aloha random access. The traffic sources
consist of exponential on-off traffic generators unless indicated below. With the traffic
rates configured below, approximately one tenth of the packets collide and must be
retransmitted.
Tests:

1. basic: Mac operates in stop-and-wait mode (one outstanding packet at a time).

Collisions and drops are not traced. This test should provide similar results to
the satellite test suite.

2. basic tracing: Same as ’basic’, but drops (’d’) and collisions (’c’) are instead
explicitly traced. Again, similar to test suite

3. Poisson : Packets arrive according to Poisson process. Each source still operates
in stop-and-wait mode, and collisions and drops are traced. rtx limit == 0 (no
persistence).This can be used to try to approximate theoretical unslotted Aloha
results, if the number of terminals is large compared to the arrival rate (so that
no packets are queued)

22
Output Obtained - Type 1 Satellite

ptype Itime Sno Dno Traff Qlen Sno Dno lon lon lat lat
+ 2.6 33 83 exp 210-0 33.0 83.0 -5.10 5.10 9.90 -9.90
- 2.6 33 83 exp 210-0 33.0 83.0 -5.10 5.10 9.90 -9.90
+ 2.6 77 27 exp 210-0 77.1 27.1 8.10 -8.10 -6.90 6.90
- 2.6 77 27 exp 210-0 77.1 27.1 8.10 -8.10 -6.90 6.90

Table 1: Output for Type-1 satellite

b)sat-iridium.tcl : Example of a broadband LEO constellation with orbital configura-

tion similar to that of Iridium. The script sets up two terminals. The script illustrates
how the latency due to propagation delay changes depending on the satellite configu-
ration.
Output Obtained - Type 2 Satellite

ptype Itime Sno Dno Traff Qlen Sno Dno lon lon lat lat
+ 1.0 288 105 cbr 210-0 288.0 289 37.9 -122.3 44.7 -125.27
- 1.0 288 105 cbr 210-0 288.0 289 37.9 -122.3 44.7 -125.2
r 1.0 288 105 cbr 210-0 288.0 289 37.9 -122.3 44.7 -125.2
+ 1.0 105 153 cbr 210-0 288.0 289 44.7 -125.2 44.7 -95.2

Table 2: Output for Type-2 satellite

c)sat-teledesic.tcl: Example of a broadband LEO constellation with orbital configu-

ration similar to that of Teledesic’s 288 satellite configuration. The script sets up two
terminals and sends a packet. The script illustrates how the latency due to propagation
delay changes depending on the satellite configuration.
Output Obtained - Type 3 Satellite

All the tcl script are coded and subsequently executed. The output generated is a
”out.tr” file. Following is the description of the output file obtained.

23
 ptype Itime Sno Dno Traff Qlen Sno Dno lon lon lat lat
+ 1.0 66 26 cbr 210-0 66.0 67.0 37.9 -122.3 48.9 -120.9
- 1.0 66 26 cbr 210-0 66.0 67.0 37.9 -122.3 48.9 -120.9
r 1.0 66 26 cbr 210-0 66.0 67.0 37.9 -122.3 48.9 -120.9
+ 1.0 26 37 cbr 210-0 66.0 67.0 48.9 -120.9 32.6 -87.5

Table 3: Output for Type-3 satellite

Description of the output:

Where:
ptype = operation on packet
Itime = Time at simulation starts
Sno = Source node
Dno = Destination node
Traff = Type of traffic whether cbr or exp
Qlen = The lengthe of queue
lon = Longitude
lat = Lattitude
As an output of simulation is a text file, where single nodes with their positions, links
and delays are described. These delays rise during transmission of a packet. The terms
in the output of sat-teledesic.tcl is explained. Here receive event is indicated by ’r’,
’+’ means ”enque” operation, ’-’ ”deque” operation. The letter ’d’ describes a dropped
packet. The second column shows time from the beginning of the simulation. Next
column represents the number of nodes; the links between these nodes are created.
From the example we can see, node 66 receives packet from node 26. In this simulation,
length of the queue is decreased to ensure that a drop event will occur. CBR describes
the traffic. 66 and 67 are the source and destination terminals respectively. Also other
nodes generate traffic at the same time and the next column describes the number of
scripts. We simulated two of possible satellite packets transmitted from the terminal

24
66 and the second shows how many packets were transmitted through the network to
the current time. Next is the longitude and latitude of the source and destination. Also
it is possible to create our own error model. One of them is used in this experiment.
Basically error models can be set to cause packets to be errored according to various
probability distributions.

2.3.3 Conclusions

We created a text file as output. From the results we are now able to determine delays
between two terminals. Disadvantage of NS-2 is that it is impossible to create NAM file
for satellite networks which always can be generated as a graphical output for classical
wired network. We overcame this by using ns-sat-plot program.

2.4 Implementation

The dependency to be installed for our implementation is Vnstat v1.2 or higher. Ini-
tially, all the network interfaces available in the system are listed. This is done through
issue of system calls and retrieval of network hardware information. The code is de-
signed to capture interfaces of virtual operating systems installed on the machine.

System commands are used to retrieve the hardware interfaces available in the sys-
tem. Vnstat is a console based network traffic monitoring tool. It keeps a log of hourly,
daily and monthly network traffic for the selected interface(s). However, it isn’t a packet
sniffer. The traffic information is analyzed from the proc and sys file systems depending
on availability. Our module uses this tool to measure the traffic on each interface.

In the next part, the above listed interfaces will be monitored in a round robin fashion.
During monitoring, the network traffic on the interface being monitored is observed in

25
real time. An interface is considered active and in use if it has live traffic i.e. trans-
reception of packets.

The logical name of this interface is mapped to its hardware type to determine the
type of network. The look up table has the congestion control algorithm to be set for
different interfaces. This data is used to choose the appropriate algorithm to be set.
The chosen algorithm is then set as the system’s current control algorithm using system
control commands.

The program continuously monitors the interfaces and the above mentioned process
is repeated when a change in the active interface is detected.

3 Testing and Experimental Results

In computer networking, an Internet socket or network socket is an endpoint of a bidi-

rectional inter-process communication flow across an Internet Protocol-based computer
network, such as the Internet. A socket address is the combination of an IP address
(the location of the computer) and a port (which is mapped to the application program
process) into a single identity, much like one end of a telephone connection is the com-
bination of a phone number and a particular extension.

When the user changes the interface, a new IP on a different subnet is assigned to
the network interface. As the IP address changes, the old socket can no longer be used
and the application has to re-send the requests to the server to receive data, i.e. the
server isn’t aware of the change in socket and the application can’t receive data unless
it sends the new socket number along with the request to the server. Hence it isn’t pos-

26
sible to measure the packet loss or delay while the switching takes place. Our module
detects the interface change and sets the appropriate congestion algorithm. Therefore
the performance analysis of the system is measured in terms of the congestion algorithm
set by our module for the active interface in comparison with the default algorithm.
This section gives the performance analysis report based on the experiments done using
IPERF and BMON. It includes information about the throughput for a particular time
duration for various TCP algorithms. This gives a comparison between the default
algorithm for Linux, i.e. ”Cubic” and the algorithms which are used for the project
(Westwood and Reno). For this, IPERF, which is a network testing tool that can cre-
ate TCP data streams, is used and the throughput is obtained for wired and wireless
networks after executing the program. This is compared with the throughput which is
obtained without executing the program. The results are shown below:

Wired network:
Before executing the program: (Default algorithm - Cubic)
The average throughput and RTT values are calculated. The results obtained are as
shown below.
Average throughput obtained is 1076835 KBytes/sec.
Round-Trip-Time, min/avg/max = 0.275/0.328/0.638 ms

The graph below shows the Time vs Bandwidth plot for Cubic algorithm. For a
time interval of 15sec, the bandwidth is calculated and plotted. The average of these
values is observed as 1076835Kbytes/sec.
After executing the program: (Algorithm - Reno)
The average throughput and RTT values are calculated. The results obtained are as
shown below.

27
 Figure 7: Time vs Bandwidth plot for wired (cubic)

Average throughput obtained is 1096327 KBytes/sec.

Round-Trip-Time, min/avg/max = 0.283/0.324/0.092 ms
The graph below shows the Time vs Bandwidth plot for Reno algorithm. For a time

Figure 8: Time vs Bandwidth plot for wired (Reno)

interval of 15sec, the bandwidth is calculated and plotted. The average of these values
is observed as 1096327Kbytes/sec.

28
For wireless network:
Before executing the program: (Default algorithm - Cubic)
The average throughput and RTT values are calculated. The results obtained are as
shown below.
Average throughput obtained is 581333 KBytes/sec.
Round-Trip-Time, min/avg/max = 0.121/0.239/0.240 ms
The graph below shows the Time vs Bandwidth plot for Cubic algorithm. For a time

Figure 9: Time vs Bandwidth plot for wireless (Cubic)

interval of 15sec, the bandwidth is calculated and plotted. The average of these values
is been observed as 581333Kbytes/sec.
After executing the program: (Algorithm - Westwood)
The average throughput and RTT values are calculated. The results obtained are as
shown below.
Average throughput obtained is 857706 KBytes/sec.
Round-Trip-Time, min/avg/max = 0.183/0.224/0.229 ms
The graph below shows the Time vs Bandwidth plot for Westwood algorithm. For a
time interval of 15sec, the bandwidth is calculated and plotted. The average of these

29
 Figure 10: Time vs Bandwidth plot for wireless (Westwood)

values is observed as 857706Kbytes/sec.

Analysis from the experiments conducted:
According to the results obtained, it can be seen that the average throughput obtained
for wired network using Reno is better than Cubic. Similarly, the average throughput
obtained for wireless network using Westwood is better than Cubic. Observing the
Round-Trip-Time, average RTT for Cubic and Reno in case of wired network is almost
the same. In case of wireless network, RTT for Westwood is less as compared to Cubic.
These results compare the performance of the networks with and without using the
program. From these observations it can be concluded that, changing TCP congestion
control algorithms on the fly improves the performance of the network.

4 Conclusion

Our goal is to change the TCP congestion control algorithm on the fly. We have im-
plemented a system which monitors the network interfaces available on the system and
detects the network interface currently in use. It then refers the lookup table for the

30
congestion control algorithm best suited for the active interface, and changes it auto-
matically without user intervention and without the need for a system reboot. With
implementation of this the biggest problem of common use of a particular algorithm
for all kind of connection can be avoided. Now if wireless is connected the network
congestion algorithm is set to be Westwood which is best for wireless. Similarly for
wired connection Reno can solve the purpose. If Sat-Comm is detected Cubic should
be connected further taking care of long RTTs not to be misinterpreted as congestion
in the network. On the whole, this improves the system performance by giving user
a scope to utilize the range of TCP congestion algorithm as required. The algorithms
which have been chosen so far are decided from simulation results of NS2. If user
wants to set some different algorithm according to his/her requirement, the mapping
in look-up table is to be changed which is not tough to accomplish, hence it provides
flexibility. Finally it is always better to utilize the available resources according to
one’s requirement rather than just following a pre-used prototype. It is concluded that
changing TCP variants on the fly enriches the user with a facility to utilize the features
of TCP-Linux Algorithms providing better performance.

31
References

[1] S. Jaiswal, S. Trivedi, R. Kumar, and S. Rao, “Comparative performance evaluation

of tcp hybla and tcp cubic for satellite communication under low error conditions,”
in 4th IEEE International Conference on Internet Multimedia Systems Architecture
and Application (IMSAA-2010), Bangalore, Dec. 2010.

[2] R. Wang, M. Valla, M. Sanadidi, B. Ng, and M. Gerla, “Efficiency/friendliness trade-

offs of tcp,” in Computers and Communications, 2002. Proceedings. ISCC 2002.
Seventh International Symposium on, 2002, pp. 304 – 311.

[3] W. Bao, V. Wong, and V. Leung, “A model for steady state throughput of tcp
cubic,” in GLOBECOM 2010, 2010 IEEE Global Telecommunications Conference,
Dec. 2010, pp. 1 –6.

[4] X. Wu, M. C. Chan, and A. Ananda, “Effects of applying high-speed congestion

control algorithms in satellite network,” in Communications, 2008. ICC ’08. IEEE
International Conference on, May 2008, pp. 1925 –1929.

[5] C. Caini, R. Firrincieli, D. Lacamera, T. De Cola, M. Marchese, C. Marcondes,

M. Sanadidi, and M. Gerla, “Tcp live experiments on a real geo satellite testbed,”
in Computers and Communications, 2007. ISCC 2007. 12th IEEE Symposium on,
July 2007, pp. 523 –529.

[6] L. Grieco, S. Mascolo, and E. Di Sciascio, “A mathematical model for the steady
state throughput of the westwood tcp congestion control algorithm,” in Informa-
tion Technology Interfaces, 2002. ITI 2002. Proceedings of the 24th International
Conference on, 2002, pp. 487 – 492 vol.1.

32
[7] B. Sikdar, S. Kalyanaraman, and K. Vastola, “Tcp reno with random losses: latency,
throughput and sensitivity analysis,” in Performance, Computing, and Communi-
cations, 2001. IEEE International Conference on., Apr. 2001, pp. 188 –195.

[8] I. Al-Mejibli and M. Colley, “Evaluating transmission time of service discovery pro-
tocols by using ns2 simulator,” in Wireless Advanced (WiAD), 2010 6th Conference
on, June 2010, pp. 1 –6.

[9] M. Bateman and S. Bhatti, “Tcp testing: How well does ns2 match reality?” in
Advanced Information Networking and Applications (AINA), 2010 24th IEEE In-
ternational Conference on, Apr. 2010, pp. 276 –284.

33