Network Protocols: Design and Analysis-Wireless and Mobile

(1)

Network Protocols:

Design and Analysis

Polly Huang EE NTU

http://cc.ee.ntu.edu.tw/~phuang phuang@cc.ee.ntu.edu.tw

(2)

Wireless and Mobile:

What’s Really Different from tradition

?

• wireless

– could be celluar (computers tal k to nearest access point/basest ation) vs. ad hoc (peer comput ers form their own multi-hop n etwork)

• transmission media is air, interfere nce from other radios and obsticals => much less reliable

– higher error rates

– but can be mitigated by PHY-l evel work (coding, etc.)

• not everyone can hear each other • speed—wireless is slower

– no physical media, limited spe ctrum

• mobile

– locations change => routing needs to change

• what basestation are you talking to

– security: (both mobile and wireless) • you connect to diff nets (do you

trust them?)

• network may not trust users (ea vesdropping)

– limited energy – scale?

• sometimes scale is not importan t (ex. get to basestation and then go to the internet over wires) • scale in ad hoc is open question

(3)

Polly Huang, NTU EE 3

Dimensions of Wireless/Mobile

• mobility

– one-hop to base-station vs. ad hoc/multi-hop

• wireless

– fixed vs. mobile

• protocols

– IP vs. cell phone (3G) vs. ???

• constraints:

– energy – radio range – antenna directionality

• trust

– do you trust others to forward your data

– to overhear your packets

• app-level issues

– even if you have connectivity, what can you do?

• ex. it may be easier to share files with floppies!

• often e-mail must go through a central server

(4)

Class Approach

• Lots of work in mobile/wireless

• We will just look at a small sample

– link-layer: MACAW

– routing: Mobile IP and DSR

– transport-layer: SNOOP

(5)

MACAW

[Bhargahavan94a]

(6)

Key ideas

• hidden terminal problem

– not everyone hears the same thing, so two

people can talk over each other without

realizing

• set of MAC-level algorithms that resolve

wireless-specific cases

(7)

Wireless MAC Options

• Contention-based vs. token-bas ed

– why contention? low delay if tfc is light, easy to be rob ust (to node movement, batt ery exhaustion, etc.)

– why token? fairness, esp. u nder high loads, low numbe rs of collision

– MACAW: contention; 802. 11 contention (to get started and in ad hoc mode), token-like scheme in infrastructur e mode

• Base-station vs. ad hoc

– why base-station? more reliable—pre-position base stations, better

coordination/more centralized control, easy to get to internet (base station connected to wired net), simpler routing

– why ad hoc? more robust—no single point of failure, allows you to talk to computers near you, no pre-configuration needed

– MACAW; 802.11 both support both, but 802.11 deployments are mostly base stations

(8)

Radio Propagation

• Simple model: fixed tx ran

ge

– propagation can be r -3 or r – 1 (near or far)

– issues: collisions, capture, i nterference

– good simple model, but onl y an approximation

• Reality is much worse

– multipath fading – time-varying effects

connectivity from one node to others

% p kt s re ce iv ed to 5 d es ts

time since start (in hours)

(9)

Carrier Sense in Wireless

• Carrier Sense: before

transmitting, check if

carrier present

– works in Ethernet

– why not for wireless?

because receiver and

sender have different

“carrier senses”

• Issues: hidden and

exposed terminals

A

B

C

exposed terminal hidden terminal

A

B

C

A

B

C

(10)

Karn/MACA’s RTS-CTS

• Src sends Ready-to-Send (RTS) before data

– overhearers defer for CTS

• Dest replies with Clear-to-Send (CTS)

– overhearers defer for data

• RTS around src, CTS around dest, so ev eryone should be quiet

– in MACA: only quiet for next part – in 802.11 quite for whole exchange – why diff? xxx

• Must also deal with collisions, etc.

hidden terminal scenario

A

B

C

A sends RTS  B gets RTS and sends CTS  C hears CTS and is quiet (no hidden terminal)

(11)

Backoff Issues

• Backoff algorithm:

– backoff counter bo estimates p opulation

– randomly wait [0,bo] before se nding

– orignal: binary exponential:

• bo = 0 after success

• bo *= 2 after carrier sense

• Problem: channel capture

– if I succeed, my bo = 0, so I a m likely to win again

– others who fail get slower and slower…

• Fixs:

– share bo (send in each pkt) – increase multiplicatively, de

crease additively (“MILD”) – per-destination backoff

A

(12)

Adding Link-level ACKs

• Wireless losses possible

– noise or collisions

– end-to-end argument?

• Add link-level ACK of DA

TA

– lost DATA => no ACK => r

etx

– lost ACK => sender retx RT

S, receiver sends ACK inste

ad of CTS

A

B

C

A sends RTS  B gets RTS and sends CTS A sends DATA B sends ACK

if no ACK, A resends RTS

(13)

Continuing Fairness Problems

• An exposed terminal may not be able to compete effectively

– C doesn’t know if RTS/CTS was successful,

– … so reduced to trying at random times

– tends to back-off more and more

• Fix:

– carrier sense

– …or a DS packet

• Doesn’t solve all fairness issues (try A sends to B)

A

B

C

B sends RTS  A gets RTS and sends CTS; but C misses CTS  B sends DS  C hears DS (and data length) and so knows when to try RTS again

 B sends DATA  C knows to RTS after data

(14)

Commercializing MACAW:

IEEE 802.11

• Standard for wireless communication

• MAC-layer uses many of the ideas

discussed

– Basic MAC is a CSMA/CA

• Carrier-sense and transmit, ACK

– RTS/CTS exchange is optional

• Allows two modes

– ad-hoc (DCF; Distributed Coordination Function)

– base-station (PCF; Point Coordination Function)

DCF

(15)

802.11 Comments

• much more complex th

an MACAW (because

it’s real, and because it

’s designed by commit

tee)

• doesn’t include all of

MACAW (less empha

sis on fairness, ex. no

shared backoff)

• spec assumes that all

nodes can hear all others

at all times

– but in practice it’s used ad hoc/multi-hop

• infrastructure mode (PCF)

is run by access point in a

TDMA-like style

• includes several PHY

schemes (IR, FH, DS,

multiple bit rates)

(16)

Mobile IP

[Johnson96b]

(18)

Key ideas

• idea of Mobile IP

• problem: IP combines location and addressing

– applications know your IP address, but when you move,

your IP address changes

• point of mobile IP: move without changing your

IP address

• basic approach: a home agent forwards packets

sent to you to your current location

(19)

Mobile IP

• How do we deliver IP packets when the endpoints

move?

• Issues: addressing and routing

• Key design considerations

– Scale (many mobile nodes)

– Incremental deployment / backwards compatibility

• Result: Mobile IP, RFC 2290

(20)

Possible Approaches

• Why not just announce a route to your host?

– doesn’t allow aggregation

• Why not re-address your host?

– if I change my address, how do people find me?

– could do dynamic DNS (but dynamic DNS was after

this work)

– and even with dynamic DNS, existing connections

can’t survive renumbering

• Why not separate naming and addressing?

(21)

Mobile IP Terminology

FA

Foreign Agent (FA)

HA

Home Agent (HA)

Mobile Host (MH)

home network (HN) corresponding host (CH)

CH

(22)

Discovering Agents

HA FA

Routers periodically beacon

ICMP router advertisements

Q: How do laptops usually figure things out? Why not use that?

A:

Today most laptops use DHCP (but DHCP not available in ’96)

CH

(23)

Registration

HA FA

MH registers with FA

when it travels and get

s temp local IP addr

FA informs HA so HA

always knows

Issues: security

CH MHhome MHtemp-local

(24)

Tunneling

HA FA

CH

CH sends pkt to MH’s IP address like normal

HA intercepts pkt (us es same IP network a s MH) and tunnels pk t to FA FA gets tunneled pkt, decapsulates i t, sends it to MHte mp-local MHtemp-local

MH’s reply can then go straight back to the CH

(25)

Tunneling Inefficiency

HA FA

CH

MHtemp-local

what is wrong with this picture?

data must always go through

HA

fix?

would like to cache MH(temp-local)

(26)

Other Mobile IP Issues

• Route optimality

– resulting paths are not optimal, they all go through the

HA

– can be improved with route optimization

• smart senders keep cache of FA & MHlocal-temp

• one more thing to keep updated

• Smooth handoffs

– don’t want to drop pkts when changing FAs

• Authentication

(27)

The IETF Mobile IP Approach

• A location registry

– HA, FA,

tunneling, etc.

– keeps track of

where you are

– forwards packets

to you

• Pros:

– decouple location and addressing whil e preserving backwards compatiliby – easy to deploy

– reasonable scalabity

• Cons:

– triangle routing – security

– is this really necessary?

• most current computers aren’t ser vers, just clients

• and today people don’t care about keeping one connection open whil e they move

• (but what about tomorrow?) • and what about end-to-end?

(28)

Ad hoc Routing

[Johnson96c]

(30)

Key ideas

• for fixed nodes, you can do lots things for

routing (static, landmark, regular internet)

• what about mobile nodes?

– [Johnson96c] proposes ad hoc routing, DSR:

Dynamic Source Routing

– compare to mobile IP: w/ad hoc there is no

sever (home/foreign agent)

(31)

Mobile Routing Alternatives

• Why not just assume a base station?

– single point of failure, and there may not be a base stati

on where we want

• Why not just use regular Internet routing?

– with mobile nodes, route changes are very frequently

• Why not just flood the data to all nodes?

– would be expensive, but may be cheaper than maintaini

ng routes if the nodes move very quickly & continuious

ly

(32)

General Ad Hoc Routing

• assumptions:

– multi-hop routing (all nodes for ward data)

– wireless nodes – typically mobile

– typically trustworth (more or les s)

– want low energy consumption

• implications

– cannot really use hierarchical ad dressing

– should assume things will chang e

• approaches:

– a priori protocols

(DSDV, TORA)

pre-compute routing tables

– on-demand protocols

(DSR, AODV)

compute routes lazily

(only when needed)

– (other researchers have

proposed the obvious

hybrid schemes, too)

(33)

Ad-Hoc Routing Goals

• Paths should be:

– multi-hop paths

– loop-free

– inexpensive to set up

– robust to node moveme

nt

• System should autoco

nfigure, adapt to move

ment

• low memory, bandwid

th, energy req’d

– scalable with numbers

of nodes

– localize effects of link

failure

• multicast?

(34)

Problems with traditional

approaches

• Periodic (a priori) routing or LS updates are expensi

ve

• Dynamic topology problems:

– frequent LS updates

– algorithm must converge very quickly to avoid blackholes

• Many “links” in wireless (many nodes can hear each

other) => large rtg tables/msgs

• Not studied in the context of realistic radio propagati

on models, MAC layers and mobility patterns

(35)

Problems using DV or LS

• DV protocols may form loops

– very wasteful in wireless: bandwidth, power

– loop avoidance sometimes complex

• LS protocols: high storage and

communication overhead

(36)

Proposed Protocols

• Destination-Sequenced Distance Vector (DSDV)

– hop-by-hop, DV protocol w/periodic routing update broadcasts (a priori)

• Temporally-Ordered Routing Algorithm (TORA)

– on demand creation of hop-by-hop routes based on

link-reversal

– depends on IMEP (a priori) for connectivity info

• Dynamic Source Routing

(DSR)

– on demand source route discovery

• Ad Hoc On-Demand

Distance Vector (AODV)

– combination of DSR and DSDV: on demand route discovery with hop-by-hop routing

(37)

DSR

• Components:

– route discovery

– route maintenance

• Route discovery - basic idea

– S broadcasts route-request to D

– each node forwards request by adding own

address and re-broadcasting

(38)

Route Requests (RREQ)

and Replies (RREP)

• A request (w/new hop) is forwarded if:

– not a duplicate

– node is not the destination (if D, then send RREP reply)

– node not already listed in recorded source route (loop

suppression)

• Replies at D are returned to S via

– source route from D’s cache

– invert source route (not preferred because of potential

radio asymmetry)

(39)

Route Maintenance

• several options to detect broken “links”

– use link-level info (if present)

– passive ACKs (listen for data to be forwarded)

– end-to-end

(40)

Route Cache

• Keep all source routes in route cache (reuse if poss

ible)

• Can short-circuit RREQs if it matches the cache

– just generate a reply

– but make sure you don’t step on your neighbors

(41)

Other Optimizations

• Piggybacking

– Data messages on the initial route request – Reply messages on the reverse route request – Need to do this carefully

• … interacts with route cache optimization

• Hop short-cuts

– If a node notices that the packet has skipped a hop, it can send an unsolicited route reply

• Optimized error handling

– Rate limiting requests: need to worry about partitions – Snooping error messages

(42)

Sending Data

• Check cache for route to D

• If route exists then

– if reachable in one hop

• send packet

– else insert routing header to D and send

• If route does not exist, buffer packet and do

route discovery

(43)

Performance Evaluation

• Models for

– traffic: random pairs sending pseudo-CBR

– mobility: random waypoint

– node placement: random

• Metrics

– path-length relative to optimal

(44)

Mean Route Length vs.

Movement

[Johnson96c],figure 7 _{number of}

nodes

(45)

Discussion

• Source routing is good for on-demand

routes instead of a priori distribution

• Route discovery protocol used to obtain

routes on demand

– Caching used to minimize use of discovery

• Periodic messages avoided

• But need to buffer packets

(46)

Snoop and Handoff

[Balakrishnan95a]

(48)

Key ideas

• transport layer issues in wireless networks?

– handoff management

– loss rates/loss recovery

(49)

Problem: TCP Loss Handling and

Wireless

• TCP assumes loss implies congestion

– TCP’s reaction:

slow down/back off

• Wireless adds losses due to corruption, collision,

handoff

– desired reaction:

retransmit

• Approach:

– them: base-station will cache packets and help repair

losses

(50)

Alternatives

• Why not make TCP distinguish congestion vs. other kinds

of loss?

– decbit-like, Explicit Congestion Notification (ECN)

• Split-connection TCP:

– use one TCP connection BS, another to MH

– must keep TCPs in sync, must modify appliaction, chan

ge TCP semantics, must know which parts of link get w

hich kind of TCP/loss

• Link-layer retx

– can’t count on just LL reliabilty (need e2e)

– can get interactions between LL reliability and TCP reli

abilty if the LL takes a long time (i.e., about the same ti

me as TCP)

(51)

Constraints

• Incremental deployment

– Solution should not require modifications to

fixed hosts

– If possible, avoid modifying mobile hosts

• Preserve TCP end-to-end semantics

(52)

Snoop Overview

FH MH Fixed Host (FH) sends data to MH no change to FH code Mobile Host (MH) receives data,