Simulation case studies J.-F. Pâris University of Houston

Introduction We will discuss several simulation studies Dynamic Heuristic Broadcasting protocol Stream tapping

A HYBRID DYNAMIC BROADCASTING PROTOCOL FOR VIDEO-ON-DEMAND S. R. Carter, J.-F. Pâris, S. Mohan University of Houston D. D. E. Long University of California, Santa Cruz

OUTLINE Video-on-demand Video distribution protocols Stream tapping Broadcasting protocols Dynamic broadcasting The dynamic heuristic broadcasting protocol How we simulated it

VIDEO-ON-DEMAND A great idea: Watching at home the video of your choice at the time of your choice Still too expensive to compete with video rentals or pay-per-view Primary cost factor is very high bandwidth requirements of service 5 Mbits/sec for a video in MPEG-2 format

What can be done? Many user requests to the same video will overlap Should try to share as many data as possible Requires a set-top box (STB) that can Receive data from several channels in parallel Store data that arrive out of sequence in a buffer (disk drive)

A hard drive in each STB? “Digital VCRs” can store hours of TV programming on a hard drive: TiVo Replay Ultimate TV Owners of these digital VCRs are likely to be among early adopters of VOD services

VIDEO DISTRIBUTION PROTOCOLS Attempt to minimize server and network bandwidth Require a “smart” STB with a large buffer Three approaches Reactive Protocols:Stream Tapping Proactive Protocols: Broadcasting Hybrid Protocols: Dynamic Broadcasting

Broadcasting Most of the demand is for the 20 most popular videos Simplest solution is to schedule staggered broadcasts of each popular video Solution does not require any changes to the customer set-top box (STB) To achieve a maximum delay d for a video of duration D, we need D/d streams

Broadcasting Protocols Require much less bandwidth than plain staggered broadcasting to achieve the same waiting time Can provide much smaller waiting times Have much smaller bandwidth requirements Transmit different segments of the video at different rates on different streams

Fast Broadcasting Uses fixed-size segments Stream 1 continuously repeats segment S 1 Stream 2 continuously repeats segments S 2 and S 3 Stream j continuously repeats segments S 2 j-1 to S 2 j -1 Any segment S i is repeated at least once every i slots

S5S5 The first three streams Stream 3: S4S4 S7S7 S6S6 S5S5 S7S7 S4S4 S6S6 S4S4 S5S5 S1S1 Stream 1: S1S1 S1S1 S1S1 S1S1 S1S1 S1S1 S1S1 S1S1 S1S1 bandwidth b Stream 2: S2S2 S3S3 S2S2 S3S3 S2S2 S3S3 S3S3 S3S3 S2S2 S2S2 bandwidth b

New Pagoda Broadcasting Uses fixed-size segments Has bandwidth requirements comparable to those of most sophisticated protocols Key idea is to schedule segments As frequently as needed but Not more than that Uses a more complex segment-to-stream mapping

The first three streams S1S1 Stream 1: Stream 3: Stream 2: S4S4 S5S5 S4S4 S1S1 S1S1 S1S1 S1S1 S1S1 S1S1 S1S1 S1S1 S4S4 S5S5 S1S1 S2S2 S2S2 S2S2 S2S2 S2S2 S3S3 S3S3 S3S3 S3S3 S6S6 S6S6 S7S7 S8S8 S8S8 S9S9 bandwidth b

Dynamic Broadcasting Stream tapping works best when request arrival rates remains 10 accesses/hour Broadcasting protocols make more sense when request arrival rates exceed 20 to 40 accesses/hour Video popularity is bound to vary with the time of day We need distribution protocols that work well at all request arrival rates

The UD Protocol The universal distribution protocol (UD) Based on the fast broadcasting protocol Transmits segments on demand Has same bandwidth requirements as stream tapping at low arrival rates Has same bandwidth requirements as fast broadcasting at high arrival rates

The First Three Streams Server only schedules the segments that cannot be shared with a previous request

The Problem UD protocol performs As well as stream tapping at low request arrival rates Worse than NPB at high arrival rates We want a dynamic protocol performing as well as NPB at high arrival rate

DYNAMIC HEURISTIC BROADCASTING We tried first a dynamic version of NPB Protocol performed poorly at low request arrival rates Dynamic heuristic broadcasting: Allocates segment transmissions on the fly Uses a heuristic to avoid sudden bandwidth peaks

The Protocol Assume a request arrives during slot t Basic idea is for segment s := 1 to n_segments do if no segment s in slots t+1 to t+s then transmit s in slot t+s end if end loop

Example Assume three requests for a video with seven segments Each segment can be assigned to any channel

Avoiding bandwidth peaks When the video is in high demand segment s will be repeated exactly once every s slots Slot k! will contains transmissions of segments 1 to k To eliminate these peaks, we will schedule some segments slightly ahead of time Slightly less efficient

Example slot selected by DHB last possible slot for segment S k

The DHB Protocol if one or more requests have arrived then for s := 1 to n_segments do if s not already in any slot from t+1 to t+s then n min := min {n(k) | t+1  k  t+s} k max := max{k | k  t+s and n(k)=n min } transmit s in slot k max end if end loop end if

The trick Prob [one or more arrivals] is equal to 1 - Prob[no arrival] = 1-exp(-λd) where λ is the request arrival rate D is the slot duration

STREAM TAPPING

Stream Tapping Clients will “tap” into any other stream showing the same video Video server will send to each client only what could not be obtained from the tap Requires a set-top box than can: Receive data from more than one video stream at a time Store at least 10 minutes of video

How it works New “Tap” from 1 st request 1 st request for the video: 2 nd request :

Full tap Tap Optimization Extra tapping allows STB to tap tap streams in addition to original streams Requires a STB capable of receiving data from more than two streams Extra tap Extra

Limitations Stream works best when request arrival rate does not exceed ten requests per hour Not indicated for distributing popular videos over a large metropolitan area Extra tapping requires a STB capable of receiving data from at lest three channels Increases the STB cost

OUR SOLUTION Stream tapping with partial preloading Stream tapping works very well at low to moderate request arrival rates We preload in the customer STB the first few minutes of the “hottest” videos Very good performance at high to very high request arrival rate We limit client bandwidth to two channels

How it works (I) Protocol preloads in customer STB first D PP minutes of top 10 to 20 videos When first request arrives, server schedules a complete stream in D PP minutes D pp Request arrives Complete stream D pp

Requests arriving within D PP minutes of first request share the same complete stream No impact on server workload How it works (II) Complete stream D PP D pp

Requests arriving more than D PP minutes after first request “tap” the complete stream D pp How it works (III) Complete stream D PP Missed Tap

Requests arriving less than D PP minutes of after a full tap will use extra tapping D pp How it works (IV) Complete stream From tap Tap Extra Tap No

First request arriving more than D PP minutes after last full tap will start a new full tap D pp How it works (V) Missed Complete stream Tap New Tap

As tapping become less and less efficient, server decides to start a new complete stream Protocol imposes a maximum duration  to all full taps (35 minutes in our experiments) How it works (VI) Complete stream D pp New complete stream

Partial preloading Have one dedicated channel broadcasting initial segments of all top videos Could also use server dead times or some form of STB snooping In both cases, STB should be permanently turned on

Simulator organization (I) for i = 1; i <= maxarrivals; i++) { clock += exponential(rate); if (clock >= lastfullstart + duration) { tap = "no"; } else { tapduration = clock -lastfullstart; newtotalbatchbw = totalbatchbw + tapduration; newavgbatchbw = newtotalbatchbw / (batchsize + 1);

Simulator organization (II) if (newavgbatchbw > coefficient*minavgbatchbw) { tap = "no"; } else { tap = "yes"; } // inner if... else } // outer if... else

Simulator organization (III) if (tap eq "no") { lastfullstart = clock; minavgbatchbw = avgbatchbw = totalbatchbw = duration; batchsize = 1; totalbw += duration; } else {

Simulator organization (IV) batchsize++; totalbatchbw = newtotalbatchbw; avgbatchbw = totalbatchbw / batchsize; if (avgbatchbw < minavgbatchbw) { minavgbatchbw = avgbatchbw; } // inner if totalbw += tapduration; } // 2nd outer if... else } // for each

Comments Implementing extra tapping was hard Did only a partial implementation Could tap full taps but not taps of full taps