advanced network seminar 14.04.10 p2p in vod constantin radchenko
Post on 18-Jan-2016
224 Views
Preview:
TRANSCRIPT
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
top related