Churn Resilience of P2P System Suitable for Private Live-streaming Distribution

1. Churn Resilience of P2P System Suitable for Private Live-streaming Distribution Speaker: Li-Wei Wu Advisor: Dr. Kai-Wei Ke

2. Outline • Introduction • Coolstreaming • Proposed system • Simulation • Conclusion • Reference

3. Introduction • With the appearance of various live-streaming distribution services, the demand for private distribution service is increasing. But the private distributor’s bandwidth is narrow. One of ways for reducing transmission load of distributor is to adopt P2P technology. This paper present and evaluate churn resilience of P2P live-streaming system which based on Coolstreaming which suitable for private distribution.

4. Coolstreaming -Network architecture • Coolstreaming configures one network to distribution one content. The network consists of three types of nodes; Boot-strap node , Origin node , Peer node. • Boot-strap node: keeping all information of Peers and gives information of other Peers to a newly joined node. • Origin node: has source content and provides the content to peer continuously. • Peer node: viewer , exchange blocks of content with each other and play back the content.

5. Coolstreaming -Network architecture • A node has an identifier list of other Peers. This list called “mCache” . • mCache regular update which is achieved by the periodic exchange of alive message. • A node selects a certain number of node from mCache randomly and transfers alive message to them. The receiver of this message stochastically updates its information or transfers this message to a random selected node.(SCAMP)

6. Coolstreaming -Network architecture

7. Coolstreaming – Join network • Communication with Boot-strip node to get information of other peers and store the information in the “mCache”. • Select a certain number of Peers from node in mCache to connect them by TCP. The connected node are called partners. • Each node regularly exchanges information that the parts of content the node has. • Each node selects a certain number of node s as supplier and send request. • Once a node receives this request messages, the node servers the content as continuously as possible.

8. Coolstreaming – Join network

9. Coolstreaming – Leave network • Explicit leave: • Peer send leave message to Origin and some Peers in the work. • Sudden leave: • The network can not recognize leave of the peer until the peer’s ID in mCache is deleted by timeout.

10. Coolstreaming – Content playback • Each streaming content is divided into blocks with equal sizes. • The blocks need to reach the viewer node before playback deadline. • Continuity Index: Continuity index = / :number of blocks which arriver before playback deadline. :number of all blocks in one content.

11. Coolstreaming–Bndwidth influence • Peers upload bandwidth is not enough large and peers which can not upload data because of Network Address Translation. Those node should be far from Origin. • Broadband peers should be nearby origin. • It is necessary for considering performance of nodes to constructing network.

12. Proposed system-Concept • Define some broadband peers selected from peers as Surrogates for the alternatives of Origin. • Origin and surrogates from one cluster. The cluster as a service of one virtual and much broadband distributor. • The system considers departure of both peer and surrogates.

13. Proposed system-Architecture • Boot-strap and Origin node in coolstreaming are merged into one node named Origin in proposed system. • Peers are divided into Surrogate and Peers. • Origin node: Boot-strip +origin node • Surrogate node: node to supply Peers with a content instead of Origin. • Peer node: mainly narrower bandwidth node which is not chosen as Surrogate.

14. Proposed system-Architecture • Origin node supplies only Surrogate with content. • Surrogate exchanges content with each other to have large part of content. Surrogate with almost all part of content can be tread as Original.

15. Proposed system-Architecture

16. Proposed system-Join network • Newly joined Node sends information of its bandwidth to Origin. • Origin appoint the node as Surrogate or Peer by information of bandwidth. • In the case of Peer, Origin send a set of nodes to the node as ID list. • In the case of Surrogate, Origin notifies the node of both ID list of the Surrogate and Peers.

17. Proposed system-Maintenance of the number of surrogate • On initial state, Surrogate are selected based on there self-reported upload bandwidth. • There may be some nodes with incorrectly-reported bandwidth, false bandwidth or different bandwidth from that in the initial state because of changing network environment. • Promotes Peer to Surrogate and demotes Surrogate to Peer.

18. Proposed system-Maintenance of the number of surrogate • Each peer periodically reports information about received blocks with its sender information and sends them to Surrogate to calculate contribution degree of each Peer. • Contribution degree: = =

19. Proposed system-Maintenance of the number of surrogate • The number of Surrogate: = the number of Peer. the number of Peer partner.

20. Proposed system-Promotion to Surrogate • If Origin decides promotion of one Peer ,this decision is noticed to a Surrogate. • This Surrogate send request of contribution degree to its partner Peer. • The Peer received this message requests information of contribution degree to other Peer who are its partner. • These Peer send information of contribution degree to Surrogate.

21. Proposed system-Promotion to Surrogate • The Surrogate selects maximum bandwidth among Peers with certain contribution level. And sends Peer the message indicating that the Peer is assigned as Surrogate. • When the Peer received this message ,the Peer transmits its promotion to other Surrogate and its Peer partner.

22. Proposed system-Promotion to Surrogate

23. Proposed system-Demotion from Surrogate • Origin sends demotion message to the Surrogate. • Surrogate received this message then send demotion notification message to other Surrogate and Peer partners to demote to Peer.

24. Simulation-Case 1 • Evaluation of Surrogate selection based on bandwidth of nodes. • 4 broadband nodes. • 96 narrowband nodes.

25. Simulation-Case 1

26. Simulation-Case 1

27. Simulation-Case 2 • Evaluation of Effect on Surrogate leave. • 5 broadband node and 95 narrowband node . • Surrogate leave without previous notice in 600 seconds.

28. Simulation-Case 3 • Evaluation of Effect on node leave. • 4 broadband node and 96 narrowband node. • 1 narrowband joins and 1 another narrowband leave.

29. Simulation-Case 3

30. Conclusion • This paper proposed effective live-streaming system used in private distribution based on Coolstreaming. This system achieves better performance then Coolstreaming system dose in both node leave and no leave environment.

31. Reference • T. Hisada, S. Yamazaki, Y. Hirota, H. Tode, K. Murakami, “Churn Resilience of P2P System Suitable for Private Live-streaming Distribution.” P2P,Parallel,Grid,Cloud and internet Computing(3PGCIC),2010 International Conference. • T. Hisada, S. Yamazaki, Y. Hirota, H. Tode, K. Murakami,”P2P Live Streaming System Suitable for Private Content Distribution.” Consumer Communications and Networking Conference(CCNC),2010 7th IEEE.