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

2. ZXL June 10, 2002ravenben@eecs.berkeley.edu 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) Intro Algorithms Evaluation Conclusion

3. ZXL June 10, 2002ravenben@eecs.berkeley.edu 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…) Intro Algorithms Evaluation Conclusion

4. ZXL June 10, 2002ravenben@eecs.berkeley.edu 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 Intro Algorithms Evaluation Conclusion

5. ZXL June 10, 2002ravenben@eecs.berkeley.edu 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 Intro Algorithms Evaluation Conclusion

6. ZXL June 10, 2002ravenben@eecs.berkeley.edu 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 small Finds closest copy of object with low RDP Intro Algorithms Evaluation Conclusion

7. ZXL June 10, 2002ravenben@eecs.berkeley.edu Object Location and Routing Intro Algorithms Evaluation Conclusion

8. ZXL June 10, 2002ravenben@eecs.berkeley.edu Mobile Tapestry Intro Algorithms Evaluation Conclusion 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 routing The Internet is your home network!

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

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

11. ZXL June 10, 2002ravenben@eecs.berkeley.edu 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 – Route msg to mobile address MN, find – Route msg to proxy P, then forward Intro Algorithms Evaluation Conclusion

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

13. ZXL June 10, 2002ravenben@eecs.berkeley.edu 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 P x as node S – Each proxy P x updates location of S Each mobile device registers with train as MD i – Server publishes MD i as local object for all i CH sends message to a device – Message routes to D i, finds mapping for S – Message routes towards S, routes to P, then S, then D i. Intro Algorithms Evaluation Conclusion

14. ZXL June 10, 2002ravenben@eecs.berkeley.edu Hierarchical Mobility bullet train S md1md2md3 md4 md5 P2 P1 B R(S) R(md1) CH A location update forward pointer Intro Algorithms Evaluation Conclusion

15. ZXL June 10, 2002ravenben@eecs.berkeley.edu 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 Mobile Node Mobile Child Object on Static Node Object on Mobile Node Object on Mobile Child residing on Indirection as Intro Algorithms Evaluation Conclusion

16. ZXL June 10, 2002ravenben@eecs.berkeley.edu 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 1. CH sends message to ALL aliases MN receives first, drops duplicates 2. On initializing connection, CH sends message to ALL aliases. MN responds and indicates preferred alias. All subsequent communication uses chosen alias.

17. ZXL June 10, 2002ravenben@eecs.berkeley.edu 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 Intro Algorithms Evaluation Conclusion

18. ZXL June 10, 2002ravenben@eecs.berkeley.edu GUID Aliasing vs. Mobile IP Intro Algorithms Evaluation Conclusion

19. ZXL June 10, 2002ravenben@eecs.berkeley.edu Update Latency w/ Rapid Mobility Intro Algorithms Evaluation Conclusion

20. ZXL June 10, 2002ravenben@eecs.berkeley.edu Router Load vs. Mass Mobility Intro Algorithms Evaluation Conclusion

21. ZXL June 10, 2002ravenben@eecs.berkeley.edu Summing It Up… Intro Algorithms Evaluation Conclusion 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

22. ZXL June 10, 2002ravenben@eecs.berkeley.edu For More Information… Intro Algorithms Evaluation Conclusion Tapestry / Bayeux / Brocade – http://www.cs.berkeley.edu/~ravenben/tapestry http://www.cs.berkeley.edu/~ravenben/tapestry – Locality-awareness Mechanisms for Large-scale Networks Zhao, Joseph, Kubiatowicz. Proc. of FuDiCo 2002 OceanStore – http://oceanstore.cs.berkeley.edu http://oceanstore.cs.berkeley.edu Other relevant material: – http://www.cs.berkeley.edu/~ravenben

23. ZXL June 10, 2002ravenben@eecs.berkeley.edu Backup slides follow… Intro Algorithms Evaluation Conclusion

24. ZXL June 10, 2002ravenben@eecs.berkeley.edu GUID Aliasing Intro Algorithms Evaluation Conclusion

25. ZXL June 10, 2002ravenben@eecs.berkeley.edu 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 Intro Algorithms Evaluation Conclusion

26. ZXL June 10, 2002ravenben@eecs.berkeley.edu Ongoing Issues I Enabling edge devices – Less resources – Disconnected / mobile operation Need infrastructure support Intro Algorithms Evaluation Conclusion

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