IMPLEMENTATION AND EVALUATION OF A PERFORMANCE ENHANCING ...kom.aau.dk/group/03gr996/documentation/master_thesis_aau.pdf · implementation and evaluation of a performance enhancing

IMPLEMENTATION AND EVALUATION OF A PERFORMANCE

ENHANCING PROXY FOR WIRELESS TCP

Master Thesis

by

Dennis Dungs

Department of Communication Technology

Wireless Networking Group / IP Lab

Aalborg University

Niels Jernes Vej 12

9220 Aalborg

IMPLEMENTATION AND EVALUATION OF A PERFORMANCE

ENHANCING PROXY FOR WIRELESS TCP

Project Period: September 1st 2003 - March 30th 2004

Author: Dennis Dungs

Supervisor: Assoc. Prof. Hans-Peter Schwefel

Number of pages: 138

Number of copies: 7

Abstract:

Future mobile networks are expected to support heterogenous wireless access technologies allowing

vertical handover between these technologies. Different access technologies have been developed

and optimized for maximum throughput and mobility support mechanisms have been deployed to

prevent breakdowns of the communication between distributed systems. The Transmission Control

Protocol (TCP) is known to potentially show performance degradations in wireless settings and

TCP proxies modifying the TCP congestion control behavior are a common method to overcome

these inefficiencies.

This thesis will examine if those assertions can be proven when Wireless LAN or Bluetooth is used

as wireless link in an experimental network. Based on these results, an implementation of a TCP

proxy is presented and evaluated.

Dedicated to my family

iii

iv

Table of Contents

Table of Contents v

List of Tables viii

List of Figures xi

Abstract xv

Acknowledgements xvii

1 Introduction 1

2 Background 32.1 ISO/OSI Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 The TCP Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 Goals of TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.2 The TCP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.3 Connection Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.4 Data Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.5 Connection Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 TCP Flavours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.1 Common TCP Flavours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.2 TCP Flavours using TCP Header Options . . . . . . . . . . . . . . . . . . . . 182.3.3 Wireless TCP Flavours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.4 Other TCP Flavours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.4 Wireless Access Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.4.1 Introduction to Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.4.2 Introduction to Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3 Evaluation Method 293.1 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1.1 Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.1.2 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.1.3 Traffic Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2 Measurement procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

v

3.3 Performance Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.3.1 Instantaneous Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.3.2 Instantaneous Averaged Throughput . . . . . . . . . . . . . . . . . . . . . . . 413.3.3 Transmission Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.3.4 Round-Trip Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.3.5 Handover delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.3.6 Other Performance Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4 Evaluation of standard TCP 474.1 TCP over Ethernet and Serial Links . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.1.1 Influence of Test-Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.1.2 Influence of Serial links on Performance . . . . . . . . . . . . . . . . . . . . . 49

4.2 TCP over Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.2.1 General Performance of TCP over WLAN . . . . . . . . . . . . . . . . . . . . 544.2.2 Curve fitted Transmission Throughput . . . . . . . . . . . . . . . . . . . . . . 584.2.3 Influence of Bit Error Rates on TCP Performance . . . . . . . . . . . . . . . 614.2.4 Influence of Cross-Traffic on TCP Performance . . . . . . . . . . . . . . . . . 634.2.5 Influence of Handovers on TCP Performance . . . . . . . . . . . . . . . . . . 68

4.3 TCP over Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.3.1 Performance of a Bluetooth link in adhoc scenario . . . . . . . . . . . . . . . 714.3.2 Throughput of a Bluetooth link using an access point . . . . . . . . . . . . . 75

4.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5 Implementation of the TCP Proxy 835.1 Proxy Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.2 The Split TCP Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.4 Proxy Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.4.1 Meta-Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.4.2 TCP proxy with handover support in intrasubnet handovers . . . . . . . . . . 875.4.3 TCP proxy with handover support in intersubnet handovers . . . . . . . . . . 885.4.4 TCP proxy without proxy handover . . . . . . . . . . . . . . . . . . . . . . . 885.4.5 TCP proxy with Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.4.6 Conclusion about the Proxy Location . . . . . . . . . . . . . . . . . . . . . . 91

5.5 Network Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.5.1 Header Option Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.5.2 IP Tunneling Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945.5.3 In-Path Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955.5.4 ARP Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965.5.5 Routing Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975.5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

5.6 Proxy Functionality and Software Architecture . . . . . . . . . . . . . . . . . . . . . 1005.6.1 Mirroring Proxy Implementation . . . . . . . . . . . . . . . . . . . . . . . . . 1005.6.2 Split TCP Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.6.3 Mobile IP Daemon Implementation . . . . . . . . . . . . . . . . . . . . . . . . 105

vi

6 Evaluation of the TCP Proxy in Wireless Scenarios 1076.1 Influence on RTTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076.2 Influence of Delayed ACKs on Throughput . . . . . . . . . . . . . . . . . . . . . . . 1086.3 Influence of the Delay-ACK Timer on Throughput . . . . . . . . . . . . . . . . . . . 1106.4 Further Evaluations and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7 Conclusion 113

A TCP 117A.1 The TCP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117A.2 TCP Flavours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

A.2.1 Vegas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118A.2.2 Forward Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120A.2.3 Total Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121A.2.4 Header Checksum Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122A.2.5 Transactional TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123A.2.6 Multicast TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124A.2.7 Smooth-Start + Dynamic Recovery . . . . . . . . . . . . . . . . . . . . . . . 125A.2.8 TCP Pacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

B Hardware Specification 129

C Additional Related Measurement Results 133

D Performance Test Tools 137D.1 IPerf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137D.2 Ethereal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137D.3 tcptrace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138D.4 UDPBurst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Bibliography 140

vii

viii

List of Tables

3.1 Overview of different Access Technology Parameters . . . . . . . . . . . . . . . . . . 38

4.1 Comparison of transmission times with Ethereal disabled/enabled . . . . . . . . . . . 48

4.2 UDP Throughput over 8 MBit/s serial links . . . . . . . . . . . . . . . . . . . . . . . 51

4.3 Statistical Performance Parameters of UDP over Wireless LAN . . . . . . . . . . . . 55

4.4 Statistical Performance Parameters of TCP over Wireless LAN . . . . . . . . . . . . 57

4.5 Statistical Comparison between UDP and TCP over Wireless LAN . . . . . . . . . . 57

4.6 Curve fitted Transmission Throughput parameters . . . . . . . . . . . . . . . . . . . 59

4.7 Transmission throughput of a TCP stream competing with a 500 kBit UDP stream

over Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.8 Cumulative Transmission Throughput of TCP over Wireless LAN with different con-

stant packet rate UDP stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.9 Handover delays of TCP in a WLAN handover scenario . . . . . . . . . . . . . . . . 70

4.10 Average Transmission Throughput of UDP after 10s in a Bluetooth Adhoc Scenario 73

B.1 Hardware specifications of used routers . . . . . . . . . . . . . . . . . . . . . . . . . . 129

B.2 Hardware specifications of used switches . . . . . . . . . . . . . . . . . . . . . . . . . 129

B.3 Hardware specifications of used WLAN access point . . . . . . . . . . . . . . . . . . 129

B.4 Hardware specifications of used PAN access point . . . . . . . . . . . . . . . . . . . . 130

B.5 Hardware specifications of used fixed hosts . . . . . . . . . . . . . . . . . . . . . . . . 130

B.6 Hardware specifications of the proxy hosts . . . . . . . . . . . . . . . . . . . . . . . . 130

B.7 Hardware specifications of Mobile Node 1 . . . . . . . . . . . . . . . . . . . . . . . . 130

B.8 Hardware specifications of Mobile Node 2 . . . . . . . . . . . . . . . . . . . . . . . . 130

B.9 Hardware specifications of the 3Com WLAN adapter card . . . . . . . . . . . . . . . 131

B.10 Hardware specifications of the Belkin Bluetooth adapter . . . . . . . . . . . . . . . . 131

C.1 Throughput of two competing UDP streams over Wireless LAN . . . . . . . . . . . . 133

ix

C.2 Throughput of a TCP stream competing with a 3 MBit UDP stream over Wireless

LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

C.3 Throughput of a two competing TCP streams over Wireless LAN . . . . . . . . . . . 134

C.4 Throughput of a TCP streams competing with 1 MBit burst UDP stream over Wire-

less LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

C.5 Transmission Throughput of a TCP streams over a Bluetooth link using an access point135

x

List of Figures

2.1 ISO/OSI-Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 The TCP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 TCP Connection Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 TCP Data Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5 Duplicate Acknowledgement Situations in case of packet loss (left figure) or reordering

(right figure) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.6 TCP Connection Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.7 TCP Tahoe’s slow start and congestion avoidance algorithm . . . . . . . . . . . . . . 15

3.1 Meta-modell of the considered infrastructure . . . . . . . . . . . . . . . . . . . . . . 31

3.2 Fully wired network architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.3 Single Access Point Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . 33

3.4 Mobility Support Network architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1 UDP Throughput over 8 MBit/s serial links at sender (left figure) and receiver side

(right figure) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.2 TCP Transmission Throughput over a 8 MBit/s serial link . . . . . . . . . . . . . . . 51

4.3 Instantaneous Averaged TCP Throughput over a 8 MBit/s serial link . . . . . . . . 52

4.4 TCP RTTs over 8 MBit/s serial links . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.5 Performance of UDP over Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.6 TCP Performance over Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.7 Curve fitted Transmission Throughput and Residuals . . . . . . . . . . . . . . . . . . 59

4.8 Round-Trip Times of TCP over Wireless LAN . . . . . . . . . . . . . . . . . . . . . . 60

4.9 Single RTT Measurement over WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.10 WLAN Location Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.11 Influence of distances and obstacles on TCPs Performance over Wireless LAN . . . . 63

xi

4.12 Network model to measure the influence of crosstraffic on TCP’s performance over

Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.13 TCP Performance over Wireless LAN in presence of a competing 500 kBit/s UDP

stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.14 Cumulative Throughput of TCP over Wireless LAN with different constant packet

rate UDP streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.15 Instantaneous Transmission in a WLAN handover situation . . . . . . . . . . . . . . 69

4.16 A Problem in the DHCP-Client of the mobile nodes causes long network layer dis-

connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.17 Network model of Bluetooth adhoc scenario . . . . . . . . . . . . . . . . . . . . . . . 72

4.18 UDP performance over a Bluetooth link in adhoc scenario . . . . . . . . . . . . . . . 72

4.19 TCP Performance over a Bluetooth link in Adhoc Scenario . . . . . . . . . . . . . . 74

4.20 Single RTT measurement over Bluetooth in adhoc scenario . . . . . . . . . . . . . . 74

4.21 TCP performance over a Bluetooth link in adhoc scenario . . . . . . . . . . . . . . . 75

4.22 Single UDP Performance over Bluetooth Run using an access point . . . . . . . . . . 76

4.23 UDP Transmission Throughput over Bluetooth using an access point . . . . . . . . . 77

4.24 TCP Transmission Throughput over Bluetooth using an access point . . . . . . . . . 78

4.25 TCP RTTs over a Bluetooth link using an access point . . . . . . . . . . . . . . . . . 79

5.1 The Split TCP Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.2 Meta-Model for network integration of a TCP proxy . . . . . . . . . . . . . . . . . . 86

5.3 Model for Network Implementation of a TCP proxy supporting proxy Handover in

intrasubnet Handover Scenarios of a Mobile Node . . . . . . . . . . . . . . . . . . . . 87

5.4 Model for Network Implementation of a TCP proxy supporting proxy Handover in

intersubnet Handover Scenarios of a Mobile Node . . . . . . . . . . . . . . . . . . . . 88

5.5 Model for Network Implementation of a TCP proxy without proxy Handover in Han-

dover Scenarios of a Mobile Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.6 Model of Mobile IP Data-Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.7 IP Header Modification model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.8 IP Tunneling Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.9 In-Path Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

5.10 Model of the ARP Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

5.11 TCP proxy implementation using policy-based routing . . . . . . . . . . . . . . . . . 99

5.12 High-Level-Design of the mirroring TCP Proxy . . . . . . . . . . . . . . . . . . . . . 101

5.13 High-Level-Design of the Split TCP Proxy . . . . . . . . . . . . . . . . . . . . . . . . 102

xii

5.14 The qualitative impact of different proxy functionalities on connection setup delays

in TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

5.15 High-Level Design of the Mobile IP Module . . . . . . . . . . . . . . . . . . . . . . . 105

6.1 Influence of the TCP Proxy on RTTs . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

6.2 Transmission throughput with different number of ACKs transmitting 30 MByte of

data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

6.3 Transmission Throughput with different delayed ACK timeout values . . . . . . . . . 111

A.1 TCP State Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

xiii

xiv

Abstract

The difference between theory and practice is a lot bigger in practice than in theory.

(Peter van Linden in ”Expert C Programming - Deep C Secrets”)

Future mobile networks are expected to support heterogenous wireless access technologies allow-

ing vertical handover between these technologies. Different access technologies have been developed

and optimized for maximum throughput and mobility support mechanisms have been deployed to

prevent breakdowns of the communication between distributed systems. The Transmission Control

Protocol (TCP) is known to potentially show performance degradations in wireless settings and

TCP proxies modifying the TCP congestion control behavior are a common method to overcome

these inefficiencies.

This thesis examines if those assertions can be proven when Wireless LAN or Bluetooth is used as

wireless link in an experimental network. Based on these results, an implementation of a TCP proxy

is presented and evaluated.

Chapter 1 presents a general introduction to the project and states the goal of this project.

Chapter 2 introduces the specification of the Transmission Control Protocol, its goals, concepts and

flavours.

Chapter 3 describes the experimental approach to measure the performance of TCP and the con-

sidered scenarios.

Chapter 4 evaluates the performance of the Transmission Control Protocol in the defined scenarios.

Chapter 5 discusses the different implementation possibilities of a TCP proxy and presents the ap-

proach followed in this thesis.

Chapter 6 evaluates the basic functionality of the TCP proxy.

Chapter 7 ends with the conclusion about the performance of TCP over wireless links.

xv

xvi

Acknowledgements

First, I would like to thank Assoc. Prof. Schwefel, Prof. Jessen, Dr. Jobmann and Prof. Prasad for

making this thesis possible.

Special thanks to my supervisor, Assoc. Prof. Hans-Peter Schwefel, for his guidance, support,

hints and ideas. This thesis is a direct consequence of his supervision.

Many thanks to my parents, Angelika and Werner, for supporting and believing in me through-

out my whole studies.

Many thanks also to my my parents, my sister Janine and her boyfriend, Alex, and my sister

Carolin for giving me ”nutritional” support during my thesis in Denmark.

Thanks deserve also Markus, Janine and Martin for commenting my thesis.

Thanks to the people from Winglab, namely Rui, Ezequiel, Martin, Sergio, Imad, Suvra, Yaoda,

Lars, Daniel, Basak, Homare and Witold for some amazing month in Denmark. Also thanks to all

the people I met during my stay in Denmark.

And last, but not least, i want to thank my friends in Germany, Quirin, Markus, Martin,

Christoph, Carmen and Mike for always being there when needed.

xvii

Chapter 1

Introduction

In today’s networks, TCP/IP has become the most used communication protocol. It is not only used

in the world largest network, the Internet, but also more and more in any kind of computer networks,

like measurement and control networks. Nowadays, wireless access technologies and mobility support

have been developed to allow the moveability of network, paritcularly and system hosts. People are

able read their e-mails everywhere and to do their work from every place in the world with their

own laptop.

As the Transmission Control Protocol (TCP) was first introduced in 1988 by Van Jacobsen, some

assumptions have been made. The Bit Error Rate (BER) at the link layer and disconnections on

the link layer have been considered as negligible. For Ethernet, the BER is typically in a range of

10−6 and disconnections on link layer are rather unlikely. So it was supposed that packet loss only

occurs in case of congestion in the network layer. Packets are dropped, when a node in the path

from sender to receiver cannot receive a packet due to a full packet buffer. Van Jacobsen developed

a mechanism of detecting the maximum transfer rate available in the current network [26]. This

mechanism is divided into two parts: flow control and congestion window adjustment.

Flow control prevents the receiver from flooding with too many packets in too short time, so that

the receiver cannot process all these packets. Congestion window adjustment means a ”continuous

probing” algorithm and tries to determine the current maximum available bandwidth by measuring

packet loss. The sender’s packet rate is incremented until packet loss occurs, is set back to a start

value and incremented again.

Different implementations showing better performance than the original implementation have been

1

proposed, for example NewReno, SACK and Vegas. These implementations are still based on the

assumptions from Van Jacobsen and perform good in wired scenarios. As more and more mobile

hosts are integrated into current networks, these assumptions seem to be unsustainable for wireless

links. Wireless links suffer from higher Bit Error Rate (BER), its value is reported to be around

10−5 and more. Times of physical disconnection, particularly, when a mobile node switches its point

of attachment to a new network and is handed over from one access point to another, may degrade

the performance of TCP.

This thesis first describes the TCP specification as it is currently standard in the Internet. Secondly,

different implementations for a wired TCP implementation and its enhancements as well as proposed

solutions for a wireless TCP implementation are presented. The main part investigates the TCP

Perfromance over wireless technologies in an experimental setting. The investigation covers different

wireless scenarios over different access technologies, in particular Wireless LAN and Bluetooth.

Based on the identification of performance problems of TCP over the wireless links, a possible

improvement that is based on a split connection approach, its implementation into the network and

its software design will be shown. The evaluation of the proposed solution concludes the work.

2

Chapter 2

Background

TCP uses a congestion control algorithm to transmit data at the maximum available bandwidth.

To analyze the performance of TCP in wireless settings, a deep understanding of the dynamics of

TCP is required. The specification of

The specification basically describes the functional requirements on a implementation of TCP, but

do not describe the algorithm to perform congestion control and to send data at the maximum

available bandwidth, researchers have developed different approaches to implement this algorithm.

This approaches are called flavours and are also described in this chapter.

The performance of TCP over wireless links is evaluated using two wireless access technologies,

namely Wireless LAN and Bluetooth. An introduction to Wireless LAN and Bluetooth is given in

this chapter.

2.1 ISO/OSI Model

The International Standards Organization (ISO) has developed a layered structure to describe the

different tasks in a networking operating system. The structure is called Open System Interconnec-

tion (OSI) model, which is often referred as ISO/OSI-Model. This model consists of 7 Layers. Every

layer has its specific functions and goals and uses the functions provided by the underlying layer to

fulfill its goals.

The 7 layers are from top to down: Application Layer, Presentation Layer, Session Layer, Trans-

port Layer, Network Layer, Link Layer and Physical Layer. Figure 2.1 shows the structure of the

3

2.1 ISO/OSI Model

ISO/OSI-Model.

7. Application Layer

6. Presentation Layer

5. Session Layer

4. Transport Layer

3. Network Layer

2. Link Layer

1. Physical Layer

7. Application Layer

6. Presentation Layer

5. Session Layer

4. Transport Layer

3. Network Layer

2. Link Layer

1. Physical Layer

Logical Link

Logical Link

Logical Link

Logical Link

Logical Link

Logical Link

Physical Link

Figure 2.1: ISO/OSI-Model

The Application Layer defines the topmost layer in the model. Its purpose is to provide function-

ality for the end user, for example writing e-Mails or browsing web-pages. Common Application-

Layer Protocols are HTTP, SMTP or POP3. These protocols use byte streams to communicate with

each other.

The Presentation Layer translates the system-dependent byte stream (for example ANSI-Code) to

a system-independent stream (for example UNICODE).

The Session layer provides functionality to use sessions for user-authentication and splitting the

byte-stream into logical tokens.

The Transport Layer provides a logical end-to-end connection for an application. The tokens deliv-

ered to the Transport Layer are split into so called segments and sent through the Network Layer.

The end-to-end connection might be reliable as in TCP or unreliable as in UDP. Units of data

including the transport layer headers will be called segments in the thesis1.

The Network Layer delivers the segments from the Transport Layer from one end to another. The1Some papers distinguish between TCP segments and UDP datagrams. In order to avoid confusion, the term

segment will be used for UDP and TCP furthermore

4

2.2 The TCP Specification

goals of the Network Layer is to find a path from the sender to the receiver and send the packet

along this path. A wide-spreaded example for a Network Layer protocol is IP. Units of data at the

network layer will be termed datagrams.

The Link Layer provides a connection between two neighbor-nodes in a network. The Link Layer

can be divided into two sub-layers: medium access layer and link-layer control. The medium access

layer controls, which node is currently allowed to use the medium. The link-layer control adds error

correction code to the bit-stream to provide a reliable transmission of the bits. Examples of Link-

layer protocols are Ethernet and TokenRing. Units of data sent at this layer will be called frames.

Last, but not least, the Physical Layer defines the electrical specifications of a network including

medium, voltage levels and termination. Examples for Physical Layers are 10BaseT-Twisted Pair

and FDDI.

The last 4 Layers (Physical, Data Link, Network and Transport Layer) are often called transport

system, whereas the first 3 Layers (Session, Presentation and Application Layer) often are imple-

mented in one application on the target system. The term packet is used in general case and used

for units of data on every layer.


TCP [41] resides on the Transport Layer and was designed to realize a reliable, bidirectional end-to-

end connection for data transfer on top of the Internet Protocol (IP). When IP is mentioned here,

it is always referred to IP Version 4 [40]. The next section will describe the basic concepts of TCP

and its requirements to implementations of the specification.

2.2.1 Goals of TCP

IP provides a basic service for sending data over a network. Every host in an IP-Network gets a

specific address, called IP-Address. The IP-Address is an unique number for an interface of a host

to a network. The data, send over an IP-network, is routed through the network from the source

host to the destination host at best effort. There is no guarantee that a datagram sent over an

IP-network is received at the destination host. It may be lost in case of a full buffer at a routing

point. If more than one packet is sent, the packets do not necessarily arrive in the order they were

5


sent. There is also no support for any kind of multiplexing. TCP tries to solve these problems and

therefore, its goals are:

• Byte oriented data transfer

• Reliable in-order delivery

• Bidirectional data transfer

• Multiplexing

• Flow Control

Byte-oriented data transfer

TCP transfers a continuous stream of bytes between its attached processes by fragmenting them

into packets and sending them over an IP-network.

Reliable in-order delivery

Reliable transmission of a data stream includes not only the arrival of all data, but also the arrival

of data in the order they were sent. IP itself does not take care of the order of packets or packet loss.

TCP introduces two mechanism to achieve reliability: sequence numbers and acknowledgements.

Additionally, reliability ensures also, that the TCP packets are received correctly, without any bit

or byte errors. TCP adds a checksum to achieve this aim.

Sequence numbers are consecutive numbers representing the position of a byte in the data stream.

As packets are received out-of-order, they can be reassembled upon their sequence number. Ac-

knowledgement numbers represent the packet number the receiver is expecting next. The receiver

implicitly acknowledges all previous packets as successfully received. As the sender receives the

acknowledgements of the receiver, he can determine if packets are lost and react accordingly by

retransmitting possibly lost packets.

6


Bidirectional

Because of the bidirectional nature of TCP, data can be exchanged in both directions using the same

TCP connection.

Multiplexing

In an IP-network, only one connection is possible between two end-hosts . If two concurrent processes

on the two hosts wish to communicate, IP would not be able to distinguish between the processes.

To solve this problem, TCP introduces a new mechanism: ports. A port represents a unique number

on one host, the communicating process is attached to. The sender process as well as the receiver

process is connected to a port.

Flow Control

The mechanism to prevent the receiver process to be flooded by too many packets is called flow

control2. To achieve flow control, the receiver of data is advertising the number of bytes he can

process. This number is called receiver advertised window (RWND)3 and is transmitted in the TCP

header. The RWND describes the number of bytes the process can handle after the reception of the

last packet. It allows the sender to send more data until further permission is received.

2.2.2 The TCP Header

TCP uses its own header to communicate protocol specific data between the two endpoints. The

TCP header follows immediately the IP header and is shown in Figure 2.2. Its main fields are as

follows:

• Source Port: The source port carries the port number the sending communication process

is attached to.

2The term congestion control, that will be described in detail later, is sometimes also used for the combination ofcongestion and flow control. Since flow control is a requirement by the TCP specification and congestion control is afeature provided by the TCP flavours, these two schemes will be explicitly distinguished in the thesis.

3The expresseion advertising window (AWND) is sometimes also used in the literature. In this thesis, the termreceiver advertised window window will be used

7


U

R

G

A

C

K

P

S

H

R

S

T

S

Y

N

F

I

N

Options Padding

Data

Data Offset Reserved Window

Checksum Urgent Pointer

Source Port Destination Port

Sequence Number

Acknowledgement Number

Figure 2.2: The TCP Header

• Destination Port: The destination port carries the port number the destined communication

process is attached to.

• Sequence Number: The Sequence Number contains the position of the first byte of payload

in the data stream. If a SYN is present, the sequence number contains the initial chosen

sequence number, so that the first byte of the data stream will be numbered with initial

sequence number plus one.

• Acknowledgement Number: The acknowledgement number contains the sequence number

of the byte, that is expected next to receive. In case the TCP packet is a pure SYN-packet,

no packet can be acknowledged and thus the acknowledgement number is set to zero

• Data Offset: The number indicates the length of the TCP header. Since different options

may be added to the TCP header, its length is variable for different packets. Data offset

indicates the position of the payload.

• SYN, ACK, RST, FIN Control Bit: These Bits signal different flags to the communication

partner. They are used in connection setup (SYN) and connection termination (RST, FIN).

Packets with ACK enabled indicate a valid acknowledgement number. TCP packets with SYN

enabled will be referred to as SYN-packet, with SYN and ACK enabled as SYNACK-packet.

• Window: The window value is used in the reverse communication direction to indicate the

number of bytes, that the receiver is willing to accept

8


• Checksum: A checksum of a pseudo IP header4, the TCP header and the payload is computed

into this field. The checksum is computed by the ones complement of the sum of the ones

complement of every 16bit byte word.

• Options: Additional options can be carried in the options field. For instance, the maximum

segment size negotiated in the connection

2.2.3 Connection Setup

As TCP is a connection-oriented transport protocol, an explicit connection setup is needed, to ensure

that the destination process is reachable. This may not be the case, if the corresponding IP address

is not found, no path to the destination IP address is found or no process is listening on the specific

destination port. In general, a communication partner can set up or close one side of the connection.

The destination process has to set up or terminate its corresponding side of the connection.

Sender ReceiverSYN, Seq=10000, ACK=0

SYNACK, Seq=60000, ACK=10001

ACK=60001

Figure 2.3: TCP Connection Setup

The Connection Setup is so called 3-Way-Handshake, meaning that at least 3 packets have to be

exchanged before the connection is usable for data transfer5. The initiating process starts the setup

by sending a specific SYN packet. A SYN packet is a TCP packet with the SYN-Flag enabled in the

TCP header. It also contains a clock-driven initial sequence number and may advertise a maximum4The complete pseudo header consists of source and destination IP address, the TCP protocol identifier and the

size of the TCP segment5The specification is unclear if the sender is allowed to send data within in the third packet. In any observed case

in the evaluation, the sender did not use the third packet to send data.

9


segment size (MSS). The MSS is used to indicate the maximum number of bytes that can be send

over the IP-network without being fragmented.

When the destination process receives the SYN-packets, it sends a SYN-packet back to the sender,

explicitly acknowledging the SYN packet. This packet is often called SYNACK-packet. If the

advertised MSS is higher than the destination can handle, it also sends a new (lower) MSS to the

sender. The SYNACK-packet explicitly acknowledges the received SYN-packet by inserting the

sequence number of the SYN-packet in the acknowledge field of the TCP header and incrementing

it by one. SYN-packets, as well as SYNACK-packets and FIN-packets are considered as a one-byte-

packet. The SYNACK-packet also a clock-driven initial sequence number

After the sender process receives the SYNACK-packet, it acknowledges the reception of the packet

by sending an empty ACK-packet. The connection is then setup and usable for any kind of data

transfer. The Connection Setup is visualized in 2.3.

2.2.4 Data Communication

As soon as a TCP connection is established, data can be exchanged via segments. TCP uses retrans-

missions to ensure that every packet is delivered, since packets may be lost due to errors indicated

via a bad checksum or network congestion. Sequence numbers that are assigned consecutively to

every byte of the data stream indicate the position of the bytes in the overall data stream. In the

following section, the data transfer only of an unidirectional flow will be described for the sake of

clearness. The bidirectional data flow follows the same rules, but would complicate the description.

After the TCP connection is established, the TCP sender can start sending data by chopping the

data into different chunks, adding the TCP header to it, and sending the segment to the IP layer.

The sequence numbers of the different packets are set in the TCP header according to the position

of the data chunk in the data stream plus an initial offset, that was negotiated in the connection

setup phase. An example of a data communication can be found in Figure 2.4.

In this example, the sender starts to send a data packet containing 1460 bytes of payload. The

initial sequence number was negotiated to 10000. After receiving the packet, an ACK expecting a

sequence number of 11461 is send back. After the reception of the ACK, the sender starts sending

another data packet with 1460 bytes of payloadwith a sequence number of 11461. The receiver

10


Sender ReceiverSeq=10000, Data 1460

ACK 11461

Seq=11461, Data 1460

ACK 12921

Figure 2.4: TCP Data Communication

responds the data packet with an adequate ACK packet expecting byte 2921 next. In the example,

every TCP packet, regardless of data- or ACK packet, triggered a new packet. One data packet

triggered one new ACK packet and vice versa. As described in the specification of TCP, an ACK

need not necessarily be triggered immediately after the reception of a data packet. This technique is

often called ”delayed ACK”. [11] states, that a TCP implementation should not excessively delay an

ACK, but send an ACK at least after every second received TCP segment or after 500ms. Common

TCP implementations use timers of 200 ms. Due to the coarse grained implementation of timers in

a kernel, the timer may fire after an interval of 201 - 400 ms.

In common TCP implementations, duplicate ACKs (DUPACK) are used as an indication of network

congestion. DUPACKs are triggered in case of packet loss or reordering of packets. Figure 2.5 shows

two standard situations for DUPACKs.

In the first case, the sender injects one packet to the network, that is received and acknowledged

by the receiver. After the first packet, the receiver has 1460 bytes in his local buffer and expects

byte number 1461. In the example, the next packet that is sent by the sender is lost for some reason.

If the sender sends the next packet and the receiver gets this packet, the receiver still expects byte

number 1461, since the data in the local buffer cannot be filled with more in-order data. It thus

sends a DUPACK. In the same manner DUPACKs are created in case of packet reordering.

11



ACK 11461

Seq=11461, Data 1460

ACK 11461

Seq=12921, Data 1460

DUPACK !


ACK 11461Seq=11461, Data 1460

ACK 11461

Seq=12921, Data 1460

DUPACK !

ACK 14381

Figure 2.5: Duplicate Acknowledgement Situations in case of packet loss (left figure) or reordering(right figure)

2.2.5 Connection Termination

Analogous to the connection setup, the connection termination can only be performed for one side

of the connection. The connection partner has also to close his side of the connection. There are

two ways of closing a connection. In the normal case, one side of the connection sends a FIN-packet

to indicate that it wants to terminate the connection. In any error case, the connection can be reset

by sending a RST-packet.

In the standard case, one process closes the connection, if it has no more data to send. He starts

Sender Receiver

FIN, Seq=10000

ACK 10001

ACK=60001

FIN, Seq=60000

Figure 2.6: TCP Connection Termination

12

2.3 TCP Flavours

with sending a FIN-packet. If the corresponding process acknowledges the packet by sending an

ACK-packet, one side of the connection is closed and cannot send any data. As one side of the

connection is still opened, this state is often called half-opened. If the second process also finished

sending the outstanding data, it also closes the connection in the same way. Figure 2.6 shows a

typical connection termination.

Based on the requirements regarding connection setup, data communictaion and connection termi-

nation, a state machine can be build. This state machine is described in appendix A.1.

2.3 TCP Flavours

Based on the requirements that are demanded by the TCP specification, several flavours have been

proposed. An excerpt of the flavours will be described next. The flavours can be divided into the

following categories:

• Common TCP flavours: This category will cover the TCP flavours, that are mainly used in

the internet.

• Flavours using TCP header options: TCP flavours, that use additional TCP header options

to enhance the TCP performance will fall into this category.

• Wireless TCP flavours: Flavours optimized for wireless settings settings to overcome the prob-

lems introduced by wireless links are listed in this category.

• Other TCP flavours: flavours, that cannot be classified in one of the categories above, are

listed in this class.

2.3.1 Common TCP Flavours

Since the beginning of research on TCP and its congestion control algorithm, different flavours have

been proposed. The most common flavours, that have been deployed in different operating systems

are:

• Tahoe

13

2.3 TCP Flavours

• Reno

• NewReno

• Vegas

TCP Tahoe, Reno and NewReno are currently deployed in the operating systems, TCP Vegas

will be deployed in the next kernel deployment of Linux. Since only implementations of TCP Reno

and NewReno have been used in the evaluations, they will be described next. A description of TCP

Vegas can be found in Appendix A.2.1.

Tahoe

In 1988, Van Jacobsen proposed an enhanced implementation6 of TCP [26]. This version is often

called ”TCP Tahoe”. Since several performance collapses of the internet have been experienced, it

was investigated, that the performance dropdown was mainly caused by the initial implementation

of TCP. Several algorithms have been added to the implementation, namely:

• slow-start

• dynamic window sizing (congestion avoidance)

• round-trip-time variance estimation

• exponential retransmit timer backoff

• more aggressive receiver ACK policy

• Karn’s retransmit backoff

TCP is a self-throttling protocol, that adapts its sending rate corresponding to the maximum

available bandwidth. TCP uses a second window, called Congestion Window (CWND) to determine

the maximum number of packets, that can be sent without running into packet loss due to congestion.

Thus, the CWND indicates the sending rate of TCP measured in packets7.6Literature sometimes referres to TCP Tahoe as first implementation of TCP, since it was the first implementation

using a congestion control algorithm. The TCP implementation proposed in [26] was an enhancement of a first”straight forward” implementation of TCP.

7Some TCP implementations measure the CWND in bytes rather than in packets. For the sake of clarification,the CWND will be measured in packets.

14

2.3 TCP Flavours

The mechanism to adjust the sending rate automatically makes TCP stable, but also hard to

start. To bring TCP in this state, ACKs have to be present in order to send data, but ACKs are

generated after data was sent. The initial startup of a TCP connection is an important phase of TCP.

To achieve good performance in the startup-phase, an algorithm called slow-start was implemented

into TCP Tahoe. The main idea behind slow-start is to start with the smallest possible sending

rate, i.e. CWND = 1 packet, and increase the rate exponentially.

In contrast to the slow-start phase, the Congestion Avoidance phase increases the sending rate

linearly per RTT. This means, that the CWND has to be increased by 1/CWND per received ACK.

This behavior is often called ”linear increase and multiplicative decrease”.

Both algorithms, slow-start and congestion avoidance, affect the sending rate of TCP, but they are

0

2

4

6

8

10

12

14

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

pack

ets/

RT

T

RTT

TCP sending rate in congestion control algorithms

Figure 2.7: TCP Tahoe’s slow start and congestion avoidance algorithm

used in different situations. In order to signal the end of the slow-start phase and to enter Congestion

Avoidance, a new parameter called slow-start threshold (ssthresh) is used. Every TCP Connection

starts with a slow-start and increases its CWND exponentially per RTT until ssthresh is reached.

It then enters the Congestion avoidance phase and increases its sending rate linearly per RTT. If a

timeout occurs and signals a packet loss, the ssthresh is set to the half of the current CWND, while

the CWND is set to 1 to enter slow-start again. An example run of both algorithms can be found

in figure 2.7

15

2.3 TCP Flavours

Since the retransmission timer is used to detect packet loss, the value of this timer plays a very

important role. A too short value for the timer will unnecessarily trigger retransmissions enter slow-

start too often. A degradation of throughput and performance will be the result. On the other hand,

a too big value for the timer will cause a late detection of packet loss and thus give a bad estimation

of the maximum available bandwidth. Again, a degradation of throughput and performance would

be the result. The TCP standard suggests to estimate the mean round-trip time via a low-pass filter:

R ← αR + (1− α)M (2.1)

where R is the estimated average RTT , M is the RTT measurement for the most recent ACK and

α a filter constant that is suggested to be set to 0.9. The retransmission timeout (RTO) is then set

to

R ← βR (2.2)

where β accounts the variance of RTT. β is suggested to be set to 2 by the TCP standard. Van

Jacobsen presented a modified scheme of calculating the RTT that takes also the variance of the

RTT into account:

Err = M −A

A ← A + g ∗ Err

D ← D + (| Err | −D)

RTO = A + 4D (2.3)

where A is the smoothed RTT, D is the smoothed deviation, M the measured RTT. The gain g for

the average is usually set 18 and the gain h for the deviation is usually set to 1

4 . The new slow-start

and congestion avoidance algorithm as well as the modified RTT estimator improved the initial TCP

implementation dramatically.

TCP Tahoe also addressed the problem of multiple retransmissions on one packet. Reference [26]

stated, that an exponential timer backoff is the only reasonable algorithm for multiple retransmis-

sions. Thus, after a timeout, the RTO is doubled in case of a second retransmission of the same

packet. The proposed algorithm tries to handle DUPACKs. DUPACKs occur either in case of a lost

packet or in case of reordered packets. The algorithm proposes, that reordered packets will only be

16

2.3 TCP Flavours

received one or two packets out-of-order. Thus, teh algorithm waits for the next two packets after

receiving the DUPACK to determine, if the packet was lost or reordered. If three or more DUPACKs

are received, a lost packet is assumed, the apparently lost packets is retransmitted and slow-start is

entered. If less than three DUPACKs are received, TCP Tahoe continues to transmit data via the

Congestion Avoidance algorithm.

Reno

TCP Reno [47] is a modified version of TCP Tahoe. It adds the Fast Recovery algorithm to the

TCP Implementation. When TCP Reno enters Fast Retransmit and receives 3 or more DUPACKs,

this information also indicates that there is still data flowing between the sender and the receiver.

Thus, there is still a moderate bandwidth available for the TCP connection and the connection must

not be restarted by a Slow-Start. The Fast Recovery algorithm retransmits the lost packets and

performs the congestion avoidance algorithm.

NewReno

The NewReno Implementation [24] is a slight modification of Reno to overcome the problems of

multiple packet losses in one window of the Reno Implementation. TCP Reno retransmit only one

packet per window in case packet loss is indicated via three DUPACKs. If multiple packets are lost in

one window, a performance degradation would be the result. TCP NewReno uses some information,

that is available in order to make a retransmission decision during Fast Recovery.

After receiving three DUPACKs, NewReno retransmits the missing packets, but additional DU-

PACKs could be received, since the receiver acknowledges data packets, that were injected to the

network before the sender entered Fast Retransmit. In case of a single packet loss, the retransmitted

packet will acknowledge all packets, that have been sent before the sender entered Fast Retransmit.

In case of multiple losses, an ACK for some, but not all packets will be received assuming, that there

was no reordering. This ACK is called partial ACK.

NewReno changes the NewReno flavour in case of the reception of a partial ACK. NewReno does

17

2.3 TCP Flavours

not leave Fast Recovery and wait for the next three DUPACKs in case of multiple packet losses.

Instead, it decreases its congestion window by the amount of new acknowledged data and sends the

new packet according to the partial ACK. If subsequent ACKs are received, TCP Reno remains in

Fast Recovery and retransmits the lost packets.

2.3.2 TCP Flavours using TCP Header Options

Additionally to the common TCP implementations, some flavours have been developed, that use

header options to transmit additional information from the sender to the receiver. This information

can be used to estimate the current available bandwidth more precisely or to react more precisely

to lost packets. The following TCP flavours are described next:

• Selective Acknowledgements (TCP SACK)

• Forward Acknowledgements (TCP FACK)

• Total Acknowledgements (TCP TACK)

• Header Checksum Option (TCP HACK)

TCP SACK is currently implemented in most operating systems while TCP FACK, TCP TACK

and TCP HACK are only partially available in the operating system protocol stacks and have not

been used in the evaluation. Hence, TCP SACK will be described next, while a description of TCP

FACK can be found in Appendix A.2.2, TCP TACK in Appendix A.2.3 and TCP HACK in A.2.4

Selective Acknowledgements

Selective Acknowledgements (SACK) [33, 27] are used to inform the sender about the current state

of the receiving buffer in case of multiple packet losses. SACK introduces a new TCP header option,

that carries the information of the successful received bytes beyond the in-order byte stream. On

receiving any SACK information by the sender, the sender can skip those sequence numbers and

thus reduce the number of bytes, that have to be retransmitted. SACK blocks can also be used

to adapt congestion control more adequately, since the number of selectively acknowledged bytes

18

2.3 TCP Flavours

provide information about the maximum available bandwidth.

2.3.3 Wireless TCP Flavours

The next section will describe TCP Implementations, that have been proposed to perform substan-

tially better over wireless links to overcome the problems, that are introduced by wireless links.

I-TCP

Indirect TCP (I-TCP, [4]) follows a split connection approach to overcome the lacks of TCP in

wireless settings. The connection between the Mobile node and the fixed host is split into two sepa-

rated connections. I-TCP terms the connection splitting node ”mobile support router” (MSR). This

approach results in two benefits: First, the TCP endpoint is moved from the wireless part to the

wired MSR, so that all the characteristics of wireless links are hidden to TCP. Second, the connec-

tion between the MSR and the mobile node can be optimized for the wireless link. The connection

between MSR and mobile node needs not necessarily be a full TCP/IP implementation, but can be

a small protocol stack, e.g. implemented on a small palm top. The palm top would still be able to

use services from the fixed network. If both connections use a full TCP to communicate, I-TCP can

be seen as a TCP Proxy.

I-TCP proposes, that the connection splitting point should be implemented at the base station or

the access point of a wireless network. Thus, the MSR is changed during a handoff and the logical

split connection state has to be transferred to the new MSR.

The evaluation showed, that I-TCP enhances the performance the more greatly, the more the wireless

link characteristics come into play. In a local area scenario, where the different cells of the different

base stations are overlapping, the performance gain was around 4.5%, whereas the performance gain

in scenario with non-overlapping cells and a 1 sec cell distance, was around 53%. The performance

gains in a wide area network were even better. These gains result mainly from the fact, that the

TCP sender is hidden to the handover process and thus does not see any ACK-losses.

A drawback of I-TCP is the loss of the true end-to-end semantics supposed to TCP as a transport

layer protocol in the ISO/OSI-model (2.1) as it splits the TCP connection into two different con-

nections. Another drawback is, that I-TCP maintains a hard-state, that has also to be handed over

19

2.3 TCP Flavours

during a cell switching process of a mobile node. This causes additional network traffic and delays

the traffic between the MSR and the mobile node. [4] showed, that even in a static scenario, where

no handover takes place, the performance was improved due to the lower variation of the RTT.

Multiple TCP

[55] suggests a new session layer protocol (Mobile Host Protocol, MHP), implemented in the Base

Stations of a wireless network and the mobile node, to overcome the problems of wireless links.

MHP assumes, that all routing for mobile hosts is done via MobileIP and that MobileIP can provide

information about a pending handover to the upper layers.

When an application on mobile node requests a connection to a host, MHP intercepts this requests

and sets up a TCP connection to its base station. The base station in turn receives the request and

sets up MHP agent and establishes a connection to the desired host. These two independent TCP

connections can be optimized to their parts of the link, regarding their parameters.

M-TCP

Mobile TCP (M-TCP, [13]) was designed to improve standard TCPs performance lack in handover

situations, while keeping up the end-to-end semantics of TCP.

Mobile TCP uses a split-connection approach between the mobile host and the fixed host. The

TCP connection is split into two parts at the Supervisor Host (SH). The SH is an entity in the

network, that controls several Mobile Support Stations (MSS) and handles routing and Quality of

Service (QoS) tasks. The TCP client at the SH connected to the fixed host sender uses a modified

version of TCP, called SH-TCP, while the TCP client connected to the mobile node uses a M-

TCP8 implementation. Thus, the implementations that is provided in fixed host can further be

used without any changes. When the SH-TCP receives data from the fixed host, it passes it to the

M-TCP to send it to the mobile node. To maintain end-to-end semantics, ACKs are not generated

independently at the SH-TCP, but they are send when an according ACK is received from the mobile

node.

SH-TCP strategy to cope with the TCPs problems in handover situation is to acknowledge one8The term M-TCP is used in [13] for the complete split-connection concept as well as the TCP implementation

between the SH and the mobile node.

20

2.3 TCP Flavours

byte less to the fixed host sender than the mobile node has acknowledged to the SH-TCP. The

last unacknowledged byte is then used to freeze sender into a persistent state by sending a Zero

Window Advertisement (ZWA) in case the mobile node gets disconnected. M-TCP is responsible

for notifying the SH-TCP client about the disconnection and reconnection events. After receiving

the reconnection event, SH-TCP sends a new ACK with a non Zero Receiver Window Advertisement

to open up the window again quickly.

On the mobile nodes side, a changed TCP implementation ”M-TCP” was used. M-TCP was build

on the assumption, that the Bit Error Rate (BER) is rather low and retransmission timeouts only

occur due to disconnection. The low BER can be justified by the use of link-layer techniques like

Forward Error Correction (FEC) or Automatic Repeat Request (ARQ). On the SH side of the M-

TCP connection, the retransmission timeout is used to indicate the disconnection and thus informs

SH-TCP, that freezes the fixed host sender. If the mobile node gets informed by the communication

hardware, that the mobile node got disconnected, it freezes all timers and enters the persistent

state. After receiving the reconnection notification from the communication hardware, M-TCP

sends a special marked ACK providing the sequence number of the last successfully received byte.

This special marked ACK is used to inform SH-TCP to unfreeze the fixed host sender.

The evaluation of M-TCP showed, that TCPs lacked due to frequent disconnection could be reduced

by using the M-TCPs split-connection approach. The impact of M-TCP rises, the more the influence

of the wireless link compared to the whole path from the sender to the receiver is.

FreezeTCP

FreezeTCP ([25]) addresses TCPs problems in handover situations without breaking the end-to-

end semantics of TCP. TCP assumes, that packets, that were lost due to the handover, were lost

due to congestion. TCP reacts with inappropriate slowing the sending rate. This leads to an

underutilization of the wireless link. Furthermore, TCP uses an exponential backoff mechanism

to retransmit packets. After a packet is lost, while the mobile node is disconnected, TCP tries to

retransmit the lost packet and backs off exponentially. During this backoff time, the mobile node can

be reconnected again. The mobile node will thus idle until the retransmission timer fires, although

it is able to send data again.

21

2.3 TCP Flavours

FreezeTCP uses two mechanism to avoid this performance degrading behavior of TCP. It uses Zero

Window Advertisements (ZWA) to ”freeze” the complete state of the senders TCP and 3 DUPACKs

to recover from the frozen state and continue sending at the rate that was determined before the

handover took place [11].

A Zero Window Advertisement (ZWA) is a TCP packets, that offers a Advertised Receiver Window

(AWND) of 0. The sending TCP, which receives the ZWA, assumes, that there is no buffer space

left in the receivers and stops therefore immediately sending new packets. Since a ZWA does not

provide any information or state change of the intermediary nodes of the network, TCP assumes,

that the maximum available bandwidth stays constant and freezes its congestion window as well

as its timers and enters a persist state. Thus sending a ZWA before the handover event occurs,

keeps up the congestion window and therefore results in a better performance. FreezeTCP suggests,

that the ZWAs have to be sent one RTT before the handover takes place. If the time, before the

ZWA is sent is too long, the connection would be unnecessarily idle for some time resulting in a

bad performance. On the other hand, if the time is to short, the mobile node might not be able to

send the ZWA before the handover event occurs, resulting in an idle time after reconnection and a

decreased congestion window.

To recover from this frozen state, the standard TCP sends Zero Window Probes (ZWPs) to the

receiver until the receiver opens up the window again. The ZWPs are also sent in an exponential-

backoff manner, so using ZWPs to recover from the frozen state could also lead to an idle time.

FreezeTCP sends 3 copies of the ACK for the last segment, that was received before the handover.

In a TCP Implementation with Fast Recovery algorithm implemented, the 3 DUPACKs result in

transmitting the packet expected by the 3 DUPACKs and TCP continues sending data without

shrinking the congestion window.

The evaluation of FreezeTCP showed, that FreezeTCP enhances the performance of TCP in wireless

settings in handover scenarios, especially in cases, where the influence of the wireless link is big (like

in single or few-hop scenarios). FreezeTCP also does not need any changes in the sending TCP and

does not break up the end-to-end semantics of TCP.

The drawbacks of FreezeTCP are the small overhead, that is produced by sending the ZWA and the

3 DUPACKs to recover, but this overhead has almost no influence on the throughput in cases, where

22

2.3 TCP Flavours

the wireless link has almost no influence on the overall link. Secondly, a FeezeTCP sender has to

predict a handover in order to send the ZWA early enough. This requires to exchange some cross-

layer information or may even not be possible in certain cases (e.g. RTTs in GPRS are measured

around 700ms to 1s, that requires the mobile node to send the ZWA 700ms to 1s before the handover

event occurs).

Snoop

The snoop protocol [5, 50, 51] was designed to maintain the end-to-end-semantics of TCP while

keeping the TCP implementations on the mobile node and the correspondent node.

The snoop module is implemented as na agent on the base station in order to eavesdrop and cache

all TCP packets flowing from and to the mobile node. Depending on the kind of TCP packets that

arrive at the base station and are received by the snoop module, the snoop agent triggers different

actions:

• A new data packet is received. In a regularly flowing TCP connection, receiving a new

data packet is the standard case. The snoop module caches this packet in its local data cache

and places a timestamp on the packet in order to calculate RTTs for the packet.

• An out-of-order data packet arrives, that was cached before. An already cached,

out-of-order packet is received, when a dropped packet causes a timeout at the sender, which

is a less common case. Depending, if the sequence number of the packet is higher than the last

acknowledgement seen so far, further actions are triggered. If the sequence number is higher,

then it is very likely, that the packet did not reach the mobile node and is thus forwarded. In

the second case, if the sequence number is lower than the last acknowledged sequence number

seen so far, the packet was already received by the mobile node, so it could be discarded. Since

such an out-of-order packet is mainly generated by a lost ACK packet, the snoop module sends

an ACK to the correspondent host.

• An out-of-order data-packet arrives, that was not cached before. This situation

indicates, that either a packet was lost due to congestion or has been delivered out-of-order.

Since reordering by the network layer is rather unlikely, congestion is assumed and the packet

is forwarded to the mobile node, while it is marked as retransmitted locally.

23

2.3 TCP Flavours

• A new ACK is received. On receiving a new ACK, the successful reception of new data

is signalled. Thus, the ACK is forwarded and the local cache of unacknowledged data packet

is cleared the acknowledged sequence number. The ACK packet is also used to update the

estimation of the current RTT.

• An old ACK is received. In this normally rare situation, the ACK is dropped by the

snooped module.

• A DUPACK is received. Depending on the type and current state of the snoop module,

different actions are taken. If the DUPACK indicates the expectation of a data packet, that was

not saved in the local cache, the packet was lost from the sender to the snoop module. Thus,

the data packet has to be resent with eventually triggering congestion control at the sender

side by forwarding the DUPACK to the sender. If a DUPACK is received, that indicates the

expectation of a data packet, that is stored in the local cache, the stored data is retransmitted

and the ACK is discarded.

To improve the performance of TCP over the wireless link, the snoop protocol implements NACK

scheme, that requires changes in the TCP implementation of the mobile node. Additionally, a

mechanism to support mobility based on the approach of Mobile IP was additionally implemented

The evaluation of the Snoop protocol showed, that the influence and performance gain of snoop

raises with the probability of packet errors.

2.3.4 Other TCP Flavours

Other TCP flavours have been proposed that do not fit in one of the categories above. Four TCP

flavours are categorized in this class:

• Transactional TCP (T/TCP): Transactional TCP enhances the TCP performance by reducing

the overhead introduced by connection setup and connection termination. A description of

T/TCP can be found in Appendix A.2.5

• Multicast TCP: Multicast TCP addresses the problems introduced when multicast IP addresses

are used rather than unicast. A dsescription of Multicast TCP can be found in Appendix A.2.6

24

2.4 Wireless Access Technologies

• Smooth start + dynamic recovery: Smooth start is proposed to replace slow start to provide

a better estimation of the maximum bandwith in slow start and dynamic recovery intends to

estimate the available bandwidth more accurately in multiple losses scenarios. Smooth start

and dynamic recovery are described in Appendix A.2.7

• TCP Pacing: TCP Pacing’s approach spreads data packets equistant in one RTT rather then

sending a packet burst. A description of TCP Pacing can be found in A.2.8


In the latter evaluation of TCP, two wireless link technologies have been used, namely Wireless LAN

802.11b and Bluetooth. A short introduction to both technologies can be found in the next section.

2.4.1 Introduction to Wireless LAN

Since the beginning of mobile computing and wireless networking, different wireless technologies

have been developed. The Institute of Electrical and Electronics Engineers (IEEE) has developed

a standard for Wireless Local Area Networks (WLAN), that operates in the license-free industrial-,

science- and medical- (ISM) radio band (2.4 GHz or 5 GHz) or in infrared range. This standard is

known as IEEE 802.11 standard [1]. IEEE 802.11 defines the physical and medium access (MAC)

layer.

IEEE 802.11 defines two different types of network nodes: A mobile node equipped with a WLAN

NIC and access points which act as a bridge between a wireless and a wired network. Two different

modes are supported by 802.11: Infrastructure mode and adhoc mode. In infrastructure mode, one

or more fixed central nodes are used as attachment to a wired network. An adhoc network is formed

by several nodes without any central administration.

The MAC layer of WLAN 802.11 is formed by two coexisting coordination functions: the Distributed

Coordination Function (DCF) is used for asynchronous data transfer and the Point Coordination

Function (PCF) is used for synchronous, time-bounded data transfer. WLAN 802.11 defines three

different interframe spaces (IFS): short IFS (SIFS), point coordination IFS (PIFS) and distributed

IFS (DIFS). The IFS are mandatory and control different priorities of events. The DCF is the

25


basic function to access the channel and implements a Carrier Sense Multiple Access with Collision

Avoidance (CSMA/CA) scheme. In CSMA/CA, a sender of a packet senses the channel and starts

to send a frame, if the channel is idle. Otherwise, the transmission is delayed until the channel is

sensed idle again. To reduce the probability of collisions, the sender has to wait for an randomly

generated time after the channel is sensed busy for the first time. The back off time is reduced at

every transmission attempt. After transmitting a packet, an ACK is sent back by the receiver. If the

ACK is not received at the sender, a link layer retransmission is triggered. A second, but optional

method to share the channel with other nodes is RTS/CTS. A Request-to-Send (RTS) packet is send

from the sender to the receiver using CSMA/CA. After receiving the RTS, a Clear-to-Send (CTS)

is sent back to the sender. After a CTS, only the sender is requesting sender is allowed to send

data. Since the RTS packet contains a information about the length of the packet, other nodes can

eavesdrop on this information and backoff for the time of transmission.

The PCF uses a point coordinator which usually resides on the access point. The point coordinator

organizes the traffic flow between the nodes and the access point using a polling scheme. The PCF

is optionally, whereas the DCF has to be implemented by every WLAN node.

2.4.2 Introduction to Bluetooth

Bluetooth [46] was developed to provide a cheap, short range, low power, wireless connection sys-

tem, so that small and cheap devices can exchange data easily. A Bluetooth network is formed out

of several devices that are grouped into piconets and scatternets. A piconet is formed out of one

master device, that controls the traffic on the physical channel by a polling scheme. A master can

communicate to maximal 7 slave devices in an adhoc fashion. A scatternet is formed out of several

collocated piconets that are interconnected to each other via devices, that are slaves in more than

one piconets.

Bluetooth specifies a synchronous, connection oriented (SCO) data transfer mode that can be com-

pared to circuit switched networks and is mainly used for transferring speech data. A maximum

full duplex data transfer rate of 64 kBit/s is achievable in SCO mode. Asynchronous connection-

less (ACL) data transfer can be used to transfer data over a packet-switched network. A nominal

symmetrical data rate of 433.9 kBit/s or a nominal asymmetric data rate of 723.2 / 57.6 kBit/s is

26


achievable in ACL mode.

Bluetooth uses a Frequency Division Multiple Access (FDMA) with frequency hopping to multiplex

different links over the air interface. The frequency hopping sequence is negotiated at the beginning

of a connection. A Time Division Multiple Access (TDMA) scheme is used to send packets over the

connection in a constant time slot. Packets can be sent in 1, 3 or 5 time slots.

Different packet types for the ACL link are defined in the specification of Bluetooth. The packet

types differ mainly in their time slot length and their error protection. Packets can use Forward

Error Correction (FER) and Cyclic Redundancy Check (CRC) to detect bit errors. In case of bit

errors, Bluetooth uses an ARQ scheme to retransmit packets on link layer. Depending on the num-

ber of used time slots and the amount of FEC/CRC, a payload between 17 and 339 bytes can be

carried in one packet.

27


28

Chapter 3

Evaluation Method

The evaluation of the performance of TCP in different scenarios is done using an experimental net-

work. The next chapter gives a definition of scenario and describes the different parameter described

in a scenario as well as the limitations of scenarios regarding to the evaluation.

Different performance metrics to quantify the performance of TCP are also introduced in this chap-

ter.

3.1 Scenarios

TCP can be evaluated in many cases and in different scenarios. The performance of TCP might

be considered in scenarios with a moving mobile node, with different kind of traffics or different

kind of link types. In this thesis a description of a scenario contains a description of the network

architecture, a description of the mobility model and a description of the traffic model.

These different models and its limitations to the thesisi are described in detail next.

3.1.1 Network Architecture

The network architecture basically describes the network nodes and link types used in the path

between the communication partners. The different parameters described in the network topology

can be divided into several descriptions:

• Access technology of mobile node: A mobile node might use different wireless access

technologies to access a wired network. The evaluation is limited to the access technologies

29

3.1 Scenarios

IEEE 802.11 [1] and Bluetooth [46]. Only one concurrent access technologiy will be used.

Multi-homed scenarios are not considered. Although only one wireless technology at time is

used, the level of interference is unknown.

• Number of hops: The number of hops describe the number of single links a packet has to

pass, until it reaches the receiver. The number of can be divided into the number of wired

hops and wireless hops. The number of hops and hence the number of intermediary network

nodes influences the round trip time (RTT). The more network nodes have to be passed, the

higher the RTT is expected. In this thesis, only a single last wireless hop is considered. The

number of wired hops is limited to a small known number depending on the scenario.

• Link layer types of intermediary wired links: Each network node might be connected

with different types of link technologies to a neighbored network node. Besides the wireless

technologies, only Ethernet and serial links are used between the wired networks.

• Network configuration: The network configuration contains information about the routing

process used to forward packets form the sender to the receiver as well as the configuration

of the different links, for example, the serial links may run at different clock rates, the access

point might use special channels or transmitting power.

• Proxy location: The proxy can be inserted in different locations in between the logical path

from the sender to the receiver. The implications of different proxy locations are described in

Section 5.4. In the considered scenarios, the proxy was located on a fixed position.

A meta-model for the network topology that is used for the evaluation, can be found in Figure

3.1.

The meta-model consists of three routers, that form a backbone of the network. Specifications

for the three routers can be found in Appendix B.1. The routers are interconnected via an 8 MBit/s

serial link. On both ends of the backbone, a subnet1 for the communicating end systems was

installed. In case a proxy was installed into the network, it was added to the intermediate router

via a FastEthernet link. The specifications of the proxy host can be found in Appendix B.6. It has

been observed, that the routers send infrequent background traffic caused by routing algorithms or1When subnet is mentioned, it is referred to an IP subnet

30

3.1 Scenarios

Legend:

Fixed Host

Router

TorontoSwitch

Tokyo DelftAalborg8 MBit/s 8 MBit/s

100 MBit/s100 MBit/s

TCP Proxy

100 MBit/s

Host1-Network Host2-Network

Figure 3.1: Meta-modell of the considered infrastructure

MAC address updates.

Based on the meta model three different network architectures are considered in this thesis:

• Fully wired srchitecture

• Single access point architecture

• Mobility support architecture

These network models are described next.

Fully Wired Network architecture

The first test setup used for an evaluation of the performance of the backbone was built without

any wireless link. The network architecture can be found in Figure 3.2.

One fixed host was installed on each edge router with a 100 MBit/s FastEthernet link over a

switch. The specifications of the fixed hosts is described in Appendix B.5, the specification of the

switch in Appendix B.2. No Proxy was installed in this network architecture.

Single Access Point Network architecture

To measure the influence of a wireless link on the performance of TCP, one wired host was repleaced

by a wireless access point and a mobile node. The network architecture can be found in Figure 3.3.

31

3.1 Scenarios

Tokyo Delft

Legend:

Aalborg

Fixed Host

Router

Toronto

10.10.3.254

TorontoSwitch

8 MBit/s 8 MBit/s


Shanghai

10.10.1.254

Figure 3.2: Fully wired network architecture

A laptop is used as mobile node equipped with wireless adapters. The specifications of the mobile

node can be found in Appendix B.7. The used Wireless LAN adaptor is specified in Appendix B.9,

the Bluetooth adaptor in Appendix B.10. For an evaluation of multiple data streams over an access

point, a second mobile node (MN2) was used. The specification of MN2 is described in Appendix

B.8.

Two different access technologies have been used as wireless links. In case of a Wireless LAN

link, a CISCO access point was installed as a bridge between the mobile node and the wired network.

The standard configuration, that was used for the access point, can be found in Appendix B.3. In

case of a Bluetooth link, a Bluetooth access point bridging between the mobile node and the wired

network was installed. The specifications of the Bluetooth access point and the Bluetooth link can

be found in Appendix B.4.

Mobility Support Network architecture

To measure the influences of handover delays on the TCP performance, a network architecture

supporting mobility was used. A second Wireless LAN cell was added to the previous architecture

and mobility support was added by integrating Mobile IP into the network architecture. An overview

can be found in Figure 3.4.

The second Wireless LAN cell was built with a second access point attached to the wired network.

The specification of the second access point can be found in Appendix B.3. Two non-adjacent cells

with different SSIDs have been chosen to minimize the influence of interference and overlapping cells

32

3.1 Scenarios

10.10.1.X

Tokyo Delft

Legend:

Aalborg

Fixed Host

Mobile HostDhaka

Router

Mobile Node

Toronto

Server

10.10.3.254

TorontoSwitch

WLAN Access Point

8 MBit/s 8 MBit/s

100 MBit/s 100 MBit/s

100 MBit/s

Shanghai

100 MBit/s

Figure 3.3: Single Access Point Network Architecture

have been used.

A Mobile IP implementation provided by [37] was used to support IP mobility for the mobile node.

A Home Agent has been installed in the subnet of the first Wireless LAN cell. The subnet conatining

the Home Agent will be referred to home network. A Foreign Agent was installed into the second

Wireless LAN cell. Accordingly, this subnetwork will be referred to foreign network.

3.1.2 Mobility

The second part of a scenario description will cover the mobility. Mobility itself contains a wide

range of mobile objects.

Mobility categories

Mobility can be divided into 4 categories:

• user mobility

• application mobility

• host mobility

33

3.1 Scenarios

Tokyo Delft

Legend:

Aalborg

Fixed Host

Mobile HostDhaka

Router

Mobile Node 1

Toronto

Foreign Agent

10.10.3.254

TorontoSwitch

WLAN Access Point

8 MBit/s 8 MBit/s


100 MBit/s

Shanghai

100 MBit/s

Istanbul

Home Agent

10.10.3.254

Frankfurt

Server

10.10.2.254Shanghai

10.10.3.X10.10.1.X

Figure 3.4: Mobility Support Network architecture

• network mobility

User mobility means, a person may use a special service from every computer he has access to.

Reading your e-mails with a web-interface, would be a typical example of user mobility. You can

read your mails from every terminal, which has access to the internet independent from the web-

browser, the operating system, the computer architecture or even network technology you use, as

long as they meet the different standards. You are able to read your mails at your Unix System with

Mozilla Browser and an Ethernet Local Area Network (LAN) connected to the internet at work.

You can use your Home PC using Windows and Windows Explorer and an Dial-Up Connection to

an Internet Service Provider (ISP) or your even may use your laptop with a Wireless LAN card

connected to an Access Point at the airport.

Application mobility is the ability to move application between different kind of hosts regardless

which operating system or hardware architecture the source or destination host is using. A presen-

tator might move with his presentation from a crowded small room to a bigger room. The application

associated will move with him to a new host, if the presentation application is mobile.

34

3.1 Scenarios

Host mobility describes the movability of computers, mainly notebooks or nowadays IP-aware mo-

bile phones, in a network without loosing its connectivity and without the breakdown of the current

applications and connections running on the mobile host. For instance,the mobile networks like

GPRS, HSCSD and the upcoming UMTS are examples for networks supporting host mobility. One

can use his host (that is your phone) nearly everywhere, as long as network coverage is available.

Other techniques, like WLAN (Wireless Local Area Network, IEEE 802.11), ”Bluetooth” and In-

frared make computers and computer peripherals mobile in a short range. They communicate via

the air-interface based either on radio or infrared signals, but have no built-in support for handovers.

Network mobility outlines the moveability of small networks in the encapsulating network. Wireless

Personal Area Networks (WPANS) connected to the internet via WLAN or UMTS could be an

example for network mobility. A WPAN might be, for example, a wireless system generating an

Electrocardiogram (ECG). The single nodes capture different views of your heartbeat, while the

patient is free to move around.

Mobility considered in the observed scenarios will cover only the mobility of hosts, in particular the

mobility of one or two hosts.

Host mobility categories

Host Mobility itself can be distinguished into several categories:

• Fixed position

• Fixed access point

• Handover in same subnet

• Handover to different subnet

• Handover to different access technology

Fixed position

A Host could be installed on fixed position. On a fixed position, a wireless connection may justify

the lower maximum bandwidth compared to the wired solution, if the installation of a cable might

35

3.1 Scenarios

be difficult for some reasons. On a fixed position, the installation of a wireless can be optimized to

the needs of the fixed host, e.g. by optimizing the position and transmitting power of antennas and

shielding the link to background noise and interference.

The fixed host will thus have a fixed IP-Address and the link quality is expected to be the same

most of the time. Thus TCP is expected to perform well in this scenario.

Fixed access point

When a mobile node moves around a fixed access point in short range, he could stay associated with

the access point at all time, if he stays within the coverage of the access point. While moving around,

he could experience the signal strength of the link and a resulting a higher BER. Also noise and

interference could be a problem, if the signal between access point and mobile node is not shielded.

This would also affect the BER.

While the mobile node is constantly associated to the access point, its IP-Address will be constantly

assigned. Packet losses will occur due to congestion or a high BER, which is rather likely, especially

on wireless links with bad channel quality.

This scenario is typical for rooms in offices or hotels, where access points, so called hot-spots, are

installed.

Handover in same subnet

If a mobile node gets out of range of the access point into the range of another access point, the

scenario is called handover. One scenario contains the handover to the same subnet. The IP-Address

remains constant, but during the handover a disconnection and reassociation time will effect the TCP

performance. This time could be influenced by the overlapping degree of the access points and by

the type of configuration of the mobile node. If the mobile node is configured dynamically, e.g. via

the Dynamic Host Configuration Protocol (DHCP), some information, like its current IP-Address,

has to be exchanged to configure the mobile node. Thus, the disconnection time will be longer as in

case of a static configuration.

During the time of disconnection and reassociation, TCP is unable to send data over the network.

The standard TCP implementation could would interpret this scenario as congestion and perform a

36

3.1 Scenarios

slow-start. This would lead to a performance degradation.

A typical application of this scenario would be a building, that is equipped with several Access

Points on different levels and rooms.

Handover to different subnet

If a mobile node disconnects from one access point into the range of another access point, the new

access point must not be necessarily in the same subnet as the access point, the mobile node was

connected to before. From the corresponding nodes point of view, the mobile node is not reachable

with its first IP-Address. As the mobile node will not response to any packet send to the old IP-

Address, this will results in several timeouts and will finally break down the TCP connection. To

overcome this problem, a mechanism to make the mobile node also available in other subnetworks

than the home network was introduced. This approach was termed Mobile IP [38].

During the handover, different components impact the time, the mobile node is unreachable. The

time of physical disconnection as well as the time of reassociation prevents the mobile node of sending

or receiving any packets. The time of reconfiguring the mobile node to the new scenario influences

the time of unreachability as described above. The fourth component, that counts to the time of

unreachability, is the time, the mobile nodes needs to register at the foreign agent and to setup a

IP-Tunnel to the home agent.

Depending on the implementation of the home agent and foreign agent, packets send to the old IP-

Address might be lost, if the agents implement a store-and-forward-algorithm. TCP itself will then

cause a retransmission timeout and resend the packet again. Another case would be, that the sending

TCP keeps sending packets while the mobile node hands over. After reconnecting, reassociation and

relocating, the receiving TCP will receive some out-of-order data and acknowledge this data with

DUPACKs. In both cases (DUPACK and timeout), TCP wrongly assumes a congested network

and lowers unnecessarily the CWND. If the home and foreign agents implementation is aware of

the TCP protocol on top, a more intelligent store-and-forward algorithm could be implemented,

that will forward packets based on the ACKs of the mobile node. This approach would equal a

home/foreign agent with an integrated TCP proxy.

37

3.1 Scenarios

Handover to different access technology

A mobile node could also switch to another access technology. Depending on the underlying network

architecture, this handover could be to the same subnet, or to a different subnet. In this case, the

time of physical disconnection, the time of reassociation and relocating will impact the time of

unreachability.

Wired optimized TCP implementation would react to a packet loss due to time-over or DUPACKs2

with a slow-start. In case of a handover to a different handover, this behavior is desirable, since

the maximum available bandwidth is very unknown and varies strongly between different access

technologies. Table 3.1.2 gives an overview of maximum bandwidth and round-trip times of different

access technologies.

Maximum Bandwidth Round-trip timesGPRS 196 kBit/s 700 ms

Bluetooth 723 kBit/s 200 msWireless LAN 802.11b 11 MBit/s 20 ms

UMTS 2 MBit/s 200ms

Table 3.1: Overview of different Access Technology Parameters

3.1.3 Traffic Model

The traffic model contains information about the network traffic, that is applied to the network

model. In this thesis, only unicast data flow will be observed.

• Type of transport layer protocol: Two distributed applications might use different transport

layer protocols to communicate. The type of transport layer and the transport layer protocol

specifc parameters are part of the traffic model

• Size of transmitted data or transmission duration: Data is sent over a transport layer protocol.

The traffic model contains either a specification of the size of the transmitted data or the

duration, data is transmitted from sender to receiver.

• Number of connections: The number of connections concurrently established over the network

characterizes the traffic model.2depending on the implementation, DUPACKs may cause slow-start

38

3.2 Measurement procedure

• Unidirectional / bidirectional traffic: data might be transmitted only in one direction (unidrec-

tional) or data might be sent in both directions as it appears mainly in interactive applications.

• Constant or bursty traffic: Traffic flowing over a network need not necessarily be of constant

bandwidth or packet rate. In case of variable bit rate video streaming [31], the used bandwidth

will vary over time, online games usually create traffic patterns characterized as ON/OFF-

traffic [45]. Such traffic sends data repetitively in a specific interval (ON period) following a

period without sending data (OFF period).

In the evaluation, only three different basic traffic types that can be combinded, are used:

• Unidirectional TCP connection: A TCP connection is established between two end sys-

tems. Only unidirectional data streams are considered. A MSS of 1460 byte per segment will

be used throughout the evaluation in order to fully utilize an Ethernet frame. A sending and

receiving socket buffer of 85 kbyte is used for a TCP connection.

• Unidirectional constant bandwidth UDP stream: A UDP stream with a constant appli-

cation layer bandwidth is used in some scenarios. A segment size of 1472 bytes and a sending

and receiving socket buffer of 64 kbyte is used for UDP streams, unless otherwise specified.

• Unidirectional bursty UDP stream: A bursty UDP stream is used to simulate variable

data flow as it often occurs in the Internet. The UDP stream sends UDP packets an ON-period

and idles in an OFF-period. Only ON- and OFF-periods that are exponentially distributed

with the same mean value are considered. During the ON-period, data is sent at a constant

application layer bandwidth.

3.2 Measurement procedure

A measurement consists of three phases. First, the network has to be setup for the measurement

according to the scenario. Secondly, the measurement itself has to be performed according to the

traffic model. The third step is to evaluate the gathered data and to perform statistical analysis.

In order to perform a measurement according to the traffic model, IPerf Version 1.7.0 [49] was used

as traffic generator for UDP and TCP traffic. Iperf is able to generate TCP traffic with specific

39

3.3 Performance Metrics

buffer sizes and UDP traffic with definable payload sizes and application layer bandwidth, As IPerf

is not capable of generating ON-OFF UDP traffic, a self written traffic generator UDPBurst was

additionally used in some scenarios.

Ethereal Version 0.10.0 [21] was used to capture the packets on both communication ends, i.e. on

sender and receiver side. Packets leaving or arriving at the network interface card (NIC) are recorded

into a file and timestamps are placed to the packets at the time, the packets have been detected by

Ethereal.

After recording the packets into a file, the files have been analyzed via tcptrace to calculate the

throughput metrics. Matlab [48] has been used to compute the statistical parameters and GNUplot

[42] was used to visualize the data.


Different metrics are needed to describe quantitavely the performance of UDP and TCP. The metrics

used to analyze the performance of TCP are described in the next section.

3.3.1 Instantaneous Throughput

Packets captured with Ethereal at the network interface card (NIC) are marked with a time stamp,

at the time they are arriving or leaving, Thus, Ethereal creates tuples formed by (time, packet),

where time is the time, the packet was captured and packet is the byte sequence of the captured

packet. By ordering the tuples by time, every packet can be given a consecutive ascending number

k. Subsequently, the series of captured packets will be referred to packetk.

From an application layer point of view, the throughput Λ can be calculated as the amount of data,

that can be send over UDP or TCP in a given time:

Λ =amount of data

time(3.1)

Based on this equation, the throughput is calculated only by packets that carry payload. In case

of UDP, that sends only data packets, the series of data packets is equal to the series of captured UDP

packets. TCP introduces ACK and retransmitted packet, that are counted to calculate throughput

values. Hence, the data packet series is extracted out of the captured packet series by leaving out

40


all ACK and retransmitted packets.

Based on the data packet series, the instantaneous throughput that is achieved for every single

packet can be calculated. It is assumed, that the sender always has enough data to send, so that the

time to transmit a data packet can be calculated as the time difference to the previous data packet:

Λinst(n) =packetsizen

tn − tn−1(3.2)

whith

• Λinst(n) the constant throughput of data packet n

• packetsizen the amount of TCP payload in the data segment n, measured in bytes

• tn the detection time of data segment n

Additionally, the average Λinst(n) over the instantaneous throughput can be computed by:

Λinst =∑n

l=1 Λinst(i)n

(3.3)

3.3.2 Instantaneous Averaged Throughput

The instantaneous throughput calculates the throughput for every single packet. Measurements of

the instantaneous throughput showed that throughput values tend to build blocks of high throughput

values. A small group of values gained a very high throughput, while the following packet showed

a very low throughput. Ethereals method of timestamping the packets can cause this effect. The

packets arriving in the network card are buffered before read and timestamped by Ethereal. Thus,

while Ethereal gets processing time by the kernel, Ethereal reads all packets stored in the buffer

and places the actual system clock value as timestamp to the packets. Thus, a bundle of packets

gets almost the same timestamp resulting in a high throughput value. After expiring the processing

time, additional packets are buffered and delayed resulting in a low throughput for the first packet.

Other influences may also affect the correct timestamping.

To overcome those effects, a block of instantaneous throughput values is build and the average over

41


the block is calculated. The throughput values calculated over a block of instantaneous throughput

values are termed instantaneous averaged throughput and can be described as follows:

Λaverage(n) =

∑i+kl=i+1 packetsizel

ti+k − ti, i = k ∗ (n− 1), for a given k. (3.4)

The average Λaverage(n) can be computed by:

Λaverage =∑n

l=1 Λaverage(i)n

(3.5)

An import question is, how to set the correct value for the block size k. From intuition, some

considerations can be made. The effect of process switching and thus the number of grouped

packets depends on the processing time, that is given to one process. If this time is very long,

many packets will be buffered until they are read and timestamped resulting in a big block of high

throughput values. Thus, the more often processes are switched and the more often the times-

tamping process can read the packet buffer, the more appropriate the throughput values are and

less packets have to be averaged. So the block size is proportional to the processing time given

to one process3. Secondly, the more processes are running on the host, the less often the pro-

cessing time is granted to the timestamping process. Hence, the block size is proportional to the

number of concurrently running process excluding the timestamping process. On the other hand,

the higher the packet rate arriving at the NIC with constant processing time, the more packets

will be buffered resulting in a higher block size. Hence, the block size is proportional to the

packet rate arriving at the NIC. Summing up, these consideration lead to the conclusion, that

block size ≈ packet rate ∗ (number of processes− 1) ∗ processing time .

For simplification, a constant block size of 10 packets have been used throughout the measurements,

since it showed a good compromise between time accuracy and accurate throughput.

When calulating statistical throughput values, mean throughput values and confidence intervals are

calculated based on Λaverage(n).

3It is assumed, that the processing time is sliced into equidistant parts and given equally to every process. Thisround robin process scheduling scheme can be assumed in common operating systems for non real-time applicationsthat use the same process priorities

42


3.3.3 Transmission Throughput

When transferring objects like files or HTTP objects over a TCP connection, the end-user is mainly

interested in the time it takes to transmit the complete object. This time is often termed transmission

time. Based on the transmission time, the development of the transmission throughput over time

can be calculated by:

Λtransmission(n) =∑n

i=1 packetsizei

tn − t0(3.6)

with t0 the detection time of the first detected packet. In single TCP connection scenarios, t0 is

the time of the first SYN packet detected and hence t0 = 0. In multiple connection, t0 may be the

detection of the first UDP or TCP packet depending on the scenario.

Given these formulas, the average value of the instantaneous throughput over the transmission

time, the average value of the instantaneous averaged throughput over the transmission time and

the transmission throughput after the transmission time can be calculated. Since the packet times

are not distributed in equidistant intervals, those values differ:

Λtransmission(n) 6= Λaverage 6= Λinst (3.7)

3.3.4 Round-Trip Times

Based on the ACK mechanism of TCP, the RTT tRTT (n) of a data packet can be computed. Since

every sent data packet requires a subsequent ACK packet, the time difference between the detection

of a data packet and the detection of an ACK packet can be used to measure the TCP RTTs. Since

data packets can be cumulative acknowledged, the RTTs calculations are only based on non-delayed

ACKs:

tRTT (n) = tACK(n)− tdata(n) (3.8)

with

• tRTT (n) the measured RTT for data packet n

43


• tACK(n) the detection time of an ACK for data packet n

• tdata(n) the detection time of data packet n that is not delayed ACKed.

In principle, the RTT measurements can be done on senders and receiver side. On receiver side,

the RTT measurement result in a measurement of the processing time, since received data packets

are processed and ACKs generated immediately. The oneway packet delay, i.e. the time it takes the

network to transmit a packet over the network, is not included at the receiver’s side. Hence, RTT

measurements are only made on the sender’s side.

Based on the single RTT measurements, the RTT average tRTT can be computed by:

tRTT =∑n

i=1 tRTT (n)n

(3.9)

95% confidence intervals are computed as indication of jitter.

3.3.5 Handover delay

During a handover, the mobile nodes looses its connectivity to a network until it is reconnected

again. To measure the performance of TCP in handover situations, a UDP probing data stream

is concurently to the TCP connection established, while the handover is performed. The handover

delay on network layer can be approximated by :

∆network = tfirst − tlast (3.10)

with

• ∆network the network layer handover delay

• tfirst detection time of first packet seen after handover

• tlast detection time of last packet seen before handover

Accordingly, the TCP handover delay is computed by:

∆TCP = tfirstTCP − tlastTCP (3.11)

with

44

3.4 Conclusion

• ∆TCP TCP handover Delay

• tfirstTCP detetion time of first TCP packet seen after handover

• tlastTCP detetion time of last TCP packet seen before handover

3.3.6 Other Performance Metrics

Some other metrics are used to quantify the performance of TCP more precisely:

• ηpackets: Number of packets to transmit the given data.

• ηRT : Number of retransmitted packets.

• ϑRTO: Number of retransmission timeouts.

3.4 Conclusion

This chapter aimed to introduce the considered scenarios, the evaluation process as well as the

performance metrics.

A definition of a scenario has been given and has been decomposed into a network architeture, a

mobility model and a traffic model. Given the description of the models, the considered scenarios

have been limited. The limitations are as follows:

• Network architecture: Only last single wireless hops and fixed proxy location are considered.

The thesis focus on the wireless access technology Wireless LAN and Bluetooth. Only the three

main architectures ”fully wired architecture”, ”single access point architecture” and ”mobility

support architecture” are evaluated in this thesis.

• Mobility: The different flavours of mobility have been described. In the evaluation, only host

mobility is considered.

45

3.4 Conclusion

• Traffic model: The chracteristics of a traffic model have been described. The traffic model

used in the evaluation is limited to three basic streams, that can used combined: A unidi-

rectional TCP stream, a unidirectional constant bandwidth UDP stream and a uniderectional

bursty UDP stream.

The experimental approach to evaluate the performance of TCP has been described. To quantify

the performance, different performance metrics have been introduced. The main metrics are as

follows:

• Instantaneous throughput Λinst(n)

• Instantaneous averaged throughput Λaverage(n)

• Transmission throughput Λtransmission(n)

• Network layer hand over delays ∆network and TCP hand over delay ∆TCP

• RTTs

46

Chapter 4

Evaluation of standard TCP

TCP is reported to perform poorly under conditions, where the initial assumptions made for wired

TCP flavours cannot be kept up. Wired TCP flavours assume that disconnections are unlikely and

packet loss occurs only in case of congestion in the network. Wireless links introduce packet drops

due to bit errors and times of link disconnection due to handovers of the mobile node.

Different measurements with an experimental network have been made to analyze the behavior of

TCP over two wireless technologies, IEEE 802.11b [1] and Bluetooth [46]. The results of the exper-

iments are illustrated in the following chapter.

4.1 TCP over Ethernet and Serial Links

The experimental network used for the experiments consisted of different types of network nodes:

routers, switches and fixed hosts as well as different type of links like wireless IEEE 802.11 links,

wireless Bluetooth links, wired serial links and wired FastEthernet links.

Since the different links and nodes influence the end-to-end connection characteristics, experiments

have been made to get an overview of those influences. In a first experiment, the influence of the

test-setup on the connection performance was measured. Secondly, the performance of a 8 MBit/s

serial link, that was established between the routers, was analyzed, since the 8 MBit/s serial link

provided nominally a lower bandwidth than a IEEE 802.11 11 MBit/s WLAN link. The results of

those experiments are presented next.

47


4.1.1 Influence of Test-Setup

The packet capturing program Ethereal was used to capture the packets from the network interface

card in order to perform detailed statistical and analytical evaluation on the traffic flow. Since

capturing packets takes processing time of the CPU of a node, this degradation of available processing

power and time may affect the throughput and RTTs of the TCP connection.

In order to get an impression about the influence of the capturing program, the following experiment

was made. The fully wired network architecture as described in Section 3.1.1 was set up and a TCP

connection between two fixed hosts was established transferring 10 MByte of data. Since the traffic

generating program IPerf is capable of reporting the duration time of the TCP Connection with a

resolution of 100 ms, a comparison between the duration times of a run with Ethereal enabled and

a run with Ethereal disabled could be used as an indicator of the influence of Ethereal on the TCP

performance. Note, that the connection time, that is reported by IPerf, is the connection time seen

from an applications point of view and thus not the time between the first SYN-packet and last

FINACK-packet seen. The packets will be buffered in different levels of the operating system and

additional delay due to process- and kernel-thread-switching will be encountered. Table 4.1 shows

the transmission times for the described scenario with Ethereal enabled and disabled.

Transmission Time with Ethe-real disabled [s]

Transmission Time with Ethe-real enabled [s]

Run 1 10.9 11.0Run 2 10.9 11.1Run 3 10.9 11.0Run 4 10.9 11.1Run 5 10.9 11.2Run 6 10.9 11.1Run 7 10.9 11.2Run 8 10.9 11.0Run 9 10.9 11.2Run 10 10.9 11.2Average 10.9 11.11Std.Dev. 0.0 0.08756

Table 4.1: Comparison of transmission times with Ethereal disabled/enabled

Performing a Lilliefors-Test [48] on the transmission times with Ethereal enabled to test if the

data follows a normal distribution, leads to the result, that the null hypothesis can be accepted and

the data thus follows a normal distribution. Based on this result, a T-Test can be applied on both

48


data sets to compare their means and calculate their statistical differences in mean value. Perform-

ing the T-Test, the Null-Hypothesis, that both data sets have the same means, can be rejected at

a significance level of 5%. The confidence interval of the difference between the transmission times

with Ethereal disabled and enabled can be computed to [0,1518s - 0,2682s].

Although the statistical analysis showed that the influence of Ethereal on the performance is statis-

tical significant, the influence on the overall transmission time and thus the average throughput is

rather low (2% in worst case). It has to be considered, that the measurement procedure is based on

a higher layer in the operating system. Thus, influences of process- and thread-switching are higher

than on lower layers. The measurements made in the following chapters are based on a lower layer

and thus more appropriate.

4.1.2 Influence of Serial links on Performance

The different routers used in the experimental network have been interconnected over serial links

capable of transmitting 8 MBit/s. Since some considered access techniques, especially Wireless LAN

802.11b, is nominally capable of transmitting 11 MBit/s of data over the wireless link, the serial link

would limit the available bandwidth instead of the wireless link resulting in different results. The

fully wired network architecture was used to measure the maximum bandwidth with UDP and to

measure the performance of TCP.

UDP Performance over a 8 MBit/s serial link

To measure the maximum bandwidth, that can be provided by the serial links, the throughput using a

constant bandwidth packet rate UDP stream as described in Section 3.1.3 was used. The application

layer bandwidth provided by UDP was set to 8,5 MBit/s. The throughput graphs measured at the

sender and receiver side are shown in Figure 4.1.

The throughput graph shows, that the instantaneous throughput as well as the instantaneous

averaged throughput reach nearly a maximum of 1 MByte/s, which equals 8 MBit/s. In constant

time intervals of around 5s several peaks of the throughput value can be observed.

These dropdown periods can be can be caused by Ethereal: Since Ethereal records packets at Eth-

ernet level, packets with a packet size of 1514 bytes including all headers are recorded and written

49


0

200000

400000

600000

800000

1000000

1200000

1400000

1600000

1800000

2000000

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35

Thr

ough

put (

byte

/s)

Time

UDP Throughput of a 8 MBit/s serial link (Sender)

Instantaneous ThroughputInstantaneous Averaged Throughput

Transmission Throughput0

200000

400000

600000

800000

1000000

1200000

1400000

1600000

1800000

2000000

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35

Thr

ough

put (

byte

/s)

Time

UDP Throughput of a 8 MBit/s serial link (Receiver)

Instantaneous Throughput Instantaneous Averaged Throughput

Transmission Throughput

Figure 4.1: UDP Throughput over 8 MBit/s serial links at sender (left figure) and receiver side(right figure)

into a file, that is buffered in the local RAM. As packets arrive at an application layer bandwidth

of 1 MByte/s, after 5 sec, the buffered in the memory contains 1 MByte/s∗5s∗1514 byte1472 byte ≈ 5.4 MByte.

This amount of data is then transferred from the local RAM to the physical memory on the hard

disk. The writing process is CPU intensive on a low power PC, so that less CPU processing time is

left to record the packets in real-time in Ethereal. Secondly, occupied CPU resources by the kernel

due to disk writes reduce the available CPU processing time for IPerf. Hence, IPerf is not able

to generate UDP Packets at the given bandwidth resulting in a lower throughput while the kernel

is writing the Ethereal trace file to the hard disk. IPerf uses an adaptive method to compute the

delay times between two packets before they are sent. Hence, the time it takes the operating system

to send a packet to NIC is taken into account. Since the new computed delay time is based on

the previous sending time, an oscillating sending time causes an inappropriate inter packet delay

resulting in oscillating throughput.

A second effect, that influences the throughput, is generated by the packet-capturing method, Ethe-

real is using. The operating systems copies all packets that are arriving and leaving the NIC into

a buffer. Ethereal reads the packets from this buffer and places a timestamp to every packet at

the time, the packet was read from the buffer. In high loaded CPU situations, more packets are

delayed in the buffer before a timestamp is placed. Thus, packets will be timed too late resulting

in a lower instantaneous throughput. In contrast, packets, that are timestamped in time after a

50


delayed packet, will experience an incorrect higher throughput.

Average Through-put Λaverages

[ kBytes

]

Standard Devia-tion of Λaverage(n)

[ kBytes

]

95% Confidence In-terval of Λaverage(n)

[ kBytes

]

Λtransmission(10s)

[ kBytes

]

Sender 1050,6 245,6 [1039,8 - 1061,4] 981,8Receiver 954,3 103,8 [949,6 - 959,0] 922,6

Table 4.2: UDP Throughput over 8 MBit/s serial links

Despite the observed throughput dropdown, an estimate for the maximum achievable throughput

over the serial link can be given by Λaverage and the confidence interval of Λaverage(n) confidence

interval. The results of this computation is given in Table 4.2. Since the throughput dropdown

cause a lower average throughput compared to the real throughput value, this measured value can

be used as a lower bound for the real throughput value. Later evaluation showed, that a UDP

throughput of 850 kByte/s and thus the serial link is able to provide sufficient bandwidth not to

limit the bandwidth of Wireless LAN.

TCP Performance over a 8 MBit/s serial link

In a second experiment, the performance of TCP over the serial links was evaluated. A single

TCP connection as described in Section 3.1.3 was used to measure the TCP performance. The

transmission throughput graphs measured at sender and receiver side can be found in Figure 4.2.

0

100000

200000

300000

400000

500000

600000

700000

800000

900000

1000000

1100000

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35

Thr

ough

put (

byte

s/se

c)

Time

TCP Transmission Throughput over a 8 MBit/s serial link (Sender)

Run 1Run 10Run 2Run 3Run 4Run 5Run 6Run 7Run 8Run 9

0

100000

200000

300000

400000

500000

600000

700000

800000

900000

1000000

1100000

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35

Thr

ough

put (

byte

s/se

c)

Time

TCP Transmission Throughput over a 8 MBit/s serial link (Receiver)


Figure 4.2: TCP Transmission Throughput over a 8 MBit/s serial link

51


From the graphs it can be observed, that the Ethereal effects the transmission throughput mostly

on the senders side, whereas the transmission throughput on the receiver side is less influenced by

Ethereal. Since IPerf creates high load on the sender CPU, Ethereal is granted less processing time

resulting in inappropriate timestamps resulting in throughput dropdowns. Plotting Λaverage and

the confidence intervals of Λaverage(n) and leads to Figure 4.3.

948000

950000

952000

954000

956000

958000

960000

962000

1 2 3 4 5 6 7 8 9 10

Thr

ough

put (

byte

s/s)

Run

TCP Throughput over Serial links

Figure 4.3: Instantaneous Averaged TCP Throughput over a 8 MBit/s serial link

The average throughput achieved over the serial link varies sparsely except the first run. In

order to calculate the throughput degradation caused by TCPs dynamics, a t-test was performed

over Λaverage(n) of TCP of each run compared with the coresponding UDP values. The t-test

calculates that the TCP throughput is in a 95% confidence interval of [ 30,0 - 40,6 ] kbytes/s higher

than the UDP throughput.

These results are counter-intuitive to the expectation. TCP should degrade the maximum application

layer throughput compared to a UDP stream due to its increased overhead and its congestion

control and slow start algorithm. Since the throughput values were used as indication for maximum

52


achievable throughput, no further investigation was made. The latter evaluation showed, that the

serial link provided sufficient bandwidth not to limit the bandwidth of the wireless link, when both

are part of an end-to-end connection.

TCP Round-trip times over a 8 MBit/s serial link

Based on the ACK-packets, the RTT times for data packet have been measured. For every single

run, the average and 95% confidence intervals have been calculated and are visualized in Figure 4.4.

63.20

63.40

63.60

63.80

64.00

64.20

64.40

64.60

64.80

1 2 3 4 5 6 7 8 9 10

RT

T (

ms)

Run

RTT of TCP over Serial links

Figure 4.4: TCP RTTs over 8 MBit/s serial links

Calculating the average over tRTT of each single run leads to RTT of 64.1 ms. Conceptually, the

RTT can be decomposed into different delays:

• Propagation delay is the time, it needs to transport a bit over the physical medium. Since

only link length up to 40m have been used, the propagation delay can be assumed to.

• Serialization delay is the time it needs to serialze a data packet and send it to the medium.

53

4.2 TCP over Wireless LAN

• Queuing delay is the time it packets are buffered at intermediate routers.

• Processing delay is the time it takes the receiver to process a packet.

Based on the specification of the serial link and the FastEthernet throughput, the serialization

delay of a 1460 byte segment and a following ACK-packet in reverse direction over 2 serial links

can be computed to 6,2 ms. Measurements at the receiver side showed, that the processing time

for generating an ACK is in the interval [ 0.3 - 0.7 ] ms. Hence, the additional delay added to the

RTT is caused by queuing. Since the TCP (TCP Reno in Linux) to estimate the maximum available

bandwidth by successive doubling the sending rate in slow start, packets wiull be queued when the

maximum bandwidth is achieved.


After measurements over the the serial links of the experimental network, measurements were ex-

tended to evaluate the TCP performance over Wireless LAN (WLAN 802.11b). A mobile node

equipped with a WLAN card and a WLAN access point attached to the experimental network pro-

vided a basis for the following experiments.

4.2.1 General Performance of TCP over WLAN

In order to get an overview of the performance and throughput of a wireless link, two experiments

have been made. First, a constant packet rate UDP stream was used to measure the maximum

throughput, that is achievable on link-layer. Secondly, the same experiment was repeated with a

TCP flow and compared with the UDP stream.

In both experiments, the single access point network arhcitecture as described in Section 3.1.1 has

been used. The mobile node stayed at a distance of 2m from the access point.

UDP Performance over WLAN

For the first experiment, the traffic model consisted only of a constant bandwidth UDP stream of

7,5 MBit/s at application level. Thus, a packet is send every 1,57 ms. Taking the overhead of

UDP, IP and Ethernet into account, the bandwidth at link layer can be computed to 7,7 MBit/s,

54


which equals 960 kbyte/sec . Each measurement lasted 30sec and was performed in upstream and

downstream direction1. The results for downstream and upstream are shown in Figure 4.5.

0

200000

400000

600000

800000

1000000

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35

Thr

ough

put (

byte

/s)

Time

UDP Throughput over Wireless LAN (Downstream)


Transmission Throughput0

200000

400000

600000

800000

1000000

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35

Thr

ough

put (

byte

/s)

Time

UDP Throughput over Wireless LAN (Upstream)

Figure 4.5: Performance of UDP over Wireless LAN

To evaluate the throughput of UDP over Wireless LAN, Λaverage as well as the Λtransmission

at the end of the transmission can be considered. Table 4.3 shows the throughput statistics for

the UDP connection over Wireless LAN. The mean throughput as well as the confidence interval

calculations are based on Λaverage. The confidence level was chosen to 95%.

Λaverage [ kBytes

] Confidence Inter-val Boundaries ofΛaverage(n) [ kByte

s]

Λtransmission [ kBytes

]

Downstream 857,8 ± 3,5 850,6Upstream 479,5 ± 0,8 479,0

Table 4.3: Statistical Performance Parameters of UDP over Wireless LAN

The value for mean throughput and transmission throughput differ slightly, since the packets do

not arrive in equidistant time intervals.

The evaluation shows that a UDP application layer throughput of about 850 kbytes/s (6,8 MBit/s),

is achievable in downstream direction. Comparing this value to the UDP throughput achievable over

the serial link (954 kbyte/s = 7,6 MBit/s), it can be concluded, that the wireless link provides less

1Upstream and Downstream-Direction is seen from the mobile node’s point of view. Thus, in downstream direction,data is send to the mobile node, while data is send from the mobile node in upstream direction

55


throughput than the 8 MBit/s serial link, although the nominal throughput of 802.11b is 11 MBit/s.

In upstream direction, a low throughput of 480 kbytes/s (3.8 MBit/s) is achieved, although WLAN

provides a symmetric 11 MBit/s wireless link. Further evaluation showed, that on sender as well as

on receiver side the number of captured packets and hence the throughput was equal. Measurements

with different mobile nodes with the same WLAN NIC card as well as measurements with a different

WLAN NIC card of the same model and different operating systems on the mobile node showed

the same UDP performance. This leads to the conclusion, that the WLAN NIC adapter was not

able to send at higher data rates than the observed throughput. A measurement with a Cisco 350

WLAN NIC adapter instead showed a performance in upstream direction, that is comparable to the

downstream performance of the 3Com card. This effect may be a cause of compatibility, since the

used access point was also a product of Cisco.

TCP Performance over WLAN

To measure the performance of TCP and to be able to compare the performance of the wireless link

teh experiment was repeated with a TCP connection between the mobile node and the fixed host.

Figure 4.6 shows the transmission throughput for every run in downstream and upstream direction.

0

100000

200000

300000

400000

500000

600000

700000

00:00 00:02 00:04 00:06 00:08 00:10 00:12

Thr

ough

put (

byte

s/se

c)

Time

TCP Transmission Throughput over Wireless LAN (Downstream)


0

100000

200000

300000

400000

500000

600000

700000

00:00 00:01 00:02 00:03 00:04 00:05 00:06 00:07 00:08 00:09 00:10 00:11

Thr

ough

put (

byte

s/se

c)

Time

TCP Transmission Throughput over Wireless LAN (Upstream)


Figure 4.6: TCP Performance over Wireless LAN

Different observations can be made from the graphs. In downstream direction, TCP adapts

accurately to the maximum available bandwidth. The transmission throughput after 10s can be

56


observed to be 700 kbytes/s. Over ten runs, TCPs behavior seems very stable. In contrast, in

upstream direction TCP seems to adopt more slowly to the maximum available bandwidth. The

maximum available bandwidth can be observed to be lower than in downstream direction. Over ten

runs, the maximum available bandwidth varies more than in downstream direction. To prove those

observations, a statistical analysis of the throughput values has been performed. The analysis can

be seen in Table 4.4.

Downstream Upstream

Λaverage

[ kBytes

]

ConfidenceIntervalBoundaries ofΛaverage(n)

[ kBytes

]

Λtransmission(10s)

[ kBytes

]

Λaveraget

[ kBytes

]

ConfidenceIntervalBoundaries ofΛaverage(n)

[ kBytes

]

Λtransmission(10s)

[ kBytes

]

Run 1 717,9 ± 77,0 700,7 654,6 ± 111,6 609,8Run 2 721,5 ± 74,0 717,2 618,8 ± 113,7 608,5Run 3 719,4 ± 84,1 708,3 600,4 ± 113,8 560,9Run 4 706,2 ± 80,7 697,0 672,7 ± 110,6 546,6Run 5 718,5 ± 77,3 691,0 677,7 ± 19,9 631,5Run 6 726,5 ± 73,1 704,3 672,9 ± 110,1 646,0Run 7 727,0 ± 73,2 713,6 655,9 ± 111,0 639,5Run 8 724,5 ± 74,0 713,7 664,3 ± 111,1 617,3Run 9 715,9 ± 80,52 710,8 635,5 ± 112,1 623,5Run 10 728,6 ± 68,2 701,3 651,9 ± 11,7 590,7Average 720,6 705,8 650,5 607,4

Table 4.4: Statistical Performance Parameters of TCP over Wireless LAN

Assuming, that the channel quality did not change significantly during the measurement of UDP

and TCP flows and further assuming, that the UDP throughput measured from above can be used

as metric for the maximum achievable throughput over a wireless link connection, the performance

degradation due to TCP slow-start and congestion algorithm can be calculated as shown in Table

4.5.

UDP TCP Degradation

Λaverage

[ kBytes ]

Λtransmission(10s)

[ kBytes ]

Λaverage

[ kBytes ]

Λtransmission(10s)

[ kBytes ]

Λaverage [%] Λtransmission(10s)[%]

Downstream 857,8 850,6 720,6 705,8 15.9 17.0Upstream 479,5 479,0 650,5 607,4 -35.7 -26.8

Table 4.5: Statistical Comparison between UDP and TCP over Wireless LAN

The statistical evaluation proves the visual observations. In downstream direction a TCP

throughput of 700 kbyte/s (equals 5.6 MBit/s) can be achieved. Compared to the UDP flow,

57


around 16% of throughput is lost due to TCP slow-start, congestion control and additional over-

head. In upstream direction a throughput of 600 kbyte/s (which equals 4.8 MBit/s) can be achieved

in contrast to a low UDP throughput in upstream direction. An explanation for this behavior could

be that overloading the card with packets leads to a lowered throughput.

4.2.2 Curve fitted Transmission Throughput

Based on the form of the transmission throughput graph and the consideration that such a curve

could be compared to saturation curve, an approach to fit the measured values to a saturation

curve was applied to the values measured above. The time coherence used for a fitted transmitted

throughput is expressed by the following expression:

Λtransmission(n) = Λmax ∗ (1− e−tn−ts

tr ) + εn (4.1)

with the measured parameters

• tn packet detection time

• Λtransmission(n)

and the fitting parameters

• Λmax maximum achieved throughput

• ts setup time of connection

• tr relaxation time

The estimation error εn expresses the degree of error made in the fitting process.

The data series calculated by the transmission throughput were fitted to this equation. Since a indi-

vidual Λtransmission(n) value contains information about the history of the transmission throughput,

the transmission throughput values are highly correlated. Thus, the estimation error εn will also be

highly correlated. This considerations leads to to the result, that a standard least square method

will produce wrong results, thus a generalized non-linear least squares method [22] has to be applied.

This method is provided by the software R [52].

58


An analysis of a single TCP measurement over Wireless LAN using a generalized non-linear least

squares aproximation method on the transmission throughput data led to the following results pre-

sented in Table 4.6.

Maximum Throughput 693109 Bytess

Connection Setup Time 0.0593 sRelaxation Time 0.1412 s

Table 4.6: Curve fitted Transmission Throughput parameters

Comparing the maximum transmission throughput (693,1 kBytes ) computed by approximation

to the transmission throughput gained at the end of the transmisison (697,0 kBytes ) leads to the

conclusion, that the approximation at the end of the connection can be seen as appropriate. Plotting

the results and calculating the residuals of the estimation leads to Figure 4.7.

0

100000

200000

300000

400000

500000

600000

700000

00:00 00:01 00:02 00:03 00:04 00:05 00:06 00:07 00:08 00:09

Curve fitted Transmision Throughput (WLAN, downstream, Single TCP Connection)

f(t) = 693109.0*(1-e-(t-0.0593)/0.1412)

Transmisison ThroughputCurve fitted Transmisison Throughput

-120000

-100000

-80000

-60000

-40000

-20000

0

20000

40000

60000

00:00 00:01 00:02 00:03 00:04 00:05 00:06 00:07 00:08 00:09

Residuals for Curve fitted Transmission Throughput

Figure 4.7: Curve fitted Transmission Throughput and Residuals

The residuals show, that the approximation in the beginning of the connection is not accurate

due to an inappropriate model. Also a steady TCP state and thus a steady transmission throughput

can not be assumed. In the single TCP connection scenario, the approximation did not converge in

most cases, so that this approach was not followed further.

59


TCP Round-trip times over WLAN

To conclude the evaluation of a single TCP connection over a WLAN link, the RTTs have been

analyzed. RTTs were measured at the sender side based on the measurements from above. For

every single run, the average RTT and its 95% confidence interval was computed. The results can

be found in Figure 4.8.

16.00

17.00

18.00

19.00

20.00

21.00

22.00

23.00

24.00

25.00

1 2 3 4 5 6 7 8 9 10

RT

T

Run

RTTs in Wireless LAN (Downstream)

16.00

17.00

18.00

19.00

20.00

21.00

22.00

23.00

24.00

25.00

1 2 3 4 5 6 7 8 9 10

RT

T

Run

RTTs in Wireless LAN (Upstream)

Figure 4.8: Round-Trip Times of TCP over Wireless LAN

In downstream direction, the RTT are distributed in a small interval of [ 22 - 23 ] ms. In upstream

direction, the RTTs vary in a greater interval of [ 17 - 24 ms ]. Comparing this values to the RTTs

of 60ms measured in the serial link scenario, the RTTs are lowered, although a WLAN link was

inserted instead of a wired FastEthernet link.

The measurements of the RTTs showed a greater variation in upstream direction than in downstream

direction. Plotting the RTTs of a measruement run five in upstream direction leads to Figure 4.9.

A dropdown of the RTTs after approximately 2.5s can be observed. Further evaluation showed,

that those dropdown are distributed between 1s and 5s. Hence, the average RTT shown in 4.8

depends on the time of the dropdown. To measure the individual delays in downstream direction,

the measurement nodes must be high precision time-synchronized.

60


0

10

20

30

40

50

60

70

80

00:00 00:02 00:04 00:06 00:08 00:10 00:12

RT

T (

ms)

Time

RTTs over WLAN (Single Run Upstream)

Figure 4.9: Single RTT Measurement over WLAN

4.2.3 Influence of Bit Error Rates on TCP Performance

The influence of a high BER in wireless environment is reported to be significant resulting in poor

TCP performance since packet loss is used as an indicator for congestion. Thus, TCP reduces its

sending rate, although the packet was lost due to bit errors.

To measure this influence on TCPs performance and behavior over Wireless LAN, a new experiment

was setup. Since it was not possible to measure the BERs, the BERs were assumed to be higher,

the more the distance is between the mobile node and the access point. Also obstacles like walls

should increase the BERs. An experiment with different locations of the mobile node compared to

the access point was made. In a first scenario, the mobile node was situated in a direct line-of-sight

location in 1 m distance of the access point. The channel conditions are expected to be ideal in this

setting and thus the BER should be near to 0. In a second scenario, the mobile node was placed in

a direct line-of-sight connection 5 m away from the access point. The third position of the mobile

node was chosen to be 5 m distant from the access point with a wall in between. Finally, a fourth

61


position was chosen as a 20 m out-of-sight location. An overview of the different positions can be

found in Figure 4.10.Room 4Room 3Room 2Room 1 Position #1

Position #2

Position #3

Position #4

Legend:

Mobile Host

WLAN Access Point

Figure 4.10: WLAN Location Scenario

The single access point network architecture, shown in Section 3.1.1, was used except that the

transmission power of the access point was lowered from 100mW to 30mW. The lower transmission

power was chosen in order to achieve poorer transmission quality. The signal strength and link

quality as reported by the WLAN card driver in the mobile node was very low in position 4, whereas

on the other 3 positions, the link quality was reported to be good.

The traffic model contained a TCP stream sent over 10s. The experiments were repeated in upstream

and in downstream direction.

The results of the experiments are shown in Figure 4.11.

The graphs show that in the first 3 positions, where the channel quality and signal strength was

reported to be good, the impact on the throughput can almost be neglected. In Position 4, with

bad channel quality reported, the throughput drops heavily to a very low level. Looking at the TCP

traces, recorded at the sender and the receiver, it can be observed that on TCP layer no packet was

dropped and thus no retransmission was triggered. Wireless LAN uses link layer retransmissions to

overcome the problems of bit and packet errors thus preventing any packet loss due to bit errors.

With link layer retransmissions the link layer can be seen as a reliable link with the drawback of

a lowered bandwidth. Therefore, also the IP layer can be assumed to be reliable, if there is no

62


0

100000

200000

300000

400000

500000

600000

700000

800000

00:00 00:02 00:04 00:06 00:08 00:10 00:12

Thr

ough

put (

Byt

es/s

ec)

Time

Influence of Distance and Obstacles in Wireless LAN (Downstream)

Direct Line of Sight ConectionLine of Sight 5mOut-of-Sight 5m

Out-of_sight 20m

0

100000

200000

300000

400000

500000

600000

700000

800000

00:00 00:02 00:04 00:06 00:08 00:10 00:12

Thr

ough

put (

Byt

es/s

ec)

Time

Influence of Distance and Obstacles in Wireless LAN (Upstream)

Direct Line of Sight ConectionLine of Sight 5mOut-of-Sight 5m

Out-of_sight 20m

Figure 4.11: Influence of distances and obstacles on TCPs Performance over Wireless LAN

congestion on one of the links or intermediary systems. So, from TCP’s point of view,if there is

no congestion, the IP layer provides a reliable datagram service with a specific bandwidth, that is

lowered the more bit errors can be observed. The interference between link layer retransmissions

and TCP retransmission scheme is left for future work, since it was not possible to deactivate the

link layer retransmission scheme at the access point in order to make comparable experiments.

Rapidly changing conditions, that can occur when a mobile node moves in a Wireless LAN cell,

are not observed here and also left for future work. If channel conditions change rapidly, link

layer retransmissions may occur with rapidly changing frequency resulting in widely varying packet

delays. It is expected, that TCP may not be able to adjust fast enough to those conditions resulting

in lowered throughput.

4.2.4 Influence of Cross-Traffic on TCP Performance

Single UDP or TCP Connections over Wireless LAN in different scenarios have been observed so far

and the measurements indicate that TCP is performing well under these conditions. The next part

of the evaluation will investigate TCPs performance over the Wireless LAN 802.11b link in presence

of multiple network flows competing for bandwidth.

The single access point scenario was used to and two mobile nodes have been associated to the access

point. The specification of Mobile Node 1 (MN1) can be found in Appendix B.7, of Mobile Node 2

63


(MN2) in Appendix B.8. In upstream direction, both mobile nodes sent data to the server, whereas

in downstream direction, both modile nodes received data from the fixed host. Figure 4.12 shows

the architecture for crosstraffic measurements.

10.10.1.X

Tokyo Delft

Legend:

Aalborg

Fixed Host

Mobile HostDhaka

Router

Mobile Node 1

San Francisco

Toronto

Server

10.10.3.254

TorontoSwitch

WLAN Access Point

8 MBit/s 8 MBit/s


100 MBit/s

Shanghai

100 MBit/s

Mobile Node 2

CrosstrafficConnection

TCP Connection

Figure 4.12: Network model to measure the influence of crosstraffic on TCP’s performance overWireless LAN

In a first scenario, a constant bandwidth UDP stream with at an application layer bandwidth

of 500 kBit/s was established between the fixed host and MN2. After approximately 2 sec, a TCP

connection was established for 10 sec between the fixed host and MN1. The experiment was repeated

for upstream and downstream and the transmission through development of TCP can be observed

in Figure 4.13.

Performing a t-test leads to the result, that the difference between the transmission throughput

of a single TCP connection and Λtransm.,UDP + Λtransm.,TCP in case of a 500 kBit/s UDP stream

lies in a confidence interval of [ 58,6 - 112,4 ] kByte/s ([ 468,8 - 898,4 ] kBit/s).

Repeating the experiments with two UDP connections, with a UDP bandwidth of 3 MBit/s and

with two TCP connections that compete for the available bandwidth, leads to the results shown in

Table 4.8. The table shows the cumulative transmisison throughput of both streams. See Table C.1

to Table C.3 in the Appendix for the detailed results. Using a WLAN adapter card from CISCO led

64


0

100000

200000

300000

400000

500000

600000

700000

00:00 00:02 00:04 00:06 00:08 00:10 00:12

Thr

ough

put (

byte

s/se

c)

Time

TCP Throughput (Downstream)


0

100000

200000

300000

400000

500000

600000

700000

00:00 00:02 00:04 00:06 00:08 00:10 00:12 00:14 00:16

Thr

ough

put (

byte

s/se

c)

Time

TCP Throughput (Upstream)


Figure 4.13: TCP Performance over Wireless LAN in presence of a competing 500 kBit/s UDPstream

to the result, that in a UDP/UDP and a TCP/TCP scenario, almost all traffic generated or received

by the 3COM card was blocked out. An interpretation of this behavior could be, that the adaptor

card from CISCO uses a more aggressive policy to access the channel and send data packets over

the link.

In this section only UDP streams with a constant packet rate have been observed. This model is

not very appropriate for the Internet, where the available bandwidth changes rapidly in short times.

In that case, TCP should adapt to the available bandwidth as fast as possible without overestimating

the bandwidth and therefore loosing some packets. To evaluate the effectiveness of TCPs adaption

mechanism, the following experiment was made.

The network model with two mobile nodes connected over Wireless LAN to an access point from

above (Figure 4.12) was reused. The traffic model consisted of a TCP stream, that was established

between MN1 and the fixed host and a burst UDP stream flowing between the MN2 and the fixed

host. The UDP sender sent packets at a constant packet rate for a specific time (ON-Time), then

backs off for a while (OFF Time) and starts sending packets again, after the OFF-Time expired. The

ON- and OFF-Times were chosen to be distributed exponentially with a mean value of 100 packets

at an application layer bandwidth of 1 MBit/s. The packets contained 1472 bytes of payload. Given

these numbers, the mean ON- and OFF-Time can be computed to be 1.1 s.

Since ON- and OFF-Times are identically distributed the average bandwidth used by the burst UDP

65


Upstream DownstreamΛtransm.,UDP

[ kBytes

]

Λtransm.,TCP

[ kBytes

]

Λtransm.,UDP +Λtransm.,TCP

[ kBytes

]

Λtransm.,UDP

[ kBytes

]

Λtransm.,TCP

[ kBytes

]


[ kBytes

]

Run 1 54,3 489,8 544,2 62,5 655,5 718,0Run 2 61,5 490,9 552,3 62,3 652,7 715,1Run 3 56,9 494,8 551,7 62,5 656,0 718,4Run 4 58,2 476,9 535,2 62,8 662,2 725,0Run 5 55,5 491,2 546,8 62,4 649,5 711,9Run 6 56,3 481,9 538,1 62,5 647,6 710,0Run 7 59,4 496,3 555,8 62,4 652,1 714,5Run 8 59,2 435,7 495,0 62,5 654,7 717,2Run 9 59,3 490,5 549,8 62,4 642,8 705,2Run 10 60,6 430,6 491,2 62,4 663,6 726,0Average 58,1 477,9 536,0 653,7 62,5 716,1Std.Dev 2,3 24,3 23,5 19,8 18,8 6,0

Table 4.7: Transmission throughput of a TCP stream competing with a 500 kBit UDP stream overWireless LAN

UDP/UDP 500 kBit/s UDPCrosstraffic

3 MBit/s UDPCrosstraffic

TCP/TCP

Upstream 659586 564976 570523 447047Downstream 665180 716137 650742 670537

Table 4.8: Cumulative Transmission Throughput of TCP over Wireless LAN with different constantpacket rate UDP stream

stream can be set to half of the bandwidth used in the OFF-Times. Thus, the 1 MBit/s burst UDP

stream has the same long term average rate as the 500 kBit/s constant packet rate UDP stream.

Compared to a 500 kBit UDP stream competing with TCP, a TCp stream competing with a 1 MBit

burst UDP stream gains a higher throughput, which seems counter-intuitive. Since TCP uses an

adaptive method to adjust to the maximum throughput, it takes time to adjust to the new available

bandwidth when the UDP burst sender changes from an ON-period to an OFF-period. When chang-

ing from an OFF-period to an ON-period, it was expected, that TCP encounters packet loss due to

congestion and hence halving its congestion window. No retransmissions have been observed in the

traces, since the receiving window limited the sending rate of TCP instead of the congestion window.

Plotting the results that have been observed so far leads to Figure 4.14. The values used for the

graphs are the sum of the transmission throughputs of both streams.

The graphs show, that the maximum throughput achieved over WLAN, is lower in upstream

66


0

100000

200000

300000

400000

500000

600000

700000

800000

900000

TC

P /

TC

P

3 M

Bit

UD

P /

TC

P

1 M

Bit

Bur

stU

DP

/ T

CP

500

kBit

UD

P /

TC

P

UD

P/U

DP

TC

P

UD

P

Thr

ough

put (

byte

s/se

c)

Cumulative Throughput of TCP and UDP over WLAN in different scenarios

UpstreamDownstream

Figure 4.14: Cumulative Throughput of TCP over Wireless LAN with different constant packet rateUDP streams

direction than in downstream direction in every case. This could be a direct effect of the overloading

problem of the 3COM card.

In downstream direction, it was expected, that the throughput degradation in the UDP/UDP sce-

nario compared to the UDP scenario is negligible, since one access point sends arrives on the wireless

links. Influences due to collision avoidance and exponential back off on link layer should not occur,

since only the access point sends packets over the wireless link. In contrast to the expectation, the

throughput degrades severely. In scenarios combining a TCP connection with a UDP stream, the

throughput was expected to degrade, since the mobile node receiving data over TCP sends ACK

packets. Thus, collisions while accessing the wireless medium resulting in lowered throughput were

expected in downstream. The tendency to lowered throughput should fall with higher bandwidth

UDP streams, since TCP should adopt to a lower throughput resulting in less ACK packets and

thus in less collisions. In contrast to this expectation, two concurrent TCP connections gain the

same throughput compared to the UDP/UDP scenario.

67


In upstream direction, the graph meets the expectations regarding collisions on link layer. A TCP

connection with a concurrent 500 kBit/s UDP stream gains slightly less throughput than a TCP

connection with a 3 MBit UDP stream. Since the overhead added by UDP is less than the overhead

added by TCP, the given result can be expected. Thus, two concurrent TCP connections gain least

throughput. Considering that the access point and two mobile nodes are accessing the wireless link

and two nodes send long data packets of 1514 bytes (including all headers), confirms the observation

of a lowered throughput.

4.2.5 Influence of Handovers on TCP Performance

The last experiments made with Wireless LAN links considered the issue of handovers. The mobil-

ity support network architecture was set up for handover experiments. The mobile node was first

associated to the access point in the home network. Approximately 5s after establishing the data

flows, the mobile node was handed over to the foreign network by changing the SSID. Thus, the

handover was performed mobile node initiated.

Two simultaneous flows were established before the mobile node was handed over. A low bandwidth

UDP flow was used as probing flow to measure the time of reestablished network layer connectivity.

UDP packets with a payload size of 50 bytes were sent at an application layer bandwidth of 50

kbyte/s. Hence, nominally one UDP packet was sent every 1ms, so the precision of measuring net-

work layer connectivity can be assumed to 1ms. A TCP connection was established simultaneously

to the UDP flow.

The instantaneous throughput, that shows graphically every detected packet, is shown in Figure

4.15.

The Figure shows, that TCP restarts transmitting data after approximately 30s despite network

layer connectivity is recovered after approximately 15s. To prove this behavior, the measurement

was repeated 10 times. The results of 10 runs can be found in Table 4.9. The handover delays have

been calculated as presented in Section 3.3.5.

The results raise three questions:

• The handover delays are rather long. What is the main influence that leads to this result?

68


0

200000

400000

600000

800000

1000000

1200000

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35 00:40 00:45

Thr

ough

put (

byte

s/se

c)

Time

TCP/UDP Throughput in handover situation (Receiver)

UDP probing flowTCP Flow

Figure 4.15: Instantaneous Transmission in a WLAN handover situation

• TCP almost doubles the handover delays. What mechanism causes this effect?

• Run 5 did not suffer from long TCP delays as the others. What has changed compared to the

other runs?

To answer the first question, the message flow while performing a handover was investigated.

The evaluation showed that assigning a new IP address to the mobile node via DHCP [20] causes

network layer disconnection delays of over 11s. The problem is visualized in Figure 4.16.

After the mobile node is handed over and link layer connectivity is reestablished, the mobile

nodes broadcasts a DHCP-Request to find a the new DHCP server and to ask for a new IP address.

The IP address, that was assigned to the mobile node before the handover was performed, is inserted

as source address into the broadcast packet. The new DHCP server does not respond to this re-

quest, since the node that is asking for a new IP address does not belong to its subnet. After 1s, the

DHCP client on the mobile node times out and requests to release its IP address, again with its old

IP address inserted as source IP address. Since the DHCP server does not respond to this request,

69

4.3 TCP over Bluetooth

Handover Delay ∆network [s] TCP Delay ∆TCP [s] TCP Gap ∆network −∆TCP [s]Run 1 15.91 29,046 13,13Run 2 14,65 29,16 14,51Run 3 15,12 29,22 14,10Run 4 15,68 29,22 13,54Run 5 15,02 16,39 1,38Run 6 15,65 29,06 13,41Run 7 16,19 29,22 13,03Run 8 14,90 29,05 14,15Run 9 14,92 29,04 14,12Run 10 14,88 29,05 14,17Mean 15,29 27,85 12,55

Std.Dev 0,52 4,02 3,9695% - Conf. 0,010 0,080 0,078

Table 4.9: Handover delays of TCP in a WLAN handover scenario

the DHCP client on the mobile node times out again after 10s. At this point, the normal method

of obtaining a new IP address is performed and the mobile node achieves network connectivity in

short time. The remaining 5s are caused by Mobile IP and its message signaling.

To answer the second question, the packet traces at the sender side were analyzed. Since the sender

does not receive any ACK packet for the last few packets, the retransmission timer is fired and a

packet is retransmitted. For Run 3, the measured retransmission timeout is 230 ms. Due to the

handover delay, the sender does not receive an ACK for 15s, the retransmission timer is doubled

every failed retransmission (x times within 15s) until the value for the retransmission timer reaches

14,72s and an ACK is received form the mobile node. Summing up the individual retransmission

timeout values leads to a value of 29,21s, which corresponds to the value measured as TCP Delay.

Analyzing Run 5 leads to the result, that the initial retransmission timeout value was computed

to 260ms. Thus, the retransmission timeout needed to double only until it reached 8320ms, since

after that amount of time an accumulated time of 16,38s had expired. From the measurement, a

handover delay of 15s can be observed. So, the retransmission timer did not need to double again

to retransmit a new data packet.


In a second series of experiments, the influence of TCP over a Bluetooth wireless link was evaluated.

Since Bluetooth encounters different link characteristics than WLAN due to different access and

70


Mobile Node DHCP Server

DHCP Request, IP Source = 10.10.1.123

DHCP Offer, IP Source = 10.10.3.1

Layer 2 reconnect

Layer 2 disonnect

IP: 10.10.1.123/24 IP: 10.10.1.1/24

IP: 10.10.3.1/24

Subnet change

dropDHCP Release, IP Source = 10.10.1.123 drop

1s timeout

DHCP Discover, IP Source = 0.0.0.0

10s timeout

DHCP Request, IP Source = 0.0.0.0

DHCP ACK, IP Source = 10.10.3.1

IP: 10.10.3.123/24

Figure 4.16: A Problem in the DHCP-Client of the mobile nodes causes long network layer discon-nection

data transfer techniques, the influences of this characteristics have been evaluated.

4.3.1 Performance of a Bluetooth link in adhoc scenario

In a first scenario, the maximum achievable throughput that is achievable over a Bluetooth link was

measured using a constant packet rate UDP stream in an adhoc scenario. Two Mobile nodes were

equipped with a Belkin Class 2 USB Bluetooth adapter. A Pentium4 2.66 GHz laptop with 512 MB

RAM running WindowsXP (referred as MN1) acted as master device in the piconet. A Pentium

266MHz laptop with 32MB RAM running WindowsXP (referred as MN2) acted as slave device. A

wireless network connection was established using the Personal Area Network (PAN) application

profile. The mobile nodes were situated in a distance of 1m. The network model is shown in Figure

4.17

Throughput measurements have been done for UDP and TCP in upstream and downstream

71


Mobile Node 1(Master)

Mobile Node 2(Slave)

Figure 4.17: Network model of Bluetooth adhoc scenario

direction2 and are described in the following section.

UDP throughput of a Bluetooth link in adhoc scenario

The first experiment using a constant packet rate UDP stream was applied to analyze the maximum

achievable throughput.

A constant packet rate UDP stream was established between both mobile nodes to measure maximum

throughput. UDP packets with a payload size of 1472 bytes per packet were sent at an application

layer bandwidth of 700 kBit/s. Taking the different headers of the different layers into account, the

network layer bandwidth can be computed to 720 kBit/s. The transmission throughput developments

of every single run is graphically shown in Figure 4.18.

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

00:00 00:02 00:04 00:06 00:08 00:10 00:12

Thr

ough

put (

byte

s/se

c)

Time

UDP Throughput in Bluetooth AdHoc Scenario (Downstream)


0

10000

20000

30000

40000

50000

60000

70000

80000

90000

00:00 00:02 00:04 00:06 00:08 00:10 00:12

Thr

ough

put (

byte

s/se

c)

Time

UDP Throughput in Bluetooth AdHoc Scenario (Upstream)


Figure 4.18: UDP performance over a Bluetooth link in adhoc scenario

Computing the average transmission throughput after 10s over the 10 runs leads to Table 4.10.

Performing a t-test on both data series with a significance level of 5% leads to the result, that

2Upstream and downstream direction are seen from the slave device’s point of view

72


Downstream [kBytes

] Upstream [ kBytes

]

Run 1 80,5 80,1Run 2 80,4 79,9Run 3 69,3 78,4Run 4 80,8 79,9Run 5 80,6 78,2Run 6 80,9 80,5Run 7 80,4 81,0Run 8 80,2 80,9Run 9 81,0 80,3Run 10 80,7 80,6Average 80,63 80,0Std.Dev. 0,243 0,955

Table 4.10: Average Transmission Throughput of UDP after 10s in a Bluetooth Adhoc Scenario

the UDP transmission throughput after 10s is not significant different in upstream and downstream

direction. Since the effect that caused the throughput degradation in Run 3 in downstream direction

was observed more frequently in a scenario using an access point, an explanation for this effect will

be given there.

TCP throughput over a Bluetooth link

The experiment from above was repeated with a TCP stream instead of a UDP stream to measure

the performance of TCP over a single Bluetooth hop. A sender and receiver buffer of 85 kByte was

used for the TCP connection. The measured transmission throughput developments over time can

be found in Figure 4.19.

The graphs show that in upstream direction a maximum transmission throughput of 75 kbyte/s

is achieved after 10s in most cases. Two cases encounter the throughput dropdown to a lower level,

resulting in reduced transmission throughput. In downstream direction, only the low throughput

level is achieved by TCP. A conspicuous sawtooth pattern can be observed on the downstream

graphs. Analyzing the packet flow on receiver side show regular idle times of the connection. These

idle times are caused by ACK packets, that encounter long RTTs. Since the receiver advertised a

RWND of 17520 bytes on every arrived data packet, the sending rate of the sender was limited by

the RWND, after the CWND hit RWND. Thus, a new packet is only injected into the network upon

a reception of an ACK. Hence, an ACK with a long delay causes a delayed injected data packet and3Run 3 was left out, when calculating the average and standard deviation

73


0

10000

20000

30000

40000

50000

60000

70000

80000

90000

00:00 00:02 00:04 00:06 00:08 00:10 00:12

Thr

ough

put (

byte

s/se

c)

Time

TCP Throughput in Bluetooth AdHoc Scenario (Downstream)


0

10000

20000

30000

40000

50000

60000

70000

80000

90000

00:00 00:02 00:04 00:06 00:08 00:10 00:12

Thr

ough

put (

byte

s/se

c)

Time

TCP Throughput in Bluetooth AdHoc Scenario (Upstream)


Figure 4.19: TCP Performance over a Bluetooth link in Adhoc Scenario

thus a lowered throughput. The characteristics of the RTTs over Bluetooth are discussed next.

RTTs over a Bluetooth link

Using the measurements from above, the RTTs have been calculated. The RTTs over time of one

single run in downstream and upstream direction are shown in Figure 4.20.

0

100

200

300

400

500

600

00:00 00:02 00:04 00:06 00:08 00:10 00:12

RT

T (

ms)

Time

RTTs over Bluetooth in Adhoc Scenario (Single Run, Downstream)

0

100

200

300

400

500

600

00:00 00:02 00:04 00:06 00:08 00:10 00:12

RT

T (

ms)

Time

RTTs over Bluetooth in AdHoc Scenario (Single Run, Upstream)

Figure 4.20: Single RTT measurement over Bluetooth in adhoc scenario

The upstream RTT graph shows in the beginning an increase of the RTT until it reaches a

value of 200ms after almost 1s. After the increase, a relatively constant value of 200ms can be

observed. Additional peaks in equidistant intervals are suspicious. In downstream direction, an

74


initial first peak, that is caused by a delayed first data packet, is visible. After this first peak, the

RTT increases until it reaches 200 ms. After the increase, a baseline of 200ms with 2 additional

peaks are visible in the time interval [ 1.5s - 4s ]. The RTT increases again until it reaches 300 ms.

In the second increase phase, an additional peak can be observed. Until the connection is terminated

a RTT baseline of 300ms with additional peaks are visible.

Since no possibility was given to analyze the dynamics of the Bluetooth link and its baseband, a

proven explanation for those behavior cannot be given. It is assumed that phases of linear increase of

the RTT are the result of buffering on baseband level. Peaks could be an indicator of Bluetooths flow

control scheme at link layer. If the Bluetooth node buffers ACKs before sending in low bandwidth

direction, buffering adds time to the RTT and thus a high RTT would be visible. Since ACKs are

sent bundled, the following ACKs would lower the RTT and a falling edge of the peak would be

visible. On the other hand, sending ACKs in the low bandwidth direction will block data packets

from being transmitted resulting in a raising edge of the peak.

Calculation of the mean RTT and its confidence interval in upstream and downstream direction

leads to Figure 4.21.

150.00

200.00

250.00

300.00

350.00

400.00

450.00

1 2 3 4 5 6 7 8 9 10

RT

T

Run

RTTs over Bluetooth using adhoc scenario (Downstream)

150.00

200.00

250.00

300.00

350.00

400.00

450.00

1 2 3 4 5 6 7 8 9 10

RT

T

Run

RTTs over Bluetooth using adhoc scenario (Upstream)

Figure 4.21: TCP performance over a Bluetooth link in adhoc scenario

4.3.2 Throughput of a Bluetooth link using an access point

The single access point network architecture was changed to support Bluetooth. The WLAN access

point was replaced by a BLIP Bluetooth access point. The Bluetooth piconet was formed with the

75


access point as master and the mobile node as slave device. The distance between the mobile node

and the access point was measured to 1m. To support sending and receiving Ethernet packets over

Bluetooth, the PAN application profile was used. The mobile node did not move from its location

nor did any mobile node initiated handover take place.

UDP Throughput over a Bluetooth link using an access point

In the first experiment, a constant packet rate UDP stream was sent in downstream and in upstream

direction for 30s. The UDP payload size was chosen to 1472 bytes at an application layer bandwidth

of 700 kBit/s. The result of one single run in downstream direction is shown in Figure 4.22.

0

20000

40000

60000

80000

100000

120000

140000

160000

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35

Thr

ough

put (

byte

/s)

Time

UDP Throughput over time (Downstream)


Transmission Throughput

Figure 4.22: Single UDP Performance over Bluetooth Run using an access point

It can be observed that in the first 15s the throughput is almost constantly at 75 kbyte/s and then

drops to a lower level of 60 kbyte/s after approximately 15s. In order to measure the dynamics of the

throughput dropdown, the measurements have been repeated 10 times in upstream and downstream

direction. The results are graphically shown in Figure 4.23.

76


0

10000

20000

30000

40000

50000

60000

70000

80000

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35

Thr

ough

put (

byte

s/se

c)

time

UDP Transmission Throughput (Downstream)


0

10000

20000

30000

40000

50000

60000

70000

80000

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35

Thr

ough

put (

byte

s/se

c)

Time

UDP Throughput over Bluetoth (Upstream)


Figure 4.23: UDP Transmission Throughput over Bluetooth using an access point

It is shown, that in downstream direction the time of the throughput dropdown is distributed in

an interval of [3s - 30s]. In upstream direction, some TCP connections start to achieve a transmission

throughput of 60 kByte/s, but drop down to 50 kByte/s. Other TCP connections send only at a

transmission throughput of 50 kByte/s.

Two possible reasons can be given here:

• Additional traffic in low bandwidth direction

• Interference

To achieve maximum bandwidth in an unidirectional data flow, Bluetooth will adjust its wireless

link to a maximum asymmetry providing maximum bandwidth in the data flow direction while low-

ering the provided bandwidth in the reverse direction to a minimum. If packets are queued to send

in the low bandwidth direction, Bluetooth adjusts the asymmetry to more symmetry to send those

packets. This behavior ensures fairness between flows competing for bandwidth in downstream and

upstream direction. To realize this behavior in Bluetooth, the slave can send longer packets in low

bandwidth direction. Instead of sending 1-slot packets, the node would send 3-slot or even 5-slot

packets to transfer the queued packets. Bluetooth also defines support for basic flow control over a

Bluetooth wireless link. A node can transmit a flow control flag, that advises the communication

partner to stop sending further data packets until the flow control flag is deleted. Both options are

defined in [46], but each node can implement its own packet scheduling and flow control algorithms.

77


Since the probability of throughput dropdown have been observed to be higher in the access point

scenario compared to the adhoc scenario, this could be an indication for the effect described above,

since more background traffic is generated by the routers. In contrast, the appearance of background

traffic could not be matched timely to the throughput dropdown.

Interference of the wireless link can cause dropdown of the maximum achievable throughput. Blue-

tooth introduces an adaptive scheme, that chooses packet types and thus the level of error correction

and link layer retransmission according to the observed channel quality. This scheme is termed

”channel quality driven data rate” in Bluetooth. Thus, the overhead, that is introduced by error

correction codes, and potential retransmission lower the maximum achievable throughput. Changed

interference could cause the dropdown effect.

The algorithm for packet type choice and packet scheduling are usually implemented in hardware

into the Bluetooth device, so that the behavior on the baseband can not be measured and analyzed.

A detailed analysis of these effects can hence not be given here.

TCP Throughput over a Bluetooth link using an access point

The network architecture was reused to measure TCPs behavior over a Bluetooth access point. A

TCP connection was setup from the server to the mobile node. Bulk data was transferred over a

period of 30s. 10 measurements of the data transfer were made for upstream as well as downstream

direction. The results are shown in Figure 4.24.

0

10000

20000

30000

40000

50000

60000

70000

80000

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35

Thr

ough

put (

byte

s/se

c)

Time

TCP Throughput over Bluetooth (Downstream)


0

10000

20000

30000

40000

50000

60000

70000

80000

00:00 00:05 00:10 00:15 00:20 00:25 00:30 00:35

Thr

ough

put (

byte

s/se

c)

Time

TCP Throughput over Bluetooth (Upstream)

Run 1run 10Run 2Run 3Run 4Run 5Run 6Run 7Run 8Run 9

Figure 4.24: TCP Transmission Throughput over Bluetooth using an access point

78


The results show, that in downstream direction, some TCP connections start to approximate

to the high throughput level, but falls down to the low throughput level in short time. The other

TCP connections do not even start to reach the high throughput level and converge to the low level

directly. In upstream direction, no throughput drop is encountered and all runs show relatively

constant results. A conspicuous break after approximately 1s is visible in the upstream graphs. An

analysis of the packet flows showed that in TCPs slow-start phase packet loss is encountered due to

a high initial value of ssthresh. TCP reacts on packet loss in slow-start phase with retransmitting

the lost packets, halves ssthresh and restarts slow-start by setting the CWND to 1. Thus the packet

rate is set to 1 packet per RTT and doubled every RTT. This leads to low instantaneous throughput

and a drop in transmission throughput.

TCP RTTs over a Bluetooth link using an access point

The RTTs of Bluetooth observed using an access point showed similar behavior compared to the

adhoc scenario. The average values and its confidence intervals are visualized in Figure 4.25.

200.00

220.00

240.00

260.00

280.00

300.00

320.00

340.00

1 2 3 4 5 6 7 8 9 10

RT

T

Run

TCP RTTs over Bluetooth using an acces point (Downstream)

200.00

220.00

240.00

260.00

280.00

300.00

320.00

340.00

1 2 3 4 5 6 7 8 9 10

RT

T

Run

TCP RTTs over Bluetooth using an access point (Upstream)

Figure 4.25: TCP RTTs over a Bluetooth link using an access point

The RTTs measured using an access point follow the consideration and results about additional

network traffic and interference. A low throughput value and throughput drops caused by network

traffic or interference leads to a high RTT and vice versa.

79

4.4 Conclusions

4.4 Conclusions

The chapter aimed to evaluate the performance of TCP in the considered scenarios using the given

performance metrics.

An evaluation of the backbone showed that the serial links provided sufficient bandwidth not to limit

the bandwidth of Wirless LAN 802.11b or Bluetooth. The influences of Ethereal and the operating

system on the measuremnts have also been presented.

The performance of TCP over WLAN and the influence of BERs, crosstraffic and handover situations

have been evaluated. The evaluation showed the following results:

• Single TCP connection: A single TCP connection in downstream direction reduced the

throughput about 15% compared to UDP. In upstream direction, influences of the WLAN

adaptor potentially caused UDP throughput dropdowns, when the card is overloaded.

• Influence of BERs: The influence of BERs was measured usign different distances betrween

the access point and the mobile node. The evaluation showed, that with higher expected

BERs, the throughput drops to a lower level, but does not trigger retransmission due to link

layer retransmissions. Hence, link layer retransmissions are an effective method to hide packet

losses on link layer to TCP.

• Influence of crosstraffic: Different concurrent crosstraffic has been applied while sending

data over a TCP connection. The evaluation showed, that TCP performs quite efficient in

downstream direction in presence of competing streams. In upstream direction, influences of

the WLAN adapter card might cause throughput degradation in case of overloading the card.

• Influence of handovers: The influence of handover events on the performance on TCP has

been evaluated. The evaluation showed, that TCP can potentially double the network handover

delay. It has also been investigated, that a problem with the IP address assignement via DHCP

adds 10s to the network layer handover delay. A proxy might improve the performance of TCP

in handover situations.

The performance of TCP over a Bluetooth link was investigated in an adhoc scenario and an

access point scenario. The evaluation showed the following results:

80

4.4 Conclusions

• Adhoc scenario: The evaluation showed, that a throughput of approximately 80 kByte/s

can be gained with UDP and a TCP throughput of around 75 kByte/s in upstream direction.

In downstream direction, a lower throughput has been observed, since the average RTT was

higher compared to the upstream case and the CWND hit the RWND before running into

congestion.

• Access point scenario: In an access point scenario, throughput dropdowns have been ob-

served when sending UDP and TCP segments. These dropdowns could be caused by either

interference or additional traffic in low bandwith direction.

81

4.4 Conclusions

82

Chapter 5

Implementation of the TCP Proxy

An integration of a TCP Proxy into a wireless supporting network covers considerations about

the location of a proxy in the logical path from the sender to the receiver, the actual network

implementation of TCP proxy into the network as well as the software design.

5.1 Proxy Terminology

The concept of a proxy is well-known and wide-spreaded in the Internet. Mostly proxies are used to

cache data that is often needed to reduce response times for requests. For example, HTTP-Proxies

are used in larger networks to cache websites on a local permanent memory. A client is sending his

request not directly to the host containing the website, but to the HTTP-proxy. The HTTP-proxy

looks up the website on his local memory and delivers the page to the client in case the proxy had

cached the page before. In the other case, the proxy forwards the request to the server, stores the

reply of the server in his own memory and forwards it to the client. Performance improvements are

gained due to the shorter path from the client to the proxy, but depend on the size of the memory

and the strategy of keeping the cached websites up to date.

A proxy need not necessarily only enhance the performance, it can also enhance security. A proxy

might filter certain requests in order to protect the internal network. Those types of proxies are

thus combined with a firewall.

There are many different types of proxies [8] that are intended to enhance performance. Performance

enhancement does not necessarily mean to enhance only throughput. For example, M-TCP tries to

keep up the TCP connection over a wireless link while a handover is in progress. Proxies can be

83

5.2 The Split TCP Approach

described and categorized in different classes:

• Layer: Application Proxies like an HTTP-Proxy or a Mail Transfer Agent (MTA) are based on

the application layer and try to improve performance and reliability. Transport Layer Proxies

are mainly used to improve throughput and round trip time (RTT) of data packets send over

an IP network. They mainly do modifications on packet sequences and acknowledgements.

They are not aware of the application protocol and its payload content transported in their

packets.

• Distribution: Integrated proxies consist of one node, where the performance improvements

are applied. Distributed proxies consist of two or more nodes enhancing the performance. For

example, distributed proxies could be used every time a wireless link meets a wired link to

overcome the performance problems of the different medium types.

• Symmetry: Symmetric proxies behave the same way on both sides, to the client and to the

server. Asymmetric proxies will behave different to both sides. For example, a proxy between

a wireless network and a wired network would typically be asymmetrical, an HTTP-Proxy on

the other side would be symmetrical. Symmetry is independent from the type of distribution.

An asymmetric proxy could be integrated, for example, when a wireless link meets a wired

link, but could also be distributed, with different implementations on both ends.

• Transparency: The proxy may be transparent on network layer, on transport layer, on

application layer or even on user level.

5.2 The Split TCP Approach

The split TCP approach is based on the consideration, that two different TCP connection can be

optimized for their performance individually for two different kind of links. Figure 5.1 shows the

approach from a protocol stack point of view.

A TCP connection that was established between a fixed host and the mobile node, would be

intercepted and broke int two parts by the TCP proxy. An application on the fixed host, that uses

a TCP connection to communicate with an application on the mobile node, would not notice any

changes to the functionality of the underlying TCP layer. A Split TCP daemon running on top of

84

5.3 Security

Application

Fixed Host Mobile Node

Split TCP-Daemon

TCP

IP

LL / PHY

Application

TCP

IP

LL / PHY

TCP

IP

LL / PHY

TCP

IP

LL / PHY

TCP Proxy

Figure 5.1: The Split TCP Approach

the TCP layer in the proxy would watch for incoming data on the one TCP connection and forward

it to the associated TCP connection. The strength of this approach is the ability to optimize the

TCP implementation over the wireless link, while the TCP connection to the fixed host can remain

a standard implementation.

For the further thesis, it is assumed that the communication partner that initiates the TCP connec-

tion, is also the sender of data in the scenario. The TCP connection from the sender and initiator

to the TCP Proxy will be termed as ”left connection”, whereas the TCP connection from the TCP

Proxy to the receiver of data will be call ”right connection”.

5.3 Security

When using a proxy as an intermediary network node to enhance the performance of TCP, some

implications and limitations to security have to be considered.

Security can be applied on different layers. Applications using security on application layer can

benefit from the use of a TCP proxy, since the encrypted payload of TCP is not modified. Security

applied on transport layer, like Transport Layer Security (TLS, [19]) can be used in conjunction with

a TCP Proxy. Instead, network layer security like IPSec [28] cannot be used with an intercepting

proxy, since TCP packets are encrypted and thus not available for a proxy. In case the proxy

is non-transparent, IPSec can be used between the proxy and the mobile node and an additional

IPSec connection between the correspondent node and the proxy. In most cases, this behavior is

85

5.4 Proxy Location

not desired as the end system cannot trust the proxy in general. Additionally, if different levels of

security are applied from the proxy to the end system, the end system with the higher security level

might not be aware of the lower security level on the other end system. This can lead to wrong

security implications. The proxy could prevent such a scenario by ensuring the same security levels

on both sides.

5.4 Proxy Location

Before integrating the proxy as a node into an existing network and implementing the software on

the node, some considerations about the location of the proxy in the network and its implications

will be presented.

5.4.1 Meta-Model

As a general meta model, the network can be divided into two parts. One part of the network

enables the mobile node to be wirelessly connected to the rest of the network. This part is called

”wireless supporting network”, while the counterpart of the network is termed ”wired network”.

By that definition, the border between the wireless supporting network and the wired network is

not defined clearly, since the wireless supporting network could on the one hand consist out of one

access point, on the other side, multiple access points or base stations could be connected via a

wired backbone to the wired network. This definition gets more precise by introducing the TCP

proxy into the network. The TCP simply resides between the wireless supporting network and the

wired counterpart. An overview of the meta-model is given in Figure 5.2.

TCP Proxy CorrespondantHost

Wireless supporting

network

Wired network

Mobile Node

Figure 5.2: Meta-Model for network integration of a TCP proxy

Note, that the part of the network, that provides wireless access need not necessarily provide

86

5.4 Proxy Location

mobility in that network.

5.4.2 TCP proxy with handover support in intrasubnet handovers

Dimensioning the size of the wireless supporting network to optimize the performance is the main

issue and covers a lot of aspects. In TCPs case it would be desirable to implement the TCP proxy as

close as possible to the wireless access point or integrate it directly into the access point, so that the

TCP connection over the wired part of the network to the correspondent host is as long as possible.

The standard TCP implementations are well known to perform good under such conditions. On

the other side, the influence of the wireless link on the wireless TCP connection is maximized and

can be optimized best. Figure 5.3 shows one possible scenario with TCP proxies implemented as

close to the wireless access points as possible. In a quasi-static scenario, where the mobile node

TCP Proxy

Wired network

CorrespondantHost

Mobile Node

Handover

TCP Proxy

TCP Proxy

TCP Proxy

Figure 5.3: Model for Network Implementation of a TCP proxy supporting proxy Handover inintrasubnet Handover Scenarios of a Mobile Node

is always connected to one access point during the lifetime of the TCP connection, this scenarios is

expected to perform best. When mobility comes into play and the mobile node is handed over from

one access point to another access point, the associated proxy will be changed. Thus, the connection

state information maintained at the proxy has to be transferred to the new proxy1. This approach

would follow the model of a distributed proxy. The drawback of this location design - besides the

1It is assumed that the TCP proxy maintains a hardstate. In this thesis hardstate is defined, that a hard-stateTCP proxy makes a TCP connection unable to persist, if the state of the TCP proxy is lost or the TCP proxy stopsits service. A full definition of the terms hard- and soft-state can be found in [16]

87

5.4 Proxy Location

hardware effort - would be frequent proxy handovers that can lead to enormous traffic if the number

of users and access points is very high.

5.4.3 TCP proxy with handover support in intersubnet handovers

The number of proxy handovers could be reduced by grouping all access points, that belong to the

same subnetwork and assigning them to the same TCP proxy. Figure 5.4 shows a possible scenario

with access points in the same subnetwork assigned to one TCP proxy.

TCP Proxy

Wired network

CorrespondantHost

Mobile Node

Handover

TCP Proxy

Handover

Figure 5.4: Model for Network Implementation of a TCP proxy supporting proxy Handover inintersubnet Handover Scenarios of a Mobile Node

This approach would reduce the number of handovers, since handovers in the same subnet do not

need to change the TCP proxy. In cellular networks, access points in the same subnet cover normally

neighboring cells, so that a mobile node would be connected to the same TCP proxy with some larger

geographicall area. Drawbacks of this approach are that the TCP proxy has to be handed over, if the

mobile node moves to another subnet, and that the TCP proxy is further away from the access point.

5.4.4 TCP proxy without proxy handover

In order to remove the necessity of TCP proxy handovers, when the mobile node hands over to a

new access point, support for inter-subnet handover of the mobile node has to be provided by the

TCP proxy. Thus, all access points, providing wireless access to a network, have to be assigned to

the TCP proxy. A model for this scenario is shown in Figure 5.5.

88

5.4 Proxy Location

TCP Proxy

Wired network

CorrespondantHost

Mobile Node

Handover

Figure 5.5: Model for Network Implementation of a TCP proxy without proxy Handover in HandoverScenarios of a Mobile Node

The TCP proxy would reside at a single point of attachment of the wireless supporting network

to the wired network. A mobile node would always be connected to this single TCP proxy, regardless

if a intrasubnet or intersubnet handover is performed. Figure 5.5 shows the model of a single TCP

proxy supporting a wireless supporting network. Drawbacks concern the again increased distance of

the TCP proxy to the wireless link and scalability. Scalability could be a problem for a TCP proxy

in case many users are attached to the wireless supporting network: the TCP proxy has to maintain

every TCP connection, that is established over the wireless supporting network, which can easily

lead to memory shortage or increased processing time of the TCP proxy.

5.4.5 TCP proxy with Mobile IP

Mobile IP [38] introduces two entities into the logical path between the mobile node and the cor-

respondent host to support mobility: A Home Agent and a Foreign Agent. In case, the mobile

node is co-located in the visiting network, the data would flow from the correspondent node to the

Home Agent, which passes the packets in an IP Tunnel to the Foreign Agent, which forwards the

decapsulated IP packets to the mobile node. An overview of Mobile IP data flow can be found in

Figure 5.6

A TCP proxy could principally be inserted on any of the subpaths between the mobile node and the

correspondent node, resulting in different implications and drawbacks.

In order to locate the TCP proxy close to the wireless link, it could be inserted between the Foreign

89

5.4 Proxy Location

CorrespondentHost

Mobile Node

IP network

Home AgentForeignAgent

IP Tunnel

Destination Routing Destination Routing

Visited Network Home Network

Figure 5.6: Model of Mobile IP Data-Flow

Agent and the mobile node. The TCP proxy would eavesdrop the TCP flow as well as the Mobile IP

requests and replies between the Foreign Agent and mobile node and thus get knowledge of mobile

nodes, that register in the new network. Once the mobile node is registered, its Layer 3 connectivity

is restored and the TCP connection could start sending data immediately instead of waiting for a

retransmission timeout. Mobile nodes, that left the network can be identified by expired registration

lifetimes of mobile IP. When a mobile node is handed over to the new subnet and the new TCP

proxy gets knowledge of it, the TCP proxy has to hand over the TCP connection from the old TCP

proxy to the new one. Since the mobile IP messages contain no information about the previous

location of the mobile node, some information between the Home Agent and the Foreign Agent

have to exchanged, to overcome this problem. Once the TCP Connection is handed over, it could

immediately proceed transmitting data.

Depending on the exact location of TCP proxy between the Foreign Agent and the mobile node,

frequent handovers of the TCP proxy implying the state transfer from the old to the new TCP proxy

would be necessary (assuming that the TCP proxy maintains a hard state). As a lower bound for

the number of handovers it has to be considered, that at least for every intersubnet handover the

state of the proxy has to be transferred.

Inserting the TCP proxy between the Home Agent and the Foreign Agent would lead to some other

implications on the functionality of the TCP proxy. The proxy would then need to intercept the

IP Tunnel that is setup between the Foreign Agent and the Home Agent as well as the Mobile IP

90

5.5 Network Implementation

requests and replies. Another drawback of this approach is, that Mobile IP does not specify, that

the communication from the mobile node to the fixed host has to pass the Home Agent. Thus,

packets may not pass the tunnel from the Home Agent to the Foreign Agent and hence the TCP

proxy could not eavesdrop on the packets. The TCP proxy could thus not provide its service.

Inserting the TCP proxy between the Home Agent and the fixed host would eliminate the need for

decoding the IP tunnel, but the distance between the TCP proxy and the wireless link would be

decreased further.

In this work, the TCP proxy was located in the same subnet as the Home Agent intercepting the TCP

connection between the correspondent node and the Home Agent. The intercepting was achieved

using policy-based routing. Mobile IP registration messages have also been intercepted using policy

based routing. To ensure, that the TCP packets in the path from the mobile node to the correspon-

dent node are also intercepted by the TCP proxy, the Home Agent and Foreign Agent have been set

up to use reverse tunneling.

5.4.6 Conclusion about the Proxy Location

Concluding the considerations about the location of the Proxy in a network, a trade-off between a

highly distributed TCP Proxy implying a high number of handovers resulting in additional network

traffic with few hardware efforts on a single TCP Proxy and a integrated TCP Proxy with few

or no handovers, but eventually high hardware requirements for the TCP Proxy has to be found,

individually for every network.

The routing approach was chosen in the thesis.


Depending on different demands to the proxy and the underlying network structure, several solutions

to integrate the TCP Proxy into the network are possible. The solutions can be divided into two

categories, depending on the transparency to the end-user.

Non-transparent proxies are known to the end-user. The end-user has to specify the IP address of

the TCP proxy in his mobile node in order to take advantage of the use of the TCP proxy. The TCP

packets are sent directly to the TCP proxy using the standard routing algorithms. Two approaches

91


for non-transparent proxy implementations will be introduced:

• Header option approach

• IP Tunneling approach

Intercepting and thus transparent proxies are hidden to the end-user. The end-user does not

need to specify any use of the proxy and takes automatically advantage of the functionality of the

TCP proxy. The proxy itself has to find a solution to get into the logical packet path between the

communicating nodes. Three approaches implementing a transparent proxy will be presented in the

following sections:

• In Path approach

• ARP approach

• Routing approach

5.5.1 Header Option Approach

A first approach to integrate a non-transparent TCP proxy is derived from the architecture of a

HTTP proxy. In an HTTP proxy, the request for an object is not send directly to the destination

host, but the HTTP request is send to the HTTP proxy. The HTTP requests itself contains the

requested HTTP object and the IP address of the destination host. The HTTP proxy forwards the

request to the destination host and sends the reply back to the originating host.

Based on this concept, a TCP connection has to be established to the TCP proxy carrying the

information about the destined host. The proxy itself would establish a standard TCP connection

to the destined host using the information carried in the header. The information of the destined IP

address could be carried in the IP or TCP header. A mobile node, that wants to use the TCP-Proxy,

has to specify the IP-Address of the proxy, like it has to be done for an HTTP-Proxy.

So, the source host would be able to send the IP packet with the piggybacked destination address

directly to the proxy. The proxy would extract the destination address and send the packet to the

right destination host. Figure 5.7 shows a typical data flow with the IP-Header Option implemented.

92


Mobile Node (MN) Proxy

Correspondent Node (CN)

IP Source Proxy

IP Dest: CN

TCP

data

IP Source CN

IP Dest: Proxy

TCP

data

IP Source MN

IP Dest Proxy

IP Option: Dest CN

TCP

data

IP Source Proxy

IP Dest MN

TCP

data

Figure 5.7: IP Header Modification model

Some problems arise with this approach. First, the IP or TCP layer has to be changed and the

new header option has to be implemented. If a host would not support this IP option, it would not

be possible to use the TCP proxy. Secondly, the TCP proxy has to be specified in the IP layer of the

source host. As every TCP/IP-packet has to carry the IP-Address of the destination host, at least

6 bytes (1 byte for the option type, 1 byte for the option length and 4 byte for the destination IP

address) are needed. Given a fixed maximum frame length on network layer, the maximum segment

size would be reduced by 6 bytes. In standard Ethernet, this would mean a reduction of the MSS

from 1460 bytes to 1454 bytes. Given the assumptions, that

• the network link provides constant bandwidth B and is fully utilized

• the maximum frame length (FL) is constant bytes

• every data packet transports maximum amount of data

• every second data packet is acknowledged

• TCP is in a constant state and sending as much data as possible

the application layer throughput (ALT ) can be computed by:

ALT =2 ∗MSS

2 ∗ FL + AL∗B (5.1)

93


where AL is the length of the acknowledgement. The accumulated header length of IP and TCP

(without options) would be 40 bytes, so that a data packet can carry 1460 bytes and an ACK would

be 40 bytes long. Given this numbers the throughput would be ALTst = 2∗1460bytes2∗1500bytes+40bytes ∗ B =

2920bytes3040bytes ∗B = 0, 9605 ∗B.

Implementing the header option would cause additional 6 bytes per packet, resulting in data pack-

ets, that carry 6 bytes less data and ACKs that are 6 bytes longer. Thus the throughput would be

ALTimp = 2∗1454bytes2∗1500bytes+40bytes ∗B = 2908bytes

3040bytes ∗B = 0, 9547 ∗B. The performance degradation would

be ALTst−ALTimpl

ALTst= 0,9605∗B−0,9547∗B

0,9605∗B = 0, 006 = 0, 6%. In case, the TCP proxy would only run on

one specific port to allow more services to be run on the TCP proxy host, the destination port has

to be added to the IP or TCP header causing additional 4 bytes overhead.

A problem when using this solution will be encountered, when the mobile node is not the connection

initiator. Since only the stack of the mobile node could be changed, the initiating fixed host would

send its connection request directly to mobile node instead of the proxy. The same problem arises,

when two mobile nodes using a TCP proxy are establishing a TCP connection.

5.5.2 IP Tunneling Approach

A similar approach to overcome the problem of changing the IP protocol by introducing a new IP

option in the IP header can be avoided by using an IP tunnel [14] from the mobile node to the TCP

proxy.

If one communication partner wants to send a packet to the receiver, the original IP packet containing

the TCP packet is encapsulated into a second IP packet, destined to the TCP proxy. This IP packet

would the be forwarded to the TCP proxy by the standard routing algorithms. The TCP proxy

receives the IP packet, decapsulates the inner IP packet and uses it for the TCP proxy algorithm.

The TCP proxy itself establishes a normal TCP connection to the destination host. Figure 5.8 shows

a model for an TCP proxy implementation using IP-Tunneling.

The drawback of this solution would be an additional amount of header data, by the second IP

header. This additional reduces the maximum segment size, that can be used for data over IP. A

standard additional IP header would increase the header size by 40 bytes and reduce the theoretical

maximum throughput to ALTIPIP = 2∗1440bytes2∗1500bytes+60bytes ∗ B = 2880bytes

3060bytes ∗ B = 0, 9412 ∗ B. The

94


IP Source MN

IP Dest Proxy

IP Source MN

IP Dest: CN

TCP

data

Mobile Node (MN) Proxy

Correspondent Node (CN)

IP Source Proxy

IP Dest: CN

TCP

data

IP Source CN

IP Dest: Proxy

TCP

data

IP Source Proxy

IP Dest MN

IP Source CN

IP Dest: MN

TCP

data

Figure 5.8: IP Tunneling Model

relative reduction would be ALTst−ALTIP IP

ALTst= 0,9605∗B−0,9412∗B

0,9605∗B = 0, 020 = 2%.

A consideration, that could invalidate the equation, covers the question, if the additional IP header

added by the IP tunnel will cause fragmentation of each individual packet. Since the mobile node

and the TCP proxy are endpoints of the IP tunnel, they both know about the reduced MSS and

thus can reduce the segment size accrodingly. Secondly, approaches like Path MTU Discovery [35]

prevent those problems.

The amount of additional header information can be reduced by deleting all the unneeded header

information of the encapsulated IP header. This technique is called ”Minimal Encapsulation” and

is described in detail in [15].

The problem of TCP connections not initiated by the mobile node will not be solved using an IP

tunnel.

5.5.3 In-Path Approach

An integration of an intercepting TCP proxy into a given network can be achieved by directly in-

tegrating the TCP proxy into the physical path from the mobile node to the correspondent host.

A model of this approach is shown in Figure 5.9. The TCP proxy would be equipped with 2

network interface cards and used as packet forwarder in the network. Packets, that arrive at one

network interface card will be decoded and inspected for the TCP protocol. TCP packets would be

95


TCP Proxy CorrespondentHost

Mobile Node

Figure 5.9: In-Path Model

sent to a running TCP proxy daemon, while all other packets would be forwarded directly to the

second interface card. The same logic applies to the reverse direction. A drawback of this scenario

is that breakdowns of the TCP proxy would directly lead to a disconnection of the complete wireless

supporting network. Secondly, not only the TCP traffic itself but all traffic would be sent over the

TCP proxy. Depending on the implementation of packet decoding and encoding, this could lead to

performance problems.

5.5.4 ARP Approach

In Ethernet networks, the Address Resolution Protocol (ARP, [23, 39]) is used to map IP addresses

to corresponding MAC addresses in a subnet. If a node in an Ethernet network has to send a packet

to a specific IP address in its subnet, the IP address is looked up in a local ARP table and the packet

is forwarded to the MAC address, if an ARP entry is available in the table. If no entry matches to

the IP address, an ARP request is broadcasted over the network do determine the mapping between

IP and MAC address. The requested node in the network sends a unicast ARP reply back to the

sender. If the IP address is outside the subnet, the packet is forwarded to the IP address of the

gateway.

The idea behind the ARP approach is to shadow the mobile node from the correspondent node and

vice versa. Since ARPs are only generated in a subnet, the IP address of the gateway, that forwards

the IP packets to the correspondent node, is spoofed. For the gateway, the TCP proxy would appear

at the IP address of the mobile node, and for the mobile node at the IP address of the gateway.

Thus, the ”trick” of the TCP Proxy would be to spoof the IP address of the mobile node as well as

of the gateway. This approach can be seen as a ”controlled” man-in-the-middle-attack. A model of

this approach can be found in Figure 5.10.

96


TCP Proxy

CorrespondentHost

Mobile Node Gateway

Figure 5.10: Model of the ARP Approach

To realize the spoofed IP address, the TCP Proxy would send a spoofed ARP reply containing

the TCP Proxy’s MAC address on every ARP request. Thus, the mobile node would add an entry

to its local ARP table containing the IP address of the gateway and the MAC address of the TCP

Proxy. The mobile node would then send every packet to the TCP Proxy. The same scheme is

applied to the ARP table of the gateway. Since ARP entries time out after a certain amount of

time, ARP request are sent to keep the ARP table up to date. Due to this behavior of ARP, an

automatic failover - assuming a soft-state proxy - would be possible. In case of a defective TCP

Proxy, that would not respond to ARP requests, the mobile node or gateway would reply to the

ARP request and thus reporting being available.

The drawback of this approach is a potential timing problem. Since the TCP Proxy and the com-

munication hosts are both replying to ARP requests, both network nodes race for the entry in the

ARP table. The implementation has to ensure, that the ARP entry containing TCP proxy address

is always the most recent in every network node, that uses the TCP proxy. The stability of the TCP

proxy will mostly depend on how effective this problem can be solved.

5.5.5 Routing Approach

To intercept TCP connections between the mobile node and the correspondent node, the TCP Proxy

does not necessarily need to be located on the physical path between them, but in the logical path.

This fact leads to a last solution that is based on an adapted routing process.

The standard routing process is based on destination based routing. With destination based routing,

an incoming IP packet is routed by its destination IP address and sent accordingly to the interface,

97


that is specified in the routing table. The routing table itself could either be setup with static

routes manually entered into the router or dynamically with routing protocols like Border Gateway

Protocol (BGP, [43]), Routing Information Protocol (RIP, [32]) or Open Shortest Path First (OSPF,

[36]).

Assuming, that all wireless supporting networks are connected via a central router to the wired

network, the routing tables could be altered in such a way, that the packets would be forwarded

to the TCP proxy located on one interface of the central router. Thus, the router has to support

three interfaces: one for the wireless supporting network, one for the TCP Proxy and one for the

wired network. In a first configuration, static routes could be used to route every packet to the

TCP Proxy. Every packet coming from the wireless supporting network as well as every packet from

the wired network would be sent to the TCP Proxy. But also packets, that are sent from the TCP

Proxy are sent back to the Proxy. Assuming that the TCP Proxy mirrors all packets, that cannot

be processed, the packets would oscilate between the router and the TCP Proxy and be discarded

after the time-to-live of the IP packets expires.

A routing process, that can route a packet based also on the source IP address or on the interface,

on which it has been received, would be needed to avoid this oscillation. Policy-based routing [18]

is the technology, that can be used to achieve this behavior. Policy-based routing can be applied on

different interfaces of the router individually and is performed before the standard destination-based

routing on incoming packets. It allows to reroute individual packets matching to specific criteria to

different interfaces. In this case, policy-based routing is applied on the interfaces connecting to the

wireless supporting network and to the wired network. Every packet that is identified as a TCP

packet, is forwarded to the TCP Proxy. If the TCP Proxy now sends a TCP packet back to the

router, this packet is processed by the destination based routing and forwarded to the destination

network. Figure 5.11 shows a model of the implementation with altered routing tables.

Automatic failover can be achieved by combining policy-based routing with periodical ARP re-

quests on the TCP Proxy. If the TCP Proxy goes down, the policy-based routing rules will be

disabled and destination-based routing ensures the correct routing to the according networks.

Policy-based routing requires a full inspection of the arriving packets and therefore needs more pro-

cessing power in the routers. The routers used in the experiments were reported to be capable of

98


TCP Proxy

CorrespondantHost

Mobile Node

Policy Based Routing applied

Figure 5.11: TCP proxy implementation using policy-based routing

processing 70.000 packets per second with destination based routing, whereas the performance drops

to 1.000 to 10.000 packets per seconds with policy-based routing [17].

Since this approach offered the most flexibility in most scenarios and did not need any changes in

the IP-stack of the mobile node, this implementation option was chosen.

5.5.6 Conclusion

Concluding the considerations about the network implementation of a TCP proxy results mainly in

the tradeoff of the advantages and disdavantages between transparent and non-transparent proxy

implementation. A non-transparent implementation would give the end-user the control wether to

trust and use the TCP proxy, but using a TCP proxy in case the mobile node is not the connection

initiator seems to be difficult if not even impossible. The individual non-transparent implementations

differ mainly in their ammount of additional overhead.

Transparent proxies move the decision wether using a proxy or not to the network operator. Thus,

end users not willing or in need of non-modified end to end connections are not able to disable the

proxy functionality. The same problem will be encountered, when specific TCP connections want to

use a TCP proxy while other connections need undmodified end to end connections. On the other

hand, TCP connections established to the mobile node could also benefit from the use of a TCP

proxy. The different transparent implementations differ mainly in their approach to get into the

logical path between the two end systems.

99

5.6 Proxy Functionality and Software Architecture


The TCP Proxy was implemented in three phases. In a first phase, a TCP Proxy, that simply

mirrors all incoming packets and sends them back to the network was implemented. In a second

phase the full split TCP connection approach was designed and implemented into the TCP Proxy.

Finally, a module to eavesdrop on Mobile IP messages was added to the TCP Proxy to provide a

performance enhancement option in handover situations.

5.6.1 Mirroring Proxy Implementation

In a first implementation, the functionality of a mirroring proxy was implemented. The aim of

the mirroring proxy was on the one hand to figure out, which interfaces and possibilities for packet

capturing, decoding, encoding and sending are provided by the Linux operating system, on the other

hand to develop a flexible and stable packet capturing, decoding, encoding and sending engine.

The basic high level fesign is shown in Figure 5.12 and consists of three main entities:

• Packet listener module: This module provides functionality for capturing packets from the

network interface card (NIC) and storing the decoded packet into a buffer.

• Mirror Daemon: The daemon is responsible for mirroring the packets. It thus has to watch

for incoming packets, that are stored in the buffer of the packet listener module and forward

the packets to the packet sender.

• Packet sender module: The packet sender provides a buffer to the mirror daemon to send

packets to the NIC. The task of the packet sender was to encode the packets and send them

to the NIC.

To achieve better performance of the three modules, they have been implemented into three dif-

ferent threads. The reason for choosing a threaded model came from the consideration, that packets

might get lost by the packet listener, if the mirror (or especially the later split-TCP daemon) are

using too much processing time and thus the application could not start to listen fast enough for the

next packet. Since the modules are not independent from each other, but share common resources

(that are the packet buffers), each packet buffer has been protected by semaphores, that count the

100


NIC

Packet Listener

NIC

Packet sender

Capture and decode Encode and send

Pop packet Push packet

Mirror Daemon

packet buffer packet buffer

Figure 5.12: High-Level-Design of the mirroring TCP Proxy

number of packets currently stored in the buffer.

Since the packet sender and the packet listener modules are independent from each other, the im-

plementation is flexible to the kind and number of interfaces, that are used for sending or receiving.

Thus, the implementation could be changed in this two particular modules to support multiple in-

terfaces or using the mirror as a switching entity in the network.

5.6.2 Split TCP Implementation

After implementing the mirroring TCP proxy, a design for the Split TCP proxy was developed. The

design of the split TCP daemon was adopted from the mirroring Proxy, so that the packet listener

and packet sender modules could be reused. Therefore, only the mirror daemon was exchanged by

the split TCP daemon. The architecture of the split TCP proxy is visualized in Figure 5.13. The

split TCP daemon itself is decomposed into different subcomponents:

• Connection Pool

• Packet Router

• TCP Connection

• Split TCP Connection

101


Get data

establishclose

Process known TCP packet

Push packet(s)

send data

TCP ConnectionData buffer

Split-TCP Connection

Notify(old state, new state)


Packet Router Connection PoolFind

Connection

Pop packetForward unknown packet

Split TCP Daemon

NIC

Packet Listener

NIC

Packet sender

Capture and decode Encode and send

packet buffer packet buffer

Figure 5.13: High-Level-Design of the Split TCP Proxy

The connection pool acts as a container for all established TCP connections. It provides func-

tionality mainly for searching TCP Connections for different properties.

The packet router is responsible for identifying the packet and forwarding the packet to the right

TCP connection. In case a TCP SYN-packet is received, the packet router creates a new split-

connection including a TCP connection (comparable to a TCP Control Block (TCB)) and adds the

newly created connection to the connection pool. If no active connection is found or the packet

could not be identified, the packet is forwarded to the packet sender, so that the packet is mirrored.

This behavior ensures, that data flows, that were previously established, are not interrupted and

packets that are misrouted to the proxy are sent back.

The TCP connection implements the TCP specification using the TCP Reno algorithm and offers

an interface to the packet router and an interface to the split TCP connection handler. For the

packet router, an interface to receive the TCP packet is provided. The interface offered to the split

TCP connection component is similar to the interface of a socket, that is implemented in operating

102


systems. Methods for opening, closing and resetting the connection as well as methods for reading

and sending data are provided. The data is read and written to a connection-local data buffer, that

is used for sending or receiving data. After a TCP connection has processed a new packet, it informs

its split connection about its state before and after processing the packet. The split TCP connec-

tion thus gets noticed, when the TCP connection is setup, terminated, reset or received new data.

Since only two interfaces are needed to communicate to the packet router and the split connection

component, the implementation of the TCP connection can be changed dynamically.

The split TCP connection component acts as a daemon object, that basically interconnects two TCP

connection. Data, that is received on the one connection, is forwarded to the associated connection

via its in- and out-buffers.

Depending on the detailed implementation, different behaviors regarding performance and safety

of the TCP proxy are possible. The basic decision, that has to be made, is, wether the TCP Proxy

should acknowledge data packets, before an according ACK is received from the corresponding or

not. The same decision has to be made for connection setup and termination. In case the TCP

Proxy would send ACKs before a corresponding ACK is received, both TCP connections would

be completely independent and follow a true split-connection approach. It is expected, that the

throughput of this solution is higher, since there is less dependency on the second TCP connection

with its RTTs and throughput. The impact on TCP performance in a connection setup is visualized

in Figure 5.14.

If the TCP Proxy would delay ACKs until receiving the according ACK from the correspondent

host, the safety in case of failures would raise. In case, no listening process on the correspondent

host is attached to the requested port, a SYN would be rejected with a RST packet. In a true

split connection approach, the left connection would have been setup and maybe even started to

transfer data, before the right connection send the RST-packet. Thus, the communication partner

on the left connection believes, that the connection was setup correctly. In this implementation, the

performance argument lead to the choice of a true split connection approach.

In the design of the mirroring proxy, threads were used for the packet listener, for the packet sender

and for the mirror daemon. This concept of a three-thread model could be adapted to the split TCP

103


Sender TCP Proxy

SYN

SYNACK

ACK

SYN

SYNACK

ACK

Receiver Sender TCP Proxy

SYN

SYNACK

ACK

SYN

SYNACK

ACK

Receiver

Figure 5.14: The qualitative impact of different proxy functionalities on connection setup delays inTCP

proxy. Thus, the complete split TCP daemon and every TCP connection would run in common

thread. Another approach would run every pair of TCP connection or even every TCP connection

could run in a separate thread. A per-connection-threaded model could mainly effect the perfor-

mance in multi-user and multi-connection scenarios. On the one hand, a per-connection-threaded

implementation would improve the processing fairness of the TCP connection threads, since process-

ing times would be divided nearly equally2 and every active TCP connection would be granted some

processing time. In a single-threaded implementation, a processing TCP connection would block all

other TCP connection connections in its processing.

On the other hand, a per-connection-threaded implementation increases the number of threads and

consequently the number of thread-switches, that have to be performed by the operating system

and the processor. The effects of thread switching could change the throughput significantly on

high load of the proxy. Secondly, an increased number of threads would also reduce the processing

time, that is given to the packet listener. In general, assuming a fair operating system, that assigns

processing time equally to every thread, the processing time would fall from 13 to 1

n+2 , if n is the

number of TCP connections. The additional two threads are the packet listener and packet sender.

For a large number of TCP connections and hence a large n, few processing time is assigned to the

2dependant on the process scheduling algorithm implemented in the operating system

104


packet listener, potentially resulting in packet loss.

5.6.3 Mobile IP Daemon Implementation

To overcome the problems of long handover delays, a module was implemented, that eavesdropped

on incoming and outgoing MobileIP messages in order to use the Mobile IP messages an indication

of a reconnected mobile node. All TCP connections, that were established to the mobile node

could immediately start to send data instead of waiting for a retransmission timeout. The Mobile

IP daemon made an enhancement of the packet listener, packet sender and packet router and an

implementation of the Mobile IP daemon necessary. The extended part of the split TCP architecture

can be found in Figure 5.15.


Packet Router Connection PoolFind Connection

Pop packetForward unknown packets

Mobile IP DaemonProcess known TCP packet

Process MobileIPpacket Find all

Connections

Recover

Packet-buffer Packet-buffer

Forward MIPpacket

Figure 5.15: High-Level Design of the Mobile IP Module

The packet listener and packet sender were extended to support the decoding and encoding of

MobileIP requests and replies. The packet router was extended to forward all Mobile IP messages

to the Mobile IP daemon.

The task of the Mobile IP daemon was to inform all TCP connections, that the mobile node is

available again. Thus, the daemon inspected the Mobile IP message for the advertised home address

and performed a lookup of the IP address in the TCP connection pool. All found TCP connections

are then informed about the reconnected mobile node.

105


106

Chapter 6

Evaluation of the TCP Proxy inWireless Scenarios

In this chapter, the implemented TCP proxy is evaluated. First, the influence of the TCP proxy on

RTTs is investigated since the additional processing and serialization and probably queuing delay

is expected to add delays to the RTTs of TCP. Secondly, the influence of different ACK handling

on the performance over a wireless link is investigated, since the number of delayed ACKs and the

value for a ACK timer is not specified in [41].

6.1 Influence on RTTs

In a first experiment, the influence of the mirroring proxy as well as of the split TCP proxy was

investigated over wireless LAN. The single access point network model as described in Section 3.1.1

was reused except that access point was replaced. The Cisco 350 WLAN access point was replaced

by a Cisco 1100 WLAN access point, since only that access point was available at the time this

evaluation was made. A TCP connection was setup from the mobile node to the correspondant

node and data was sent upstream from the mobile node to the correspondent node for 10s. The

mobile node was located 1m away from the access point and did not move during the duration of

the measurements. Running a TCP connection over the wireless link leads to Figure 6.1.

The graphs show, that integrating the TCP proxy into the network and running the proxy in

mirroring mode adds approximately 1,5 ms to the RTT. The additional budget of RTT is generated

by the additional queuing and processing amount of the TCP proxy. The main delay, that is added

107

6.2 Influence of Delayed ACKs on Throughput

15.00

15.50

16.00

16.50

17.00

17.50

18.00

18.50

19.00

No Proxy Mirror Split TCP

RT

T (

ms)

Impact of TCP Proxy on RTTs

Figure 6.1: Influence of the TCP Proxy on RTTs

by the TCP proxy is caused by the decoding, buffering and subsequent encoding of packets.

Integrating a Split TCP proxy into the network, adds an additional budget of 1,5 ms to the RTT

compared to the mirroring proxy. This effect is caused by the Split-TCP daemon, that adds addi-

tional processing delay to the proxy. Additional proccessing time is caused by assigning the TCP

segment to the TCP connection and processing the TCP packet in the TCP algorithms.


In a second experiment, the influence of the number of delayed ACKs over the wireless link was

evaluated. The single access point network architecture was used to measure this influence. In a

first set of measurements, a TCP connection was setup in upstream direction and data was sent

over a period of 10s. The mobile node was situated 1m away from the access point and stayed

at that location. Measurements have been made for different number of delayed ACKs. In a first

measurements, every data packet was acknowledged, in the second every second data packet was

108


acknowledged. The delayed ACK timer was set to 500ms. The measurements have been compared

to the mirroring proxy scenario. Plotting the transmission throughput leads to Figure 6.2.

0

100000

200000

300000

400000

500000

600000

700000

800000

00:00 00:10 00:20 00:30 00:40 00:50 01:00

Thr

ough

put (

byte

s/se

c)

Time

Receiver Throughput

ACK every packetACK every 3 packetACK every 5 packet

Mirroring

Figure 6.2: Transmission throughput with different number of ACKs transmitting 30 MByte of data

It can be observed, that acknowledging every data packet leads very fast to an aproximately

constant transmisison throughput, while acknowledging every fifth packets suffers from a long initial

slow start phase. After approximately 25s, the transmission throughput exceeds the throughput of

the mirroring proxy. In case of every third data packet is acknowledged, the initial setup time is

lower compared to acknowledging every fifth packet and exceeds the mirroring proxy more timely

after approximately 15s, but gains less average throughput.

Two effects cause those results. First, the more packets are cumulative acknowledged and hence

ACKs are more delayed, the less additional overhead is caused by the ACK packets. This leads

to a higher throughput when TCP is in congestion avoidance phase. In contrast, when TCP is in

slow-start, an immediate ACK would be needed to open up the congestion window quickly. Since

slow-start sends only one packet in the first RTT, a delayed ACK mechanism will delay the packet

109

6.3 Influence of the Delay-ACK Timer on Throughput

resulting the sender to wait for a retransmission timeout. The more data packets are delayed, the

more retransmissions are triggered resulting in a lowered throughput.

6.3 Influence of the Delay-ACK Timer on Throughput

To overcome the problem of delaying ACK too long, TCP defines, that an ACK must not be delayed

longer than 500ms. In operating system implementations, the delayed ACK timer has a value of

200ms. Timers in an common operating system like Windows and Linux are usually implemented

coarse grained since they are costly. A 200ms timer is usually fired between 201ms and 400ms after

the timer was set.

In the proxy implementation, the timer was implemented with a finer granularity. Experiments

showed, that under averaged load the implemenmted timer algorithm showed a constant offset of

approximately 5ms with a resolution of 5ms.

In order to evaluate the TCP performance of different delayed ACK timer values, the measurement

from above was repeated with delaying every third packet with a measurement duration of 10s. The

results are visualized in Figure 6.3.

It can be observed that the shorter the timer value, the faster the connection reaches the con-

gestion avoidance phase and thus a steady throughput state. On the other hand, a low timer value

leads potentially to uneccessary ACKs since data packets may not arrive fast enough to shift a timer.

Reference [11] states, that an acknowledgement must be triggeredt at least after every second packet

or after 500ms, whatever comes first. It is also stated, that ACKs have to be sent immediately,

when data packets with an amount of data less than the MSS. The threshold of data amount, if a

packet must be triggered immediately, is not defined explicitly. The used TCP implementations in

the operating systems (see Appendix B.5 and B.7) use this requirement to force an ACK in the first

RTT of slow start. TCP sends a small data packet (payload sizes of 24 bytes have been observed in

Windows XP and Linux Kernel 2.4.18-3) although the initial congestion window would allow a fully

utilized packet. The receiver host then has to ACK immediately this packet resulting in a doubled

congestion window at the sender side. In the second RTT, the sender is allowed to send two data

packets, that are now fully utilized and acknowledged with a delayed ACK of the receiver.

110

6.4 Further Evaluations and Future Work

0

100000

200000

300000

400000

500000

600000

700000

800000

00:00 00:01 00:02 00:03 00:04 00:05 00:06 00:07 00:08 00:09 00:10 00:11

Thr

ough

put (

byte

s/se

c)

Time

Transmission Throughput using different delayed ACK timeout values

10ms100ms50ms

500msMirroring

Figure 6.3: Transmission Throughput with different delayed ACK timeout values


The TCP proxy was evaluated in scenarios with different BER rates. The experiments have been

made at the concurrently with the evaluation shown in Section 4.2.3. The evaluation did not show

any new results. The performance of TCP measured with proxy enabled was comparable to the

performance of TCP with the proxy disabled.

Different scenarios and evaluations of the proxy have not been performed. Coupling Mobile IP with

the TCP proxy in order to use the Mobile IP signaling to restart the TCP connection to the mobile

node has not been evaluated.

Another approach using a TCP proxy could improve the performance of TCP, in case different MSSs

are used for the TCP connections. The TCP Proxy thus could defragment smaller packets received

on the low MSS TCP connection and send a full MSS packet on the high MSS TCP connection.

The idea to implement this into the current architecture is to introduce two thresholds to the socket

buffer. One threshoild is used to trigger data packets to be sent if the socket buffer reaches the first

111


threshold. The second threshold is used to stop TCP to send more data and wait for new data from

the application. An additional timer could be used to ensure, that data is send at least in a certain

interval.

The influence of transparency has not been evaluated. If an ACK is not sent to the sender by the

proxy unless a corresponding ACK is received from the receiver, the throughput and RTTs might

be influenced as well as the initial connection setup time as shown in Figure 5.14.

112

Chapter 7

Conclusion

The thesis aimed to verify, if the initial assumptions of TCP can be kept up when TCP is used over

Wireless LAN 802.11b and Bluetooth.

The evaluation of Wireless LAN showed, that high BERs did not trigger TCP retransmission thus

resulting in a good TCP performance. It can be concluded, that link layer retransmissions seem to

be an effective method to hide BERs on link layer to TCP. Even with competing crosstraffic flows

TCP performs good.

Indeed, handovers in Wireless LAN and hence a period of disconnection degrades the TCP per-

formance resulting in additional TCP handover delays. It has been observed that dynamic IP

assignment caused long handover times on network layer. A TCP proxy could solve this problem in

case Mobile IP is used to support IP mobility.

The evaluation over a Bluetooth link showed that different influnces can cause throughput drop-

downs of UDP or TCP. These dropdowns can be caused by interference or additional traffic. A

detailed evaluation could not be done, since a sniffing tool on baseband level was not available.

The concept of a TCP proxy has been introduced and the various options to integrate the proxy into

an existiung network as well as implementation options have been discussed. A discussion about

the different parameters of the acknowledgement mechansim of TCP has been shown. A successfull

implementation of the Mobile IP coupling approach has not been done.

For future work, a more detailed analysis has to be done to evaluate the influences of BERs on

the performance of TCP. It has not been proven, that a different implementation of TCP or a TCP

proxy can perform better than the current TCP implementation in Windows or Linux with link layer

113

retransmissions. An evaluation of TCP Vegas over a wireless link as well as TCP over W-CDMA or

GPRS is also considered for future work.

114

List of Abbreviations

ACK Acknowledgement

ARP Address Resolution Protocol

ARQ Automatic Repeat Request

AWND Advertised Receiver Window

BER Bit Error Rate

CWND Congestion Window

DHCP Dynamic Host Configuration Protocol

FDMA Frequency Division Multiple Access

FEC Forward Error Correction

GPRS General Packet Radio System

GSM Global System for Mobile Communication

HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol

IP Internet Protocol

MAC Medium Access

115

MN Mobile Node

NIC Network Interface Card

PAN Personal Area Network

QoS Quality of Service

RTO Retransmission Timeout

RTT Round trip time

ssthresh slow-start-threshold

TCP Transmission Control Protocol

TDMA Time Division Multiple Access

WLAN Wireless Local Area Network

WPAN Wireless Personal Area Network

ZWA Zero Window Advertisement

ZWP Zero Window Probes

116

Appendix A

TCP

A.1 The TCP Header

LISTEN

SYN_RCV SYN_SENT

Rcv SYN; Send SYNACK

ESTABLISHED

FIN_WAIT_1 CLOSING

FIN_WAIT_2 TIME_WAIT

CLOSE_WAIT

LAST_ACK

Send SYN

Rcv SYN; Send SYNACK

Rcv ACK Rcv SYNACK; Send ACK

Send FIN Rcv FIN; Send ACK

Send FIN

Rcv FIN; Send ACK

Rcv ACK Rcv ACK

Rcv FIN; Send ACK

2 MSL timeout

timeout

Rcv ACK

Send FINRcv FIN; Send ACK

Figure A.1: TCP State Machine

The TCP State Machine describes the different states of a TCP connection during its lifetime.

In a brief description, its states can be described as follows:

117

A.2 TCP Flavours

• LISTEN is the initial state of a TCP connection and represents the state, that TCP is either

waiting for a request from a remote TCP or a request from the local port to initiate the

connection.

• SYN-SENT describes the state after sending the first SYN-packet. TCP now waits for

receiving a matching connection request.

• SYN-RECEIVED represents the state after both connection partners have signaled the

connection request via a SYN-packet. In this state, TCP waits for the acknowledgement of

the SYN-packet.

• ESTABLISHED describes an open connection, able to send and receive data. The TCP

connection will stay most of the time in this state.

• FIN-WAIT-1 describes TCP’s state after a connection termination request was sent to the

remote TCP. TCP waits for an acknowledgement of the termination request or a termination

request from the remote TCP.

• FIN-WAIT-2 represents TCP’s state waiting for a connection termination request.

• CLOSE-WAIT describes the state waiting for a connection termination by the local port.

• CLOSING represents the state waiting for a connection termination request acknowledgement

from the remote TCP

• LAST-ACK represents TCP’s state waiting for the connection termination request acknowl-

edgement.

• TIME-WAIT describes a final timeout wait state, that is used to ensure that the remote

TCP received the acknowledgement of its connection termination request

A.2 TCP Flavours

A.2.1 Vegas

TCP Vegas [12] is an alternative implementation of the TCP specification, that increases TCPs

throughput compared to the Reno implementation. To achieve this aim, TCP Vegas introduces

three new schemes:

118

A.2 TCP Flavours

• A new retransmission scheme that retransmits dropped packets more timely

• A modified congestion control algorithm, that adjusts more adequate to the available band-

width

• A new slow-start algorithm that avoids packet loss, while finding the maximum available

bandwidth

In standard operating systems, the timers are usually implemented coarse-grained with a granu-

larity of 500ms, so that the values for the actual retransmission timeout is not very accurate. TCP

Vegas overcomes this problem by placing timestamps to the TCP segments, when they are injected

to the network. If an ACK is received at the senders side, a second timestamp is used to calculate

the RTT. On the reception of a DUPACK, the time difference between the actual system clock

and the timestamp recorded at sending is compared. If the value exceeds the retransmission timer,

a retransmission is triggered without waiting for three DUPACKs. If an ACK is received after a

retransmission, TCP Vegas compares the time interval with the retransmission timeout and retrans-

mits the packet. This will recover multiple lost packets in one window. Concluding TCP Vegas uses

ACKs as indicator for a retransmission timeout, but uses still the coarse grained timers as a fallback

case.

TCP Vegas introduces a new congestion control algorithm, that is based on a proactive approach.

TCP Reno uses a reactive approach, that estimates the maximum available bandwidth by artificially

creating congestion. TCP Vegas instead, uses the following phenomenon to measure the available

bandwidth without artificially creating congestion. If the congestion window is increased, the ex-

pected sending rate (ESR) is increased as well. The available sending rate (ASR) at receivers

side, may not be increased if the sending rate is close to the maximum available bandwidth, since

the packets will be queued at one of the intermediate routers. TCP Vegas measures the expected

sending rate (ESR) by dividing the window size by the RTT that was measured for the first sent

segment. The actual sending rate is calculated for a specific packet by the amount of data, that was

injected into the network between the time, the specific packet was sent, and the time the ACK was

received. This amount of data is divided by the RTT, that was measured via timestamps. TCP

Vegas increases its congestion window linearly, if ESR − ASR < α and decreases the congestion

window linearly, if ESR − ASR < β, with α < β. if the ESR − ASR is between α and β, the

119

A.2 TCP Flavours

congestion window remains unchanged. α and β are suggested to α = 1 and β = 3.

TCP Vegas also modifies TCP’s slow-start algorithm to avoid packet loss, while finding the maxi-

mum available bandwidth. The slow-start algorithm is also adapted to the new congestion control

algorithm. So, TCP Vegas increases its sending rate exponentially, but measures the difference of

the sending rates meanwhile. So, every second RTT the congestion window is kept constant to get an

accurate measurement of ESR and ASR. If the value of ASR falls below the expected value ESR

by γ, slow-start is left and the congestion avoidance algorithm is entered, otherwise the congestion

window is increased exponentially.

The evaluation [3] showed, that TCP Vegas improves the performance compared to TCP Reno and

NewReno by reducing the number of retransmission rapidly. Since TCP Vegas is less aggressive to

the use of intermediary router buffers, TCP Vegas performs poorly when competing with a TCP

Reno stream. An evaluation of TCP Vegas over large bandwidth delay networks [30] showed, that

TCP Vegas performs poor in its slow-start phase, since it underestimates the maximum available

bandwidth and it leads to temporary buffer queue buildup.

Modifications that improve the fairness of TCP Vegas, have been proposed in [29].

A.2.2 Forward Acknowledgements

Forward Acknowledgements (FACK) [34] try to estimate the outstanding data in the network in er-

ror recovery states in a more appropriate way under multiple packet losses. In a standard TCP Reno

implementation, multiple packet losses can result in loosing the self-throttling behavior of TCP and

cause unnecessary retransmission timeouts and a slow-start. During that timeout and additional

slow-start, the network bandwidth is underutilized resulting in poor TCP performance. Reference

[34] pointed out the inability of TCP Reno to perform congestion control in error recovery states.

The FACKs are an extension to SACKs and introduce two new state variables at the senders side:

snd.fack and retran data. The sender keeps not only track of the first byte of unacknowledged

data (snd.una) and the first byte of unsent data (snd.nxt), but also of the highest sequence number

of correctly received data (snd.fack) plus one. In the normal data processing, the snd.fack value

equals the snd.una value. In recovery states, the snd.fack utilizes the SACK blocks and updates the

sequence number of highest number of correctly received data, if necessary. The second variable,

120

A.2 TCP Flavours

retran data, reflects the number of retransmitted data, that is outstanding in the network.

The FACK implementation uses this new variables in order to compute the amount of data out-

standing in the network. This value was called awnd. In non-recovery state, awnd is computed

as per normal, i.e. awnd = snd.nxt − snd.fack. Note that in non-recovery states, snd.una and

snd.fack have the same values and therefore it is the same equation as in TCP Reno. In recov-

ery state, the value of outstanding retransmitted data, retran data, has to be added and leads to

awnd = snd.nxt − snd.fack + retran data. The sender sends data as long as enough congestion

window is available to fill up the outstanding data, i.e. data is send if awnd < cwnd. The robust-

ness is derived from the fact, that the sender either increases retran data in case of a retransmitted

packet or snd.nxt if a new packet was send. Received ACKs decrease either the value of retran data

or increase snd.fack. If snd.fack acknowledges data beyond snd.nxt, this indicates that the packet

was lost. To improve TCPs behavior in case of packet loss, the recovery condition was changed.

Recovery is additionally triggered in case that more than three packets have to be reassembled. This

condition can be computed by (snd.fack − snd.nxt) > 3 ×MSS. Two additional algorithm were

also implemented and evaluated in [34], Overdamping and Rampdown.

The new congestion control scheme showed substantly better performance in case of multiple packet

loss in a simulation environment, since it is not as bursty as the common TCP Reno implementation.

The additional Overdamping algorithm showed too conservative performance whereas Rampdown

seemed to perform good.

A.2.3 Total Acknowledgements

Total Acknowledgements (TACK) [53] address the problems of asymmetric links, that cause frequent

ACK losses. TACKs follow the same approach as FACKs, i.e. estimating the outstanding data in

the network, but suggest negative ACKs (NACKs) recover from multiple data or ACK losses.

TCP FACK may overestimate the number of outstanding data in some cases. TCP FACK assumes,

that SACK blocks beyond the lost packets are contiguous. In a scenario, where 6 packets are injected

into the network and packet 3 and 5 are dropped due to congestion, FACK would receive an ACK

for packet 2, expecting packet 3 and set snd.fack to 7, since packet 6 was the last successful received

packet reported by SACK blocks. Therefore, the estimated outstanding data is 4 instead of 3. TCP

121

A.2 TCP Flavours

TACK suggests the use of total acknowledgements tack, that can be computed by the number of

cumulative acknowledged bytes cack and the number if additionally, out-of-order received bytes

additional, i.e. tack = cack − 1 + additional. This additional value is transmitted by the receiver

in an additional option field.

[53] also proposes a scheme for using NACKs instead of positive ACKs like in SACK, since they tend

to be more robust against ACK loss than positive ACKs. They also showed, that the TCP TACK

implementation including NACKs enhanced the TCP performance in asymmetrical links.

A.2.4 Header Checksum Option

The TCP Header Checksum Option (TCP HACK) [6] uses the premise, that in case of packet

corruption it is more likely, that the data will be corrupted and not the header. In standard

networks, the amount of data is much larger than the amount of the header. With this knowledge

the receiving TCP can identify the corrupted data and forward this information to the sender. The

sender could then retransmit the corrupted packet without unnecessarily lowering the congestion

window. The result is a more appropriate bandwidth estimation and a higher throughput.

Two new TCP options were added to the TCP implementation. One option carries the header

checksum in a data packet, the second option contains the sequence number of the corrupted packet

in ACK packet.

The data processing algorithm of the TCP implementation was changed at three specific locations.

After negotiating the TCP Header Checksum Option in the SYN- and SYNACK-packets, the sending

TCP calculates the TCP checksum including an IP-pseudo header and adds this value to the TCP

Options. When the receiving TCP receives this data packet including the option, it checks first the

standard TCP checksum. If the checksum fails, it can determine wether the corruption took place in

the header or the data by calculating the header checksum and comparing it to the value transmitted

in the header checksum option. If the corruption occurred in the header, the normal TCP processing

is applied, i.e the packet is discarded. In case of corrupted data, a ”special ACK” is sent. This special

ACK contains the sequence number of the corrupted data packet in the TCP options. When the

sending TCP receives an ACK, it looks first for the option containing the sequence number of the

corrupted data. If it is not present, the normal TCP processing is applied. If the option is present,

122

A.2 TCP Flavours

the corrupted data is retransmitted in a new packet, while the ACK itself is discarded without

further processing at the senders TCP.

The evaluation of TCP HACK showed, that TCP HACK performs much better in lossy links than

SACK alone. It also showed, that SACK and HACK can benefit heavily from the characteristics of

each other since they are disjoint algorithms.

A.2.5 Transactional TCP

Transactional TCP (T/TCP) [7, 10, 9] was designed to improve TCPs performance in transactional

scenarios. Transactional scenarios are mainly characterized by a short request message from the

client to the server and a response message by the server. For instance, HTTP is a typical transac-

tional service, that runs on top of TCP. The client, i.e. the web browser, sends a small HTTP-Request

to the server and the server responds by delivering the appropriate HTML document encapsulated

in an HTTP response.

TCP performs poor in those scenarios, since the 3-way-handshake to establish a connection and the

connection close outweigh the request and the response messages. In typical transaction scenarios,

the request messages as well as the response message fits to one packet each. A typical TCP flow

would then need 3 packets for establishing the connection, 1 packet for the request, one for the

response and 4 for the connection termination. In sum 9 packets would be needed to perform a

transaction, where just two packets are ”effective” for the transaction.

T/TCP eliminates the 3-Way-Handshake by introducing a new number called a ”connection count”

(CC), that is carried in a TCP option in each segment. T/TCP assigns monotonically increasing

CC values to successive connections that. A request packet carries the SYN and FIN bit enabled,

the connection count in an option field and the request itself in its payload. The server would then

respond with a SYN/FIN packet, acknowledging the received SYN/FIN packet and carrying the

response data of the transaction in the data field.

T/TCP is also capable of turning the 3-way-handshake bypass off for the sake of backward compati-

bility. If no connection count option is sent in the SYN packet of a TCP Connection, T/TCP reacts

like a normal TCP implementation. T/TCP was successfully implemented into the Linux Kernel

[7].

123

A.2 TCP Flavours

A.2.6 Multicast TCP

Multicast TCP [44] proposes a TCP based congestion control scheme for reliable multicast. Stan-

dard TCP implementations suffer mainly from the problem, that is introduced by the multicast tree.

A standard TCP implementation that sends data to the multicast group, considers every DUPACK,

that is generated in one of the branches of the multicast tree, as indication of congestion. Thus, TCP

reduces the congestion window to every third DUPACK, regardless which path the packet along the

multicast tree took.

To handle this problem, Multicast TCP introduces sender agents (SA) in every node of the multicast

tree from the sender to the receiver. Every SA stores the received packets in local buffer and set

a retransmission timer for every packet. When the SA receives an ACK from every receiver of the

data packet, the packet is discarded. If a packet gets lost, indicated by a negative Acknowledgement

(NACK) or a timeout, the packet is retransmitted via unicast.

To compute an appropriate congestion window, every ACK from the SA’s receivers includes a con-

gestion summary, i.e. an actual congestion level report of the receiver. The SA the computes its

own congestion level by calculating the minimum of all the current congestion level reports. This

mechanism ensures, that the congestion level, that is reported to the sender, represents the conges-

tion level at the bottleneck link. The Congestion Avoidance mechanism, that was used in Multicast

TCP, was derived from TCP Vegas. Packets, that have to be retransmitted due to loss in one of the

subtrees of the SAs, are not send with the actual congestion window, but with an additional window

called retransmission window.

As the RTT cannot be measured accurately and thus a retransmission timer cannot be calculated

by the RTT, Multicast TCP introduces the ”relative time delay (RTD)”, that is computed by the

time difference between the time of the departure of a packet at the sender and the time of arrival

of the corresponding ACK. To compute the RTO, a weighted average of the RTD is used.

In different scenarios, [44] showed, that Multicast TCP ensures the fairness between the different

receivers of the multicast group, as well as that Multicast TCP is interfair. A protocol is interfair,

if it does not take more bandwidth than a conforming TCP data flow.

124

A.2 TCP Flavours

A.2.7 Smooth-Start + Dynamic Recovery

[54] proposes two new schemes to improve the performance of TCP: Smooth-Start and Dynamic

Recovery.

Smooth-start is supposed to replace the standard slow-Start algorithm in TCP. In slow-start, the

sending rate is doubled every RTT until the slow-start threshold (ssthresh) is reached. For a good

performance, the initial value for ssthresh should be set to the maximum available bandwidth.

Since the maximum available bandwidth is unknown to TCP, there are often default values used for

ssthresh. If ssthresh is overestimated, this can result in multiple packet loss in one window.

Smooth-start resolves this problem by dividing the slow-start phase into two different, new phases.

In the first phase smooth-start acts like slow-start and increases its sending rate exponentially until

ssthresh/2 is reached. Beyond ssthresh/2, smooth-start enters the probing phase and increases

its sending rate more slowly than exponential, but still faster than in the congestion avoidance. In

the probing phase the congestion window is increment every (N + i) received ACK, where i is the

number of the subsequent RTT and N the number of RTTs it takes to reach ssthresh. Thus, N

controls how fast the desired ssthresh is reached. A high value for N would result in a very accurate

probe for ssthresh, but takes long probing times. In turn, a slow value for N takes short time to

reach ssthresh, but gives a very inaccurate probe for sstrhesh. For slow-start N would be set to 1.

In [54], a value of 2 for N is suggested.

Dynamic recovery is suggested as a replacement for the Fast Recovery Mechanism. The standard

Fast Recovery mechanism ends the recovery phase, when an ACK for the first packet, that was lost

and retransmitted, is received. Fast Recovery keeps cwnd constant during the recovery phase and

cuts the congestion window (cwnd) into half after the recovery ended, regardless how many packets

were lost. Dynamic recovery tries to take advantage of counting the number of lost packets and to

give a more accurate estimation for cwnd after a multiple packet loss. Dynamic recovery itself is

divided into two phases: the damping phase and the probing phase.

In the damping phase, the numbers of DUPACKs are counted into a state variable (dupcwnd) and

for every three DUPACKs, two new data packets are injected into the network. When a new non-

duplicate ACK is received, the damping phase ends and Dynamic Recovery enters the probing phase.

In the probing phase, the number of packets, that are in transit are counted in an new state variable

125

A.2 TCP Flavours

(actnum). In Dynamic Recovery, actnum takes the role of cwnd to determine, how many packets

can be injected into the network without running into congestion. At the end of the damping phase

actnum is initially set to dupwnd ∗ 23 , since this is the number of packets that were sent in the

damping phase. After entering the probing phase, actnum is increased by one per RTT, similar

to the Congestion Avoidance algorithm in standard TCP. For every further packet loss Dynamic

Recovery is invoked recursively. After recovering the most recently packet, Dynamic Recovery sets

cwnd to actnum, actnum to 0 and enters Congestion Avoidance.

[54] shows in their evaluation, that implementing smooth-start results in a 25%-200% higher through-

put depending on the underlying TCP Version, that smooth-start was implemented in. Even if the

initial estimate for ssthresh was very poor, smooth-start showed a good performance. Dynamic

Recovery showed a throughput improvement 33% compared to NewReno and 5-8% compared to

TCP SACK and TCP FACK discussed next.

A.2.8 TCP Pacing

As described above, TCP uses a window to determine how much data can be sent over the network

and ACKs to signal when data can be injected into the network. In the common implementations

of TCP, data, fragmented into several packets, is sent immediately after receiving an ACK, while

the sender idles after sending the packets until one RTT expires. This leads to a bursty behavior of

TCP. Even if multiple connections share a bottleneck link, the packets send from one TCP connection

remain together. In case of a bottleneck router with a drop-tail queueing strategy, one connection

would suffer from multiple packet losses and lower its sending rate dramatically while the other

connections continue sending packets at their higher sending rate.

Using a pacing scheme, the packets send over the network are spaced evenly over the RTT. Referring

to the example above, every connection should suffer from a single packet loss and adjust its sending

rate accordingly.

[2] shows, that in a single TCP scenario, the performance of a standard TCP Reno implementation

is comparable to its paced correspondent. The spaced TCP implementation performs better in the

slow-start phase, since it doesn’t overwhelm the network with too many packets but saturates the

bottleneck link. In steady state, the two implementations perform comparable.

126

A.2 TCP Flavours

In a multi-TCP scenario, paced TCP seems to show synchronization effects. Due to the spaced

packets, packets from the different connections are dropped, when the bottleneck link is overutilized,

resulting in lowering the sending rate of all connections and thus underutilizing bandwidth. With

TCP Reno implementations, one randomly chosen flow suffers from multiple losses, while the other

connections keep up sending at the higher rate. Over time every TCP connections likely suffers from

multiple losses resulting in comparable fairness at higher throughput.

In scenarios, where TCP Reno competed with paced TCP Reno for bandwidth, the paced version

showed even worse performance.

127

A.2 TCP Flavours

128

Appendix B

Hardware Specification

Aalborg, Frankfurt and Delft Tokyo and San FransicoModel CISCO 3620 CISCO 3631IOS 12.2(5d) 12.2(13)T

Table B.1: Hardware specifications of used routers

Toronto and ShanghaiModel CISCO Catalyst 2950IOS 12.1(11)EA1

Table B.2: Hardware specifications of used switches

Dhaka IstanbulModel CISCO Aironet 350 CISCO Aironet 350

Standard IEEE 802.11b IEEE 802.11bIOS 12.01T 12.01T

Mode Bridge BridgeTransmit Power 50mW 50mWFrag. Threshold 2338 2338RTS Threshold 2339 2339

Max. RTS Retries 32 32Max.Data Retries 32 32Beacon Period 100 100

Data Beacon Rate 2 2Default Radio Channel 13 (2472 MHz) 1 (2412 MHz)

SSID enabled enabledWEP Keys 128 Bit 128 Bit

Table B.3: Hardware specifications of used WLAN access point

129

ChinaModel Ericson BlipNodeRange 100m

Used Application Profile PAN

Table B.4: Hardware specifications of used PAN access point

Fixed HostCPU PentiumPro 166 MHzRAM 32 MBHDD 2GOS Redhat Linux 7.3

Kernel 2.4.18-3TCP Flavour TCP Reno + TCP SACK

Table B.5: Hardware specifications of used fixed hosts

Fixed HostCPU Pentium III 666 MHzRAM 512 MBHDD 20GOS SuSE linux 9.0

Kernel Linux linux 2.4.21-192TCP Flavour TCP Reno + TCP SACK

Table B.6: Hardware specifications of the proxy hosts

Mobile NodeCPU Pentium 4 2.66 GHzRAM 512 MBHDD 40GOS Windows XP

Kernel 2.4.166WLAN-driver supplied by vendor (2.1.1.3005)Blueooth-Stack supplied WidComm-Stack by vendor 1.4.2.10TCP Flavour TCP Reno + TCP SACK

Table B.7: Hardware specifications of Mobile Node 1

Mobile NodeCPU Pentium 4 2.88 GHzRAM 512 MBHDD 40GOS Windows XP

WLAN-driver supplied by vendor (2.1.1.3005)Blueooth-Stack supplied WidComm-Stack by vendor 1.4.2.10TCP Flavour TCP Reno + TCP SACK

Table B.8: Hardware specifications of Mobile Node 2

130

WLAN AdapterModel 3Com 3CRWE6209B

Adapter Type PCMCIA Type IIStandard IEEE 802.11b

SSID enabledWEP Key 128 Bit

Table B.9: Hardware specifications of the 3Com WLAN adapter card

Bluetooth AdapterModel Belkin FT8003

Adapter Type USBRange 10m

Standard Bluetooth v1.1Used Profile PAN

Table B.10: Hardware specifications of the Belkin Bluetooth adapter

131

132

Appendix C

Additional Related MeasurementResults

UDP / UDP Upstream UDP / UDP DownstreamΛtransm.,MN1

[ kBytes

]

Λtransm.,MN2

[ kBytes

]

Λtransm.,MN1+Λtransm.,MN2

[ kBytes

]

Λtransm.,MN1

[ kBytes

]

Λtransm.,MN2

[ kBytes

]


[ kBytes

]

Run 1 486,9 158,5 645,4 435,8 233,4 669,1Run 2 486,9 180,2 667,0 444,8 230,5 675,3Run 3 486,4 186,2 672,7 445,0 216,3 661,3Run 4 484,1 169,7 653,9 432,3 233,5 665,8Run 5 486,5 182,6 669,1 437,1 223,7 660,8Run 6 487,5 159,8 647,2 429,7 224,6 654,3Run 7 487,6 179,8 667,4 446,7 221,3 668,0Run 8 487,9 179,3 667,1 427,1 252,7 679,8Run 9 487,7 156,7 644,4 441,8 216,6 658,4Run 10 487,1 174,6 661,7 440,9 218,0 659,0Average 486,8 172,8 659,6 438,1 227,0 665,2Std.Dev 1,0 10,3 10,2 6,5 69,2 7,6

Table C.1: Throughput of two competing UDP streams over Wireless LAN

133

3 MBit UDP / TCP Upstream 3 MBit UDP / TCP DownstreamΛtransm.,UDP

[ kBytes

]

Λtransm.,TCP

[ kBytes

]


[ kBytes

]

Λtransm.,UDP

[ kBytes

]

Λtransm.,TCP

[ kBytes

]


[ kBytes

]

Run 1 157,6 454,6 612,2 118,7 537,3 655,9Run 2 156,6 387,6 544,2 112,1 537,8 649,9Run 3 149,5 391,2 540,8 109,5 545,8 655,4Run 4 151,4 431,4 582,8 117,1 535,9 653,0Run 5 159,8 475,5 635,4 112,7 531,3 644,1Run 6 143,2 369,6 512,7 118,0 542,3 660,3Run 7 151,2 445,0 596,3 116,3 534,7 650,9Run 8 142,4 378,2 520,5 113,6 535,8 649,4Run 9 145,7 422,2 567,9 114,6 528,1 642,7Run 10 144,3 448,2 592,5 107,7 538,2 645,9Average 150,2 420,3 570,5 114,0 536,7 650,7Std.Dev. 6,0 34,7 40,6 3,4 4,8 5,3

Table C.2: Throughput of a TCP stream competing with a 3 MBit UDP stream over Wireless LAN

TCP / TCP Upstream TCP / TCP DownstreamΛtransm.,MN1

[Bytess

]

Λtransm.,MN2

[Bytess

]


[Bytess

]

Λtransm.,MN1

[Bytess

]

Λtransm.,MN2

[Bytess

]


[Bytess

]


Table C.3: Throughput of a two competing TCP streams over Wireless LAN

134

1 MBit Burst UDP / TCP Upstream 1 MBit Burst UDP / TCP DownstreamΛtransm.,TCP

[ kBytes

]

Λtransm.,UDP

[ kBytes

]

Λtransm.,TCP +Λtransm.,UDP

[ kBytes

]

Λtransm.,TCP

[ kBytes

]

Λtransm.,UDP

[ kBytes

]

Λtransm.,TCP +Λtransm.,UDP

[ kBytes

]


Table C.4: Throughput of a TCP streams competing with 1 MBit burst UDP stream over WirelessLAN

Λtransm. Upstream [ kBytes

] Λtransm. Downstream [ kBytes

]

Run 1 51,4 59,3Run 2 50,5 58,5Run 3 51,4 58,4Run 4 51,5 59,6Run 5 50,8 59,1Run 6 53,2 58,9Run 7 51,8 59,0Run 8 52,0 59,3Run 9 50,7 59,0Run 10 50,7 58,6Average 51,4 59,0Std.Dev. 0,8 0,4

Table C.5: Transmission Throughput of a TCP streams over a Bluetooth link using an access point

135

136

Appendix D

Performance Test Tools

The next appendix chapter covers a list of the used evaluation tools and its description as it currenlty

appears on its website.

D.1 IPerf

While tools to measure network performance, such as ttcp, exist, most are very old and have confus-

ing options. Iperf was developed as a modern alternative for measuring TCP and UDP bandwidth

performance.

Iperf is a tool to measure maximum TCP bandwidth, allowing the tuning of various parameters and

UDP characteristics. Iperf reports bandwidth, delay jitter, datagram loss.

D.2 Ethereal

Ethereal is a GUI network protocol analyzer. It lets you interactively browse packet data from a

live network or from a previously saved capture file. Ethereal’s native capture file format is libpcap

format, which is also the format used by tcpdump and various other tools. In addition, Ethereal

can read capture files from snoop and atmsnoop, Shomiti/Finisar Surveyor, Novell LANalyzer, Net-

work General/Network Associates DOS-based Sniffer (compressed or uncompressed), Microsoft Net-

work Monitor, AIX’s iptrace, Cinco Networks NetXRay, Network Associates Windows-based Sniffer,

AG Group/WildPackets EtherPeek/TokenPeek/AiroPeek, RADCOM’s WAN/LAN analyzer, Lu-

cent/Ascend router debug output, HP-UX’s nettl, the dump output from Toshiba’s ISDN routers,

137

D.3 tcptrace

the output from i4btrace from the ISDN4BSD project, the output in IPLog format from the Cisco

Secure Intrusion Detection System, pppd logs (pppdump format), the output from VMS’s TCPIP-

trace/TCPtrace/UCX$TRACE utilities, the text output from the DBS Etherwatch VMS utility,

traffic capture files from Visual Networks’ Visual UpTime, the output from CoSine L2 debug, and

the output from Accellent’s 5Views LAN agents. There is no need to tell Ethereal what type of file

you are reading; it will determine the file type by itself. Ethereal is also capable of reading any of

these file formats if they are compressed using gzip. Ethereal recognizes this directly from the file;

the ’.gz’ extension is not required for this purpose.

Like other protocol analyzers, Ethereal’s main window shows 3 views of a packet. It shows a sum-

mary line, briefly describing what the packet is. A protocol tree is shown, allowing you to drill down

to exact protocol or field that you interested in. Finally, a hex dump shows you exactly what the

packet looks like when it goes over the wire.

In addition, Ethereal has some features that make it unique. It can assemble all the packets in a

TCP conversation and show you the ASCII (or EBCDIC, or hex) data in that conversation. Display

filters in Ethereal are very powerful; more fields are filterable in Ethereal than in other protocol

analyzers, and the syntax you can use to create your filters is richer. As Ethereal progresses, expect

more and more protocol fields to be allowed in display filters.

Packet capturing is performed with the pcap library. The capture filter syntax follows the rules of

the pcap library. This syntax is different from the display filter syntax.

Compressed file support uses (and therefore requires) the zlib library. If the zlib library is not

present, Ethereal will compile, but will be unable to read compressed files.

The pathname of a capture file to be read can be specified with the -r option or can be specified as

a command-line argument.

D.3 tcptrace

tcptrace is a tool written by Shawn Ostermann at Ohio University, for analysis of TCP dump files. It

can take as input the files produced by several popular packet-capture programs, including tcpdump,

snoop, etherpeek, HP Net Metrix, and WinDump. tcptrace can produce several different types of

138

D.4 UDPBurst

output containing information on each connection seen, such as elapsed time, bytes and segments

sent and recieved, retransmissions, round trip times, window advertisements, throughput, and more.

It can also produce a number of graphs for further analysis.

D.4 UDPBurst

UDPBurst is a self written UDP packet genarator that is compatible to IPerf. It allows to send

bursty UDP streams in an ON/OFF traffic model. Data is sent at a constant bandwidth in an

ON period and afterwards idles for an OFF-period. The ON and OFF period are exponentially

distributed and its mean value can be specified by command line parameters.

139

D.4 UDPBurst

140

Bibliography

[1] ANSI/IEEE Std. 802.11. Wireless LAN Medium Access Control (MAC) and Physical Layer

(PHY) Specifications, 1999.

[2] Amit Aggarwal, Stefan Savage, and Thomas Anderson. Understanding the performance of TCP

pacing. In INFOCOM (3), pages 1157–1165, 2000.

[3] Jong Suk Ahn, Peter B. Danzig, Zhen Liu, and Limin Yan. Evaluation of TCP vegas: Emulation

and experiment. In SIGCOMM, pages 185–205, 1995.

[4] Ajay Bakre and B. R. Badrinath. I-TCP: Indirect TCP for mobile hosts. 15th International

Conference on Distributed Computing Systems, 1994.

[5] Hari Balakrishnan, Srinivasan Seshan, and Randy H. Katz. Improving reliable transport and

handoff performance in cellular wireless networks. ACM Wireless Networks, 1(4), 1995.

[6] Rajesh Krishna Balan, Lee Boon Peng, K. Renjish Kumar, Lillykutty Jacob, Winston K. G.

Seah, and A. L. Ananda. TCP HACK: TCP header checksum option to improve performance

over lossy links. In INFOCOM 2001, April 2001.

[7] Ren Bin and Zhang Xiaolan. Implementation of Transaction TCP in Linux Kernel 2.4.2. Tech-

nical report, Department of Electronic Engineering, School of Electronics and Information Tech-

nology, Shanghai Jiaotong University.

[8] J. Border, M. Kojo, J. Griner, G. Montenegro, and Z. Shelby. Performance Enhancing Proxies

Intended to Mitigate Link-Related Degradations. IETF, RFC 3135, June 2001.

[9] R. Braden. T/TCP – TCP extensions for transactions, functional specification. IETF, RFC

1644, July 1994.

[10] R. Braden. Extending TCP for transactions – concepts. IETF, RFC 1379, November 1992.

141

BIBLIOGRAPHY

[11] R. Braden. Requirements for Internet Hosts – Communication Layers. IETF, RFC 1122,

October 1989.

[12] Lawrence S. Brakmo, Sean W. OMalley, and Larry L. Peterson. TCP Vegas: New Techniques

for Congestion Detection and Avoidance. Technical report, Department of Computer Science,

University of Arizona, 1994.

[13] Kevin Brown and Suresh Singh. M-TCP: TCP for mobile cellular networks. ACM Computer

Communication Review, 27(5), 1997.

[14] C. Perkins. IP Encapsulation within IP. IETF, RFC 2003, October 1996.

[15] C. Perkins. Minimal Encapsulation within IP. IETF, RFC 2004, October 1996.

[16] J. Noel Chiappa. Soft and Hard State. Webpage http://users.exis.net/˜jnc/tech/hard soft.html.

[17] Cisco. Cisco IOS Quality of Service Solutions Configuration Guide,

http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products configuration guide chapter09186a00800c75d2.html,

April 2004.

[18] Cisco. Cisco IOS Quality of Service Solutions Configuration Guide,

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos c/fqcprt1/qcfclass.pdf,

April 2004.

[19] T. Dierks and C. Allen. The TLS Protocol Version 1.0. IETF, RFC 2131, Jan. 1999.

[20] R. Droms. Dynamic Host Configuration Protocol. IETF, RFC 2131, March 1997.

[21] Gerald Combs et al. Ethereal 10.0, Feb 2004.

[22] Julian Faraway. Practical Regression and Anova using R. July 2002.

[23] R. Finlayson, T. Mann, J.C. Mogul, and M. Theimer. Reverse Address Resolution Protocol.

IETF, RFC 903, June 1984.

[24] S. Floyd. The NewReno Modification to TCP’s Fast Recovery Algorithm. RFC 2582, 1999.

[25] Tom Goff, James Moronski, Dhananjay S. Phatak, and Vipul Gupta. Freeze-TCP: A true

end-to-end TCP enhancement mechanism for mobile environments. In INFOCOM (3), pages

1537–1545, 2000.

142

BIBLIOGRAPHY

[26] V. Jacobson. Congestion avoidance and control. ACM Computer Communication Review;

Proceedings of the Sigcomm ’88 Symposium in Stanford, CA, August, 1988, 18, 4:314–329,

1988.

[27] V. Jacobson and R. Braden. TCP extensions for long-delay paths. IETF, RFC 1072, October

1988.

[28] S. Kent and R. Atkinson. Security Architecture for the Internet Protocol. IETF, RFC 2401,

Nov. 1998.

[29] Soo-Hyeong Lee, Byung G. Kim, and Yanghee Choi. Improving the Fairness and the Response

Time of TCP Vegas. Technical report, Department of Computer Science and Engineering, Seoul

National University.

[30] Soo-Hyeong Lee, Byung G. Kim, and Yanghee Choi. TCP Vegas Slow-Start Performance in

Large Bandwidth Delay Networks. Technical report, Department of Computer Science and

Engineering, Seoul National University.

[31] M. Krunz and S.K. Tripathi. On the Characteristics of VBR MPEG Streams. In ACM SIG-

METRICS, pages 192–202.

[32] G. Malkin. RIP Version 2 – Carrying Additional Information. IETF, RFC 1723, November

1994.

[33] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow. TCP selective acknowledgment options.

IETF, RFC 2018, October 1996.

[34] Matthew Mathis and Jamshid Mahdavi. Forward acknowledgement: Refining TCP congestion

control. In SIGCOMM, pages 281–291, 1996.

[35] J.C. Mogul and S.E. Deering. Path MTU Discovery. IETF, RFC 1191, Nov. 1990.

[36] J. Moy. OSPF version 2. IETF, RFC 1247, July 1991.

[37] Helsinki University of Technology. Dynamics mobile ip. Webpage

http://dynamics.sourceforge.net.

[38] C. Perkins. IP Mobility Support for IPv4. IETF, RFC 3344, August 2002.

[39] D.C. Plummer. Ethernet Address Resolution Protocol: Or converting network protocol ad-

dresses to 48.bit Ethernet address for transmission on Ethernet hardware. IETF, RFC 826,

Nov 1982.

143

BIBLIOGRAPHY

[40] Jon Postel. Internet protocol. IETF, RFC 791, September 1981.

[41] Jon Postel. Transmission control protocol. IETF, RFC 793, September 1981.

[42] GNU public license. GNUplot 3.8k, Feb 2004.

[43] Y. Rekhter and P. Gross. A Border Gateway Protocol 4 (BGP-4). IETF, RFC 1771, March

1995.

[44] Injong Rhee, Nallathambi Ballaguru, and George N. Rouskas. MTCP: Scalable TCP-like con-

gestion control for reliable multicast. Technical Report TR-98-01, 2, 1998.

[45] Hans-Peter Schwefel. Modeling of Packet Arrivals Using Markov Modulated Poisson Processes

with Power-Tail Bursts. Master’s thesis, Technical University Munich, Aug 1997.

[46] Bluetooth SIG. Bluetooth Specification v1.1, Feb. 2001.

[47] W. Stevens. TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery

Algorithms. IETF, RFC 2001, January 1997.

[48] Inc. The MathWorks. MatLab 6.5, Online Help, June 2002.

[49] Ajay Tirumala, Feng Qin, Jon Dugan, Jim Ferguson, and Kevin Gibbs. Iperf 1.7.0, March 2003.

[50] Sarma Vangala and Miguel A. Labrador. Performance of TCP over Wireless Networks with the

Snoop Protocol. Technical report, Department of Computer Science and Engineering, University

of South Florida, Tampa.

[51] Sarma Vangala and Miguel A. Labrador. The TCP SACK-Aware Snoop Protocol for TCP

over Wireless Networks. Technical report, Department of Computer Science and Engineering,

University of South Florida.

[52] W. N. Venables, D. M. Smith, and the R Development Core Team. Introduction to R. Nov

2003.

[53] J. Waldby, Upamanyu Madhow, and T. V. Lakshman. Total acknowledgements: A robust

feedback mechanism for end-to-end congestion control (extended abstract). In Measurement

and Modeling of Computer Systems, pages 274–275, 1998.

[54] H. Wang and Carey L. Williamson. A new scheme for TCP congestion control: Smooth-start

and dynamic recovery. In MASCOTS, pages 69–76, 1998.

144

BIBLIOGRAPHY

[55] Raj Yavatkar and Namrata Bhagawat. Improving end-to-end performance of tcp over mobile

internetworks. In IEEE Workshop on Mobile Computing Systems and Applications, Dec. 1994.

145

Documents

IMPLEMENTATION AND EVALUATION OF A PERFORMANCE ENHANCING ...kom.aau.dk/group/03gr996/documentation/master_thesis_aau.pdf · implementation and evaluation of a performance enhancing