1 / 25

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

End-to-End Analysis of Distributed Video-on-Demand Systems. Padmavathi Mundur, Robert Simon, and Arun K. Sood IEEE Transactions on Multimedia, February 2004. Outline. Motivation Hierarchical VoD architecture Analytical model Evaluation methodology and results Conclusion. Motivation.

keenan
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. End-to-End Analysis of Distributed Video-on-Demand Systems Padmavathi Mundur, Robert Simon, and Arun K. Sood IEEE Transactions on Multimedia, February 2004

  2. Outline • Motivation • Hierarchical VoD architecture • Analytical model • Evaluation methodology and results • Conclusion

  3. 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

  4. Hierarchical VoD architecture

  5. Data flow at server Double buffer technique RSVP

  6. Disk scheduling and double buffer scheme in the server Token bucket + WFQ 1. RAID-5 storage 2. SCAN EDF scheduling (RSVP) 2 7 6 1 4 5 3

  7. packets packets wait r pkts/sec send pkts to network Traffic regulator at server (1/2) • Leaky bucket • Control average rate

  8. r tokens/sec buckets holds up to b tokens packets packets wait remove token to network Traffic regulator at server (2/2) • Token Bucket • Control average rate • Control input burst size

  9. Weighted fair queuing (WFQ) at server • Provide different priority to different packets

  10. Token bucket scheme controls the average output rate WFQ allocates different resource to different users Token bucket + WFQ  provide delay upper bound Combine token bucket & WFQ

  11. Resource reservation protocol (RSVP) along the routing path

  12. Review the whole data flow Double buffer technique Token bucket + WFQ RAID 5 storage SCAN EDF scheduling RSVP

  13. request Admission control scenario Remote cluster Remote cluster Network connections Disk admission control Local cluster Local distribution network Check available bandwidth

  14. Analysis – admission control • Server disk • , if accept the request • Network overall disk bandwidth client playback rate bandwidth available on jth link reserved rate client playback rate

  15. rJ r1 bJ b1 wJ w1 Analytical model – use delay bound to calculate reserved bandwidth …… : MTU : max packet size for the flow WFQ + Token bucket : retrieval block size

  16. 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

  17. Simulation setup – environment • 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 Remote cluster1 Remote cluster2 Network1 Network2 Local cluster requests

  18. 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

  19. 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

  20. Simulation results – compare performance of request handling policies in RVC • Purpose: test the performance of the VoD system using different request handling policies • Redirect policy performs better than the other two policies

  21. Split-50-60 performs better at heavy load Split-60-60 performs better at low load 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

  22. Simulation results – performance at each resources for split policies in RVC • Use individual resource performance to help explain the crossover and divergence behavior

  23. 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

  24. Simulation results – varying the number of videos on local server in DVC • 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

  25. Conclusion and distribution • Develop a method to analyze distributed VoD systems • Use an extensive simulation to the distributed VoD architecture and evaluate several request handling policies

More Related