Slide 1 Implementation and Evaluation of a Performance Enhancing Proxy for Wireless TCP Master Thesis Project (Sep 03 – April 04) Dennis Dungs Technical.

Slide 1

Implementation and Evaluation of a Performance Enhancing Proxy for Wireless

TCP

Master Thesis Project (Sep 03 – April 04)

Dennis DungsTechnical University Munich, Germany

Aalborg University, Denmark

Januar 2004 modified March 04

Supervised byHans-Peter Schwefel

Aalborg University, Denmark

Slide 2

Overview

• Performance evaluation of wireless access technologies– WLAN 802.11b

• General Eval• Influence of High Bit Error Rates• Influence of Cross-Traffic (missing)• Influence of Handovers

– Bluetooth• UDP and TCP throughput

• TCP Proxy– Implementation

• Network setup• Proxy design

– Proxy Eval• Influence on RTT & Throughput

Goal of Master Project– Identify TCP performance lacks in wireless scenarios– Evaluate performance improvements using a TCP Proxy

Slide 3

Experimental Evaluation

Slide 4

Evaluation - Parameters

• Throughput over time

• Round-Trip-Times (RTT)– Average– Jitter

• Transmission time

• Nr. of packets

• Nr. of retransmitted bytes

• Nr. of timeouts– Transmission timeouts

Slide 5

Evaluation – Measurement Procedure

• IPerf – Setup a UDP/TCP connection from sender to receiver– Send data from sender to receiver at maximum bandwidth (TCP)

or given bandwidth (UDP)

• Ethereal – Trace Ethernet packets at sender and receiver in real-time into a

file– Traces arrival times of packets t(n) and contents of Ethernet

packets

• TCPTrace– Generate TCP Statistics offline

• Matlab– Generating UDP Statistics offline– Calculating statistical parameters

• GNUPlot– Visualizing TCP Statistics (RTT Graphs, Throughput Graphs)

Slide 6

Evaluation - Metrics

• Instantaneous Throughput

• Instantaneous Averaged Throughput

• Transmission Throughput

• Round-Trip-Times (RTT)

const.k 1),-(i*k n ,)( 1,

nkn

kn

nll

AvgInst tt

epayloadsizi

1

1)(tt

epayloadsizn

n

n

ii

ontransmissi

1

)(

nn

nInst tt

epayloadsizn

Slide 7

WLAN 802.11b Evaluation

Slide 8

802.11 Evaluation: Setup

Tokyo Delft

Legend:

Aalborg

Fixed Host

Mobile HostDhaka

Router

Mobile Node 1

Toronto

TorontoSwitch

WLAN Access Point

8 MBit/s 8 MBit/s

100 MBit/s100 MBit/s

100 MBit/s

Shanghai

100 MBit/s

Istanbul

Frankfurt

Server

10.10.2.254Shanghai

Slide 9

Evaluation - General Eval on WLAN

Slide 10

Evaluation - General Eval on WLAN

Slide 11

Evaluation - General Eval on WLAN

Slide 12

Evaluation - General Eval on WLAN

• Observations:– TCP downstream reaches 720 kByte/s,

downstream 650 kByte/s– TCP degrades throughput by 16% compared

to UDP– RTTs in upstream vary wide, vary less in

downstream– Most influences in upstream result from

strange behaviour of 3COM card

Slide 13

Evaluation – BERs in WLAN

Room 4

Room 3

Room 2

Room 1 Position #1

Position #2

Position #3

Position #4

Legend:

Mobile Host

WLAN Access Point

Slide 14

Evaluation – BERs in WLAN

Measurement Options:•AP transmission power: 30mW•MN transmission power 50mW•Transmission time: 10s•Proxy turned off•RTS/CTS off•WEP enabled

Slide 15

Evaluation - BERs in WLAN

• Observations:– NIC reported good signal strength and quality in 1,2,3

and poor signal strength and quality in 4– Position 1,2 and 3 gain same throughput– Only Position 4 suffers from bad channel quality and

high BER– No TCP retransmissions observed in all 4 cases– Same behaviour in upstream case– ARQ used by WLAN efficient mechanism to hide

BERs from TCP– IP layer provides reliable, but less performant

datagram service in bad channel condition situations– TCP can adopt very accurate to those conditions

Slide 16

Evaluation – Handovers in WLAN

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

Slide 17

Evaluation – Handovers in WLAN

Slide 18

Evaluation – Handovers in WLAN

• Observations:– TCP connection restarts after 29s, although

receiver available after 16s.– 11s of handover time due to problems in

DHCP– 5s for signaling MIP and IP-Tunnel setup.– TCP performs poor due to exponential backoff– 10 runs showed same performance

Slide 19

Bluetooth Evaluation

Slide 20

Single Connection over Bluetooth - Scenario

10.10.1.X

Tokyo DelftAalborg

China

Mobile Node

Toronto

Server

10.10.3.254

8 MBit/s 8 MBit/s

100 MBit/s

100 MBit/s100 MBit/s

Shanghai

100 MBit/s

Fixed Host Mobile HostRouter Switch BT AP

Legend:

Network Setup: • Scenario Parameters:– MN: 2.6 GHz-P4 512MB

RAM, WinXP, Belkin Class2 BT USB Adapter

– AP: BlipNet BlipNode L1– Supposed Master: AP– Supposed Slave: Mobile Node– Application Profile: PAN– Distance AP->MN: 1m– Server: PPro 166Mhz, 32MB

RAM, running Redhat 7.3– Sending duration: 30sec– UDP payloadsize: 1470 bytes– UDP Bandwidth: 700kBit/s

(Application Layer Bandwidth)– TCP receiver buffer: 8 kBytes

Downstream

Slide 21

Single UDP Connection over Bluetooth

Slide 22

Single UDP Connection over Bluetooth

Slide 23

Single TCP Connection over Bluetooth

Slide 24

Single TCP Connection over Bluetooth

Slide 25

Single TCP Connection over Bluetooth

• Possible Reasons for throughput jumps– Traffic in low-bandwidth direction

• Packet Scheduler has to send more data• Adjusting to „more symmetric“ bandwidth• Flow Control on Baseband

– Interference• Channel quality driven data rate change (CQDDR)

Slide 26

Additional Results

• Transmission Throughput always dependant on time of throughput jumps

• Adhoc – Scenario:– Same throughput jumps (UDP & TCP) as in

AP-scenario, but less likely– Higher average throughput

• No significant differences between WinXP (WidComm-Stack) and Linux (BlueZ-Stack)

Slide 27

Conclusions: Bluetooth

• Conclusion:– Many factors could cause the throughput-

dropdown– Difficult to analyze TCP performance lacks, if

underlying behaviour unclear– To get deeper understandings, packet trace

tool for Baseband is needed

Slide 28

TCP Proxy: Implementation and Evaluation

Slide 29

Considered Scenarios

• Definition:„A Scenario consists of a description of the network infrastructure, mobility model and traffic model.“

Proxy

Server

Wired Network

MobileHost

Wirelesssupporting Network

• Network Infrastructure:– Access Technology– Proxy Location– Sender / Receiver Location– Network configuration

• Mobility Model– Fixed position– Handover to same/different subnet– Handover to new access technology

• Traffic Model– Size of transmitted data– Used bandwith– Single-/Multi-User– Cross-traffic– Constant / Burst Traffic

Slide 30

Implementation of TCP Proxy - Idea

Application

Split TCP Idea:

Sender Receiver

Split TCP-Daemon

TCP

IP

LL / PHY

Application

TCP

IP

LL / PHY

TCP

IP

LL / PHY

TCP

IP

LL / PHY

TCP Proxy

Slide 31

Implementation of TCP Proxy – Software Architecture

NIC

Packet-buffer

NIC

Packet-buffer

decode encode

ConnectionConnection

ConnectionConnection

Connection ConnectionSend data

establish connection

close connection

Process packet Create packet(s)

Send data

Data buffer

(Mirror)

Split TCP daemon

Slide 32

Implementation of TCP Proxy – Current Features

• Mirroring• Split TCP:

– TCP Reno implementation– Slow start– Congestion avoidance– Retransmission timer (partially)– Fast retransmission– Delayed ACKs– Adjustable Maximum Segment Size– Adjustable data buffer– Asymetrical TCP setup

Slide 33

Implementation of TCP Proxy - Options

• IP-Header-Option-Solution– Add original IP-Destination-Adress to IP-Header Option– Send every IP packet to Proxy– Unpack IP-packets at Proxy and start a „normal“ TCP/IP-Connection– Disadvantage: Changes in TCP/IP-Stack of connection initiator necssary

• IP-Tunneling– Tunnel the IP-packets from connection initiator to Proxy– Unpack IP-packets at Proxy and start a „normal“ TCP/IP-Connection– Disadvantage: additional IP-Overhead

• Hardware - Solution– Proxy directly integrated in Sender-Receiver-Path– Disadvantage: Different Scenarios need different locations of proxy ->

Maintainance efforts

• ARP – Solution– „emulate“ IP Adresses by faking IP-MAC-Maps– Disadvantage: Difficult to maintain maps– Disadvantage: Timing problems

• Routing-Solution

Slide 34

Implementation of TCP Proxy – Network setup

10.10.4.X

Tokyo Delft

Legend:Proxy

Aalborg

Fixed Host

Mobile Host

Spjald

Router

10.10.254.254

Mobile Node San Francisco

Toronto

Server

10.10.1.254

TorontoSwitch

WLAN Access Point

8 MBit/s 8 MBit/s

100 MBit/s100 MBit/s

100 MBit/s

100 MBit/s

Policy-Based Routing applied

Slide 35

Evaluation – RTTs in WLAN

• Comparison of RTTs in WLAN– AP transmission power: 30 mW– Distance to AP: 20 cm– Transmission period: 10 s– TCP Proxy configuration:

• Delayed ACKs off• No Buffer Thresholding• MSS: 1460 Bytes

Samples Average Max Min Std. Dev.

No Proxy 2494 16 ms 57 ms 3 ms 3 ms

Mirror 2500 21 ms 60 ms 3 ms 5 ms

Split TCP Proxy

4455 22 ms 70 ms 3 ms 5 ms

Slide 36

Evaluation – Delayed ACKs in WLAN

Measurement Options:•AP transmission power: 30mW•Distance to AP: 20cm•Transmission amount: 30MB•Symmetrical TCP setup

•Delay Timer: 500ms•MSS: 1460 bytes•No Buffer Thresholding

Slide 37

Evaluation – Delayed ACKs in WLAN

• Observations:– Higher number of delayed ACKs leads to

higher performance– Drawback: Higher number of delayed ACKs

lead to a slow slow-start, since in first RTT, some retransmissions are needed to trigger one ACK

– Linux/Windows do not delay first ACK in a connection to avoid this behaviour

Slide 38

Evaluation – Delay ACK timer in WLAN

Measurement Options:•AP transmission power: 30mW•Distance to AP: 20cm•Transmission amount: 30MB•Symmetrical TCP setup:

•Delayed ACKs: 3•MSS: 1460 bytes•No Buffer Thresholding

Slide 39

Evaluation – Delay ACK timer in WLAN

• Observations:– The shorter the DelayACK timer, the faster

the connection reaches steady state– The shorter the DelayACK timer, the higher

the probability to send an ACK without necessity

– 50ms timer seems to be the best tradeoff between fast connection setup and low probability of unnecesarily sending ACKs in 10s connections.

Slide 40

Future Outline

• Implementation:– Coupling TCP-Proxy and MIP Mobility Support– FreezeTCP

• Freeze Sender by advertising a zero Window• Recover sender by:

– 3 Duplicate ACKs (slow-start)– 1 Non-Zero Window ACK (fast recovery)

• Evaluation:– Impact of Buffer-Thresholding– Multi-User/Bursty Cross Traffic in WLAN Scenarios– GPRS– Bluetooth– [W-CDMA]– MobileIP / Handover Scenarios

Slide 41

Current Problems

• Ethereal not working with PPP in Windows NT/2000/XP (-> BT LAN, GPRS)

• No globally routable IP-Address available in GPRS• MobileIP-Setup over GPRS• No W-CDMA Equipment available• Bugs,....

Slide 42

References

• Project WebSite: http://kom.auc.dk/~dennis/

• IPLab WebSite:

http://kom.auc.dk/iplab/

• WLAN Evaluation Project:

http://kom.auc.dk/~ruipt/

• RFCs : RFC791 (IP), RFC793 (TCP)

• eMail: [email protected]

Slide 43

Thanks for listening!

Any Questions?

Slide 44

Backup

Slide 45

Current IPLab network architectureIP LAB: Current Architecture

Delft

Internet

Toronto

Frankfurt

Shanghai

Sydney Dhaka

Tokyo

San Francisco 130.225.51.6

10.10.1.210.10.2.2

10.10.2.1 10.10.1.1

Aalborg

10.10.2.254

Spjald10.10.4.2

10.10.1.254

Shanghai

10.10.3.254

10.10.254.254

Toronto10.10.3.1

GPRS Network