Advanced Network Seminar14.04.10

P2P in VoD

Constantin Radchenko

222

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

333

VoD Cost (YouTube)

2006 : 100 million views per day2009 : over a billion views per dayISPs charge 0.1-1.0 cent per video minute

bandwidth costs US$1 million per day!

not too profitable with client-server approach...

444

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 on9-month trace from MSN Video

520 million streaming requests for ~60000 videos

Analyze 3 pre-fetching policiesNo-prefetching

Water-leveling

Greedy

555

P2P/VoD Simulation Model (Cont.)

User interactivity

Early departures

Pause/resume

Skipping content

Impact on ISPs

Cross-ISP traffic

666

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-fetchingMoving from Surplus to Deficit mode

Server resources increase dramatically, particularly for large number of users

777

Pre-fetching Policies

Why to pre-fetch ?Unused surplus upload capacity

While in surplus mode, store data for possible future deficitThe 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

888

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

999

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)

101010

Greedy pre-fetching

Each peer dedicates its remaining upload bandwidth to the next peer right after itselfAlgorithm :

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

111111

Simulation Results on Pre-Fetching Policies

In Balanced mode, pre-fetching provides significant improvementsGreedy policy is slightly better than water-leveling policy

121212

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-positioningReal-world case : early departure and re-positioning

131313

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

141414

No User Interactivity

Server rate is dramatically reduced for peer-assisted system vs client-serverFor 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)

151515

User Interactivity. Early Departures.

Still see significant improvement in performanceImproves even over non-prefetching policy

particularly, in balanced mode (1.8-2.6)

161616

User Interactivity. Early Departures and Re-Positioning

Too difficult to simulate, basing on existing traces : don’t know what content user skippedConservative approach

Upload bandwidth is zero after interactivity

Optimistic approachAll content is available for upload

171717

User Interactivity. Early Departures and Re-Positioning

Too difficult to simulate, basing on existing traces : don’t know what content user skippedConservative approach

Upload bandwidth is zero after interactivity

Optimistic approachAll content is available for upload

No significant changes due to re-positioning

181818

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.

191919

Scalability

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

202020

Impact on ISPs

Balance between VoD provider’s server cost and P2P cross traffic among ISPsISP relationship types

transit (aka customer-provider)

sibling (same organization ISPs)

peering (free traffic exchange)

212121

Impact on ISPs.ISP-Unfriendly Peer-Assisted VoD.

No consideration to ISP economicsSignificant amount of traffic crossing ISP boundaries

222222

Impact on ISPs.ISP-Friendly Peer-Assisted VoD.

Restrict P2P traffic to be contained within ISP entityBetter than ISP-Unfriendly P2PBetter even than simple no-P2P (~50% improvement)

Possible reason for insufficient resultsmany ISPs were separated to two different entities for simulation, but, in fact, they belongs to the same entity…

232323

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 progressPiece Selection Policies

Rarest-First (aka Random)Strict In-Order(Random)

Strict In-Order(FCFS – First Come First Serve)

Variability of Downloads

242424

Analytic Model Definition

252525

Rarest-First

Each downloader acquires n (≤D)Each supplier provides UBased on Markov chain equations

Downloader arrives at rate λ

Downloader becomes seed at rate (x+y)UC

Seed leaves at rate μy

262626

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

272727

Rarest-First. Download Latency Analysis.

Is independent of peer arrival rate λ

scalability of BT-like systems

Decreased with upload capacity U increasingDecreased with seed residence time increasing 1/μ

282828

Rarest-First. System Efficiency.

U < D - due to demand-driven assumptionY << x – seeds is a small fraction of the system population

From experiments, η > 0.92

292929

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/MPiece is available

on all seeds

on half of peers (see probability above)

Demand for each piece :

303030

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

313131

Sequential Progress. Rarest-First (Random) vs In-Order.

Random policy provides a useful boundRarest-First behaves similarly to Random for sequential progress, as it ignores numerical ordering of pieces like pure Random

323232

Sequential Progress. Rarest-First (Random) vs In-Order.

Random policy provides a useful boundRarest-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) ?

333333

Sequential Progress. Rarest-First (aka Random).

Divide file to M piecesDownloader 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 ?

343434

Sequential Progress. Rarest-First (aka Random).

Divide file to M piecesDownloader 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 ?

353535

Sequential Progress. Rarest-First (aka Random).

Divide file to M piecesDownloader 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?

363636

Sequential Progress. Rarest-First (aka Random) (Cont.)

About half of the file must be retrieved before E[j]≥1Even 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 filledAbsolute startup delay can be calculated from sequential progress :

where r is playback rate

Large gap between Random and In-Order policiesthere are a lot of policies between them…

373737

Strict In-Order

Downloader sends D concurrent requestsonly subset of these requests may be satisfied

Since strict in-order, downloader never uploads to its provider peerIf uploader receives more than U requests, it chooses randomly U from and drops others

383838

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 RFTotal swarm population depends on seed residence timeStrict In-Order is sluggish vs RF

393939

Strict In-Order

Reasons for sluggishnessUnevenly 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

404040

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

414141

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 pieceContinue with peer that responses quickly

Use finite cache – peer discards piece after playing it locally

Provides temporal bound on useful peer relationships

424242

Sequential Progress. Strict In-Order.

Startup DelayDetermined 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 rateScaling

434343

Sequential Progress. Strict In-Order (FCFS).

Startup DelayAchieves 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

444444

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

454545

Simulation Results.Total swarm population.

Rarest-First / In-Order (FCFS) In-Order

464646

Simulation Results.Download Time.

Rarest-First / In-Order (FCFS) In-Order

474747

Simulation Results.Startup Delay.

In-Order (FCFS) In-Order

484848

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, Anirban Mahanti, Niklas Carlsson