45307487 Performance Evaluation of Tcps in Wireless Network

7/27/2019 45307487 Performance Evaluation of Tcps in Wireless Network

1/82

1

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.


2/82

2

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
http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci212839,00.htmlhttp://searchunifiedcommunications.techtarget.com/sDefinition/0,,sid186_gci214031,00.htmlhttp://searchunifiedcommunications.techtarget.com/sDefinition/0,,sid186_gci214031,00.htmlhttp://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci212839,00.html


3/82

3

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.


4/82

4

1.4 Scope of Research

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


5/82

5

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.


6/82

6

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

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

conclude this chapter in section 2.4


7/82

7

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.

Figure 2.1:TCP overview

Application ApplicationByte stream byte stream

------------------ Segments ----------------------------

Transmitter receiver

Send buffer receive buffer

ACKs


8/82

8

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 packet s) 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 beenimplemented 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
http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci212839,00.htmlhttp://searchunifiedcommunications.techtarget.com/sDefinition/0,,sid186_gci214031,00.htmlhttp://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci212736,00.htmlhttp://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci212736,00.htmlhttp://searchunifiedcommunications.techtarget.com/sDefinition/0,,sid186_gci214031,00.htmlhttp://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci212839,00.html


9/82

9

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 aretransmission 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).


10/82

10

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.

Limits amount of data thatdestination buffer

Sender Receiver

Wnd=1200

500 bytes500 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.

Src Des


11/82

11

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.


12/82


13/82

13

Slow Start

threshold

time-out

CongestionAvoidance

3 DuplicateACKs

threshold

0

5

10

15

20

25

30

Time(RTT)

C o n g e s t i o n i n d o w S i z e

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].

initial slow-start

slow-start

Time-out

addditiveincrease

duplicateACKs arrive

02468

10121416182022242628303234363840

Time(RTT)

C o n g e s t i o n

i n d o w S i z e

Figure 2.5 : Fast Retransmit phase


14/82

14

2.2.4.3 Fast recovery

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].

initial slow-start

additiveincrease

Time-outduplicate

ACKs arrive

0

2

4

6

8

10

12

14

16

18

20

22

24

26

28

30

32

34

36

38

40

Time(RTT)

C o n g e s t i o n

i n d o w S i z e

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


15/82

15

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

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 save s 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


16/82

16

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

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. Sa ck 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


17/82

17

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 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


18/82

18

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,Congestionavoidance 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

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

highway systems and others.


19/82

19

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

widely implemented for wireless communication. Because of reliability services of

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


20/82

20

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 TC P 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 V egass 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

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


21/82

21

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 paper Improving 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.


22/82

22

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

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


23/82

23

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.


24/82

24

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.


25/82

25

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.

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

Design network

topology

Develop Algorithm

Validation

Testing and

simulation

Analysis

Discussion


26/82

26

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.


27/82

27

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'vefinished. Select the 'manually' option.Optional, you can setup the system'shostname. Enter your Gateway andPrimary/Secondary DNS servers


28/82

28

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

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

partitions will be created.


29/82

29

select the desired packages

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


30/82

30

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.

STEP 2

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

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

following command.

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

following command.

yum install autoconf yum install automakeyum install gcc-c++yum install libX11-develyum install xorg-x11-proto-develyum install libXt-develyum install libXmu-devel

$ w et htt : www.isi.edu nsnam dist ns-allinone-2. 0.tar. z

$ tar -xzf ns-allinone-2. 0.tar. z

$ cd ns-allinone-2. 0
http://www.isi.edu/nsnam/dist/ns-allinone-2.30.tar.gzhttp://www.isi.edu/nsnam/dist/ns-allinone-2.30.tar.gz


31/82

31

Then, we install ns-2 by using the following command

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.

$. install

# LD_LIBRARY_PATH OTCL_LIB=/usr/local/ns-allinone-2.30/otcl-1.12

NS2_LIB=/usr/local/ns-allinone-2.30/libX11_LIB=/usr/X11R6/libUSR_LOCAL_LIB=/usr/local/libexportLD_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/libraryUSR_LIB=/usr/libexport 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/unixNS=/usr/local/ns-allinone-2.30/ns-2.30/NAM=/usr/local/ns-allinone-2.30/nam-1.12/PATH=$PATH:$XGRAPH:$NS:$NAM


32/82


33/82

33

Table 3.2 : design Topology Description

- Source - Link - Sink

- 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 2N3 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.

N1 W1


34/82

34

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.

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.

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.

set ns [new Simulator]

set nf [open out.nam w]$ns namtrace-all $nf

proc finish {} {global ns nf

$ns flush-traceclose $nf

exec nam out.nam &exit 0}


35/82

35

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.

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.

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

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

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


36/82

36

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. Duplex link create a bi-directional link between node 1 and

node 2. Figure 3.4 below shows link between nodes.

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.

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

UDP NULL Agent

TCP Traffic Source

Duplex Link

UDP Agent

1

0
http://en.wikipedia.org/wiki/Communication_systemhttp://en.wikipedia.org/wiki/Communication_system


37/82

37

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 agents are connected using the simulator method.

After setting up the network with the connections established and protocol set,

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.

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

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

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 ftp [new Application/FTP]$ftp attach-agent $tcp$ns at 1.2 ftp start

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


38/82

38

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

topological boundary.

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.

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.

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

set val(chan) Channel/WirelessChannel ;# channel typeset val(prop) Propagation/TwoRayGround ;# radio-propagation modelset val(ant) Antenna/OmniAntenna ;# Antenna typeset val(ll) LL ;# Link layer type

set val(ifq) Queue/DropTail/PriQueue ;# Interface queue typeset val(ifqlen) 50 ;# max packet in ifqset val(netif) Phy/WirelessPhy ;# network interface typeset val(mac) Mac/802_11 ;# MAC typeset val(rp) DSDV ;# ad-hoc routing protocolset val(nn) 1 ;# number of mobilenodes

set topo [new Topography]

$topo load_flatgrid 500 500

create-god $val(nn)


39/82

39

Creating mobiles node as follow

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

3.5 Validation

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

$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

for {set i 0} {$i < $val(nn) } {incr i} {set node_($i) [$ns_ node ]$node_($i) random-motion 0 ;# disable random motion

}

# 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


40/82

40

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

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

NAMVisual

Simulation

NS

Tracing andMonitoringSimulation

Out.nam

Out.tr

TCLFileFile.tcl


41/82

41

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

Head_

drop

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_

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

Link

drop

enqT_ Queue _

Link_deqT

Ttl_ recvT

drpT

Drophead


42/82

42

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 size7 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 Fromnode

Tonode

Pckttype

Packetsize

Flag Fid Srcaddress

Destaddr

Seq.no PacketID

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.


43/82

43

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 protocol

s 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 departured drop Packet drop

r receive Packet received at destination node

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

Table 3.7: Partial raw trace file for wireless topology(new 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 11r 1.65458 3 2 tcp 1060 ------- 2 1.0.1.1 0.0.1.0 2 8

-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 -NlAGT -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


44/82

44

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

Edit layout zoom out

Figure 3.7 :NAM tool description

ANIMATION AREA


45/82

45

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 data is extracted using AWK programming.

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&Tii. NAWK - A newer, improved version from AT&T

set title "Delay"set xlabel "Time"set ylabel "Delayset yrange [0.0:2]

#set size 1,1#set origin 0.0set xrange [0.0:100.0]#set mxtics 20

#set key 100,8plot "reno.txt" w lines


46/82

46

iii. GAWK - The Free Software foundation's version

AWK is the GNU Projects impleme ntation 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

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" }


47/82

47

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

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.


48/82

48

CHAPTER 4

ANALYSIS AND DISCUSSION

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


49/82

49

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.

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 delay2. Average delay3. Average Throughput4. 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


50/82

50

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

proposed.

Figure 4.1: Screenshot of ns simulation

Figure 4.2: Simulation in network animator (NAM)


51/82

51

Figure 4.3: Partial trace file for Sack

Figure 4.4 :Screenshot of delay for TCP SacK

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 3 4 ack 40 ------- 2 0.0.1.0 1.0.1.1 1 11

- 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 -Il1064 -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 -NlAGT -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

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

send time delay1.62833 0.04013961.62833 0.05019871.70699 0.0397991.70912 0.068249499.8666 0.10187899.8687 0.10998999.8748 0.123994

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

Average Delay is : 0.313364Maximum Delay is : 0.470701


52/82

52

4.2.1 Analysis of TCP Tahoe in wireless communication

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


53/82

53

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

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.


54/82

54

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.


55/82

55

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


56/82

56

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.


57/82

57

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

4.2.4 Analysis of TCP Newreno in wireless communication

Figure 4.11: Simulation of TCP Newreno for 100s

Congestionnetwork


58/82

58

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


59/82

59

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.


60/82


61/82

61

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


62/82

62

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 time out, the sender increases the CWND to two segments. Later if the two


63/82

63

segments is acknowledged, the CWND is increased to four segments and so on. The

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.


64/82

64

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.


65/82

65




66/82

66

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.


67/82

67

Figure 4.20 : Combination graph of various TCP


68/82

68

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-


69/82

69

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 than Reno when mulitple packetare lost in 1 window of data

- slow start is not alwaysefficient, especially if theerror was random in nature.

- unable to fully utilize theavailable bandwidth of theradio channel during the

phase of window re-expansion.

Reno Performs well over WLANcompared to TCP Tahoe when onlya single packet is lost from onewindow of data

- Poor performance over WLAN compared toTCPTahoe when multiple

packets are lost from onewindow of data

- Cannot distinguish betweencongestion loss and packeterrors.

- Overreacts to packet errors.

Newreno - Performs better than TCP Renoover WLAN when multiple

packets are lost from onewindow of data

- Modifications are only neededin the sender.

- Very popular protocol overall

Cannot distinguish betweencongestion loss and packet errors.


70/82

70

Sack The source has better informationof the packets thathave beensuccessfully delivered compared toother TCP versions. It can thereforeavoid unnecessary delays and

retransmissions.

Requires modification to theacknowledgement procedures at

both sender and receiver sides.

Vegas - Good performance over WLAN when using Snoop

protocol

- Cannot distinguish betweencongestion loss and packeterrors.

- Poor performance over WLAN when multiple error

bursts (>4 losses) occur without using Snoop

protocol.

- Asymmetric path.

- Algorithm is currently notembedded in most TCPimplementations.

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


71/82

71

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

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 wi

45307487 Performance Evaluation of Tcps in Wireless Network

Documents

Transcript of 45307487 Performance Evaluation of Tcps in Wireless Network