1 / 73

15-446 Networked Systems Practicum

15-446 Networked Systems Practicum. Lecture 20 – Mobility. Overview. Internet mobility TCP over noisy links Mosh CODA LBFS. Routing to Mobile Nodes. Obvious solution: have mobile nodes advertise route to mobile address/32 Should work!!! Why is this bad?

emelda
Download Presentation

15-446 Networked Systems Practicum

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 15-446 Networked Systems Practicum Lecture 20 – Mobility

  2. Overview • Internet mobility • TCP over noisy links • Mosh • CODA • LBFS

  3. Routing to Mobile Nodes • Obvious solution: have mobile nodes advertise route to mobile address/32 • Should work!!! • Why is this bad? • Consider forwarding tables on backbone routers • Would have an entry for each mobile host • Not very scalable • What are some possible solutions?

  4. How to Handle Mobile Nodes?(Addressing) • Dynamic Host Configuration (DHCP) • Host gets new IP address in new locations • Problems • Host does not have constant name/address  how do others contact host • What happens to active transport connections?

  5. How to Handle Mobile Nodes?(Naming) • Naming • Use DHCP and update name-address mapping whenever host changes address • Fixes contact problem but not broken transport connections

  6. How to Handle Mobile Nodes? (Transport) • TCP currently uses 4 tuple to describe connection • <Src Addr, Src port, Dst addr, Dst port> • Modify TCP to allow peer’s address to be changed during connection • Security issues • Can someone easily hijack connection? • Difficult deployment  both ends must support mobility

  7. How to Handle Mobile Nodes?(Link Layer) • Link layer mobility • Learning bridges can handle mobility  this is how it is handled at CMU • Encapsulated PPP (PPTP)  Have mobile host act like he is connected to original LAN • Works for IP AND other network protocols

  8. How to Handle Mobile Nodes?(Routing) • Allow mobile node to keep same address and name • How do we deliver IP packets when the endpoint moves? • Can’t just have nodes advertise route to their address • What about packets from the mobile host? • Routing not a problem • What source address on packet?  this can cause problems • Key design considerations • Scale • Incremental deployment

  9. Basic Solution to Mobile Routing • Same as other problems in computer science • Add a level of indirection • Keep some part of the network informed about current location • Need technique to route packets through this location (interception) • Need to forward packets from this location to mobile host (delivery)

  10. Interception • Somewhere along normal forwarding path • At source • Any router along path • Router to home network • Machine on home network (masquerading as mobile host) • Clever tricks to force packet to particular destination • “Mobile subnet” – assign mobiles a special address range and have special node advertise route

  11. Delivery • Need to get packet to mobile’s current location • Tunnels • Tunnel endpoint = current location • Tunnel contents = original packets • Source routing • Loose source route through mobile current location

  12. Mobile IP (RFC 2290) • Interception • Typically home agent – a host on home network • Delivery • Typically IP-in-IP tunneling • Endpoint – either temporary mobile address or foreign agent • Terminology • Mobile host (MH), correspondent host (CH), home agent (HA), foreign agent (FA) • Care-of-address, home address

  13. Mobile IP (MH at Home) Packet Correspondent Host (CH) Internet Visiting Location Home Mobile Host (MH)

  14. Mobile IP (MH Moving) Packet Correspondent Host (CH) Internet Visiting Location Home Home Agent (HA) Mobile Host (MH) I am here

  15. Mobile IP (MH Away – FA) Packet Correspondent Host (CH) Mobile Host (MH) Internet Visiting Location Home Encapsulated Home Agent (HA) Foreign Agent (FA)

  16. Mobile IP (MH Away - Collocated) Packet Correspondent Host (CH) Internet Visiting Location Home Encapsulated Home Agent (HA) Mobile Host (MH)

  17. Other Mobile IP Issues • Route optimality • Resulting paths can be sub-optimal • Can be improved with route optimization • Unsolicited binding cache update to sender • Authentication • Registration messages • Binding cache updates • Must send updates across network • Handoffs can be slow • Problems with basic solution • Triangle routing • Reverse path check for security

  18. Overview • Internet mobility • TCP over noisy links • Mosh • CODA • LBFS

  19. Performance Degradation Expected TCP performance (1.30 Mbps) TCP Reno (280 Kbps) Sequence number (bytes) Time (s) 2 MB wide-area TCP transfer over 2 Mbps Lucent WaveLAN

  20. 0 3 2 1 2 2 2 Loss  Congestion Wireless Bit-Errors Router Computer 1 Computer 2 Loss  Congestion Wireless Burst losses lead to coarse-grained timeouts Result: Low throughput

  21. TCP Problems Over Noisy Links • Wireless links are inherently error-prone • Fades, interference, attenuation • Errors often happen in bursts • TCP cannot distinguish between corruption and congestion • TCP unnecessarily reduces window, resulting in low throughput and high latency • Burst losses often result in timeouts • Sender retransmission is the only option • Inefficient use of bandwidth

  22. Proposed Solutions • Incremental deployment • Solution should not require modifications to fixed hosts • If possible, avoid modifying mobile hosts • End-to-end protocols • Selective ACKs, Explicit loss notification • Split-connection protocols • Separate connections for wired path and wireless hop • Reliable link-layer protocols • Error-correcting codes • Local retransmission

  23. Approach Styles (End-to-End) • Improve TCP implementations • Not incrementally deployable • Improve loss recovery (SACK, NewReno) • Help it identify congestion (ELN, ECN) • ACKs include flag indicating wireless loss • Trick TCP into doing right thing  E.g. send extra dupacks Wired link Wireless link

  24. Approach Styles (Link Layer) • More aggressive local rexmit than TCP • Bandwidth not wasted on wired links • Possible adverse interactions with transport layer • Interactions with TCP retransmission • Large end-to-end round-trip time variation • FEC does not work well with burst losses Wired link Wireless link ARQ/FEC

  25. Overview • Internet mobility • TCP over noisy links • Mosh • CODA • LBFS

  26. Overview • Internet mobility • TCP over noisy links • Mosh • CODA • LBFS

  27. Background • We are back to 1990s. • Network is slow and not stable • Terminal  “powerful” client • 33MHz CPU, 16MB RAM, 100MB hard drive • Mobile Users appeared • 1st IBM Thinkpad in 1992 • We can do work at client without network

  28. CODA • Successor of the very successful Andrew File System (AFS) • AFS • First DFS aimed at a campus-sized user community • Key ideas include • open-to-close consistency • callbacks

  29. Hardware Model • CODA and AFS assume that client workstations are personal computers controlled by their user/owner • Fully autonomous • Cannot be trusted • CODA allows owners of laptops to operate them in disconnected mode • Opposite of ubiquitous connectivity

  30. Accessibility • Must handle two types of failures • Server failures: • Data servers are replicated • Communication failures and voluntary disconnections • Coda uses optimistic replication and file hoarding

  31. Design Rationale • Scalability • Callback cache coherence (inherit from AFS) • Whole file caching • Fat clients. (security, integrity) • Avoid system-wide rapid change • Portable workstations • User’s assistance in cache management

  32. Client Caching in AFS v2 • Client caches both clean and dirty file data and attributes • The client machine uses local disks to cache data • When a file is opened for read, the whole file is fetched and cached on disk • Why? What’s the disadvantage of doing so? • However, when a client caches file data, it obtains a “callback” on the file • In case another client writes to the file, the server “breaks” the callback • Similar to invalidations in distributed shared memory implementations • Implication: file server must keep state!

  33. Design Rationale –Replica Control • Pessimistic • Disable all partitioned writes - Require a client to acquire control of a cached object prior to disconnection • Optimistic • Assuming no others touching the file • sophisticated: conflict detection + fact: low write-sharing in Unix + high availability: access anything in range

  34. What about Consistency? • Pessimistic replication control protocols guarantee the consistency of replicated in the presence of any non-Byzantine failures • Typically require a quorum of replicas to allow access to the replicated data • Would not support disconnected mode

  35. Pessimistic Replica Control • Would require client to acquire exclusive (RW) or shared (R) control of cached objects before accessing them in disconnected mode: • Acceptable solution for voluntary disconnections • Does not work for involuntary disconnections • What if the laptop remains disconnected for a long time?

  36. Leases • We could grant exclusive/shared control of the cached objects for a limited amount of time • Works very well in connected mode • Reduces server workload • Server can keep leases in volatile storage as long as their duration is shorter than boot time • Would only work for very short disconnection periods

  37. Optimistic Replica Control (I) • Optimistic replica control allows access in every disconnected mode • Tolerates temporary inconsistencies • Promises to detect them later • Provides much higher data availability

More Related