Tapestry : An Infrastructure for Fault-tolerant Wide-area Location and Routing Presenter : Lee Youn Do Oct 5, 2005 Ben Y.Zhao, John Kubiatowicz, and Anthony D,Josephetc. Computer Science Division University of California, Berkeley

-2/20- Contents Motivation System Overview Operations Measurements Summary

-3/20- Motivation Today’s dynamic nature of the computing environment stresses in many ways traditional approaches to providing object name service, consistency, location and routing. I’m old now.. Scaling current solutions – A house of cards built from many individual houses-of-cards Tapestry!

-4/20- System Overview Tapestry I have object O I want object O Query with Object-ID(O) 3. Query with Object-ID(O) 4. Sending Object O

-5/20- Contents Motivation System Overview Operations – Routing – Surrogate Routing – Node Insertion Measurements Summary – Publishing & Location – Fault Handling – Node Deletion

-6/20- Routing(1/3) Each node can be server, router, and client Objects/Nodes names – Random fixed-length bit-sequence (e.g., B4F8, 9098) – Evenly distributed in namespace – Independent of their locations Using local routing maps – Called neighbor maps

-7/20- Routing(2/3) Suffix matching ( similar to CIDR ) – Incrementally routing digital by digital – Maximum hops : log b (N) 6789 B4F Msg to 4598 B437

-8/20- Routing(3/3) Neighbor Map A table with b*log b (N) entries Entry( i, j ) - Pointer to the neighbor “ j” + (i- 1) suffix 2 Secondary neighbors Back Pointers Soft state

-9/20- Publishing 1. Map the object ID to a virtual node ID 2. Server send the message with the object id and server id 3. Find the surrogate node as the “root” for the object 4. Save the related info there, such as Server :B F734 B Surrogate Routing Location Pointers

-10/20- Locating Client : B4F8 Server : B A Surrogate Routing 1. Client send the query with the object id 2. Route the query to the root node for the object 3. Forward the query to the server

-11/20- Surrogate Routing each nonexistent ID is mapped to some live node with a similar ID Looks for a “close” digit in the neighbor maps Ensuring that arrive at the same unique root node from any location in the Tapestry network The expected number of additional hops is 2

-12/20- Fault Handling Fault-tolerant Routing – Detecting link and server failures Relying on TCP timeouts Using back pointers to send periodic heartbeats – Operation under faults 2 secondary neighbors Second chance Fault-tolerant Location – Multiple root nodes – Republish location information at regular intervals

-13/20- Node Insertion 1. Get an Node ID 2. Begin with a “Gateway node” G (Assuming that knows of a gateway node) 3. Pretends to route to itself 4. Get the neighbor maps from the nodes on route and optimize it 5. Go to the root node for new node ID and moves data meant for new node 6. Send a “hello” message to all neighbors and secondary neighbors Gateway node : B4F F734 B Surrogate Routing New node : 1234 : Neighbor map transfer : Data transfer

-14/20- Node Deletion Trivial problem Informing the relevant parties of its departure using its back pointers Relying on soft state

-15/20- Contents Motivation System Overview Operations Measurements Summary

-16/20- Measurements(1/3) Experiments on a packet level simulator using unit-distance hop topologies Metric – Location Relative Delay Penalty (RDP) The ration of distance traveled via Tapestry, versus that traveled via direct routing to the object – Latency Topologies – TIERS – Transit-stub (generated by GT-ITM)

-17/20- Measurement(2/3) The effect of location pointers

-18/20- Measurement(3/3) The effect of multiple root nodes

-19/20- Summary Tapestry is presented due to need for new Routing/Location scheme Tapestry is – Self-organizing – Scalable – Robust – Adaptable – Distributed

-20/20- Thank you, any question?