Supporting Rapid Mobility via Locality in an Overlay Network

1. Supporting Rapid Mobility via Locality in an Overlay Network Ben Y. Zhao Anthony D. Joseph John D. Kubiatowicz Sahara / OceanStoreJoint SessionJune 10, 2002

2. Intro Algorithms Evaluation Conclusion Ubiquitous Computing to the Edge • Trends • Network infrastructure growing fast (802.11b, 3G) • Edge devices getting smaller, more powerful • Edge devices increasing in storage capacity • Legacy mobility support not enough • Mobile IP focused on single roaming nodes • # of mobile devices reaching critical mass • E.g. ~400 million Cellphones, PDAs • Sheer volume can overwhelm mobility infrastructure • Devices need object location support for P2P applications (IM, file sharing, directory services) ravenben@eecs.berkeley.edu

3. Intro Algorithms Evaluation Conclusion Pushing the Limits of Mobility • What is the next step? • Scenario I • UCB Professor roaming to MIT, directing streaming media to his laptop, participating in video-conference • Need: persistent connection with low latency delivery, and fast handover between proxies • Scenario II • Morning ride on BART, 100-1000 wired commuters switching from proxy to proxy in tandem • Need: scalable solution to proxy handover for large mobile groups (tourist groups, airplane passengers, etc…) ravenben@eecs.berkeley.edu

4. Intro Algorithms Evaluation Conclusion Legacy Mobility Support • Mobile IP review • Mobile Host (MH), Correspondent Host (CH)Home Agent (HA), Foreign Agent (FA) • Path: CH  HA  FA  MH • Issues • Triangle routing (High RDP) • More fault-prone • Higher BW ravenben@eecs.berkeley.edu

5. Intro Algorithms Evaluation Conclusion What Do We Need and Why? • Mobile IP weakness: triangle routing • High latency for messages and location updates • Messages / updates incur high costs in wide-area • Messages / updates susceptible to wide-area routing failures • Key insight: scalability via locality-awareness • Client requests result in load on overall network • Dampen / confine the impact of network operations:reduce wide-area storage / communication costs, faults • In practice: minimize routing and update latency by localizing communication • Strategy: • Leverage locality-aware overlay infrastructure: Tapestry ravenben@eecs.berkeley.edu

6. Intro Algorithms Evaluation Conclusion Tapestry Review • Decentralized object location and routing overlay • Related to approach in PRR97 • Related projects: Pastry, Chord, CAN, Kademlia • Routing infrastructure based on prefix routing • Route to nearest node increasing prefix match by 1 AA93  4A6D  4361  437A  4378 • Locality-aware design: • Proximity routing: local traffic confined to local network • Object location: replicate Log(N) pointers to object, place disproportionate more replicates near object • Result: RDP of routing to node is smallFinds closest copy of object with low RDP ravenben@eecs.berkeley.edu

7. Intro Algorithms Evaluation Conclusion Object Location and Routing ravenben@eecs.berkeley.edu

8. Intro Algorithms Evaluation Conclusion Mobile Tapestry • Reduce mobility problem to object location • Register (MN) = Proxy “publish” object MN with reverse forwarding path • Routing to MN = Find object MN + forward by proxy • No HA, no FA, no triangle routingThe Internet is your home network! ravenben@eecs.berkeley.edu

9. Intro Algorithms Evaluation Conclusion Registration and Routing R(mn) • Mobile node mn registers with nearby proxy P • RegisterMsg R publishes object named mn atnode P • Nodes store locationmapping <mn, P> • Message for mn routesto P, then to mn • Object location locality  distance traveled by message proportional to actual distance between CH and P A B CH P2 P1 mn RegisterMsg Message to mn ravenben@eecs.berkeley.edu

10. Intro Algorithms Evaluation Conclusion Location Updates R(mn) • mn moves from P1 to P2sends ProxyHandoverMsg U • mn sets up forward link fromP1 to P2 • Update message U routesup until intersects old route at B • U backtracks to P1 to delete old references • Message M forwardedas RouteObjMsg toproxy P2, then to mn • Routing locality  distance traveled by update “proportional” to distance between proxies A B CH P2 P1 mn UpdateMsg Message to mn ravenben@eecs.berkeley.edu

11. Intro Algorithms Evaluation Conclusion Mobile Objects • Extending object location to mobile nodes • Access data on roaming devices • Mobile object location • Extra step of indirection • CH routes message to mobile object MO • Route msg to MO, find <MO, MN> • Route msg to mobile address MN, find <MN, P> • Route msg to proxy P, then forward ravenben@eecs.berkeley.edu

12. Intro Algorithms Evaluation Conclusion P B Mobile Objects R(mn) R(mo) A CH <mo, mn> mn location update forwarding pointer ravenben@eecs.berkeley.edu

13. Intro Algorithms Evaluation Conclusion Hierarchical Mobility • Scenario: • Networked bullet train in motion • Carrying passengers with 1000 networked devices • Train server is node in mobile Tapestry • Server registers with nearby proxies Px as node S • Each proxy Px updates location of S • Each mobile device registers with train as MDi • Server publishes MDi as local object<MDi, S> for all i • CH sends message to a device • Message routes to Di, finds mapping for S • Message routes towards S, routes to P, then S, then Di. ravenben@eecs.berkeley.edu

14. Intro Algorithms Evaluation Conclusion B P2 P1 bullet train S md2 md1 md3 md4 md5 Hierarchical Mobility R(S) R(md1) A CH <md1, S> location update forward pointer ravenben@eecs.berkeley.edu

15. Intro Algorithms Evaluation Conclusion Levels of Type Indirection • Functionality enabled by multiple levels of indirection • Mobile node = object on static node (proxy) • Mobile object = object on mobile node • Mobile child = object on mobile node (proxy) • Potentially limitless levels of indirection for hierarchy of mobile devices Proxy Node residing on Object onStatic Node Indirection as Mobile Node residing on Object onMobile Node Indirection as Mobile Child residing on Object onMobile Child ravenben@eecs.berkeley.edu

16. GUID Aliasing • Utilize redundancy for performance and stability • Each node gets several aliases • Generated by SHA-1(nodeID, int i) for (0 < i < 5) • Usage • CH sends message to ALL aliasesMN receives first, drops duplicates • On initializing connection, CH sends message to ALL aliases. MN responds and indicates preferred alias.All subsequent communication uses chosen alias. ravenben@eecs.berkeley.edu

17. Intro Algorithms Evaluation Conclusion Simulation Framework • Packet level simulation • Simulation of network topologies (5000 nodes, 4096 Tapestry nodes, 6 digit base 4 IDs for nodes / objects) • No simulation of congestion or network-level traffic flow • Experiments on GT-ITM topology • Aggregated over 9 topologies • Each run over 3 random overlay placements • GUID aliasing • Initiate connection by using 3 parallel aliases • Quickly measure and pick alias for good performance ravenben@eecs.berkeley.edu

18. Intro Algorithms Evaluation Conclusion GUID Aliasing vs. Mobile IP ravenben@eecs.berkeley.edu

19. Intro Algorithms Evaluation Conclusion Update Latency w/ Rapid Mobility ravenben@eecs.berkeley.edu

20. Intro Algorithms Evaluation Conclusion Router Load vs. Mass Mobility ravenben@eecs.berkeley.edu

21. Intro Algorithms EvaluationConclusion Summing It Up… • Mobility via indirection • Mobile nodes register as “objects” in infrastructure • Messages to mobile node redirect through location pointer • Distinctions from ROAM: all based on locality-awareness • Performance • Tapestry routes with locality  low RDP for routing (even with indirection), fast location updates • Extreme scalability • Localize traffic around shortest path, stabilize wide-area • Use multiple levels of indirection for hierarchical mobility • Fault-tolerance • Reduce susceptibility to wide-area faults by localizing wide-area traffic ravenben@eecs.berkeley.edu

22. Intro Algorithms EvaluationConclusion For More Information… • Tapestry / Bayeux / Brocade • http://www.cs.berkeley.edu/~ravenben/tapestry • Locality-awareness Mechanisms for Large-scale NetworksZhao, Joseph, Kubiatowicz. Proc. of FuDiCo 2002 • OceanStore • http://oceanstore.cs.berkeley.edu • Other relevant material: • http://www.cs.berkeley.edu/~ravenben ravenben@eecs.berkeley.edu

23. Intro Algorithms Evaluation Conclusion Backup slides follow… ravenben@eecs.berkeley.edu

24. Intro Algorithms Evaluation Conclusion GUID Aliasing ravenben@eecs.berkeley.edu

25. Intro Algorithms Evaluation Conclusion Towards Uniquitous Computing • Applications driving force • Leveraging resources on a global scale • Storage: file sharing, multimedia  Rio, I-Pod • Connectivity: decentralized communication  AIM/ICQ • How close are we? • Networking, Hardware scaling down, HCI, management, … • Some issues getting closer with time • Devices decreasing in size • Increasing in power (Moore’s law) • Network connectivity expanding ravenben@eecs.berkeley.edu

26. Intro Algorithms Evaluation Conclusion Ongoing Issues I • Enabling edge devices • Less resources • Disconnected / mobile operation • Need infrastructure support ravenben@eecs.berkeley.edu

27. Intro Algorithms Evaluation Conclusion Ongoing Issues II • Extending scale • Network increasing in size and complexity • Faults, misconfiguration, flash-crowds result in loss of availability ravenben@eecs.berkeley.edu