290 likes | 320 Views
Overcast: Reliable Multicasting with an Overlay Network. CS294 Paul Burstein burst@cs.berkeley.edu 9/15/2003. Outline. Goals & Motivation Network Overview Protocols Evaluation Discussion. Motivation. Offering bandwidth-intensive content on demand primarily video content
E N D
Overcast: Reliable Multicasting with an Overlay Network CS294 Paul Burstein burst@cs.berkeley.edu 9/15/2003
Outline • Goals & Motivation • Network Overview • Protocols • Evaluation • Discussion Paul Burstein: Ovarcast, 9/15/2003
Motivation • Offering bandwidth-intensive content on demand • primarily video content • Long-running content availability for multiple clients Paul Burstein: Ovarcast, 9/15/2003
Goals • Maximize Bandwidth • Limit repeated usage of physical links • No change to existing routers • Easy deployment
Outline • Goals & Motivation • Network Overview • Protocols • Evaluation • Discussion Paul Burstein: Ovarcast, 9/15/2003
Design • Overlay network • runs on top of existing infrastructure • Central source • Distribution Trees • Responsive to transient failures and congestion Paul Burstein: Ovarcast, 9/15/2003
Why Overlay? Paul Burstein: Ovarcast, 9/15/2003
Pros Incrementally Deployable Adaptable Robust Customizable Standard Why Overlay? Paul Burstein: Ovarcast, 9/15/2003
Pros Incrementally Deployable Adaptable Robust Customizable Standard Cons Management “The real world” firewalls, proxies… Inefficiency Information Loss Why Overlay? Paul Burstein: Ovarcast, 9/15/2003
Pros Incrementally Deployable Adaptable Robust Customizable Standard Cons Management “The real world” firewalls, proxies… Inefficiency Information Loss Why Overlay? Paul Burstein: Ovarcast, 9/15/2003
Single-Source Multicast • Simplicity • a clear point of interaction • Optimization • only for one path • Extendable to multi-source • single source forwarding • Address Space • vs. IP multicast Paul Burstein: Ovarcast, 9/15/2003
Deployment & Usage • Deployed on unmodified Web browsers via HTTP • Final Consumers – HTTP clients • HTTP URLs define Overcasts groups • Hostname – root • Path – network group Paul Burstein: Ovarcast, 9/15/2003
Example Video and live stream distribution • Studio • The source of content • Appliances • Organize into distribution tree • Clients • Studio requests get redirected to appliances Paul Burstein: Ovarcast, 9/15/2003
Outline • Goals & Motivation • Network Overview • Protocols • Evaluation • Discussion Paul Burstein: Ovarcast, 9/15/2003
Tree Building Protocol • Build a deep tree without sacrificing the bandwidth to the root • Choose nodes based on bandwidth to root • Secondary criteria: proximity (network hops) • Dynamic Adaptation vs. Static Configuration Paul Burstein: Ovarcast, 9/15/2003
Up/Down Protocol (1/2) • Handles joins and departures • Periodic status propagation from children to parent nodes • “Death Certificates” • children that missed report time • “Birth Certificates” • nodes joining the reporting node Paul Burstein: Ovarcast, 9/15/2003
Up/Down Protocol (2/2) • Up/Down Race condition • Death certificate of a moved node conflicting with its new Birth certificate • Associate a sequence number for the number of parent changes • Optimization • Propagation of certificates for known nodes is unnecessary Paul Burstein: Ovarcast, 9/15/2003
Root Replication (1/2) • Root • Single point of failure • Handles join requests • Solution 1 • Replicate the root • Good for joins which are read only • Bad for up/down protocol – changing state Paul Burstein: Ovarcast, 9/15/2003
Root Replication (2/2) • Solution 2 • Linearly configured backup nodes • Good: consistent through up/down updates • Bad: increased latency due to longer initial path • Skip extra nodes during distribution Paul Burstein: Ovarcast, 9/15/2003
Joining an Group • An HTTP request contacts the root and the root selects a server to serve the contents to the client. • The selection algorithm is not discussed Paul Burstein: Ovarcast, 9/15/2003
Multicasting • Data goes down the tree with logs recording the data received • A failed node rejoins the tree with up/down protocol and gets the data from the new parent’s log • Where’s the reliability? Paul Burstein: Ovarcast, 9/15/2003
Outline • Goals & Motivation • Network Overview • Protocols • Evaluation • Discussion Paul Burstein: Ovarcast, 9/15/2003
Evaluation • Based on simulations with GT-ITM • Five 600-node graphs • 3 transit domains (backbone) • 8 stub networks per domain • 25 nodes per stub • Bandwidth Averages • 45Mbps, 1.5Mbps, 100Mbps • T3, T1, Fast Ethernet • One node supports 20 clients • (MPEG-1 video) Paul Burstein: Ovarcast, 9/15/2003
Bandwidth Utilization • Backbone • Adds transit nodes first • Random • All nodes chosen randomly • Fraction = Overcast bandwidth/Optimal bandwidth • At full participation – distribution trees are different Paul Burstein: Ovarcast, 9/15/2003
Tree Convergence • Round period • time to get a stable position • Reevaluation period • finding new parent • Lease period • parent waiting for child’s status • Assumption: stable underlying network Paul Burstein: Ovarcast, 9/15/2003
Up/Down Protocol (1/2) • Simulating node additions • topology reconfiguration • every parent change results in certificate • Certificates Scale • Depends on the number of new nodes, not the network size Paul Burstein: Ovarcast, 9/15/2003
Up/Down Protocol (2/2) • Node Failure • handles large networks well • scales to number of failures • Abnormalities • caused by failures near the root and long propagations Paul Burstein: Ovarcast, 9/15/2003
Outline • Goals & Motivation • Network Overview • Protocols • Evaluation • Discussion Paul Burstein: Ovarcast, 9/15/2003
What’s the point • Adding and using more secondary storage is easier than increasing network bandwidth • Is this multicasting or data replication? Paul Burstein: Ovarcast, 9/15/2003