360 likes | 435 Views
Proxy-based Asynchronous Multicast for Efficient On-demand Media Distribution. Multimedia Operating and Networking System (MONET) Group Yi Cui and Klara Nahrstedt {yicui, klara}@cs.uiuc.edu. Motivation. Media Distribution Video on Demand, Distance Learning, etc. Challenges Scalability
E N D
Proxy-based Asynchronous Multicast for Efficient On-demand Media Distribution Multimedia Operating and Networking System (MONET) Group Yi Cui and Klara Nahrstedt {yicui, klara}@cs.uiuc.edu
Motivation • Media Distribution • Video on Demand, Distance Learning, etc. • Challenges • Scalability • Efficiency • On-demand
Multicast t0 • Pros: Scalable and Efficient • Cons: synchronous transmission manner t0 t0 t0 t0
Multicast-based Solutions • Previous Works • Batching, Patching, Hierarchical Merging, Periodic Broadcast, etc. • Limitations • Clients have to participate multiple multicast sessions simultaneously • Not so scalable in case of non-sequential access • Deployment of IP multicast severely limited
Application-layer Multicast t0 Existing Works (Narada, Overcast, Yoid, ALMI, RON, etc.) Naïve Solution Simply elevate IP-multicast based solutions to application layer t0 t0 t0 t0
t2 t1 t4 t3 t2 t4 t3 Asynchronous Multicast t0 Same stream reusable by asynchronous clients Clients not required to receive multiple streams at the same time Non-sequential access supported IP multicast not required t1
Outline • Motivation • Problem Formulation • Temporal Dependency Model • Our Solution • Media Distribution Algorithm • Content Discovery Service • Performance Study • Summary
R1 R2 R3 Temporal Dependency Model • Eachclient R1keeps the received stream in its buffer B(R1) (or simply B1) for a certain amount of time • If R2 requests the same stream after R1 did, and the time difference is less than Size(B1), R2 could retrieve data from R1 • R1 is the predecessor of R2 • R2 is the successor of R1 B1 Time
Media Distribution Graph Directed edge from B1 to B2 indicates that B1 is the predecessor of B2 Edge weight is the communication cost between end hosts carrying B1 and B2 Bserver 5 4 4 3 B1 B3 6 1 2 3 B2 B4 5 B5
Media Distribution Graph How does one know which of its peers has the stream it demands? Which one to choose if there are multiple candidates? Bserver 5 4 4 3 • Construction and maintenance of Media Distribution Graph • Finding the Media Distribution Tree on the graph B1 B3 6 1 2 3 B2 B4 5 B5
Model Deployment Client-based Framework Complex Group Management Resource Heterogeneity Highly Unpredictable (machine crash, constant joining and leaving)
Model Deployment Proxy-based Framework Steady Group Abundant Resource Dedicated Machine
A Layered Picture B4 B2 B3 S Media Distribution Graph B1 Proxy Network Physical Network
Outline • Motivation • Problem Formulation • Temporal Dependency Model • Our Solution • Media Distribution Algorithm • Content Discovery Service • Performance Study • Summary
Media Distribution Algorithm • Function • Maintaining the Media Distribution Tree (MDT) on the dynamically changing Media Distribution Graph • Properties • Distributed: executed by local nodes, no centralized manager required • Incremental: only a portion of the tree is affected in case of node join/leave • Optimal: media distribution tree guaranteed to be the minimal spanning tree
Operations • MDT-Insert • On insertion of a new node Bnew, Bnewchooses its closest predecessor (the one of the minimum communication cost) as its parent • MDT-Delete • When an old node Bdeleteleaves, it notifies its current children to find themselves new parents as done in the MDT-Insert operation
Analysis • Correctness • MDT-Insert and MDT-Delete are guaranteed to return loop-free trees. • Optimality • The trees returned by MDT-Insert and MDT-Delete are minimal spanning trees. Y. Cui, K. Nahrstedt, Proxy-based Asynchronous Multicast for Efficient On-demand Media Distribution http://cairo.cs.uiuc.edu/publications/paper-files/TR2002-yicui.pdf
Content Discovery Service • Purpose • The proxy which runs MDT-Insert or MDT-Delete needs up-to-date knowledge of its predecessors and successors • Limitation of static-content-based solutions • The content of a proxy buffer is time varying, which could constantly invalidate the content availability information, thus resulting high volume of update messages
R2 R3 R1 buffer size Time P0 P1 P2 P3 P4 P5 P6 Indexing Servers R2 query R3 query R1 registration Content Discovery Service B1
Outline • Motivation • Problem Formulation • Temporal Dependency Model • Our Solution • Media Distribution Algorithm • Content Discovery Service • Performance Study • Summary
Performance Study • Simulation Setup • NS-2 simulator • GT-ITM network generator (transit-stub model) • Evaluation Metrics • Communication Cost (# of RTP packets traveled across the network) • Storage Cost (associated with time) • Access Latency (delayed observed by a client from initial request until the stream playback)
Communication Cost Server Communication Cost Link Communication Cost • Comparing with Batching and Proxy Prefixing • Buffer Size: 5 min. • 12 proxies, 192 clients
Impact of Buffer Size Server Communication Cost Link Communication Cost • Comparing with Batching and Proxy Prefixing • 12 proxies, 192 clients
Storage Cost 12 proxies, 192 clients 30 proxies, 480 clients Comparing with Proxy Prefixing
Access Latency Buffer Size 5 min Buffer Size 20 min Buffer size has no significant impact on access latency
Buffer Hit Ratio Access latency only improves when cache hit ratio increases
Access Latency in Details Streaming delay dominates the overall end-to-end latency
Summary • Proxy-based asynchronous multicast • Buffering Capabilities on End hosts (Proxies) • Temporal Locality of Stream Access • Efficient Media Distribution • Time-based Content Discovery • Future Work • Real network experimentation • User Access Pattern Study
Thank You http://www-monet.cs.uiuc.edu
Related Work • Asynchronous Multicast in Web Caching • Pablo Rodriguez et al. • Similar ideas in Streaming • Chaining, K. Hua et al. • Cache-and-Relay, S. Jin et al. • Proxy Caching • Middleman, S. Acharya et al. • Silo, Tokens and Rainbow, Y. Chae et al.