Network Protocols: Design and Analysis

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 could be celluar (computers talk to nearest access point/basestation) vs. ad hoc (peer computers form their own multi-hop network) transmission media is air, interference from other radios and obsticals => much less reliable higher error rates but can be mitigated by PHY-level work (coding, etc.) not everyone can hear each other speed—wireless is slower no physical media, limited spectrum 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 (eavesdropping) limited energy scale? sometimes scale is not important (ex. get to basestation and then go to the internet over wires) scale in ad hoc is open question Wireless and Mobile:What’s Really Different from tradition?

3. 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 Dimensions of Wireless/Mobile

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. Contention-based vs. token-based why contention? low delay if tfc is light, easy to be robust (to node movement, battery exhaustion, etc.) why token? fairness, esp. under high loads, low numbers of collision MACAW: contention; 802.11 contention (to get started and in ad hoc mode), token-like scheme in infrastructure 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 Wireless MAC Options

8. Simple model: fixed tx range propagation can be r -3 or r –1 (near or far) issues: collisions, capture, interference good simple model, but only an approximation Reality is much worse multipath fading time-varying effects connectivity from one node to others % pkts received to 5 dests (data from Jerry Zhao, ISI, 2002) time since start (in hours) Radio Propagation

9. A B C hidden terminal 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 A B B C C exposed terminal

10. 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 everyone 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. A B C hidden terminal scenario Karn/MACA’s RTS-CTS • A sends RTS • B gets RTS and sends CTS • C hears CTS and is quiet (no hidden terminal)

11. Backoff algorithm: backoff counter bo estimates population randomly wait [0,bo] before sending orignal: binary exponential: bo = 0 after success bo *= 2 after carrier sense Problem: channel capture if I succeed, my bo = 0, so I am likely to win again others who fail get slower and slower… Fixs: share bo (send in each pkt) increase multiplicatively, decrease additively (“MILD”) per-destination backoff A B C Backoff Issues

12. A B C Adding Link-level ACKs • Wireless losses possible • noise or collisions • end-to-end argument? • Add link-level ACK of DATA • lost DATA => no ACK => retx • lost ACK => sender retx RTS, receiver sends ACK instead of CTS • A sends RTS • B gets RTS and sends CTS • A sends DATA • B sends ACK • if no ACK, A resends RTS

13. A B C 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) • 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 PCF

15. much more complex than MACAW (because it’s real, and because it’s designed by committee) doesn’t include all of MACAW (less emphasis 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) 802.11 Comments

16. Other questions/observations? • denial of service attacks in wireless? • some coding techniques (spread-spectrum or UWB) reduce the problem, but no good fix

17. 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 • Internet standard for support for mobility in IP

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? • breaks backwards compatibility

21. Mobile IP Terminology corresponding host (CH) Foreign Agent (FA) Home Agent (HA) CH FA HA home network (HN) MH Mobile Host (MH)

22. Discovering Agents Routers periodically beacon ICMP router advertisements CH FA HA MH Q: How do laptops usually figure things out? Why not use that? A: Today most laptops use DHCP (but DHCP not available in ’96)

23. MH registers with FA when it travels and gets templocal IP addr FA informs HA so HA always knows Issues: security Registration CH FA HA MHhome MHtemp-local

24. Tunneling CH sends pkt to MH’s IP address like normal FA gets tunneled pkt, decapsulates it, sends it to MHtemp-local CH FA HA HA intercepts pkt (uses same IP network as MH) and tunnels pkt to FA MHtemp-local MH’s reply can then go straight back to the CH

25. Tunneling Inefficiency what is wrong with this picture? data must always go through HA fix? would like to cache MH(temp-local) downside? must change CH! (loses backwards compatibility) CH FA HA MHtemp-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 • don’t want others to claim to be MH!

27. A location registry HA, FA, tunneling, etc. keeps track of where you are forwards packets to you Pros: decouple location and addressing while preserving backwards compatiliby easy to deploy reasonable scalabity Cons: triangle routing security is this really necessary? most current computers aren’t servers, just clients and today people don’t care about keeping one connection open while they move (but what about tomorrow?) and what about end-to-end? The IETF Mobile IP Approach

28. Other questions/observations? • is the home agent a difficult requirement? (single point of failure)

29. 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 station 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 maintaining routes if the nodes move very quickly & continuiously

32. assumptions: multi-hop routing (all nodes forward data) wireless nodes typically mobile typically trustworth (more or less) want low energy consumption implications cannot really use hierarchical addressing should assume things will change 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) General Ad Hoc Routing

33. Paths should be: multi-hop paths loop-free inexpensive to set up robust to node movement System should autoconfigure, adapt to movement low memory, bandwidth, energy req’d scalable with numbers of nodes localize effects of link failure multicast? not here :-) Ad-Hoc Routing Goals

34. Problems with traditional approaches • Periodic (a priori) routing or LS updates are expensive • 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 propagation 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. 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 Proposed Protocols

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 • requests propagate outward until target is found

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) • piggy-backed on another route request from D to S

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 possible) • Can short-circuit RREQs if it matches the cache • just generate a reply • but make sure you don’t step on your neighbors • Can eavesdrop to pre-fill route cache

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 • message count relative to optimal

44. Mean Route Length vs. Movement [Johnson96c],figure 7 number of nodes (continuous movement) (very stable)

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. Other questions/observations? • where do people use ad hoc rtg today? • sensor nets • or military/disaster recovery applications • mesh networking • small-scale sharing w/workgroups could use it, but today most people use floppy disks • vs. most laptop users today use basestations • what are alternatives?

47. 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 • alternative: could do link-level reliability

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, change TCP semantics, must know which parts of link get which kind of TCP/loss • Link-layer retx • can’t count on just LL reliabilty (need e2e) • can get interactions between LL reliability and TCP reliabilty if the LL takes a long time (i.e., about the same time as TCP) • also, how does LL know which pkts need reliability