1. Nomadic Information Access Hari Balakrishnan S. Devadas, F. Kaashoek, D. Karger, R. Morris, K. Steele, I. Stoica, S. Teller & Several Students MIT Project Oxygen DARPA Ubiquitous Computing Meeting January 22, 2002

2. Imagine this… Harry wakes up in the morning later than he should have. He has a 7am flight to catch. He starts downloading huge ppt files and his email while he gets ready. He’s ready to leave but the download isn’t complete. Cursing, he aborts it and decides to deal with it in DC. He reaches the airport and has a few minutes to spare. He starts to download things again. Same problem. He reaches DC and makes his meeting on time, but he still has to work on his slides. He gets a network connection and starts the painful download. His connection to his office server is reeeeeeallly slow. An hour later, he’s finally ready to start on pulling today’s talk together. He only has 20 minutes left to do this in. To get a good overview of all the stuff he should talk about, he really would like to print some slides. Oops… Harry gives a lousy talk 

3. Instead, what if… Harry wakes up in the morning later than he should have. He has a 7am flight to catch. He starts downloading huge ppt files and his email while he gets ready. He’s ready to leave but the download isn’t complete. He suspends this and decides to resume it later He reaches the airport and has a few minutes to spare. He resumes his long download. Despite the new network and disconnection in-between, it continues from where it left off. He reaches DC and makes his meeting on time, but he still has to work on his slides. He gets a network connection and resumes the download task. Thankfully, his files are in a globally distributed file system and his software finds a nearby set of servers to continue from 2 minutes later, he’s ready to start on pulling today’s talk together. He has 78 minutes left to do this in. Piece of cake! To get a good overview of all the stuff he should talk about, he really would like to print some slides. His location-aware resource discovery system finds an accessible nearby printer and he’s all set

4. Nomadic System Architecture Seamless end-to-end sessions: Migrate Global file access: CFSGlobal resource discovery: INS Scalable decentralized lookups: Chord Context-aware Nomadic applications Location-awareness: Cricket Networked sensors/actuators Ad hoc network integration E21 information Suspend-resume capability for nomadic applications Energy-efficient protocols Secure cooperative file system Finding by intent Internet-scale hashing abstraction “Indoor GPS” within few cms Generic API

5. Migrate: Towards End-to-end Mobility (Alex Snoeren’s dissertation) Naming Service (Dynamic DNS) Mobile Host foo.bar.edu Location Query (DNS Lookup) Session Initiation xxx.xxx.xxx.xxx Correspondent Host Location Update (DNS Update) Session Migration via continuation yyy.yyy.yyy.yyy

6. Migrate Functions Locate the mobile host or service Preserve communication across movement –Support changes in network attachment –Choose best network amongst available choices Expect and support disconnection –Gracefully detect lack of connectivity –Conserve resources during disconnection –Reconnect quickly and efficiently Key idea: Notion of sessions to preserve application connectivity across suspensions –Migrating TCP connections across changes in IP is an important optimization (solves long-standing open issue in TCP design)

7. Session Continuations: A New Abstraction for Nomadic Access 1.Initialization –At beginning of session, exchange information for subsequent migration (crypto token exchange) 2.Disconnection –Identify critical state (a “session continuation”) –Package and store –Suspend applications 3.Resumption –Resynchronize transport, session, and application state –Security achieved by presenting token negotiated in #1 –Restart session A session continuation encapsulates state Exports migration-awareness API for application adaptation Interfaces with connectivity monitor and policy module

8. CFS: Cooperative File System Highly available using aggressive replication Provides robustness under failures –No central server; handles joins and leaves robustly Incremental scaling with new servers Harnesses server resources, cooperatively Provides authentic and secure file access Server Internet Server ( & client)

9. CFS Architecture Layers 995: ID=901 ID=732 Signature File System ID=995 (public key) 732: … 901: “a.txt” ID=144 144: ID=431 ID=795 795: … 431: … (root block) (directory blocks) (i-node block) (data) File System Internet Node A Node C Node B 995: ID=901 ID=732 Signature Block 732 247: ID=407 ID=992 ID=705 Signature Block 407 Block 705 DHash Chord: Maps keys to nodes (e.g., CFS ID’s)

10. Chord: Internet-Scale Hash Tables N32 N10 N5 N20 N110 N99 N80 N60 Circular ID Space Chord maps ID’s to “successor” Nodes and blocks have 160-bit ID’s Successor: Node with next highest ID Stores block IDs 21..32 Block IDs 33..60

11. Basic lookup N32 N90 N105 N60 N10 N120 K80 “Where is key 80?” “N90 has K80” Successor pointer

12. “Finger table” allows log(N)-time lookups N80 ½ ¼ 1/8 1/16 1/32 1/64 1/128 finger[k] points to successor (n + 2 k ) log(n) fingers in all R = log(n) immediate Successors for robustness Stabilization methods for concurrency

13. RON/CFS Deployment ~20 RON nodes running CFS servers in 4 continents Many different Autonomous Systems KAIST, Korea Venezuela MSR, UK

14. Robustness Against Failures Failed Lookups (Fraction) Failed Nodes (Fraction) 1000 CFS servers Average of 5 runs Run before stabilization All failures due to replica failing 50% of nodes disappear but only less than 1.6% of lookups fail

15. INS: Nomadic Resource Discovery [service = printer] [building = schafer [room = *]] Intentional name Late binding: integrate resolution and message routing Lookup schafer-printer@schafercorp.com Resolver self-configuration Intentional name resolvers form an overlay network Uses Chord as underlying hash lookup for scalability [service = printer] [building = schafer [room = 405]] Intentional name

16. Beacons on ceiling B  SPACE=NE43-510 ID=34 COORD=146 272 0 MOREINFO= http://cricket.lcs.mit.edu/ Obtain linear distance estimates: RF + ultrasound Pick nearest to infer “space” Solve for mobile’s (x, y, z) Determine  w.r.t. each beacon and deduce orientation vector Obtain linear distance estimates: RF + ultrasound Pick nearest to infer “space” Solve for mobile’s (x, y, z) Determine  w.r.t. each beacon and deduce orientation vector Mobile device Cricket listener Cricket: Toward Location-Awareness

17. Cricket Architecture Beacon Listener No central beacon control or location database Passive listeners + active beacons preserves privacy Straightforward deployment and programmability No central beacon control or location database Passive listeners + active beacons preserves privacy Straightforward deployment and programmability info = “a1” info = “a2” Estimate distances to infer location

18. A beacon transmits an RF and an ultrasonic signal simultaneously –RF carries location data, ultrasound is a narrow pulse The listener measures the time gap between the receipt of RF and ultrasonic signals –A time gap of x ms roughly corresponds to a distance of x feet from beacon –Velocity of ultrasound << velocity of RF The listener measures the time gap between the receipt of RF and ultrasonic signals –A time gap of x ms roughly corresponds to a distance of x feet from beacon –Velocity of ultrasound << velocity of RF Determining Distance RF data (space name) Beacon Listener Ultrasound (pulse)

19. Ultrasonic sensor RF antenna Ultrasonic sensor RF module (rcv) Atmel processor ListenerBeacon RF module (xmit) RS232 i/f Cricket v1 Prototype Host software libraries in Java; Linux daemon (in C) for Oxygen BackPaq handhelds Several apps…

20. Synergies Seamless end-to-end sessions: Migrate Global file access: CFSGlobal resource discovery: INS Scalable decentralized lookups: Chord Context-aware Nomadic applications Location-awareness: Cricket Networked sensors/actuators Ad hoc network integration E21 information Suspend-resume capability for nomadic applications Energy-efficient protocols Secure cooperative file system Finding by intent Internet-scale hashing abstraction “Indoor GPS” within few cms “Coda” for network applications Data staging (Aura) Oceanstore Philips, Nokia, Intel, Duke, (recently) UW CAN, Pastry, Tapestry SDS, …

21. Summary Several new technologies for context-aware nomadic applications –Migrate, Chord, CFS, INS, Cricket, energy-efficient protocols, sensor/device integration Fundamental new abstractions –Session continuations, cooperative overlays, distributed hash tables, intentional naming, late binding Public-domain prototypes and several papers –Some technologies being used outside of Oxygen What next? –Robust integration of context into application workflow –Software system architecture for embedded + human-centric systems –Dealing with scale and unreliable components –Handling challenging privacy and security issues