1. Using P2P Technologies for Video on Demand (VoD) Limor Gavish limorgav at tau.ac.il Yuval Meir wil at tau.ac.il Tel-Aviv University Based on:  Cheng Huang, Jin Li, Keith W. Ross, "Can Internet Video-on-Demand Be Profitable," in Proc. of ACM SIGCOMM, August 2007  N. Parvez C. Williamson, Anirban Mahanti, Niklas Carlsson Analysis of BitTorrent-like Protocols for On-Demand Stored Media Streaming, Sigmetrics 2008

2. VoD - Introduction VoD providers enable users to watch videos on-line without waiting for the entire file to download. Examples: YouTube, MSN Video, Flicker, Yahoo Video.

3. Traditional VoD System design All users download the contents directly from the server (or a content distribution network).

4. The Problem Bandwidth is a significant expense for VoD providers. For example, according to estimation, YouTube was paying about 1$Million/month for bandwidth alone as of 2007. Demand is growing. Providers want to increase video quality (and therefore BW).

5. Suggested Solution Peer assisted VoD

6. There is still a server. The peers that are viewing the video help in redistributing it. Each MB uploaded from one peer to another means 1MB less the server has to upload.

7. Comparing Users Demand and Upload Resources All information gathered from a large scale trace on MSN video service from April to December 2006. According to measurements of download bandwidths, the following information was gathered: Providers may give incentives to users for bandwidth contribution, especially at peek hours.

8. Peer Assistance May Help Based on measurements, the day with the maximum traffic in April had bandwidth requirements from the server and total upload resources as described in the following figure: Conclusion: peer-assisted VoD may perform well.

9. Three possible modes of the system The figure in the previous slide exhibits significantly more upload resources than peer demand. This is called surplus mode. There are 3 possible modes: Surplus Mode – total upload resources of peers greater than total demand. Deficit Mode – total upload resources of peers less than total demand. Balanced Mode – total upload resources of peers approx. as total demand.

10. No-Prefetching policy (1) Each user downloads at playback rate. No pre-fetching for future needs. Assume n users in the system. The user that arrived first can only download from server. User k can download from users 1, …,k-1, and from the server if it is not satisfied.

11. No-Prefetching policy (2) Let u i be the upload bandwidth of the i th user. (u 1, …,u n ) is the state of the system. s(u 1, …,u n ) is the rate required from server. According to previous slide we get: Where r is the video playback rate.

12. No-Prefetching policy (3) In surplus mode, we conclude that: Server upload rate is close to the playback rate. (i.e negligible). Additional users may be added without increasing server bandwidth. Video quality may be increased without increasing server bandwidth, until reaching balanced mode.

13. No-Prefetching policy (4) In deficit mode: When supply S is substantially less than demand D server rate almost equals D-S. Server resources increase dramatically in the move from balanced mode to deficit mode. In all cases, no-prefetching policy reduces server bandwidth rate.

14. No-prefetching is not Optimal Balanced mode is actually a dynamic equilibrium The system fluctuates between deficit and surplus No-prefetching is not optimal under these conditions – peer BW sits idle in the surplus phase, and server BW is consumed in the deficit phase.

15. Prefetching Server never sends prefetched contents. Server only used to fulfill current demand. User may drain his reservoir before requesting new data.

16. Two Prefetching Schemes Water-leveling Try to equally distribute surplus capacity. If there is a peer with less prefetched content, all peers channel their surplus bandwidth to him. Greedy Each user dedicates its surplus upload bandwidth to the next user. Those policies are nearly optimal considering average server bandwidth (the greedy policy is slightly better).

17. Simulation of the Greedy Policy Based on data from MSN video trace We consider three cases All users watch the entire video without interactivity Users may depart early, no interactivity Both early departures and interactivity

18. No Departures, No Interactivity (1) The figure below compares performance of VoD with P2P for the most popular videos on April 2006:

19. No Departures, No Interactivity (2) The table below presents the results in the context of the 95 percentile rule We observe that the greedy policy is close to the lower bound of server resources N.P. is no prefetching

20. 95 Percentile Rule The average server upload bandwidth is measured every 5 minutes within the month. The ISP charges according to the 95 percentile of these values. We will use this for measuring the bandwidth cost for the service provider.

21. No Departures, No Interactivity (3) We observe that: P2P reduces server rate dramatically Server resources are barely needed, only in case of small no. of peers. We can offer much higher quality without significantly more server resources Peer assistance can be beneficial for both flash crowd (gold stream) and long lasting (silver stream)

22. Early departures (1) Duration of session may vary. Especially when viewing longer videos. The table below compares server rates for different system modes, for the silver stream Bitrate scaling refers to the video playback rate

23. Early departures (2) We conclude that: Even with early departures, peer assistance provides dramatic improvement Prefetching provides improvement over no- prefetching, particularly in balanced mode.

24. User Interactivity (1) Popular among long videos According to trace, 40% of over 30 minutes videos contained interactivity A user may have holes in his buffer Two possible approaches for analysis: Conservative: User bandwidth is zero after interactivity – lower bound Optimistic: Assume there are no holes – upper bound

25. User Interactivity (2) The below plot compares the approaches for the traffic on April 18 th 2006 We see that the loss of bandwidth due to interactivity is insignificant Thus the results for early departures are also representative

26. Summary of simulation The savings using the 95 percentile rule: Server bandwidth may be reduced by 97% at current quality Alternatively, triple quality and trim server bandwidth by 37.6%

27. P2P good for popular videos 12,000 videos available on MSN on April 2006 Rank by popularity and classify into 4 groups Compare the 95 percentile of each group Popular videos are a smaller fraction of bandwidth in P2P Conclusion: P2P is especially beneficial for popular videos

28. ISP Friendly P2P (1) We maximized server bandwidth savings using P2P This approach is costly for ISPs Observations have showed that most P2P traffic crosses entity boundaries

29. ISP Friendly P2P (2) Extreme approach: constrain P2P traffic within entities Increases server bandwidth, but still better than client-server VoD Need to find balance between approaches

30. Summary We have showed the potential of P2P for saving server bandwidth costs With / Without pre-fetching The implications of user interactivity We have discussed the implications on ISPs

31. Bit-Torrent Protocols for VoD

32. Introduction As said earlier, P2P may be extremely beneficial for VoD We would like to analyze the performance of P2P VoD in a server-less setting We will try to modify the BitTorrent protocol to the constrains of VoD

33. Piece Selection Policies (1) Like in BitTorrent, we assume that a file is obtained in pieces In the usual BitTorrent protocol, peers use a Rarest-First policy to ensure high piece diversity Downloaders prefer pieces that are rare among the peers in the swarm

34. Piece Selection Policies (2) Is rarest-first policy efficient also for on demand streaming? We will analyze the performance of the Rarest First policy, and compare it to strict in order piece selection policies. Strict in order piece selection Strict in order piece selection (FCFS)

35. Mathematical Model (1) In order to measure the performance of different piece selection policies, we construct a mathematical model The system has a poisson behavior Peers enter the system at rate download the entire file become seeds at rate and depart after a constant time 1/ 

36. Mathematical Model (2) Model Notations: Target file divided into M pieces File playback rate is r Each peer has: U upload connections D download connections x is the number of downloaders in the system y is the number of seeds in the system Downloaders enter the system at rate Download latency is T

37. Mathematical Model (3) Model Notations (continued): Startup delay is  Seeds reside in the system for 1/  time C is the throughput per connection Model Assumptions: D>U Demand is greater than supply: xD>(x+y)U All peers are equal Steady state – always same number of downloaders and seeds Peers are cooperative Peers download the entire file

38. Rarest First Policy (1) As explained, in rarest first peers prefer pieces that are rare among the swarm Probability for a peer to obtain a successful connection

39. Rarest First Policy (2) Calculations show that download latency in Rarest First model is Independent of the peer arrival rate Near optimal – high utilization of upload bandwidth

40. Rarest First Policy and sequential progress (1) Sequential Progress = acquiring the initial pieces from the beginning of the Sequential Progress is independent of download progress Strict in order policies retrieve the pieces in order – ideal sequential progress

41. Rarest First Policy and sequential progress (2) Rarest first is like random piece selection – provides poor sequential progress

42. Rarest First Policy and sequential progress (3) The probability to download pieces 1 through j after having k pieces is Thus the expected value of j is Plotted in the figure from previous slide

43. Rarest First Policy and sequential progress (4) We conclude that: Bad sequential progress E[j] 1 only after retrieving half of file After retrieving M-1 pieces j is expected at most half of the file Startup delay If the playback rate is r, the startup delay is Startup delay gets worse as M increases

44. Strict in Order Policy (1) Peers request pieces in numerical order from connected peers In each round peer issues D concurrent requests to “ older ” peers A subset of these requests are satisfied in the round, unsatisfied requests are purged Relationship are a-symmetric An uploader that receives more than U requests chooses randomly

45. Strict in Order Policy (2) For a peer that has been in the system for time t, the probability to obtain a successful upload connection is: For ease of presentation we will rewrite this formula with a new variable  Numerical experiments show that  is typically in the range [1.09,1.25]

46. Strict in Order Policy (3) Further calculations show that the average download latency is: Conclusion: The average download latency is almost double than rarest first

47. Strict in Order policy – startup delay  is the fraction of data that is allowed to arrive late Then the startup delay is It reaches maximum when t=T so We can do better

48. Strict in Order Policy (FCFS) (1) Peers are queued until they are serviced Fair progress, no starvation Each peer is allowed D outstanding requests at any time Probability for a peer to obtain a successful connection is independent of age Exactly like rarest-first

49. Strict in Order Policy (FCFS) (2) Calculations show that download latency is Like the latency of rarest-first – near optimal

50. Strict in Order policy (FCFS) – startup delay (1) Calculation bring us to the conclusion that startup delay is It reaches maximum when t=T so We conclude that: In-Order (FCFS) achieves lowest startup delay

51. Strict in Order policy (FCFS) is optimal Final conclusion: Strict in Order policy (FCFS) is optimal for on- demand streaming Near optimal download latency Best sequential progress (startup delay)

52. Model Validation Validation of the analytic model using a simulation experiment All peers have identical U,D,C Peers perform complete download and stay a bit afterwards Inter arrival times of peers are exponential Seed residence time distributes normally

53. Validation results (1) Effect of arrival rate on download latency Analytical model predicts independence Results show similar trends, though In-Order (Random deviates a little) Notations: + – Rarest first o – in order random – in order FCFS

54. Validation results (2) Effect of seed residence time on download latency Like in analytical model, more seeds in the system means faster download

55. Validation results (3) Effect of upload bandwidth on download latency As expected: more upload bandwidth means faster downloads Until download bandwidth becomes bottleneck

56. Validation results (4) Effect of arrival rate on startup delay Analytical model predicts independence Simulation confirms this, though little deviation for random Startup delay of in- order(FCFS) is lower than Rarest-first. In-order random is much worse

57. Validation results (5) Effect of seed residence time on startup delay Increasing seed residence time reduces startup delay In-Order (FCFS) has the lowest startup delay Both in-order policies reach lower bound i.e. piece retrieval time Rarest first never reaches this point

58. Validation results (6) Effect of upload bandwidth time on startup delay Increasing upload bandwidth reduces startup delay. For in-order policies, startup delay equals piece retrieval time when upload bandwidth is large enough

59. Validation Conclusions The simulation results show good agreement with analytical model

60. Possible Future Research ISP friendly P2P VoD strategies How to enforce peer cooperation as we ’ ve seen, Tit-for-Tat doesn ’ t work