RFC 3170
IP Multicast Applications: Challenges and Solutions
RFC 3170: IP Multicast Applications: Challenges and Solutions 💖
Okay bestie, let's get into it. This one is RFC 3170, titled IP Multicast Applications: Challenges and Solutions. B. Quinn from Celox Networks and K. Almeroth from UC-Santa Barbara wrote it. It's Informational (so it's not an Internet standard, just useful info 🧚) and it was published in September 2001. The title block doesn't list anything it obsoletes or updates. 🎀
Status of This Memo ✨
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice 🌸
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract 🦋
This doc is all about the challenges of designing and building multicast applications. It's an intro guide for app developers that spotlights what makes multicast apps different from unicast apps, and honestly it's giving very "read this before you build" energy. 💅
It walks through a taxonomy of multicast application I/O models and the kinds of services they can support. Then it covers the service requirements those apps need, plus the recent and ongoing efforts to build protocol solutions for them. 🔥
Table of Contents 🌈
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Focus and Scope. . . . . . . . . . . . . . . . . . . . . . . 3
2. IP Multicast-enabled Network. . . . . . . . . . . . . . . . . . 3
2.1 Essential Protocol Components. . . . . . . . . . . . . . . . 4
2.1.1 Expedient Joins and Leaves . . . . . . . . . . . . . . . 5
2.1.2 Send without a Join. . . . . . . . . . . . . . . . . . . 5
3. IP Multicast Application Taxonomy . . . . . . . . . . . . . . . 6
3.1 One-to-Many Applications . . . . . . . . . . . . . . . . . . 8
3.2 Many-to-Many Applications. . . . . . . . . . . . . . . . . . 9
3.3 Many-to-One Applications . . . . . . . . . . . . . . . . . .10
4. Common Multicast Service Requirements . . . . . . . . . . . . .13
4.1 Bandwidth Requirements . . . . . . . . . . . . . . . . . . .13
4.2 Delay Requirements . . . . . . . . . . . . . . . . . . . . .13
5. Unique Multicast Service Requirements . . . . . . . . . . . . .14
5.1 Address Management . . . . . . . . . . . . . . . . . . . . .16
5.2 Session Management . . . . . . . . . . . . . . . . . . . . .16
5.3 Heterogeneous Receiver Support . . . . . . . . . . . . . . .18
5.4 Reliable Data Delivery . . . . . . . . . . . . . . . . . . .20
5.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . .21
5.6 Synchronized Play-Out. . . . . . . . . . . . . . . . . . . .23
6. Service APIs. . . . . . . . . . . . . . . . . . . . . . . . . .23
7. Security Considerations . . . . . . . . . . . . . . . . . . . .24
8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . .24
9. References. . . . . . . . . . . . . . . . . . . . . . . . . . .24
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .27
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . .281. Introduction 🚀
IP Multicast is going to be a huge deal on the Internet in the coming years. It's a requirement, not an option, if the Internet is going to scale. 📈 Multicast lets app developers add more functionality without really hammering the network. ✨
Making multicast apps is supposedly simple, and I'm not gonna lie, that's kinda the trap 🙈. Having datagram access means any app can send to a multicast address. A multicast app only needs to bump the Internet Protocol (IP) time-to-live (TTL) value to more than 1 (the default value) so its outgoing datagrams can get through routers. To receive a multicast datagram, apps join the multicast group, and that quietly generates an [IGMPv2, IGMPv3] group membership report. 💫
The simplicity is deceptive though, bestie. Getting multicast support into apps and protocols that scale well on a heterogeneous network is a serious challenge. Sending constant bit rate datastreams, reliable data delivery, security, and managing many-to-many communications all need special consideration. 😭 Some solutions exist, but a lot of these services are still active research areas. 🧪
1.1 Motivation 🎯
The point of this document is to give you a framework for understanding the challenges of designing and implementing multicast apps. To use multicast communications correctly, app developers first have to understand the various I/O models and the network services (on top of basic multicast communication) that are required. Next, devs need to know about the efforts underway to provide those services. These efforts range from deployed commercial products all the way to basic research to check if something is even feasible. 🔬
Multicast-based apps and services are going to play a big role in the future of the Internet as deployment keeps growing and encouraging their use. It's important that devs know the issues and solutions available, and especially their limitations, so they don't end up with protocols that negatively impact networks (which totally cancels out the benefits of multicast) or waste their effort "re-inventing the wheel". 🛞🙄
The hope is that by raising developers' awareness, we can adjust their expectations about finding solutions and steer them toward successful, scalable, and "network-friendly" development efforts. 🌱
1.2 Focus and Scope 🔍
Our starting premise is that the multicast infrastructure is transparent to applications, so it isn't directly relevant to this discussion. 🫶 Our focus is on multicast application protocol services, so this doc explicitly skips any discussion of multicast routing issues. We identify and describe the multicast-specific issues involved in developing apps.
We assume you've got a general understanding of how multicast works, and in that respect we're meant to compliment other introductory documents [BeauW, Maufer, Miller]. Since this is an introductory survey and not a comprehensive examination, we point readers to other multicast application requirements descriptions [RM, LSMA, Miller] for more detail. 📚
For the rest of the doc, we first define the term "IP multicast enabled network", the multicast infrastructure, and the essential multicast services. Next we describe the new types of functionality that multicast apps can enable and what they require. Then we look at the services that satisfy those requirements, the challenges they bring, and give a quick survey of the solutions that are available or under development. We wrap up with a discussion of application programming interfaces (APIs) for multicast services. 🎀
2. IP Multicast Enabled Network 🌐
An "IP multicast-enabled network" provides end-to-end services in the IP network infrastructure so that any IP host can send datagrams to an IP multicast address that any number of other IP hosts, widely dispersed, can receive. 💜
There are two kinds of multicast-enabled networks available. The first is based on the original multicast service model defined in RFC 1112 [Deering]. In this model, a receiver just joins the group and doesn't need to know who the source(s) are. This model goes by a bunch of names, including Internet Standard Multicast (ISM), Internet Traditional Multicast (ITM), Deering multicast, etc. 🧁
The second kind changes the original service model so that, in addition to knowing the group address, a receiver must know the set of relevant sources. This is called Source Specific Multicast (SSM) [SSM]. It becomes the application's responsibility to know what kind of multicast capability the network provides. Right now, the only way for an app to figure out the type of multicast is from the group address. If the group is in the 232/8 range, the application should assume SSM is the service model. Otherwise, the application should assume source-generic multicast is the service model. 🕵️♀️
At the time of writing, end-to-end "global" multicast service isn't available yet, but the "multicast-enabled" Internet is growing. 🌱 Recent development and deployment of interdomain multicast routing protocols and multicast-friendly Internet exchanges have enabled peering between major ISPs. This, along with the growing availability of compelling content, is spurring deployment and availability of the IP Multicast Enabled Network. 📈
For the rest of this document we assume the multicast-enabled network is already ubiquitous. Since a large and growing portion of the global Internet is IP multicast-enabled now, and many enterprise networks (intranets) are too, this perspective is relevant today. 💅
2.1 Essential Protocol Components 🧩
An IP multicast enabled network needs two essential protocol components:
- An IP host-based protocol that lets a receiver application notify a local router(s) that it has joined the group, and starts the data flow from all sender(s) within the scope.
- An IP router-based protocol that lets any routers with multicast group members (receivers) on their local networks talk to other routers, so that all datagrams sent to the group address get forwarded to all receivers within the intended scope.
Ideally these protocol components are transparent to multicast apps. 🫧 However, there are two parts of their functionality requirements worth calling out specifically, because they affect app performance and design. These are the multicast application requirements for:
- Expedient Joins and Leaves
- Sends without a Join
2.1.1 Expedient Joins and Leaves ✨
okay so some apps need joins and leaves to be super speedy, because their usability or functionality is sensitive to how much latency there is when joining or leaving a group 💅
- Join Latency: The time it takes for data to begin flowing after an application issues a command to join a multicast group
- Leave Latency: The time it takes for data to stop flowing after an application issues a command to leave a multicast group [IGMPv2,IGMPv3]
picture distributed a/v as a multicast-based "television" 📺 it has to let users "channel surf"--changing channels frequently. every channel change triggers a group leave and a group join, so any delay in either one wrecks the vibe 😭 ngl this is more of a user requirement than an application requirement
the functionality of distributed interactive simulations [DIS] is also super sensitive to join/leave latency 🛸 this is especially true when you're trying to share info about fast-moving objects that zip in and out of a simulated environment (think low-flying, fast-moving aircraft). if the join latency is too long, the info is already old by the time it shows up 💀
a fast leave phase is highly desirable for two reasons: it helps congestion control mechanisms stop unwanted flows quickly, and it helps the network in general filter out unwanted traffic [Rizzo] 🧹 applications can't control join or leave latency themselves. they depend on the multicast infrastructure to make these operations expedient. this is a basic multicast service requirement 🎀
2.1.2 Sends without a Join
applications that send to a multicast address should be able to start sending right away, without joining the destination group first 🚀 this matters a lot for embedded devices and bursty-source applications that need low-delay delivery
the current IGMP-based multicast host model and all current implementations let senders send to a group without joining it, as a standard feature 🫶
3. IP Multicast Application Taxonomy 🌈
with an IP multicast-enabled network, some unique and powerful applications and application services become possible ✨ as [Estrin] puts it: "Multicast enables coordination - it is well suited to loosely coupled distributed systems (of people, servers, databases, processes, devices...)" 🧚
a "multicast application" is simply defined as any application that sends to and/or receives from an IP multicast address. these may or may not also reference IP unicast addresses, as we describe later 🍓
what makes IP multicast applications different from one-to-one unicast apps is the other sender and receiver relationships multicast enables 👑 there are three general categories of multicast applications:
- One-to-Many (1toM): A single host sending to two or more (n) receivers
- Many-to-Many (MtoM): Any number of hosts sending to the same multicast group address, as well as receiving from it
- Many-to-One (Mto1): Any number of receivers sending data back to a (source) sender via unicast or multicast
here's the vibe check, Table 1 🔍
+-----------------------------------+
| Host 2->n ("many") |
+-------------+---------------------+
| One-Way | Two-Way |
+-------------+---------------------|
| A B | C D E |
+-----------+-------------+---------------------+
| I/O | | S(m)/ S(u)/ S(m)/|
| Operations| S(m) R(m) | R(m) R(m) R(u) |
+-------+---+-----------+-------------+---------------------|
| | 1 | S(m) | 1toM | MtoM |
| Host | 2 | R(m) | Mto1 | MtoM |
| +---+-----------+-------------+ |
| 1 | 3 | S(m)/R(m) | Mto1 1toM MtoM |
| | 4 | S(m)/R(u) | Mto1 |
|("one")| 5 | S(u)/R(m) | Mto1 |
+-------+---+-----------+-----------------------------------+
Legend: S: "Send" (u): "unicast"
------ R: "Receive" (m): "multicast"
Table 1: Application types characterized by I/O relationships
and destination address types (multicast or unicast)Table 1 defines these application types by the I/O relationships they represent 🦋 the categories are defined by the combination of communication mechanisms they use. at the IP level, all multicast I/O is only 1toM or MtoM, and unicast is always one-to-one (1to1). the Mto1 category, for example, covers several possible combinations of IP-level relationships, including unicast. we created Mto1 to help tell apart the many applications and services that use multicast 💖
1toM: MtoM: Mto1:
R1 S1/R1 S1
/ / | \ \
S-R2 S2/R2-+-S3/R3 S2-R
\... \ | / .../
Rn Sn/Rn Sn
Legend: S: "Sender"
------ R: "Receiver"
Figure 1: Generalization of the three application categoriesFigure 1 shows the general model for each of the three multicast application categories 🌸 again, Mto1 is an artificial category, defined by the application-level relationship between sender(s) and receiver. at the IP level, multicast doesn't provide an Mto1 I/O mechanism, since it doesn't let senders limit receivers, or even know who they are. receiver information and limits are handled at the application level, as the multicast application requires 🫠
we go through each of these general application types in more detail, with examples, in the subsections below. the list of examples isn't comprehensive, but it tries to capture the prominent multicast application and service types in each of the three categories. we reference these items throughout the rest of the document as we describe their specific service requirements, the challenges they present, and the solutions that are available or under development 🛠️
3.1 One-to-Many Applications
one-to-many (1toM) apps have a single sender and multiple simultaneous receivers 📣 entry B1 in Table 1 is the classic 1toM relationship. entry B3 is only slightly different, since the sender also acts as a receiver (i.e., it has loopback enabled) 🔁
when people think of multicast, they usually think of broadcast-style multimedia: television (video) and radio (audio). that's a reasonable analogy, and these are definitely significant multicast applications, but they're far from the full extent of what multicast can enable. audio/video distribution is just a fraction of the possibilities, and most of them don't have analogs in today's consumer broadcast industry 📻
- a) Scheduled audio/video (a/v) distribution: Lectures, presentations, meetings, or any other type of scheduled event whose multimedia coverage could benefit an audience (i.e. television and radio "broadcasts"). One or more constant-bit-rate (CBR) datastreams and relatively high-bandwidth demands characterize these applications. When more than one datastream is present--as with an audio/video combination--the two are synchronized and one typically has a higher priority than the other(s). For example, in an a/v combination it is more important to ensure an intelligible audio stream than perfect video 🎙️
- b) Push media: News headlines, weather updates, sports scores, or other types of non-essential dynamic information. "Drip-feed", relatively low-bandwidth data characterize these applications 📰
- c) File Distribution and Caching: Web site content, executable binaries, and other file-based updates sent to distributed end-user or replication/caching sites 📦
- d) Announcements: Network time, multicast session schedules, random numbers, keys, configuration updates, (scoped) network locality beacons, or other types of information that are commonly useful. Their bandwidth demands can vary, but they're generally very low bandwidth 📢
- e) Monitoring: Stock prices, sensor equipment (seismic activity, telemetry, meteorological or oceanic readings), security systems, manufacturing or other types of real-time information. Bandwidth demands vary with sample frequency and resolution, and may be either constant-bit-rate or bursty (if event-driven) 📊
3.2 Many-to-Many Applications
in many-to-many (MtoM) applications, two or more of the receivers also act as senders 🤝 in other words, MtoM apps are characterized by two-way multicast communication 💬
the many-to-many capabilities of IP multicast enable the most unique and powerful applications 🔥 each host running an MtoM app may receive data from multiple senders while also sending data to all of them. as a result, many-to-many apps often come with complex coordination and management challenges 😵💫
- f) Multimedia Conferencing: Audio/Video and whiteboard make up the classic conference app. Having multiple datastreams with different priorities characterizes this type of application. Co-ordination issues--such as determining who gets to talk when--complicate their development and usability. There are common heuristics and "rules of play", but no standards exist for managing conference group dynamics 🎤
- g) Synchronized Resources: Shared distributed databases of any type (schedules, directories, as well as traditional Information System databases) 🗂️
- h) Concurrent Processing: Distributed parallel processing ⚙️
- i) Collaboration: Shared document editing 📝
- j) Distance Learning: This is a one-to-many a/v distribution application with "upstream" capability that allows receivers to question the speaker(s) 🙋♀️
- k) Chat Groups: These are like text-based conferences, but may also provide simulated representations ("avatars") for each "speaker" in simulated environments 💬
- l) Distributed Interactive Simulations [DIS]: Each object in a simulation multicasts descriptive information (e.g., telemetry) so all other objects can render the object and interact as necessary. The bandwidth demands for these can be tremendous, as the number of objects and the resolution of descriptive information increases 🛸
- m) Multi-player Games: Many multi-player games are simply distributed interactive simulations, and may include chat group capabilities. Bandwidth usage can vary widely, although today's first-generation multi-player games attempt to minimize bandwidth usage to increase the target audience (many of whom still use dial-up modems) 🎮
- n) Jam Sessions: Shared encoded audio (e.g., music). The bandwidth demands vary based on the encoding technique, sample rate, sample resolution, number of channels, etc. 🎶
3.3 Many-to-One Applications 🌸
okay so the many-to-one (Mto1) category is lowkey different from the other two, bestie, because it's not a communications mechanism at the IP layer 🫶 Mto1 apps have multiple senders and one (or a few) receivers, and that's defined at the application layer. Table 1 shows that Mto1 apps can be one-way, or use a two-way request/response protocol where either the senders or the receiver(s) can generate the request. Figure 2 breaks down the I/O possibilities:
1) S1 2) S1 3) S1 4) S1
\ \ \ \
S2-R S2-R S2-R S2-R
.../ .../ .../ .../
Sn Sn Sn Sn
Data(m) Request(m) Request(m) Request(u)
------> ----------> <---------- ---------->
Response(u) Response(u) Response(m)
<----------- -----------> <----------
Figure 2: Characterization of Mto1 I/O possibilitiesMto1 apps have a LOT of scaling issues 😭 Too many simultaneous senders can totally overwhelm the receiver(s), which is called the "implosion problem" 💀 The other big one is the huge amount of state the network has to hold because there are so many multicast senders. Apps mostly don't notice this, and it might get better later with bi-directional trees in multicast routing protocols 🦋 But app designers should still keep it in mind ✨
There are no standards yet for alternate and equivalent Mto1 app designs, but there are a few possibilities to think about [HNRS]. The main perk of multicast in an Mto1 app is that senders don't need to know the receiver(s) unicast address(es). So one option is for each receiver to advertise its unicast address via multicast 💜 BUT this still leaves the implosion risk on each receiver, so extra strategies might be needed to spread the load. For example, you could increase the number of receivers (in a "flat" receiver topology), or set up localized receivers (in a "hierarchical" topology) like the ones used in "local recovery" (section 5.3) 🧚 These methods come with coordination issues, and since standard solutions haven't been identified yet, Mto1 app developers should weigh their alternatives carefully 🔥
o) Resource Discovery: Service Location is a perfect example, because it uses IP Multicast to get something like a "host anycasting service" capability [AnyCast] 🌈 A multicast receiver sends a query to a group address, and the closest host responds so it can satisfy the request. The responses might also include info that helps the receiver figure out the most appropriate (e.g., closest) service provider to use 👑
In Table 1, this app is entry D4. It's also illustrated in Figure 2 as possibility number 3. Alternately, the response could go to a multicast address instead of a unicast one, although technically that would make it an MtoM application type. (This is how the Service Location Protocol [SLP] works, when a user agent tries to find a directory agent 🎀)
p) Data Collection: This is the flip side of the one-to-many "monitoring" app we talked about earlier 🍓 Here there can be any number of distributed "sensors" sending data to a data collection host. The sensors might send updates in response to a request from the data collector, send continuously at regular intervals, or send spontaneously when a pre-defined event happens. Bandwidth demands can vary based on sample frequency and resolution 💖
This shows up in Table 1 as entries A1 and A3, the only difference being that A3 has a loopback interface. In Figure 2, this is possibility number 1. Since the number of receivers can easily be more than one, this is really an MtoM application 🫶
q) Auctions: The "auctioneer" kicks off the bidding by describing whatever is for sale (product, service, or whatever), and receivers send their bids privately or publicly (i.e., to a unicast or multicast address) 💅
This is possibility number 2 in Figure 2, and D5 in Table 1. The response could go to a multicast address, although technically that would make it an MtoM application ✨
r) Polling: The "pollster" sends out a question, and the "pollees" respond with answers 🦋 This is possibility number 2 in Figure 2, and it could also be characterized as an MtoM application if the response goes to a multicast address.
s) Jukebox: This one allows near-on-demand a/v playback 🎶 Receivers use an "out-of-band" protocol mechanism (via web, email, unicast or multicast requests, etc.) to send their playback request into a scheduling queue [IMJ].
This is characterized by possibility number 4 in Figure 2, and entry D4 in Table 1. The initial unicast request is the only difference between this type of app and a typical 1toM. If that initial request were sent to a multicast address, it would effectively be an MtoM application 🌸
t) Accounting: This is basically data collection, but it's worth separating out since it's such an important app 🔥 In some multicast apps it's imperative to know info about each receiver, possibly in real-time. But that info can get overwhelming [MRM] 💀 Current mechanisms, like RTCP (which is actually MtoM since it's multicast but could be made Mto1), use scaling techniques but trade off information granularity. As a group grows, the total amount of feedback stays constant, but each receiver sends less 🧚
4. Common Multicast Service Requirements ✨
Some multicast app service requirements are also common to unicast network apps 🫶 We're going to look at two of them here: bandwidth and delay requirements 💜
4.1 Bandwidth Requirements 🌈
Figure 3 shows the approximate bandwidth requirements of multicast apps 👑
Both unicast and multicast apps need to be designed to adapt to the variability of network conditions. But as we describe in section 5.3, it's the need to accommodate multiple heterogeneous multicast receivers, with their diversity of bandwidth capacity and delivery delays, that makes it a unique challenge for multicast apps to meet these requirements 😭
|
1toM | b, d c, e a
|
MtoM | k g, i f, h, j, l, m, n
|
Mto1 | o, q, r p, t s
|
+-----------------------------------------------
Low Bandwidth High Bandwidth
Figure 3: Bandwidth Requirements of applications4.2 Delay Requirements 🦋
Aside from apps with time-sensitive data (e.g., stock prices, and real-time monitoring info), most one-to-many apps have a high tolerance for delay and delay variance (jitter) 🍓 Constant bit-rate (CBR) data, like streaming media (audio/video), is sensitive to jitter, but apps usually counteract that by buffering data and delaying playback 💖
Most many-to-one and many-to-many multicast apps are intolerant of delays, because they're bidirectional, interactive, and request/response dependent 🔥 So delays should be minimized, since they can seriously hurt the app's usability 💀
This need to minimize delays is most obvious in (two-way) conference apps, where users can't converse effectively if the audio or video is delayed by more than 500 milliseconds 🙈 For this and other examples, see Figure 4, which plots multicast apps on a (coarse) scale of sensitivity to delivery delays ✨
|
1toM | b, c a, d e
|
MtoM | g, i, j, k f, h, l, m, n
|
Mto1 | r o, p, s, t q
|
+-----------------------------------------------
Delay Tolerant Delay Intolerant
Figure 4: Delay tolerance of application typesFor delay-intolerant multicast (or unicast) apps, quality of service (QoS) is the only option 🌈 IP networks currently only provide "best effort" delivery, so data is subject to variable router queuing delays and loss due to network congestion (router queue overflows) 😭 IP QoS standards do exist now [RSVP], and efforts to enable end-to-end QoS support in the Internet are underway [E2EQOS] 👑
However, QoS support is an IP network infrastructure consideration. Although there are multicast-specific challenges for implementing QoS in the network for multicast flows, they're beyond the control of applications, so further discussion of the QoS protocols and services is beyond the scope of this document 🧚
5. Unique Multicast Service Requirements ✨
okay so the three application categories we talked about earlier are super general, bestie 🫶 Inside each category, and even inside each application type, specific apps have all kinds of different requirements. One-to-many apps are pretty simple to build, but many-to-one and many-to-many apps come with real challenges, as we pointed out. Some of them have bandwidth and delay requirements, just like unicast apps do.
Multicast apps can also be told apart from unicast apps, and from each other, by the services they need. This section is basically a survey of the services that have unique requirements for multicast apps 💅
+--------------------------------------------------------------+
| Multicast Application |
+--------------------------------------+ +-------------------+
+-------------------------------------+| |+--------++--------+
| Multicast Security || || || |
+----------------------+ +----------+| || System || |
+----------++---------+| |+---------+| || Time || Codecs |
| Reliable || Address || || Session || || || |
| Delivery || Mgt || || Mgt || || || |
+----------++---------++---++---------++---++--------++--------+
+----------------------------------------++--------------------+
| Basic IP Multicast Service || IP Unicast |
| (e.g., UDP and IGMPv2/v3) || Service |
+----------------------------------------++--------------------+Figure 5: Multicast service requirements summary
Here's the list of multicast app service requirements, lowkey the core of this whole section 🌸
- Address Management - Selection and coordinated of address allocation. The need is to provide assurances against "address collision" and to provide address ownership.
- Session Management - Perform application-layer services on top of multicast transport. These services depend heavily on the application but include functions like session advertisement, billing, group member monitoring, key distribution, etc.
- Heterogeneous Receiver Support - Sending to receivers with a wide variety of bandwidth capacities, latency characteristics, and network congestion requires feedback to monitor receiver performance.
- Reliable Data Delivery - Ensuring that all data sent is received by all receivers.
- Security - Ensuring content privacy among dynamic multicast group memberships, and limiting senders.
- Synchronized Play-Out - Allow multiple receivers to "replay" data received in synchronized fashion.
In the rest of this section we go through each of these app services in more detail, the challenges they bring, and where standardized solutions are at 🦋
5.1 Address Management
okay first question every multicast app developer runs into: which multicast address do I use?? 😭 Multicast addresses aren't assigned to individual hosts, the assignments can change dynamically, and some addresses have meanings of their own (like Admin Scoping). So multicast apps need an address management service that handles address allocation or assignment queries. There are a few ways apps can learn about multicast addresses:
- Hard-Coded: Software configuration, encoded in a binary executable, or burned into ROM in embedded devices. These apps typically reference IANA statically allocated multicast addresses (including relative addresses).
- Advertised: Session announcements (as described in the next section), or via another "out-of-band" query or discovery protocol mechanism.
- Algorithmically Derived: Using a programmatic algorithm to allocate a statistically random (unused) address.
|
1toM | c, e a, b d
|
MtoM | f, j, k, n g, h, i, l, m
|
Mto1 | r o, p, s q, t
|
+-----------------------------------------------
Hard-Coded Advertised AlgorithmicFigure 6: Multicast address usage for application types
In almost all cases, app designers should assume that multicast addresses are going to be dynamic 🎀 Very little of the multicast address space is available for static assignment by IANA [MADDR]. And since SSM gives you host-specific addressing, Internet-wide static address assignment is expected to be super rare 🙈
5.2 Session Management
Session management is one of the most misunderstood services when it comes to multicast, no cap 💀 Most app developers assume multicast will handle stuff like security, encryption, reliability, session advertisement, monitoring, billing, etc. But real talk, multicast is just a transport mechanism that gives you end-to-end delivery. Everything else is an application-layer service that has to be provided by each particular app. On top of that, in most cases there aren't defined standards for how these functions should be provided. What each function needs depends on the app, and no single method (or standard) can cover every case 🧚
There are no generic solutions that give you every session management function, but there are some protocols and common techniques that support some of them ✨ Congestion control and heterogeneous receiver support techniques are discussed in Section 5.3. Protocols for reliability are discussed in Section 5.4. Security considerations are discussed in Section 5.5.
For session advertisement, there are a bunch of mechanisms, and one popular move is advertising sessions via the WWW. Users can join a group by clicking on URLs, and then get a response that includes the group address and maybe info about group source(s) 🌈 Another option is the session description protocol [SDP]. It gives you a format for representing info about sessions, but it doesn't handle transport for sending those session descriptions around, and it doesn't do address allocation or management either. SDP only provides the syntax for describing session attributes, periodt 💅
SDP session descriptions can be shared publicly or privately over any number of transports, including web (HTTP) and MIME encoded email. The session announcement protocol [SAP] is the de facto standard transport, and a lot of multicast-enabled apps use it right now. SAP limits distribution through multicast scoping, but the current protocol definition has scaling issues that still need fixing 😩 Specifically, the initialization latency for a session directory can get pretty long, and it grows in proportion to the number of session announcements. This is kind of a multicast infrastructure issue, though, since this level of protocol detail should be transparent to apps 🦋
The session management service needs to:
- Advertise scheduled sessions
- Provide a query mechanism for retrieving information about session schedules
5.3 Heterogeneous Receiver Support 🦋
okay so the Internet is literally a network of networks 🌐 and IP's whole superpower is letting hosts on totally different network media still talk to each other seamlessly. that's the heterogeneous network, and it's iconic. 💅
when two hosts chat via unicast (one-to-one) over IP, it's pretty easy for the sender to adapt to whatever the network is doing. TCP provides reliable data transport and is basically the queen of "network friendly" adaptability 👑
TCP receivers send acknowledgements back to the sender for data they got. the TCP sender notices data loss when something it sent isn't acknowledged. when it sees loss, TCP assumes there's network congestion or a low-bandwidth link, and it adapts by throttling down its send rate [SlowStart]. so careful and polite 🫶
User Datagram Protocol (UDP) doesn't have a receiver feedback loop like TCP does, since UDP doesn't provide reliable data delivery. that means it also doesn't have a loss detection and adaptive congestion control mechanism like TCP does. buuut 🙈 it's totally possible for a unicast UDP app to enable similar adaptive algorithms and get the same result, or even do better!
a unicast UDP app that uses a feedback mechanism to detect data loss and adapt its send rate can actually beat TCP at this. TCP automatically shrinks the "congestion window" when loss is detected, although the updated send rate may be slower than what a CBR audio/video stream needs. when a UDP app detects loss, it can adapt the data itself to fit the lower send rate. for example, a UDP application can:
- Reduce the data resolution (e.g., send lower fidelity audio/video by reducing sample frequency or frame rate) to reduce data rate. 🎀
- Modify the data encoding to add redundant data (e.g., forward error correction) offset in time to avoid fate sharing. This could also be "layered", so a percentage of data loss will simply reduce fidelity rather than corrupt the data. 🧚
- Reduce the send rate of one datastream in order to favor another of higher priority (e.g., sacrifice video in order to ensure audio delivery). 🎶
- Send data at a lower rate (i.e., with a different encoding) on a separate multicast address and/or port number for high-loss receivers. 🌸
however, with multicast apps (one-to-many or many-to-many) that have multiple receivers, the feedback loop design needs to be modified 🙃 if all receivers return data loss reports at the same time, the sender gets absolutely buried in a storm of replies. this is known as the "implosion problem" 💀
another problem is that heterogeneous receiver capabilities can vary wildly. this happens statically because of the wide range of network media bandwidth capabilities, and dynamically because of transient traffic conditions. if a sender adapts its send rate and data resolution based on the loss rate of its worst receiver(s), then it can only serve the lowest common denominator. hence, a single "crying baby" can spoil it for all the other receivers 😭
there are strategies for dealing with these heterogeneous receiver problems. here are two examples:
- Shared Learning - When loss is detected (i.e., a sequenced packet isn't received), a receiver starts a random timer. If it receives a data loss report sent by another receiver while it waits for the timer to expire, it stops the timer and does not send a report. Otherwise, it sends a report when the timer expires. The Real-Time Protocol and its feedback-loop counterpart Real-Time Control Protocol [RTP/RTCP] employ a strategy similar to this to keep feedback traffic to 5 percent or less of the overall session traffic. This technique was originally utilized in IGMP. ✨
- Local Recovery - Some receivers may be designated as local distribution points or "transcoders" that either re-send data locally (possibly via unicast) when loss is reported, or re-encode the data for lower bandwidth receivers before re-sending. No standards exist for these strategies, although "local recovery" is used by several reliable multicast protocols. 🍓
adaptive multicast app design for heterogeneous receivers is still an active area of research 🔬 the fundamental goals are to maximize application usability while accommodating network conditions in a "network friendly" manner. in other words, congestion detection and avoidance are (at least) as important in protocol design as the user experience. the adaptive mechanisms also need to be stable, so they don't adapt too quickly. changing encodings and rates based on too little information about what may be a transient condition can cause oscillation, and nobody wants that 🌀
this "feedback loop" service that's needed to support heterogeneous receivers isn't shown in the services summary in Figure 4, although it could be added alongside "Reliable Transport" and the others. this service could be implemented within an application or accessed externally, as provided by the operating system or a third party. see [HNRS] for a taxonomy of strategies for providing feedback for multicast, with the ultimate goal of developing a common multicast feedback protocol 💜
5.4 Reliable Data Delivery 🌈
a lot of the multicast app examples on our list (like audio/video distribution) have loss-tolerant data content. the data can stay useful even if some of it gets lost. for example, audio might have a short gap or lower fidelity but will stay intelligible despite some data loss 🎧
other app examples (like caching and synchronized resources) require reliable data delivery. they deliver content that has to be complete, unchanged, in sequence, and without duplicates 🧐 the "Loss Intolerant" column in Figure 7 shows the apps with this requirement, while the others can tolerate varying levels of data loss. the tolerance levels are typically determined by the nature of the data and the encoding in use 🍰
|
1toM | b a, d c, e
|
MtoM | f, j, k, l, m, n g, h, i
|
Mto1 | o, p, r, s, t q
|
+------------------------------------------------
Loss Tolerant Loss Intolerant
Figure 7: Reliability Requirements of Application typessome of the challenges with enabling reliable multicast transport are the same as those of sending to heterogeneous receivers, and some of the solutions are similar too 🤝 for example, many reliable multicast transport protocols avoid the implosion problem by using negative acknowledgements (NAKs) from receivers to indicate what was lost. they also use "shared learning", where receivers listen to others' NAKs and then listen for the resulting retransmission of data, rather than requesting retransmission by sending a NAK themselves. big brain energy 🧠
although reliable delivery can't change the data sent (except, perhaps, to use a loss-less data compression algorithm), it can use other adaptive techniques like sending redundant data or adjusting the send rate 🔁
although many reliable multicast protocol implementations exist [Obraczka], and a few are already available in commercial products, none of them are standardized. work is ongoing in the "Reliable Multicast" research group of the Internet Research Task Force [IRTF] to provide a better definition of the problem, the multicast transport requirements, and protocol mechanisms 🔭
scalability is the paramount concern 👑, and it implies the general need for "network friendly" protocols that detect and avoid congestion as they provide reliable delivery. other considerations are protocol robustness, support for "late joins", group management, and security (which we discuss next) 🔐
the current consensus is that, due to the wide variety of multicast application requirements (some of which are at odds), no single multicast transport will likely be appropriate for all applications. as a result, most believe we will eventually standardize a number of reliable multicast protocols, rather than a single one [BULK, RMT] 💖
5.5 Security
Okay so security is non-negotiable for ANY IP network app, unicast or multicast, bestie 🔒 because networks are full of users with totally different levels of trust. Like, not everyone in the room is your friend 💅
Network app security is already hard for unicast 😭 and the more you need it (aka the scarier it gets to go without it), the harder it gets. The complexity and overhead of a security system is basically matched to how much protection it gives you. As Schneier puts it: "No one can guarantee 100% security. But we can work toward 100% risk acceptance...Strong cryptography can withstand targeted attacks up to a point--the point at which it becomes easier to get the information some other way...A good design starts with a threat model: what the system is designed to protect, from whom, and for how long." [Schneier]
Multicast apps need security just as much as unicast ones do, and they need the same basic services: user authentication, data integrity, data privacy and user privacy (anonymity). BUT enabling security for multicast is even more of a challenge than for unicast 🙈 having multiple receivers makes a difference, and so do their heterogeneity and the dynamic nature of multicast group memberships. It's a whole thing ✨
Multicast security requirements can include any combination of the following services:
- Limiting Senders - Controlling who can send to group addresses
- Limiting Receivers - Controlling who can receive
- Limiting Access - Controlling who can "read" multicast content either by encrypting content or limiting receivers (which isn't possible yet)
- Verifying Content - Ensuring that data originated from an authenticated sender and was not altered en route
- Protecting Receiver Privacy - Controlling whether sender(s) or other receivers know receiver identity
- Firewall Traversal - Proxying outgoing "join" requests through firewalls, allowing incoming or outgoing traffic through, and (possibly) authenticating receivers for filtering purposes and security [Finlayson].
This list isn't comprehensive, but it covers the most commonly needed security services 🦋 Different multicast apps and different app contexts can have wildly different needs for these services, and for others too. Two main issues stand out, where the performance of current solutions leaves much to be desired [MSec]:
- Individual authentication - how is sender identity verified for each multicast datagram received?
- Membership revocation - how is further group access disabled for group members that leave the group (e.g., encryption keys in their possession disabled)?
Performance mostly matters when a user joins or leaves a group ⏱️ For example, the methods used to authenticate potential group members during joins, or to re-key current members after a member leaves, can involve a lot of processing and protocol overhead. That can cause big delays that hurt usability 😩
Like reliable multicast, secure multicast is also being investigated in the Internet Research Task Force [IRTF] 🌈 Protocol mechanisms for many of the most important of these services, like limiting senders, haven't even been defined yet, let alone developed and deployed.
Same as with reliable multicast, the current consensus is that no single security protocol will satisfy the wide variety of sometimes-contradictory requirements across multicast apps. So multicast security will probably need a bunch of different protocols 👑
5.6 Synchronized Play-Out
This is when all receivers play out the multicast data they received at the same time ⭐ It might be needed for fairness, like playing out prices for auctions or stock prices, or to keep receivers in sync with each other, like when playing music 🎶
Picture this: a multi-speaker stereo system wired through a whole house (analog). With the stereo playing on every speaker set, you hear continuous music as you walk from room to room 🎀
Now imagine a house full of multimedia and network-enabled computers. They'll all receive the same music datastream at the same time via multicast, but the playback will be discontinuous as you walk from room to room 💀
To get synchronized playback that keeps the music continuous from room to room, you need three things:
- system clocks on all systems should be synchronized
- datastreams must be framed with timestamps
- you must know the playback latency of the multimedia hardware
The third one is the hardest to achieve right now 😤 Hardware and drivers don't provide any mechanism for retrieving this information, even though different audio and video devices have a wide range of performance.
6. Service APIs ✨
Sometimes the protocol services in this doc can be turned on transparently by passive configuration mechanisms and "middleware" 🧚 For example, it's conceivable that a UDP implementation could implicitly enable a reliable multicast protocol without the app explicitly interacting with it.
Other times, though, apps need explicit access to these services for flexibility and control 💜 For example, an adaptive app sending to a heterogeneous group of receivers using RTP may need to process RTCP reports from receivers so it can adapt (by throttling its send rate or changing its data encoders, for example) [RTP API]. So there's often a need for service APIs that let an app qualify and initiate service requests and receive event notifications. In Figure 5, the top edge of the box for each service effectively represents its API 🦋
Network APIs generally reflect the protocols they support. Their functionality and argument values are a (varying) subset of protocol message types, header fields and values. Some protocol details and actions may not be exposed in APIs, since many protocol mechanics don't need to be exposed, but others are crucial to efficient and flexible app operation 🫶
A more complete look at the application services described in this document might also identify protocol features that could be mapped to define a (generic) API definition for each service. APIs are often controversial though 😬 Not only are there lots of language differences, but you can also create different APIs by exposing different levels of detail, trading off flexibility against simplicity.
7. Security Considerations 🔒
See section 5.4
8. Acknowledgements 💖
The authors would like to acknowledge and thank the following individuals for their helpful feedback: Ran Canetti, Brian Haberman, Eric A. Hall, Kenneth C. Miller, and Dave Thaler. 🌸
9. References 📚✨
okay so bestie, this is the reading list 🎀 every doc the spec leans on is in here, and I'm going to list them all with their details so nothing gets lost 💅
[AnyCast] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. 🧚
[BeauW] B. Williamson, "Developing IP Multicast Networks, Volume I", (c) 2000 Cisco Press, Indianapolis IN, ISBN 1-57870-077-9. 📘
[BULK] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S. and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001. 🍓
[Deering] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989. 👑
[DIS] Pullen, J., Mytak, M. and C. Bouwens, "Limitations of Internet Protocol Suite for Distributed Simulation in the Large Multicast Environment", RFC 2502, February 1999. 🫶
[E2EQOS] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Speer, M., Braden, R. and B. Davie, "Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000. 🌈
[Estrin] D. Estrin, "Multicast: Enabler and Challenge", Caltech Earthlink Seminar Series, April 22, 1998. 🦋
[Finlayson] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, May 1999. 🔥
[HNRS] Hofman, Nonnenmacher, Rosenberg, Schulzrinne, "A Taxonomy of Feedback for Multicast", June 1999, Work in Progress. 💜
[IGMPv2] Fenner, B., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. 🌸
[IGMPv3] Cain, B., Deering, S., Kouvelas, I. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", Work in Progress. ✨
[IMJ] K. Almeroth and M. Ammar, "The Interactive Multimedia Jukebox (IMJ): A New Paradigm for the On-Demand Delivery of Audio/Video", Proceedings of the Seventh International World Wide Web Conference, Brisbane, AUSTRALIA, April 1998. 🎧
[IRTF] Weinrib, A. and J. Postel, "The IRTF Guidelines and Procedures", BCP 8, RFC 2014, January 1996. 🧭
[Kermode] Kermode, R., "MADCAP Multicast Scope Nesting State Option", RFC 2907, September 2000. 🎀
[LSMA] Bagnall, P., Briscoe, R. and A. Poppitt, "Taxonomy of Communication Requirements for Large-scale Multicast Applications", RFC 2729, December 1999. 💅
[MADDR] Albanna, Z., Almeroth, K., Meyer, D. and M. Schipper, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 3171, August 2001. 🌷
[MASC] Estrin, D., Govindan, R., Handley, M., Kumar, S., Radoslavov, P. and D. Thaler, "The Multicast Address-Set Claim (MASC) Protocol", RFC 2909, September 2000. 🫧
[Maufer] T. Maufer, "Deploying IP Multicast in the Enterprise", (c) 1998 Prentice Hall, Upper Saddle River NJ ISBN 0-13-897687-2. 📗
[Miller] C. K. Miller, "Multicast Networking and Applications", (c) 1999 Addison Wesley Longman, Reading MA ISBN 0-201-30979-3. 📙
[MADCAP] Hanna, S., Patel, B. and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999. 🌟
[MRM] K. Sarac, K. Almeroth, "Supporting Multicast Deployment Efforts: A Survey of Tools for Multicast Monitoring", Journal of High Speed Networking--Special Issue on Management of Multimedia Networking, March 2001 🔍
[MSec] Multicast Security (msec) IETF Working Group charter 🔐
[MZAP] Handley, M., Thaler, D. and R. Kermode, "Multicast-Scope Zone Announcement Protocol (MZAP)", RFC 2776, February 2000. 🎶
[Obraczka] K. Obraczka "Multicast Transport Mechanisms: A Survey and Taxonomy", IEEE Communications Magazine, Vol. 36 No. 1, January 1998. 📰
[Rizzo] L. Rizzo, "Fast Group management in IGMP", HIPPARC 98 workshop, June 1998, UCL London http://www.iet.unipi.it/~luigi/hipparc98.ps.gz 🛼
[RM] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998. 🥰
[RSVP] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. 💖
[RTP API] H. Schulzrinne, et al, "RTP Library API Specification," http://www.cs.columbia.edu/IRT/software/rtplib/rtplib-1.0a1/rtp_api.html 🖥️
[RTP/RTCP] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. 🎬
[SAP] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. 📣
[SDP] Handley, M., and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. 🗓️
[Schneier] B. Schneier, "Why Cryptography Is Harder Than It Looks", December 1996, http://www.counterpane.com/whycrypto.html 🔒
[SlowStart] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997. 🐢
[SLP] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service Location Protocol", RFC 2165, June 1997. 📍
[SSM] Holbrook, H. and B. Cain, "Specific Multicast for IP", Work in Progress. 🦄
10. Authors' Addresses 🫶
Bob Quinn Celox Networks 2 Park Central Drive Southborough, MA 01772
Phone: +1 508 305 7000 EMail: bquinn@celoxnetworks.com
Kevin Almeroth Department of Computer Science University of California Santa Barbara, CA 93106-5110
Phone: +1 805 893 2777 EMail: almeroth@cs.ucsb.edu
11. Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🌈
Funding for the RFC Editor function is currently provided by the Internet Society. 💜
📦 where this page comes from
- ietf: rfc3170 2001-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms