CHAPTER 1

INTRODUCTION

Nowadays wireless communication deployment is widely growth. From the beginning,

wireless communication have developed good element in modern society. Staring from

communication network in telegraph invention to telephone, followed by radio

transmission and the exponential growth of radio transmission, the quality of the data

transmission has been improved [7]. The communication has become cheaper and

simple. The devices enable private, public communication and wireless networking.

As to ensure the quality of the data transmission, an efficient protocol with is

named as Transmission Control Protocol (TCP) is introduced. TCP is widely used in the

transport layer in wired network. However in recent years,. TCP is implemented in

wireless link because of the highly demands attention. This is because of the

importance of supporting application over wireless communication like laptops,PDAs,

and others.

1
 TCP (Transmission Control Protocol) is a set of rules (protocol) used along with

the Internet Protocol (IP) to send data in the form of message units between computers

over the Internet. While IP takes care of handling the actual delivery of the data, TCP

takes care of keeping track of the individual units of data that a message is divided into

for efficient routing through the Internet. TCP is known as a connection-oriented

protocol, which means that a connection is established and maintained until such time as

the message or messages has been exchange. TCP is responsible for ensuring that a

message is divided into the packets. TCP manages and reassembles the packets back

into the complete message at the other end. TCP is usually used in wired network, but

nowaday TCP has been implemented in wireless network.

TCP is known of its reliability, congestion control, and connection management

and also flow control in their service, that are needed in wireless communicsation. Most

of the internet applications use TCP as its underlying transport layer protocol for reliable

data transfer. It is a very urgent need of a reliable data transfer protocol for wireless

network as wireless users growth is increasing tremendously [17].

1.1 Research Motivation

TCP is widely used in wired link. In recent years, wireless link also uses TCP for

supporting application over wireless. But TCP is inefficient in wireless network

because of longer delay and then causes packet losses. Packets may incur random loss

due to transient congestion caused by fluctuations in real-time traffic. Packet losses

over wireless links reduce TCP data transfer speed. Moreover, TCP with complete

design only focuses on the properties of wired network that is performing very poorly in

wireless networks. This is because wireless network has a very different characteristics

than wired which causes TCP is inefficient over the heterogeneous environment in both

2
of network links. Addionally, TCP also causes congestion network in wireless network.

This is because when several networks transmit over the wireless link, there may be a

collision in wireless link. Therefore, network congestion may occur during the

transmission.

1.2 Research objectives

The aim of this research is to investigate the performance evaluation of TCP over

wireless communication with different TCPs. Objectives of this research are:

1. To investigate the performance of TCP in wireless environment.

2. To conduct simulation experiment of various TCPs in wireless environment
3. To compare the results of different TCPs in wirelss communication.

1.3 Significance of the Research

Major contributon of this research are:

Investigation of different wireless TCPs can help to

understand the improvement of such variants on the TCP

performance over wireless networks.

Conducting the simulation experiment shows us the

compatibility of TCP in wireless link and performance

evaluation to the TCPs show us the behaviors of TCPs in

wireless communication.

The comparative of different TCPs that we have studied show us which

TCP have better potential usage for wireless communication.

1.4 Scope of Research

3
In this research, we are specifically studying the performance evaluation of TCPs in

wireless communication. The project focuses mainly on TCP Tahoe, TCP

Reno, TCP Newreno, TCP Vegas and TCP Sack as the different TCPs

over the wireless environment. We study about the performance of the TCPs

and the behaviour between the TCPs in wireless link. Then, we conduct simulation

experiment to investigate the TCP performance. A simulation using Network

Simulator 2 (ns-2) is carried out on these three TCPs by sending FTP

packets over TCP protocol. An analysis study of the results is carried

out to investigate the effectiveness of each protocol when it is

implemented on wireless environment.

1.5 Thesis overview

This research presents our work in the performance evaluation of TCP Tahoe, TCP

Newreno, Sack, Reno and Vegas in wireless communication. We evaluate TCPs

performance in aspect of efficiency, delay and also congestion network in wireless link.

Chapter 2 review the background and related work on all major research issues

covered in this thesis. First, we overview the section discussed in chapter 2 . After that,

we discuss the detail about the TCP operation, congestion control, connection

management, and also flow control.

Chapter 3 presents the methodology of the research. It is started from the

installation of Linux operating system (Fedora 12) and the installation of simulation tool

network simualator 2.30. Then, we discuss about the development of designed topology

using TCL language. The protocol is modified under ns-2 according to our proposed

network model. We also discussed detail about the validation stage, testing and

4
simulation experiment. Description of awk code is also discussed to extract the useful

information from the simulation experiment for further analysis.

Chapter 4 presents the analysis of the data from the simulation. The data are

presented into graphs and tables. From the graphs and tables, we analyse the

performance evaluation of TCP in wireless communication. The comparative analysis is

discussed in this chapter.

Chapter 5 concludes the study and we present the final

discussion and findings in this chapter. The limitations that are faced

in this project is stated in this chapter. Finally some recommendations

and future work that can be suggested is presented the project.

5
 CHAPTER 2

BACKGROUND AND RELATED WORKS

2.1 Introduction

This research focuses on the performance evaluation of TCP Tahoe, Newreno, Sack,

Reno and Vegas in wireless communication. In this chapter, background and issues to

be covered in this chapter are presented. In section 2.2, we present the terminology of

the research area. Section 2.2.1 describes about transmission control protocol (TCP) and

sestion 2.2.2 we describes about TCP overview. In addition, Section 2.2.3 and Section

2.2.3 present about TCP operation and TCP congestion control algorithms. Section

2.2.4 discusses about TCP variants and last section 2.2.5 we describe about TCP in

6
wireless communication. Related work will be presented in section 2.3 and we

conclude this chapter in section 2.4

2.2. Background Study

2.2.1 Transmission Control Protocol

Over the past several years, Transmission control protocol (TCP) is the most used

transport protocol all over the world [12, 13]. It is the basic transport protocol for

Internet. TCP provides data transmission between computers with connection oriented,

reliable, in sequence,byte stream service [8]. TCP also provides flow data control on an

end-to-end basis and also for error recovery. By the services provided, TCP can deal

with the problems such as due to lost, delayed and misdelivered packet during

transmission. There are also several mechanisms provided by TCP that can reduce the

rate of data that are transmitted when network congestion is detected. Applications

provided by TCP are file transfer protocol (FTP) for file transfer, hyper text transfer

protocol (HTTP) for web service and real-time protocol (RTP) for real-time transfer

such as video. TCP provides a connection setup for client . Figure 2.1 below shows the

TCP overview.

Application Application
Byte stream byte stream
------------------ Segments ----------------------------

Transmitter receiver

Send buffer receive buffer

ACKs
Figure 2.1:TCP overview

7
 Having understood the principle of TCP, in the following subsection, we are

presenting the TCP operation. TCP overview discusses how the TCP operation.

2.2.2 TCP overview

TCP (Transmission Control Protocol) is a set of protocol used along with the

Internet Protocol (IP) to send data in the form of message units between computers over

the internet. IP takes care of handling the actual delivery of the data and TCP takes care

of keeping track of the individual units of data (called packets) for efficient routing

through the Internet. TCP is known as a connection-oriented protocol, which means that

a connection is established and maintained until such time as the message received at

the receiving end. TCP is responsible for ensuring that a message is broken into

packets, manages and reassemble the packets back into the complete message at the

other end. TCP is usually used in wired network, but nowaday TCP has been

implemented in wireless communication network.

2.2.3 TCP Operation

There are three phases of TCP operation as follows:

i. Connection establishment phase

ii. Data transfer phase
iii. Termination of connection phase

In the first phase, TCP establishes a connection between two applications by creating

and initializing variables that are used in the protocol. TCP uses a three-way

8
handshaking procedure to setup a connection. TCP synchronizes both ends of a

connection by enabling both sides to agree upon initial sequence numbers.

Figure 2.2: TCP connection establishment

In second phase, TCP will starts to transmit ordered data transfer to the

destination host that rearranges according to sequence number. TCP alsp make a

retransmission of lost packets which any cumulative stream not acknowledged will be

retransmitted. When duplicate packets occur during transmission, TCP will discard the

packets using sequence number.

In third phase, after transmission finished, each directions of the connection will

be terminated independently.

There are several of TCP operations. Flow control: one of the TCP operations.

Besides, other TCP operations are congestion control which introduces a congestion

window (CWND), in addition to flow control window (WND).

9
2.2.3.1 Flow control

Flow control operation allows receiver to control the rate at which the sender

transmit information. TCP inherently supports flow control to prevent buffer overflow at

the receiver. In flow control, receiver advertises a window (WND) in

acknowledgements returned to the sender. Sender cannot send more than WND

unacknowledged bytes to the receiver. Flow control is useful for fast sender transmitting

to slower receiver.

Src Dest
Limits amount of data that
destination buffer

Sender Receiver
Wnd=1200
500 bytes
500 bytes
Wnd = 200
200 bytes
Wnd = 500
500 bytes

Figure 2.3: TCP Flow Control Example

Following a series of congestion collapses starting late of 1986, Jacobson and

Karels developed a congestion control mechanism, named TCP Tahoe [14]. Since then,

many modifications have been made to the TCP and several different versions of TCP

have been implemented [14, 15]. The several versions of TCP are discussed in the next

section.

10
2.2.4 TCP congestion control algorithms
Congestion control algorithms are provided by TCP is to ensure the rate of data

entering the network is below of certain rate that would trigger network congestion.

There are 4 intertwined mechanisme in congestion control algorithms. There are slow-

start, fast retransmit, fast recovery and congestion avoidance. All these congestion

control algorithm use Additive Increase/Multiplicative-Decrease (AIMD) paradigm,

which additively increases the cwnd to grab the available bandwidth and decrease the

cwnd when network capacity is hit and congestion is caused of segment losses [20].

2.2.4.1 Slow-Start mechanisme

Slow-start mechanisme is used in the beginning of transfer or if when the algorithm

restart after recovery from segment loss [8]. TCP Slow start is implemented using two

variables, CWND and ssthresh (Slow Start Threshold). In slow-start phase, the

congestion window is initialized to a small value (usually 1 MSS). The sender starts by

transmitting one segment and waiting for its ACK. When that ACK is received before

time-out, the congestion window is incremented to one segment. Then sender send two

segments and when each of those two segments is acknowledged, the congestion

window is increased to four and so on. This provides an exponential growth of

congestion window. At some point the capacity of the internet can be reached, and an

intermediate router will start discarding packets. This tells the sender that its CWND too

large enough. When the CWND exceed the ssthresh, the slow start phase will end.

Then, the slow-start mechanisme hands over the CWND control to the congestion

avoidance algorithm.

2.2.4.2 Congestion Avoidance Algorithm

11
 Congestion can occur when data arrives on a big pipe (a fast LAN) and sent to a

smaller pipe (a slower WAN). Congestion can also occur when multiple input streams

arrive at a router (bottleneck) whose output capacity is less than the total of the inputs.

Congestion avoidance is a way to deal with lost packets. The loss of a packet signals

congestion somewhere in the network between the source and destination. There are two

indications of packet loss: a timeout occurring and the receipt of duplicate ACKs. When

congestion occurs TCP must slow down its transmission rate of packets into the

network, and then invoke slow-start mechanisme to get things going again. In practice

they are implemented together. As slow-start, congestion avoidance also require two

variables be maintained for each connection: a congestion window (CWND) and a slow

start threshold size,(ssthresh). The combined algorithm operates firstly sets CWND to

one segment and ssthresh to 65535 bytes. When congestion occurs, it reduces CWND

and one-half of the current window size is saved in ssthresh. After reducing CWND,

TCP goes back to slow-start phase. Congestion avoidance dictates that CWND be

incremented by segsize*segsize/cwnd each time an ACK is received, where segsize is

the segment size and CWND is maintained in bytes. The increase in CWND should be

at most one segment each round-trip time. This is a linear growth of CWND, compared

to slow-start's exponential growth. Figure 2.4 below shows the dynamic of TCP

congestion window in slow-start and congestion avoidance phase [30].

12
 Figure 2.4 : Dynamics of TCP congestion window in slow-start and congestion

avoidance.

2.2.4.2 Fast Retransmit

In fast retransmit mechanism, TCP receiver generate three duplicate ACKs

(dupacks) when segment losses. The purpose of this dupacks is to let the sender know

that a segment was lost. Then sender performs a retransmission of what appears to be

the missing segment, without waiting for a retransmission timer to expire. Figure 2.5

shows fast retransmit phase [30].

Figure 2.5 : Fast Retransmit phase

2.2.4.3 Fast recovery

13
 Fast recovery works hand in hand with fast retransmit. This mechanism allow

TCP to detect and recover from segment drops more effectively than relying on the

retransmission timer. When the third duplicate ACK is received, TCP set ssthresh to

one-half the current congestion window. Then, sender retransmit the missing segment.

Set CWND to ssthresh plus 3 times the segment size. After that, sender continue in

congestion avoidance phase. All of the TCP mechanism we discussed are used in TCP

variants like Sack, Vegas,Reno and many kinds of other TCP variants. the figure below

show fast recovery phase [30].

Figure 2.6: Fast Recovery phase

2.2.5 TCP variants

There are many variants in TCP, such as TCP Sack, Reno, Vegas, Tahoe, Hybla, BIC,

CUBIC and many more. In this research we propose to investigate about TCP Tahoe,

Reno, Newreno, Selective acknowledgement(SACK) and TCP Vegas. All the TCP we

propose to investigate, implement congestion control algorithms we have discussed in

section 2.2.4.

2.2.5.1 TCP Tahoe

TCP Tahoe as an early version of TCP included slow-start, congestion avoidance and

fast retransmit in the congestion control. Tahoe refers to the TCP congestion control

algorithm which was suggested by Van Jacobson in his paper [14]. The refinements of

14
the original TCP version include a modification to the RTT estimator used to read just

retransmission timeout values. The problem of TCP Tahoe is that slow-start is not

always efficient, especially if the error was random in nature. In such a case the massive

shrinkage of the congestion window is unnecessary. TCP is in such a situation unable to

fully utilize the available bandwidth of the radio channel during the phase of window re-

expansion. For congestion avoidance, Tahoe uses Additive Increase Multiplicative

Decrease. A packet loss is taken as a sign of congestion. Then TCP Tahoe saves the

half of the CWND as a threshold value. It then set CWND to one and restart slow-start

until it reaches the threshold value. After that it increments linearly until it encounters a

packet loss and TCP will increase window slowly as it approaches the bandwidth

capacity.

2.2.5.2 TCP Reno.

TCP Reno is a TCP variant which use slow-start, congestion avoidance, fast

retransmit and fast recovery. It retains the basic principle of tahoe like slow-start and

congestion avoidance but it adds some modification of fast retransmit and fast recovery.

In fast retransmit, the congestion window isnt reduce but there will be 3 duplicate

ACK(dupacks) sending to the sender. It is mean the segment was lost or reached out of

order. Then the sender retransmit the segment without waiting for transmission time-

out For fast recovery phase, the sender retransmit one segment and set the congestion

threshold to half current congestion window (cwnd) and set the CWND at same value.

The CWND will be incremented by one when each dupacks received. The fast recovery

phase is completed when an acknowledgement for new data is received.

2.2.5.3 TCP Newreno

TCP Newreno is a modification over TCP Reno. Newreno also enter Fast-retransmit

when it receives duplicate packets. But the implementation of fast retransmit because it

doesnt exit fast-recovery until all the outstanding data is acknowledged. Thus, it

15
overcome the problem faced by Reno of reducing thecwnd multiple times. The fast

retranmsit phase implementation same like Reno. The different in fast recovery in

Newreno is TCP allow for multiple re-transmission [21].

2.2.5.4 TCP Selective Acknowledgement(Sack)

TCP with selective acknowledgements is an extention of Reno. It also works around

Reno in detection multiple lost packets, retransmit of more than one packet per RTT in

congestion control algorithms. Sack also retains the Renos slow-start and fast recovery

but there are some modification of segment acknowledgement which is acknowledged

selectively. TCP Sack uses a Sack option field containing a number of Sack blocks.

Each of Sack block reports a contiguous set of data that has been received and queued

[19]. Sack blocks tell the sender which segments are being acknowledged. The sender

initializes a variable pipe which estimate how much the is outstanding when in fast

recovery phase. The pipe will be decreased by 1 for each ACK received and is

incremented when retransmit the segment. The pipe become a signal when it smaller

than cwnd, TCP Sack will check for the outstanding data and retransmit the data again.
The main difference between the TCP Sack and TCP Reno implementation is in

the behavior when multiple packets are lost from one window of data. Reno cannot deal

with the losses of multiple packet in one RTT but Sack can transmits multiple packet

losses per RTT. The other one of TCP variant we propose to investigate in this research

is TCP Vegas.

2.2.5.5 TCP Vegas

TCP Vegas is proposed by Brakmo and Peterson [5]. TCP Vegas also retains the basic of

congestion control algorithm based on some modification source of Reno. Vegas have

modified retransmission mechanism, congestion avoidance mechanisme and also slow

start mechanism. In retransmission mechanisme, Vegas no need to wait for 3 dupacks

from the receiver or time-out to send the lost segment. Additionally, the congestion

avoidance mechanisme is totally different from other TCP variants. Vegas use rate to

16
signal the congestion by decreasing rate by compared to the expected rate. When the

calculated rate is different with the expected one, it increasess the tranmissions and

instead if the rate is close to expected rate. In slow-start mechanisme implementation,

Vegas increases exponentially in other RTT.

2.2.5.6 Evolvement of TCP

Following the evolvement of TCP, there are a lot of different TCP versions. Considering

the importance that TCP performs, we think it is profitable to have a close look of the
difference of some important TCP versions. More importantly, from previous research

papers, we hear different voice about the performance of Tahoe, Reno, Newreno, SACK

and Vegas TCP at different scenarios [26], [27]. We are trying to find out the truth of the

performance by further investigation and performance. We hopefully we can finally get

the comprehensive understanding of these different TCPs performances under different

scenarios. Table 2.1 below show evolvement of TCP.

Table 2.1 :Evolvement of TCP

TCP Version Difference

Tahoe Added slow-start & Fast retransmit
Reno Based on Tahoe, added Fast Recovery
Newreno Based on Reno,modification of Fast retransmit
SACK Based on Reno, added SACK(Selective ACK)
Vegas Based on Reno,New Re-transmission mechanism,Congestion
avoidance and modified slow-start

2.2.6 Wireless communication

In Wireless communications book [12] notice the wireless communication is a

rapidly growing segment of the communications industry, with the potential to provide

high-speed and high-quality information exchange between portable devices located

anywhere in the world. Potential applications enabled by this technology include

17
multimedia Internet-enabled cell phones, smart homes and appliances, automated

highway systems and others.

Wireless history starting from invention of telegraph network in 1838 by Samuel

Morse, followed by in 1895, the first radio transmissionby Marconi. After that the

radio communication exists and the radio technology advanced rapidly to enable

transmission with better improvement like quality then an improvement of radio

improvement by transmit digital signal. The existing of network based on packet radio

was developed by ALOHANET (1971) for communication using radio transmission,

followed by communication for battlefield and commercial application in wide area

wireless data services. These services are introduced in 1990s, which enabling such as

file transfer services, web browsing etc. Nowadays, we are preferred to use wireless

LAN as Internet access method because of the convenience and freedom from wires.

Moreover, wireless communication exponentially growth and rapidly replace wired link

widely in our modern society.

The performance of wireless communication is better today. There are many

kinds of wireless technology such as Wireless local area networks, cellular wireless,

Satellites and others. Moreover, TCP also is used in wireless communication because of

better services provided for wireless application compared to UDP.

2.2.6 TCP in Wireless communication

The Transmission Control Protocol (TCP) provides a reliable, connection-oriented, byte

stream, point-to-point transport layer service [8]. It has been the dominant and most

thoroughly tested reliable transport layer protocol ever. Nowadays around 90% of the

Internet traffic uses TCP as its transport layer protocol [9]. In recent years, TCP is also

18
widely implemented for wireless communication. Because of reliability services of TCP,

many of wireless technology have chosen TCP for their application. But TCP

performance is not working fine in wireless network by facing of longer delay and

packet losses. Thus, will causes congestion network in wireless communication and

effect the performance of TCP.

2.3 Related works

Sally Floyd et al.[1] said in their article Simulation-based Comparisons of Tahoe,

Reno,and SACK TCP when the implementation without TCP Selective

acknowledgement, the transmission of packet is at most one dropped packet per RTT or

they transmit other packet until the transmission of previous packet is completed after

time-out. Based on this previous research by Floyd and Kevin Fall, we make a further

investigation to explore the benefit of TCP Sack.

Jeonghoon Mo et al.[2] in their article Analysis and Comparison of TCP Reno and

Vegas, they have proposed some improvement of Vegas and made comparison with

TCP Reno. Through their analysis and detailed comparison, they have observed that

Vegas is more fair than TCP Reno. Besides, Vegas use the network resources efficiently

than Reno. Additionally, the modification of the mechanisme used by Vegas, they

observed Vegass performance is better than Reno. Therefore, we have proposed to

make further investigation through simulation experiment based on the their

performance on previous research.

Upkar Varshney [3] said in his article Selective Slow Start: A simple algorithm for

improving TCP performance in wireless ATM network said mobile computing has

19
emerged as an area of significant research and development activities.. However, the

problem with existing versions of TCP is lack of differentiation between segment loss

due to the network congestion and due to the handoff in wireless network. After a

segment loss, TCP would initiate a slow start phase to reduce its offered traffic assuming

that the network is going through congestion. This may reduce the TCP throughput

significantly and will lead to unacceptable performance specially if underlying wireless

ATM network is capable of supporting high data rates. This paper proposes a new

algorithm called Selective Slow Start, where TCP will attempt to differentiate between

segment losses due to the network congestion and due to the handoffs based on the

pattern of losses (timeouts). We make investigation and research by simulation and

implementation to observe the effectiness of Selective Slow Start algorithm.

Christina Parsa et al.[4] in their paperImproving TCP performance over wireless

networks at the link layer said the transport unaware link improvement protocol

(TULIP), improves the performance of TCP over lossy wireless links, without

competing with or modifying the transport- or network-layer protocols. TULIPs timers

rely on a maximum propagation delay over the link, rather than performing a round-trip

time estimate of the channel delay. TULIP is exceptionally robust when bit error rates

are high which it maintains high goodput. The performance of TULIP is compared

against the performance of the Snoop protocol (a TCP-aware approach) and TCP

without link-level retransmission support. The results of simulation experiments using

the actual code of the Snoop protocol show that TULIP achieves higher throughput,

lower packet delay, and smaller delay variance. So we have decided to investigate TCP

performance over wireless in this research.

20
S . Brakmo et al.[5] said in their paper TCP Vegas: New Techniques

for congestion detection and avoidance throughput of Vegas

achieve 40% - 70% in their implementation mechanisme compared to

Reno. In their paper, they describe three techniques of Vegas during

simulation experiment: timely decision to retransmit drop packet,

ability to anticipate congestion and modification of slow start. So

based on this research by Brakmo, we make further extension

research and investigate Vegas behaviour and performance by some

simulation experiments.

Hari Balakrishnan et al. [6] in his article A Comparison of Mechanisms for Improving

TCP Performance over Wireless Links said networks with wireless and other lossy

links also suffer from significant losses due to bit errors and handoffs. TCP responds to

all losses by invoking congestion control and avoidance algorithms, resulting in

degraded end-to-end performance in wireless and lossy systems. They made some

comparison to improve the performance of TCP by several schemes designed and they

classify those schemes into three categories and present the result of the schemes using

throughput and goodput. The result showed the performance of TCP is good without

splitting the end-to-end connection at the base station and explicit loss notifications

result in significant performance improvements. Based on their article, we make a

research to investigate the TCP performance in wireless link.

2.4 Conclusion

In this chapter we have discussed about TCP overview and related work from previous

research. In this chapter we have presented the TCP over wireless communication and

21
TCP variants as Tahoe, Newreno, Sack, Vegas, and Reno. TCP have been improved over

the years in wired network and now TCP is used in wireless communication. With

investigation and conducting simulation experiment of TCP variants in our proposed

network topology, we present performance evaluation of the behavior of TCP in

wireless link.

22
 CHAPTER 3

METHODOLOGY

3.1 Introduction

In this chapter, we are presenting the methodology of our research. Figure 3.1

below shows the phases of research that we have been carried out throughout our

research.

In this research, we propose to perform simulation experiment as one of the

performance evaluation techniques. For the simulation technique, we use network

simulator version 2.30 (ns-2) for simulation tool. For the operating system, we use

Fedora 12 Operating system. It is easier to use and compatible for the simulation tool

ns-2 that we use.

23
 Design network
topology

Develop Algorithm

Validation

Testing and
simulation

Analysis

Discussion

Figure 3.1 Research phases

In the first phase of simulation experiment, we design the proposed network

topology. In our research, we aim to evaluate performance of TCPs in wireless

communication. We also want to evaluate the behavior of TCPs in wireless

communication. Thus, we study the mechanisme of various models of TCP variants that

have been proposed by other research before. Then, we proposed our network topology

based on TCP variants we have chosen.

24
 After creating the proposed topology, we write code for the design in TCL

language using network simulator tool. All the parameters setting in the designed model

require justification to ensure the designed network topology represent the real network

situation.

Then, we develop algorithm to our proposed network topology. After that, the

developed network model undergoes the simulation experiment. The developed network

model have to validate to verify that the designed network model represent the real

network simulation. After that, we run the simulation. The output of simulation

experiment is raw trace file which require further analysis. Awk code is use to analyse

the raw trace file and extract the useful data from the raw trace file. The useful data is

presented into graphs and tables. We are using gnuplot for graph tool.

Before we start simulation experiment, we install fedora operating system and

network simulator 2 (ns-2). We present the installation of fedora operating system in the

section 3.2 . Then, we present the ways of installing ns-2 in fedora operating system.

3.2 Fedora and ns-2 Installation

3.2.1 Fedora Installation

Table 3.1 below shows the details of ways of installation of fedora operating system.

The version of fedora that we have installed are Fedora 12. We use this operating system

because it is easier to use and compatible with ns-2 simulator tool.

Having studied ways of installing fedora 12, in the following subsection, we

show the ways of installing ns-2 on the fedora 12 operating system.

25
 Table 3.1 : Fedora Installation

Select the 'Skip' option and press the Enter

Click 'Next'... Choose language.

Choose keyboard layout. click the 'Yes' button.

Setup network. Click OK once you've

finished. Select the 'manually' option.
Optional, you can setup the system's

26
hostname. Enter your Gateway and
Primary/Secondary DNS servers

Click 'Next' and select location Click next and enter the root (System
Administrator) password.

Click the 'Write changes to disk' button The hard drive will be formatted and the
partitions will be created.

27
select the desired packages

Hit the 'Next' button Click the 'Reboot' button and your computer
will automatically restart...

28
3.2.2 Installation of ns-2.30

This subsection shows the ways to install ns-2.30. Firstly, we download ns-2 from the

ns2 at http://website www.isi.edu/ns/nsnam. We follow the steps below to install the

network simulator.

STEP 1

There are some of the packages that are not available in Fedora 12 which are needed by

ns-2. Thus, in the following, we are updating the packages before installing ns-2. From

terminal, we login as super user and do the following. Internet connection must be

connected in order to install the package dependencies.

yum install autoconf

yum install automake
yum install gcc-c++
yum install libX11-devel
yum install xorg-x11-proto-devel
yum install libXt-devel
yum install libXmu-devel

STEP 2

From terminal, we download ns-allinone-2.30 and by typing the following commands.

$ wget http://www.isi.edu/nsnam/dist/ns-allinone-2.30.tar.gz

The file that we have downloaded is in .tar.gz format. We need to untar the file using the

following command.

$ tar -xzf ns-allinone-2.30.tar.gz

After untar the file, we go into the ns-2 directory by changing the directory using the

following command.

$ cd ns-allinone-2.30
29
Then, we install ns-2 by using the following command

$. /install

We wait for about half an hour for the execution until the ns-2 is successfully installed

into the system.

STEP 3

In this step, we need to update the bash file by adding the following files to the .bachrc

file in the fedora operating system. We go to /etc folder and type

gedit ~/.bashrc

Under the .bashrc file, we add the following lines to the end of it.

# LD_LIBRARY_PATH
OTCL_LIB=/usr/local/ns-allinone-2.30/otcl-1.12
NS2_LIB=/usr/local/ns-allinone-2.30/lib
X11_LIB=/usr/X11R6/lib
USR_LOCAL_LIB=/usr/local/lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$OTCL_LIB:
$NS2_LIB:$X11_LIB:$USR_LOCAL_LIB

# TCL_LIBRARY
TCL_LIB=/usr/local/ns-allinone-2.31/tcl8.4.14/library
USR_LIB=/usr/lib
export TCL_LIBRARY=$TCL_LIB:$USR_LIB

# PATH
XGRAPH=/usr/local/ns-allinone-2.30/bin:/usr/local/ns-allinone-
2.30/tcl8.4.13/unix:/usr/local/ns-allinone-2.30/tk8.4.13/unix
NS=/usr/local/ns-allinone-2.30/ns-2.30/
NAM=/usr/local/ns-allinone-2.30/nam-1.12/
PATH=$PATH:$XGRAPH:$NS:$NAM

30
 source ~/.bashrc

$ ns

Then, a % will appear on the screen. Type exit to quit the mode and back to $.

The appearance of % shows the the ns-2 is successfully installed in the system.

3.3 Design Topology

Having successfully installed ns-2 in fedora operating system, in the following phases,

we are going to design the topology for our research purposes. The proposed model

aims to evaluate the behavior and performance of TCP in wireless environment. In our

research, we aim to investigate about packet loss, the transmission delay and also the

performance evaluation of TCP in wireless environment respectively. Thus we study the

architecture of various models that have been proposed to evaluate the performance of

TCP. Then we proposed our networking model by this network topology using 7 of

network nodes. Figure 3.2 shows the topology that we have designed for our simulation

experiment.
FT FT
PP P

TCP TCP

PP P

N1 N3
100mb 100mb
W1
2ms 2ms
R1 R2
1.5mb 20ms
NULL
N2 N4

Figure 3.2 Simulation Topology

TCP
TCP

FT
P
FT
P

31
 Table 3.2 : design Topology Description

- Source - Link - Sink

N1 W1
- Agent - Node - Wireless node

Referring to Figure 3.2, the designed topology is setting up of 7 nodes. The

description of each nodes are describe in table 3.2 below.

Table 3.3 Topology Nodes Description

Node Description

N1 Node 1

N2 Node 2

R1 Router 1

R2 Router 2

N3 Base station 1

N4 Base station 2

W1 Wireless node

Refer to Figure 3.2, node1 and node 2 are connection to router 1 with 100Mbps.

The 100 Mbps represents the local area network (LAN) high speed Ethernet. Router 1 is

connection to router 2 with the bandwidth of 1.5 Mbps. This represents the T1 service

that represents the wide area network (WAN). Then, base station 1 and base station 2

are connection to router 2 with high speed Ethernet of 100 Mbps. The wireless node is

connected to base station 1.

32
 The delay of LAN networks are set to 2 ms which represent the delay of high

speed Ethernet. The delay of router 1 and router 2 are set to 20ms which represents the

long delay in WAN.

3.4 Develop the designed topology

After designed the topology, we are going to develop the designed topology in

ns-2 using the TCL language. In this subsection, we explain the code that we have

written in ns-2 in details. The first step in writing the tcl code is to create the simulation

object. The simulation object is created using the following command.

set ns [new Simulator]

Having created the simulation object, we need to create the trace file and the

nam trace file. The reason of creating the trace files is to study the behavior of the traffic

during the simulation execution. The following codes show the ways of creating the

trace file and the nam trace file.

set nf [open out.nam w]

$ns namtrace-all $nf

The codes below show the finish procedure in ns-2. The finish procedure is the

closing part of the simulation. Thus, as the codes below have shown, the finish

procedure closes the trace file and nam trace file. The finish procedure also flushes the

trace files so that there is no repetition of same set of data for the next simulation.

proc finish {} {
global ns nf
$ns flush-trace
close $nf
exec nam out.nam &
exit 0
}

33
 In our simulation experiment, there are 7 nodes that we have created. The ways

of creating nodes are shown in the following code. The code below show the ways of

create node 1 which is named as n1 and node 2 which is named as n2.

set n0 [$ns node]

set n1 [$ns node]

After creating nodes, we need to link up the nodes with link. There are 2 types of

link that are available which are simplex link and duplex link. The simplex link is a

unidirectional link which sends data only in one direction. Whereas, the duplex link is

the bi-directional link which sends data in two directions. Command below shows the

way to create a link.

$ns duplex-link $n0 $n1 1Mb 10ms DropTail

The command above creates a link between n0 and n1 with 1Mbps of bandwidth and

delay of 10ms. In our research, we need to create the links that use to simulate the

network. We do this by specifying for each of our nodes which links they have, the

bandwidth of the link and the delay associated with the link and we can also specify the

queue that is associated with the link; in this scenario we specify a drop tail queue. The

following piece of code creates a link between node n1 to r1 that has a bandwidth of

100Mb and has a delay of 2ms. It then creates a link between node r1 to r2 with a

bandwidth of 1.5Mb with a delay of 20ms. Then node n2 is linked to r1 with a

bandwidth of 100Mb with a delay of 2ms. It then creates a link between node n3 to r2

with the same bandwidth and delay of n2 to r1. It finally creates a link between node n4

and r2, with a bandwidth of 100Mb and a delay of 2ms. Each of the links has a

DropTail queue. DropTail is a base class queue that are a subclasses of queue objects

that implement simple FIFO queue. There are no methods configuration parameters or

34
state variables that are specific to DropTail objects. For routers we use RED queue.

We create 7 nodes topology because it is a wireless topology. There are 2 routers that

will be forward the packets from the sender to the receiver.

A duplex communication system is a system composed of two connected parties

or devices that can communicate with one another in both directions. Duplex systems

are employed in many communications networks, either to allow for a communication

"two-way street" between two connected parties or to provide a "reverse path" for the

monitoring and remote adjustment of equipment in the field. A duplex link correponds

two queues in the network. Duplexlink create a bi-directional link between node 1 and

node 2. Figure 3.4 below shows link between nodes.

UDP NULL Agent 1 Duplex Link

UDP Agent 0 TCP Traffic Source

Figure 3.4 Link between nodes

The class Agent and the class Application are two classes for

traffic generation in ns2. Every node in the network that needs to

send or receive traffic has to have an agent attached to it. These

agents are important to run the application. The application

determines the kind of traffic that is simulated which is two types of

agents UDP and TCP.

35
 The following types of TCP are available in ns-2 : TCP/Tahoe,

TCP/Reno, TCP/Vegas, TCP/Sack1, TCP/Fack, TCPSink. First, we create

a TCP agent and attach it to the TCP nodes using the attach agent.

Then, it create TCP agent that we have selected. This acts as the

agent that we chose and attach it to the TCP sink node. The two
Set tcp [newusing
agents are connected Agent/the
TCP]simulator method.
$tcp set class_2
Set sink [new Agent/TCPSink]
$ns attach-agent
After setting up the$n0 $tcp with the connections established
network
$ns attach-agent $n3 $sink
and protocol$ns connect
set, $tcp $sink
we need to add a traffic source in order to send data

across the simulated network. In the scenario, the data source is a

FTP application that runs on node n0 to n2. For each of this node, we

need to create a new FTP application. The FTP application then needs

to be assigned to the TCP agent that we have already created.

Set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns at 1.2 ftp start

The next step is to add a 'finish' procedure that closes the trace file and starts nam

proc finish {} {
global ns f nf
$ns flush-trace
close $f
close $nf
puts running nam
exec nam out,nam &
exit 0

During creating mobiles nodes in ns2, we need to define the type for each of these

network components like Link Layer (LL), Interface Queue (IFQ), MAC layer, the

36
wireless channel nodes transmit and receive signals from etc. There are the parameters

like type of antenna used, the radio-propagation model, the type of ad-hoc routing

protocol used by mobilenodes etc. Below is example of parameters to be defined.

set val(chan) Channel/WirelessChannel ;# channel type

set val(prop) Propagation/TwoRayGround ;# radio-propagation model
set val(ant) Antenna/OmniAntenna ;# Antenna type
set val(ll) LL ;# Link layer type
set val(ifq) Queue/DropTail/PriQueue ;# Interface queue type
set val(ifqlen) 50 ;# max packet in ifq
set val(netif) Phy/WirelessPhy ;# network interface type
set val(mac) Mac/802_11 ;# MAC type
set val(rp) DSDV ;# ad-hoc routing protocol
set val(nn) 1 ;# number of mobilenodes

We create topology object that keeps track of movements of mobilenodes within the

topological boundary.

set topo [new Topography]

We provide the topography object with x and y co-ordinates of the boundary, (x=500,

y=500) if mobilenodes move within a topology of 500mX500m.

$topo load_flatgrid 500 500

After that, we create GOD (General Operations Director) is the object that is used to

store global information about the state of the environment, network or nodes that an

omniscent observer would have. God object stores the total number of mobilenodes and

a table of shortest number of hops required to reach from one node to another.

create-god $val(nn)

37
After create GOD, we need to configure nodes before we create the nodes. Node

configuration API may consist of defining the type of addressing (flat/hierarchical etc),

the type of adhoc routing protocol, Link Layer, MAC layer, IFQ etc

$ns_ node-config -adhocRouting $val(rp) \

-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqLen $val(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-topoInstance $topo \
-channelType $val(chan) \
-agentTrace ON \
-routerTrace ON \
-macTrace OFF \
-movementTrace OFF

Creating mobiles node as follow

for {set i 0} {$i < $val(nn) } {incr i} {

set node_($i) [$ns_ node ]
$node_($i) random-motion 0 ;# disable random motion
}

After creating nodes, we set the position and movement for the nodes.

# Provide initial (X,Y, for now Z=0) co-ordinates for node_(0)

and node_(1)

$node_(0) set X_ 5.0

$node_(0) set Y_ 2.0
$node_(0) set Z_ 0.0

3.5 Validation

38
After the stages designing and development of network model, the designed and

developed network topology requires validation under ns-2. The process of validation

is to verify that the designed network protocol represent the real network situation. This

process to ensure that the data collected is correct. We validate the developed network

topology by run validate program in the root directory of the ns-2 distribution. The

validation program run all current standards tests. By the validation process represent

the more stable core of protocols in ns-2.

3.6 Testing and Simulation

After validation process, we run the simulation experiment. All the parameters set in the

simulation experiments are justified. This is to ensure that the parameters represent the

real world situation. After the completion of simulation process that is run long enough,

which to ensure that the result obtained is accurate. To obtain accurate data from the

simulation, let the simulation run many times with random generator. Simulation in

short duration cause the data we collect not stable and not accurate. We are collecting

data that is executed after certain duration. This data is the stable, accurate and useful

result. Depending on the users purpose for an OTcl simulation script, simulation results

are stored as trace files, which can be loaded for analysis by an external application:

1. A NAM trace file (file.nam) for use with the Network Animator Tool

2. A Trace file (file.tr) for use with XGraph or TraceGraph

Out.na
m
NAM
TCL Visual
File Simulation
File.tcl

NS

Tracing and
Monitoring
Simulation

39
 Out.tr

Figure 3.5: Flow of events for a Tcl file run in NS

3.7 Data Analysis

3.7.1 Data Analysis from raw trace file

After we have developed the topology, we run the simulation experiment for the

designed topology. The output of the simulation experiment is a raw trace file. The raw

trace file is not a presentable output. Thus, we need to analyse the raw trace file with

awk code. Then we represent the useful information into graphs and tables.

n0 n1
Link
Head_
enqT_ Queue_ deqT Link_ Ttl_ recvT
_ _
_
Drophead drpT
dropdrop _ _

Figure 3.6: ns Link

A trace file contains all information that is needed for animation

purposes - both on a static network layout and on dynamic events

such as packet arrivals, departures, drops and link failures.Tracing in

ns-2 is implemented with the following OTcl code. Figure 3.5 shows

the component of trace file elements. There are:

EnqT_ refer to the element that traces packets entering

queue_
deqT_ - refer to the element that traces packets leaving the
queue_

40
 drpT_ -refer to the element that traces packets dropped from
queue_
recvT_ - refer to the element that traces packets received by
the next node

From the Figure 3.5, we observe that a simple link is set up of:

head_ - the entry point to the link. This is first object point of
the link
Queue_ refers to the main queue element of the link
Deque_ Refers to the element that models the link
Link_ is the representative of delay and bandwidth characteristic
of the link
Ttl_ refers to an object that is the head of a queue of elements
drophead_ processes link drop

Table 3. 3: Trace file data explanation

No Explanation
1 Operation performed in the simulation
2 Simulation time of event occurrence
3 Node 1 of what is being traced
4 Node 2 of what is being traced
5 Packet type
6 Packet size
7 Flags
8 IP flow identifier
9 Packet source node address
10 Packet destination node address
11 Sequence number
12 Unique packet identifier

Table 3.4: Field appearing in a trace

Event Time From To Pckt Packet Flag Fid Src Dest Seq.no Packet
node node type size address addr ID

41
From the figure 3.4, we observe the field of a trace is setup of:
Event which refer to type of event. There are 4 type of event;
r,+,-,d which is correspond respectively to
receive,enqueued,dequeued and dropped.
Time which refer to time of event occur.
From node refer to which node the event occur.
To node refer to the node that output of event occur.
Packet type refer to what packet type is used(for example UDP
or TCP).
Packet size refer to packet size.
Flag refer to some flags.
Fid refer to flow ID of IPV6 that a user can set for each flow at
the input of Otcl script.
Src add - refer to source address given in the form of
:node.port.
Dst add refer to destination address in the same form.
Seq num refer to network protocols packet sequence number.
Pkt id refer to unique id of the packet.

Table 3.5: Symbols in the raw trace file

Symbol Symbol Name Description
+ Enque Packet arrival
- Dequeue Packet departure
d drop Packet drop
r receive Packet received at destination node

Table 3.6: Partial raw trace file for wired topology(old trace
file)

+ 1.648101 2 3 ack 40 ------- 2 0.0.1.0 1.0.1.1 1 11

- 1.648101 2 3 ack 40 ------- 2 0.0.1.0 1.0.1.1 1 11
r 1.65458 3 2 tcp 1060 ------- 2 1.0.1.1 0.0.1.0 2 8

42
 Table 3.7: Partial raw trace file for wireless topology(new
trace file

-t 1.601855415 -Hs 6 -Hd 4194305 -Ni 6 -Nx 100.00 -Ny -210.00 -Nz 0.00 -Ne -1.000000
-Nl AGT -Nw --- -Ma 13a -Md 2 -Ms 0 -Mt 800 -Is 0.0 -Id 4194305.0 -It tcp -Il 40 -If 1 -Ii 0
-Iv 27 -Pn tcp -Ps 0 -Pa 0 -Pf 1 -Po 0

s -t 1.601855415 -Hs 6 -Hd -2 -Ni 6 -Nx 100.00 -Ny -210.00 -Nz 0.00 -Ne -1.000000 -Nl
AGT -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 4194305.0 -Id 0.0 -It ack -Il 40 -If 1 -Ii 6 -Iv 32
-Pn tcp -Ps 0 -Pa 0 -Pf 0 -Po 0

+ 1.604002 4 3 ack 60 ------- 1 1.0.1.0 0.0.0.0 0 6

- 1.604002 4 3 ack 60 ------- 1 1.0.1.0 0.0.0.0 0 6

3.7.2 Network animator(NAM)

Nam is a Tcl/TK based animation tool for viewing network simulation traces and real

world packet traces. It supports topology layout, packet level animation, and various

data inspection tools. The network animator ``nam'' began in 1990 as a simple tool for

animating packet trace data. This trace data is typically derived as output from a

network simulator like ns or from real network measurements, e.g., using tcpdump.

zoom in forward by 25 * step seconds Time between twoa nimation frames

Stop animation Current animation time Change the step parameter

play animation backwards Play animation

43
 ANIMATION AREA

Edit layout zoom out

Figure 3.7 :NAM tool description

3.7.3 Data analysis using Gnuplot

Gnuplot is a free portable command-line driven graphing utility for linux, OS/2, MS

Windows, OSX, VMS, and many other platforms. It was created to allow us to visualize

mathematical functions and data interactively. Gnuplot has been developed since 1986.

Gnuplot supports many types of plots in either 2D and 3D [28,29]. Gnuplot is used in

our project to display data from trace file for further investigation and performance

evaluation. The useful

set titledata is extracted using AWK programming.
"Delay"
set xlabel "Time"
set ylabel "Delay
set yrange [0.0:2]

#set size 1,1

#set origin 0.0
set xrange [0.0:100.0]
#set mxtics 20
44
#set key 100,8
plot "reno.txt" w lines
 Figure 3.7 : plotting graph for TCP Reno

3.7.3 Data analysis using AWK programming

The awk utility interprets a special-purpose programming language. It is possible to

handle simple data-reformatting jobs easily with a few lines of code. Gawk is GNU

implementation of awk. There are three variations of AWK: there are AWK, NAWK and

GAWK.

i. AWK - the original from AT&T

ii. NAWK - A newer, improved version from AT&T

iii. GAWK - The Free Software foundation's version

AWK is the GNU Projects implementation of the AWK programming language. It

conforms to the definition of the language in the POSIX1003.1 Standard. This

version in turn is based on the description in The AWK Programming Language, by

Aho, Kernighan, and Weinberger, with the additional features found in the System V

Release 4 version of UNIX awk. Gawk also provides more recent Bell Laboratories

awk extensions, and a number of GNU-specific extensions. Pgawk is the profiling

version of gawk. It is identical in every way to gawk, except that programs run more

slowly, and it automatically produces an execution profile in the file awkprof.out

45
when done. The command line consists of options to gawk itself, the AWK program

text (if not supplied via the -f or --file options), and values to be made available in the

ARGC and ARGV pre-defined AWK variables. Using awk, we can manage small or

personal databases, general reports, validate data etc. Even experiment with algorithms

that can be adapted later to other computer languagesThe essential organization of an

AWK program follows the form:

pattern { action }

The pattern specifies when the action is performed. The pattern specifies when

the action is performed. AWK is line oriented which the pattern specifies a test that is

performed with each line read as input. pattern. Two other important patterns are

specified by the keywords "BEGIN" and "END." These two words specify actions to be

taken before any lines are read, and after the last line is read.

BEGIN { print "START" }

{ print }
END { print "STOP" }

We use AWK code to extract useful file from raw trace file to graphs and tables.

We have run AWK code for obtaining the average and maximum delay for our

proposed network topology for further investigation and performance evaluation.

3.8 Conclusion

In this chapter, we have discussed the ways to conduct the research in

details.starting from Operating system and the simulator tool installation, design the

proposed network model, make development to the designed network model. We also

46
have discuss the validation and testing and simulation to the network model. These

details discussion enable us to conduct the experiment in the correct method. The

validation of the development ensures that the designed propose are correctly

implemented in the simulation experiment.

Having analysed the results obtain, we are presenting the results and discussion

for performance evaluation in the next chapter. In in next chapter we analysed the output

of the simulation in a raw partial trace file. The raw trace file require further analysis

and will be discussed in the next chapter 4. In the chapter, We also obtained and

plotting graph which provide information for future development.

CHAPTER 4

ANALYSIS AND DISCUSSION

47
4.1 Introduction

In the previous chapter, we have presented the methodology of our research. We

also have discussed the phases of research that we have been carried out throughout

our research.

In this chapter, we are presenting the performance analysis and simulation on our

proposed protocol and the existing protocol. The performance evaluation of protocol we

used shows the efficiency of the protocols in many aspects such as the delay during

transmission and also congestion network.

This chapter discuss performance analysis and discussion of the TCP variants in

section 4.2. This section describes a realistic analysis which is comparing the

performance of the various TCP variants over wireless communication. The simulation

experiment result and discussed are presented this section.

We discuss the difference of TCP Tahoe, TCP Newreno, TCP Vegas, TCP Sack and TCP

Reno in wireless communication in section 4.3. Then, we discuss the comparison of

TCP based on the average delay and maximum delay, throughput and packet sent for all

the TCPs in section 4.4. Then, we conlude this chapter in section 4.5.

4.2 Performance analysis and discussion.

48
In this section we discuss the performance analysis of the protocol that we use for

proposed network topology whcih we have designed. In this section, we analysis

several TCP versions. There are TCP Tahoe, TCP Reno, TCP Newreno, TCP Sack, and

TCP Vegas. We analysed the TCP variants based on the simulation experiment in ns-2.

We investigate and evaluate the performance of those TCPs based on their:

1. Maximum delay
2. Average delay
3. Average Throughput
4. Packet sent

After having tcl script, we run the script to observe the simulation of wireless network

topology that we have designed. The Figure 4.1 shows an interface that is simulated

using ns-2. The next Figure 4.2 and Figure 4.3 show the partial trace file and namtrace

(NAM) for the wireless network topology that we have run. The trace file and nam file

are created after we run the tcl script of wireless network topology. Network animator is

a tool for animating packet trace data. NAM visual the output from network topology

we have designed. We see the movement of the packet transmit from sender to the

reveiver. Using trace file we observe network behavour of our network topology

designed. Figure 4.4 shows the transmission delay of the network topology we have

proposed.

49
 Figure 4.1: Screenshot of ns simulation

r 1.663851 3 4 tcp 1064 ------- 1 0.0.0.0 1.0.1.0 2 10

r 1.668314 2 3 ack 40 ------- 2 0.0.1.0 1.0.1.1 1 11

+ 1.668314 3Figure 4.2:

4 ack 40 Simulation
------- in network
2 0.0.1.0 1.0.1.1 1 11 animator (NAM)

- 1.668314 3 4 ack 40 ------- 2 0.0.1.0 1.0.1.1 1 11

r -t 1.668470601 -Hs 6 -Hd 4194305 -Ni 6 -Nx 100.00 -Ny -210.00 -Nz 0.00 -Ne
-1.000000 -Nl AGT -Nw --- -Ma 13a -Md 2 -Ms 0 -Mt 800 -Is 0.0 -Id 4194305.0 -It tcp -Il
1064 -If 1 -Ii 9 -Iv 28 -Pn tcp -Ps 1 -Pa 0 -Pf 1 -Po 0

s -t 1.668470601 -Hs 6 -Hd -2 -Ni 6 -Nx 100.00 -Ny -210.00 -Nz 0.00 -Ne -1.000000 -Nl
AGT -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 4194305.0 -Id 0.0 -It ack -Il 40 -If 1 -Ii 13 -Iv 32
-Pn tcp -Ps 1 -Pa 0 -Pf 0 -Po 0

r 1.670317 3 4 ack 40 ------- 2 0.0.1.0 1.0.1.1 1 11

50
r 1.678881 2 3 ack 40 ------- 2 0.0.1.0 1.0.1.1 2 12

+ 1.678881 3 4 ack 40 ------- 2 0.0.1.0 1.0.1.1 2 12

 Figure 4.3: Partial trace file for Sack

send time delay

1.62833 0.0401396
1.62833 0.0501987
1.70699 0.039799
1.70912 0.0682494
99.8666 0.101878
99.8687 0.109989
99.8748 0.123994

Average Throughput[kbps] = 333.11 startTime=1.63 stopTime=100.00

Average Delay is: 0.313364
Maximum Delay is: 0.470701

Figure 4.4 :Screenshot of delay for TCP SacK

4.2.1 Analysis of TCP Tahoe in wireless communication

51
 Figure 4.5 shows the simulation result of TCP Tahoe for 100s. We have

considered the mobile node as a TCP receiver. From the figure, we see the several of

delay patterns based on data transmission. We observe that delay at the starting point at

time 0s is 1.60186s. The delay becomes high because to initiate a TCP connection

before start the transmission. The source (sender) sends a sync packet of 40 bytes to

the destination (receiver). After the signaling packet is received, receiver sends ACK

(also 40 bytes) called sync ACK[22]. When receiving this ACK, TCP nodes start

sending first segment to their destination respectively. TCP start send data at time

1.616458s. There are certain period congestion network occurs. The most congested

period is among time 2s to time 11s. The transmission of the segment is too fast which

cause the bottleneck link becomes congested. Therefore, the segment is transmitted

over the base station to wireless node that is too slow and the delay also increases at that

time.

Figure 4.5: Simulation of TCP Tahoe for 100s

The simulation shows that slow-start mechanism opens up the transmission in a smooth

manner without too many retransmissions. After that, TCP congestion avoidance phase

52
takes over. The delay at this time is higher because there are many packets are sending

to the destination. This causes the route is congested and make the transmission slower

than before. Usually the slower route at router n2 from local area network ( LAN ) to

router n3 at T1 service that represents the wide area network (WAN)

Figure 4.6: Simulation of TCP Tahoe for 10s

For congestion avoidance, Tahoe uses Increase Multiplicative Decrease. A packet

losses is taken as a sign of congestion and TCP saves half of the CWND as slow-start

threshold (ssthreshold). It then set CWND to 1 MSS and restart slow-start again until

ssthreshold value. Then the CWND will growths linearly until it encounters a packet

loss. Then it increase the CWND slowly as it approaches the bandwidth capacity.

53
 Figure 4.7: Simulation of TCP Tahoe at time 90s-100s

In figure 4.7 above, we observe the delay is lower at time 95s than other period of time.

This is because in Tahoe, when encounter congestion TCP decrease the sending rate and

reduce congestion window to one. After that, TCP start retransmission over again. In

TCP Tahoe, the fast retransmit and fast recovery are not covered in the implementation

for congestion control algorithm.. But these mechanism is implemented in TCP Reno.

We discuss and analyze TCP Reno in the next section.

4.2.2 Analysis of TCP Reno in wireless communication

Figure 4.8 shows the simulation for TCP Reno for 100s. The TCP Reno and TCP Tahoe

have some equilibrium but there are some different on their mechanism implementation.

Refer to this graph below, we observe the congestion network better as compared to

TCP Tahoe.

54
 Figure 4.8: Simulation of TCP Reno for 100s

From the figure 4.8, we observe that the delay at the starting point is also high because

signalling packet is sent by the host to the destination before it starts the transmission

to initiate TCP connection. Then TCP start to send data at 1.616274s. TCP Reno retains

the basic principle of Tahoe, just a slight modification over TCP Tahoe. We can see at

the beginning, the slow-start mechanism phase is starting until there is some dropping

point before it reaches congestion threshold. Then, slow-start restarts again. When the

congestion window is larger enough and reaches the congestion threshold, the slow-start

phase is over. After that, congestion avoidance mechanism continue to control the

transmission. In congestion avoidance phase, the congestion window is linearly growth.

TCP Reno implements the fast recovery mechanism in conjunction with the fast

retransmit. Fast retransmission and fast recovery algorithms [13,15,16] were developed

to recover packet losses quickly without RTTs. In fast retransmit, when there are

congestion network, it increases congestion window to 1 by reached 3 dupacks from the

receiver. The fast recovery algorithm in Reno [15, 16] replaces the slow-start with

congestion avoidance by reducing the congestion window to one half. Slow-start is

55
omitted if no timeout occurs, then CWND is immediately set to the threshold value.

After that, TCP increases the CWND by 1 MSS after every successful round of

transmissions. The effect of Reno TCP cuts the congestion window by half for each

recovered loss that causes maximum number of recoverable packet losses in a

congestion window without timeout is limited to one or two packets in most cases.

Under the most optimistic assumption that the algorithms always be triggered, no more

than six losses can be recovered with a maximum window size of 128 packets [15] .

Figure 4.9: Simulation of TCP Reno for 10s

Refer to figure 4.10, we observed at certain period of times, transmission of the

segments occur in order and sequentially. Hence, this decreases congestion network

until the end of simulation. After time 100s, the simulation end and the packet that are

still in the buffer is dropped.

56
 Figure 4.10: Simulation of TCP Reno at time 90s-100s

4.2.4 Analysis of TCP Newreno in wireless communication

Congestion
network

Figure 4.11: Simulation of TCP Newreno for 100s

57
Figure 4.11 above is a simulation experiment for TCP Newreno for 100s. The pattern of

simulation graph between Reno and Newreno are also have some equilibrium but

congested network in Newreno is worse than Reno at the beginning of the simulation

time. Before start a transmission between sender and receiver, TCP first sending

signalling packet to initiate connetion same like other TCPs. Same like Tahoe and Reno,

slow-start phase starts in the beginning of the transmission.TCP Newreno start send data

at time 1.637125s. Newreno is a slight modification over TCP Reno. The main

different among Reno and TCP Newreno is Newreno able to detect multiple packet

losses and more efficient than Reno per RTT. There are certain period of times network

are congested. When congestion occurred, Newreno solve the congestion same like

Reno for congestion avoidance. There are different implementation of Newreno in

fast recovery. mechanism. After entering the recovery phase, it will wait until all the

data which was outstanding is acknowledged, then will exit the phase. It will overcome

reducing the CWND multiple time.

Figure 4.12: Simulation of TCP Newreno for 10s

58
 Figure 4.13: Simulation of TCP Newreno for at 90s-100s

After time 99.997s, the transmission is over and the packet that is sending after the

simulation time will be dropped. In the next section 4.2.5, we discussed simulation

experiment of TCP Sack.

4.2.5 Analysis of TCP Sack in wireless communication

Figure 4.14 shows the simulation result of TCP Sack for 100s. We have

considered the mobile node as a TCP receiver. The simulation shows that slow-start

mechanism opens up the transmission in a smooth manner without too many

retransmissions. From the figure, we see the various of delay patterns based on data

transmission. There are certain period network become congested. The most congested

period is among time 25s until to time 58s. The transmission of the segment is too fast

which cause the bottleneck link become congested. Therefore, the segment is

transmitted over the base station to wireless node that is too slow and the delay also

increases at that time.

59
 Figure 4.14: Simulation of TCP Sack for 100s

From figure 4.14, we observe that delay at the starting point at time 0s is 1.60186s

because to initiate a TCP connection before start the transmission that we called three

handshake like other TCPs. When receiving ACK from the receiver, TCP nodes start

sending first segment to their destination respectively. At time 1.616274s, first segment

starts to transmit from node 0 to node 2. After n6 have received the segment, it sends

ACK to tell the sender that the first segment have been received at time 1.706477s.

Before time 2.01s, we see that the transient behavior in TCP is in the slow-start phase

and we see from the time 2.01s onwards, a steady-state cyclic regime of TCP is attained.

This is because TCP is in congestion avoidance and its window size is almost linearly

until congestion occurred. The congested network has occurred at time 23s until time

38s after that, the network congested again at time 40s until 58s. This is because of the

bottleneck link at n2 and n3. Node n2 and n3 are routers that link the sender to receiver

at different LANs. The bottleneck link has bandwidth capacity of 1.5Mb only. Both

wired node and wireless nodes sending data respectively at bandwidth capacity 100Mb,

these have caused the congestion network occurs at bottleneck link. Additionally, the

60
slow-start operation also have caused congested network. Every each segment that has

received to the receiver, the sender receives the ACK and transmits two segments then

have caused congestion network. An alternative to decrease the congested network

occur at the bottleneck link, we use RED (Random early detection) queue for the

bottleneck link. Operation of RED is preventing the routers queue for becoming full

which can cause randomly dropping packets then network become congested. In RED

operation, it sends signals to the sender. This signal is to tell the sender to slow down

the transmission before the queue entirely full. After that, the transmission is slower and

this will decrease congestion network. At certain time, we could see the behavior of the

network is smooth. Hence, the congested network is also decreased than the certain

times before.

Figure 4.15: Simulation of TCP Sack for 10s

61
 Figure 4.16: Simulation of TCP Sack at time 90s-100s

Starting from 61 onwards, the congested network decreases because of the

transmission of the segments are transmitted to their destination in order. Thus, the order

transmission makes the data not to be sent too fast. The network start congestion again

starting at time 90s. Then, congestion network decreases at time 96s onwards. The

traffic at bottleneck link also is in controlled. Maximum delay is 0.470701s and average

delay is 0.313364s. There are no drop segment occur until some segments drop at the

end time of simulation:100s

Slow-start mechanism is used at the beginning of the transmission, or after

repairing loss detected by retransmission timer [11]. For the operation of slow-start,

every each ACK received to the sender, the sender will send two more segments and this

will caused the cwnd increased exponentially. As each ACK arrives, two packets are

generated [14]. Each time the sender receives the ACK from the receiver, the sender

increases the CWND by 1 segment (1MSS). Therefore, after sending the first segment

before a timeout, the sender increases the CWND to two segments. Later if the two

segments is acknowledged, the CWND is increased to four segments and so on. The
62
CWND size grown exponentially during the slow-start phase because slow-start need to

fill the pipe as quickly as possible to utilize network resources maximally. But refer of

this graph, there is not exactly exponential growth because the receiver delay its ACK.

When the capacity of the network is reached, the bottleneck link will start discarding the

packets. This tells the CWND is too large. The slow-start will end when the CWND

exceeds a certain value specified as the congestion threshold. The slow-start algorithm

hands over the CWND control to the congestion avoidance algorithm based on Reno

implementation on congestion avoidance. After that, fast retransmit or fast recovery is

implemented if there are any packet losses in congestion avoidance phase. In the next

section 4.2.6 we analyse TCP Vegas performance in wireless communication.

4.2.6 Analysis of TCP Vegas in wireless communication

Figure 4.17 shows the simulation of TCP Vegas for 100s. The graph pattern of

TCP Vegas is different compared to other four TCPs we have discussed before. From

the figure, we observed the congestion network does not occur frequently, only at

certain periods when the data transmission occurs so fast over the bottleneck link. Thus,

the bottleneck link becomes congested.

At time 3.19483s, delay becomes higher again because of fast transmission of the

segments. When the trasnmission is fast, there are many segments are sent to the

receiver. Thus this cause congested network at the receiver, so the RTT of the segment is

longer than usual. We observe the average delay for Vegas simulation is 0.07151s and

the maximum delay is 0.11827s.

63
 Figure 4.17: Simulation of TCP Vegas for 100s

From the figure 4.13, we observed delay at starting point is high because to

initiate TCP connection same with Sack and other TCPs we have discussed before.

After receiving ACK from the host, the transmission of first segment is started. Vegas is

a TCP implementation which is a modification of Reno. Slow-start mechanism that is

used in Vegas is modified of Reno. Same like Reno and Sack, Vegas implement slow-

start mechanism at the beginning of first segment transmission. But the implementation

of slow-start of Vegas is different than other TCPs. In slow-start phase of Vegas , it

increases exponentially only every other RTT, between that, it calculates the actual

sending throughput to the expected and the difference goes above a certain threshold it

exits slow-start and enter the congestion phase. Refer to the graph, we observe the

delay for the simulation of Vegas is lower than Sack and other TCPs. In Vegas, it

detects congestion before the packet losses occur. Thus cause delay is lower than other

TCPs because the rate of congested network is lower as compared to them. We observe

the delay of Vegas is balance starting from the begining to the end of simulation.

64
Figure 4.18: Simulation of TCP Vegas for 10s

Figure 4.19: Simulation of TCP Vegas for 90s

65
4.3 The difference of TCPs in wireless communication

Figure 4.20 above shows the comparative pattern of three TCP variants for simulation

experiment of 100s. From the figure we observed the pattern of the TCPs are different

among each other. The different patterns of the TCP variants above are caused by the

algorithm that is implemented on each of them. All of the TCP variants above do the

same mechanism for congestion control algorithm. But all the TCPs have their own

modification for the mechanisme we have discussed. As Vegas, it have modification of

slow-start mechanism congestion avoidance and also re-transmission mechanisme. In

Reno,it adds fast retranmsit conjunction with fast recovery. For Selective

Acknowledgement (SACK), IT added Sack option. Moreover, in Newreno, it have

modified the Reno to be more efficient in the event of multiple packet losses which is

able to detect multiple packet losses as compared to Reno. At the beginning of

simulation, we see all the TCPs have higher delay because of initiate TCP connection.

After that, all the TCPs start the simulation with slow-start phase with different

modification.

66
Figure 4.20 : Combination graph of various TCP

67
 Figure 4.21: Comparison of TCP variants

The main difference between the TCP Sack implementation and the TCP Reno

implementation is in the behavior when multiple packets are lost from one window of

data. With Sack, the sender is able to identify and retransmit multiple lost packets

within the same RTT if there are enough ACKs returning to the sender [15].

New retranmission mechanisme implement by Vegas is accurate than Reno[5].

Vegas does not need to wait for 3 dupacks for retransmission of packet losses. In

contrast, Reno still have to wait for 3 dupacks and when the coarse-grained timeout

occur for retransmission of packet losses. In Vegas, slow-start mechanisme is also

different than others. The exponential growth of Vegas increases only every other RTT.

In between, the CWND stays fixed so a valid comparison of the expected and actual

rates can be made. When the actual rate falls below the expected rate by a certain

amount. When the difference goes above the certain threshold , Vegas exits slow-start

phase and change to linear increase/decrease phase. But Vegas will implement coarse-

68
grained timeout like Reno if the mechanisme fail to recognize lost segment. In

Newreno, it take one RTT to detect each packet loss. When the ACK for the first

retransmitted segment is received, we only can deduce which other segment was lost. In

tahoe, in most of Tahoe implementation, it takes longer time because of the coarse grain

timeout. The table below show the advantages and disadvantages of TCP variants.

Table 4.1: The advantages and disadvantages of TCP variants

TCP ADVANTAGES DISADVANTAGES

Tahoe - Performance of Tahoe is better - slow start is not always

than Reno when mulitple packet efficient, especially if the error
are lost in 1 window of data was random in nature.
- unable to fully utilize the
available bandwidth of the
radio channel during the phase
of window re-expansion.

Reno Performs well over WLAN - Poor performance over

compared to TCP Tahoe when only WLAN compared to
a single packet is lost from one TCPTahoe when multiple
window of data packets are lost from one
window of data
- Cannot distinguish between
congestion loss and packet
errors.
- Overreacts to packet errors.

Newreno - Performs better than TCP Reno Cannot distinguish between

over WLAN when multiple congestion loss and packet errors.
packets are lost from one
window of data
- Modifications are only needed
in the sender.
- Very popular protocol overall

Sack The source has better information Requires modification to the

of the packets thathave been acknowledgement procedures at
successfully delivered compared to

69
 other TCP versions. It can therefore both sender and receiver sides.
avoid unnecessary delays and
retransmissions.

Vegas - Good performance over - Cannot distinguish between

WLAN when using Snoop congestion loss and packet
protocol errors.
- Poor performance over
WLAN when multiple error
bursts (>4 losses) occur
without using Snoop
protocol.
- Asymmetric path.
- Algorithm is currently not
embedded in most TCP
implementations.

Based on the simulation experiment of all TCP variants we have proposed, the

perfomance evaluation of TCP Vegas is better than other TCPs we have analysed. But

all the TCPs we have discussed their own advantages and disadvantages respectively. In

section 4.4 we describe about the comparison of TCPs based on average of delay,

throughput and packset sent.

Table 4.1 shows the average delay Average, average throughput and maximum

delay, and packet sent of all TCPs we have discussed. From the table, we observed TCP

Sack has the highest average delay and average delay of Reno is higher than Vegas.

Average delay for Newreno is higher than Reno, Tahoe, and Vegas. Between all TCPs

we have analyzed, we have observed that TCP Vegas have the lowest average delay as

compared to other 4 TCPs. For the maximum delay, Newreno has the highest maximum

delay compared to other TCPs. For the average throughput, Vegas has the highest

average throughput as compared to others with 364.71Kbps. For packet sent, Tahoe

sent 3970 packet and TCP Sack sent 4010 packet. Then Reno sent 4163 packet. TCP

70
Vegas sent the highest packet 4379 as compared to other TCPs. Tahoe is the lowest TCP

of sent packet in simulation experiment. Thus, we conclude that Vegas performs better

than others in wireless communication. This is because Vegas has the lowest average

delay and sent more packet as compared to others.

Table 4.2: Average delay of TCP variants

TCP Average Average Maximum Packet

Delay(s) Throughput(kbps) Delay(s)
Sent(packet)

Tahoe 0.28806 329.78 0.4723 3970

Reno 0.27264 346.36 0.4710 4163

Newreno 0.3042 333.52 0.4745 4021

Sack 0.31336 333.11 0.4708 4010

Vegas 0.07151 364.71 0.11827 4379

4.5 Conclusion

71
Having the discussion of performance evaluation of TCP Tahoe, Reno, Newreno,Sack

and Vegas in this chapter, we have seen the comparative of TCPs by conducting

simulation experiment. From the discussion we have done, we observed that TCP Vegas

performs better in wireless communication. We also have investigated the behavior of

TCPs in wireless link. Moreover, we have seen the comparative pattern of TCPs in

graph and also the comparison of average and maximum delay among of them.

Among of five TCP we have evaluated, TCP Vegas has the highest average throughput.

72
 CHAPTER 5

CONCLUSION

From this research, we observe the importance of Transmission Control Protocol (TCP)

in this modern society. Thus, the aim of this study is to evaluate the performance of TCP

variants in wireless communication via simulation experiment in ns-2.

In this thesis, we had presented our work about the performance evaluation of

TCP variants in wireless communication. We have investigated the performance

evaluation of the TCPs, we conduct the simulation experiment in ns-2 and we do some

comparative with the result that we have obtained. We present the results into graphs

and tables. The result of the simulation experiment using ns-2 shows that our proposed

network model performs well in wireless link. Between TCP variants we have compare

(on delay performance) each of the TCP variant that shows the various result. TCP

Vegas has the lowest delay in wireless link as compared to Tahoe, Newreno, Sack and

Reno. Vegas also have the best througput as compared to others. Moreover, based on

sending packet, Vegas also sent more packet than other TCPs. The effective congestion

control technique of Vegas makes it optimal in such a heterogeneous environment. The

lowest transmission delay causes the transmission of Vegas much better than Reno and

73
Sack. The service of wireless communication also performs better with implementation

of TCP algorithms. Thus the performance of the wireless communication is improved .

In chapter 2, we have discuss overview of our thesis. We also attach some

related works from previous researches. From the previous researches, we study about

the research that are related with our project.

In chapter 3, we presented the methodology used in our research. We had

discussed about the operating system that we used for our project and the simulation

tool ns-2 which we used for the simulation experiment. In the other hand ,we have

discussed the designed network topology which is written in the Tcl language in details.

In chapter 4, we evaluate the performance study of our proposed network

topology. We conduct some simulation experiment to our proposed topology, we do

some investigation to evaluate the performance of TCPs that we have proposed in

wireless communication. We also do the comparative of TCPs in graphs and tables.

Lastly in this chapter we conclude all the performance evaluation studies we

have done in all chapters before. After some evaluations and investigation, we

observed that TCP Vegas has better performance in wireless communication.

5.2 Future Work

As further improvement of this study, here are some points to be

considered:

(i) Investigate more TCP variants to tackle different problems

facing the behavior and performance of TCP in wireless

environments.

74
(ii) The network model can include more routers, base stations and

links to simulate other problems facing wired and wireless

scenarios such as, Out of Order Delivery, handoff latencies, the

effects of using different routing protocols, jitters, bandwidth per

station and packet processing time.

(iii) Other application that uses transportation protocols, such as

snoop, can be simulated. Thus, we could investigate the effects

and behavior of the different network topologies on such

protocols in wireless communication.

75
 REFERENCE

[1] Kevin Fall and Sally Floyd Simulation-based Comparisons of Tahoe, Reno, and
SACK TCP Lawrence Berkeley National Laboratory

[2] Jeonghoon Mo, Richard J. La Venkat Anantharam, and Jean Walrand Analysis
and Comparison of TCP Reno and Vegas , Department of Electrical Engineering
and Computer Sciences University of California at Berkeley

[3] Upkar Varshney Selective Slow Start: A simple algorithm for improving TCP
performance in wireless ATM network Computer Information Sciences
Washburn University of Topeka

[4] Christina Parsa and J.J. Garcia-Luna-AcevesImproving TCP performance over

wireless networks at the link layerComputer Engineering Department, Baskin
School of Engineering, University of California, Santa Cruz, CA 95064, USA

[5] Lawrence S . Brakmo, Sean W.O Malley and Larry L

Peterson.TCP Vegas: New Techniques for congestion detection
and avoidance

[6] Hari Balakrishnan, Venkata N. Padmanabhan, Srinivasan Seshan and Randy H.

Katz1 A Comparison of Mechanisms for Improving TCP Performance over
Wireless Links

76
[7] Andrea Goldsmithwireless communicationCambridge University Press,2005

[8] Alberto Leon-Garcia and Indra widjaja Communication networks fundamental

concepts and key architectures 2th edition 2009

[9] Transmission Control Protocol, RFC 793, Sep 1981.

[10] Cooperative Association for Internet Data Analysis (CAIDA), Traffic Workload
Overview:http://www.caida.org/outreach/resources/learn/trafficworkload/tcpudp.
xml

[11] Jinwen Zhu and Tianrui Bai Performance of Tahoe, Reno, and SACK TCP at
Different Scenarios

[12] Padhye, J., S. Floyd, On Inferring TCP Behavior, Computer Communications

Review ACM-SIGCOMM, Vol. 31, August 2001.

[13] Stevens, W.R., TCP Slow Start, Congestion Avoidance, Fast Retransmit, and
FastRecovery Algorithms, RFC 2001, 1999

[14] V. Jacobson Congestion Avoidance and Control Proc Computer

Communication Review, 18(4):314{ 29, August 1988.

[15] V. Jacobson. Modified TCP Congestion Avoidance Algorithm. Technical report,

April 1990.

[16] Wright, G., Stevens, W. R., TCP/IP ILLUSTRATED VOLUME 2, Addison-

Wesley Publishing Co., New York, 1995

[17] Tsang-Ling Sheu and Lien-Wen Wu An analytical model of fast retransmission

and recovery in TCP-SACK Department of Electrical Engineering, National
Sun Yat-Sen University, Kaohsiung, Taiwan 26 April 2006

[18] Dong Lin and H.T. Kung TCP Fast Recovery Strategies: Analysis and
Improvements

[19] Sharjeel Shahid Improving TCP Performance over Wireless Networks

[20] Dah-Ming Chiu, Jain, R. Analysis of the increase and decrease algorithms for
congestion avoidance in computer network. Computer Networks and ISDN
Systems, 17(1), (1989), 1-14.

[21] Dongmin Kim, Beomjoon Kim, Jechan Han, and Jaiyong Lee Enhancements to
the Fast Recovery Algorithm of TCP NewRenoDepartment of Electrical &
Electronic Engineering, Yonsei University Seoul, Korea

[22] Eitan Altman and Tania Jimenez NS Simulatior for Beginner, Lecture notes
2003-2004, University De Los Andes.December 4,2003

77
[23] Paul Meeneghan and Declan Delaney An Introduction to NS, Nam and OTcl
Scripting NUIM-CS-TR-2004-05

[24] Kevin Fall and Kannan Varadhan The ns Manual (formerly ns Notes and
Documentation)1 The VINT Project. UC Berkeley, LBL, USC/ISI, and Xerox
PARC. January 6, 2009

[26] Sikdar, S. Kalyanaraman, and K. S. Vastola, Analytic Models for the Latency
and Steady-State Throughput of TCP Tahoe, Reno and
SACK, Proceedings of IEEE GLOBECOM, San Antonio, TX, 2001.

[27] C. Barakat, E. Altman, and W. Dabbous, On TCP Performance in a

Heterogeneous Network: A Survey, IEEE Communications
Magazine, Vol38, No 1, pp. 40-46, Jan. 2000.

[28] Thomas Williams & Colin Kelley Gnuplot An Interactive Plotting Program
Copyright c 1986 - 1993, 1998, 2004 Thomas Williams, Colin Kelley

78
APPENDICES

79
 New trace file description
Event type

s send
r receive
f Drop
forward
General tag

-t time
-t * (global setting)
Node property tags

-Ni node id
-Nx node's x-coordinate
-Ny node's y-coordinate
-Nz node's z-coordinate
-Ne node energy level
-Nl trace level, such as AGT, RTR, MAC
-Nw

"END"
DROP_END_OF_SIMULATION
"COL"
DROP_MAC_COLLISION
"DUP"
DROP_MAC_DUPLICATE
"ERR"
DROP_MAC_PACKET_ERROR
"RET"
DROP_MAC_RETRY_COUNT_EXCEEDED
"STA"
DROP_MAC_INVALID_STATE
"BSY"
DROP_MAC_BUSY

"NRTE"
DROP_RTR_NO_ROUTE i.e no route is available.
"LOOP"
DROP_RTR_ROUTE_LOOP i.e there is a routing loop
"TTL"
DROP_RTR_TTL i.e TTL has reached zero.
"TOUT"
DROP_RTR_QTIMEOUT i.e packet has expired.
"CBK"

80
 DROP_RTR_MAC_CALLBACK

"IFQ"
DROP_IFQ_QFULL i.e no buffer space in IFQ.
"ARP"
DROP_IFQ_ARP_FULL i.e dropped by ARP
"OUT"
DROP_OUTSIDE_SUBNET

Packet information at IP level

-Is: source address.source port number

-Id: dest address.dest port number
-It: packet type
-Il: packet size
-If: flow id
-Ii: unique id
-Iv: ttl value
Next hop info

-Hs: id for this node

-Hd: id for next hop towards the destination.
Packet info at MAC level

-Ma: duration
-Md: dst's ethernet address
-Ms: src's ethernet address
-Mt: ethernet type
Packet info at "Application level"

-P arp Address Resolution Protocol. Details for ARP is given by the

following tags
-Po ARP Request/Reply
-Pm src mac address
-Ps src address
-Pa dst mac address
-Pd dst address
-P dsr

-Pn how many nodes traversed

-Pq routing request flag
-Pi route request sequence number
-Pp routing reply flag
-Pl reply length
-Pe src of srcrouting->dst of the source routing
-Pw error report flag ?
-Pm number of errors
-Pc report to whom
-Pb link error from linka->linkb
-P cbr

81
 -Pi sequence number
-Pf how many times this pkt was forwarded
-Po optimal number of forwards
-P tcp Information about TCP flow is given by the following subtags:
-Ps seq number
-Pa ack number
-Pf how many times this pkt was forwarded
-Po optimal number of forwards

Available options for node configuration (see tcl/lib/ns-lib.tcl).

Option Available values Default

general
addressType Flat, hierachical Flat
MPLS ON, OFF OFF
Both satellite-and wireless oriented
WiredRouting ON,OFF OFF
IIType Ll,LL/Sat
macType Mac/802_11,Mac/Csma/Ca, Mac/Sat,
Mac/Sat/UnslottedAloha,Mac/Tdma
ifqType Queue/DropTail, Queue/Droptail/Priqueue
phyType Phy/WirelessPhy, Phy/Sat
Wireless-oriented
adhocRouting DIFFUSION/RATE, DIFFUSION/PROB, DSDV,
DSR,FLOODING,OMNIMCAST,AODV,TORA
propType Propagation/TwoRayGround,Propagation/shadowing
propIinstance Propagation/TwoRayGround,Propagation/shadowing
antType Antenna/Omniantenna
channel Channel/WirelessChannel,Channel/Sat
topoInstance <topology file>
mobileIP ON,OFF OFF
energyModel EnergyModel
initialEnergy <values in joules>
rxPower <value in W>
txPower <value in W>
IdlePower <value in W>
agentTrace ON,OFF OFF
routerTrace ON,OFF OFF
macTrace ON,OFF OFF
movementTrace ON,OFF OFF
errProc UniformErrorProc
FEC
toraDebug ON,OFF OFF
Satellite-oriented
satNodeType Polar,geo,terminal,geo-repeater

82
downlinkBW <bandwidth value, e.g. 2Mb>

83