A study of TCP performance in wired cum ad hoc environments

First, a comprehensive evaluation of different TCP algorithms performance in wired-cum-ad hoc environments is done, and the results give clear answers to questions like which TCP algorit

DEPARTMENT OF ELECTRICAL AND COMPUTER ENGINEERING

NATIONAL UNIVERSITY OF SINGAPORE

2003

Acknowledgements

I would like to express my deep and sincere gratitude to Dr Winston Seah, who guides me all the way to the ad hoc network world, and sparks this research with his constant help, tremendous efforts, and precious enlightenment I am also cordially grateful to Dr Yin Qinghe, who always gives me valuable inspirations and helpful suggestions during our discussions It is a great pleasure to have them as my supervisors, and to work with them together

I also thank NUS and I2R for providing me with this opportunity to pursue my M.Eng study here So many friends in NUS and I2R help me both in my research and

in my life here, especially I would like to acknowledge the assistance of Mr Li Feng and Mr Teh Keng Hoe

Finally, special thanks must go to my wife and my parents, who support me with their love and encourage me to do my best in life

Contents

SUMMARY IV ABBREVIATIONS VI LIST OF FIGURES VII LIST OF TABLES IX

CHAPTER 1 INTRODUCTION 1

1.1 OVERVIEW OF AD HOC NETWORKS 1

1.2 OVERVIEW OF TCP PERFORMANCE IN AD HOC NETWORKS 3

1.3 THESIS CONTRIBUTIONS 4

1.4 THESIS ORGANIZATION 5

CHAPTER 2 LITERATURE REVIEW 7

2.1 INTRODUCTION 7

2.2 PROPOSED TCP ALGORITHMS 7

2.3 TCP PERFORMANCE IN AD HOC NETWORKS 10

2.3.1 Improving TCP Performance in MANET 10

2.3.2 TCP Interactions with Lower Layer Protocols 11

2.4 SUMMARY 13

CHAPTER 3 EVALUATION OF TCP ALGORITHMS IN WIRED-CUM-AD HOC ENVIRONMENTS 14

3.1 INTRODUCTION 14

3.2 SIMULATION CONFIGURATION 14

3.3 S R D 15

3.3.1 Static Scenario without Congestion 16

3.3.2 Static Scenario with Congestion 23

3.3.3 Scenario with Node Mobility 28

3.3.4 Impact of Rerouting on Vegas Performance 33

3.3.5 Conclusions of Evaluation Results 37

3.4 SUMMARY 38

CHAPTER 4 IMPROVING FAIRNESS BETWEEN TCP FLOWS IN WIRED-CUM-AD HOC ENVIRONMENTS 39

4.1 INTRODUCTION 39

4.2 PROBLEM IDENTIFICATION 39

4.3 DESIGN OF THE SCHEME 41

4.4 SIMULATION RESULTS 43

4.4.1 Simulation Environment 43

4.4.2 Simulation Results 45

4.5 ANALYSIS AND DISCUSSIONS 55

4.6 LIMITATION OF OUR APPROACH AND FUTURE WORK 57

4.7 SUMMARY 58

CHAPTER 5 CONCLUSIONS AND FUTURE WORK 59

5.1 CONCLUSIONS 59

5.2 FUTURE WORK 60

PUBLICATION LIST 62

REFERENCES 63

Summary

With the rapid advancement in mobile computing devices and wireless communication technology, the demand for continuous network connectivity regardless of physical location has spurred interest of the use of ad hoc networks, which are instantly deployable and find their applications in disaster rescue, battlefield, and many other scenarios

Ad hoc networks may operate in a standalone fashion, or may be connected to wired networks, such as the Internet Actually many foreseeable applications of ad hoc networks require connections to be established between wired network and wireless ad hoc network for various purposes, such as Internet surfing, database update, etc We call this kind of connection patterns wired-cum-ad hoc networks As the de facto transport protocol in the Internet, TCP, is sure to be used over ad hoc networks Many researchers have studied TCP performance in ad hoc networks that operate in a standalone fashion However, few researches have been done to investigate TCP performance in wired-cum-ad hoc environments, which motivates us to conduct this research

This thesis provides an in-depth study on TCP performance in wired-cum-ad hoc networks Two important properties of TCP, throughput and fairness, are both addressed First, a comprehensive evaluation of different TCP algorithms performance

in wired-cum-ad hoc environments is done, and the results give clear answers to questions like which TCP algorithm should be implemented in this specific scenario, and how to tune TCP parameters to optimize its performance Moreover, this thesis also presents a scheme that successfully eliminates the severe unfairness between TCP

flows spanning wired and IEEE802.11-based wireless ad hoc networks Simulation results show that our scheme improves the fairness between TCP flows greatly without incurring much throughput loss

Abbreviations

AODV Ad hoc On-demand Distance-Vector routing protocol

ARP Address Resolution Protocol

cwnd Congestion Window

DSDV Dynamic Destination-Sequenced Distance Vector routing

ECN Explicit Congestion Notification

ELFN Explicit Link Failure Notification

FIFO First In First Out

FTP File Transfer Protocol

ICMP Internet Control Message Protocol

IETF Internet Engineering Task Force

maxcwnd Maximum congestion window size

SSA Signal Stability based Adaptive routing

SACK TCP Selective Acknowledgement

ssthresh TCP Slow Start Threshold

TCP Transmission Control Protocol

List of Figures

Figure 3.1 The static scenario without wired cross traffic 16

Figure 3.2 MAC layer trace of TCP and IEEE 802.11 interaction 19

Figure 3.3 Static scenario with congestion on wired links 23

Figure 3.4 TCP goodput (kb/s), CBR = 1.6 Mb/s, Exp = 0.4 Mb/s 25

Figure 3.5 TCP goodput (kb/s), CBR = 1.5 Mb/s, Exp = 0.4 Mb/s 26

Figure 3.6 Scenario for mobility impact study 29

Figure 3.7 TCP performance in mobile environments 30

Figure 3.8 Scenario for studying rerouting impact on Vegas 34

Figure 3.9 Rerouting impact on Vegas (Goodput: Kb/s) 35

Figure 3.10 Congestion window size comparison 36

Figure 4.1 Testbed for identification of unfairness 40

Figure 4.2 Scenario A for simulation 43

Figure 4.3 Goodput of normal scheme, wired link delay = 5ms 46

Figure 4.4 Goodput of our scheme, wired link delay = 5ms 46

Figure 4.5 Maxcwnd = 4, wired link delay = 5ms, normal scheme 47

Figure 4.6 Maxcwnd = 4, wired link delay = 5ms, our scheme 47

Figure 4.7 Maxcwnd = 8, wired link delay = 5ms, normal scheme 48

Figure 4.8 Maxcwnd = 8, wired link delay = 5ms, our scheme 48

Figure 4.9 Goodput of normal scheme, wired link delay = 45ms 49

Figure 4.10 Goodput of our scheme, wired link delay = 45ms 50

Figure 4.11 Scenario B for simulation 51

Figure 4.12 Goodput of normal scheme for scenario B 51

Figure 4.13 Goodput of our scheme for scenario B 52

Figure 4.14 Maxcwnd = 8, normal scheme for scenario B 53

Figure 4.15 Maxcwnd = 8, our scheme for scenario B 53

Figure 4.16 Pure ad hoc scenario with extreme unfairness 54

Figure 4.17 ACK sequence progress, normal scheme 54

Figure 4.18 ACK sequence progress, our scheme 54

List of Tables

Table 3.1 TCP goodput (W0 to node 1, kb/s) 17

Table 3.2 TCP goodput (W0 to node 2, kb/s) 17

Table 3.3 TCP goodput (W0 to node 3, kb/s) 17

Table 3.4 TCP goodput (W0 to node 4, kb/s) 17

Table 3.5 TCP goodput (W0 to node 5, kb/s) 18

Table 4.1 Parameter settings in ns 44

Table 4.2 Parameter settings in our scheme 44

Chapter 1 Introduction

1.1 Overview of Ad Hoc Networks

The Internet Engineering Task Force’s (IETF) Mobile Ad Hoc Networks (MANET) Working Group [1] describes mobile ad hoc network as an autonomous system of mobile routers (and associated hosts) connected by wireless links, the union of which forms an arbitrary graph The routers are free to move randomly and organize themselves arbitrarily Thus, the network's wireless topology may change rapidly and unpredictably Such a network may operate in a standalone fashion, or may be connected to the larger Internet In real applications, ad hoc networks are multiple hop wireless networks consisting of a large number of radio-equipped nodes that may be as simple as autonomous (mobile or stationary) sensors to laptops mounted on vehicles or carried by people

Ad hoc networks have several salient features that make it different from wired network, and cellular network:

• Node Functions Each node in wireless ad hoc networks not only plays the role

of a communication endpoint, but also a router between nodes that are multiple hops apart, i.e., every node has the obligation to forward packets for others besides enjoying services from other nodes

• Node Mobility The unpredictable movement of nodes leads to rapidly

changing network topology as well as frequent link breakages, which pose tough challenges on the design of routing protocol, and affect TCP performance severely

Chapter 1 Introduction

• Node Operation Each node depends on batteries to provide energy for

transmission and processing, thus power must be conserved at every node to maximize node lifetime Meanwhile, the raw bandwidth of the wireless channel

is limited Media access contention, fading and interference make the effective bandwidth even much less than the raw bandwidth In short, ad hoc nodes operate in a power-constrained and bandwidth-constrained mode

Ad hoc networks are self-organizing and instantly deployable, thus it is very suitable for those situations where the fixed infrastructure does not exist or is destroyed as well

as situations where it is not suitable or impossible for men to access It finds its important applications in battlefield, disaster rescue, etc In fact, with the rapid development of communication technology and constant optimization of network protocol performance, the scope of MANET applications will be broadened further to include many civilian applications

Besides operating standalone, sometimes ad hoc nodes may need to establish connections with servers in wired networks We call this kind of connection patterns

“wired-cum-ad hoc networks” For example, a node that finds the potential target may need to send the collected data back to its command center for processing and further decisions; or the command center needs to update the node with the latest target information or database Another foreseeable and important application is that the ad hoc nodes may need to access the Internet at times With the popularity of the Internet, this may become a basic feature of the future commercial products of ad hoc networks All the above applications require TCP connections to span both wired domain and wireless ad hoc domain

1.2 Overview of TCP Performance in Ad Hoc Networks

The Transmission Control Protocol (TCP) is a reliable, connection-oriented, duplex transport protocol It is used by many end-user applications, such as Web browser, e-mail, and FTP Actually the vast majority of today’s Internet traffic is carried by TCP As the de facto transport protocol on the Internet, the use of TCP over

full-ad hoc networks is a certainty

TCP assumes packet loss as a signal of network congestion If it observes successful transmission of its packets, TCP will increase the congestion window gradually to detect extra bandwidth Once packet loss is detected, TCP will invoke congestion control measures to avoid further congestion, such as reduction of congestion window,

or exponential backoff of the retransmission timer In this way, TCP successfully avoids the likely network collapse caused by congestion while fully utilizing the network resource dynamically

TCP is designed and tuned well for wired networks over these years However, in ad hoc environments, the assumption of TCP that packet loss signals congestion becomes quite problematic Besides packet loss caused by inherent wireless channel errors, which has been extensively studied and solved by numerous works in research on TCP performance in general wireless environments, one unique characteristic of ad hoc networks, node mobility, poses severe challenges on TCP

The random movement of nodes causes frequent link breakages, or worse, network partitions, which forces TCP to invoke congestion control The problem does not lie in the fact that TCP invokes congestion control, but lies in the fact that even if new route

is found, TCP may need several RTTs to finish the slow start phase to fully utilize the available bandwidth, or in the worst case TCP may be still be in the backoff state waiting for next timeout to send the packet again, both of which result in low

Chapter 1 Introduction

throughput and waste of network resources Moreover, in ad hoc networks, TCP performance is deeply affected by the underlying routing protocol and MAC protocol, which often play determinant roles in the performance TCP can achieve The mechanisms of lower layer protocols may have great impacts on TCP performance through their interactions with the TCP algorithms

Many researches have been done to study TCP performance in pure ad hoc

networks However, no research has been done to evaluate different TCP

algorithms’ performance in wired-cum-ad hoc environments This is the first

motivation of our research Furthermore, [2] found the extreme unfairness between

TCP connections crossing wired network and wireless ad hoc network, but no solution

has been proposed in the literature, this is the second motivation of our research

• We show that New Reno and SACK are the best candidates for deployment As far as the ability to handle congestion, New Reno and SACK are clearly better than Reno Meanwhile, compared with Vegas, New Reno and SACK perform more robustly in all scenarios The performance difference between New Reno and SACK is slight and there is no obvious winner Vegas may lead to

significant throughput loss in wired-cum-ad hoc environments because it cannot always update its notion (c.f section 2.2 and chapter 3) of base RTT accordingly when rerouting occurs Therefore, Vegas cannot be deployed until there is practical solution for this problem, though Vegas outperforms other TCP variants in some static scenarios and is recommended as the best TCP algorithm for ad hoc environments by some previous research in the literature

• We have determined that the value of TCP minimum RTO has great impact on TCP performance in mobile environments The choice of its value and the impact brought by RTO rounding up behavior recommended in RFC2988 deserves further research It is clear that to achieve a desirable throughput, TCP

maxcwnd for end hosts of the wired-cum-ad hoc connection should be set to

large values as long as it is allowed by their buffer capacity

• Lastly, this thesis presents a scheme to eliminate the extreme unfairness between TCP flows crossing wired network and wireless ad hoc network It is the first scheme proposed in the literature to tackle this issue and it improves the fairness greatly without significant throughput loss, though this scheme is not perfect in eliminating the unfairness in all scenarios The heuristic in the scheme is also very helpful for future use in the design of MAC protocols for wireless ad hoc networks

1.4 Thesis Organization

In the remaining part of this thesis, we first review the prevalent TCP algorithms and existing TCP performance studies in Chapter 2 Chapter 3 presents the thorough performance evaluation of different TCP algorithms in wired-cum-ad hoc environments After studying TCP performance from a throughput perspective, Chapter 4 describes our scheme and shows that it is able to eliminate the severe

Chapter 1 Introduction

unfairness between TCP flows crossing wired network and wireless ad hoc network Then, Chapter 5 concludes this thesis and points out future work A publication list follows the five chapters

Chapter 2 Literature Review

2.2 Proposed TCP Algorithms

There are four prevalent and widely recognized TCP algorithms, viz Reno [5], New Reno [6], SACK [7], and Vegas [8] Actually, most TCP variants are Reno-based except Vegas Therefore, we sometimes use “Reno-based TCP” to refer to Reno, New Reno, and SACK Vegas differs from others in its unique congestion avoidance technique For a better understanding, we introduce Reno first Five mechanisms characterize the behavior of Reno:

• Slow start: Beginning from one packet or a larger value, cwnd (congestion

window) is increased by one for every received non-duplicate ACK, until the

source’s estimation of network capacity, ssthresh (slow start threshold), is reached During slow start phase, cwnd is increased exponentially, aiming to

alleviate the burstiness of TCP while quickly filling the pipe

Chapter 2 Literature Review

• Congestion avoidance: Once cwnd exceeds ssthresh, a TCP sender switches to

a slower cwnd increase rate of one packet for every window's worth of ACK This phase is called congestion avoidance, during which cwnd grows linearly

to detect any extra bandwidth

• Timeout: TCP sender maintains a retransmission timer to ensure data delivery

in the absence of any feedback from the remote data receiver If the desired ACK does not come back within the timer duration, TCP will go to slow start again, backoff RTO (Retransmission TimeOut) exponentially, and retransmit the earliest unacknowledged packet

• Fast retransmission: If three or more duplicate ACK are received in a row,

TCP assumes it as a strong indication that a packet has been lost It then performs a retransmission of what appears to be the missing packet, without

waiting for the retransmission timer to expire This is called fast retransmission, which avoids timeout for a single packet loss and leads to

higher channel utilization and throughput

• Fast recovery: After fast retransmission of what appears to be the missing

packet, congestion avoidance instead of slow start is performed This is fast recovery ssthresh is set to half of the cwnd value When the ACK that acknowledges new data arrives, TCP set cwnd to ssthresh and increase cwnd

linearly

Based on Reno, both New Reno and SACK improve Reno’s ability to handle multiple packet losses in a single window of data, which is common in heavily congested networks or wireless environments

New Reno modifies Reno by incorporating a response to partial acknowledgement received during fast recovery to keep TCP in fast recovery state until all the data lost

from that window has been recovered New Reno successfully avoids multiple reductions of congestion window in fast recovery and reduces the chance of retransmission timeout

Due to the limited information available from cumulative acknowledgment, a Reno sender can only learn about a single lost packet per RTT To overcome this limitation, SACK introduces the selective acknowledgment mechanism to inform a TCP sender of the packets that have been correctly received, combined with the selective repeat retransmission policy, which makes the TCP sender retransmit only those missing data packets

TCP Vegas, however, differs significantly from the above three TCP algorithms in three aspects:

• New congestion avoidance technique: In every RTT, Vegas computes the

difference between expected throughput and actual throughput It compares the difference with two thresholds, α and β According to the result of comparison,

it decides to increase cwnd, or decrease cwnd, or keep the current cwnd size

• New retransmission mechanism: Vegas keeps a fine-grained timer for every

packet it sent Whenever it receives a duplicate ACK, it checks if this timer has expired If so, Vegas retransmits the corresponding packet without waiting for three duplicate ACK When receiving the first or second ACK after retransmission of lost packet, Vegas checks this timer again

• Modified slow start behavior: Vegas uses a congestion detection mechanism,

which is similar to its congestion avoidance technique, to decide when to change to congestion avoidance phase This makes it less likely to overshoot the network during slow start phase

Chapter 2 Literature Review

TCP Vegas uses the smallest RTT it experiences as base RTT to compute the expected throughput However, in ad hoc networks node mobility causes frequent rerouting and thus the base RTT should also be updated in time to reflect this fact Therefore, whether Vegas can update its notion of base RTT correctly may affect its performance in ad hoc environments This thesis will address this issue in Chapter 3

In short, Vegas does congestion control based on its inference of network condition

On the contrary, Reno-based TCP algorithms keep increasing congestion window until packet loss occurs, i.e., they detect congestion by creating packet loss Therefore, Vegas is proactive whereas Reno, New Reno, and SACK are reactive

2.3 TCP Performance in Ad Hoc Networks

Generally speaking, research efforts on TCP performance in ad hoc environments can

be classified into two categories:

• Proposals for improving TCP performance in ad hoc networks

• Studies on cross-layer interactions between TCP and lower layer protocols Therefore, our survey is also presented following this classification

2.3.1 Improving TCP Performance in MANET

Holland and Vaidya [9] investigate the impact of frequent link breakages on TCP performance They show that TCP’s inability to differentiate congestion loss from the link failure loss leads to significant throughput degradation They propose an approach called Explicit Link Failure Notification (ELFN), the objective of which is to let the routing protocol provide TCP with route failure information so that TCP can avoid responding to route failures as if congestion occurred Upon receiving ELFN, a TCP source suspends packet transmission and freezes its state, including retransmission timer and congestion window Meanwhile, it probes the network periodically to see if a

new route is established After finding a route, the sender restores its previous state instantly and resumes as normal Chandran et al propose a similar scheme called TCP-Feedback or TCP-F [10] It differs from TCP-ELFN in the fact that instead of probing the network, TCP-F relies on Route Reestablishment Notification (RRN) provided by the underlying routing protocol to know when route is reestablished

These feedback-based schemes rely on route failure information from routing protocols, which makes them expensive for deployment due to their dependence on specific routing protocol In addition, Monks et al [11] show that with this approach TCP throughput may be degraded by false routing failure notification, which is caused

by MAC layer contentions and leads to frequent unnecessary TCP source freezing Liu and Singh [12] propose ATCP, which does not require information from the routing protocol They add a thin layer to listen for network state information provided

by ECN [13] and ICMP [14] ECN is used to provide congestion indication, whereas ICMP message “Destination Unreachable” is used to provide link failure information With this approach, the TCP stack need not to be modified, but the requirement of implementing ECN and ICMP on every ad hoc node really increases the complexity Wang and Zhang [15] present TCP-DOOR where a TCP sender can distinguish route changes from network congestion by detection of out-of-order delivery, thereafter improve the performance of TCP by not invoking unnecessary congestion control The advantage of their approach is that it does not rely on any feedback from the lower layer, which makes it easy to implement and also applicable to wired-cum-ad hoc environments, though it may be not as efficient as those feedback-based schemes

2.3.2 TCP Interactions with Lower Layer Protocols

Tang and Gerla [16] provide insights into the interactions between TCP and various MAC layer protocols in multi-hop networks In particular, they address the issue of fair

Chapter 2 Literature Review

sharing of MAC with multiple TCP flows Their results indicate that further research is necessary to make TCP and MAC layer protocol work consistently well together in ad hoc environments

Xu and Gerla [2] investigate the fairness issue between TCP connections across wireless ad hoc network and the Internet with testbed implementation They show that unfair channel sharing between TCP flows leads to extreme unfairness, which often forces some TCP flows to stop transferring any more data despite all links being in good states It is the first and only research that studies TCP behavior in wired-cum-ad hoc environments

Xu and Saadawi [17] evaluate several prevalent TCP algorithms performance in pure ad hoc networks They argue that Vegas performs best in most cases due to the interactions between TCP and IEEE 802.11 protocol [18] They also recommend using four segments as TCP maximum window size, at which TCP performs best and all TCP variants differ little in their performance

Meanwhile, several researchers study the TCP performance over different routing protocols in ad hoc networks Dyer and Boppana [19] compare TCP performance over on-demand routing protocols and over adaptive proactive routing protocols They argue that the adaptive proactive routing protocols are better for TCP than on-demand protocols A simple heuristic, fixed-RTO, is also proposed to improve TCP throughput Ahuja et al [20] compare TCP performance over DSDV [21], DSR [22], AODV [23], and SSA [24] routing protocols They find that SSA prefers the stable routes, whereas DSR and AODV prefer shorter routes, which makes the former help TCP to achieve higher throughput in highly mobile environments

on TCP parameter tuning, such as how to set TCP maximum congestion window size, and how to set TCP minimum retransmission timeout value On the one hand, not all the conclusions drawn from pure ad hoc scenarios hold in wired-cum-ad hoc scenarios

On the other hand, compared with traditional wired-cum-wireless network that only has one hop in wireless domain, wireless-cum-ad hoc network differs in that it has multiple wireless hops Moreover, TCP performance over wired-cum-ad hoc network

is a topic that has seldom been investigated before in the literature, as opposed to TCP performance over traditional wired-cum-wireless network that has been intensively studied This is just the reason why this thesis specially focuses on TCP performance study in wired-cum-ad hoc environments

Chapter 3 Evaluation of TCP Algorithms in Wired-cum-Ad Hoc Environments

3.1 Introduction

As described in Chapter 1 and Chapter 2, it is very likely for TCP to be used in the wired-cum-ad hoc environments However, no work has been done to investigate which TCP algorithm should be adopted, and how TCP parameters should be tuned to improve its performance Bearing these questions in mind, we start our work in this chapter

Section 3.2 introduces the simulation configuration In Section 3.3, we evaluate different TCP algorithms’ performance in various scenarios in the wired-cum-ad hoc environments Based on the evaluation results, we present a recommendation on TCP implementation in this section as well Finally, Section 3.4 concludes our work in this chapter

3.2 Simulation Configuration

We use the NS simulator [25] with ad hoc extensions provided by MONARCH project [26] to perform simulations The four prevalent TCP algorithms, viz Reno [5], New Reno [6], SACK [7], and Vegas [8] are evaluated FTP session with infinite backlogs

is used to generate TCP traffic DSR [22] is selected as routing protocol for our targeted wired-cum-ad hoc scenarios NS implements the IEEE 802.11 MAC protocol’s Distributed Coordination Function at MAC layer

The buffer management policy for both wired and wireless nodes is drop-tail with queue limit of 50 packets, unless otherwise stated All packet size of TCP, CBR, and exponential traffics are 1000 bytes Here, exponential traffic refers to the widely used ON/OFF traffic During ON periods, packets are generated at a constant burst rate During OFF periods, no traffic is generated Burst times and idle times are taken from exponential distributions The wireless parameter settings are modeled after the commercially available WaveLAN product with a bandwidth of 2 Mb/s and a nominal transmission range of 250 meters In all static scenarios, each wireless node is 200 meters apart, which allow them only to communicate with their immediate neighbors successfully TCP receiver enables delayed acknowledgement option [27] Two reasons make us decide to use delayed acknowledgement First, most of the hosts on the Internet enable this option Second, [17] shows that in pure ad hoc networks delayed acknowledgement improves TCP throughput We use goodput as the metric for evaluation We compute goodput as the number of bits received by the receiver in a unit time, excluding those duplicate data

3.3 Simulation Results and Discussions

In this section, we study TCP performance in wired-cum-ad hoc networks step by step First, we study TCP performance in the simplest scenario where there is no background traffic and no mode mobility Second, we add background traffic to study congestion impacts on TCP performance in the wired-cum-ad hoc networks Third, we take node mobility into considerations Lastly, we specially point out that Vegas is not

a robust TCP algorithm under mobile environments because it may not always update its notion of base RTT accordingly after rerouting

Chapter 3 Evaluation of TCP Algorithms

3.3.1 Static Scenario without Congestion

Figure 3.1 The static scenario without wired cross traffic

Figure 3.1 shows a simple wired-cum-ad hoc network where all the ad hoc nodes are static In each simulation, TCP traffic is sent from node W0 to wireless nodes 1, 2, 3,

4, and 5 respectively TCP connection starts at 0 second and ends at 100 second All the simulation results shown are the average of ten runs To investigate how the

maximum congestion window size (maxcwnd) value affects TCP performance, we run each simulation with different maxcwnd value, viz 1, 4, 8, 16, and 32 packets,

respectively Both the wired link between W0 and W1, as well as the link between W2 and BS has a propagation delay of 2ms with a bandwidth of 10 Mb/s, whereas those of the link between W1 and W2 are 5ms and 2 Mb/s, respectively

Table 3.1 TCP goodput (W0 to node 1, kb/s)

Table 3.2 TCP goodput (W0 to node 2, kb/s)

Table 3.3 TCP goodput (W0 to node 3, kb/s)

Table 3.4 TCP goodput (W0 to node 4, kb/s)

Chapter 3 Evaluation of TCP Algorithms

Table 3.5 TCP goodput (W0 to node 5, kb/s)

high enough maxcwnd value is a must Here, our simulation results suggest that there

are different requirements on TCP parameter tuning in pure ad hoc networks and in wired-cum-ad hoc networks In pure ad hoc networks, both [16] and [17] have shown that a small window value does not degrade goodput However, in wired-cum-ad hoc networks a high enough window value is a premise to achieve satisfactory goodput One thing to note is that in some scenarios, the goodput of Vegas is slightly lower than that of others, about 2% to 3% We find that this is mainly caused by the rounding operation during computing of Vegas threshold α and β in the NS implementation However, the results in Table 3.3, 3.4, and 3.5 interest us with the fact that the goodput

of TCP Reno, New Reno, and SACK begin to drop once the maxcwnd size exceeds

some value whereas Vegas keeps its goodput stable regardless of the increase of

maxcwnd value After analysis, we find that this phenomenon is due to the same

reason, as reported in [17] for the case of pure ad hoc networks They call it

Figure 3.2 MAC layer trace of TCP and IEEE 802.11 interaction

(Reno, node W0 to node 4, maxcwnd = 16)

Figure 3.2 illustrates the reason Node 0 in Figure 3.2 refers to node BS, the base station node We can see that node BS tries to reach node 1 by sending RTS to node 1 seven times before it decides that the link between them are broken and drops the queued packets, though in fact all links are in good states After node BS sends out the first RTS, actually node 1 successfully receives it But, node 1 cannot reply with CTS because it senses that node 3 is transmitting The following two RTS attempts of node

BS result in collisions at node 1 because node 3 is still sending the TCP packet with sequence number 512, which is much longer than RTS message After some backoff period, node BS tries to reach node 1 with another 4 RTS attempts, but all collide at node 1 with the transmissions of TCP packet 513 and packet 514 from node 3 After seven retries, node BS comes to the wrong conclusion that the link is broken, drops the queued packets and initiates new route request TCP sender at W0 may timeout sometimes because of the packet dropping and the extra delay introduced

Chapter 3 Evaluation of TCP Algorithms

The root cause of this phenomenon is the exposed node problem and hidden node problem at MAC layer In detail, to ensure reliable reception in wireless communication, the node’s sensing range and interfering range is much larger than the communication range Node BS is out of the interfering range of node 3 and cannot sense whether node 3 is transmitting, but its intended receiver, node 1, is within the interfering range of node 3, though node 1 cannot correctly receive packets from node

3 In simulation of W0 to node 1 as well as simulation of W0 to node 2 there is no such problem, because once there is only one or two hops in the wireless domain of the wired-cum-ad hoc connection, all the relevant ad hoc nodes are within the interfering and sensing range of each other

All Reno-based TCP algorithms, such as Reno, New Reno, and SACK, detect congestion by increasing the congestion window persistently to create loss This greatly increases the chance of occurrence of “instability problem” In contrast, Vegas decides to increase, decrease, or maintain the current congestion window value by

comparing the expected throughput with the measured throughput The maxcwnd

setting is only an upper limit for it and Vegas adjusts the congestion window according

to its own perception of the network condition On the one hand, Vegas estimates the end-to-end pipe capacity well and adjusts its congestion window accordingly On the other hand, Vegas seldom over-fills the pipe because once it finds that throughput cannot benefit from the increase of congestion window, Vegas will keep its current congestion window value Therefore, Vegas reduces the probability of occurrence of

“instability problem”

We change the bandwidth and delay of the link between W1 and W2 to 500 kb/s and 100ms The round trip time and pipe capacity are changed accordingly Again, the simulation results reveal the challenges that Reno-based TCP algorithms face in wired-

cum-ad hoc environments: A large maxcwnd value will exacerbate the IEEE 802.11

inefficiency in multiple hops wireless networks and lead to unnecessary throughput

loss, but a small maxcwnd value wastes network resource and yields low throughput

However, it is hard for TCP to get the end-to-end pipe capacity information in advance because the capacity varies with the delay and bandwidth of the wired links On the contrary, Vegas generally does not have this problem

During extensive simulations, we also find that in either of the situations below, the

“instability problem” will not happen even if maxcwnd of Reno-based TCP algorithms

is very high:

• Bandwidth of wired bottleneck link is lower than the effective bandwidth of wireless channel Here, effective bandwidth is usually much lower than the raw channel bandwidth due to MAC layer media contentions Roughly, the

effective bandwidth of an n-hop ad hoc connection is equivalent to the goodput achieved by this n-hop connection in a pure ad hoc network without cross

traffic

• Congestion exists on wired link of the wired-cum-ad hoc connection

This is reasonable, because once the wired link is the bottleneck due to its low bandwidth, or there is congestion on wired link, TCP packets are sure to be congested

in wired domain rather than in ad hoc nodes, which greatly reduces the intensity of media contentions

The “instability problem”, as reported in [17], was first noticed on pure ad hoc

networks They recommend using 4 packets as the TCP maxcwnd value and report that

at this value, TCP performs best and all TCP variants differ little in performance Our results show that not only in pure ad hoc networks, but also in wired-cum-ad hoc networks, the “instability problem” still exists Furthermore, we show that the

Chapter 3 Evaluation of TCP Algorithms

recommended 4 packets setting is not suitable for those ad hoc networks, the nodes of which may communicate via the Internet or with other wired network hosts at times, because a small congestion window that fails to fill the pipe may lead to unacceptably low throughput and the degradation is usually much more severe than the degradation caused by “instability problem”

From IETF’s definition of MANET [1] and the results we obtain, we argue that performance evaluation of TCP algorithms must be done both in pure ad hoc environments and in wired-cum-ad hoc environments before choices are made on TCP parameter tuning and which TCP variant to adopt, unless the targeted deployment scenario only requires communications between ad hoc nodes However, there is no doubt that future commercial products with TCP algorithm that address the requirements of both environments will be more popular

During simulation, we also find that besides the above static scenarios, even in mobile ad hoc networks, the “instability problem” persists But two reasons make it difficult to be noticed First, frequent route changes cause most links to be used only for a limited time The link may be broken even before enough contentions occur to cause the problem, i.e mobility alleviates the “instability problem” Second, current studies of TCP performance over MANET usually define an area, and let nodes move randomly within the area according to some parameters, then use throughput as the performance metric, which is the average of the throughput achieved in all possible hop count situation We know that the “instability problem” only occurs when wireless hop count is equal or greater than three The throughput obtained in large hop count scenarios only constitutes a small fraction of the final result This is another reason why the “instability problem” is rarely observed in mobile environments

3.3.2 Static Scenario with Congestion

In reality, when there are communications between Internet hosts and ad hoc nodes, the congestion on the Internet is unavoidable Therefore, in this section, we add cross traffic to study how congestion on wired links affects different TCP algorithms’ performance

Figure 3.3 Static scenario with congestion on wired links

In Figure 3.3, node W3 sends CBR traffic to node W5 while node W4 sends exponential ON/OFF traffic to node W6 In each simulation, there is one TCP connection from node W0 to one of the ad hoc node The link between W1 and W2 is the bottleneck contended for by TCP, CBR, and exponential traffic Its bandwidth is 2 Mb/s and its delay is 5ms The bandwidth of every other wired link is 10 Mb/s with 2ms delay Both TCP and CBR traffic start at 0s The starting time of exponential traffic depends on its first state If it is ON, the exponential traffic will start at 0s, too Each simulation runs 300 seconds and all the results shown are the average of thirty runs Buffer size of all wired and wireless nodes are 50 packets except that in different simulations, the buffer sizes of W1 to W2 are set to 8 and 32 packets, respectively

TCP maxcwnd value is 32 packets

Chapter 3 Evaluation of TCP Algorithms

Figure 3.4 and Figure 3.5 show TCP goodput obtained under different background traffic situations In Figure 3.4, CBR traffic rate is 1.6 Mb/s and the rate of exponential traffic in the ON period is 0.4 Mb/s with average ON period lasting 2500ms and average OFF period lasting 1500ms In Figure 3.5, CBR traffic rate is 1.5 Mb/s and the rate of exponential traffic in ON period is 0.4 Mb/s with average ON/OFF periods lasting 2000ms each

Both Figure 3.4 and Figure 3.5 demonstrate that New Reno, SACK, and Vegas constantly perform much better than Reno in handling the congestion on wired link This is not surprising because these three algorithms have been proposed as improvement schemes of Reno Among New Reno, SACK, and Vegas, none outperforms the others in all situations, and the performance differences between these three algorithms are much smaller than the performance gap between Reno and them Just as we pointed out in last section, with congestion on wired links, Vegas no longer shows any advantage over others because the congestion greatly alleviate media contentions in wireless domain

120 130 140 150 160 170 180

(A) Bottleneck buffer size = 32

1 2 3 4 5 80

85 90 95 100 105 110 115 120 125

(B) Bottleneck buffer size = 8 Figure 3.4 TCP goodput (kb/s), CBR = 1.6 Mb/s, Exp = 0.4 Mb/s

ON = 2500ms, OFF = 1500ms

180 200 220 240 260 280 300 320

(A) Bottleneck buffer size = 32

Chapter 3 Evaluation of TCP Algorithms

140 160 180 200 220 240 260

(B) Bottleneck buffer size = 8 Figure 3.5 TCP goodput (kb/s), CBR = 1.5 Mb/s, Exp = 0.4 Mb/s

ON = 2000ms, OFF = 2000ms

An interesting observation is that TCP goodput does not always drop with the increase of hop count, which is beyond our expectation because previously reported results [9] and our results in Table 3.1 to Table 3.5 show that in ad hoc environments, TCP goodput usually drops drastically with the increase of hop count But, in Figure 3.4.B and Figure 3.5.B, for all TCP algorithms the goodput of the connection with one wireless hop is lower than that of connection with two wireless hops This phenomenon becomes less significant in both figures when bottleneck buffer size is increased from 8 to 32 packets

Although this phenomenon is counter-intuitive, we find that it is reasonable after analysis When there is no congestion or light congestion, generally speaking, a connection with shorter RTT is expected to achieve better throughput than a connection with longer RTT But, once congestion intensifies, it is not the case The TCP connection with shorter RTT injects traffic into the network more aggressively compared with the connection with longer RTT This aggressiveness brings about two

effects: First, it helps TCP compete with other traffics Second, it aggravates the congestion and puts TCP itself in a situation where its packets are more likely to be dropped due to congestion, which makes it suffer from throughput loss This is also the reason why when bottleneck buffer size is increased from 8 to 32 packets, this phenomenon is less significant

To quantify our analysis, we record the number of packets dropped at the bottleneck link When the TCP connection is from node W0 to node 1, the highest acknowledgement number is 2223 with 370 TCP packets dropped during the 300s simulation, whereas with the same background traffic when the connection is from node W0 to node 2, the highest acknowledgement number is 2929 with 346 TCP packets dropped We develop a metric, Drop-to-ACK-Ratio (DAR), which is the ratio between the number of TCP packets dropped and the highest acknowledgement generated DAR for the former is 16% In a sharp contrast, DAR for the latter is only 11% This clearly justifies our inference, i.e., in a heavy congested situation, a connection with shorter RTT may be the victim of its aggressiveness

We also run simulations with other background traffic combinations to simulate different levels of congestion, all of which validate our conclusions below:

• Congestion existing on wired links efficiently levels the performance gap between wired-cum-ad hoc connections with different wireless hops TCP goodput degradation with the increase of hop count is not that drastic as in scenarios without congestion

• New Reno, SACK, and Vegas perform much better than Reno in handling congestion But, there is no obvious winner among these three in wired-cum-

ad hoc networks

Chapter 3 Evaluation of TCP Algorithms

3.3.3 Scenario with Node Mobility

In this section, we investigate the impact of mobility on TCP performance in cum-ad hoc environments Our mobility model consists of 30 mobile nodes in a 1500m

wired-x 300m rectangular area All nodes move according to the random waypoint model, i.e., each node randomly selects a destination in the specified area and then goes to that destination in a straight line with a selected speed that is uniformly distributed between zero and the specified maximum speed After arriving at the destination, it pauses according to the pause time setting, then chooses another destination randomly and repeats above procedures We set the maximum moving speed of nodes to 20 m/s and pause time to 0 second, which means all wireless nodes are always in motion during simulation

Figure 3.6 illustrates the scenario used for simulation The base station node, node

BS locates at point (750, 20) with 30 mobile nodes moving in the 1500m x 300m area Bandwidth and delay of the link between node W1 and W2 is 2 Mb/s and 5ms whereas each other wired link has a bandwidth of 10 Mb/s with a delay of 2ms One TCP connection is from node W0 to a randomly selected ad hoc node in each simulation

with TCP maxcwnd value of 32 packets Each simulation runs 1000 seconds and all the

results shown are the average of results obtained over 30 mobility patterns Besides the TCP connection, no other traffic is introduced in the simulation because our primary objective is to study how TCP algorithms perform in mobile environments