Implementation and Evaluation of a Performance Enhancing Proxy for Wireless TCP - PowerPoint PPT Presentation

Loading...

PPT – Implementation and Evaluation of a Performance Enhancing Proxy for Wireless TCP PowerPoint presentation | free to download - id: 3db5c-NzcxM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Implementation and Evaluation of a Performance Enhancing Proxy for Wireless TCP

Description:

Implementation and Evaluation of a Performance Enhancing Proxy for Wireless TCP ... 2.6 GHz-P4 512MB RAM, WinXP, Belkin Class2 BT USB Adapter. AP: BlipNet ... – PowerPoint PPT presentation

Number of Views:133
Avg rating:3.0/5.0
Slides: 46
Provided by: dennis84
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Implementation and Evaluation of a Performance Enhancing Proxy for Wireless TCP


1
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

2
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

3
Experimental Evaluation
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

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)

6
Evaluation - Metrics
  • Instantaneous Throughput
  • Instantaneous Averaged Throughput
  • Transmission Throughput
  • Round-Trip-Times (RTT)

7
WLAN 802.11b Evaluation
8
802.11 Evaluation Setup
Server
Legend
10.10.2.254
Router
8 MBit/s
8 MBit/s
Tokyo
Switch
100 MBit/s
100 MBit/s
WLAN Access Point
Fixed Host
100 MBit/s
100 MBit/s
Mobile Host
9
Evaluation - General Eval on WLAN
10
Evaluation - General Eval on WLAN
11
Evaluation - General Eval on WLAN
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

13
Evaluation BERs in WLAN
Legend
Room 4
WLAN Access Point
Position 4
Mobile Host
Room 3
Room 2
Position 1
Room 1
Position 3
Position 2
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

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

16
Evaluation Handovers in WLAN
Server
Legend
10.10.2.254
Router
8 MBit/s
8 MBit/s
Tokyo
Switch
100 MBit/s
Home Agent
100 MBit/s
Foreign Agent
WLAN Access Point
10.10.3.254
Fixed Host
10.10.3.254
100 MBit/s
100 MBit/s
Mobile Host
10.10.3.X
10.10.1.X
17
Evaluation Handovers in WLAN
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

19
Bluetooth Evaluation
20
Single Connection over Bluetooth - Scenario
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-gtMN 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
100 MBit/s
100 MBit/s
100 MBit/s
Server
10.10.3.254
10.10.1.X
Downstream
Mobile Node
Legend
Fixed Host
Mobile Host
Router
Switch
BT AP
21
Single UDP Connection over Bluetooth
22
Single UDP Connection over Bluetooth
23
Single TCP Connection over Bluetooth
24
Single TCP Connection over Bluetooth
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)

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)

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

28
TCP Proxy Implementation and Evaluation
29
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
  • 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

30
Implementation of TCP Proxy - Idea
  • Split TCP Idea

Sender
Receiver
TCP Proxy
Application
Application
Split TCP-Daemon
TCP
TCP
TCP
TCP
IP
IP
IP
IP
LL / PHY
LL / PHY
LL / PHY
LL / PHY
31
Implementation of TCP Proxy Software
Architecture
Split TCP daemon
Connection
Connection
establish connection
Connection
Connection
Connection
Connection
close connection
Send data
Send data
Data buffer
Process packet
Create packet(s)
(Mirror)
Packet-buffer
Packet-buffer
decode
encode
NIC
NIC
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

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 -gt Maintainance efforts
  • ARP Solution
  • emulate IP Adresses by faking IP-MAC-Maps
  • Disadvantage Difficult to maintain maps
  • Disadvantage Timing problems
  • Routing-Solution

34
Implementation of TCP Proxy Network setup
Legend
Proxy
Router
10.10.254.254
100 MBit/s
Switch
8 MBit/s
8 MBit/s
Tokyo
WLAN Access Point
100 MBit/s
100 MBit/s
Fixed Host
10.10.4.X
100 MBit/s
Mobile Host
Server
Mobile Node
San Francisco
10.10.1.254
Policy-Based Routing applied
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

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

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

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

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.

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

41
Current Problems
  • Ethereal not working with PPP in Windows
    NT/2000/XP (-gt BT LAN, GPRS)
  • No globally routable IP-Address available in GPRS
  • MobileIP-Setup over GPRS
  • No W-CDMA Equipment available
  • Bugs,.... ?

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 dennis_at_kom.auc.dk

43
Thanks for listening! Any Questions?
44
Backup
45
Current IPLab network architecture
IP LAB Current Architecture
Spjald
10.10.3.254
10.10.4.2
10.10.254.254
10.10.3.1
San Francisco
130.225.51.6
Tokyo
Frankfurt
Delft
GPRS Network
10.10.2.1
10.10.1.1
Toronto
Shanghai
10.10.1.254
10.10.1.2
10.10.2.2
Sydney
Dhaka
About PowerShow.com