An Evaluation of Scalable Application-level Multicast Using Peer-to-peer Overlays Miguel Castro, Michael B. Jones, Anne-Marie Kermarrec, Antony Rowstron,

An Evaluation of Scalable Application-level Multicast Using Peer-to-peer Overlays

Miguel Castro, Michael B. Jones, Anne-Marie Kermarrec, Antony Rowstron , Marvin Theimer, Helen Wang and Alec Wolman

Presented by Ricky Taing

Authors:

Outline

Motivations and Goals of Paper Overview of Overlay Networks Overview of p2p Multicast

Implementations Experimental Methodology Results Conclusions

Motivations and Goals

Lack of IP multicast adoption has increased development in app-layer multicast

Different versions available to use, with different implementations

Determine the best application layer multicast system from different overlays and implementations

P2P Overlay Networks

Two main approaches Divide and conquer in a ring

Pastry, Chord, Tapestry Cartesian hyper-space

CAN

Pastry

Routes by nodeID Circular 128-bit namespace Get to destination in log 2^b N time

b is configurable, usually b=4 (hex) Each node maintains a leaf set

pointers to l nodes closest to it

CAN

Route in multiple dimensions Each node is assigned a particular zone

Many optimizations Neighbor with lowest network delay Multiple nodes per zone Uniform partitioning Landmark based placement

Landmark based placement

Set of well known landmarks ordered by distance placed into evenly sized bins

Nodes with same landmark ordering end up close to each other

P2P Multicast Implementations

Flooding Unique overlay-per-group Only nodes in group get group messages

CAN broadcast to neighbors, use seq numbers

Pastry Forwards copies to all nodes in routing table

Notes levels, sends to greater levels

Tree-based

Scribe Reverse path forwarding to create one tree

per group Joins route messages to groupId (root)

Registers if a node along the route is in the tree

Evaluation

Simulation Five different topologies 5050 routers, 80000 end nodes

Two sets of experiments Single multicast group, all nodes are

members Large number of groups (1500)

Criteria

Relative Delay Penalty RMD: Ratio of Maximum delay between

app and IP multicast RAD: Ratio of Average delay between app

and IP Multicast Link Stress

number of packets sent over link

Criteria (2)

Node Stress Number of nodes in a routing table Number of messages received by a join

Duplicates Number received by end nodes

CAN+Flooding Results

Landmark based and NDR (lowest network delay) was best

Benefits from increased table state is uneven

Link stress for 80,000 joins is huge Increases with state size

Link stress is significantly lower for sent messages

Link stress CAN+Flooding

CAN+Tree Results

Landmark based assignment of nodes better

Delay is better than flooding by a factor of 2 to 3

Link stress for joins and sends are relatively similar

Pastry: Tart and Tangy

varied b from 1 to 4 TART

Topology aware routing table construction default optimization nodes probe each other to estimate delay

TOP Topology aware nodeId assignment

currently random / distributed

Pastry+Flooding Results

delay decreases as b increases delay of b=4 is 50% lower than b=1 TART and TOP both decrease delay

TOP reduces average link stress by factor of 3 and max link stress by a factor of 30

Large number of duplicates when b is large (16% b=4) due to holes in routing tables

Pastry+Tree Results

delay decreases as b increases, and with TART and TOP similar to flooding results

TART reduces both max and avg link stress TOP reduces avg but increases max link stress

Pastry with TART and without TOP is best for tree-based

Multiple multicast

Tree based Pastry was best for delay Interesting is CAN + Flooding average

CDF curve not tightly bound Flooding is better in the 1500 group

experiment than the single group

Max Delay Penalties

Average Delay Penalties

Evaluation

For delay, Pastry is 20-50% better than CAN

For average link stress, Pastry was 15% lower Max link stress: CAN was 25% lower

Conclusion

Separate overlays are only better if you want to limit nodes that route traffic

More overhead for flooding approach Tree base can reuse the same overlay for multiple

groups Less delay, joins and sends are more lightweight

Multicast trees with Pastry have better performance than CAN