INTERNET-DRAFT Expires 1997 INTERNET-DRAFT
Transport Services Area (TSV) Allison Mankin
INTERNET-DRAFT USC/ISI,
Category: Informational Allyn Romanow
Sun Microsystems,
With the TSV
Area Directorate
November 1996
<draft-mankin-reliable-multicast-00.txt>
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 Drafts.
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:
ftp.is.co.za (Africa)
nic.nordu.net (Europe)
ds.internic.net (US East Coast)
ftp.isi.edu (US West Coast)
munnari.oz.au (Pacific Rim)
Abstract
This memo describes the procedures for reviewing reliable multicast
protocols within the Transport Area (TSV) of the IETF.
They are temporary procedures. The Area Directors expect to
be able to charter one or more WGs for standards track reliable
multicast within a year or 18 months, as the procedures described
herein help the transport and applications communities to identify
and resolve the most serious technical problems with reliable
multicast.
Within today's Internet, important applications exist for
a reliable multicast service. Some examples that are pulling
reliable multicast technology are collaborative workspaces (such
as whiteboard), data and software distribution, and (more speculatively)
web caching protocols. However, the technology for accomplishing
reliable multicast in the Internet is not well-understood at the current
time. Due to the nature of the technical issues, a single commonly
accepted technical solution that solves all the demands for reliable
multicast is infeasible.
A number of reliable multicast protocols have already been
invented to solve a variety of problems for various types
of applications (See Bibliography). 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 or reliable multicast applications.
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 area
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 Internet-Draft is to present
in advance the criteria that will be used by the
TSV ADs in reviewing reliable multicast internet-drafts.
2.0 Introduction
There is a strong application pull for reliable multicast.
Widespread use of the Internet makes the economy of multicast
transport important. Current Internet multicast offers
a best-effort many-to-many delivery
service and offers no guarantees. While many types of
applications lend themselves to the group-delivery model of
multicast, they require some kind of reliability, which is not
offered by IP multicast. Applications wishing to use a
reliable multicast include collaborative applications,
distributed interactive simulations, and distribution services
(e.g. netnews).
To meet the growing demand for reliable multicast, many reliable
multicast protocols have been proposed [Obraczka96, Multicast
Transport Protocols, Reliable Multicast Protocols, Overview of RM].
However, as we discuss in Section 3, the issues raised by reliable
multicast are considerably more complex than those related to
reliable unicast. In particular, reliable multicast protocols can
do damage in the Internet, through causing congestion disasters
if they are used popularly before they are well-engineered. Because
of the complexity of the technical issues, and the abundance of
proposed solutions, we are putting in place more well-defined review
procedures than usual. We compare this action with an IESG action
taken in 1991, RFC 1264 [], 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 advanced
to RFC status.
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 the 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 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 a reliable multicast protocol 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 potential generality of a single applications
interface for that framework.
3.2 Congestion Control
A particular concern for the IETF (and a dominant concern
for the Transport Services Area) is the impact of reliable
multicast traffic on other traffic in the Internet in times of
congestion (more specifically, 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 (as currently indicated by packet drops) by reducing the
load presented on that link. Congestion collapse in today's
Internet is prevented only by the congestion control mechanisms in
TCP [Jacobson88, HostReq89, Stevens96].
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. This is because a single multicast flow can be
distributed along a large, global multicast tree reaching throughout
the entire Internet.
Further, reliable multicast applications have the potential to do
more congestion-related damage than do unreliable multicast
applications. First, 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 control traffic
(e.g., ACKs, NACKs, status messages), and with control traffic
issues in general that may be more complex than for unreliable
multicast traffic.
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 expeditously
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
progressed in the IETF context. Otherwise, the ADs may recommend
that the Internet-Draft be published as an Experimental or Informa-
tional 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 ADs'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
an IRTF 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
will charter appropriate standards track WGs. The criteria for
evaluation of standards track products will be at least as
stringent as those described herein (next section).
5. Technical Criteria for Reliable Multicast
The internet-draft must:
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 senders?
Identify the mechanisms which limit scalabilty 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?
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
the protocol 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. Show that the protocol can use IPSEC or other mechanisms for
secure operation. (General requirement with specific
ramifications for reliable multicast that are outside the
scope of this memo).
Comments on these criteria, additions to them, or refinements
are welcome, and should be sent to the Transport Services
Area (trans-area@isi.edu).
6. References
[Floyd95] Floyd, S., Jacobson, V., Liu, C., McCanne, S., and Zhang, L.,
A Reliable Multicast Framework for Light-weight Sessions and
Application Level Framing. Submitted to IEEE/ACM Transactions on
Networking. An earlier version of this paper appeared in ACM SIGCOMM
95, August 1995, pp. 342-356.
[HostReq89] R. Braden, Ed., Requirements for Internet Hosts --
Communication Layers, RFC 1122, October 1989.
[InetStdProc96] Bradner, S., The Internet Standards Process --
Revision 3, RFC 2026, October 1996.
[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".
[Multicast Transport Protocols], Multicast Transport Protocols
Web Page, URL http://www.roads.lut.ac.uk/DS-Archive/MTP.html.
[Obraczka96] Obraczka, K., Multicast Transport Mechanisms: A Survey,
October 1996.
[Overview of RM] Overview of Reliable Multicast Protocols Web Page,
URL http://gaia.cs.umass.edu/sigcomm_mcast/talk1.html.
[Reliable Multicast Protocols] Reliable Multicast Protocols Web Page,
URL http://www.tascnets.com/mist/doc/mcpCompare.html.
[Stevens96] Stevens, W. R., TCP Slow Start, Congestion Avoidance,
Fast Retransmit, and Fast Recovery Algorithms, Work in Progress,
March 1996.