P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in Peer-to-Peer Environment Tai T.Do, Kien A. Hua, Mounir A. Tantaoui Proc. of the IEEE Int. Conf. on Communications (ICC 2004)

2 Outline Introduction Related Work Architecture of P2VoD Performance Evaluation Conclusion

3 Introduction P2P approach can potentially solve many serious problems posed in existing streaming systems Infeasibility of IP Multicast Network bottleneck at the video server Several projects on “live streaming” Not trivial to apply these techniques into VoD systems

4 Introduction (cont.) Live streaming Shorter end-to-end delay, more lively the stream Short tree rooted at the video server User simply joins an on-going live streaming session User may not quit if QoS degrades VoD streaming Liveness is irrelevant, video is pre-recorded Whole video must be delivered User will stop watching if QoS degrades

5 Introduction (cont.) Proposed techniques not based on any existing live streaming systems Problems to be solved for a P2P VoD streaming system Fast and localized failure recovery without jitter Quick join Effective handling of clients’ asynchronous requests Small control overhead P2VoD (Peer-to-Peer approach for VoD streaming)

6 Related Work: P2Cast Architecture uses a P2P approach to stream video using patching Build application level multicast tree Server streams the entire video over base tree P2Cast clients provide two functions Base stream forwarding Patch serving Base tree construction & patch server selection algorithm Best Fit (BF): find the “fattest pipes” to requesting clients BF-delay: also use network delay information BF-delay-approx: not using actual available bandwidth, (1 or 0 represents enough bandwidth or not)

7 Architecture of P2VoD A streaming connection is assumed to constant bit-rate equals to the playback rate of the video Retrieval block (R-block) as a data unit of the video equivalent to one unit of playback time Each client has a buffer, whose maximum size is worth of MB units of playback time (i.e. MB R-block)

8 Architecture of P2VoD (cont.) ab X : actual amount of buffer storage used by a client X 1 ≤ ab X ≤ MB By using the cache, early arriving client can serve late coming clients by forwarding the stream tj X : the joining time of a client X X can serve clients whose joining time [ tj X, tj X + ab X ]

9 P2VoD system ab C 1 = MB = 5, ab C 4 = 3 < MB When C 6 arrives to the system at time 3, the first R-block of the video is still in the buffer of C 1 C 1 can serve the video stream to C 6

10 Architecture of P2VoD (cont.) “Generation” Group of clients having the same smallest numbered R-block in their caches Generations are also numbered 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 none of the clients has the first R-block of the video

11 P2VoD system C 1, C 2, C 3, C 4, and C 5 all have the same smallest number R-block

12 Data Caching and Generation (cont.) Rules to build generations Generations are indexed by 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, OR be the first member of a newly created generation of that video session

13 Data Caching and Generation (cont.) Caching scheme with the generation concept X and Y join the same generation at time tj X and tj Y Caching Rule: The difference of actual cache sizes used by two peers in the same generation must offset the difference in their arrival times ab X – ab Y = tj Y – tj X E.g. ab C2 = ab C1 – (tj C2 – tj C1 ) = 5 – (1 - 0) = 4

14 Data Caching and Generation (cont.) Assume that at time 36, peer C 3 fails. C 1, C 2, C 4, C 5 available to C 8 allow a quick and localized recovery for C 8

15 Control Protocol Control Protocol is required to maintain the system connectivity X sends control information to server when joining the system : expiration time when the first R-block of the video is no longer in the cache of X Neighbors of peer X Siblings (peer in same G): need to keep a list of their IP addresses Periodically update the list Update the list on-demand (joining/leaving) Child: agree to forward the video stream, X needs to send the IP addresses of X and its siblings to its child Parent: first join the system, X sends the IP address to its parent

16 Join Algorithm Server S has the list of peers at the youngest generation for each video session, denoted as G y Expiration time is the same for every member of the youngest generation Initially, when the system is empty is set to minus infinity Set of youngest generation peers contains only S

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

18 Join Algorithm (cont.) Case 2 proceeds as follows. Step1 X contacts a random member of the G y set acquires the list of peers at the super generation of G y. Step2: If t exp at the super generation > tj X, then go to Step3 Otherwise go to Step4 Step3: (generation not expired) X selects a parent from the super generation If such a candidate exists, X becomes a member of G y  X starts receiving the video stream from its selected parent  X sets its actual cache size ab X to conform to the caching rule Otherwise go to Step4

19 Join Algorithm (cont.) Case 2 proceeds as follows. Step4: (generation expired) A new generation is formed below G y X becomes the first member of that generation Actual cache size ab X is set to equal to MB X selects a peer from G y as its parent If no such peer exists, X tries other open video sessions or contacts the server

20 Parent Selection Criteria Round Robin Selection promote the fairness among peers the requesting peer should select a peer, who hasn’t served any client for the longest period of time Smallest Delay Selection minimize the joining time of the requesting peer the requesting peer picks the first peer in the candidate group, who has enough out-bound bandwidth Smallest Distance Selection 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

21 Failure Recovery P2VoD uses a two-phase failure recovery protocol 1) Detecting failure Grateful failures: When a peer leaves 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

22 Failure Recovery (cont.) 2) Recovering from failures Failure at a peer X, the whole sub-tree under X is affected The rest of the sub-tree are informed to wait through the WAIT msg A disrupted peer X finds a new parent X contacts the siblings of its parent If no such parent exists, X contacts the server Otherwise, X is rejected X succeeds, the sub-tree is recovered X fails, the immediate children of X will invoke the recovery process

23 Performance Evaluation Examine the effects of two parameters in P2VoD: max number of clients allowed in the first generation of each video session, K max buffer size each client can use, MB Compare P2VoD with P2Cast 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

24 Performance Evaluation (cont.) Rejection probability probability that a client tries to join the system but can not get the service Server stress amount of bandwidth used at the server, or the number of streams established at the server Number of contacts during the recovery number of nodes a client has to contact during the recovery process

25 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

26 Server stress with various values of K (MB = 0.1) In light workload, almost every clients get the video stream directly from the server In 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 With large K, such failure only cause a portion of the video session to be in recovery mode

27 P2VoD vs. P2Cast: Client rejection probability P2VoD use K =6 & MB = 0.2 The threshold for P2Cast is set at 0.2. P2VoD outperforms BF because P2Cast requires each client to obtain two streams

28 P2VoD vs. P2Cast: Server stress In P2VoD, a video session is open as long as clients in the G y still have the first block of the video buffer In P2Cast, a video session is open for a short period of time starting when the first client join the video session and last for the length of the threshold

29 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 more clients leave the system, network bandwidth is also released easier for an affected client to find a new parent

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