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 gt Limited
  flooding
• otherwise gt Full flooding
• FLS method
• If R contains all next round blocks gt Selective
  search
• If R contains some next round blocks gt Limited
  flooding
• Otherwise gt 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