As per Relevance of the word reliable, we have this rfc below:
Network Working Group A.
Request for Comments: 2357 USC/
Category: Informational A.
S.
Harvard
V.
With the
Area
June 1998
IETF Criteria for Evaluating Reliable Multicast
and Application
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This memo describes the procedures and criteria for
reliable multicast protocols within the Transport Area (TSV) of
IETF. Within today's Internet, important applications exist for
reliable multicast service. Some examples that are driving
multicast technology are collaborative workspaces (such
whiteboard), data and software distribution, and (more speculatively
web caching protocols. Due to the nature of the technical issues,
single commonly accepted technical solution that solves all
demands for reliable multicast is likely to be infeasible [
1997].
A number of reliable multicast protocols have already been
to solve a variety of problems for various types of applications
[Floyd97] describes one widely deployed example. How should
protocols be treated within the IETF and how should the IETF
the development of reliable multicast in a direction beneficial
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
review procedures that address these questions and set criteria
processes for the publication as RFCs of Internet-Drafts on
multicast transport protocols
1.0 Background on IETF Processes and
In the IETF, work in an area is directed and managed by the
Directors (ADs), who have authority over the chartering of
groups (WGs).
In addition, ADs review individually submitted (not by WGs
Internet-Drafts about work that is relevant to their areas prior
publication as RFCs (Experimental, Informational or, in rare cases
Standards Track). The review is done according to the guidelines
out in the Internet Standards Process, RFC 2026 [InetStdProc96].
The purpose of this document is to present the criteria that will
used by the TSV ADs in reviewing reliable multicast Internet-
for any form of RFC publication
For I-Ds submitted for Standards Track publication, these
must be met or else the ADs will decline to support publication
the document, which suffices to prevent publication. For I-
submitted as Experimental or Informational, these criteria must
met or else, at a minimum, the Ads will recommend publishing the I-
with an IESG note prepended stating that the protocol fails to
with these criteria
2.0
There is a strong application demand for reliable multicast
Widespread use of the Internet makes the economy of
transport attractive. The current Internet multicast model
best-effort many-to-many delivery service and offers no guarantees
One-to-many and few-to-few services may become more important in
future. Reliable multicast transports add delivery guarantees,
necessarily like those of reliable unicast TCP, to the group-
model of multicast. A panel of some major users of the Internet
convened at the 38th IETF, articulated reliable bulk
multicast as one of their most critical requirements [DiffServBOF97].
Examples of applications that could use reliable bulk
transfer include collaborative tools, distributed virtual reality
and software upgrade services
To meet the growing demand for reliable multicast, there is a
number of protocol proposals. A few were published as RFCs
the impact of congestion from reliable multicast was
Mankin, et. al. Informational [Page 2]
RFC 2357 Evaluating Reliable Multicast June 1998
appreciated, and these should be deprecated [DeprRFCs]. Two
of other publications are [DiotCrow97], [Obraczka98].
As we discuss in Section 3, the issues raised by reliable
are considerably more complex than those related to reliable unicast
In particular, in today's Internet, reliable multicast
could do great damage through causing congestion disasters if
are widely used and do not provide adequate congestion control
Because of the complexity of the technical issues, and the
of proposed solutions, we are putting in place review procedures
are more explicit than usual. We compare this action with an
action taken in 1991, RFC 1264 [Routing91], when community
with standard Internet dynamic routing protocols was still limited
and extra review was deemed necessary to assure that the
introduced would be effective, correct and robust
Section 3 describes in detail the nature of the particular
posed by reliable multicast. Section 4 describes the process
considering reliable multicast solutions. Section 5 details
additional requirements that need to be met by proposals to
published as Standards Track RFCs
3.0 Issues in Reliable
Two aspects of reliable multicast make standardization
challenging. First, the meaning of reliability varies in the
of different applications. Secondly, if special care is not taken
reliable multicast protocols can cause a particular threat to
operation of today's global Internet. These issues are discussed
detail in this section
3.1 One or Many Reliable Multicast Protocols or Frameworks
Unlike reliable unicast, where a single transport protocol (TCP)
currently used to meet the reliable delivery needs of a wide range
applications, reliable multicast does not necessarily lend itself
a single application interface or to a single underlying set
mechanisms. For unicast transport, the requirements for reliable
sequenced data delivery are fairly general. TCP, the
transport protocol for reliable unicast, is a mature protocol
delivery semantics that suit a wide range of applications
In contrast, different multicast applications have widely
requirements for reliability. For example, some applications
that message delivery obey a total ordering while others do not
Some applications have many or all the members sending data
others have only one data source. Some applications have
Mankin, et. al. Informational [Page 3]
RFC 2357 Evaluating Reliable Multicast June 1998
data, for example in an n-redundant file store, so that
members are capable of transmitting a data item, while for others
data originates at a single source. Some applications are
to small fixed-membership multicast groups, while other
need to scale dynamically to thousands or tens of thousands
members (or possibly more). Some applications have stringent
requirements, while others do not. Some applications such as file
transfer are high-bandwidth, while other applications such
interactive collaboration tools are more likely to be bursty but
low bandwidth overall. Some applications will sometimes trade
less than complete reliability for more timely delivery.
requirements each impact the design of reliable multicast
in a different way
In addition, even for a specific application where the application'
requirements for reliable multicast are well understood, there
many open questions about the underlying mechanisms for
reliable multicast. A key question concerns the robustness of
underlying reliable multicast mechanisms as the number of senders
the membership of the multicast group grows
One challenge to the IETF is to end up with the right match
applications' requirements and reliable multicast mechanisms.
there is general agreement that a single reliable multicast
or framework is not likely to meet the needs of all
applications, there is less understanding and agreement about
exact relationship between application-specific requirements and
generic underlying reliable mutlicast protocols or mechanisms.
are also open questions about the appropriate integration between
application and an underlying reliable multicast framework, and
potential generality of a single applications interface for
framework
3.2 Congestion
A particular concern for the IETF is the impact of reliable
traffic on other traffic in the Internet in times of congestion,
particular the effect of reliable multicast traffic on competing
traffic. The success of the Internet relies on the fact that best
effort traffic responds to congestion on a link (currently
indicated by packet drops) by reducing the load presented to
network. Congestion collapse in today's Internet is prevented
by the congestion control mechanisms in TCP, standardized by RFC 2001
[CongAvoid97, Jacobson88].
There are a number of reasons to be particularly attentive to
congestion-related issues raised by reliable multicast proposals
Multicast applications in general have the potential to do
Mankin, et. al. Informational [Page 4]
RFC 2357 Evaluating Reliable Multicast June 1998
congestion-related damage to the Internet than do
applications. One factor is that a single multicast flow can
distributed along a large, global multicast tree reaching
the entire Internet
Unreliable multicast applications such as audio and video are, at
moment, usually accompanied by a person at the receiving end,
people typically unsubscribe from a multicast group if congestion
so heavy that the audio or video stream is unintelligible.
multicast applications such as group file transfer applications,
the other hand, are likely to be between computers, with no humans
attendance monitoring congestion levels
In addition, reliable multicast applications do not necessarily
the natural time limitations typical of current unreliable
applications. For a file transfer application, for example, the
transfer might continue until all of the data is transferred to
of the intended receivers, resulting in a potentially-
duration for an individual flow. Reliable multicast
also have to contend with a potential explosion of complex
of control traffic (e.g., ACKs, NACKs, status messages). The
of congestion control mechanisms for reliable multicast for
multicast groups is currently an area of active research
The challenge to the IETF is to encourage research
implementations of reliable multicast, and to enable the needs
applications for reliable multicast to be met as expeditiously
possible, while at the same time protecting the Internet from
congestion disaster or collapse that could result from the
use of applications with inappropriate reliable multicast mechanisms
Because of the setbacks and costs that could result from
widespread deployment of reliable multicast with
congestion control, the IETF must exercise care in
standardization of a reliable multicast protocol that might
widespread use
The careful review and cautious acceptance procedures for
submitted as Internet-Drafts reflects our concern to meet
challenges described here
4. IETF Process for Review and Publication of Reliable
Protocol
In the general case of individually submitted Internet-
(proposals not produced by an IETF WG), the process of publication
some type of RFC is described in RFC 2026 (4.2.3) [InetStdProc96].
This specifies that if the submitted Internet-Draft is
related to work being done or expected to be done in the IETF,
Mankin, et. al. Informational [Page 5]
RFC 2357 Evaluating Reliable Multicast June 1998
ADs may recommend that the document be brought within the IETF
progressed in the IETF context. Otherwise, the ADs may
that the Internet-Draft be published as an Experimental
Informational RFC, with or without an IESG annotation of
relationship to the IETF context
The procedure for Reliable Multicast proposal publication will
as its default RFC status Experimental, when the technical
listed in Section 5 are deemed to be fulfilled. Both the criteria
the procedure reflect the AD's technical assessment of the
state of reliable multicast technology. It does not reflect
origins of the proposals, which we expect will be equally
commercial vendors with initial products and from researchers
Work on the development and engineering of protocols that
eventually meet the review criteria could take place either in
IRTF Reliable Multicast Research Group (http://www.irtf.org) or
focused short IETF WG with an Experimental product
When the work in reliable multicast technology has matured enough
be considered for standardization within the IETF, the TSV Area
charter appropriate working groups to develop standards
documents. The criteria for evaluation of standards track
will be at least as stringent as those described herein (
section).
5. Technical Criteria for Reliable
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
analysis. Especially the protocol behavior must be explained
detail with respect to scalability, congestion control,
recovery, and robustness
For example the following questions should be answered
How scalable is the protocol to the number of senders
receivers in a group, the number of groups, and wide
of group members
Identify the mechanisms which limit scalability and
those limits
How does the protocol protect the Internet from congestion?
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
functions needed by the applications it serves
Is there a congestion control mechanism? How well does
perform? When does it fail? Note that congestion
mechanisms that operate on the network more aggressively
TCP will face a great burden of proof that they don't
network stability
b. Include a description of trials and/or simulations which
the development of the protocol and the answers to the
questions
c. Include an analysis of whether the protocol has
avoidance mechanisms strong enough to cope with deployment in
Global Internet, and if not, clearly document the circumstances
which congestion harm can occur. How are these circumstances
be prevented
d. Include a description of any mechanisms which contain the
within limited network environments. If the analysis in a or
shows that the protocol has potential to damage the Internet,
the analysis must include a discussion of ways to limit the
or otherwise contain the protocol. We recognize that
confinement of Internet applications is an open research area
e. Reliable multicast protocols must include an analysis of how
address a number of security and privacy concerns. If
protocol can be used in different modes of secure operation,
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
secure operation and privacy of the transmitted data, to
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
subset of the receivers receive different copies? Does
protocol allow a group of receivers to determine whether
all received the same data
What limitations are placed on the retransmission mechanism
prevent it from being abused to flood network links
excessive traffic? Which parties must be trusted to
this, and to what degree, and why? The presumption will be
either a congestion control mechanism will inherently limit
volume of retransmission traffic, and that this
Mankin, et. al. Informational [Page 7]
RFC 2357 Evaluating Reliable Multicast June 1998
influence is robust under concerted attack; or
retransmission requests will be signed in a
strong manner so that abuses of the mechanism can be
back to their source. Protocols that do not provide either
these forms of protection face a great burden of proof
they don't threaten network stability
What sort of key management does the protocol require,
provide for
6. Security
This memo specifies in Section 5.e. that reliable
Internet-Drafts reviewed by the Transport Area Directors
explicitly explore the security aspects of the proposed design
7.
Sally Floyd, Steve McCanne, Mark Handley, Steve Bellovin and
Reiter gave especially helpful comments on drafts of this document
8.
[RMMinutes 1997] Minutes the Second Reliable Multicast
Group Meeting. September 1997. http://www.east.isi.edu/
[Floyd97] Floyd, S., Jacobson, V., Liu, C., McCanne, S., and Zhang
L., A Reliable Multicast Framework for Light-weight Sessions
Application Level Framing. IEEE/ACM Transactions on Networking
December 1997 An online version of the paper is
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
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
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,
1997.
[Jacobson 1988] Jacobson, V., Congestion Avoidance and Control
Proceedings of SIGCOMM '88, August 1988, pp. 314-329. An
version of this paper is available
"ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z".
Mankin, et. al. Informational [Page 9]
RFC 2357 Evaluating Reliable Multicast June 1998
9. Authors'
Allison Mankin - Past TSV Area
USC/ISI
4350 N. Fairfax Dr., Suite 620
Arlington VA 22203
Phone: 703 812 3706
EMail: mankin@east.isi.
Allyn Romanow - Past TSV Area
MCI
2560 North First
San Jose, CA 9531
Phone: 408 922 7143
EMail: allyn@mci.
Scott Bradner - TSV Co-Area
Harvard
1350 Mass. Ave., Rm. 876
Cambridge MA 02138
Phone: 617 495 3864
EMail: sob@harvard.
Vern Paxson - TSV Co-Area
MS 50B/2239
Lawrence Berkeley National
University of
Berkeley, CA 94720
Phone: 510-486-7504
EMail: vern@ee.lbl.
Mankin, et. al. Informational [Page 10]
RFC 2357 Evaluating Reliable Multicast June 1998
10. Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Mankin, et. al. Informational [Page 11]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
