a measurement study of cache rejection in p2p live streaming system
Post on 20-Jun-2015
1.295 Views
Preview:
TRANSCRIPT
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.
top related