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

Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, September Source Material ● This presentation is based on the following. – Slides from the ROC/Sahara Retreat 2002 ● pps – Tapestry Technical Report ● – Application Papers ● Oceanstore: ● Bayeux: ● Brocade:

Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, September 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)

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

Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, September 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

Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, September 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

Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, September Object Location Randomization and Locality

Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, September 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

Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, September 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

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

Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, September 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.

Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, September 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.

Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, September 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.

Arnold N. Pears, CoRE Group Uppsala University 3 rd Swedish Networking Workshop Marholmen, September 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.