1. Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, 11-14 September 2002 1 Why Tapestry is not Pastry Presenter Arnold Pears CoRE Group, Uppsala University

2. Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, 11-14 September 2002 1 Source Material ● This presentation is based on the following. – Slides from the ROC/Sahara Retreat 2002 ● http://www.cs.berkeley.edu/~ravenben/tapestry/ROC-Sahara-1- 2002.pps – Tapestry Technical Report ● http://www.cs.berkeley.edu/~ravenben/publications/CSD-01-1141.pdf – Application Papers ● Oceanstore: http://www.cs.berkeley.edu/~ravenben/publications/pdf/asplos00.pdf ● Bayeux: http://www.cs.berkeley.edu/~ravenben/publications/pdf/bayeux.pdf ● Brocade: http://www.cs.berkeley.edu/~ravenben/publications/pdf/brocade.pdf

3. Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, 11-14 September 2002 1 What is Tapestry? ● A prototype of a decentralized, fault-tolerant, adaptive overlay infrastructure (Zhao, Kubiatowicz, Joseph et al. 2000) ● Network substrate of OceanStore ➢ Routing: Suffix-based hypercube Similar to Plaxton, Rajamaran, Richa (SPAA97) ➢ Decentralized location: Virtual hierarchy per object with cached location references ● Dynamic algorithms using local information ● Core API: ➔ publishObject(ObjectID) ➔ routeMsgToObject(ObjectID) ➔ RouteMsgToNode(NodeID)

4. Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, 11-14 September 2002 1 An Overview of Features ● A brief comparison of Pastry with Tapestry

5. Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, 11-14 September 2002 1 Routing and Location ● Namespace (nodes and objects) ➢ 160 bits length ⇒ 2 80 names before name collision ➢ Each object has its own hierarchy rooted at Root f (ObjectID) = RootID, via a dynamic mapping function ● Suffix routing from A to B ➢ At h th hop, arrive at nearest node hop(h) such that: hop(h) shares suffix with B of length h digits ➢ Example: 5324 routes to 0629 as follows 5324 → 2349 → 1429 → 7629 → 0629 ● Object location: ➢ Root responsible for storing object’s location ➢ Publish / search both route incrementally to root

6. Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, 11-14 September 2002 1 4 2 3 3 3 2 2 1 2 4 1 2 3 3 1 3 4 1 1 43 2 4 Tapestry Mesh Incremental suffix-based routing NodeID 0x43FE NodeID 0x13FE NodeID 0xABFE NodeID 0x1290 NodeID 0x239E NodeID 0x73FE NodeID 0x423E NodeID 0x79FE NodeID 0x23FE NodeID 0x73FF NodeID 0x555E NodeID 0x035E NodeID 0x44FE NodeID 0x9990 NodeID 0xF990 NodeID 0x993E NodeID 0x04FE NodeID 0x43FE

7. Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, 11-14 September 2002 1 Object Location Randomization and Locality

8. Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, 11-14 September 2002 1 Fault-tolerant Routing ● Strategy: – Detect failures via soft-state probe packets – Route around problematic hop via backup pointers ● Redundant Access to Objects: – Via multiple root nodes for each object – Object roots are “well chosen” within the net ● Protocols: – First Reachable Link Selection (FRLS) – Proactive Duplicate Packet Routing

9. Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, 11-14 September 2002 1 Architecture Overview OceanStore implementation ➢ Java with asynchronous I/O ➢ Event-based, stage driven architecture (Sandstorm - M. Welsh) Operating System Java Virtual Machine Sandstorm (async I/O, event arch.) Tapestry OceanStore Applications: e.g. Bayeux, Brocade

10. Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, 11-14 September 2002 1 The Applications ● Tapestry – OceanStore: file sharing – Bayeux: scalable multicast for streaming applications – Brocade: Landmark routing ● Pastry – PAST: file sharing – SCRIBE: publish/subscribe service

11. Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, 11-14 September 2002 1 Why is Tapestry not Pastry Then? ● Object location, replication and routing. – Tapestry allocates “root” nodes to each content item and inserts “hints” into the network when the “object” or a “replica” register themselves with the “root”. ⇒ multiple “root” nodes eliminate single point of failure – Pastry creates a NodeID for each entity to be inserted into the overlay and inserts the resulting node into the network based on the NodeID, no “hints” or “replication” are managed by the substrate.

12. Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, 11-14 September 2002 1 Why is Tapestry not Pastry Then? ● More on replication...... – Pastry + PAST replicates to the k nodes nearest to the original in the NodeID space. Content objects are replicated. – Tapestry replicates “hints” along the "path from the server to the root". "Hints", i.e. references and metadata related to the original, are replicated.

13. Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, 11-14 September 2002 1 Why is Tapestry not Pastry Then? ● Substrate knowledge of IP Net costs – Proximity metrics relating the overlay to the underlying IP net topological costs are implemented slightly differently. One can argue that this is a cosmetic detail, and any arbitary cost strategy (such as location binning[Ratnasamy et al.]) can be used in either system without any impact on the essential functionality.

14. Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, 11-14 September 2002 1 Conclusions ● Tapestry and Pastry are extremely similar! ● Some confusion arises when comparing the two due to the division between the substrates and the file sharing applications built on them; OceanStore and PAST respectively. ● Routing in both is based on Plaxton et al. ● Replication is handled in Tapestry via hints, but left to the application in Pastry ● Associating overlay routing with the underlying IP network structure via locality metrics is managed differently, but perhaps this is not significant.