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