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

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.

Traditional VoD System design All users download the contents directly

from the server (or a content distribution network).

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

Suggested Solution Peer assisted VoD

Peer assisted VoD

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.

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.

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.

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.

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.

No-Prefetching policy (2)

Let ui be the upload bandwidth of the ith user.

(u1,…,un) is the state of the system. s(u1,…,un) is the rate required from server. According to previous slide we get:

Where r is the video playback rate.

iu

)))1(,0max((max),...,(1

111

j

ii

njn urjruus

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.

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.

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.

Prefetching

Server never sends prefetched contents.

Server only used to fulfill current demand.

User may drain his reservoir before requesting new data.

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

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

No Departures, No Interactivity (1) The figure below compares performance of

VoD with P2P for the most popular videos on April 2006:

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

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.

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)

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

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.

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

User Interactivity (2) The below plot compares the approaches for

the traffic on April 18th 2006 We see that the loss of bandwidth due to

interactivity is insignificant Thus the results for

early departures are also representative

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%

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

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

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

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

Bit-Torrent Protocols for VoD

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

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

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)

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/

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

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

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

xD

Uyxp

)(

demand

supply

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

11

UC

T

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

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

provides poor sequential progress

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 slide1

][

kM

kjE

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

1)1(2)1( rMrM

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

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]

tyxyx

DtyxDtxD

Utyxtp

ln)(

)(

demandconnection

supplyconnection)(

xD

Utyxtp

)(

demandconnection

supplyconnection)(

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

11

2UC

T

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

r

tx

txy

UC

tMCt )1(

21

,1

max

2

rUCMC )1(

1112,

1maxmin

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

xD

Uyxp

)(

demand

supply

Strict in Order Policy (FCFS) (2)

Calculations show that download latency is

Like the latency of rarest-first – near optimal

11

UC

T

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

r

xy

UCt

MCt

1

1,

1max

rUCMC )1(

111,

1maxmin

Strict in Order policy (FCFS) is optimal Final conclusion:

Strict in Orderpolicy (FCFS) is optimal for on-demand streaming

Near optimal download latency Best sequential progress (startup delay)

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

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

Validation results (2) Effect of seed residence time on

download latency Like in analytical

model, more seedsin the system means fasterdownload

Validation results (3) Effect of upload bandwidth on

download latency As expected:

more upload bandwidth means faster downloads

Until downloadbandwidth becomes

bottleneck

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

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

Validation results (6) Effect of upload bandwidth time on startup

delay Increasing upload

bandwidth reduces startup delay.

For in-order policies,startup delay equalspiece retrieval time when upload bandwidth is large enough

Validation Conclusions

The simulation results show good agreement with analytical model

Possible Future Research

ISP friendly P2P VoD strategies

How to enforce peer cooperation as we’ve seen, Tit-for-Tat doesn’t

work