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. transmission. Therefore, network congestion may occur during the

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

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.

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

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

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

-----------------Transmitter

receiver

Send buffer ACKs

receive buffer

Figure 2.1:TCP overview

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. ii. iii. Connection establishment phase Data transfer phase 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

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

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

Des t

Limits amount of data that destination buffer

Sender

Receiver
500 bytes 500 bytes

Wnd=1200

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 slowstart, 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.

11

2.2.4.2 Congestion Avoidance Algorithm

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

30

Congestion Window Size

25 20 15 10 5 0

Slow Start Congestion Avoidance threshold 3 Duplicate ACKs time-out Time(RTT) threshold

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].
40 38 36 34 32 30 28 26 24 22 20 18 16 14 12 10 8 6 4 2 0

duplicate ACKs arrive

Time-out addditive increase

Congestion Window Size

initial slowstart slow-start

Time(RTT)

Figure 2.5 : Fast Retransmit phase

13

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].
40 38 36 34 32 30 28 26 24 22 20 18 16 14 12 10 8 6 4 2 0

Congestion Window Size

duplicate ACKs arrive

Time-out additive increase

initial slowstart

Time(RTT)

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

14

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

15

order. Then the sender retransmit the segment without waiting for transmission timeout 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. 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

16

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

17

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 Tahoe Reno Newreno SACK Vegas Difference Added slow-start & Fast retransmit Based on Tahoe, added Fast Recovery Based on Reno,modification of Fast retransmit Based on Reno, added SACK(Selective ACK) 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

multimedia Internet-enabled cell phones, smart homes and appliances, automated highway systems and others.

18

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

19

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

20

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.

21

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
22

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.

23

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.

24

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

25

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.

26

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 hostname. Enter your Gateway and Primary/Secondary DNS servers
27

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.

28

select the desired packages

Hit the 'Next' button

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

29

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
30

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

31

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.
FTP P TCP FTP

TCP

PP N1
100mb
2ms

P N3
100mb

W1

R1
1.5mb 20ms

R2

2ms

NULL

N2

N4

Figure 3.2 Simulation Topology

TCP TCP FTP FTP

32

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 N1 N2 R1 R2 N3 N4 W1 Description Node 1 Node 2 Router 1 Router 2 Base station 1 Base station 2 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.

33

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

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

35

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

Duplex Link

UDP Agent

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

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

37

set val(chan) set val(prop) set val(ant) set val(ll) set val(ifq) set val(ifqlen) set val(netif) set val(mac) set val(rp) set val(nn)

Channel/WirelessChannel Propagation/TwoRayGround Antenna/OmniAntenna LL Queue/DropTail/PriQueue 50 Phy/WirelessPhy Mac/802_11 DSDV 1

;# channel type ;# radio-propagation model ;# Antenna type ;# Link layer type ;# Interface queue type ;# max packet in ifq ;# network interface type ;# MAC type ;# ad-hoc routing protocol ;# 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)

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

38

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

39

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.nam
TCL File File.tcl

NAM Visual Simulation

NS
Tracing and Monitoring Simulation Out.tr

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

40

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 Head_
Link
enqT_ Queue_ deqT _ Drophead _ Link_ Ttl_ recvT

n1

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

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

Table 3.4: Field appearing in a trace

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

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.

42

 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 + d r Symbol Name Enque Dequeue drop receive Description Packet arrival Packet departure Packet drop 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

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 Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 4194305.1 -Id 1.0 -It tcp -Il 1040 -If 2 -Ii 7 -Iv 32 -Pn tcp -Ps 1 Pa 0 -Pf 0 -Po 0

43

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

Time between twoa nimation frames

Current animation time Change the step parameter Play animation

play animation backwards

ANIMATION AREA

Edit layout

zoom out Figure 3.7 :NAM tool description

44

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.

set title "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 #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
45

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

46

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.

47

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

48

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. 2. 3. 4. Maximum delay Average delay Average Throughput 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
49

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)

50

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 -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 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 Partial trace - 1.678881 3 4 ack 40 ------- 24.3: 0.0.1.0 1.0.1.1 2 12 file for Sack

send time 1.62833 1.62833 1.70699 1.70912 99.8666 99.8687 99.8748

delay 0.0401396 0.0501987 0.039799 0.0682494 0.101878 0.109989 0.123994 stopTime=100.00

Average Throughput[kbps] = 333.11 startTime=1.63 Average Delay is: 0.313364 Maximum Delay is: 0.470701

Figure 4.4 :Screenshot of delay for TCP SacK

51

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

52

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.

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. recovered loss The effect of Reno TCP cuts the congestion window by half for each 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

62

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.

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 slowstart 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 Tahoe ADVANTAGES Performance of Tahoe is better than Reno when mulitple packet are lost in 1 window of data DISADVANTAGES slow start is not always efficient, especially if the error was random in nature. unable to fully utilize available bandwidth of radio channel during phase of window expansion. the the the re-

Reno

Performs well over WLAN compared to TCP Tahoe when only a single packet is lost from one window of data -

Poor performance over WLAN compared to TCPTahoe when multiple 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

69

Sack

The source has better information Requires modification to the of the packets thathave been acknowledgement procedures at successfully delivered compared to both sender and receiver sides. other TCP versions. It can therefore avoid unnecessary delays and retransmissions. Good performance over WLAN when using Snoop protocol Cannot distinguish between congestion loss and packet 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.

Vegas

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
70

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 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 Delay(s) 0.28806 Average Throughput(kbps) 329.78 Maximum Delay(s) 0.4723 Packet Sent(packet)

Tahoe Reno Newreno Sack Vegas

3970 4163 4021 4010 4379

0.27264

346.36

0.4710

0.3042

333.52

0.4745

0.31336

333.11

0.4708

0.07151

364.71

0.11827

71

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

73

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 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 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 Upkar Varshney Selective Slow Start: A simple algorithm for improving TCP performance in wireless ATM network Computer Information Sciences Washburn University of Topeka 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 Lawrence S . Brakmo, Sean W.O Malley and Larry L Peterson.TCP Vegas: New Techniques for congestion detection and avoidance Hari Balakrishnan, Venkata N. Padmanabhan, Srinivasan Seshan and Randy H. Katz1 A Comparison of Mechanisms for Improving TCP Performance over Wireless Links Andrea Goldsmithwireless Press,2005 communicationCambridge University

[2]

[3]

[4]

[5]

[6]

[7]

[8]

Alberto Leon-Garcia and Indra widjaja Communication networks fundamental concepts and key architectures 2th edition 2009 Transmission Control Protocol, RFC 793, Sep 1981.

[9]

76

[10]

Cooperative Association for Internet Data Analysis (CAIDA), Traffic Workload Overview:http://www.caida.org/outreach/resources/learn/trafficworkload/tcpudp .xml Jinwen Zhu and Tianrui Bai Performance of Tahoe, Reno, and SACK TCP at Different Scenarios Padhye, J., S. Floyd, On Inferring TCP Behavior, Computer Communications Review ACM-SIGCOMM, Vol. 31, August 2001. Stevens, W.R., TCP Slow Start, Congestion Avoidance, Fast Retransmit, and FastRecovery Algorithms, RFC 2001, 1999 V. Jacobson Congestion Avoidance and Control Communication Review, 18(4):314{ 29, August 1988. V. Jacobson. Modified TCP Congestion Avoidance report, April 1990. Proc Computer

[11]

[12]

[13]

[14]

[15]

Algorithm. Technical

[16]

Wright, G., Stevens, W. R., TCP/IP ILLUSTRATED VOLUME 2, AddisonWesley 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 Sharjeel Shahid Improving TCP Performance over Wireless Networks 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. 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 Eitan Altman and Tania Jimenez NS Simulatior for Beginner, Lecture notes 2003-2004, University De Los Andes.December 4,2003 Paul Meeneghan and Declan Delaney An Introduction to NS, Nam and OTcl Scripting NUIM-CS-TR-2004-05 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

[19] [20]

[21]

[22]

[23]

[24]

77

[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. 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. Thomas Williams & Colin Kelley Gnuplot An Interactive Plotting Program Copyright c 1986 - 1993, 1998, 2004 Thomas Williams, Colin Kelley

[27]

[28]

78

APPENDICES

79

New trace file description

Event type s r f send receive Drop forward General tag -t -t time * (global setting) Node property tags -Ni -Nx -Ny -Nz -Ne -Nl node id node's x-coordinate node's y-coordinate node's z-coordinate node energy level 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" 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

80

Packet information at IP level -Is: -Id: -It: -Il: -If: -Ii: -Iv: source address.source port number dest address.dest port number packet type packet size flow id unique id ttl value Next hop info id for this node id for next hop towards the destination. Packet info at MAC level duration dst's ethernet address src's ethernet address ethernet type Packet info at "Application level" Address Resolution Protocol. Details for ARP is given by the following tags ARP Request/Reply src mac address src address dst mac address dst address -P dsr how many nodes traversed routing request flag route request sequence number routing reply flag reply length src of srcrouting->dst of the source routing error report flag ? number of errors report to whom link error from linka->linkb -P cbr sequence number how many times this pkt was forwarded optimal number of forwards Information about TCP flow is given by the following subtags: seq number ack number how many times this pkt was forwarded
81

-Hs: -Hd:

-Ma: -Md: -Ms: -Mt:

-P arp -Po -Pm -Ps -Pa -Pd

-Pn -Pq -Pi -Pp -Pl -Pe -Pw -Pm -Pc -Pb

-Pi -Pf -Po -P tcp -Ps -Pa -Pf

-Po

optimal number of forwards

Available options for node configuration (see tcl/lib/ns-lib.tcl).

Option

Available values
general

Default

addressType MPLS WiredRouting IIType macType ifqType phyType adhocRouting propType propIinstance antType channel topoInstance mobileIP energyModel initialEnergy rxPower txPower IdlePower agentTrace routerTrace macTrace movementTrace errProc toraDebug satNodeType downlinkBW

Flat, hierachical ON, OFF Both satellite-and wireless oriented ON,OFF Ll,LL/Sat Mac/802_11,Mac/Csma/Ca, Mac/Sat, Mac/Sat/UnslottedAloha,Mac/Tdma Queue/DropTail, Queue/Droptail/Priqueue Phy/WirelessPhy, Phy/Sat Wireless-oriented DIFFUSION/RATE, DIFFUSION/PROB, DSDV, DSR,FLOODING,OMNIMCAST,AODV,TORA Propagation/TwoRayGround,Propagation/shadowing Propagation/TwoRayGround,Propagation/shadowing Antenna/Omniantenna Channel/WirelessChannel,Channel/Sat <topology file> ON,OFF EnergyModel <values in joules> <value in W> <value in W> <value in W> ON,OFF ON,OFF ON,OFF ON,OFF UniformErrorProc FEC ON,OFF Satellite-oriented Polar,geo,terminal,geo-repeater <bandwidth value, e.g. 2Mb>

Flat OFF OFF OFF OFF OFF OFF OFF OFF

82