Simulation case studies J.-F. Pâris University of Houston.
-
Upload
alexis-small -
Category
Documents
-
view
219 -
download
1
Transcript of 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