1 / 46

Is Random Scheduling Sufficient in P2P Video Streaming?

Is Random Scheduling Sufficient in P2P Video Streaming?. The 28th International Conference on Distributed Computing Systems. 課程： 同儕計算 日期： 2008.12.16. 報告者： 69721041 朱振伸 69721502 張欽天. 1. INTRODUCTION 2. RELATED WORK 3. P2P STREAMING: DESIGN AND IMPLEMENTATION

zanta
Download Presentation

Is Random Scheduling Sufficient in P2P Video Streaming?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Is Random Scheduling Sufficient in P2P VideoStreaming? The 28th International Conference on Distributed Computing Systems 課程： 同儕計算 日期：2008.12.16 報告者：69721041 朱振伸69721502 張欽天

  2. 1. INTRODUCTION • 2. RELATED WORK • 3. P2P STREAMING: DESIGN AND IMPLEMENTATION • 4. EVALUATION METHODOLOGY • 5. EXPERIMENTAL RESULTS • 6. CONCLUSIONS AND FUTURE WORK

  3. INTRODUCTION • Video-over-IP applications are quickly becoming the new generation “killer” applications on the Internet • ISPs (private IP networks) e.g. FiOS of Verizon • client-server based • P2P

  4. INTRODUCTION • How elaborate should a good P2P video streaming design be? • 學術界 • focus on exploring design space to approach theoretical performance bound • 企業界 • deliver good user Quality to Experience with simple designs

  5. Comparison study • Modeling and analysis • Simulation • Experiments on Internet • PlanetLab

  6. PlanetLab • An overlay network testbed • 能夠在真實世界條件下且在大規模中試驗新服務。 • 分佈於全球的計算機群 • PlanetLab目前由933 nodes，由454個站點託管。 • A software package • 收集管理工具、監控節點健康、審計系統活動和控制系統參數的管理工具集，管理用戶賬戶和分發密鑰的工具。

  7. Three basic scheduling algorithms • Random Pull scheduling (RP) • Adaptive Queue Based Chunk scheduling (AQCS) • Random Useful Packet Forwarding (RUPF) • p.s. AQCS and RUPF have been theoretically proved to be optimum

  8. Random Pull Scheduling • A peer in RP scheduling randomly select M neighbors to serve. • The value of M is chosen to be proportional to the peer’s upload capacity. • A peer can request up to K data chunks from one serving peer. • RP randomly selects missing chunks to pull

  9. Random Pull Scheduling

  10. Adaptive Queue-based Chunk Scheduling • A fully connected mesh among participating peers • Data chunks are pulled/pushed from the server to all peers, cached at peers’ forwarding queues, and relayed from peers to their neighbors

  11. Adaptive Queue-based Chunk Scheduling

  12. Random Useful Packet Forwarding • the mesh is fully connected • the most-deprived peer • Source server gives highest priority to the fresh data chunks that have not been sent out before

  13. Random Useful Packet Forwarding • pushpull • A large number of duplicate chunks are observed • A high percentage of chunks miss their playback deadlines • Outdate、Collision、uplink capacity sometimes cannot be fully utilized.

  14. RUPF vs RP • RUPF selects M most deprived peers • RF select M random peers • The source server in RUPF pushes out fresh data chunk first • Random Pull with Fresh chunk first (RPF) • Random Pull with Most-Deprived peer selection (RPMD)

  15. Random Useful Packet Forwarding

  16. EVALUATION METHODOLOGY • Experiment Setting • 10, 000 lines of C++ code • 100 PlanetLab nodes • nodes are TCP connections • 20% peers have upload capacity of 128kbps • 40% have 384kbps • 25% have 1Mbps • 15% have 4Mbps

  17. EVALUATION METHODOLOGY • average upload bandwidth is around 1Mbps • each node collects related statistics every second • estimates the average upload and download rate per ten seconds.

  18. EVALUATION METHODOLOGY • Performance Metrics • chunk miss ratio • the number of data chunks which miss the playback deadline over the total number of data chunks that peer should receive. • peer bandwidth utilization • average upload rate/the peers’ pre-set upload capacity • playback delay • when a chunk is generated at the source until it is played at the peer side

  19. V. EXPERIMENTAL RESULTS • Five different P2P streaming designs • 1. Random Pull (RP), • 2. Random Pull with Fresh first policy (RPF), • 3. Random Pull with Most-Deprived peer selection (RPMD), • 4. Random Useful Packet Forwarding (RUPF) and Adaptive • 5. Queue-based Chunk Scheduling (AQCS).

  20. 串流系統的環境 • 在P2P串流系統中，n個peer最大串流速度為： • 代表server上傳的能力 • 代表每一個peer的上傳能力 • 代表整體的上傳能力，即

  21. 串流系統的環境 • The bandwidth resource index ρ • the ratio of the total uploading resources in the system to the total resource demand at streaming rate of r

  22. In AQCS, • the chunks size is set to be 1KByte, and the server replies each pull signal with only one chunk. • The server increases the streaming rate by increasing the number of chunks generated per second.

  23. In RUPF and RP, • we fix the buffer map size at 120bits(15 bytes). • The download window is set to be 30 seconds and moves forward every 10 seconds. • The server produces four chunks per second and increases the streaming rate by increasing the chunk size (this way the buffer map size remains the same).

  24. 94% 72% 80% 註： CDF= Cumulative Distribution Function value (the user data access cost over light load and heavy load)

  25. B. Impact of Server Scheduling Rule and Capacity • The experiment results suggest that • (i) the fresh-chunk-first scheduling at source server plays an important role in improving the system performance; • (ii) most deprived scheduling, although has been theoretically shown to be optimal , does not seem to bring performance improvement in our experiments.

  26. 960Kbps 圖5-a 不同串流速度在各演算法中的失誤率影響 1100Kbps

  27. B. Impact of Server Scheduling Rule and Capacity(服務清單規則與能力衝突) • 實驗環境上傳頻寬環境在3.2Mbps的時候進行， • 當串流速度< 960Kbps , 失誤率 0 • 當960Kbps<串流速度, RUPF和RP↑ • 當1100Kbps<串流速度，AQCS↑ • => 串流效能在安排系統資源索引時影響不大 • => 增加server的能力可增加資源索引

  28. Loading較重 Loading較輕 圖5 註：有效率的演算法對於server的load比較輕

  29. (圖6) 註：Server 上載的頻寬變動對各種排班演算法的影響

  30. 圖7

  31. 圖7

  32. 註：磁區緩衝越長，失誤率越低；反之會越高

  33. C. Impact of Buffering Delay • In client-server based video streaming, client side video buffering is necessary for continuous playback in face of network bandwidth variations. • 考慮緩衝長度(環境：串流速度640kbps,伺服器頻寬：1Mbps) • 1. 緩衝長度 = 10 秒時，Chunk損失：23% • 2. 緩衝長度 = 30 秒時，Chunk損失： 5% • => 但緩衝長度越長的時候，越來越少磁區能滿足最後的播放期限。

  34. D. Impact of Peering Topology and Degree • 實驗環境：100 Planetlab node，speed 640kbyte/s • 1. 考慮 Degree • (1). 當peer的degree = 6 時，平均失誤率 = 20% • (2). 當peer的degree =10 時，平均失誤率 = 5% • (3). 當peer的degree =14 時，平均失誤率 = 3%

  35. 2. 考慮 the average hop count 的分配 • (1) 當 peers 連接到 6 個鄰居, 每個 chunk 需橫越平均 6 個 hops • (2) 當 peer 連接到 14個鄰居, 平均路徑長 降低到 低於 4.

  36. Peer 離開率 與 分支度的影響 • 1. 初始值 ，每個 peer 皆有 14 degree • 2. 當10%peer離開，平均失誤率12%，degree降低到 13 • 3. 當40%peer離開，平均失誤率20%，degree降低到 9 • 4. 越多peer離開，鄰居越少，失誤率越高。

  37. Large peering degreehelps in improving system robustness in the face of peer churn. • 當degree=18時，50%的peer離開，失誤率大概15% • 但degree=10時， 50%的peer離開，失誤率大概是30%

  38. VI. CONCLUSIONS AND FUTURE WORK • 1. several key factors contributing most to the successes of simple P2P streaming designs on the current Internet. • 2. In the future work, we are interested in exploring different ways to extrapolate our results to draw more general conclusions on P2P systems with different sizes

  39. 心得： • 1. 目前商業P2P串流系統仍處在約400k左右或更低的狀態，與目前網路的頻寬的發展關係密切。 • 2. 本篇主要的研究部分是以研究影音串流在網路的傳輸情況作考量，但是在頻寬往上提升的情況下，PC電腦的效能與使用者網路的先天限制或許是影響到最後結果的因素之一。 • 3. 在讀這篇文章時發現到，作者將現有的網路傳輸技術做各種比較，這個精神值得我們仿效。

More Related