Implementation and Evaluation of a
Performance Enhancing Proxy for Wireless
TCP
Master Thesis Project (Sep 03 – April 04)
Dennis Dungs
Technical University Munich, Germany
Aalborg University, Denmark
Januar 2004 modified March 04
Supervised by
Hans-Peter Schwefel
Aalborg University, Denmark
Slide 1
Overview
Goal of Master Project
– Identify TCP performance lacks in wireless scenarios
– Evaluate performance improvements using a TCP Proxy
• 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
Slide 2
Experimental Evaluation
Slide 3
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 4
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 5
Evaluation - Metrics
• Instantaneous Throughput
payloadsiz en
 Inst (n) 
t n  t n 1
• Instantaneous Averaged Throughput
nk
 Inst, Avg (i ) 
 payloadsiz e
l
l  n 1
tnk  tn
, n  k * (i - 1), k const.
• Transmission Throughput
n
 transmission (n) 
 payloadsiz e
i
i 1
t n  t1
• Round-Trip-Times (RTT)
Slide 6
WLAN 802.11b Evaluation
Slide 7
802.11 Evaluation: Setup
Server
Shanghai
Legend:
Frankfurt
10.10.2.254
Router
8 MBit/s
8 MBit/s
Aalborg
Tokyo
Delft
100 MBit/s
Toronto
Switch
100 MBit/s
WLAN Access Point
Shanghai
Toronto
Fixed Host
100 MBit/s
100 MBit/s
Dhaka
Istanbul
Mobile Node 1
Slide 8
Mobile Host
Evaluation - General Eval on WLAN
Slide 9
Evaluation - General Eval on WLAN
Slide 10
Evaluation - General Eval on WLAN
Slide 11
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 12
Evaluation – BERs in WLAN
Legend:
Room 4
Position #4
WLAN Access Point
Mobile Host
Room 3
Room 2
Room 1
Position #1
Position #3
Position #2
Slide 13
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 14
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 15
Evaluation – Handovers in WLAN
Server
Shanghai
Legend:
Frankfurt
10.10.2.254
Router
8 MBit/s
8 MBit/s
Aalborg
Home Agent
Tokyo
Delft
100 MBit/s
100 MBit/s
Toronto
Switch
Foreign Agent
WLAN Access Point
Shanghai
10.10.3.254
100 MBit/s
Toronto
100 MBit/s
Dhaka
Istanbul
10.10.1.X
10.10.3.X
Mobile Node 1
Slide 16
10.10.3.254
Fixed Host
Mobile Host
Evaluation – Handovers in WLAN
Slide 17
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 18
Bluetooth Evaluation
Slide 19
Single Connection over Bluetooth - Scenario
• Scenario Parameters:
Network Setup:
Aalborg
– 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
8 MBit/s
8 MBit/s
Tokyo
100 MBit/s
Delft
100 MBit/s
Shanghai
Toronto
100 MBit/s
100 MBit/s
Server
China
10.10.3.254
Downstream
10.10.1.X
Mobile Node
Legend:
Router
Switch
BT AP
Fixed Host
Mobile Host
Slide 20
Single UDP Connection over Bluetooth
Slide 21
Single UDP Connection over Bluetooth
Slide 22
Single TCP Connection over Bluetooth
Slide 23
Single TCP Connection over Bluetooth
Slide 24
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 25
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 (BlueZStack)
Slide 26
Conclusions: Bluetooth
• Conclusion:
– Many factors could cause the throughputdropdown
– Difficult to analyze TCP performance lacks, if
underlying behaviour unclear
– To get deeper understandings, packet trace
tool for Baseband is needed
Slide 27
TCP Proxy: Implementation and Evaluation
Slide 28
Considered Scenarios
•
Definition:
„A Scenario consists of a description of the network infrastructure, mobility model and
traffic model.“
•
Network Infrastructure:
–
–
–
–
•
Access Technology
Proxy Location
Sender / Receiver Location
Network configuration
Wireless
supporting
Network
Wired
Network
Proxy
Mobility Model
– Fixed position
– Handover to same/different subnet
– Handover to new access technology
•
Server
Traffic Model
–
–
–
–
–
Size of transmitted data
Used bandwith
Single-/Multi-User
Cross-traffic
Constant / Burst Traffic
Mobile
Host
Slide 29
Implementation of TCP Proxy - Idea
Split TCP Idea:
Sender
TCP Proxy
Receiver
Application
Split TCP-Daemon
Application
TCP
TCP
TCP
TCP
IP
IP
IP
IP
LL / PHY
LL / PHY
LL / PHY
LL / PHY
Slide 30
Implementation of TCP Proxy – Software Architecture
Split TCP daemon
Connection
Connection
Connection
establish connection
close connection
Send data
Connection
Connection
Connection
Send data
Data buffer
Process packet
Create packet(s)
(Mirror)
Packet-buffer
Packet-buffer
decode
encode
NIC
NIC
Slide 31
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 32
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 33
Implementation of TCP Proxy – Network setup
Legend:
Proxy
Router
10.10.254.254
100 MBit/s
Aalborg
Toronto
8 MBit/s
8 MBit/s
Tokyo
Switch
Delft
WLAN Access Point
100 MBit/s
Spjald
10.10.4.X
100 MBit/s
Fixed Host
Toronto
100 MBit/s
Mobile Host
Server
Mobile Node
San 10.10.1.254
Francisco
Slide 34
Policy-Based
Routing applied
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 35
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 36
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 37
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 38
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 39
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 40
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 41
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: dennis@kom.auc.dk
Slide 42
Thanks for listening!
Any Questions?
Slide 43
Backup
Slide 44
Current
IPLab
network
architecture
IP LAB:
Current
Architecture
Spjald
10.10.3.254
10.10.4.2
10.10.254.254
Shanghai
10.10.3.1
Toronto
Aalborg
Internet
San Francisco
130.225.51.6
Delft
GPRS
Network
Tokyo
Frankfurt
10.10.2.1
10.10.1.1
Toronto
Shanghai
10.10.2.254
10.10.2.2
10.10.1.254
10.10.1.2
Sydney
Dhaka
Slide 45