Wireless Internet: Protocols and Performance

1
Wireless InternetProtocols and Performance

• Carey Williamson
• iCORE Professor
• Department of Computer Science
• University of Calgary

2
Tutorial Outline

• 1. Introduction/Motivation (10 min)
• 2. Networking Terminology (10 min)
• 3. IEEE 802.11b WLANs (30 min)
• 4. TCP (20 min)
• 5. HTTP (15 min)
• 6. Wireless TCP Performance Part 1 (15 min)
• 7. Wireless TCP Performance Part 2 (15 min)
• 8. Wireless Web Performance (30 min)
• 9. Summary, Questions, Discussion (10 min)

---- Coffee Break Here ---- (1030-1045am)
3
1. Wireless InternetIntroduction
4
What Is Wireless Networking?

• The use of infra-red (IR) or radio frequency (RF)
  signals to share information and resources
  between devices
• A hot computer industry buzzword
• Lots of advertising by companies and media
• Wireless Broadband, 3G wireless, 4G, WAP, iMode,
  Bluetooth, WiFi
• Mobile Internet, Pervasive Computing, Nomadic
  Computing, M-commerce
• Ubiquitous Global Revolutionary

5
Two Popular 2.4 GHz Standards

• IEEE 802.11
• Fast (11b)
• High Power
• Long range
• Single-purpose
• Ethernet replacement
• Easily Available
• Apple Airport, iBook, G4
• Cisco Aironet 350

• Bluetooth
• Slow
• Low Power
• Short range
• Flexible
• Cable replacement
• Vapourware (?)

6
IEEE 802.11 Organization Tree
7
Pros and Cons of 802.11

• Pro
• High bandwidth (up to 11 Mbps)
• Two modes of operation infrastructure vs. ad hoc
• Con
• Incompatibility between old and new cards
• Signal blocked by reinforced concrete or tinted
  glass
• High channel BER can degrade performance (lots!)
• No standard for hand-off between base stations
• Some channel numbers overlap spectrum
• High power consumption in laptops

8
Bluetooth

• Think USB, not Ethernet
• Cable replacement technology
• Created by Ericsson
• PAN - Personal Area Network
• 1-2 Mbps connections
• 1600 hops per second FHSS
• Includes synchronous, asynchronous, voice
  connections
• Piconet routing
• Small, low-power, short-range, cheap, versatile
  radios
• Used as Internet connection, phone, or headset
• Master/slave configuration and scheduling

9
Security

• Wireless sniffers, war driving
• IEEE 802.11
• ESSID Extended Services Set ID
• WEP Wired Equivalent Privacy (useless)
• NAT - Network Address Translation (firewall)
• Bluetooth Security
• FHSS, with rapid hop sequence
• Short range
• Encrypted transmissions (optional)

10
Guerrilla.net

• An underground alternative to the wired Internet
• A grassroots movement established in 1996
• 802.11 Wireless LAN cards
• Roof mounted antennae
• Free software (FreeBSD)
• Multi-hop routing, Internet connectivity
• About 500 per node (and dropping)
• Other networks popping up in SF, Seattle, London

11
Future of Wireless

• Higher data rates
• Better security
• Wider selection of products
• Lower prices
• Zero configuration networking
• More end-user focus
• Better software
• Less visible
• More popular

12
2. BackgroundNetworking Terminology
13
Wireless Internet Technologies

• Mobile devices (e.g., notebooks, laptops, PDAs,
  cell phones, wearable computers)
• Wireless network access
• Bluetooth (1 Mbps, up to 3 meters)
• IEEE 802.11b (11 Mbps, up to 100 meters)
• IEEE 802.11a (55 Mbps, up to 20 meters)
• Operating modes
• Infrastructure mode (access point)
• Ad hoc mode
• Wireless Web, WiFi hot spots

14
Internet Protocol Stack

• Application supporting network applications and
  end-user services
• FTP, SMTP, HTTP, DNS, NTP
• Transport end to end data transfer
• TCP, UDP
• Network routing of datagrams from source to
  destination
• IPv4, IPv6, BGP, RIP, routing protocols
• Data Link hop by hop frames, channel access,
  flow/error control
• PPP, Ethernet, IEEE 802.11b
• Physical raw transmission of bits

001101011...
15
Internet Protocol Stack

• Application
• e.g., Hyper-Text Transfer Protocol (HTTP)
• Transport
• Transmission Control Protocol (TCP)
• User Datagram Protocol (UDP)
• Network
• Internet Protocol (IP, IPv4, IPv6)
• Data Link
• e.g., IEEE 802.3 Ethernet, IEEE 802.11b
• Physical
• Device specific, network specific

001101011...
16
Multi-Hop Wireless Ad Hoc Networks

• Routing protocols used to improve wireless
  connections
• Infrastructure-free, dynamic
• True Peer-to-Peer routing
• Fault tolerant
• Examples AODV, DSDV, TORA, DSR, ...

17
Example

• Multi-hop ad hoc networking

Kelly
Carey
18
3. IEEE 802.11bWireless LANs
19
The Basics

• In several respects, the IEEE 802.11b wireless
  LAN (WLAN) standard is similar to that for IEEE
  802.3 (Ethernet) LANs
• Similarities
• LAN limited geographic coverage multiple
  stations shared transmission medium CSMA-based
  Medium Access Control protocol 48-bit
  MAC addresses comparable data rates (11 Mbps vs
  10 Mbps)

20
The Basics (Contd)

• But there are also distinct differences
• wireless (air interface) versus wired (coax)
• wireless propagation environment (multipath)
• higher error rate due to interference, etc.
• successful frames are ACKed by receiver
• mobile stations hidden node problem potential
  asymmetries
• CSMA/CA versus CSMA/CD
• multiple data transmission rates (1, 2, 5.5, 11)

21
Some Features

• Infrastructure mode vs ad hoc mode
• Access Point (AP) sends beacon frames
• Mobiles choose AP based on signal strength
• Multiple channel access protocols supported
• CSMA/CA (DCF) PCF RTS/CTS
• MAC-layer can provide error control,
  retransmission, rate adaptation, etc.
• Direct Sequence Spread Spectrum (DSSS)
• signal spread across 14 22-MHz channels

22
Where Does Wireless RF Live?ISM Band
Industrial, Scientific, Medical
902-928 MHz
2400-2483.5 MHz
5725-5850 MHz
Old Wireless
802.11a
802.11/802.11b
Bluetooth
Cordless Phones
Home RF
Baby Monitors
Microwave Ovens
23
Where does 802.11 live in the OSI?
24
Wireless Cells
11 Mbps bandwidth shared by all devices in the
Cell!
25
Wireless Cells
Computers can roam between cells
26
CSMA-CA Acknowledgement
Carrier Sense Multiple Access with Collision
Avoidance
How CSMA-CA works

• Device wanting to transmit senses the medium
  (Air)

• If medium is busy - defers

• If medium is free for certain period (DIFS) -
  transmits frame

Latency can increase if air is very busy!
Device has hard time finding open air to send
frame!

• DIFS - Distributed Inter-Frame Space (approx 128
  µs)

27
CSMA-CA Acknowledgement
Carrier Sense Multiple Access with Collision
Avoidance
others
source
destination
Air is free for DIFS time period
DIFS
send frame
data
All other devices must defer while air is busy
NAV defer access
SIFS
Receive ACK back that frame was received intact!
ack

• Every frame is acked - except broadcast and
  multicast!

• SIFS - Short Inter-Frame Space (approx 28 µs)

28
MAC-Layer Retransmission

• If no ACK received right away, then the sender
  retransmits the frame again at the MAC layer
• indicates frame (or ACK) was lost/corrupted
• very short timeout (e.g., 1 msec)
• exponential backoff (doubling) if repeated loss
• Typically recovers before TCP would notice
• Max retransmission limit (e.g., 8)
• May do MAC-layer rate adaptation or frame
  fragmentation if channel error rate is high

29
Other MAC Protocols Supported

• Point Coordination Function (PCF)
• AP polls stations in turn to see if frames to
  send
• useful for real-time traffic
• Request-To-Send/Clear-To-Send (RTS/CTS)
• reservation-based approach (ask permission)
• useful for very large frames
• useful for solving the hidden node problem
• request asks for clearance (permission) to send
• request also indicates time required for transmit

30
Frame Formats

• Two frame formats available
• long preamble
• short preamble
• Configuration option for NIC and AP
• Variable-size frames (max 2312 data bytes)
• 16-bit Cyclic Redundancy Code (CRC) for
  error checking of frames

31
Long Preamble
Long Preamble 144 bits

• Interoperable with older 802.11 devices

• Entire Preamble and 48 bit PLCP Header sent at 1
  Mbps

32
Short Preamble
Short Preamble 72 bits

• Preamble transmitted at 1 Mbps

• PLCP Header transmitted at 2 Mbps

• more efficient than long preamble

Transmitted at 2 Mbps
Signal Speed 1,2,5.5,11 Mbps
Length of Payload
16 bit Start Frame Delimiter
16 bit CRC
Service (unused)
Payload 0-2312 bytes
56 bit Preamble
33
Even More Features

• Power Management
• mobile nodes can sleep to save power
• AP will buffer frames until client requests them
• AP can use virtual bitmap field in beacons to
  indicate which stations have data waiting
• Security
• Wired Equivalent Privacy (WEP)
• not secure at all!

34
Summary

• IEEE 802.11b (WiFi) is a wireless LAN technology
  that is rapidly growing in popularity
• Convenient, inexpensive, easy to use
• Growing number of hot spots everywhere
• airports, hotels, bookstores, Starbucks, etc
• Estimates 70 of WLANs are insecure!

35
4. TCP 101Transmission Control Protocol
36
Tutorial TCP 101

• The Transmission Control Protocol (TCP) is the
  protocol that sends your data reliably
• Used for email, Web, ftp, telnet, p2p,
• Makes sure that data is received correctly right
  data, right order, exactly once
• Detects and recovers from any problems that occur
  at the IP network layer
• Mechanisms for reliable data transfer sequence
  numbers, acknowledgements, timers,
  retransmissions, flow control...

37
TCP 101 (Contd)

• TCP is a connection-oriented protocol

YOUR DATA HERE
Web Client
Web Server
38
TCP 101 (Contd)

• TCP slow-start and congestion avoidance

39
TCP 101 (Contd)

• TCP slow-start and congestion avoidance

40
TCP 101 (Contd)

• TCP slow-start and congestion avoidance

41
TCP 101 (Contd)

• This (exponential growth) slow start process
  continues until either
• packet loss after a brief recovery phase, you
  enter a (linear growth) congestion avoidance
  phase based on slow-start threshold found
• limit reached slow-start threshold, or maximum
  advertised receive window size
• all done terminate connection and go home

42
Tutorial TCP 201

• There is a beautiful way to plot and visualize
  the dynamics of TCP behaviour
• Called a TCP Sequence Number Plot
• Plot packet events (data and acks) as points in
  2-D space, with time on the horizontal axis, and
  sequence number on the vertical axis
• Example Consider a 14-packet transfer

43

Key X Data Packet Ack Packet
X

X

X

X

X
SeqNum

X

X
X


X

X

X

X

X

X
Time
44
So What?

• What can it tell you?
• Everything!!!

45

Key X Data Packet Ack Packet
X

X

X

X

X
SeqNum

X

X
X


X

X

X

X

X

X
Time
RTT
46

Key X Data Packet Ack Packet
X

X

X

X

X
SeqNum

X

X
X


X

X

X
TCP Seg. Size

X

X

X
Time
47

Key X Data Packet Ack Packet
X

X

X

X

X
SeqNum

X

X
X


X

X

X

X

X

X
Time
TCP Connection Duration
48

Key X Data Packet Ack Packet
X

X

X

X

X
SeqNum

X

X
X


Num Bytes Sent
X

X

X

X

X

X
Time
49

Key X Data Packet Ack Packet
X

X

X

X

X
SeqNum

X

X
Bytes
Avg Throughput (Bytes/Sec)
X


X

X

X

X

X

X
Sec
Time
50

Key X Data Packet Ack Packet
X

X

X

X

X
SeqNum
Access Network Bandwidth (Bytes/Sec)

X

X
X


X

X

X

X

X

X
Time
51

Key X Data Packet Ack Packet
X

X

X

X

X
SeqNum

X

X
X


X
Senders Flow Control Window Size

X

X

X

X

X
Time
52

Key X Data Packet Ack Packet
X

X

X

X

X
SeqNum

X

X
TCP Slow Start
X


X

X

X

X

X

X
Time
53

Key X Data Packet Ack Packet
X

X
X

X
X
SeqNum

X
X
X

X
Delayed ACK

X
X

X
X

X
Time
54
Key X Data Packet Ack Packet
X


X

X
Packet Loss
SeqNum

X

X
X


Duplicate ACK
X

X

X

X

X

X
Time
55
Cumulative ACK
Key X Data Packet Ack Packet

X
X


X

X
SeqNum

X

Retransmit
X
X


X

X

X

X

X

X
Time
56
Key X Data Packet Ack Packet

X
X


X

X
SeqNum

X

X
X


X

X

X

X

X

X
Time
RTO
57
TCP 201 (Contd)

• What happens when a packet loss occurs?
• Quiz Time...
• Consider a 14-packet Web document
• For simplicity, consider only a single packet
  loss

58

Key X Data Packet Ack Packet
X

X

X

X

X
SeqNum

X

X
X


X

X

X

X

X

X
Time
59
?
Key X Data Packet Ack Packet

X

X

X

X
SeqNum

X

X
X


X

X

X

X

X

X
Time
60
Key X Data Packet Ack Packet

X

X

X

X
SeqNum

X

X
X


X

X

X

X

X

X
Time
61

Key X Data Packet Ack Packet
X

X

X

X

X
SeqNum

X

X
X


X

X

X

X

X

X
Time
62
Key X Data Packet Ack Packet
X
?

X

X

X
SeqNum

X

X
X


X

X

X

X

X

X
Time
63

Key X Data Packet Ack Packet
X
X


X

X

X
SeqNum

X

X
X


X

X

X

X

X

X
Time
64

Key X Data Packet Ack Packet
X

X

X

X

X
SeqNum

X

X
X


X

X

X

X

X

X
Time
65
Key X Data Packet Ack Packet
X
X
X
?

X
SeqNum

X

X
X


X

X

X

X

X

X
Time
66

Key X Data Packet Ack Packet
X
X
X
X




X
SeqNum

X

X
X


X

X

X

X

X

X
Time
67

Key X Data Packet Ack Packet
X

X

X

X

X
SeqNum

X

X
X


X

X

X

X

X

X
Time
68
Key X Data Packet Ack Packet
SeqNum
?

X

X
Time
69
Key X Data Packet Ack Packet
SeqNum

X

X
X
X



X

X
Time
70
TCP 201 (Contd)

• Main observation
• Not all packet losses are created equal
• Losses early in the transfer have a huge adverse
  impact on the transfer latency
• Losses near the end of the transfer always cost
  at least a retransmit timeout
• Losses in the middle may or may not hurt,
  depending on congestion window size at the time
  of the loss

71
Congratulations!

• You are now a TCP expert!

72
5. HTTPHyperText Transfer Protocol
73
Introduction to HTTP
http request
http request
http response
http response
Laptop w/ Netscape
Desktop w/ Explorer
Server w/ Apache

• HTTP HyperText Transfer Protocol
• Communication protocol between clients and
  servers
• Application layer protocol for WWW
• Client/Server model
• Client browser that requests, receives, displays
  object
• Server receives requests and responds to them
• Protocol consists of various operations
• Few for HTTP 1.0 (RFC 1945, 1996)
• Many more in HTTP 1.1 (RFC 2616, 1999)

74
Request Generation

• User clicks on something
• Uniform Resource Locator (URL)
• http//www.cnn.com
• http//www.cpsc.ucalgary.ca
• https//www.paymybills.com
• ftp//ftp.kernel.org
• Different URL schemes map to different services
• Hostname is converted from a name to a 32-bit IP
  address (DNS lookup, if needed)
• Connection is established to server (TCP)

75
What Happens Next?

• Client downloads HTML document
• Sometimes called container page
• Typically in text format (ASCII)
• Contains instructions for rendering
• (e.g., background color, frames)
• Links to other pages
• Many have embedded objects
• Images GIF, JPG (logos, banner ads)
• Usually automatically retrieved
• I.e., without user involvement
• can control sometimes
• (e.g. browser options, junkbusters)

lthtmlgt ltheadgt ltmeta nameAuthor contentErich
Nahumgt lttitlegt Linux Web Server Performance
lt/titlegt lt/headgt ltbody text00000gt ltimg
width31 height11 srcibmlogo.gifgt ltimg
srcimages/new.gifgt lth1gtHi There!lt/h1gt Heres
lots of cool linux stuff! lta hrefmore.htmlgt Cli
ck herelt/agt for more! lt/bodygt lt/htmlgt
sample html file
76
Web Server Role

• Respond to client requests, typically a browser
• Can be a proxy, which aggregates client requests
  (e.g., AOL)
• Could be search engine spider or robot (e.g.,
  Keynote)
• May have work to do on clients behalf
• Is the clients cached copy still good?
• Is client authorized to get this document?
• Hundreds or thousands of simultaneous clients
• Hard to predict how many will show up on some day
  (e.g., flash crowds, diurnal cycle, global
  presence)
• Many requests are in progress concurrently

77
HTTP Request Format
GET /images/penguin.gif HTTP/1.0 User-Agent
Mozilla/0.9.4 (Linux 2.2.19) Host
www.kernel.org Accept text/html, image/gif,
image/jpeg Accept-Encoding gzip Accept-Language
en Accept-Charset iso-8859-1,,utf-8 Cookie
Bxh203jfsf Y3sdkfjej ltcrgtltlfgt

• Messages are in ASCII (human-readable)
• Carriage-return and line-feed indicate end of
  headers
• Headers may communicate private information
• (browser, OS, cookie information, etc.)

78
Request Types

• Called Methods
• GET retrieve a file (95 of requests)
• HEAD just get meta-data (e.g., mod time)
• POST submitting a form to a server
• PUT store enclosed document as URI
• DELETE removed named resource
• LINK/UNLINK in 1.0, gone in 1.1
• TRACE http echo for debugging (added in 1.1)
• CONNECT used by proxies for tunneling (1.1)
• OPTIONS request for server/proxy options (1.1)

79
Response Format
HTTP/1.0 200 OK Server Tux 2.0 Content-Type
image/gif Content-Length 43 Last-Modified Fri,
15 Apr 1994 023621 GMT Expires Wed, 20 Feb
2002 185446 GMT Date Mon, 12 Nov 2001 142948
GMT Cache-Control no-cache Pragma
no-cache Connection close Set-Cookie
PAwefj2we0-jfjf ltcrgtltlfgt ltdata followsgt

• Similar format to requests (i.e., ASCII)

80
Response Types

• 1XX Informational (defd in 1.0, used in 1.1)
• 100 Continue, 101 Switching Protocols
• 2XX Success
• 200 OK, 206 Partial Content
• 3XX Redirection
• 301 Moved Permanently, 304 Not Modified
• 4XX Client error
• 400 Bad Request, 403 Forbidden, 404 Not Found
• 5XX Server error
• 500 Internal Server Error, 503 Service
  Unavailable, 505 HTTP Version Not Supported

81
Outline of an HTTP Transaction

• This section describes the basics of servicing an
  HTTP GET request from user space
• Assume a single process running in user space,
  similar to Apache 1.3
• Well mention relevant socket operations along
  the way

initialize forever do get request
process send response log request
server in a nutshell
82
Readying a Server
s socket() / allocate listen socket
/ bind(s, 80) / bind to TCP port 80
/ listen(s) / indicate willingness to
accept / while (1) newconn accept(s) /
accept new connection /b

• First thing a server does is notify the OS it is
  interested in WWW server requests these are
  typically on TCP port 80. Other services use
  different ports (e.g., SSL is on 443)
• Allocate a socket and bind()'s it to the address
  (port 80)
• Server calls listen() on the socket to indicate
  willingness to receive requests
• Calls accept() to wait for a request to come in
  (and blocks)
• When the accept() returns, we have a new socket
  which represents a new connection to a client

83
Processing a Request
remoteIP getsockname(newconn) remoteHost
gethostbyname(remoteIP) gettimeofday(currentTime)
read(newconn, reqBuffer, sizeof(reqBuffer)) req
Info serverParse(reqBuffer)

• getsockname() called to get the remote host name
• for logging purposes (optional, but done by most)
• gethostbyname() called to get name of other end
• again for logging purposes
• gettimeofday() is called to get time of request
• both for Date header and for logging
• read() is called on new socket to retrieve
  request
• request is determined by parsing the data
• GET /images/jul4/flag.gif

84
Processing a Request (cont)
fileName parseOutFileName(requestBuffer) fileAt
tr stat(fileName) serverCheckFileStuff(fileName
, fileAttr) open(fileName)

• stat() called to test file path
• to see if file exists/is accessible
• may not be there, may only be available to
  certain people
• "/microsoft/top-secret/plans-for-world-domination.
  html"
• stat() also used for file meta-data
• e.g., size of file, last modified time
• "Has file changed since last time I checked?
• might have to stat() multiple files and
  directories
• assuming all is OK, open() called to open the file

85
Responding to a Request
read(fileName, fileBuffer) headerBuffer
serverFigureHeaders(fileName, reqInfo) write(newS
ock, headerBuffer) write(newSock,
fileBuffer) close(newSock) close(fileName) writ
e(logFile, requestInfo)

• read() called to read the file into user space
• write() is called to send HTTP headers on socket
  
• (early servers called write() for each header!)
• write() is called to write the file on the
  socket
• close() is called to close the socket
• close() is called to close the open file
  descriptor
• write() is called on the log file

86
Network View HTTP and TCP

• TCP is a connection-oriented protocol

YOUR DATA HERE
Web Client
Web Server
87
Example Web Page
Harry Potter Movies
As you all know, the new HP book will be out in
June and then there will be a new movie shortly
after that Harry Potter and the Bathtub Ring
hpface.jpg
page.html
castle.gif
88
Server
Client
The classic approach in HTTP/1.0 is to use
one HTTP request per TCP connection, serially.
89
Server
Concurrent (parallel) TCP connections can be
used to make things faster.
Client
C
C
S
S
90
Server
Client
The persistent HTTP approach can re-use
the same TCP connection for Multiple HTTP
transfers, one after another, serially. Amortizes
TCP overhead, but maintains TCP state longer at
server.
91
Server
Client
The pipelining feature in HTTP/1.1
allows requests to be issued asynchronously on
a persistent connection. Requests must
be processed in proper order. Can do clever
packaging.
GG
92
Summary of Web and HTTP

• The major application on the Internet
• Majority of traffic is HTTP (or HTTP-related)
• Client/server model
• Clients make requests, servers respond to them
• Done mostly in ASCII text (helps debugging!)
• Various headers and commands
• Too many to go into detail here
• Many web books/tutorials exist
  (e.g., Krishnamurthy Rexford 2001)

93
6. Wireless TCPPerformance Issues (Part 1)
94
Example 1

• Wireless TCP Performance Problems

Low capacity, high error rate
Wired Internet
High capacity, low error rate
Wireless Access
95
Example 1 (Contd)

• Solution wireless-aware TCP (I-TCP, ProxyTCP,
  Snoop-TCP, split connections...)

96
Example 2

• Wireless TCP Fairness Problems

D
Wired Internet
Wireless Bottleneck
AP
U
97
Example 3

• Multi-hop ad hoc networking

Kelly
Carey
98
Example 3 (Contd)

• Multi-hop ad hoc networking

Kelly
Carey
99
Example 3 (Contd)

• Multi-hop ad hoc networking

Kelly
Carey
100
Example 3 (Contd)

• Multi-hop ad hoc networking

Kelly
Carey
101
Example 3 (Contd)

• Multi-hop ad hoc networking

Kelly
Carey
102
Example 3 (Contd)

• Multi-hop ad hoc networking

Kelly
Carey
103
Example 3 (Contd)

• Multi-hop ad hoc networking

Kelly
Carey
104
Example 3 (Contd)

• Multi-hop ad hoc networking

Kelly
Carey
105
Example 3 (Contd)

• Multi-hop ad hoc networking

Kelly
Carey
106
Example 3 (Contd)

• Multi-hop ad hoc networking

Kelly
Carey
107
Example 3 (Contd)

• Two interesting subproblems
• Dynamic ad hoc routing node movement can disrupt
  the IP routing path at any time, disrupting TCP
  connection yet another way to lose packets!!!
  possible solution Explicit Loss Notification
  (ELN)? Handoff? Route prediction?
• TCP flow control the bursty nature of TCP packet
  transmissions can create contention for the
  shared wireless channel among forwarding nodes
  collisions between DATA and ACKs possible
  solution rate-based flow control? Burst mode?
  Spatial reuse of channels?

108
Summary of Wireless TCP

• TCP is the four wheel drive of TPs
• Wireless is a newly emerging technology with
  rapidly growing deployment popularity
• TCP and Wireless dont fit together all
  that well
• Making TCP smarter about wireless helps!

109
7. Wireless TCPPerformance Issues (Part 2)
110
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?

111
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

112
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

113
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)

114
Background USB (contd)

• Queued mode (keep HC busy)
• Transfer size 64 1023 bytes each

115
Background USB (contd)

• Queued mode (keep HC busy)
• Transfer size 64 1023 bytes each

116
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
117
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
118
Results USB Experiments
119
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)

120
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

121
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

122
Results Wireless Problems (MAC-layer rate
adaptation)
123
Summary of Observations

• 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

124
7. Wireless WebPerformance Issues
125
Introduction and Motivation

• Observation the same wireless technology
• that allows a Web client to be mobile also
• allows Web servers to be mobile
• Idea portable, short-lived, ad hoc networks
• Possible applications
• classroom area networks, seminars
• press conferences, media events
• sporting events, gaming, exhibitions
• conferences and trade shows
• disaster recovery sites, field work, etc.

126
Objectives

• to assess feasibility of portable networks
• to benchmark the performance capabilities
• and limitations of an Apache Web server in
• a wireless ad hoc network
• to identify the performance bottlenecks
• to understand impacts of different factors
• number of clients
• Web object size
• persistent connections
• transmit power (energy consumption)
• wireless channel conditions

127
Experimental Setup

• Compaq Notebooks (1.2GHz Pentium III, 128MB RAM,
  
• 512 KB L2 cache, Cisco Aironet 350 network
  cards)
• RedHat Linux 7.3, httperf, Apache 1.3.23,
  SnifferPro 4.6
• Network 11 Mbps IEEE 802.11b wireless LAN, ad
  hoc mode

128
Experimental Setup (Contd)

• IEEE 802.11b a standard for wireless LANs
• Carrier Sense Multiple Access with Collision
  Avoidance
• (CSMA/CA), up to 11 Mbps data rate at physical
  layer
• ad hoc mode
• frames are addressed directly from sender to
  receiver
• httperf
• Web benchmarking software tool developed at HP
  Labs
• Web server Apache (version 1.3.23)
• Process-based, flexible, powerful,
  HTTP/1.1-compliant
• SnifferPro 4.6
• real-time capture, recording all wireless channel
  activity,
• enabling protocol analysis at MAC, IP, TCP and
  HTTP layers

129
 
 
Experimental Design

• Impacts of different factors on wireless Web
  server
• performance (one-factor-at-a-time)

Experimental Factors and Levels

• Performance metrics
• HTTP transaction rate, throughput, response
  time, error rate
• at Application Layer,
• TCP connection duration at Network Layer
• Transmit queue behaviour at Link Layer,

 
 
130
Experiment 1 Request Rate

• Purpose to determine the range of feasible and
  sustainable
• loads for the wireless Web
  server
• Design
• Number of Clients 1
• HTTP transaction rate 10, 20, , 160 req/sec
• HTTP transfer size 1 KB (fixed)
• Persistent connections no
• Transmit power 100 mW
• Client-server distance 1 meter (on same desk)

131
Wireless Web Performance at Application Layer

• Main observation
• As the offered load increases
• linear increase ? instability ? lower
  plateau
• Peak throughput lt 1 Mbps for 1 KB transfers

132
Experiment 2 Transfer Size

• Purpose to study impact of HTTP response size
• Design
• Number of Clients 1
• HTTP transaction rate 10 req/sec (fixed)
• HTTP transfer size (KB) 1, 2, 4, 8,
• Persistent connections no
• Transmit power 100 mW
• Client-server distance 1 meter (on same desk)

133
Measurement at Network Layer
134
Experiment 3 Persistent Connections

• Persistent Connections
• Multiple HTTP transactions can be sent on the
• same TCP connection.
• amortize overhead of TCP connection processing
• reduce memory consumption for TCP state
• Purpose of this experiment to study impact of
• persistent connection on wireless Web
  performance
• Design
• Number of Clients 1 and 2
• HTTP transaction rate 10 req/sec (fixed)
• HTTP transfer size 1 KB (fixed)
• Persistent connections yes
• Transmit power 100 mW
• Client-server distance 1 meter (on same desk)

135
Achieved Throughput for Experiment with
Persistent Connections

• Main observation
• Peak throughput 3.22 Mbps, 3.5x improvement
• over non-persistent connections (0.9 Mbps),
• two clients share the server and network
  resources
• equally

136
Summary and Conclusions

• What we did wireless Web server, portable nw
• Application-layer measurements (httperf)
• Network-layer measurements (Wireless Sniffer)
• Our results show
• Server capability 100 conn/sec for
  non-persistent
• HTTP with throughputs up to 4 Mbps
  (adequate?)
• Bottleneck at wireless network interface
• Some network thrashing for large HTTP
  transfers
• when the network utilization is high (aborts,
  resets)
• Effect of wireless channel on performance at
• TCP and HTTP-level (MAC-layer retransmits)
• Power consumption issue for mobile client and
  server

137
8. Summary,Questions, and Discussion
138
Credits

• Thanks to the following people for the use of
  their slides and/or knowledge
• David Schwab, U of Saskatchewan
• Erich Nahum, IBM
• Sniffer Technologies
• Network Associates
• IEEE
• Guangwei Bai and Tianbo Kuang,U of C