is random scheduling sufficient in p2p video streaming?

46
1 Scheduling Sufficient in P2P Video Streaming? The 28th International Confe rence on Distributed Computi ng Systems 課課 課課課課 課課2008. 12.16 課課課69721041 課課課 69 721502 課課課

Upload: zanta

Post on 05-Jan-2016

43 views

Category:

Documents


0 download

DESCRIPTION

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 - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Is Random Scheduling Sufficient in P2P Video Streaming?

1

Is Random Scheduling Sufficient in P2P Video

Streaming?

The 28th International Conference on Distributed Computing Systems

課程: 同儕計算 日期: 2008.12.16

報告者: 69721041 朱振伸 69721502 張欽天

Page 2: Is Random Scheduling Sufficient in P2P Video Streaming?

2

1. INTRODUCTION 2. RELATED WORK 3. P2P STREAMING: DESIGN AND IMPLEMENTATION

4. EVALUATION METHODOLOGY 5. EXPERIMENTAL RESULTS 6. CONCLUSIONS AND FUTURE WORK

Page 3: Is Random Scheduling Sufficient in P2P Video Streaming?

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

Page 4: Is Random Scheduling Sufficient in P2P Video Streaming?

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 de

signs

Page 5: Is Random Scheduling Sufficient in P2P Video Streaming?

5

Comparison study

Modeling and analysis Simulation Experiments on Internet

PlanetLab

Page 6: Is Random Scheduling Sufficient in P2P Video Streaming?

6

PlanetLab

An overlay network testbed 能夠在真實世界條件下且在大規模中試驗新服務。 分佈於全球的計算機群 PlanetLab 目前由 933 nodes ,由 454 個站點託管。

A software package 收集管理工具、監控節點健康、審計系統活動和控制系統參

數的管理工具集,管理用戶賬戶和分發密鑰的工具。

Page 7: Is Random Scheduling Sufficient in P2P Video Streaming?

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

Page 8: Is Random Scheduling Sufficient in P2P Video Streaming?

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

Page 9: Is Random Scheduling Sufficient in P2P Video Streaming?

9

Random Pull Scheduling

Page 10: Is Random Scheduling Sufficient in P2P Video Streaming?

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

Page 11: Is Random Scheduling Sufficient in P2P Video Streaming?

11

Adaptive Queue-based Chunk Scheduling

Page 12: Is Random Scheduling Sufficient in P2P Video Streaming?

12

Random Useful Packet Forwarding

the mesh is fully connected the most-deprived peer Source server gives highest priority to the fre

sh data chunks that have not been sent out before

Page 13: Is Random Scheduling Sufficient in P2P Video Streaming?

13

Random Useful Packet Forwarding

pushpull 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.

Page 14: Is Random Scheduling Sufficient in P2P Video Streaming?

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)

Page 15: Is Random Scheduling Sufficient in P2P Video Streaming?

15

Random Useful Packet Forwarding

Page 16: Is Random Scheduling Sufficient in P2P Video Streaming?

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

Page 17: Is Random Scheduling Sufficient in P2P Video Streaming?

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.

Page 18: Is Random Scheduling Sufficient in P2P Video Streaming?

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

Page 19: Is Random Scheduling Sufficient in P2P Video Streaming?

19

V. EXPERIMENTAL RESULTS

Five different P2P streaming designs1. 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 Adaptive5. Queue-based Chunk Scheduling (AQCS).

Page 20: Is Random Scheduling Sufficient in P2P Video Streaming?

20

Page 21: Is Random Scheduling Sufficient in P2P Video Streaming?

21

串流系統的環境

在 P2P 串流系統中, n 個 peer 最大串流速度為:

代表 server 上傳的能力 代表每一個 peer 的上傳能力 代表整體的上傳能力,即

Page 22: Is Random Scheduling Sufficient in P2P Video Streaming?

22

串流系統的環境

The bandwidth resource index ρ

the ratio of the total uploading resources in the system to the total resource demand at streaming rate of r

Page 23: Is Random Scheduling Sufficient in P2P Video Streaming?

23

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.

Page 24: Is Random Scheduling Sufficient in P2P Video Streaming?

24

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).

Page 25: Is Random Scheduling Sufficient in P2P Video Streaming?

25

Page 26: Is Random Scheduling Sufficient in P2P Video Streaming?

26

註: CDF= Cumulative Distribution Function value

(the user data access cost over light load and heavy load)

94%80%72%

Page 27: Is Random Scheduling Sufficient in P2P Video Streaming?

27

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.

Page 28: Is Random Scheduling Sufficient in P2P Video Streaming?

28

不同串流速度在各演算法中的失誤率影響

960Kbps

1100Kbps圖 5-a

Page 29: Is Random Scheduling Sufficient in P2P Video Streaming?

29

B. Impact of Server Scheduling Rule and Capacity( 服務清單規則與能力衝突 )

實驗環境上傳頻寬環境在 3.2Mbps 的時候進行, 當串流速度 < 960Kbps , 失誤率 0 當 960Kbps< 串流速度 , RUPF 和 RP↑ 當 1100Kbps< 串流速度, AQCS↑

=> 串流效能在安排系統資源索引時影響不大 => 增加 server 的能力可增加資源索引

Page 30: Is Random Scheduling Sufficient in P2P Video Streaming?

30 註:有效率的演算法對於 server 的 load 比較輕

圖 5

Loading 較重

Loading 較輕

Page 31: Is Random Scheduling Sufficient in P2P Video Streaming?

31

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

Page 32: Is Random Scheduling Sufficient in P2P Video Streaming?

32

圖 7

Page 33: Is Random Scheduling Sufficient in P2P Video Streaming?

33

圖 7

Page 34: Is Random Scheduling Sufficient in P2P Video Streaming?

34

註:磁區緩衝越長,失誤率越低;反之會越高

Page 35: Is Random Scheduling Sufficient in P2P Video Streaming?

35

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%

=> 但緩衝長度越長的時候,越來越少磁區能滿足最後的播放期限。

Page 36: Is Random Scheduling Sufficient in P2P Video Streaming?

36

Page 37: Is Random Scheduling Sufficient in P2P Video Streaming?

37

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%

Page 38: Is Random Scheduling Sufficient in P2P Video Streaming?

38

Page 39: Is Random Scheduling Sufficient in P2P Video Streaming?

39

2. 考慮 the average hop count 的分配– (1) 當 peers 連接到 6 個鄰居 , 每個 chunk 需

橫越平均 6 個 hops– (2) 當 peer 連接到 14 個鄰居 , 平均路徑長 降低

到 低於 4.

Page 40: Is Random Scheduling Sufficient in P2P Video Streaming?

40

Page 41: Is Random Scheduling Sufficient in P2P Video Streaming?

41

Peer 離開率 與 分支度的影響

– 1. 初始值 ,每個 peer 皆有 14 degree– 2. 當 10%peer 離開,平均失誤率 12% , degree 降低到 13– 3. 當 40%peer 離開,平均失誤率 20% , degree 降低到 9– 4. 越多 peer 離開,鄰居越少,失誤率越高。

Page 42: Is Random Scheduling Sufficient in P2P Video Streaming?

42

Page 43: Is Random Scheduling Sufficient in P2P Video Streaming?

43

Large peering degree helps in improving system robustness in the face of peer churn.

– 當 degree=18 時, 50% 的 peer 離開,失誤率大概 15%– 但 degree=10 時, 50% 的 peer 離開,失誤率大概是 30%

Page 44: Is Random Scheduling Sufficient in P2P Video Streaming?

44

Page 45: Is Random Scheduling Sufficient in P2P Video Streaming?

45

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

Page 46: Is Random Scheduling Sufficient in P2P Video Streaming?

46

心得: 1. 目前商業 P2P 串流系統仍處在約 400k 左右或更低的

狀態,與目前網路的頻寬的發展關係密切。

2. 本篇主要的研究部分是以研究影音串流在網路的傳輸情況作考量,但是在頻寬往上提升的情況下, PC 電腦的效能與使用者網路的先天限制或許是影響到最後結果的因素之一。

3. 在讀這篇文章時發現到,作者將現有的網路傳輸技術做各種比較,這個精神值得我們仿效。