Multicast with Cache (MCache) for Efficient Content Delivery in Video on Demand systems - PowerPoint PPT Presentation

Loading...

PPT – Multicast with Cache (MCache) for Efficient Content Delivery in Video on Demand systems PowerPoint presentation | free to download - id: 63d315-NDBkZ



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Multicast with Cache (MCache) for Efficient Content Delivery in Video on Demand systems

Description:

Title: PowerPoint Presentation Last modified by: a0876003 Created Date: 1/1/1601 12:00:00 AM Document presentation format: On-screen Show Other titles – PowerPoint PPT presentation

Number of Views:225
Avg rating:3.0/5.0
Slides: 45
Provided by: hightechch
Learn more at: http://hightechchat.reocities.com
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Multicast with Cache (MCache) for Efficient Content Delivery in Video on Demand systems


1
Multicast with Cache (MCache) for Efficient
Content Delivery in Video on Demand systems
  • Sridhar Ramesh
  • based on joint work with Injong Rhee (NCSU) and
    Katherine Guo (Lucent Technologies, Bell Labs)

2
VoD system organization
Storage network
CPU switch
Regional server
Set top PVR
Internet
CPU Hard disk
WLAN access point
3
VoD requirements
  • High downstream data rate at client gt 5 Mbps per
    SD channel and gt 20 Mbps per HD
  • Good QoS low jitter, delay, loss
  • Plenty of storage for server 2 GB for 1 hour
    of SD quality video (MPEG-2 TS)
  • Server bandwidth 5 Mbps per SD stream, 20
    Mbps per HD stream

4
Broadband access options
  • ADSL Up to 8 Mbps downstream but usually 1
    Mbps or less
  • VDSL Up to 22 Mbps downstream loop length up
    to 5 kft
  • Data over Cable Shared bandwidth 80 MHz
    spectrum, typically 1-3 Mbps per user
  • DOCSIS 2.0 400 MHz spectrum for dataVoD, and
    better modulation schemes

Cable has incumbent as well as inherent advantage
but DSL will put up a fight
5
Efficient content delivery
  • Client bandwidth is non-negotiable
  • Server bandwidth can be reduced through
    multicasting, caching, etc
  • Efficient algorithms minimize average server
    bandwidth
  • May use client-side storage
  • May use request-batching

6
VoD algorithm classification
  • Open-loop (or server push) Client only receives
    does not request. Egs. Periodic Broadcast.
  • Closed-loop (or client pull) Transmit triggered
    by client requests. Egs. Patching, Stream
    merging.
  • Instantaneous No client wait time
  • Delayed Client delay up to t seconds

7
Periodic broadcast schemes
  • Skyscraper, Pagoda, GDB, Mayan Temple
  • Video clip split into segments of exponentially
    increasing length
  • Loop each segment continuously (back to back) on
    dedicated channel
  • Channel info available offline/out-of-band
  • Client has capability to download at least 2
    channels at any given instant
  • Continuous playout possible

8
Periodic broadcast principle
Seg 1,0
Seg1,1
Seg1,2
Seg1,3
Seg1,4
Seg1,5
Channel 1
Seg2,0
Seg2,2
Seg2,4
Channel 2
Seg3,0
Seg3,3
Channel 3
Seg4,0
Seg4,4
Channel 4
0
1
2
3
4
5
6
Seg1,0 Seg2,0 Seg3,3 Seg4,4
Seg1,1 Seg2,2 Seg3,3 Seg4,4
Seg1,2 Seg2,2 Seg3,3 Seg4,4
Seg1,3 Seg2,4
Seg3,6 Seg4,8
9
Periodic Broadcast principle
  • Clip Length 1234 10 units
  • Server bandwidth 4 channels, independent of
    request rate
  • Client bandwidth 2 channels
  • Client storage requirement 4 units
  • Maximum client delay 1 unit
  • Problem Does not scale down when client request
    rate is low

10
Periodic broadcast performance
  • N Total number of segments
  • M Number of channels received simultaneously by
    client
  • Ln Length of nth segment
  • SN Ln L and Sn Ln gt Ln1 , for continuous play
  • For M 2, Ln can be chosen exponentially
    increasing with ratio g lt 2.
  • Server bandwidth a N LoggL.

11
Multicast with Patching
12
Optimal patching
  • Motivation Instead of sending a very long
    unicast patch, start a new multicast stream so
    future clients can join new stream.
  • Threshold scheme If client is late by t lt y ,
    use patch. Else, start new stream.
  • y Patch threshold
  • L Clip length
  • Request rate (assumed Poisson)

13
Optimal patching
y
n is a random variable with Poisson distribution
and mean ly z is an exponentially distributed
random variable with mean 1/l
n patches
z
14
Optimal patching
  • Length of video stream L
  • Expected value of total length of patches y2l/2
  • Periodicity y z
  • server bandwidth B (L y2l/2)x1/(y z)
  • Optimal value of y sqrt(2L/l)
  • Corresponding value of B sqrt(2Ll)
  • Problem Bmin grows as sqrt(lL)

15
Hierarchical Stream merging
Gen 0
Gen 1
Gen 2
Gen 0 Gen 1
Gen 1 Gen 2
0
16
Optimal stream merging
  • Takes advantage of batching of first and second
    generation streams (patches)
  • Reactive to request rate changes
  • Server bandwidth sqrt (L)
  • Problems
  • Sqrt(L) is not good enough
  • Stream merging decisions are not simple for
    implementation

17
Existing scheme summary
Scheme Advantage Disadvantage Complexity
Periodic broadcast Low server bandwidth _at_ high request rates Same bandwidth for all request rates not adaptive Low
Patching Adaptive to varying request rates Server bandwidth increases with request rate, ad infinitum Low
Merging Adaptive to request rate Bandwidth required increases as sqrt (Length) High
18
Motivation for new algorithm
  • In practice, video clips can have highly variable
    access frequencies (request rates)
  • Need algorithm adaptive to request rate
  • Can be optimized for some rate, but must show
    graceful degradation for other rates
  • Easy to implement
  • Server bandwidth grows slowly with clip length
  • Best of both open and closed loop ?

19
Video popularity profile
  • Actual statistics are unknown. So we use web-page
    access profile as a model.

20
MCache overview Eg.1
Regional server
Regional server
21
MCache overview - Eg. 2
Regional server
Regional server
Notify
Notify
  • Note Control flow changes but same data flow

22
MCache overview
Req 0
Prefix
Clip
Req 1
Prefix
Req 2
Prefix
Patch (length u1 x b1)
Req 3
Prefix
Clip
0
y
-x
L
yx
u1
xu1
23
Key requirements for MCache
  • Storage half clip size near client. Egs
  • Regional server (scaled down version)
  • Client hard disk (made available to VoD service
    provider)
  • Client set-top box storage
  • Client bandwidth 2 x playout rate.
  • Multicast capability at clients, server and
    intermediate routers.
  • Good QoS, as in any VoD system

24
MCache algorithm flow
x Prefix length y Threshold L Clip length
Wait for request
Request received at time u
Schedule patch at ux. Notify client. Notify
client of clip in u-y,u.
Is a clip scheduled in u-y, ux)
NO
Schedule clip at ux. Notify client.
Notify client of patch in (u,ux). Extend
patch. Notify client of clip in u-y,u.
NO
Is a clip scheduled in u-y, u
Is a patch scheduled in (u,ux)
NO
Notify client of clip in (u,ux).
25
MCache algorithm flow
x Prefix length y Threshold L Clip length
Wait for request
Request received at time u
Schedule patch at ux. Notify client. Notify
client of clip in u-y,u.
Mcache(x,y,L,u)
Is a clip scheduled in u-y, ux)
NO
Schedule clip at ux. Notify client.
Notify client of patch in (u,ux). Extend
patch. Notify client of clip in u-y,u.
NO
Is a clip scheduled in u-y, u
Is a patch scheduled in (u,ux)
NO
Notify client of clip in (u,ux).
26
MCache performance
Time xyz, Data Lu1d1 3x u1u2d2
27
MCache performance
Bandwidth (Lu1d1 3x u1u2d2)/(xyz) z,
u1,u2 Exponentially distributed r.v.s. At high
request rate, these -gt 0. x-d1, x-d2 Exp.
distribution conditioned on being lt x. At high
request rate -gt x. Bound on bandwidth
(Ly2/2x)/(xy) Optimal y for high request rate
sqrt(2Lx) Optimal bandwidth sqrt(2L/x)
28
MCache performance
Long term average normalized bandwidth B
Sn (L SmPmnlty Pmn)/(xyzn) , where Pmn
Length of mth patch in nth round Skltm ukndmn
mx B a exp(-lT) , EW x - E(dmn) , T
slot time
29
Performance analysis
Bandwidth vs Request Rate
Clip length 100 min, Prefix length 1min, Mean
playout rate 3 Mbps
30
Performance analysis
Bandwidth vs Clip Length
Request rate 2 per min, Prefix length 1min
Mean playout rate 3 Mbps
31
MCache summary
  • Prefix caching for instantaneous playout
  • Delay of x in clip download allows batching
  • Client uses 2 channels for download one for
    patch and another for main clip
  • Delay in patch transmission allows batching
  • Optimal patch threshold sqrt(L/x)
  • Server bandwidth increases as sqrt(L/x)
  • Adapts to low and high request rates.
  • Easy implementation
  • Problem sqrt(L/x) still not good enough

32
Virtual Prefix SMCache
Case 1 1 Segment
Req 0
Req 1
Dry zone Only one channel used by client
Req 2
Req 3
x
yx
2yx
0
Lx
If y O(sqrt L), then L 2y O(L)
33
Virtual Prefix SMCache
Case 2 2 Segments
Req 0
Req 3
Req 4
0
x
xy
2xy
L1x
L1 L2 x
L1-y
Result Greater batching for second
segment Initial batch for Segment 1 x for
Segment 2 L1-y Therefore, L1-y virtual prefix
for Segment 2
34
SMCache performance
Server bandwidth for 1st segment sqrt(L1/x)
For 2nd segment sqrt(L2/(L1-y)) By choosing y
lt L1-x, we ensure that the second segment has
higher batching Extending to N segments, let xn
Ln-1 yn-1 axn-1 where a gt 1. Further, let Ln
aLn-1 Thus, bandwidth for N segments given by B
Sn sqrt (Ln/xn) N sqrt (L1/x) But L Sn Ln
Sn L1 an-1 L1 (aN-1)/(a-1) So, N Loga(L/
L1), or B Loga(L)
35
SMCache performance comparison
Bandwidth vs Clip Length
Request rate 2 per min, Prefix length 1min
Mean playout rate 3 Mbps
36
SMCache algorithm flow
Wait for request
Request received at time u1
Mcache(x1,y1,L1,u1)
For i 2 to n
Mcache(xi,yi,Li,ui)
Generate virtual request i at time ui ui-1
xi-1 yi-1
37
SMCache recap
  • Clip is divided into segments of exponentially
    increasing size
  • Dry zone of each segment to be used as virtual
    prefix for next segment
  • Virtual prefix of successive segments also
    exponentially increasing in size
  • Total server bandwidth O(Log L)
  • Implementation Iterative on MCache

38
Summary and conclusions
  • Objective Design of content delivery algorithms
    for minimizing server bandwidth
  • Given Extra storage/bandwidth at client
  • Techniques Batching, Patching, Multicast
  • Results Adaptive algorithm with server bandwidth
    O(Log L)
  • Overlooked Cost added by caching, cost of prefix
    transmission, cost of multicast

39
Backup slides
40
Optimal prefix size
  • In practice, many clips are stored together
  • Clips have different request rates
  • Need to minimize total server bandwidth
  • Constraint is total cache space for storing all
    prefixes
  • Greater request rate larger prefix
  • Greater clip length larger prefix

41
Digital Fountain approach
  • Store Meta-content created by applying Tornado
    codes to original media file
  • K bytes of media block yield N bytes of
    Meta-content block
  • Any Kd bytes of Meta-content block are enough to
    re-construct original K bytes
  • Tornado decoding has linearly increasing
    complexity with block size
  • Higher block size increases bandwidth efficiency
    but also client wait time
  • Built in error and loss tolerance

42
Optimal stream merging
0
a
2a
L
4a
3a
43
MCache algorithm flow
x Prefix length y Threshold L Clip length
Wait for request
Schedule patch at ux. Notify client. Notify
client of clip in u-y,u.
Request received at time u
Is a clip scheduled in u-y, ux)
NO
Schedule clip at ux. Notify client.
Notify client of patch in (u,ux). Extend
patch. Notify client of clip in u-y,u.
NO
Is a clip scheduled in u-y, u
Is a patch scheduled in (u,ux)
NO
Notify client of clip in (u,ux).
44
Performance comparison
About PowerShow.com