P2P in VoD

1. P2P in VoD Advanced Network Seminar 14.04.10 ConstantinRadchenko

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

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

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

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

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

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

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

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

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 10 10

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

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 12 12

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 13 13

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

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

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 16 16

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 17 17

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

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

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

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

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… 22 22

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 23 23

24. Analytic Model Definition 24 24

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 25 25

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 26 26

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/μ 27 27

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 28 28

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 : 29 29

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 30 30

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 31 31

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) ? 32 32

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 ? 33 33

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 ? 34 34

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? 35 35

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… 36 36

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 37 37

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 38 38

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 39 39

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 40 40

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 41 41

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 42 42

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 43 43

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 44 44

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

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

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

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, AnirbanMahanti, NiklasCarlsson 48 48