+ All Categories
Home > Documents > End-to-End Analysis of Distributed Video-on-Demand Systems P. Mundur, R. Simon, and A. K. Sood IEEE...

End-to-End Analysis of Distributed Video-on-Demand Systems P. Mundur, R. Simon, and A. K. Sood IEEE...

Date post: 20-Dec-2015
Category:
View: 214 times
Download: 0 times
Share this document with a friend
Popular Tags:
21
End-to-End Analysis of Distributed Video-on- Demand Systems P. Mundur, R. Simon, and A. K. Sood IEEE Transactions on Multimedia, Vol. 6, No. 1, Feb 2004 Presented by Ho Tsz Kin 10/03/2004
Transcript

End-to-End Analysis of Distributed Video-on-Demand Systems

P. Mundur, R. Simon, and A. K. SoodIEEE Transactions on Multimedia, Vol. 6, No. 1, Feb 2004

Presented by Ho Tsz Kin10/03/2004

Agenda

Introduction

System Model

Admission Control

Request Handling

Performance Evaluation

Conclusion

Introduction

Distributed VoD architecture with replication

Model and analyze subsystems – server, network, client

Design End-to-end admission control techniques

Request handling Strategies

ObjectiveMinimize the number of blocked requests

Hierarchical VoD ArchitectureMirrored sites

Provide video delivery to many user population

Cluster of video servers

Limited bandwidth

Replicated videoNo contention

Decoding, buffering and display

Contention exists

Streaming Model

Primary service provider

Delivery over local network only

Secondary service providerDelivery over high speed networkRedirecting to other remote sites

Admission control test

Server and Network Model

High capacity and bandwidth disk array Double buffer scheme

Order serving by the disk is not important

(b, r, p, M) Traffic regulatorb: token bucket sizer: token accumulation ratep: peak rate of NICM: max. packet size for the flow

Server and Network Model

(b, r, p, M) Traffic regulatorIn any interval x 0, bytes at its output is min(M+px, b+rx)Control the burstiness of the flow into the network

WFQ schedulingImplemented in the networkProvide a firm per-packet end-to-end delay bound on a per-link and per-routing path

RSVP

Reserve resources along the path of the requests

Admission ControlDerive admission control conditions at the server and networkUsing (b, r, p, M) traffic regulator, and WFQ

b = Br, r = Rr, p defaults infinityMax. bounded end-to-end delay

Retrieval block size

Network reserved rate

Routing path with J links

Max packet size

Overall bandwidth on jth link

Max packet size permitted in network(MTU)

Admission Control

New request will be admitted only if

Reserved rate for new request

1i new

T

r r ji

R R A

Admission control tests run on link by link basis over the routing path

Request Handling

redirectblocked request at one resource is simply redirected to other resourceshigher implementation overheadadditional setup time

split-basedfixed load-sharing among resourcessimpler implementationdifficult to determine efficient splits

Performance EvaluationSimulation Data and Model

Metrics: Blocking rate, Blocking probability

n e tw o rk2n e tw o rk1

L o c a ln e tw o rk

...L o c a l c lu s te r

...

R e m o te c lu s te r1

...

R e m o te c lu s te r2

Performance EvaluationAdmission control test

Request handling policiesRedirect

Local Remote1 Remote2

Request

Blocked

Performance EvaluationSplit-x-y

• First split between local and remote clusters in ratio of x and (100 - x)• Further split between remote cluster1 and cluster2 in ratio of y and (100 - y)

Split-redirect -x-y• Blocked requests in local

are redirected to remotecluster1

• Blocked requests inremote cluster1 are NOTredirected to remotecluster2

Performance EvaluationSingle rate playback service (8Mbps)750 streams by local server, 311 streams per remote clusterReplicated locally (2.5TB storing 800GB)

Performance Evaluation

CrossoverBy proportion of traffic directed toward the local cluster

DivergenceBy proportion of trafficdirected toward the remote traffic

Performance EvaluationBlocking performance at individual resources

Performance EvaluationEfficient split

Choosing split value that are close to the proportion of resource capacitiesPossible only if the portion of remote cluster capacity is knownIn general, difficult todetermine

One-level redirectionalready achieves better

Performance Evaluation

Scalability issue

Overall blockingstabilizes gradually

remain constant

Performance EvaluationReplication issue1st scenario: single server in the local cluster, top 30 videos stored locally2nd scenario: five servers in the local cluster, top 30 videos stored locally, 5 times replication allowed3rd scenario: five servers in the local cluster, complete video collection stored locally

Performance Evaluation

FairnessOnly partial list of top videos are stored on the local cluster with five video server

Class1: top 20% videos

Class2 & 3: other 80%

Redirect at 1000 requestsper hour

Conclusion & DiscussionAnalyzed VoD system with a hierarchy of servers and network elementsDerived the admission control conditionUsing extensive simulation, designed and evaluated several request handling policiesRedirect will be more suitableDiscussion

QoS guaranteed networksOther network traffic exists, and more remote sitesDifficult to determine the split percentageReliability issue


Recommended