Is Random Scheduling Sufficient in P2P Video Streaming?

Post on 05-Jan-2016

43 views 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 of 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 張欽天

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 de

signs

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 fre

sh data chunks that have not been sent out before

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.

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

20

21

串流系統的環境

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

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

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

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.

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

25

26

註: CDF= Cumulative Distribution Function value

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

94%80%72%

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.

28

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

960Kbps

1100Kbps圖 5-a

29

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

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

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

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

圖 5

Loading 較重

Loading 較輕

31

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

32

圖 7

33

圖 7

34

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

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%

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

36

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%

38

39

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

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

到 低於 4.

40

41

Peer 離開率 與 分支度的影響

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

42

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%

44

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

46

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

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

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

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