200 likes | 338 Views
Multicast for Video Streaming. EE290T Spring 2002 Puneet Mehra pmehra@eecs.berkeley.edu. IP Multicast Overview. Semantics 1 -> Many or Many -> Many Approach Build tree connecting source and receivers on Current Infrastructure in Net [1] Group Addressing – provides flexibility
E N D
Multicast for Video Streaming EE290T Spring 2002 Puneet Mehra pmehra@eecs.berkeley.edu
IP Multicast Overview • Semantics • 1 -> Many or Many -> Many • Approach • Build tree connecting source and receivers on • Current Infrastructure in Net [1] • Group Addressing – provides flexibility • Receivers/senders unaware of each other • Packets delivered throughout tree. • Dynamic changes to tree • New Receiver -> graft path onto tree • Receiver leaving -> pruning path from tree • Uses UDP – so no reliability • Challenges • Efficient routing of data to receivers
Video Multicast Over Net[1] • Issues in Multicast over Best Effort • Fixed Frame Rate – regardless of delay/jitter • Losses – degradation, possibly ungraceful • Heterogeneity of receivers • Approaches to Multicast • QoS resource reservation for Multicast • Adaptive Rate Control • Techniques for Rate Adaptation • Single Stream Video Multicast • Replicated Stream Video Multicast • Layered Video Multicast
Single Stream Video Multicast • Only send 1 stream to all receivers. • Pros: • Easy To Implement • Cons: • Ignores Receiver Heterogeneity • Feedback Implosion • INRIA Video Conferencing System • Feedback Problem handled through probabilistic receiver response • Tradeoff granularity of control vs B/W efficiency
Replicated-Stream Video Multicast • Destination Set Group (DSG) • Small # of video streams of varying quality sent to different multicast groups • Intra-stream Rate control to adjust stream rate by receivers • Inter-stream protocol used by receivers to switch streams • Pros: • deals with heterogeneity – more fair • Scalable since receiver-driven • Cons: Network carries redundant info
Layered Video Multicast • Receiver-Driven Layered Multicast (RLM) • Send different “layers” to multicast groups, and receiver subscribes as needed -> scalable solution • Congestion -> layer dropping • Spare B/W -> layer adding • Receivers conduct group join experiments and share info with others.
Layered Video Multicast Cont. • Layered Video Multicast with Retrans. (LVMR) • Improve reception w/in a layer by retransmission • Deal w/ congestion using Hierarchical Rate Control • Hierarchical Rate Control (HRC) • Congestion info distributed at both sender/receivers • Intelligent partitioning of info -> concurrent experiments w/ less overhead • Use hierarchy to only inform those who need to know about an experiment – affected regions • Collaborative layer drop – better approach to congestion
Error Control in Video Multicast • Pure FEC • ARQ – From LVMR • Local Recovery - designated receivers at each level in tree help w/ rtx. of pkts -> lower latency • Don’t rtx packets past deadline • Receivers can trade reliability/latency by picking parent with desired attributes
Multicast Routing [2,3] • Routing – construct efficient tree from source to receivers • Theoretical Results [3] • Steiner Tree – minimize total cost of a multicast tree. NP-Complete. So use heuristics to provide a “good” approx. to Steiner Tree. • Constrained Steiner Tree – impose b/w delay constraints on links to receivers. Also NP-Complete. So must use heuristics • All practical algorithms based on shortest path tree – minimize sum of weights on links along each path from source to receiver
Intra-Domain Routing • Source-based Routing • Tree rooted at source • Dense-mode routing – works best when topology densely populated with receivers • Core-based Approach • Select a Rendezvous Point (RP) to root the tree • Sparse Mode Routing – More efficient than dense mode when few, wide-spread receivers
Dense Mode Protocols • Distance Vector Multicast Routing Protocol • Uses broadcast & prune technique to build reverse shortest path trees (RSP) • Steps: • Src bcasts pkt on Lan. Local router fwds pkt on all ifaces • If pkt received on RPF iface, then it is forwarded. • Leaf routers send prune toward src if no attached receivers • Prune message forwarded to source, and send own prune if receive prune message on all ifaces. • A lot of state info kept in ALL routers in net. • Multicast extensions to OSPF • Uses IGMP locally, then floods info along with link state to net. • PIM-DM • Less complex than DVMRP since no RPF check is done. More inefficient as a result
Tree Construction in DVMRP[3] • S = Source. Black Circles = Receivers • Periodically flood net w/ datagrams • Leaf routers send prune toward source if there are no group members on leaf subnet • Final Tree is shown in (d).
Core-Based Routing • General Approach • A core, or rendezvous point (RP) is configured for a multicast group • Info about the RP & mapping from group to RP is discovered by routers using bootstrap protocol (also finds alternate RP in case of failure) • Receivers explicitly join tree -> contact RP • Src sends data to RP which sends down tree • More efficient since state only kept in routers on path from src/receivers to RP. • Examples • CBT – Core-Based Trees • PIM-SM – Protocol Independent Multicast/Sparse Mode
Tree construction in CBT • The Join Process for a new node • Receiver Contacts Local Router • Router sends JOIN_REQUEST to the core router • When msg reaches on-tree router, a JOIN_ACK is sent back • every router receiving JOIN_ACK updates state information • Periodically send echo-request to parent router. If echo not received in time, then router sends quit-notification upstream and deletes state information.
Inter-Domain Routing • Probs w/ multicast described • Large flat topology -> complexity and instability since no BGP-like protocol • No mechanism to build hierarchical mcast routing • Solution – Immediate Future • Introduce Hierarchy – multi-protocol extensions to BGP (MBGP) • Each router only knows topology of its own domain & how to reach other domains • Used to determine next hop for a host
Inter-Domain Routing Cont. • What if you have a src in one domain & receivers in others? • Multicast Source Discovery Protocol • When src registers w/ RP -> a source active (SA) msg is sent to MSDP peers • Prevent loops w/ per-RPF flooding (ie: if msg received on correct iface -> flood) • If MSDP is aware of local group members (use IGMP), then it will send a join to the src
Long-Term Inter-Domain Proposals • Border Gateway Multicast Protocol • Bidirectional shared trees between domains with single root. Need strict allocation of addresses among domains. • Address Allocation Protocols • Multi Address Set Claim – Helps allocate addresses dynamically across domains • GLOP – a “glop” of addresses statically allocated among domains
Problems Deploying IP Multicast [4] • Complexity • Can’t put it in core routers • Hardware more difficult to manage (probs w/ firewalls) • Makes old routers useless • disrupts ISP router migration model (routers generally migrate from core to edge) • Domain Independence • ISPs don’t want to rely on remote RPs • Don’t want to be RP for non-customers • Security – anyone can send/listen • Address Allocation – anyone can pick a class D addr.
References • [1] “Video Multicast over the Internet.” Xue Li et al. IEEE Network. 1999. • [2] “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment.” Kevin Almeroth. IEEE Network. 2000. • [3] “Multicast Routing and Its QoS Extension: Problems, Algorithms, and Protocols.” Bin Wang and Jennifer C. Hou. IEEE Network. 2000. • [4] “Deployment Issues for the IP Multicast Service and Architecture.” Christophe Diot et Al. IEEE Network. 2000.