1. Hybrid Video Downloading / Streaming over peer-to-peer network Yufeng Shan and Shivkumar Kalyanaraman Multimedia and Expo, 2003. ICME '03. Proceedings. 2003 International Conference on, Volume: 2, 6-9 July 2003 Presented By Sam

2. Agenda  Background  Hybrid downloading/streaming Scheme  Goal  Basic framework  Flow  Memory disk cooperative buffering  Simulation  Conclusion  Comment

3. Background Peer-to-peer(p2p) architecture is defined:  A peer stores the streamed data after receiving it, and then streams the cached content to other requesting peers. In previous study, only < 5% hosts can work as server-like peers.

4. Background Question/Problem found:  It should have sufficient number of powerful peers.  Clients (i.e. the peers) may suffer more network fluctuation and network outage than the traditional client/server architecture  In extreme case, the streaming session has to be closed when all the peers with cached content are unreachable.  On the other hand, Traditional server is always available.

5. Hybrid downloading/streaming Scheme (HDS)  Integrates  Traditional client/server based video streaming system (streaming mode)  Peer-to-peer based media data distribution system (downloading mode)  Use receiver driven coordination control (RDCC) to coordinate two modes.

6. Goal 1.HDS reduces the server load 2.RDCC maintains the maximum content availability at receiver side 3.Given all peers with cached content are unavailable, the receiver still can maintain video streaming from video server

7. Basic framework To simplify, 1 video server, 1 supplying peer, 1 requesting peer with CBR video sequence.

8. Flow 1.Peer decides to watch a movie 2.Peer sends out a request to the video server and performs lookup service to find the supplying peers who have the video content. 3.After receiving the information, divides the whole video content into N slices, a piece of video data in a video bit stream (m = M/N)

9. Flow 4. The receiver runs the RDCC algorithm:  Receive streaming traffic from the video server and prebuffer up to T pre seconds  At the same time, downloading the second slice (the slice after T pre second) video content from the supplying peer  After the streaming session catches up to the position of the second slice, it suspends the streaming mode (pure- downloading mode), offering relief to the server.  During the pure-downloading mode, RDCC checks if the amount of data in receiver is lower than a threshold. If yes, a mix of streaming mode and downloading mode will be done. Stage 1 Stage 2 Stage 3

10. Flow T pre TxTx Stage 1Stage 2Stage 3

11. RDCC  Availability of video content r  r defines as the ratio of total successive data in the buffer to the pre-buffer size.  If r > 1, enough successive data  If r < 1, underflow occurs.

12. RDCC If (r < 1&& B d < B) { Trigger the streaming mode; if (B s >= B) { Downloading (n+1)th video slice given current slice being streamed is nth; if (streaming session reaches (n+1)th video slice) Suspend streaming mode; } else run COOP mode; } else downloading-only mode; B d : Available bandwidth between supplying peer and the receiver B s : Available bandwidth between video server and the receiver

13. COOP  This mode only happens when r < 1 and both B s and B d are smaller than B  Calculate R g : Ratio between the available bandwidth of video server and the available bandwidth of the supplying peer.  Both server and supplying peer calculates the amount of frames they should send according to the ratio R g.

14. Memory disk cooperate buffering (MDB)  Use 2 buffers : memory and disk buffer  Memory buffer : same size of traditional scheme  Disk buffer : unlimited size compared to movie length  The receiver uses up as much bandwidth as available to buffer video data. First caches the packet into disk buffer and then fills the memory buffer.

15. Memory disk cooperate buffering (MDB) Advantages:  Absorb more network fluctuation  Significantly reduce the stop-and- rebuffering instances  Efficiently use the available bandwidth

16. Simulation Receiver is a laptop in the RPI network 2 computers act as supplying peers Video server is a SUN machine at UC Berkeley Test video sequence : “foreman” bit rate B = 128kbps Length of sequence : 81 seconds T pre = 3 seconds

17. Simulation Time (in seconds) # packet in Buffer Hybrid downloading/streaming Streaming Bs = 128kbpsBd = 256kbps

18. Simulation Server load in different available bandwidth

19. Simulation Available BandwidthReceiving Rate Stop and RebufferingBuffer occuption

20. Conclusion  HDS proposed, which aims integrating traditional client/server based video streaming system and peer-to-peer based media data distribution system.