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
Final Presentation - April 04
Supervised by
Hans-Peter Schwefel
Aalborg University, Denmark
Slide 1
Overview
•
•
Motivation of Master Project
Scenarios
– Network Architecture
– Traffic Model
– Mobility Model
•
Evaluation Method
– Metrics
– Measurement Procedure
•
TCP performance evaluation of wireless access technologies
– WLAN 802.11b
•
•
•
•
General Eval
Influence of High Bit Error Rates
Influence of Cross-Traffic
Influence of Handovers
– Bluetooth
• UDP and TCP throughput
•
TCP Proxy
– Implementation
• Proxy design
• Network setup
– Proxy Eval
• Influence on RTT & Throughput
•
Conclusion
Slide 2
Motivation
Motivation:
• TCP performs good in wired scenarios
• Two assumptions in wired TCPs:
– No disconnections
– Bit Error Rate (BER) very low
 Packets are only dropped in case of congestion
•
Wireless links do not follow these assumptions:
– Disconnections due to handovers
– High BER
•
TCP Proxies are a known concept to overcome those problems
Can a TCP Proxy enhance TCPs performance over a IEEE 802.11b
(WLAN) or a Bluetooth link?
 Goals:
• Identify TCP performance lacks in different wireless scenarios in an
experimental network
• Implement TCP Proxy
– Network Integration
– Software Design & Implementation
•
Evaluate TCP Proxy based on TCP performance lacks
Slide 3
Scenarios
Slide 4
Scenarios and Limitations
•
Network Architecture
–
–
–
–
•
Mobility Model
–
–
–
–
•
Access Technology of mobile node: WLAN (IEEE 802.11b) and Bluetooth
Number of hops: Last single wireless hop
Link Layer types of intermediary links: FastEthernet and 8 MBit/s Serial Link
Proxy Location: fixed Proxy location
Fixed Position
Handover to same subnet
Handover to different subnet (considered)
Handover to different access technology
Traffic Model
–
–
–
–
–
–
–
Type of Transport Layer Protocol
Size of transmitted data / transmission duration
Number of simultaneous connections
Unidirectional / Biderectional
Constant packet rate / packet burst
Bandwidth
Limited to:
• Unidirectional TCP stream
• Unidirectional, constant packet rate UDP stream
• Unidirectional bursty ON/OFF stream
Slide 5
Evaluation Method
Slide 6
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 7
Evaluation - Metrics
• Instantaneous Throughput
payloadsiz en
 Inst (n) 
t n  t n 1
• Instantaneous Averaged Throughput
nk
 Avgerage(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)
Nr. of packets
Nr. of retransmitted bytes
Nr. of retransmission timeouts
Slide 8
WLAN 802.11b Evaluation
Slide 9
Evaluation - General Eval on WLAN 802.11b
Legend:
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
Server
Dhaka
Downstream
10.10.3.254
Mobile Node 1
Slide 10
Mobile Host
Evaluation - General Eval on WLAN 802.11b
Slide 11
Evaluation - General Eval on WLAN 802.11b
Slide 12
Evaluation - General Eval on WLAN 802.11b
Slide 13
Evaluation - General Eval on WLAN 802.11b
• Observations:
– TCP downstream reaches 720 kByte/s,
upstream 650 kByte/s
– TCP degrades throughput by 16% compared
to UDP (downstream)
– RTTs in upstream vary wide, vary less in
downstream
– Most influences in upstream result from
strange behaviour of 3COM WLAN card
Slide 14
Evaluation – BERs in WLAN 802.11b
Legend:
Room 4
Position #4
WLAN Access Point
Mobile Host
Room 3
Room 2
Room 1
Position #1
Position #3
Position #2
Slide 15
Evaluation – BERs in WLAN 802.11b
Measurement Options:
•AP transmission power: 30mW
•MN transmission power 50mW
•Transmission time: 10s
•Proxy turned off
•RTS/CTS off
•WEP enabled
Slide 16
Evaluation - BERs in WLAN 802.11b
• 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 comparable 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 17
Evaluation – Crosstraffic in WLAN 802.11b
Legend:
Crosstraffic
Connection
Router
8 MBit/s
8 MBit/s
Aalborg
100 MBit/s
Toronto
Tokyo
Delft
TCP
Connection
100 MBit/s
Shanghai
Switch
WLAN Access Point
Fixed Host
Toronto
100 MBit/s
100 MBit/s
Server
Dhaka
San 10.10.3.254
Francisco
10.10.1.X
Mobile Node 2
Mobile Node 1
Slide 18
Mobile Host
Evaluation – Crosstraffic in WLAN 802.11b
Slide 19
Evaluation – Handovers in WLAN 802.11b
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.1.254
100 MBit/s
Downstream
Toronto
100 MBit/s
Dhaka
Istanbul
10.10.1.X
10.10.3.X
Mobile Node 1
Slide 20
10.10.3.254
Fixed Host
Mobile Host
Evaluation – Handovers in WLAN
Slide 21
Evaluation – Handovers in WLAN
• Observations:
– TCP connection restarts after 29s, although
receiver available after 16s.
– 11s of handover time due to problems in IP
assignment (DHCP)
– 5s for signaling MIP and IP-Tunnel setup.
– 10 runs showed comparable performance
– TCP performs poor due to exponential
backoff of the retransmission timer
Slide 22
Bluetooth Evaluation
Slide 23
Single Connection over Bluetooth - Scenario
Legend:
Router
8 MBit/s
8 MBit/s
Aalborg
Tokyo
Delft
Toronto
100 MBit/s
Switch
100 MBit/s
Shanghai
Toronto
Bluetooth
Access Point
100 MBit/s
100 MBit/s
Fixed Host
Server
China
10.10.3.254
10.10.1.X
Downstream
Mobile Node
Slide 24
Mobile Host
Single UDP Connection over Bluetooth
Slide 25
Single UDP Connection over Bluetooth
Slide 26
Single TCP Connection over Bluetooth
Slide 27
Single TCP Connection over Bluetooth
Slide 28
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)
• 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)
• Conclusion:
– Some 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
– Bluetooth uses ARQ, thus hiding BERs to TCP is expected
Slide 29
TCP Proxy: Implementation and Evaluation
Slide 30
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 31
Implementation of TCP Proxy - Options
• Non-transparent solutions
– 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 mobile node necssary
– IP-Tunneling
• Tunnel the IP-packets from mobile node to Proxy
• Unpack IP-packets at Proxy and start a „normal“ TCP/IP-Connection
• Disadvantage: additional IP-Overhead
• Transparent solutions
– 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
• Adjusting routing tables with policy based routing (PBR)
• Disdvantage: Processing time for PBR much higher
Slide 32
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
Dhaka
10.10.1.X
100 MBit/s
Fixed Host
Toronto
100 MBit/s
Mobile Host
Server
Mobile Node
San 10.10.3.254
Francisco
Slide 33
Policy-Based
Routing applied
Implementation of TCP Proxy – Software Architecture
Split TCP Daemon
Split-TCP Connection
establish
Notify(old state, new state) Get data
send data
close
TCP Connection
TCP Connection
Data buffer
Data buffer
Process known
TCP packet
Packet Router
Find
Connection
Pop packet
Push packet(s)
Connection Pool
Forward unknown packet
Packet Listener
Packet sender
packet buffer
packet buffer
Encode and send
Capture and decode
NIC
NIC
Slide 34
Implementation of TCP Proxy – Current Features
• Mirroring
• Split TCP:
– TCP Reno implementation
– Slow start
– Congestion avoidance
– Fast retransmission
– Delayed ACKs
– Adjustable Maximum Segment Size
– Adjustable data buffer
– Asymetrical TCP setup
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 maximum throughput
– Drawback: Higher number of delayed ACKs
lead to a slow slow-start, since in first RTT,
some retransmissions are needed to trigger
one ACK
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.
– Linux/Windows send a small initial packet to
force an ACK
Slide 39
Network Setup in MIP scenario
Correspondent
Host
Visited Network
Home Network
IP network
Mobile Node
Foreign
Agent
TCP Proxy
Home Agent
•
•
•
•
•
Home Agent uses TCP proxy as gateway
Reverse Tunneling forced to intercept packets from MN to CN
TCP Proxy uses MIP messages to determine MN connectivity
CN is frozen by automatically sending a Zero Window Advertisment
TCP Proxy starts sending data after receiving a MIP response and recovers CN by sending a nonzero Window Advertisment
•
•
•
The TCP Proxy was successfully enhanced with the new routing feature in upstream
MIP messages are decoded and „inform“ the TCP connection
BUT: Some problems in downstream could not be solved to overcome the handover problem of
TCP
Slide 40
Evaluation – RTTs in WLAN
Slide 41
Conclusion
• Conclusion:
– Wireless LAN:
• ARQ hides high BERs to TCP
• TCP performs good under such conditions
• Disconnections can degrade TCPs performance
– Bluetooth:
• Behaviour of underlaying layers unclear
• Bluetooth also uses ARQ that hides high BERs to TCP
• Disconnections have not been evaluated
– TCP Proxy:
• Mirror adds additional RTTs, but Proxy seems to lower RTTs,
but further evaluation needed
• Coupling MIP to the TCP Proxy is expected to enhance TCPs
performance in handover situations
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/
• Specifications:
– IEEE 802.11b (WLAN)
– Bluetooth SIG, Bluetooth Specification v1.1
• RFCs :
– RFC791 (IP)
– RFC793 (TCP)
• eMail:
– dennis@kom.auc.dk
– dungs@in.tum.de
Slide 43
Thanks for listening!
Slide 44
Backup
Slide 45
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 46