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

M. Sasabe, N. Wakamiya, M. Murata, H. MiyaharaOsaka University, Japan

Presented By Tsz Kin Ho13/10/2003

Agenda Background System architecture

Movie segmentation Block-search algorithm Block-retrieval algorithm

Simulation results Conclusion and discussion

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

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

Architecture

Q u e ry

F o rw a rd

R e s p o ns e

R e s p o ns e

T ra ns m it

1 5 6 8 21

B lo c ks in c ac he d buf fe r (L R U )

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

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

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

Block-search algorithm Per-group search

Periodically sends out a query message for N consecutive blocks (Round-based)

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

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

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

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

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

1 2 3 4 1010 1 2 3 4

L e as t R e c e nt ly U s e dM o s t R e c e nt ly U s e d

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

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

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)

Simulation Result Scalability

Simulation Result Continuity

Completeness with 95% CI About 70% of total request are complete

Popularity

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

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

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