Unformatted text preview:

CS 269: Lecture 11 MulticastThis WeekHistoryIronyLecturesAgendaMotivationMulticast Service ModelOpen Membership ModelOther Design Choices?Division of ResponsibilitiesTarget EnvironmentMulticast Routing AlgorithmsRouting Performance GoalsTwo Basic Routing ApproachesDVMRPBasic Forwarding RuleExampleBroadcasting ExtensionMulticast = Pruned BroadcastProblems with ApproachCore Based Trees (CBT)Slide 23DisadvantagesWhy Isn’t Multicast Pervasive?Possible Explanation [Holbrook & Cheriton ’99]Solution: Single-Source MulticastDiscussionUsing MulticastA Few ExamplesDistributing VideoLayered VideoExample of Rate/Quality TradeoffReceiver-driven Layered MulticastBasic AlgorithmJoin TimerScaling ProblemScaling Solution: Shared LearningRLM PaperPriority-drop and Uniform-dropLater Work ContradictsAssumptionsThe Cache Consistency ProblemTraditional Cache InvalidationMulticast Cache InvalidationReliable MulticastHow to Make Multicast Reliable?SRM Design ApproachRepair Request Timer RandomizationSuppressionLocal RecoveryApplication Layer Framing (ALF)Multicast’s True LegacyBenefits of Multicast1CS 269: Lecture 11MulticastScott Shenker and Ion StoicaComputer Science DivisionDepartment of Electrical Engineering and Computer SciencesUniversity of California, BerkeleyBerkeley, CA 94720-17762This WeekA Tale of Two FailuresMulticast and QoS: the lost decade3HistoryMulticast and QoS dominated research literature in the 90’sBoth failed in their attempt to become pervasively available-Both now available in enterprises, but not in public InternetBoth now scorned as research topics4IronyThe biggest critics of QoS were the multicast partisans-And the QoS advocates envied the hipness of mcast…They complained about QoS being unscalable-Among other complaints….Irony #1: multicast is no more scalable than QoSIrony #2: scaling did not cause either of their downfallsMany now think economics was the problem-Revenue model did not fit delivery model5LecturesToday: multicast-Focus on multicast as a state of mind, not on detailsWednesday: QoS-More “why” than “what”6AgendaPreliminariesMulticast routingUsing multicastReliable multicastMulticast’s philosophical legacy7MotivationOften want to send data to many machines at once-Video distribution (TV broadcast)-Teleconferences, etc.-News updatesUsing unicast to reach each individual is hard and wasteful-Sender state: ~O(n) and highly dynamic-Total load: ~O(nd) where d is net diameter-Hotspot load: load ~O(n) on host and first linkMulticast:-Sender state: O(1), total load O(d log n), hotspot load O(1)8Multicast Service ModelSend to logical group address-Location-independentDelivery limited by specified scope-Can reach “nearby” membersBest effort delivery9Open Membership ModelAnyone, anywhere, can joinDynamic membership-join and leave at willAnyone can send at any time-Even nonmembers10Other Design Choices?11Division of ResponsibilitiesHost’s responsibility to register interest with networks-IGMPNetwork’s responsibility to deliver packets to host-Multicast routing protocolLeft unspecified:-Address assignment (random, MASC, etc.)-Application-to-group mapping (session directory, etc.)12Target EnvironmentLANs connected in arbitrary topologyLANs support local multicastHost network cards filter multicast traffic13Multicast Routing Algorithms14Routing Performance GoalsRoughly equivalent to unicast best-effort service in terms of drops/delays-Efficient tree-No complicated forwarding machinery, etc.Low join/leave latency15Two Basic Routing ApproachesSource-based trees: (e.g., DVMRP, PIM-DM)-A tree from each source to group-State: O(G*S)-Good for dense groups (all routers involved)Shared trees: (e.g., CBT, PIM-SM)-A single tree for group, shared by sources-State: O(G)-Better for sparse groups (only routers on path involved)16DVMRPDeveloped as a sequence of protocols:-Reverse Path Flooding (RPF)-Reverse Path Broadcast (RFB)-Truncated Reverse Path Broadcasting (TRPB)-Reverse Path Multicast (RPM)General Philosophy: multicast = pruned broadcast-Don’t construct new tree, merely prune old oneObservation: -unicast routing state tells router shortest path to S-Reversing direction sends packets from S without forming loops17Basic Forwarding RuleRouting state:-To reach S, send along link LFlooding Rule:-If a packet from S is received along link L, forward on all other linksThis works fine for symmetric links-Ignore asymmetry todayThis works fine for point-to-point links-Can result in multiple packets sent on LANs18ExampleFlooding can cause a given packet to be sent multiple times over the same linkxxyyzzSSabduplicate packet19Broadcasting ExtensionFor each link, and each source S, define parent and child-Parent: shortest path to S (ties broken arbitrarily)-All other routers on link are childrenBroadcasting rule: only parent forwards packet to LProblem fixedBut this is still broadcast, not multicast!20Multicast = Pruned BroadcastStart with full broadcast (RPB)If leaf has no members, prune state-Send non-membership report (NMR)If all children of a router R prune, then router R sends NMR to parentNew joins send graft to undo pruning21Problems with ApproachStarting with broadcast means that all first packets go everywhereIf group has members on most networks, this is okBut if group is sparse, this is lots of wasted trafficWhat about a different approach:-Source-specific tree vs shared tree-Pruned broadcast vs explicitly constructed tree22Core Based Trees (CBT)Ballardie, Francis, and Crowcroft,-“Core Based Trees (CBT): An Architecture for Scalable Inter-Domain Multicast Routing”, SIGCOMM 93Similar to Deering’s Single-Spanning TreeUnicast packet to core, but forwarded to multicast groupTree construction by receiver-based “grafts”-One tree per group, only nodes on tree involvedReduce routing table state from O(S x G) to O(G)23ExampleGroup members: M1, M2, M3M1 sends datarootM1M2M3control (join) messagesdata24DisadvantagesSub-optimal delaySingle point of failure (core)Small, local groups with non-local core-Need good core selection-Optimal choice (computing topological center) is NP complete25Why Isn’t Multicast Pervasive?Sound technologyImplemented in most routersUsed by many enterprisesBut not available on public Internet26Possible Explanation[Holbrook &


View Full Document

Berkeley COMPSCI 268 - Multicast

Documents in this Course
Lecture 8

Lecture 8

33 pages

L-17 P2P

L-17 P2P

50 pages

Load more
Download Multicast
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Multicast and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Multicast 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?