ZIGZAG A Peer-to-Peer Architecture for Media Streaming By Duc A. Tran, Kien A. Hua and Tai T. Do Appear on “Journal On Selected Areas in Communications, Special Issue on Advances in Service Overlay Networks”

Agenda 1. Introduction 2. ZigZag 1. Administrative Organization 2. Multicast Tree 3. Client join/departure 4. Performance analysis 3. Conclusion

Introduction Scenario A single live source serving many clients Solution Broadcasting by IP multicast Problem IP multicast not widely deployed

Application-multicast What? Not all clients receive contents from the source Some clients (peers) help streaming data to other peers (P2P)

Design Objectives An efficient P2P media streaming scheme should 1. The end-to-end delay from source to client should be low 2. The node degree should be small 3. Adapt to free join/leave receivers 4. Minimize the amount of control overhead

ZigZag Administrative Organization Represents the logical relationships among peers Multicast tree Specify which peer data is received from Built based on C-rules which helps limits the degree of a peer (outbound links) Control protocol Specify the exchange of state information Policies adjusting the tree Maintaining the robustness of the tree

Administrative Organization What? A multi-layer hierarchy of clusters Partition peers into clusters of size [k, 3k] Assign the role “head” and “associate head” to certain peers

Administrative Organization

Properties H – number of layers Bounded by [log 3k N, log k N+1] Max. number of members in a cluster=3k To prevent cluster undersize in the case of a client leave after splitting

Multicast tree What? Built based on the administrative organization C-rules specify the actual data flow from source to any peer Some nodes will stream data to more than 1 peers Assumption: The uplink capacity of peer is enough for streaming contents to multiple peers

Multicast Tree

Properties The workload is shared among clients Worst-case node degree is 6k-3 The end-to-end delay is small Maximum height of the tree is 2log k N+1 Use of “associate head” for delivering media Number of outbound links is lower Bottleneck will less likely to appear in higher level

Control protocol Goal Minimize the number of peers needed to be contacted Only exchange information with parent, children and clustermates Exchange as few states as possible 1. Non-head peers 1. Peer degree for non-head peers 2. Cluster head 1. Current end-to-end delay from server to the peer 2. List of peers receiving contents from the peer 3. List of “associate head” receiving contents from the peer 3. Parent 1. “Reachable” and “Addable” property

Client join/departure Basic principle Maintain C-rule so that nice properties of degree and end-to-end delay is preserved Direct solution Reconstruct the administrative organization and multicast tree Costly in terms of exchange of state information Proposed join/departure algorithm Limits the number of nodes to connect during a join by O(k log k N) Limits the number of peers that need to reconnect by 6k-2

Client join Procedure 1. If X is a layer-0 associate-head 1. Add P to the only cluster of X 2. Make P a new child of X 2. Else 1. If Addable(X) 1. Select a child Y s.t. Addable(Y) and D(Y)+d(Y,P) is min 2. Forward the join request to Y 2. Else 1. Select a child Y s.t. Reachable(Y) and D(Y)+d(Y,P) is min 2. Forward the join request to Y

Client departure Tasks to do for client (X) departure 1. The parent removes link to X 2. The children of X needs a new parent 3. Each layer-i cluster X belongs to needs a new head 4. Layer-j cluster may require a new associate head

Client departure If X’s highest level is at layer 0 If X is not the “associate head” No extra work needed If X is the “associate head” The head of the cluster choose another member to take up the responsibilities

Client departure If X’s highest level is j (non zero) It implies it is a “head” in layer [0,j-1] A non-head peer (X’) at layer 0 is randomly chosen to replace the “head” responsibility Head of children of X (Y) will choose a new parent for X that has a minimum degree

Performance Analysis Comparison with another multicast tree based P2P media streaming scheme – NICE Performance metrics Maximum degree – The max. no of outbound links Join overhead – The number of peers to visit until admission Failure overhead – The number of reconnections required when a peer “fail” Control overhead – The number of peers to exchange control information with Stretch – Ratio between length of data path from server to a peer in the system to the shortest path Stress – Number of times the same packet goes through a link

Simulation study Simulation environment The network has 10,000 nodes k is set to 5 Thus, 5 peers at min. and 15 peers at max. for each cluster Compare to NICE Initially, 3000 clients join sequentially into the system Then a loop of 2000 runs, a client will fail at a probability p while joining the system at 1-p

Simulation Results I

Simulation Results II

Conclusion A P2P media streaming scheme The maximum degree and end-to-end delay is small A client join/leave algorithm is proposed aim at reducing the control overhead Simulation result suggests that 5000 peers can be supported at a max. degree of 15

Q & A Thank You