Slide 1 Implementation and Evaluation of a Performance Enhancing Proxy for Wireless TCP Master...
-
date post
21-Dec-2015 -
Category
Documents
-
view
223 -
download
3
Transcript of Slide 1 Implementation and Evaluation of a Performance Enhancing Proxy for Wireless TCP Master...
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