Movatterモバイル変換

Network Working Group                                          A. MankinRequest for Comments: 2357                                       USC/ISICategory: Informational                                       A. Romanow                                                                     MCI                                                              S. Bradner                                                      Harvard University                                                               V. Paxson                                                                     LBL                                                            With the TSV                                                        Area Directorate                                                               June 1998IETF Criteria for Evaluating Reliable Multicast Transportand Application ProtocolsStatus 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]

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 fullyMankin, 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 inSection 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 replicatedMankin, 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 byRFC 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 moreMankin, 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 inRFC 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, theMankin, 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 inSection 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 limitingMankin, 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 inSection 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 athttp://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 19989. 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.govMankin, et. al.              Informational                     [Page 10]

RFC 2357             Evaluating Reliable Multicast             June 199810.  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]