a measurement study of cache rejection in p2p live streaming system

A Measurement Study of Cache Rejection in P2P Live Streaming System

Yishuai Chen*, Changjia Chen, Chunxi Li Network Research Group, Telecom Lab, Beijing Jiaotong University http://telcomlab.googlepages.com

Index

Introduction Measurement Result Analysis Modeling

Limited Cache Size

Cache: For P2P sharing Live service: like TV

Peers keep forwarding to watch the newest scene.

Old content become out-of-date and is not required by any peers, so it can be discarded by peers safely

So the cache size can be limited 10s-100s

Sliding Window

Chunks may arrive out of sequence not a FIFO

Example A new chunk is received Assume a fixed size cache

1111111111111…………1111111111001011011

1111111111111…………11111111110010110111111111111111 0000000000001

Get a new chunk

Reject the same amount of chunks

No, We are downloading!

Rate Changes

Ideal stable status Cache rejection rate = Chunk arriving rate =

Server upload rate Rate Change

8 chunks/s -> 10 chunks/s With fixed size chunk, it reflects the change of

encoding rate Should sync, but how sync?

Immediately delay

Measurement

Design our PPLive crawler to actively crawl the buffer status of media server and peers

1st May, 2007, 4hr. 1 PPLive channel Media Server

{head chunk id, end chunk id} crawl interval: 10s

376 Peers: {head chunk id, bitmap} crawl interval: 5s

Rs vs. Ro(One Peer)

Rate Change

Tracking(PLL)

Latency

Peers Change Ro at Different Time

大多分布在 50s-100s之间，极个别有 300s延时

变化点比较集中。进一步分析数字特征

At the Same Chunk!

Detail, 4 Peers, Rate Change Point 4

Rs also Change at the Same Chunk! 因为 Rs的取样间隔长，所以最后获得的 Rs变化曲线比较平缓，通常需要 1.5-2K offset范围来完成速率改变

Behavior & Meaning

Peer’s cache rejection synchronizes with media server’s chunk upload on chunk

What’s its underlying meaning? Fixed Time Rejection Algorithm

No matter how chunk rate changes, server always upload 1s’ content in 1s, peers playback 1s’ content in 1s, therefore, it is natural to reject 1s’ content in 1s

Inspiration: Time is the most important property in P2P Live

streaming system It is invariable in the universe

Indirect, looks good

Modeling

Virtual Buffer

Characteristic FIFO Buffer

Input: Media Server Output: Peer buffer head

Fixed duration buffer

Validation

Virtual Buffer Abstract

The buffer abstract includes the P2P network The chunk propagation process in the P2P network can

be modeled with this abstraction Sliding windows model Key: It is measurable!

It can be validated in the real world PPLive network

Thanks!

Backup

Numerical Result

Interval Mean Min Max Max-Min Std. Dev

1 24200 24193 24206 13 4.93

2 33097 33086 33106 20 7.20

3 53498 53474 53509 35 11.14

4 55377 55372 55382 10 4.84

5 94895 94879 94901 22 7.17

6 104909 104890 104923 33 12.59

Rate change chunk offset:

Comparison: Ro and Rs Change

Interval Difference

1 3

2 -72

3 -42

4 186

5 56

6 -126

Change Chunk Offset Difference

Lack of Explicit Result

Misc existed system report Coolstreaming, Anysee, GridMedia, etc. 10s-200s

Measurement: PPLive: “adaptively allocated buffer size according to the

streaming rate and the buffering time period specified by the media source” [X. Hei, C. Liang, J. Liang, Y. Liu and K. W. Ross, “A

Measurement Study of a Large Scale P2P IPTV System”, Nov 2006 Method: downloading media file from its local streaming

server after physically disconnecting the PC from network. Found buffer size varied from 7.8 MBytes to 17.1Mbytes

Performance

Stable sharing for partner peers Avoid the abrupt rejection problem

Adaptively adjusts buffer size according to the streaming rate Smoothly change buffer size when chunk rate

change

Reference

Y. Zhou, D. M. Chiu, and John C.S Lui, "A Simple Model for Analyzing P2P Streaming Protocols", The fifteenth IEEE InternationalConference on Network Protocols (ICNP 2007), Bei Jing, China, Oct. 2007

Our paper: Measure and Model P2P Streaming System by Buffer Bitmap, To appear in HPCC 2008.