Network Working Group                                     Allison Mankin
INTERNET-DRAFT                                                   USC/ISI
                                                           Allyn Romanow
                                                           Scott Bradner
                                                      Harvard University
                                                             Vern Paxson
                                                            With the TSV
                                                        Area Directorate
                                                                May 1998

       IETF Criteria for Evaluating Reliable Multicast Transport
                       and Application Protocols


Status of this Memo
   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups. Note that other groups may also distribute
   working documents as Internet

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the internet-drafts Shadow
   Directories on: (Africa) (Europe) (US East Coast) (US West Coast) (Pacific Rim)

   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

   A number of reliable multicast protocols have already been developed

Mankin/Romanow/Bradner/Paxson                                   [Page 1]

Internet-Draft        Evaluating Reliable Multicast             May 1998

   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?

   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 Standards Track RFCs.

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.
   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
   appreciated, and these should be deprecated [DeprRFCs].  Two surveys

Mankin/Romanow/Bradner/Paxson                                   [Page 2]

Internet-Draft        Evaluating Reliable Multicast             May 1998

   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/Romanow/Bradner/Paxson                                   [Page 3]

Internet-Draft        Evaluating Reliable Multicast             May 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.  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

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
   congestion-related damage to the Internet than do unicast
   applications.  One factor is that a single multicast flow can be

Mankin/Romanow/Bradner/Paxson                                   [Page 4]

Internet-Draft        Evaluating Reliable Multicast             May 1998

   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
   ADs may recommend that the document be brought within the IETF and

Mankin/Romanow/Bradner/Paxson                                   [Page 5]

Internet-Draft        Evaluating Reliable Multicast             May 1998

   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 ( 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

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 users in a group,
         number of groups, wide dispersion of group members? If
         appropriate, how scalable is the protocol to the number of

         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/Romanow/Bradner/Paxson                                   [Page 6]

Internet-Draft        Evaluating Reliable Multicast             May 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

   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.  It is likely that some
      answers to a.  and c. will mean that such mechanisms are required.
      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
         influence is robust under concerted attack; or that

Mankin/Romanow/Bradner/Paxson                                   [Page 7]

Internet-Draft        Evaluating Reliable Multicast             May 1998

         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.

   [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

   [InetStdProc96] Bradner, S., The Internet Standards Process --
   Revision 3, RFC 2026, October 1996.

   [DiffServBOF97]  [6] -
   Transport Area - FDDIFS BOF, April 1997.

   [DeprRFCs].  Freier, A. Multicast Transport Protocol, RFC 1301,
   February 1992. and  Braudes, R., Zabele, S., 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/Romanow/Bradner/Paxson                                   [Page 8]

Internet-Draft        Evaluating Reliable Multicast             May 1998

   [Routing91] Hinden, R. M., Internet Engineering Task Force internet
   routing protocol standardization criteria, RFC 1264, October 1991

   [CongAvoid97] Stevens, W. R., 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

9. Authors Addresses

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

   Allyn Romanow - Past TSV Area Director
   MCI Corporation
   2560 North First Street
   San Jose, CA 9531
   408 922 7143

   Scott Bradner - TSV Co-Area Director
   Harvard University
   1350 Mass. Ave., Rm 876
   Cambridge MA 02138
   617 495 3864

   Vern Paxson - TSV Co-Area Director
   MS 50B/2239
   Lawrence Berkeley National Laboratory
   University of California
   Berkeley, CA 94720

Mankin/Romanow/Bradner/Paxson                                   [Page 9]

Internet-Draft        Evaluating Reliable Multicast             May 1998

Mankin/Romanow/Bradner/Paxson                                  [Page 10]