Can Internet VoD be Profitable?

1. Cheng Huang (MSR), Jin Li (MSR), Keith W. Ross (NY Polytechnique) Can Internet VoD be Profitable?

2. Peer-Assisted VoD • Peers assist the server in delivering VoD • content • Assistance done so that it provides the same • user quality experience as pure client-server • distribution

3. The paper’s goal • Examine the design space and potential benefits of peer-assisted VoD

4. Methodology • MSN traces • Client info fields • Video content fields (file name, length, size) • Streaming • time client connects • point in video to start playback • Playback duration • MSN video does no prefetching, i.e. time to playback = time to stream • Each pause, resume, FF, FR and repositioning generates new trace

5. Methodology • Identify users • based on unique ID (only 7% had one) • hash (IP,player version,OS version, browser version) • Group traces by user • Group user traces by session • streaming session is as a series of streaming requests from the same player to the same video file, as long as the beginning time of one request is no more than 10 seconds after the ending time of the previous request. • Over 471 million streaming sessions in total.

6. Methodology • Identify users • based on unique ID (only 7% had one) • hash (IP,player version,OS version, browser version) • Group traces by user • Group user traces by session • streaming session is as a series of streaming requests from the same player to the same video file, as long as the beginning time of one request is no more than 10 seconds after the ending time of the previous request. • Over 471 million streaming sessions in total.

7. Video Popularity Distribution • Greater the locality of requests to a subset of videos, the greater are the benefits of peer-assistance • High Degree of Locality • Distribution is more skewed than Zipf.

8. User demand and upload resources • Determine the aggregate upload resources of the participating peers, and compare the aggregate upload resources with the aggregate user demand

9. User demand and upload resources • Available upload bandwidth at clients far exceeds • user demand

10. User Behavior • Users generally view large fraction of short videos, • But less than 20% of the users view more than 60% • of videos larger than 30 minutes

11. User Behavior • Fraction of sessions that start at the beginning of a • video and have no interactivity is important in the • success of a peer-assisted VoD. • For < 30 min videos, 80% of the session does not • have interactivity

12. Video Service Requirements Increase • The demand and the bitrates for VoD increase rapidly • They believe it is likely that bitrates will increase faster • than client upload B/W

13. ISP server charges • 95th percentile rule • Charge customer according to its peak B/W usage • but ignore anomalous periods, where usage is too • high. • The average server bandwidth is measured every • 5 minutes within each month. These measurements • over a month form a set of values, and the 95th • percentile value is the smallest number that is greater • than 95% of the values in the set

14. Modelling – Single Video • The time user remains online to see the video is T • The bitrate of the video is r • Users arrive with Poisson rate l • M is the number of peers of type m • Probability of user type m is pm • System’s average upload B/W is m =S pm wm • Expected number of type m users is pm l T • In steady state average total demand isr S pm l T = r l T • Average supply is S pml T wm = m l T

15. Modelling – Single Video • System is in surplus mode if S > D, i.e. • S pm wm > r • If system is in deficit mode, server must upload to peers • Even if on average the system is in surplus mode, the server may still need to help during demand bursts • Depending on the prefetching policy, the system may not be able to use all the client upload B/W

16. No prefetching model • Each user downloads at playback rate r and does not prefetch • Assume that each user views the video without gaps • At any instant of time there are n users in the system. • Order such that user n is the most recent to arrive, user n − 1 is the next most recent etc • uj , j = 1, . . . , n, is the upload bandwidth of the jth user and • This user is of type m with upload B/W wm with probability pm. • State of the system be (u1, u2, · · · , un) and the rate required from the server is s(u1, u2, · · · , un). • The demand of user 1 (r) can only be satisfied by the server. The demand of user 2 will be satisfied first by user 1 and then the server if u1 is not sufficient. And so on. … • e.g, for n = 2, we have s(u1, u2) = r + max(0, r − u1). • Monte Carlo simulations for random n, uj and set D/S

17. No-prefetching Results • S/D is Supply / Demand • Two types of users: w1 = 768 kbps, w2 = 256 kbps, r = 512 kbps and T = 300s.

18. No-prefetching observations • When S is greater than D by a substantial margin the server rate is very close to r and does not increase with number of clients • When operating in surplus mode, the provider can increase r without incurring significant increases in average server bandwidth. • When the supply S is less than the demand D by a substantial margin, the server rate almost equals to D−S. This means that when the system is in this high-deficit mode, users do not need to adopt sophisticated prefetching approaches. • No-prefetching does not perform well in the balanced mode, which motivates considering more sophisticated prefetching policies.

19. No-Prefetching Problem • Note that the upload bandwidth of the most recent user n is not utilized. Furthermore, if un-1 > r, the upload bandwidth portion un-1 – rof user n-1 is also wasted, as n-1 can only upload r to user n.

20. Water-Leveling Prefetching • When in a surplus state, the no-prefetching policy does not use the surplus upload bandwidth that might be available • When in deficit state, the server needs to supplement the peers’ uploading in order to satisfy the real-time demands. • If users prefetch and save for a rainy day, the server contribution can potentially be reduced. • With water-leveling users prefetch content and buffer data for their future needs. • Users do not prefetch from the server. • A peer only prefetches from those peers that arrived • before it and have sufficient upload bandwidth • WL consists of algorithms that aim at making all peers to have Almost the same buffer level.

21. Greedy Prefetching • With water-leveling data demands imposed on the server are usually generated by the earliest users. Due to the asymmetry of the P2P VoD, only earlier users can upload to later users, and early users are more likely to have less buffer than later users. Whenever users run out of buffer, these users will have to request data directly from the server. • First, pass through all users in order and process each of them to determine the server rate that satisfies the real-time demands. Record the remaining bandwidth at each user. • Second, pass through all users in order and allocate as much bandwidth as possible to the next user.

22. Discrete Even Simulation • When in balanced mode, prefetching helps a lot • The greedy policy does slightly better than water-leveling • Both the greedy and water-leveling policies are close to the D-S lower bound

23. Trace-data-based analysis • Two videos: popular for a few days (gold stream), popular for a month (silver) • Greedy Prefetching • Three cases: • a) users watch entire video without departing early and without interactivity. After watched the video they depart; • b) early departures but no interactivity; • c) original trace

24. No early departure • 1000-fold server rate reduction! • P2P deployment at the current quality level, typically no server resources are needed. Some resources needed when few concurrent users

25. Early departures • Even with early departures peer-assistance can provide a dramatic improvement • Prefetching continues to provide improvements over non-prefetching, particularly in the balanced mode

26. With User Interactivity • Do to interactivity, a user might have holes in its buffer • The first extreme approach, user upload bandwidth to zero after after interactivity (conservative) • The second approach assumes there is no hole in the user’s buffer (optimistic) • The actual performance will lie between these two bounds.

27. Cost • 12 000 videos • How many users?

28. Cost Reduction • 12 000 videos • 95th percentiles of server rates

29. ISP’s may not like P2P VoD • If peer-assisted VoD is deployed without considering the ISP economics there will be a significant amount of traffic crossing entity boundaries • Two types of ISP entity partitioning • Sibling entity includes all ISPs that are siblings to each other • Peering entity includes not only all siblings but peering ISPs too • To estimate the traffic crossing entity boundaries: • Map IP addresses of peers to ISPs using tools like the ASFinder. • Based on an inferred AS relationships dataset, group ISPs into economic entities • For each user, categorize peers from which user receives content: • 1) from peers within the same ISP entity; • 2) from peers from other entities. • Assume that the ratio of traffic from these two classes is • equal to the ratio of upload bandwidths for these two classes.

30. P2P VoD greatly increases ISP costs • Most P2P VoD crosses ISP boundaries

31. ISP friendly P2P VoD • Restrict P2P traffic to be contained within entity boundaries. • Due to rigid entity partitioning, the distribution of one video becomes several separate distributions, one for each entity watching the video. • Using the silver stream, we observe more than 5, 000 distinct video distributions. • When an entity contains few peers, the sharing becomes more difficult as well, and the server bandwidth is increased accordingly.

32. ISP friendly P2P VoD still reducesserver costs substantially • Silver stream single video, 5000 distinct video distributions • Top 10 more popular videos among the 12000 in traces.

33. Conclusion • Simulations and cost calculations • Peer-assisted VoD, with the proper prefetching policy, can dramatically reduce server bandwidth costs. • Peer assisted VoD can be both server and ISP friendly