simulation case studies j.-f. pâris university of houston

Simulation case studies

J.-F. PârisUniversity of

Houston

Introduction

We will discuss several simulation studies Dynamic Heuristic Broadcasting

protocol Stream tapping

A HYBRID DYNAMIC BROADCASTING PROTOCOLFOR VIDEO-ON-DEMAND

S. R. Carter, J.-F. Pâris, S. MohanUniversity of Houston

D. D. E. LongUniversity 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 S1

Stream 2 continuously repeats segments S2 and S3

Stream j continuously repeats segmentsS2

j-1 to S2

j-1

Any segment Si is repeated at least once every i slots

S5

The first three streams

Stream 3:

S4 S7 S6 S5S7S4S6 S4S5

S1

Stream 1:

S1 S1 S1 S1 S1S1 S1S1 S1

bandwidth b

Stream 2:

S2 S3 S2 S3 S2 S3S3 S3S2 S2

bandwidth b

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

S1

Stream 1:

Stream 3:

Stream 2:

S4 S5 S4

S1 S1 S1 S1 S1S1 S1S1

S4 S5

S1

S2 S2 S2 S2 S2

S3 S3 S3 S3S6 S6S7S8 S8S9

bandwidth b

bandwidth b

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 asstream tapping at low arrival rates

Has same bandwidth requirements asfast 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 doif no segment s in slots t+1 to

t+s then transmit s in slot t+send 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 Sk

The DHB Protocolif 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

nmin := min {n(k) | t+1 k t+s}

kmax := max{k | k t+s and

n(k)=nmin}

transmit s in slot kmax

end if end loopend 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 1st request

1st request for the video:

2nd 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 tapExtra Extra

Limitations

Stream works best when request arrival rate does not exceed ten requests per hourNot 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 DPP

minutes of top 10 to 20 videos

When first request arrives, server schedules a complete stream in DPP minutes

Dpp

Request arrives

Complete streamDpp

Requests arriving within DPP minutes of first request share the same complete stream

No impact on server workload

How it works (II)

Complete streamDPP

Dpp

Dpp

Requests arriving more than DPP minutes after first request “tap” the complete stream

Dpp

How it works (III)

Complete streamDPP

Missed

Tap

Requests arriving less than DPP minutes of after a full tap will use extra tapping

Dpp

How it works (IV)

Complete stream

From tap

Tap ExtraTap

No

First request arriving more than DPP

minutes after last full tap will start a new full tap

Dpp

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

Dpp 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