RFC 2357

IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols

📅 published June 1998, from ietf

1. Part 1 of 3: The RFC 2357 Glow-Up 💖

okay bestie, let's get into it ✨ This is RFC 2357, titled "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols" 🦋. It's an Informational doc, so it's sharing knowledge and not setting a standard 🌸. It came out in June 1998, and it was written by A. Mankin (USC/ISI), A. Romanow (MCI), S. Bradner (Harvard University), and V. Paxson (LBL), with the TSV Area Directorate 💅. It doesn't obsolete or update any other RFCs, so it's a fresh start 🎀.

Status of this Memo 🧚

This memo is here to give info to the Internet community. It is not an Internet standard of any kind, and it can be shared freely 🍓.

Copyright (C) The Internet Society (1998). All Rights Reserved. 🫶

Abstract 🌈

Okay so the whole point of this memo is spelling out how the TSV area reviews reliable multicast protocols, plus the criteria and processes for getting them published as RFCs as Internet-Drafts 🔥. Reliable multicast is literally blowing up right now. Collaborative whiteboards, data and software distribution, and (more speculatively) web caching protocols are all driving the demand 👑. Because the technical issues are so messy, one single, commonly accepted solution that covers every reliable multicast need is probably not happening 💀 [RMMinutes 1997].

A bunch of reliable multicast protocols already exist for all sorts of apps, and [Floyd97] describes one that's widely deployed ✨. So the big questions are how these protocols should be handled inside the IETF, and how the IETF can steer reliable multicast in a direction that's actually good for the whole Internet 🦋. The TSV Area Directors and their Directorate came up with a set of review procedures to answer exactly that, along with criteria and processes for publishing reliable multicast transport protocol Internet-Drafts as RFCs 💅.

1.0 Background on IETF Processes and Procedures 🎀

In the IETF, each area is run by its Area Directors (ADs), and they're the ones with the authority to charter working groups (WGs) 👑.

ADs also review individually submitted Internet-Drafts (not the ones from WGs) about work in their area before they become RFCs. That can be Experimental, Informational, or, in rare cases, Standards Track 🌸. The review follows the Internet Standards Process in RFC 2026 [InetStdProc96] 🧚.

This document lays out the criteria the TSV ADs will use to review reliable multicast Internet-Drafts for any kind of RFC publication 🍓.

For I-Ds going for Standards Track, these criteria MUST be met, or the ADs will decline to support publication, and that alone is enough to stop it from being published 💀. For I-Ds submitted as Experimental or Informational, these criteria MUST be met too. If they aren't, the ADs will, at a minimum, RECOMMEND publishing the I-D with an IESG note saying the protocol doesn't comply with these criteria 🙈.

2.0 Introduction 💖

There is a seriously strong demand for reliable multicast 🔥. The Internet is so widespread that the economics of multicast transport look really attractive 🫶. Right now, the Internet's multicast model gives you best-effort many-to-many delivery with no guarantees at all 😭. One-to-many and few-to-few services might matter more later on 🦋. Reliable multicast transports add delivery guarantees to the group-delivery model of multicast. Those guarantees aren't necessarily the same as reliable unicast TCP, though 🌈. A panel of major Internet users at the 38th IETF named reliable bulk transfer multicast as one of their most critical requirements [DiffServBOF97] 👑. Apps that could use reliable bulk multicast include collaborative tools, distributed virtual reality, and software upgrade services ✨.

There's a huge pile of reliable multicast protocol proposals right now 🧚. A few got published as RFCs before anyone fully understood how much congestion reliable multicast could cause, and those should be deprecated [DeprRFCs] 💀. Two surveys of other publications are [DiotCrow97] and [Obraczka98] 🎀.

As Section 3 explains, reliable multicast is way more complicated than reliable unicast 🙈. Right now, reliable multicast protocols could cause serious damage through congestion disasters if they're widely used without adequate congestion control 😭.

Because the technical issues are complicated and there are so many proposed solutions, the review procedures are more explicit than usual 💅. This is similar to an IESG action from 1991, RFC 1264 [Routing91], when people hadn't really got the hang of standard Internet dynamic routing protocols yet. Extra review was needed to make sure those protocols would be effective, correct, and robust 🌸.

Section 3 goes into the specific challenges reliable multicast poses 🦋. Section 4 covers the process for considering reliable multicast solutions 🧚. Section 5 lists the extra requirements that proposals need to meet before they can be published as Standards Track RFCs 🔥.

3.0 Issues in Reliable Multicast 🌈

Two things make standardizing reliable multicast especially hard 😭. First, what "reliability" means changes depending on the app 💖. Second, if people aren't careful, reliable multicast protocols can seriously threaten how today's global Internet works 💀. This section digs into both 👑.

3.1 One or Many Reliable Multicast Protocols or Frameworks? 🎀

Reliable unicast is simpler: one transport protocol (TCP) handles reliable delivery for a wide range of apps 🌸. For unicast transport, the requirements for reliable, sequenced data delivery are pretty general. TCP is the main transport protocol for reliable unicast, and it's a mature protocol with delivery semantics that suit lots of different apps ✨.

Multicast is a whole different vibe 🦋. Reliable multicast doesn't necessarily fit into one app interface or one set of underlying mechanisms 🧚. Different multicast apps have wildly different reliability needs 💅. Some apps need message delivery to follow a total ordering, and others don't 🙈. Some have many or all members sending data, while others have just one data source 🍓. Some apps have replicated data, like an n-redundant file store, so several members can send a data item. For others, everything comes from one source 🫶. Some apps are limited to small, fixed-membership groups, while others have to scale up to thousands or tens of thousands of members (or possibly more) 🔥. Some apps have strict delay requirements, and others don't 💜. Some apps, like file transfer, need high bandwidth. Others, like interactive collaboration tools, tend to be bursty but use low bandwidth overall 🌈. Some apps will sometimes trade less than complete reliability for faster delivery 👑. All of these requirements affect the design of reliable multicast protocols, each in its own way ✨.

Even when an app's reliable multicast requirements are well understood, there are still lots of open questions about the mechanisms underneath 🧚. One key question is how robust those mechanisms are as the number of senders or the group membership grows 💀.

The IETF's challenge is getting the right match between app requirements and reliable multicast mechanisms 🎀. Everyone generally agrees that one single reliable multicast protocol or framework won't meet the needs of every Internet app 🌸. But there's less agreement on how app-specific requirements relate to the more generic underlying reliable multicast protocols or mechanisms 🦋. There are also open questions about how an app should integrate with an underlying reliable multicast framework, and how general a single application interface for that framework could be 💅.

3.2 Congestion Control ✨

okay so this is where the IETF gets SUPER protective 🛡️ The big worry is reliable multicast traffic messing with everyone else's traffic when the internet is congested, especially the TCP traffic it's competing with 😬 The whole internet works because best-effort traffic backs off when a link gets congested (right now that signal is packet drops) and sends less into the network 💅 Congestion collapse is only prevented today by the congestion control mechanisms in TCP, standardized by RFC 2001 [CongAvoid97, Jacobson88] 🫶

There are a bunch of reasons to be extra careful about reliable multicast. Multicast apps in general can do more congestion damage than unicast apps, and one reason is that a single multicast flow can get distributed along a huge global multicast tree that reaches across the entire Internet 🌍

Unreliable multicast stuff like audio and video usually has a human on the receiving end, and people typically unsubscribe from the group if congestion gets so heavy that the stream is unintelligible 🎧 Reliable multicast apps like group file transfer, on the other hand, are likely to be between computers, with no humans watching the congestion levels 🤖

Reliable apps also don't have the natural time limits that current unreliable multicast apps have ⏳ For a file transfer, the transfer might keep going until all the data reaches all of the intended receivers, so one flow could last a potentially unlimited duration. On top of that, reliable multicast has to deal with a potential explosion of complex control traffic patterns (e.g., ACKs, NACKs, status messages) 😵‍💫 Designing congestion control for reliable multicast with large multicast groups is currently an area of active research 🔬

So the challenge for the IETF is to encourage research and implementations of reliable multicast, and to meet applications' needs for reliable multicast as expeditiously as possible 🚀 At the same time, the IETF has to protect the Internet from the congestion disaster or collapse that could result from widespread use of applications with inappropriate reliable multicast mechanisms. Because of the setbacks and costs that could come from widespread deployment of reliable multicast with inadequate congestion control, the IETF MUST exercise care in standardizing a reliable multicast protocol that might see widespread use 👑

That's also why the careful review and cautious acceptance procedures for proposals submitted as Internet-Drafts exist. They reflect our concern about meeting these challenges 💜

4. IETF Process for Review and Publication of Reliable Multicast Protocol Specifications 📜

In the general case of individually submitted Internet-Drafts (proposals not produced by an IETF WG), the process for publishing them as some type of RFC is described in RFC 2026 (4.2.3) [InetStdProc96]. That says if the submitted Internet-Draft is closely related to work being done or expected to be done in the IETF, the ADs MAY recommend that the document be brought within the IETF and progressed in the IETF context. Otherwise, the ADs MAY recommend that the Internet-Draft be published as an Experimental or Informational RFC, with or without an IESG annotation of its relationship to the IETF context 🌸

The procedure for Reliable Multicast proposal publication will have Experimental as its default RFC status, as long as the technical criteria listed in Section 5 are deemed to be fulfilled ✨ Both the criteria and the procedure reflect the AD's technical assessment of where reliable multicast technology currently stands. It does NOT reflect where the proposals come from, and the IETF expects them to come equally from commercial vendors with initial products and from researchers 🧚

Work on developing and engineering protocols that might eventually meet the review criteria MAY take place either in the IRTF Reliable Multicast Research Group (http://www.irtf.org) or in a focused short IETF WG with an Experimental product 🦋

Once reliable multicast technology has matured enough to be considered for standardization within the IETF, the TSV Area MAY charter appropriate working groups to develop standards track documents 🎀 The criteria for evaluating standards track technology will be at least as stringent as the ones described here (next section) 💅

5. Technical Criteria for Reliable Multicast 🔍

The Internet-Draft MUST (in itself or a companion draft):

  • a. Analyze the behavior of the protocol. The vulnerabilities and performance problems MUST be shown through analysis. Especially, the protocol behavior MUST be explained in detail with respect to scalability, congestion control, error recovery, and robustness 🧠

For example, the following questions SHOULD be answered:

  • How scalable is the protocol to the number of senders or receivers in a group, the number of groups, and wide dispersion of group members?
  • Identify the mechanisms which limit scalability and estimate those limits.
  • How does the protocol protect the Internet from congestion? How well does it perform? When does it fail? Under what circumstances will the protocol fail to perform the functions needed by the applications it serves?
  • Is there a congestion control mechanism? How well does it perform? When does it fail? Note that congestion control mechanisms that operate on the network more aggressively than TCP will face a great burden of proof that they don't threaten network stability.
  • b. Include a description of trials and/or simulations which support the development of the protocol and the answers to the above questions 🧪
  • c. Include an analysis of whether the protocol has congestion avoidance mechanisms strong enough to cope with deployment in the Global Internet, and if not, clearly document the circumstances in which congestion harm can occur. How are these circumstances to be prevented? 🚨
  • d. Include a description of any mechanisms which contain the traffic within limited network environments. If the analysis in a or c shows that the protocol has potential to damage the Internet, then the analysis MUST include a discussion of ways to limit the scope or otherwise contain the protocol. We recognize that the confinement of Internet applications is an open research area 🔒
  • e. Reliable multicast protocols MUST include an analysis of how they address a number of security and privacy concerns. If the protocol can be used in different modes of secure operation, then each mode MUST be analyzed 🕵️‍♀️

The analysis MUST document which of the various parties (senders, routers, more generally data forwarders, receivers, and retransmission sources) MUST be trusted in order to ensure secure operation and privacy of the transmitted data, to what degree, and why. (One issue to address here is "man-in-the-middle" attacks 👀)

To what degree can data be manipulated so that at least a subset of the receivers receive different copies? Does the protocol allow a group of receivers to determine whether they all received the same data?

What limitations are placed on the retransmission mechanism to prevent it from being abused to flood network links with excessive traffic? Which parties MUST be trusted to ensure this, to what degree, and why? The presumption will be that either a congestion control mechanism will inherently limit the volume of retransmission traffic, and that this limiting influence is robust under concerted attack; or that retransmission requests will be signed in a cryptographically strong manner so that abuses of the mechanism can be traced back to their source. Protocols that do not provide either of these forms of protection face a great burden of proof that they don't threaten network stability.

What sort of key management does the protocol require, and provide for? 🔑

6. Security Considerations 🔐

This memo specifies in Section 5.e. that reliable multicast Internet-Drafts reviewed by the Transport Area Directors MUST explicitly explore the security aspects of the proposed design. This is a big deal, bestie, so don't skip it 💀

7. Acknowledgments 🫶

Sally Floyd, Steve McCanne, Mark Handley, Steve Bellovin and Mike Reiter gave especially helpful comments on drafts of this document. Iconic squad 👑

8. References 📚

  • [RMMinutes 1997] Minutes the Second Reliable Multicast Research Group Meeting. September 1997. http://www.east.isi.edu/rm
  • [Floyd97] Floyd, S., Jacobson, V., Liu, C., McCanne, S., and Zhang, L., A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing. IEEE/ACM Transactions on Networking, December 1997. An online version of the paper is at http://ee.lbl.gov/floyd/srm-paper.html.
  • [InetStdProc96] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996.
  • [DiffServBOF97] [6] http://www.ietf.org/proceedings/97apr - Transport Area - FDDIFS BOF, April 1997.
  • [DeprRFCs] Freier, A., "Multicast Transport Protocol", RFC 1301, February 1992. and Braudes, R., and S. Zabele, "Requirements for Multicast Protocols", RFC 1458, May 1993.
  • [DiotCrow97] Diot, C., Crowcroft, J., Multicast Transport Survey. Journal of Selected Areas in Communications, 1997.
  • [Obraczka98] Obraczka, K., Multicast Transport Mechanisms: A Survey and Taxonomy. To appear in IEEE Communications, 1998.
  • [Routing91] Hinden, R., and Internet Engineering Task Force, "Internet Routing Protocol Standardization Criteria", RFC 1264, October 1991.
  • [CongAvoid97] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997.
  • [Jacobson 1988] Jacobson, V., Congestion Avoidance and Control, Proceedings of SIGCOMM '88, August 1988, pp. 314-329. An updated version of this paper is available at ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.

9. Authors' Addresses 🌷

Allison Mankin - Past TSV Area Director
USC/ISI East
4350 N. Fairfax Dr., Suite 620
Arlington VA 22203
USA

Phone: 703 812 3706
EMail: mankin@east.isi.edu
Allyn Romanow - Past TSV Area Director
MCI Corporation
2560 North First Street
San Jose, CA 9531
USA

Phone: 408 922 7143
EMail: allyn@mci.net
Scott Bradner - TSV Co-Area Director
Harvard University
1350 Mass. Ave., Rm. 876
Cambridge MA 02138
USA

Phone: 617 495 3864
EMail: sob@harvard.edu
Vern Paxson - TSV Co-Area Director
MS 50B/2239
Lawrence Berkeley National Laboratory
University of California
Berkeley, CA 94720
USA

Phone: 510-486-7504
EMail: vern@ee.lbl.gov

Copyright (C) The Internet Society (1998). All Rights Reserved. 🎀

Okay bestie, so this doc and any translations of it can be copied and handed out to literally anyone 🫶. People can also make derivative works that comment on or explain it, or help people actually implement it 🧚. Those works can be prepared, copied, published and distributed, in whole or in part, with no restrictions of any kind 🔥. The one condition is that the copyright notice and this paragraph have to be on every single copy and derivative work 💜.

But the document itself? It may not be modified in any way 🙈. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. The only exceptions are if you need to change it to develop Internet standards, in which case the copyright procedures in the Internet Standards process must be followed 📜, or if you need to translate it into a language other than English 🌍.

The limited permissions above are perpetual, and the Internet Society or its successors or assigns will never revoke them 👑. That's a forever promise, no cap ✨.

⚠️ Heads up: the document and the information in it are provided "AS IS", and the vibe is pretty clear: no guarantees 💀.

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. 🦋

📦 where this page comes from