implementation and evaluation of a performance enhancing proxy for wireless tcp
DESCRIPTION
Implementation and Evaluation of a Performance Enhancing Proxy for Wireless TCP. Diploma Thesis (Sep 03 – April 04) Dennis Dungs Technical University Munich, Germany Aalborg University, Denmark Final Presentation - May 04 Supervised by Hans-Peter Schwefel Aalborg University, Denmark. - PowerPoint PPT PresentationTRANSCRIPT
Slide 1
Implementation and Evaluation of a Performance Enhancing Proxy for Wireless
TCP
Diploma Thesis (Sep 03 – April 04)
Dennis DungsTechnical University Munich, Germany
Aalborg University, Denmark
Final Presentation - May 04
Supervised byHans-Peter Schwefel
Aalborg University, Denmark
Slide 2
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 (left out)• Influence of Handovers
– Bluetooth• UDP and TCP throughput
• TCP Proxy– Implementation
• Proxy design• Network setup
– Proxy Eval• Influence on RTT & Throughput
• Conclusion
Slide 3
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
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 4
Scenarios
Slide 5
Scenarios and Limitations
• Network Architecture– 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 Links– Proxy Location: fixed Proxy location with no handover support
• Mobility Model– Fixed Position– Handover to same subnet– Handover to different subnet (considered)– Handover to different access technology
• Traffic Model– Type of Transport Layer Protocol (UDP /TCP)– 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 6
Evaluation Method
Slide 7
Evaluation – Measurement Procedure
• IPerf / UDPBurst– Setup a UDP/TCP connection from sender to receiver– Send data from sender to receiver at maximum bandwidth (TCP)
or given bandwidth (UDP)– UDPBurst to generate bursty ON/OFF-Traffic
• 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 8
Evaluation - Metrics
• Instantaneous Throughput
• Instantaneous Averaged Throughput
• Transmission Throughput
• Round-Trip-Times (RTT)• Nr. of packets• Nr. of retransmitted bytes• Nr. of retransmission timeouts
const.k 1),-(i*k n ,)( 1
nkn
kn
nll
Avgerage tt
epayloadsizi
1
1)(tt
epayloadsizn
n
n
ii
ontransmissi
1
)(
nn
nInst tt
epayloadsizn
Slide 9
WLAN 802.11b Evaluation
Slide 10
Evaluation - General Eval on WLAN 802.11b
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
Shanghai
100 MBit/s
Server
10.10.3.254Downstream
100 MBit/s
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
Slide 14
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 15
Evaluation – BERs in WLAN 802.11b
Room 4
Room 3
Room 2
Room 1 Position #1
Position #2
Position #3
Position #4
Legend:
Mobile Host
WLAN Access Point
Slide 16
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 17
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 18
Evaluation – Handovers in WLAN 802.11b
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.1.254
Frankfurt
Server
10.10.2.254Shanghai
10.10.3.X10.10.1.XDownstream
Slide 19
Evaluation – Handovers in WLAN
Slide 20
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 21
Bluetooth Evaluation
Slide 22
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
Downstream
Legend:
Fixed Host
Mobile Host
Router
TorontoSwitch
Bluetooth Access Point
Slide 23
Single UDP Connection over Bluetooth
Slide 24
Single UDP Connection over Bluetooth
Slide 25
Single TCP Connection over Bluetooth
Slide 26
Single TCP Connection over Bluetooth
Slide 27
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 28
TCP Proxy: Implementation and Evaluation
Slide 29
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 30
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 31
Implementation of TCP Proxy – Network setup
10.10.1.X
Tokyo Delft
Legend:Proxy
Aalborg
Fixed Host
Mobile Host
Dhaka
Router
10.10.254.254
Mobile Node San Francisco
Toronto
Server
10.10.3.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 32
Implementation of TCP Proxy – Software Architecture
Get dataestablish
close
Process known TCP packet
Push packet(s)
send data
TCP ConnectionData buffer
Split-TCP Connection
Notify(old state, new state)
TCP ConnectionData buffer
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
Slide 33
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 34
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 35
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 36
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 37
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 38
Network Setup in MIP scenario
CorrespondentHost
Mobile Node
IP network
Home AgentForeign Agent
Visited Network
Home Network
TCP Proxy
• 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 non-zero
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 39
Evaluation – RTTs in WLAN
Slide 40
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 41
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: – [email protected] – [email protected]
Slide 42
Thanks for listening!
Slide 43
Backup
Slide 44
Evaluation – Crosstraffic in WLAN 802.11b
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/s100 MBit/s
100 MBit/s
Shanghai
100 MBit/s
Mobile Node 2
CrosstrafficConnection
TCP Connection
Slide 45
Evaluation – Crosstraffic in WLAN 802.11b
Slide 46
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