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