Scalable and Continuous Media Streaming on Peer-to-Peer Networks

1. Scalable and Continuous Media Streaming on Peer-to-Peer Networks M. Sasabe, N. Wakamiya, M. Murata, H. MiyaharaOsaka University, JapanPresented By Tsz Kin Ho13/10/2003

2. Agenda • Background • System architecture • Movie segmentation • Block-search algorithm • Block-retrieval algorithm • Simulation results • Conclusion and discussion

3. Background • Client-server streaming • Lacks scalability and stability • Proxy mechanism cannot adapt to • Variations of user locations • Diverse user demands • Peer-to-peer streaming • Inherent scalability • New network paradigm to solve these problems

4. Background • Application-level multicast tree • Most of the p2p streaming research works focusing • Effective for live streaming, not for on-demand media streaming • Single point of failure at root • Focus on providing scalable and effective on-demand media streaming on pure P2P networks

5. Architecture

6. Main Goals • Bandwidth & storage efficiency • Segmentation of stream into “block” • Scalability • Scalable block-search algorithm • Reduce amount of query message • Continuity • Block-retrieval algorithm • Determine set of peers as provider • Achieve continuous media playback

7. Segmentation of movie • Movies are segmented into small process unit “block” • A block can be encoded and decoded by itself, e.g. the GoP in MPEG2 • Each peer maintains a part or the whole of some movies that it has watched or is watching

8. Segmentation of media stream • Smaller block • More search message • Difficult to maintain cache buffer • Longer block • Fewer search message • Drastic changes in network condition while retrieving a block • Block size affects system scalability • Block size of 10 sec in experiment

9. Block-search algorithm • Per-group search • Periodically sends out a query message for N consecutive blocks (Round-based)

10. Block-search algorithm • Consumer peer • Waits for a response for first block • Aborts watching if no response arrives after 4 seconds (based on the 8-second rule) • Retrieve first block immediately • Estimates the available bandwidth and delay from the provider peer • Schedule other blocks using the delay and playback deadline

11. Block-search algorithm • Full flooding • Flooding with fixed TTL • Limited Flooding • Flooding with decreased TTL based on the search result on previous round • Selective search • Temporal order of reference in media stream • Expect replied provider peers will contain some blocks in next round • Directly send queries to known peers to confirm the existence of desired blocks

12. Block-search algorithm • Conjectured contents of cache buffers of peers : R • FL method • If R contains all next round blocks => Limited flooding • otherwise => Full flooding • FLS method • If R contains all next round blocks => Selective search • If R contains some next round blocks => Limited flooding • Otherwise => Full Flooding

13. Block-retrieval algorithm • More than one peer may contain the required blocks • When receiving a response message, consumer determine optimum set of provider by • Choosing set of providers that can send out block in time • Choosing under • Select Fastest (SF) method • Select Reliable (SR) method

14. Block-retrieval algorithm • Select Fastest (SF) method • select a peer whose estimated retrieval time is the smallest among peers • Select Reliable (SR) method • select a peer with the lowest possibility of block disappearance in cached buffer among peers

15. Simulation Result • Movie bit rate = CBR 500 kbps • Random network with 100 peers • Generated by Waxman algorithm • RTT between two contiguous peers ranges from 10ms to 660ms • Available bandwidth randomly generated and fixed between 500 and 600 kbps

16. Simulation Result • 40 movie of 60 minutes, which are Zipf distributed with = 1.0 • Average peer idle time is exponentially distributed with mean = 20 minutes • Cache buffer • LRU replacement • size 675 MB (about size of 3 movie) • 6 blocks in a round • Block size of 10 sec

17. Simulation Result • Metric • Scalability • Average number of queries that a peer receives during the simulation • Continuity • Completeness = (number of block in time / number of block of movie)

18. Simulation Result • Scalability

19. Simulation Result • Continuity • Completeness with 95% CI • About 70% of total request are complete Popularity

20. Conclusion • Proposed scalable block-search and block-retrieval method in p2p media streaming • FLS method can provide users with continuous media playback • Future works • Determination of block size • Effective cache replacement algorithm • Dynamic network

21. Discussion • Quite related to SLVoD project • Simulation model not realistic • Network model • Total Storage requirement is 300 movie space (with only 40 movies) • FLS is very effective for LRU cache replacement • Only 70% completeness • Bandwidth is not dedicated after the search, more than one client may schedule the transmission at the same time

22. References • M. Sasabe, N. Wakamiya, M. Murata, H. Miyahara, “Scalable and Continuous Media Streaming on Peer-to-Peer Networks”, proc. P2P 2003 • M. Sasabe, Presentation Slides at P2P 2003