Network Working Group A. Mankin
`Request for Comments: 2357 USC/ISI
`Category: Informational A. Romanow
` MCI
` S. Bradner
` Harvard University
` V. Paxson
` LBL
` With the TSV
` Area Directorate
` June 1998
`
` IETF Criteria for Evaluating Reliable Multicast Transport
` and Application Protocols
`
`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 (1998). All Rights Reserved.
`
`Abstract
`
` This memo describes the procedures and criteria for reviewing
` reliable multicast protocols within the Transport Area (TSV) of the
` IETF. Within today’s Internet, important applications exist for a
` reliable multicast service. Some examples that are driving reliable
` multicast technology are collaborative workspaces (such as
` whiteboard), data and software distribution, and (more speculatively)
` web caching protocols. Due to the nature of the technical issues, a
` single commonly accepted technical solution that solves all the
` demands for reliable multicast is likely to be infeasible [RMMinutes
` 1997].
`
` A number of reliable multicast protocols have already been developed
` to solve a variety of problems for various types of applications.
` [Floyd97] describes one widely deployed example. How should these
` protocols be treated within the IETF and how should the IETF guide
` the development of reliable multicast in a direction beneficial for
` the general Internet?
`
`Mankin, et. al. Informational [Page 1]
`
`Unified Patents Exhibit 1016
`
`

`

`
`RFC 2357 Evaluating Reliable Multicast June 1998
`
` The TSV Area Directors and their Directorate have outlined a set of
` review procedures that address these questions and set criteria and
` processes for the publication as RFCs of Internet-Drafts on reliable
` multicast transport protocols.
`
`1.0 Background on IETF Processes and Procedures
`
` In the IETF, work in an area is directed and managed by the Area
` Directors (ADs), who have authority over the chartering of working
` groups (WGs).
`
` In addition, ADs review individually submitted (not by WGs)
` Internet-Drafts about work that is relevant to their areas prior to
` publication as RFCs (Experimental, Informational or, in rare cases,
` Standards Track). The review is done according to the guidelines set
` out in the Internet Standards Process, RFC 2026 [InetStdProc96].
`
` The purpose of this document is to present the criteria that will be
` used by the TSV ADs in reviewing reliable multicast Internet-Drafts
` for any form of RFC publication.
`
` For I-Ds submitted for Standards Track publication, these criteria
` must be met or else the ADs will decline to support publication of
` the document, which suffices to prevent publication. For I-Ds
` submitted as Experimental or Informational, these criteria must be
` met or else, at a minimum, the Ads will recommend publishing the I-D
` with an IESG note prepended stating that the protocol fails to comply
` with these criteria.
`
`2.0 Introduction
`
` There is a strong application demand for reliable multicast.
` Widespread use of the Internet makes the economy of multicast
` transport attractive. The current Internet multicast model offers
` best-effort many-to-many delivery service and offers no guarantees.
` One-to-many and few-to-few services may become more important in the
` future. Reliable multicast transports add delivery guarantees, not
` necessarily like those of reliable unicast TCP, to the group-delivery
` model of multicast. A panel of some major users of the Internet,
` convened at the 38th IETF, articulated reliable bulk transfer
` multicast as one of their most critical requirements [DiffServBOF97].
` Examples of applications that could use reliable bulk multicast
` transfer include collaborative tools, distributed virtual reality,
` and software upgrade services.
`
` To meet the growing demand for reliable multicast, there is a large
` number of protocol proposals. A few were published as RFCs before
` the impact of congestion from reliable multicast was fully
`
`Mankin, et. al. Informational [Page 2]
`
`

`

`
`RFC 2357 Evaluating Reliable Multicast June 1998
`
` appreciated, and these should be deprecated [DeprRFCs]. Two surveys
` of other publications are [DiotCrow97], [Obraczka98].
`
` As we discuss in Section 3, the issues raised by reliable multicast
` are considerably more complex than those related to reliable unicast.
` In particular, in today’s Internet, reliable multicast protocols
` could do great damage through causing congestion disasters if they
` are widely used and do not provide adequate congestion control.
`
` Because of the complexity of the technical issues, and the abundance
` of proposed solutions, we are putting in place review procedures that
` are more explicit than usual. We compare this action with an IESG
` action taken in 1991, RFC 1264 [Routing91], when community experience
` with standard Internet dynamic routing protocols was still limited,
` and extra review was deemed necessary to assure that the protocols
` introduced would be effective, correct and robust.
`
` Section 3 describes in detail the nature of the particular challenges
` posed by reliable multicast. Section 4 describes the process for
` considering reliable multicast solutions. Section 5 details the
` additional requirements that need to be met by proposals to be
` published as Standards Track RFCs.
`
`3.0 Issues in Reliable Multicast
`
` Two aspects of reliable multicast make standardization particularly
` challenging. First, the meaning of reliability varies in the context
` of different applications. Secondly, if special care is not taken,
` reliable multicast protocols can cause a particular threat to the
` operation of today’s global Internet. These issues are discussed in
` detail in this section.
`
`3.1 One or Many Reliable Multicast Protocols or Frameworks?
`
` Unlike reliable unicast, where a single transport protocol (TCP) is
` currently used to meet the reliable delivery needs of a wide range of
` applications, reliable multicast does not necessarily lend itself to
` a single application interface or to a single underlying set of
` mechanisms. For unicast transport, the requirements for reliable,
` sequenced data delivery are fairly general. TCP, the primary
` transport protocol for reliable unicast, is a mature protocol with
` delivery semantics that suit a wide range of applications.
`
` In contrast, different multicast applications have widely different
` requirements for reliability. For example, some applications require
` that message delivery obey a total ordering while others do not.
` Some applications have many or all the members sending data while
` others have only one data source. Some applications have replicated
`
`Mankin, et. al. Informational [Page 3]
`
`

`

`
`RFC 2357 Evaluating Reliable Multicast June 1998
`
` data, for example in an n-redundant file store, so that several
` members are capable of transmitting a data item, while for others all
` data originates at a single source. Some applications are restricted
` to small fixed-membership multicast groups, while other applications
` need to scale dynamically to thousands or tens of thousands of
` members (or possibly more). Some applications have stringent delay
` requirements, while others do not. Some applications such as file-
` transfer are high-bandwidth, while other applications such as
` interactive collaboration tools are more likely to be bursty but use
` low bandwidth overall. Some applications will sometimes trade off
` less than complete reliability for more timely delivery. These
` requirements each impact the design of reliable multicast protocols
` in a different way.
`
` In addition, even for a specific application where the application’s
` requirements for reliable multicast are well understood, there are
` many open questions about the underlying mechanisms for providing
` reliable multicast. A key question concerns the robustness of the
` underlying reliable multicast mechanisms as the number of senders or
` the membership of the multicast group grows.
`
` One challenge to the IETF is to end up with the right match between
` applications’ requirements and reliable multicast mechanisms. While
` there is general agreement that a single reliable multicast protocol
` or framework is not likely to meet the needs of all Internet
` applications, there is less understanding and agreement about the
` exact relationship between application-specific requirements and more
` generic underlying reliable mutlicast protocols or mechanisms. There
` are also open questions about the appropriate integration between an
` application and an underlying reliable multicast framework, and the
` potential generality of a single applications interface for that
` framework.
`
`3.2 Congestion Control
`
` A particular concern for the IETF is the impact of reliable multicast
` traffic on other traffic in the Internet in times of congestion, in
` particular the effect of reliable multicast traffic on competing TCP
` traffic. The success of the Internet relies on the fact that best-
` effort traffic responds to congestion on a link (currently as
` indicated by packet drops) by reducing the load presented to the
` network. Congestion collapse in today’s Internet is prevented only
` by the congestion control mechanisms in TCP, standardized by RFC 2001
` [CongAvoid97, Jacobson88].
`
` There are a number of reasons to be particularly attentive to the
` congestion-related issues raised by reliable multicast proposals.
` Multicast applications in general have the potential to do more
`
`Mankin, et. al. Informational [Page 4]
`
`

`

`
`RFC 2357 Evaluating Reliable Multicast June 1998
`
` congestion-related damage to the Internet than do unicast
` applications. One factor is that a single multicast flow can be
` distributed along a large, global multicast tree reaching throughout
` the entire Internet.
`
` Unreliable multicast applications such as audio and video are, at the
` moment, usually accompanied by a person at the receiving end, and
` people typically unsubscribe from a multicast group if congestion is
` so heavy that the audio or video stream is unintelligible. Reliable
` multicast applications such as group file transfer applications, on
` the other hand, are likely to be between computers, with no humans in
` attendance monitoring congestion levels.
`
` In addition, reliable multicast applications do not necessarily have
` the natural time limitations typical of current unreliable multicast
` applications. For a file transfer application, for example, the data
` transfer might continue until all of the data is transferred to all
` of the intended receivers, resulting in a potentially-unlimited
` duration for an individual flow. Reliable multicast applications
` also have to contend with a potential explosion of complex patterns
` of control traffic (e.g., ACKs, NACKs, status messages). The design
` of congestion control mechanisms for reliable multicast for large
` multicast groups is currently an area of active research.
`
` The challenge to the IETF is to encourage research and
` implementations of reliable multicast, and to enable the needs of
` applications for reliable multicast to be met as expeditiously as
` possible, while at the same time protecting the Internet from the
` congestion disaster or collapse that could result from the widespread
` use of applications with inappropriate reliable multicast mechanisms.
` Because of the setbacks and costs that could result from the
` widespread deployment of reliable multicast with inadequate
` congestion control, the IETF must exercise care in the
` standardization of a reliable multicast protocol that might see
` widespread use.
`
` The careful review and cautious acceptance procedures for proposals
` submitted as Internet-Drafts reflects our concern to meet the
` challenges described here.
`
`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 of publication as
` some type of RFC is described in RFC 2026 (4.2.3) [InetStdProc96].
` This specifies that if the submitted Internet-Draft is closely
` related to work being done or expected to be done in the IETF, the
`
`Mankin, et. al. Informational [Page 5]
`
`

`

`
`RFC 2357 Evaluating Reliable Multicast June 1998
`
` 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
` as its default RFC status Experimental, when 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 the current
` state of reliable multicast technology. It does not reflect the
` origins of the proposals, which we expect will be equally from
` commercial vendors with initial products and from researchers.
`
` Work on the development and engineering of protocols that may
` eventually meet the review criteria could take place either in the
` IRTF Reliable Multicast Research Group (http://www.irtf.org) or a
` focused short IETF WG with an Experimental product.
`
` When the work in 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 evaluation of standards track technology
` will be at least as stringent as those described herein (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?
`
`Mankin, et. al. Informational [Page 6]
`
`

`

`
`RFC 2357 Evaluating Reliable Multicast June 1998
`
` 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,
` 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 are "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, and 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
`
`Mankin, et. al. Informational [Page 7]
`
`

`

`
`RFC 2357 Evaluating Reliable Multicast June 1998
`
` 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.
`
`7. Acknowledgments
`
` Sally Floyd, Steve McCanne, Mark Handley, Steve Bellovin and Mike
` Reiter gave especially helpful comments on drafts of this document.
`
`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.
`
`Mankin, et. al. Informational [Page 8]
`
`

`

`
`RFC 2357 Evaluating Reliable Multicast June 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".
`
`Mankin, et. al. Informational [Page 9]
`
`

`

`
`RFC 2357 Evaluating Reliable Multicast June 1998
`
`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
`
`Mankin, et. al. Informational [Page 10]
`
`

`

`
`RFC 2357 Evaluating Reliable Multicast June 1998
`
`10. Full Copyright Statement
`
` Copyright (C) The Internet Society (1998). 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.
`
`Mankin, et. al. Informational [Page 11]
`
`