c. williamson wireless 2003 tutorial1 wireless internet: protocols and performance carey williamson...

C. WilliamsonWireless 2003 Tutorial 1

Wireless Internet:Protocols and Performance

Carey WilliamsoniCORE Professor

Department of Computer ScienceUniversity of Calgary


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 ---- (10:30-10:45am)


1. Wireless Internet:Introduction


What Is Wireless Networking?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


Two Popular 2.4 GHz Two Popular 2.4 GHz Standards: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” (?)


IEEE 802.11 Organization IEEE 802.11 Organization Tree:Tree:

802.11 IR1 / 2 M bit/s

Infra-Red (IR)

802.11 FHSS1 / 2 M bit/s

2.4 G Hz (FHSS)

802.11 DSSS1 / 2 M bit/s

802.11gData Rates > 20 M bit/s

802.11bHigh Data Rate Extension5.5 / 11 M bit/s

2.4 G Hz (DSSS)

802.11a6 / 12 / 24 M bit/sOptional 9/18/36/54 M bit/s

5 GHz (OFDM )

PHYS L ayer

Security

QOS

802.11eM AC Enhancem ents

802.11 M AC

M A C L ayer

IEEE 802.11W orking G roup


Pros and Cons of 802.11: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


BluetoothBluetooth

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


SecuritySecurity

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)


Guerrilla.net 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


Future of Wireless 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


2. Background:Networking Terminology


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”


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

Application

Transport

Network

Data Link

Physical

001101011...


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

Application

Transport

Network

Data Link

Physical

001101011...


Multi-Hop Wireless Ad Hoc NetworksMulti-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, ...


Example:

Multi-hop “ad hoc” networking

Carey

Kelly


3. IEEE 802.11bWireless LANs


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)


The Basics (Cont’d)

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)


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


Where Does Wireless RF Live?ISM Band: Industrial, Scientific, Medical

902-928 MHz 2400-2483.5 MHz 5725-5850 MHz

802.11/802.11b 802.11a

Bluetooth

Cordless Phones

Home RF

Baby Monitors

Microwave Ovens

Old Wireless


Where does 802.11 live in the OSI?Telnet, FTP, Email, Web, etc.

IP, ICMP, IPX

TCP, UDP

Logical Link Control - 802.2(Interface to the upper layer protocols)

MAC

802.3, 802.5, 802.11

Physical Layer Convergence Protocol

LAN: 10BaseT, 10Base2, 10BaseFLWLAN: FHSS, DSSS, IR

Application

Presentation

Session

Transport

Network

Data Link

Physical

Wireless lives at Layers 1 & 2 only!


Wireless Cells

11 Mbps bandwidth“shared” by all

devices in the Cell!

Access Point coverage

area is called a “Cell”

Range per Access Point is

100m

Access Point Channel 6 ESSID: NAI

• In Canada/US, there are eleven 802.11 channels

• Only channels 1, 6 and 11 are non-overlapping• Each Access Point coverage area is called a “Cell”• Computers can roam between cells


Wireless Cells

Computers can roam between cells

1

6

11

1

1

11


CSMA-CA + AcknowledgementCarrier Sense Multiple Access with Collision Avoidance

• Device wanting to transmit senses the medium (Air)

• If medium is busy - defers

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

How CSMA-CA works:

Latency can increase if “air” is very busy! Devicehas hard time finding “open air” to send frame!

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


CSMA-CA + AcknowledgementCarrier Sense Multiple Access with Collision Avoidance

* SIFS - Short Inter-Frame Space (approx 28 µs)• Every frame is ack’ed - except broadcast and multicast!

“Air” is freefor DIFS

time period

Receive ACK backthat frame was received intact!

send frame

source destination others

DIFS

SIFS

All other devices

must defer while “air” is

busy

data

ack

NA

V:

defe

r access


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


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


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


Long PreambleLong Preamble = 144 bits

• Interoperable with older 802.11 devices

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

128 bit Preamble(Long)

16 bitStart

FrameDelimiter

Signal Speed1,2,5.5

,11Mbps

Service(unused)

Lengthof

Payload

16 bitCRC

Payload0-2312 bytes

Transmitted at 1 Mbps

Transmitted at X Mbps


Short PreambleShort Preamble = 72 bits

• Preamble transmitted at 1 Mbps• PLCP Header transmitted at 2 Mbps• more efficient than long preamble

56 bit Preamble

Payload0-2312 bytes

Transmitted at

1 Mbps

16 bitStart

FrameDelimiter

Signal Speed1,2,5.5

,11Mbps

Service(unused)

Lengthof

Payload

16 bitCRC

Transmitted at

2 Mbps

Transmitted at

X Mbps


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!


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!


4. TCP 101:Transmission Control Protocol


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...


TCP 101 (Cont’d)

TCP is a connection-oriented protocol

SYNSYN/ACK

ACKGET URL

YOUR DATA HERE

FIN FIN/ACKACK

Web Client Web Server


TCP 101 (Cont’d)

TCP slow-start and congestion avoidance

ACK


TCP 101 (Cont’d)


ACK


TCP 101 (Cont’d)

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


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


Time

Seq

Num

X +

Key: X Data Packet + Ack Packet X

XXXX

XXXX

XX

XX

++

++++

+

++++

++


So What?

What can it tell you?

Everything!!!


Time

Seq

Num

X +


XXXX

XXXX

XX

XX

++

++++

+

++++

++

RTT


Time

Seq

Num

X +


XXXX

XXXX

XX

XX

++

++++

+

++++

++

TCPSeg.Size


Time

Seq

Num

X +


XXXX

XXXX

XX

XX

++

++++

+

++++

++

TCP Connection Duration


Time

Seq

Num

X +


XXXX

XXXX

XX

XX

++

++++

+

++++

++

NumBytesSent


Time

Seq

Num

X +


XXXX

XXXX

XX

XX

++

++++

+

++++

++

Avg T

hrou

ghpu

t (Byte

s/Sec

)

Bytes

Sec


Time

Seq

Num

X +


XXXX

XXXX

XX

XX

++

++++

+

++++

++Access

Network Bandwidth(Bytes/Sec)


Time

Seq

Num

X +


XXXX

XXXX

XX

XX

++

++++

+

++++

++

Sender’sFlow ControlWindow Size


Time

Seq

Num

X +


XXXX

XXXX

XX

XX

++

++++

+

++++

++

TCP SlowStart


Time

Seq

Num

X +


XXXX

XXXX

XX

XX

+

+

+

++

+

+

Delayed ACK


Time

Seq

Num

X +

Key: X Data Packet + Ack Packet

XXXX

XXXX

XX

X

++

++++

+

++++

PacketLoss

DuplicateACK


Time

Seq

Num

X +


XXXX

XXXX

XX

X

++

++++

+

+++

X+

Retransmit

Cumulative ACK

+


Time

Seq

Num

X +


XXXX

XXXX

XX

X

++

++++

+

+++

X+

RTO

+


TCP 201 (Cont’d)

What happens when a packet loss occurs?

Quiz Time... Consider a 14-packet Web document For simplicity, consider only a single packet

loss


Time

Seq

Num

X +


XXXX

XXXX

XX

XX

++

++++

+

++++

++


Time

Seq

Num

X +


XXXX

XXXX

XX

X

++

++++

+

+++

++

?


Time

Seq

Num

X +


XXXX

XXXX

XX

X

++

++++

+

+++

++

X +


Time

Seq

Num

X +


XXXX

XXXX

XX

XX

++

++++

+

++++

++


Time

Seq

Num

X +


XXXX

XXXX

XX

X

++

++++

+

++

++

?


Time

Seq

Num

X +


XXXX

XXXX

XX

XX

++

++++

+

+

+++

++


Time

Seq

Num

X +


XXXX

XXXX

XX

XX

++

++++

+

++++

++


Time

Seq

Num

X +


XXX

XXXX

XX

XX

++

++++

+

++

?


Time

Seq

Num

X +


XXX

XXXX

XX

XX

++

++++

+

+++++

X

+


Time

Seq

Num

X +


XXXX

XXXX

XX

XX

++

++++

+

++++

++


Time

Seq

Num

X +


X +?


Time

Seq

Num

X +


XX

X + ++X

XX +

+

+

X +X +X +


TCP 201 (Cont’d)

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


Congratulations!

You are now a TCP expert!


5. HTTP:HyperText Transfer Protocol


Introduction to HTTP

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)

Laptop w/Netscape

Server w/ ApacheDesktop w/ Explorer

http request http request

http response http response


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)


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)

<html><head><meta name=“Author” content=“Erich Nahum”><title> Linux Web Server Performance </title></head><body text=“#00000”><img width=31 height=11 src=“ibmlogo.gif”><img src=“images/new.gif><h1>Hi There!</h1>Here’s lots of cool linux stuff!<a href=“more.html”>Click here</a>for more!</body></html>

sample html file


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 client’s behalf: Is the client’s 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


HTTP Request Format

GET /images/penguin.gif HTTP/1.0User-Agent: Mozilla/0.9.4 (Linux 2.2.19)Host: www.kernel.orgAccept: text/html, image/gif, image/jpegAccept-Encoding: gzipAccept-Language: enAccept-Charset: iso-8859-1,*,utf-8Cookie: B=xh203jfsf; Y=3sdkfjej<cr><lf>

• 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.)


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)


Response FormatHTTP/1.0 200 OKServer: Tux 2.0Content-Type: image/gifContent-Length: 43Last-Modified: Fri, 15 Apr 1994 02:36:21 GMTExpires: Wed, 20 Feb 2002 18:54:46 GMTDate: Mon, 12 Nov 2001 14:29:48 GMTCache-Control: no-cachePragma: no-cacheConnection: closeSet-Cookie: PA=wefj2we0-jfjf<cr><lf><data follows…>

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


Response Types 1XX: Informational (def’d 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


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

We’ll mention relevant socket operations along the way

initialize;forever do { get request; process; send response; log request;}

server ina nutshell


Readying a Server

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

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


Processing a Request

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”

remoteIP = getsockname(newconn);remoteHost = gethostbyname(remoteIP);gettimeofday(currentTime);read(newconn, reqBuffer, sizeof(reqBuffer));reqInfo = serverParse(reqBuffer);


Processing a Request (cont)

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

fileName = parseOutFileName(requestBuffer);fileAttr = stat(fileName);serverCheckFileStuff(fileName, fileAttr);open(fileName);


Responding to a Request

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

read(fileName, fileBuffer);headerBuffer = serverFigureHeaders(fileName, reqInfo);write(newSock, headerBuffer);write(newSock, fileBuffer);close(newSock);close(fileName);write(logFile, requestInfo);


Network View: HTTP and TCP

TCP is a connection-oriented protocol

SYNSYN/ACK

ACKGET URL

YOUR DATA HERE

FIN FIN/ACKACK

Web Client Web Server


Example Web Page

Harry Potter Movies

As you all know,the new HP bookwill be out in Juneand then there willbe a new movieshortly after that…

“Harry Potter andthe Bathtub Ring”

page.html

hpface.jpg

castle.gif


Client Server

The “classic” approachin HTTP/1.0 is to use oneHTTP request per TCPconnection, serially.

TCP SYN

TCP FIN

page.htmlG

TCP SYN

TCP FIN

hpface.jpgG

TCP SYN

TCP FIN

castle.gifG


Client Server Concurrent (parallel) TCPconnections can be usedto make things faster.

TCP SYN

TCP FIN

page.htmlG

castle.gifG

F

S

Ghpface.jpg

S

F

C S C S


Client Server

The “persistent HTTP”approach can re-use thesame TCP connection forMultiple HTTP transfers,one after another, serially.Amortizes TCP overhead,but maintains TCP statelonger at server.

TCP FIN

Timeout

TCP SYN

page.htmlG

hpface.jpgG

castle.gifG


Client Server

The “pipelining” featurein HTTP/1.1 allowsrequests to be issuedasynchronously on apersistent connection.Requests must beprocessed in proper order.Can do clever packaging.

TCP FIN

Timeout

TCP SYN

page.htmlG

castle.gif

hpface.jpgGG


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)


6. Wireless TCP:Performance Issues (Part 1)


Example #1

Wireless TCP Performance Problems

Wired Internet

WirelessAccess

Highcapacity,lowerrorrate

Low capacity,high error rate

Hard to distinguish losseshere from losses here


Example #1 (Cont’d)

Solution: “wireless-aware TCP” (I-TCP, ProxyTCP, Snoop-TCP, split connections...)


Example #2

Wireless TCP Fairness Problems

Wired Internet

WirelessBottleneck

ACK

DATA

DATA

ACK

D

U

AP

Loss of ACK = Loss of DATA


Example #3


Carey

Kelly




Carey

Kelly


Example #3 (Cont’d) 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?


Summary of Wireless TCP

TCP is the “four wheel drive” of TP’s Wireless is a newly emerging

technology with rapidly growing deployment popularity

“TCP” and “Wireless” don’t fit together all that well

Making TCP smarter about wireless helps!


7. Wireless TCP:Performance Issues (Part 2)


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?


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


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


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)


Background – USB (cont’d)

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

DF

BF


Background – USB (cont’d)

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

FSBR


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

netserver Ethernet APnetperf

Sniffer

data

acks

laptopstcpdump


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)

OSLinux

Windows 2000

1.52 Mbps

5.11 Mbps

Throughput


Results – USB Experiments


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)


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%


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


Results – Wireless Problems (MAC-layer rate adaptation)


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 TCP’s data/ACK structure may induce excessive

collisions at the MAC layer on wireless LANs


7. Wireless Web:Performance Issues


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:

o classroom area networks, seminarso press conferences, media eventso sporting events, gaming, exhibitionso conferences and trade showso disaster recovery sites, field work, etc.


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

o number of clientso Web object sizeo persistent connectionso transmit power (energy consumption)o wireless channel conditions


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


Experimental Setup (Cont’d)

• 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 modeframes 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.6real-time capture, recording all wireless channel activity,enabling protocol analysis at MAC, IP, TCP and HTTP layers

129

Experimental Design

Factor Levels Number of Clients 1, 2, 4HTTP Transaction Rate (per-client) 10, 20, 30, …, 160

HTTP Transfer Size (KB) 1, 2, 4, 8, …, 100Persistent Connections no, yesHTTP Requests per Connection 1, 5, 10, 15, …, 60Transmit Power (mW) 1, 5, 20, 30, 50, 100

Client-Server Distance (m) 1, 10, 100

• 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,


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)


Wireless Web Performance at Application Layer

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


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)


Light load: 8 KBDuration: 24 msec Throughput: 2.8 Mbps

Overload: 64 KBDuration: >100 msec Throughput: 4.1 Mbps

Medium load: 32 KBDuration: 67 msec Throughput: 3.9 Mbps

Measurement at Network Layer


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 performanceDesign:

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


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


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


8. Summary,Questions, and Discussion


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

c. williamson wireless 2003 tutorial1 wireless internet: protocols and performance carey williamson...

Documents

r ieee

devices r

williamson wireless

wired internet r

internet connectivity

tutorial8 bluetooth

versatile radios r

g wireless