Revisiting IP MulticastSylvia RatnasamyIntel ResearchAndrey ErmolinskiyU.C.BerkeleyScott ShenkerU.C.Berkeley and ICSIABSTRACTThis paper revisits a much explored topic in networking – the searchfor a simple yet fully-general multicast design. The many years ofresearch into multicast routing have led to a generally pessimisticview that the complexity of multicast routing – and inter-domainmulticast routing in particular – can only be overcome by restrict-ing the service model (as in single-source) multicast. This paperproposes a new approach to implementing IP multicast that wehope leads to a reevaluation of this commonly held view.Categories and Subject Descriptors: C.2.2 [Network Protocols]:Routing ProtocolsGeneral Terms: Design.Keywords: Routing, Multicast.1. INTRODUCTIONIn 1990, Deering proposed IP multicast – an extension to the IPunicast service model for efficient multipoint communication [1].The multicast service model offered two key benefits: (1) the effi-cient use of bandwidth for multipoint communication and, (2) theindirection of a group address which allows for network-level ren-dezvous and service discovery. Deering’s proposal triggered an eraof research on the implementation and applications of IP multi-cast. In terms of actual deployment, this research has had some-what mixed success. On the one hand, support for multicast is builtinto virtually every endhost and IP router and the service is oftendeployed within enterprise networks. However there is little cross-provider global deployment of multicast, and today, fifteen yearsafter Deering’s seminal work, the vision of a ubiquitous multicast“dialtone” remains an elusive, if not altogether abandoned, goal.Theories abound for why this vision was never realized (e.g.,[2–4]). Very broadly, most of these can be viewed as questioningthe viability of IP multicast on two fronts. The first is its practicalfeasibility given the apparent complexity of deploying and manag-ing multicast at the network layer. The second is the desirability ofsupporting multicast with many questioning whether the demandfor multicast applications justified the complexity of its deploy-ment, whether ISPs could effectively charge for the service, theadequacy of alternate solutions, and so forth.Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SIGCOMM’06, September 11–15, 2006, Pisa, Italy.Copyright 2006 ACM 1-59593-308-5/06/0009 ...$5.00.This paper directly addresses the issue of feasibility, proposinga simpler approach to implementing IP multicast that we call FreeRiding Multicast (FRM). We focus on inter-domain multicast forwhich complexity proved particularly acute but (as we describelater) FRM can be extended to the intra-domain scenario as well.FRM offers two key advantages over existing solutions:• by leveraging existing unicast routes, FRM virtually elim-inates the need for a distributed multicast route computa-tion thus side-stepping much of the network layer complexityassociated with traditional solutions (hence the name “FreeRiding”).• a domain’s participation and use of inter-domain multicast iseffected via the same channel as in the unicast case, namelyBGP, thus offering network operators a familiar frameworkwithin which to tackle the management (access control, ac-counting, etc.) of a multicast service.These advantages however come at a cost and the core tradeoffFRM makes is to tilt the complexity of route computation to the in-ternals of a router (as opposed to distributed protocol mechanism).Consequently, FRM requires more storage and algorithmic sophis-tication at routers and can be less efficient in bandwidth consump-tion than traditional multicast solutions. However this tradeoff – theavoidance of distributed computation and configuration at the costof optimal efficiency – is one we believe is worth exploring giventechnology trends [5] that can endow routers with significant mem-ory and processing on the one hand and our continued difficultiestaming wide-area routing algorithms on the other [6,7].The primary focus of this paper is the design and evaluation ofFRM. We lay the context for our work in Section 2, then discussprior work and our overall approach in Sections 3 and 4 respec-tively. We present the design, evaluation and implementation ofFRM in Sections 5, 6 and 7 respectively. Finally, we observe thatFRM represents a more general approach to supporting network-layer services such as anycast or data-centric routing. We touch onthis and other directions in Section 8.Our contribution is a new approach to implementing multicastthat we hope would lower the technical barriers to its deployment.At the same time, our exploration is triggered in part by the sus-picion that the desirability of multicast too might merit rescrutiny.We briefly touch on this in the following section.2. IN DEFENSE OF IP MULTICASTWhile we make no claims to understand the “market” for multi-cast, we observe that many of the applications that originally mo-tivated the research on multicast have (finally) arrived and wouldstill be well served by native multicast support.One example is massive multiplayer games (MMORPGs) withreports of 30-100% [8, 9] annual subscription growth and upto 5million active subscriptions in a year [10]. In these games, a player’smoves must be propagated to those in its “virtual” vicinity. Cur-rently, game operators achieve this by deploying multiple servers,each assigned a region of the virtual world, that relay commu-nication between players. Thus, for n nodes in a virtual region,the corresponding server’s bandwidth requirements vary from O(n)to O(n2) depending on the extent to which timeliness constraintsallow multiple updates to be aggregated [11, 12]. Such scalingcan be problematic and indeed numerous reports cite overloadedservers affecting the user experience [8, 12].1In a simple sce-nario, game operators might use multicast to cut server bandwidthto between O(1) to O(n). In a more sophisticated scenario, play-ers might directly multicast updates thus offloading data forward-ing from servers. In short, IP Multicast can aid game