Multicast is (almost) as old as the Internet. Not only does it enable the efficient distribution of large-scale streaming events where delivery is intentionally organized around the schedule for an event, but it also facilitates those ‘water cooler’ moments for discovering last night’s program in an exchange with your colleagues at work. Hence, multicast provides a tool not just for improving network efficiency but also for coincidental discovery, much like social media experiences.
But advances in multicast technologies, as well as the identification of new use cases where network-level support may be desirable but unsuitable, can motivate us to rethink old perceptions of multicast and its use in the Internet overall.
In the IETF Routing Area Working Group (RTGWG) interim meeting on 22 June 2022 (coordinated by Adrian Farrel), Professor Lixia Zhang asked a crucial question in relation to multicast, specifically “’What are the things that are identified by the identifiers?”, a question Jon Crowcroft and I saw as fundamental to a better understanding but also characterizing multicast solutions, old and new alike.
If multicast is the answer, what was the question?
The (preliminary) outcome of considering Professor Zhang’s question has been captured in a brief discussion paper (available at arxiv) returned to the original question in which multicast is seemingly the right answer. In the paper, we outlined emerging new answers about what multicast intends to achieve.
A key insight learned from our revised look at multicast is the importance of decoupling the WHAT being communicated from HOW it is delivered, particularly in selecting the endpoints that should receive the multicast packets (the WHO), as represented in Figure 1.
Returning to Professor Zhang’s question, for such separation, it is crucial to understand what is being identified when requesting a multicast semantic from the network.
The one ring to rule them all?
With this separation in mind, we outlined a consolidated multicast semantic in order to look across variants of multicast realizations, not just IP multicast, in a consistent manner.
A datagram with source address S towards destinations D1, …, Dn, which in turn are identified through destination information D, is formed as one or more responses to adequate requests from D1,…, Dn towards S, where the ephemeral channel CM is defined through an identifying characteristic across all requests from D1,…, Dn.
In our semantic, the source address S and destinations D1, …, Dn represents the WHO in our separation, while the ephemeral channel CM allows for ensuring the provenance of the information (the WHAT) that is being requested, while the delivery information D (the HOW) is specific to the solution realizing the (efficient) delivery of the information. Figure 2 illustrates the information traversing the network according to our semantic.
Based on this semantic, we surveyed a number of solutions that exhibit multicast communication patterns, including IP multicast, but also various variants of information-centric networking (ICN) as well as newer IETF activities like Bit Index Explicit Replication (BIER) and Multicast Source Routing over IPv6 (MSR6).
Those approaches range from utilizing explicit group membership over implicit interest aggregation in the network (which possibly leads to multicast delivery of data returning to the interested parties) and using rendezvous points (for Protocol-Independent Multicast (PIM) dense and sparse mode but also certain ICN variants) to the source-based formation of multicast groups with path-based forwarding with bitfield encoding of those links utilized for transmission.
Why reconsider multicast?
Multiple use cases of multicast have been well documented but our paper outlines examples where the use of multicast is often not considered, particularly when coming from a group-based, long-lived relationship model.
The transmission of content chunks, for instance, can yield significant multicast gain when applying techniques like ICN, BIER, or MSR6 rather than insisting on unicast replication at the source, as is done in existing industry practice. Other examples such as interactive group experience, AI, as well as the Internet of Things have also been gaining more traction and interest, all while creating significant opportunities for possible multicast gains and thus efficiency improvements, particularly when utilizing coincidental techniques (the ad-hoc creation of multicast delivery relations) through newer solutions such as BIER and MSR6.
In the paper, we also argue that the need for improved efficiency is an important factor, certainly in times of increased scrutiny on energy efficiency; a topic also discussed in a recent workshop organized by the Internet Architecture Board (IAB) on the environmental impact of the Internet.
Falling into the same trap?
In discussions of our paper and in the IETF, the causes of IP multicast’s failure to proliferate are cited as economic incentives, amplification of Denial-of-Service (DoS) capabilities, or the lack of suitable billing and thus accountability. However, we can overcome issues of the past and our paper describes alternative solutions with either concrete examples or by a process of changing assumptions (such as the increasing locality of multicast relations).
What next (not just for the IETF)?
Crucially, to benefit from new learnings we must drive those insights into discussions about key issues. While for some, ICN’s attempt to rethink how networking is done may be seen as too radical, insights from related research works are nonetheless important when it comes to the evolution of addressing, routing, and scalability.
As we argue in the paper ‘If Multicast is the Answer – What was the Question?’, insights like these have resulted in newer approaches to multicast such as BIER and MSR6. The IETF surely has a key role to play, not just in standard setting as such but in attracting newer use cases and discussing realizations of multicast in the wider community, towards ultimately testing and adoption in real-life deployments. This paper is just one step in that direction.
Dr Dirk Trossen is a Chief Network Architecture Researcher at Huawei’s Applied Network Technology Laboratory in Munich, Germany with more than 25 years of experience in network architectures, services, and wireless technology.
Jon Crowcroft co-authored this post and the research paper. He has been the Marconi Professor of Communications Systems in the Computer Laboratory of the University of Cambridge since October 2001 with an interest in scalable multicast routing, practical approaches to traffic management, and the design of deployable end-to-end protocols.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.