30
P 2 VoD: Providing Fault Tolerant Video-on-Demand Streaming in Peer- to-Peer Environment Tai T.Do, Kien A. Hua, Mounir A. Tantaoui Tech. Rep., University of Central Fl orida, 2003

P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

  • Upload
    ronny72

  • View
    290

  • Download
    0

Embed Size (px)

Citation preview

Page 1: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in Peer-to-Peer Environment

Tai T.Do, Kien A. Hua,

Mounir A. Tantaoui

Tech. Rep., University of Central Florida, 2003

Page 2: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

2

Outline

Introduction Related Works

P2Cast Architecture of P2VoD Performance Evaluation

Adjust Parameters in P2VoD P2VoD vs. P2Cast

Conclusion

Page 3: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

3

Introduction

P2P approach can potentially solve many serious problems posed in existing VoD systems including The infeasibility of IP Multicast Network bottleneck at the video server The high maintenance/deployment of dedicated overla

y routers. Consider the problems to be solved for a P2P VoD st

reaming system: Quick join Fast and localized failure recovery without jitter Effective handling of clients’ asynchronous requests Small control overhead

Page 4: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

4

Introduction (cont.)

P2VoD (Peer-to-Peer approach for VoD streaming)

Contributions in this paper Generation and a caching scheme to provide an

efficient failure recovery protocol. Designing an efficient application multicast tre

e appropriate for VoD streaming. Proposing an efficient control protocol to facilit

ate the join and failure recovery process.

Page 5: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

5

P2Cast

P2Cast clients provide two function: Base stream forwarding. Patch serving.

Base tree construction & patch server selection algorithm. Best Fit (BF) BF-delay BF-delay-approx

Page 6: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

6

Architecture of P2VoD

Preliminary Data Caching and Generation Control Protocol Join Algorithm Failure Recovery

Page 7: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

7

Preliminary

In P2VoD, a streaming connection is assumed to constant bit-rate, which equals to the playback rate of the video player.

We define a retrieval block (R-block) as a data unit of the video, which is also equivalent to one unit of playback time.

R-blocks of a video are numbered from 1 to the length of the video file according to their temporal position in the video.

Each client has a buffer, whose maximum size is worth of MB units of playback time (i.e. MB R-block)

Page 8: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

8

Preliminary (cont.)

The actual amount of buffer storage used by a client X is denoted as abX and lies in the range of 1 ≤ abX ≤ MB.

By using the cache, early arriving client can serve late coming clients by forwarding the stream.

If the joining time of a client X is tjX, then X can serve clients whose joining time is in the range of [tjX , tjX + abX ].

Page 9: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

9

Preliminary (cont.)

Clients having the same smallest numbered R-block in their caches are grouped into generation.

Generations are also numbered, starting from G1 as the oldest generation to Gn as the youngest generation.

Clients in these generations, excluding the server, form a video session.

A video session is closed when none of the clients within that video session still has the first R-block of the video.

Page 10: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

10

P2VoD system

abC1 = MB = 5, abC4

= 3 < MB

When C6 arrives to the system at time 3, the first R-block of the video is still in the buffer of C1.

C1 can serve the video stream to C6 .

C1, C2 , C3 , C4 , and C5 all have the same smallest number R-block

Page 11: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

11

Data Caching and Generation

Previous schemes for P2P VoD streaming do not handle failure recovery well. It creates network contention at the server wh

en there is a huge number of clients need to be reconnected.

It increases the reconnection time resulting in unacceptable glitch at client’s playback.

A generation in P2VoD is a group of clients, who always have the same smallest numbered R-block in their cache.

Page 12: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

12

Data Caching and Generation (cont.)

Assume X and Y join the same generation at time tjX

and tjY, they follow the caching rule: Caching Rule: The difference of actual cache sizes us

ed by two peers in the same generation must offset the difference in their arrival times, i.e.

abX – abY = tjY – tjX .

Ex. abC2 = abC1

– (tjC2 – tjC1

)

= 5 – (1 - 0) = 4

Page 13: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

13

Data Caching and Generation (cont.)

The main idea of grouping peers into generations is to provide quick and localized failure recovery without jitter.

The following rules are applied when building generations: Generations are indexed by numerical numbers starting from 1.

Members of a lower indexed generation arrive to the system no latter than any member of other higher indexed generations.

A peer in generation i-th (i > 1) receives the video stream from a peer in generation (i – 1)-th.

Peers at the first generation receive the video stream directly from the server.

When joining a video session of the system, a new peer belongs to the current highest numbered generation be the first member of a newly created generation of that video sessi

on.

Page 14: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

14

Data Caching and Generation (cont.)

Assume that at time 36, peer C3 fails.

C1, C2, C4, C5 available to C8 before the failure to allow a quick and localized recovery for C8.

Page 15: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

15

Control Protocol

Siblings: a peer only needs to keep a list of their IP addresses. Periodically update the list (peer in same G) Update the list on-demand (joining/leaving)

Child: when agreeing to forward the video stream, X only needs to send the IP addresses of X and its siblings to its child.

Parent: X when first joins the system, it sends the IP address to its parent.

Server: X send control information < addX, G(X), > to server when joining the system, where is the expiration time when the first R-block of the video is no longer in the cache of X .

XtexpXtexp

Page 16: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

16

Join Algorithm

Server S has the list of peers at the youngest generation for each video session, denoted as Gy

Expiration time , is the same for every member of the youngest generation.

Initially, when the system is empty, is set to minus infinity and the set of youngest generation peers contains only S.

Gytexp

Gytexp

Page 17: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

17

Join Algorithm (cont.)

Case 1: If all of the existing video sessions are closed, X will be admitted if server S still has enough outbound-bandwidth; otherwise, X will be rejected.

Case 2: For the case where there is at least one existing video session still open, X will try to join that video session.

Page 18: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

18

Join Algorithm (cont.) Case 2 proceeds as follows.

Step1: X contacts a random member of the Gy set, and acquires the list of peers at the super generation of Gy.

Step2: If texp at the super generation is greater than tjX, then go to Step3, otherwise go to Step4.

Step3: X selects a peer from the super generation to become its parent according to some parent selection criteria. If such a candidate exists, X becomes a member of Gy and starts receiving the video stream from its selected parent. X also sets its actual cache size abX to conform to the caching rule. Otherwise, go to Step4.

Step4: A new generation is formed below Gy in the hierarchy, and X is made the first member of that generation. X uses the same parent selection criteria to select a peer from Gy as its parent. The actual cache size abX is set to equal to MB. If no such peer exists, X will try other open video sessions if existed. Otherwise, X last tries to join the system as in Case1.

Page 19: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

19

Parent Selection Criteria

Round Robin Selection: this selection promotes the fairness among peers. Among peers who have enough out-bound bandwidth, the requesting peer should select a peer, who hasn’t served any client for the longest period of time.

Smallest Delay Selection: This strategy aims to minimize the joining time, hence startup delay, of the requesting peer. The requesting peer picks the first peer in the candidate group, who has enough out-bound bandwidth.

Smallest Distance Selection: The goal of this selection is to reduce the number of links involved in the underlying network. The requesting peer chooses a peer, who has enough out-bound bandwidth and closest to it.

Page 20: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

20

Failure Recovery

P2VoD uses a two-phase failure recovery protocol. 1) Detecting failure: Failures in P2VoD are categorized into two

kinds: grateful and unexpected. Grateful failures: When a peer decides to leave the system, it

forwards the LEAVE_MESSAGE to its children. Unexpected failures: it happens unexpectedly without any

explicit warning, peers in P2VoD are required to monitor their incoming traffic.

TEST_ERROR – quality of the video stream received is below a threshold.

NETWORK_RECOVER - suggest child to connect to better parent.

WAIT – asking the child to wait until its recovery is finished.

Page 21: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

21

Failure Recovery (cont.)

2) Recovering from failures: When there is a failure at a peer X, the whole sub-tree under X is affected. X initiates the recovery process, while the rest of the su

b-tree are informed to wait through the WAIT msg. If X fails to find a new parent, the immediate children of

X will invoke the recovery process to try to recover their own sub-tree.

A disrupted peer X uses the following steps to find a new parent for itself.

Step1: X contacts the siblings of its parent to find a new parent according to the selection criteria. If there exists such parent, X is recovered, otherwise go to Step2.

Step2: X contacts the server S if it has enough out-bound bandwidth. Otherwise, X is rejected.

Page 22: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

22

Performance Evaluation

Rejection probability - the probability that a client tries to join the system but can not get the service.

Number of contacts during the join - the number of nodes a joining client has to contact before it can start getting service.

Server stress - the amount of bandwidth used at the server, or the number of streams established at the server.

Number of contacts during the recovery - the number of nodes a client has to contact during the recovery process.

Page 23: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

23

Performance Evaluation (cont.)

Firstly, we examine the effects of two adjustable parameters in P2VoD: the max number of clients

allowed in the first generation of each video session, K.

the max buffer size each client can use, MB.

Secondly, compare P2VoD with P2Cast.

Used Smallest Delay parent selection algorithm.

Network topology using GT-ITM Clients arriving to system follow

the Poisson distribution.

one Transit network (with 4 nodes) 12 stub domains (with 96 nodes) backbone link support 25 streams, edge link support 7 concurrent streams.

Page 24: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

24

Fig. 3. Rejection probability for various maximum buffer sizes (K = 3) MB is varied from 0.1 to 0.4 of the length of the

video. When doubling size of MB, the rejection probability

is reduced by half.

Page 25: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

25

Fig. 4. Server stress with various values of K (MB = 0.1)

Almost every clients get the video stream directly from the server in the case of light workload,

While in the case of heavy workload most clients get the video stream from some other client, not the server.

With small K a failure at the first generation will likely cause disruption the whole video session.

Large K such failure onlycause a portion of thevideo session to be inrecovery mode.

The recommendation isto use a large K (ex. 8 or 10)

Page 26: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

26

Fig. 5. P2VoD vs. P2Cast: Client rejection probability BF has the best performance in server stress. BF-delay-approx achieves lowest rejection probability. P2VoD use K =6 & MB = 0.2. The threshold for P2Cast is set at 0.2. P2VoD outperforms BF, one possible explanation is that P2Cast require

each client to obtain two streams.

Page 27: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

27

Fig. 6. P2VoD vs. P2Cast: Server stress

In P2VoD, a video session is open as long as clients in the Gy still have the first block of the video buffer.

In P2Cast, a video session is only open for a short period of time starting when the first client join the video session and last for the length of the threshold.

Page 28: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

28

Fig. 7. P2VoD vs. P2Cast: Join overhead In BF-delay-approx, a new client only needs to find an existing

client with enough bandwidth to support the stream. In BF a new client has to look for “fattest pipe” to get the stream

from. A new client in P2VoD only needs to contact existing clients in

the Gy & super generation, BF-delay-approx may have contact every existing clients.

A new client in P2VoD onlylooks for one existing clientto get the stream from, BF-delay-approx needs to lookfor two existing clients toget two separate streams.

Page 29: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

29

Fig. 8. P2VoD vs. P2Cast: Failure overhead Clients arrive to the system at a rate of 0.4 per second during a

period of 2 hours. (3516 clients) When the failure probability increases, the number of clients

contacted during a recovery decreases. Because more clients leave the system, network bandwidth is

also released; this makes easier for an affected client to find a new parent.

Page 30: P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in

30

Conclusion

P2VoD, a new system for Video-On-Demand streaming in a Peer-to-Peer environment.

the concept of generation and caching scheme to deal effectively with failures.

An efficient control protocol help P2VoD to allow clients join the system fast, as well as to recover failures in a quick and localized manner.

Simulation-based performance study shows that P2VoD is superior than P2Cast.