1. Advanced Network Seminar 14.04.10 P2P in VoD Constantin Radchenko

2. 222 What is VoD (Video-on-Demand) ? Systems which allow users to select and watch/listen to video content on demand YouTube MSN Video Google Video Bing Video (aka Live Search Video) Yahoo! Video

3. 333 VoD Cost (YouTube) 2006 : 100 million views per day 2009 : over a billion views per day ISPs charge 0.1-1.0 cent per video minute bandwidth costs US$1 million per day! not too profitable with client-server approach...

4. 444 P2P/VoD Simulation Model [1] Can Internet Video-on-Demand be Profitable? Cheng Huang, Jin Li, Keith W. Ross [2] Peer-Assisted VoD: Making Internet Video Distribution Cheap Cheng Huang, Jin Li, Keith W. Ross Based on 9-month trace from MSN Video 520 million streaming requests for ~60000 videos Analyze 3 pre-fetching policies No-prefetching Water-leveling Greedy

5. 555 P2P/VoD Simulation Model (Cont.) User interactivity Early departures Pause/resume Skipping content Impact on ISPs Cross-ISP traffic

6. 666 No-Prefetching Policy Surplus mode (S > D) Server rate ≈ video bit rate r Does NOT increase as the system scales Greatly reduce server rate even w/o pre-fetching Can increase QoS w/o increasing average server bandwidth Deficit mode (S < D) Server rate ≈ D-S No needs in pre-fetching Moving from Surplus to Deficit mode Server resources increase dramatically, particularly for large number of users

7. 777 Pre-fetching Policies Why to pre-fetch ? Unused surplus upload capacity While in surplus mode, store data for possible future deficit The most attractive in balanced mode (D ≈ S) How to pre-fetch ? Pre-fetch only from peers : save bandwidth at server If peer has pre-fetched data, use it before new data requests How to allocate surplus upload ? Dozens of schemes

8. 888 Water-leveling pre-fetching Water-leveling Policy Equalize the reservoir levels across all the peers If one peer has less pre-fetched content, all surplus upload is channeled to this peer When it reaches the same level as others, continue distribution among all the peers

9. 999 Water-leveling pre-fetching (Cont.) Algorithm : pass through all the users in order and determine the required server rate to support real-time playback process all the users (from one with the smallest buffer level) to assign remaining bandwidths traverse all the users again in order and adjust the growth rate (extra upload bandwidths assigned to user beyond satisfying its real-time demand)

10. 10 Greedy pre-fetching Each peer dedicates its remaining upload bandwidth to the next peer right after itself Algorithm : Scan each peer Determine rate that is required to satisfy real-time demands Record its remaining upload bandwidth For each peer, allocate as much bandwidth as possible to the subsequent peer

11. 11 Simulation Results on Pre-Fetching Policies In Balanced mode, pre-fetching provides significant improvements Greedy policy is slightly better than water-leveling policy

12. 12 User Interactivity All users watch the entire video w/o departing early or re-positioning in the content (pause/skipping) Preserve early departures but ignore re- positioning Real-world case : early departure and re- positioning

13. 13 User Interactivity Statistics Why to Consider User Interactivity ? Less that 20% of the users view more than 60% of the videos longer than 30 minutes

14. 14 No User Interactivity Server rate is dramatically reduced for peer-assisted system vs client-server For P2P deployment at the current quality level, no server resources are needed Only for small numbers of concurrent users in the system Easy to improve QoS (x3)

15. 15 User Interactivity. Early Departures. Still see significant improvement in performance Improves even over non-prefetching policy particularly, in balanced mode (1.8-2.6)

16. 16 User Interactivity. Early Departures and Re-Positioning Too difficult to simulate, basing on existing traces : don’t know what content user skipped Conservative approach Upload bandwidth is zero after interactivity Optimistic approach All content is available for upload

17. 17 User Interactivity. Early Departures and Re-Positioning Too difficult to simulate, basing on existing traces : don’t know what content user skipped Conservative approach Upload bandwidth is zero after interactivity Optimistic approach All content is available for upload No significant changes due to re-positioning

18. 18 Costs Improvement. 95-percentile value. The average server bandwidth is measured every 5 minutes within each month. These bandwidth measurements over a month form a set of values, and the 95 percentile value is the smallest number that is greater than 95% of the values in the set.

19. 19 Scalability Even after increasing of download bandwidth twice, P2P approach still provides costs improvement of 97%

20. 20 Impact on ISPs Balance between VoD provider’s server cost and P2P cross traffic among ISPs ISP relationship types transit (aka customer-provider) sibling (same organization ISPs) peering (free traffic exchange)

21. 21 Impact on ISPs. ISP-Unfriendly Peer-Assisted VoD. No consideration to ISP economics Significant amount of traffic crossing ISP boundaries

22. 22 Impact on ISPs. ISP-Friendly Peer-Assisted VoD. Restrict P2P traffic to be contained within ISP entity Better than ISP-Unfriendly P2P Better even than simple no-P2P (~50% improvement) Possible reason for insufficient results many ISPs were separated to two different entities for simulation, but, in fact, they belongs to the same entity…

23. 23 Analytic Model Basics [3] Analysis of BitTorrent-like Protocols for On-Demand Stored Media Streaming N. Parvez C. Williamson, Anirban Mahanti, Niklas Carlsson Download progress vs sequential progress Piece Selection Policies Rarest-First (aka Random) Strict In-Order(Random) Strict In-Order(FCFS – First Come First Serve) Variability of Downloads

24. 24 Analytic Model Definition

25. 25 Rarest-First Each downloader acquires n (≤D) Each supplier provides U Based on Markov chain equations Downloader arrives at rate λ Downloader becomes seed at rate (x+y)UC Seed leaves at rate μy

26. 26 Rarest-First. Population Analysis. Number of downloaders ~ peer arrival rate λ Number of seeds ~ seed residence time 1/μ Total swarm population is independent of the seed residence time

27. 27 Rarest-First. Download Latency Analysis. Is independent of peer arrival rate λ scalability of BT-like systems Decreased with upload capacity U increasing Decreased with seed residence time increasing 1/μ

28. 28 Rarest-First. System Efficiency. U < D - due to demand-driven assumption Y << x – seeds is a small fraction of the system population From experiments, η > 0.92

29. 29 Rarest-First. System Efficiency (Cont.) Rarest-First attempts to make each reach uniform distribution for required pieces among peers new peers have 0 pieces senior peers have ~ M pieces probability to find particular piece on peer is ½ Average demand of single piece is xD/M Piece is available on all seeds on half of peers (see probability above) Demand for each piece :

30. 30 Rarest-First. System Efficiency (Cont.) Number of idle connections on downloader is U-i*d(s) Number of downloaders with i pieces is x/M due to uniform dist of pieces among downloaders Number of idle connections on all downloaders

31. 31 Sequential Progress. Rarest-First (Random) vs In-Order. Random policy provides a useful bound Rarest-First behaves similarly to Random for sequential progress, as it ignores numerical ordering of pieces like pure Random

32. 32 Sequential Progress. Rarest-First (Random) vs In-Order. Random policy provides a useful bound Rarest-First behaves similarly to Random for sequential progress, as it ignores numerical ordering of pieces like pure Random What is the worst case policy (not practical) ?

33. 33 Sequential Progress. Rarest-First (aka Random). Divide file to M pieces Downloader retrieves one piece per unit time using BT-like protocol each piece is chosen uniformly at random After downloading k pieces how many sequential pieces we expect to ?

34. 34 Sequential Progress. Rarest-First (aka Random). Divide file to M pieces Downloader retrieves one piece per unit time using BT-like protocol each piece is chosen uniformly at random After downloading k pieces how many sequential pieces we expect to ?

35. 35 Sequential Progress. Rarest-First (aka Random). Divide file to M pieces Downloader retrieves one piece per unit time using BT-like protocol each piece is chosen uniformly at random After downloading k pieces how many sequential pieces we expect to ? HW : How we get this value?

36. 36 Sequential Progress. Rarest-First (aka Random) (Cont.) About half of the file must be retrieved before E[j]≥1 Even after retrieving M-1 pieces, expected sequential progress is at most half the file not too good for demand streaming Sequential progress is slow initially, but improves as missing holes are filled Absolute startup delay can be calculated from sequential progress : where r is playback rate Large gap between Random and In-Order policies there are a lot of policies between them…

37. 37 Strict In-Order Downloader sends D concurrent requests only subset of these requests may be satisfied Since strict in-order, downloader never uploads to its provider peer If uploader receives more than U requests, it chooses randomly U from and drops others

38. 38 Strict In-Order. Population and Download Latency. The average download latency almost doubles vs RF large price for in-order Number of downloads almost double vs RF Total swarm population depends on seed residence time Strict In-Order is sluggish vs RF

39. 39 Strict In-Order Reasons for sluggishness Unevenly distribution of load requests (older peers get more), so requests are dropped and may be re-issues many times Young peers don’t get many requests, so their uploads are wasted Young peers can always win while request purging on old peers and impede the progress of middle-aged peers

40. 40 Strict In-Order (FCFS) Uploaders do not purge requests, but queue them prevent starvation Each downloader operates at most D requests regularization to prevent too many requests in system

41. 41 How to improve loading of requests on peers ? Peer of age t downloads only from peers of age t+∆ Duplicate download requests of the same piece Continue with peer that responses quickly Use finite cache – peer discards piece after playing it locally Provides temporal bound on useful peer relationships

42. 42 Sequential Progress. Strict In-Order. Startup Delay Determined by download latency and playback duration If downloading time exceeds playback duration, consider also time to download the first piece Decreases with increasing of upload capacity or peers and seeds resident time Independent of peer arrival rate Scaling

43. 43 Sequential Progress. Strict In-Order (FCFS). Startup Delay Achieves the lowest startup delay (vs ordinary In-Order, Rarest-First) Depends on the same parameters as ordinary In-Order Independent of peer arrival rate, similar to other policies

44. 44 Variability of Downloads Rarest-First / In-Order(FCFS) Only half of downloaders complete within expected time More demand D for insufficient supply U causes greater variability Variability independent of arrival rate Variability slightly decreases for higher seed residence

45. 45 Simulation Results. Total swarm population. Rarest-First / In-Order (FCFS) In-Order

46. 46 Simulation Results. Download Time. Rarest-First / In-Order (FCFS) In-Order

47. 47 Simulation Results. Startup Delay. In-Order (FCFS) In-Order

48. 48 Papers [1] Can Internet Video-on-Demand be Profitable? Cheng Huang, Jin Li, Keith W. Ross [2] Peer-Assisted VoD: Making Internet Video Distribution Cheap Cheng Huang, Jin Li, Keith W. Ross [3] Analysis of BitTorrent-like Protocols for On-Demand Stored Media Streaming N. Parvez C. Williamson, Anirban Mahanti, Niklas Carlsson