end-to-end analysis of distributed video-on-demand systems padmavathi mundur, robert simon, and arun...
Post on 19-Dec-2015
220 Views
Preview:
TRANSCRIPT
End-to-End Analysis of Distributed Video-on-Demand Systems
Padmavathi Mundur, Robert Simon, and Arun K. SoodIEEE Transactions on Multimedia, February 2004
Outline
Motivation Hierarchical VoD architecture Analytical model Evaluation methodology and results Conclusion
Motivation
In a real environment, if a video requires R mbps transmission rate, allocate R mbps bandwidth is not accurate enough
From network view, analyze the bandwidth required for videos
Disk scheduling and double buffer scheme in the server
3541672
1. RAID-5storage
2. SCAN EDF
scheduling
(RSVP)
Token bucket + WFQ
Traffic regulator at server (1/2) Leaky bucket
Control average rate
sendpkts
packets wait
packetsto
network
r pkts/sec
Traffic regulator at server (2/2) Token Bucket
Control average rate Control input burst size
removetoken
packets wait
packetsto
network
r tokens/sec
buckets holds up to b tokens
Combine token bucket & WFQ
Token bucket scheme controls the average output rate
WFQ allocates different resource to different users
Token bucket + WFQ provide delay upper bound
Receiver B
Receiver A
Sender
Session (Ipa,PID,Port)
path (2)
Merge point
Session (Ipa,PID,Port)
Session (Ipa,PID,Port)
IGMP (1)
IGMP(1)
Resv(3)
Resv (3)
Path message
Resv message
IGMP message
DataPacket (4)
Resource reservation protocol (RSVP) along the routing path
Review the whole data flow
RAID 5 storage
SCAN EDF scheduling
Double buffer technique Token bucket +
WFQRSVP
Admission control scenario
Remote cluster
Remote cluster
Localcluster
Localdistribution
network
Networkconnections
requestDisk admission control
Check available bandwidth
Analysis – admission control
Server disk
, if accept the request
Network
p
d
R
Rn nnc 1
jrp ARR
overall disk bandwidth
client playback rate
bandwidth available on jth link
reserved rateclient playback rate
Analytical model – use delay bound to calculate reserved bandwidth
WFQ + Token bucket
rJ
bJ
wJ
r1
b1
w1
……
J
j j
rr
A
MD
MJBR
1
maxmax
)1(
J
j jrr
r
A
M
R
MJ
R
BD
1
maxmax
)1(
maxMM : max packet size for the flow
: MTU
rB : retrieval block size
Performance evaluation – request handling policy Redirect:
A blocked request at one resource is simply redirected to other resources
Split-based Sharing the loads to other resources
Simulation setup – environment
Remote cluster1
Remote cluster2
Localcluster
Network1 Network2
requests
•Servers in local cluster: 5
•Storage capacity per local server: 500 GB
•Disk transfer rate at local server: 1.2 Gbps
•Hops to remote cluster1: 3
•Hops to remote cluster2: 6
•Max. Transmission Unit: 1500 Bytes
•Maximum packet size: 1500 Bytes
•Network bandwidth: 2488 Mbps
•End-to-end delay 300 ms
•Size of video collection 150
•Size of videos in GBytes: 2.46 to 4.8
•Service time in hours: 0.68 to 2.03
•Video popularity: according to Zipf distribution
•Request arrival interval: adopt Poisson distribution
Simulation setup – request handling policies Redirect
Redirect order: LC RC1 RC2 Split
Split50-60: 50% are served in LC, 60% of the remains are served in RC1, the rests are in RC2
Split-redirect Split first, also contains redirect policy
Simulation setup – scenarios
Replicated video collection (RVC) All videos are available on local or remote servers
Distributed video collection (DVC) Only a partial set of videos is available on the
local cluster, the requests for non-available parts are served by remote clusters
Simulation results – compare performance of request handling policies in RVC Purpose: test the performance of the VoD system us
ing different request handling policies Redirect policy performs better than the other two p
olicies
Simulation results – difficulties with split-based policies in RVC The lines are
crossed over in the previous figures (Ex: split-50-60 and split-60-60)
It is difficult to pick an efficient split for a given workload
Split-60-60 performs better at low load
Split-50-60 performs better at heavy load
Simulation results – performance at each resources for split policies in RVC Use individual resource
performance to help explain the crossover and divergence behavior
Simulation results – efficient split policy in RVC
Split requests proportional to their resource
It may difficult to know remote clusters since they may be dynamically shared with other user populations
Simulation results – varying the number of videos on local server in DVC
local storage size
local video number
100 30
200 76
300 135
400 147
500 150
Distribute the available storage capacity at the local cluster to videos in proportion to their popularity
Redirect policy only Class1: top 20% popular, class2: 20~60% popular, class3: last 40%
popular
top related