1. Tapestry : An Infrastructure for Fault-tolerant Wide-area Location and Routing Presenter: Chunyuan Liao March 6, 2002 Ben Y.Zhao, John Kubiatowicz, and Anthony D,Josephetc. Computer Science Division University of California, Berkeley

2. Outline  Challenges  System overview  Operations, concerned issues & solutions Route Route Locate Locate Publish Publish  Evaluation & Conclusion  Implementation  Summary & Comments Insert Insert Delete Delete Move Move

3. Project background  Driving force : Ubiquitous Computing  OceanStore – A data utility infrastructure  Goals: –Based on the current untrusted Infrastructure –Achieve Nomadic Data  Anytime, Anywhere  Highly scalable, reliable and fault-tolerant and fault-tolerant  Basic issues: –Data Location –Routing

4. Challenges  How to achieve naming, location and routing with a complex & chaotic computing environment  Dynamic nature –Mobile and replicated Data & Services –Complex interaction between components, even in motion  Traditional approaches –fail to address the extreme dynamic nature

5. Tapestry : An infrastructure for Fault-tolerant wide-area Location and Routing  An overlay Location & Routing infrastructure built on the IP  Features –Highly scalable : Decentralized, Point-2-PointSelf-Organizing –Highly fault-tolerant: Redundancy, Adaptation –Good locality Content-based routing&location –Highly durable

6. Basic Model of Tapestry  Originated in Plaxton Scheme  Basic components: –Nodes ServersRoutersClients –Objects Data or Services –Link Point-2-Point link

7. Operations in Trapestry  Naming  Routing  Object Location  Publishing Objects  Inserting/Deleting Objects  Mobile Objects

8. Tapestry - Naming  Node ID/Object ID –A fixed length bit string (4 bits in each level ) 84F8, 9098 84F8, 9098 –Global –Randomly generated –Location-Independent –Even distributed –Not unique ( shared by replicas )

9. Routing : Rules  Suffix matching ( similar to Plaxton ) –Incrementally routing digital by digital –Maximum hops : log b (N) 6789 B4F8 9098 7598 4598 Msg to 4598 B437

10. Routing : Neighbor maps A table with b*log b (N) entries The i-th level neighbor share (i-1) suffix chunks Entry( i, j ) Pointer to the neighbor “ j” + (i-1) suffix Secondary Neighbors Back Pointers Create bi-direction link 0642

11. Routing : Fault-tolerant  Detect Server/Link failure –TCP time out( Ping ) –Periodic “heart beat” msg along back pointers  Resist fault –Secondary neighbor  Recover –Probing message –Second Chance

12. Locating : basic procedure  4 phrases locating –Map the Object ID to a “virtual” Node ID –Route the request to that node –Arrive the surrogate or“root for the object –Direct to the server Client : B4F8 Server : B346 1234 8724 F734 B234 6234 Surrogate Routing

13. Locating : Surrogate Routing(1)  Given any client at different place, how to find the same “root”? –Plaxton 1.Find the nodes with the maximum matching suffix (Stop at the empty entry in neighbor map) 2.Order them with the global knowledge 3.Choose the No.1 –Tapestry 1.Go further than Plaxton( choose an alternate entry ) 2.Stop at a neighbor map where there is only one non-empty entry pointed to node R 3.R is the root

14. Locating : Surrogate Routing(2) F3145 E1145 51145 B7645 B3467 12345 B3945 92145 B1145 Assumption: 1.Every node is reachable Ensure the same “patterns” 2.Even distributed ID Ensure less and less nodes in mapping table Conclusion: 1. Root can always be found 2. E. of Sur. Route is 2

15. Publishing  Similar to locating 1.Server send msg and pretends to locate the object 2.Find the surrogate node as the “root” for the Obj. 3.Save the related info there, such as 3.Save the related info there, such as Server :B4F8 1234 8724 F734 B234 6234 Surrogate Routing

16. Locating/Publishing : Fault-Tolerant & Locality  Multiple “root” (better than Plaxton) –Map the Obj. ID to several “root” –Publish/Locate can be executed simultaneously  Cache 2-tuple  Cache 2-tuple –Clients can get the on the way to the root –Intermediate notes can receive multiple for the same Obj., the nearest one is chosen

17. Insert a new node: basic procedure 1.Get an Node ID 2.Begin with a “Gateway node” G 3.Pretends to route to itself 4.Establish nearly optimal neighbor map during the “pseudo routing” by coping & Choosing nearest ones. 5.Go back and notify neighbors Gateway node : B4F8 8724 F734 B234 6234 Surrogate Routing New node : 1234

18. Delete a note Most simple operation  Explicitly notify the neighbors with back pointers  Use Soft sate Don’t send “heart beat” messages and republish messages any more

19. Maintain System Consistency  Components in a Tapestry node –Neighbor map –Back pointers –Object-Location pointers –Hotspot Monitor –Object store  Main correct status –Soft sate –Proactive explicit update

20. Soft state  Advantage –Easy to implement –Suited to slowly changing systems  Disadvantage –Tradeoff between bandwidth overhead and level of consistency –Not suited to the fast changing systems –Example : Bytes for the republishing for a server can be 1400MB (!) in a single interval.

21. Proactive explicit update ( PEU )  Proactive explicit updates –Epoch number  sequence # of the rounds –Expanded 3-tuple    Soft state : backup resort

22. PEU : Node Mobility Root C D E F A * * B Move Object 123 from A to B Republishing (123,B) Deleting (123,A) with “LostHopID”

23. PEU : Recover location pointers Root E F C A Server B Exiting Notification D Reconstruction (O,S,B) Deleting Old Data

24. Introspective Optimization : A dapting to the changing environment  Load balance 1.Periodically Ping by refresher thread 2.Update neighbor pointers  Hotspot 1.Find the source of the heavy traffic, “Hotspot” 2.Pub the desired data near the hotspot

25. Evaluation  Gain –Good Locality –Low Location latency –High Stability –High Fault-tolerence  Cost –Bandwidth overhead linear to the replicas

26. Implementation  Packet level simulators are finished in C  Used to support other applications –such as OceanStore –Bayeus, application-level multicast protocol  Future Working –Security issues –Mobile-IP like functionality

27. Summary  Urgent need for new Location/Routing Scheme  Features of Tapestry –Location-independent naming –Integration of location and routing –Content-based routing –Support for the dynamic environment inserting/deleting/moving Node/Object

28. Comments and Questions  Paradox or discrepancy? The underlying IP has bad scalability, how can Tapestry achieve high scalability? Just for demo!  What’s the relation between the IP and Tapestry? Tapestry doesn’t intend to replace IP, it just tries to establish a higher level locating & routing infrastructure to support the content- based operation.  How can we achieve the same goal without IP?