Diagnosing Wireless TCP Performance Problems: A Case Study - PowerPoint PPT Presentation

About This Presentation
Title:

Diagnosing Wireless TCP Performance Problems: A Case Study

Description:

High Speed Bandwidth Reclamation (HSBR) Background USB (cont'd) ... on) may be very important when higher speed wireless link is used (e.g. IEEE 802.11a) ... – PowerPoint PPT presentation

Number of Views:54
Avg rating:3.0/5.0
Slides: 24
Provided by: TeleSi
Category:

less

Transcript and Presenter's Notes

Title: Diagnosing Wireless TCP Performance Problems: A Case Study


1
Diagnosing Wireless TCP Performance Problems A
Case Study
  • Tianbo Kuang, Fang Xiao, and Carey Williamson
  • University of Calgary

2
Agenda
  • Motivation
  • Background
  • TCP
  • IEEE 802.11b Wireless LAN (WLAN)
  • Universal Serial Bus (USB)
  • Experimental Methodology
  • Results

3
Motivation
  • TCP performance often degrades over wireless
    networks reasons well-known
  • Solutions to improve TCP performance over
    wireless links exist, but how well do they work
    in a real wireless LAN environment?
  • How do link-layer mechanisms interact with TCP
    and affect the overall performance?
  • Where is the bottleneck in the network protocol
    processing path, and why?

4
Background - TCP
  • Widely used on the Internet (e.g. Web)
  • Connection-oriented, reliable byte stream
  • Window-based flow control
  • Slow start and congestion avoidance
  • Fast retransmission, fast recovery
  • Other extensions, including TCP SACK
  • Many different versions in use

5
Background IEEE 802.11b
  • An Ethernet-like LAN standard (11 Mbps)
  • Infrastructure mode and ad hoc mode
  • Carrier-sense multiple access with collision
    avoidance (CSMA/CA) to reduce collisions
  • MAC-layer positive acknowledgment and
    retransmissions (to recover from channel errors)
  • Dynamic rate adaptation can choose data
    transmission rate of 1, 2, 5.5, or 11 Mbps

6
Background USB
  • Widely used industry standard for connecting a
    computer to its peripherals (bus topology)
  • Lots of USB-based (wireless) network cards
  • Data transfers managed by Host Controller (HC)
  • Synchronous bus 1 msec slots for transfers
  • Transfer requests are handled using vertical and
    horizontal linked-list data structures
  • Two processing modes for HC
  • Breadth-First or Depth-First
  • High Speed Bandwidth Reclamation (HSBR)

7
Background USB (contd)
  • Queued mode (keep HC busy)
  • Transfer size 64 1023 bytes each

8
Background USB (contd)
  • Queued mode (keep HC busy)
  • Transfer size 64 1023 bytes each

9
Experimental Methodology
  • Experimental Setup (HW/SW)
  • Laptop Compaq Evo 719c with multiport USB
    wireless card (Linux 2.4)
  • Access point Lucent RG-1000
  • Stationary host on Ethernet LAN SunOS 5.8
  • Run netperf on laptop and netserver on wired host
  • SnifferPro 4.6 wireless sniffer and tcpdump
  • Experimental Factors
  • USB mode, driver settings
  • Wireless channel (distance) between laptop and AP

data
netperf
laptops
netserver
AP
tcpdump
Ethernet
Sniffer
acks
10
Initial Result
  • Windows 2000 implementation of TCP is more than 3
    times faster than Linux TCP!
  • Reason Linux driver bug (2 Mbps vs 11 Mbps)

OS
Throughput
Linux
1.52 Mbps
Windows 2000
5.11 Mbps
11
Results USB Experiments
12
Results USB Experiments
  • With FSBR disabled, USB is the bottleneck
  • With FSBR enabled (the default in Linux), the
    wireless network is the bottleneck
  • Queued mode makes no difference with FSBR on, but
    helps when FSBR is turned off
  • Queued mode (even with FSBR turned on) may be
    very important when higher speed wireless link is
    used (e.g. IEEE 802.11a)

13
Results TCP Problems
  • The ack holding problem
  • A bug in the NIC firmware or interrupt driver of
    Linux OS causes excessive delays (gt 100 ms)
  • This leads to a spurious TCP timeout
  • The retransmission of previously acked data!
  • Actually just an artifact of tcpdump observation
  • The lack of a TCP fast retransmit after
    receiving three duplicate Acks
  • A deliberate (but not well-known) feature of TCP

14
Results TCP ack holding
15
Results TCP ack holding
(laptop)
(wired)
(sniffer)
(kernel)
16
Results TCP repeated data
  • The spurious TCP timeout was
  • not properly detected
  • Caused by initialization
  • bug in Linux TCP
  • implementation
  • The repeated data problem is an
    artifact induced by presence
    of link layer buffer

17
Results TCP suppressed FR
  • This is a deliberate feature to prevent a false
    fast retransmit after a timeout
  • This situation is quite likely to occur in a
    wireless environment
  • Its not a bug, but a feature! (correct)

18
Results Wireless Problems
  • We observed unusually high collision rates on the
    wireless channel for TCP transfers, which we call
    the TCP data/ACK collision problem
  • Scenario laptop and AP are 1 m apart
  • For TCP, MAC-layer retransmit rate 4.58-4.73
  • For UDP, MAC-layer retransmit rate 0.47-0.98
  • In general, a retransmission rate of 1.75-7.2
    has been seen for other vendor HW/SW (N 1)
  • For TCP, disabling MAC-layer retransmission
    degrades throughput by 23

19
Results Wireless Problems (TCP data/ACK
collisions)
20
Results Wireless Problems
  • The MAC-layer rate adaptation problem
  • Scenario laptop and AP are 100 m apart
  • Lousy TCP throughput, lots of retransmits
  • Reason the multiplicative increase and
    multiplicative decrease (MIMD) bandwidth probing
    mechanism causes network thrashing and wastes
    battery power
  • The small congestion window causes temporary
    deadlock if the TCP receiver uses delayed Ack

21
Results Wireless Problems (MAC-layer rate
adaptation)
22
Conclusions
  • TCP performance on WLAN can be wacky! (at least
    for Compaq Multiport 802.11b USB wireless card
    under Linux 2.4)
  • Several factors can affect overall performance
  • Poorly configured USB bus could be the bottleneck
  • Linux TCP implementation bug makes TCP unable to
    recognize the first spurious timeout
  • Poor MAC-layer rate adaptation algorithm can
    cause a network thrashing problem
  • TCPs data/ACK structure may induce excessive
    collisions at the MAC layer on wireless LANs

23
Questions?
Write a Comment
User Comments (0)
About PowerShow.com