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

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

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

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

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.

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.

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.

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

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

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

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

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

ISP server charges 95 th 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 95 th percentile value is the smallest number that is greater than 95% of the values in the set

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 M is the number of peers of type m Probability of user type m is p m System’s average upload B/W is   p m w m Expected number of type m users is p m  In steady state average total demand is r  p m  r  Average supply is  p m  w m 

Modelling – Single Video System is in surplus mode if S > D, i.e.  p m w m > 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

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 u j, j = 1,..., n, is the upload bandwidth of the j th user and This user is of type m with upload B/W w m with probability p m. State of the system be (u 1, u 2, · · ·, u n ) and the rate required from the server is s(u 1, u 2, · · ·, u n ). 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 u 1 is not sufficient. And so on. … e.g, for n = 2, we have s(u 1, u 2 ) = r + max(0, r − u 1 ). Monte Carlo simulations for random n, u j and set D/S

No-prefetching Results S/D is Supply / Demand Two types of users: w 1 = 768 kbps, w 2 = 256 kbps, r = 512 kbps and T = 300s.

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.

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

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.

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.

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

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

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

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

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.

Cost videos How many users?

Cost Reduction videos 95 th percentiles of server rates

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.

P2P VoD greatly increases ISP costs Most P2P VoD crosses ISP boundaries

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.

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

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