rfc2887.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,236 行 · 第 1/4 页

Network Working Group                                         M. Handley
Request for Comments: 2887                                      S. Floyd
Category: Informational                                            ACIRI
                                                              B. Whetten
                                                                Talarian
                                                              R. Kermode
                                                                Motorola
                                                             L. Vicisano
                                                                   Cisco
                                                                 M. Luby
                                                  Digital Fountain, Inc.
                                                             August 2000


       The Reliable Multicast Design Space for Bulk Data Transfer

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 (2000).  All Rights Reserved.

Abstract

   The design space for reliable multicast is rich, with many possible
   solutions having been devised.  However, application requirements
   serve to constrain this design space to a relatively small solution
   space.  This document provides an overview of the design space and
   the ways in which application constraints affect possible solutions.

1.  Introduction

   The term "general purpose reliable multicast protocol" is something
   of an oxymoron.  Different applications have different requirements
   of a reliable multicast protocol, and these requirements constrain
   the design space in ways that two applications with differing
   requirements often cannot share a single solution.  There are however
   many successful reliable multicast protocol designs that serve more
   special purpose requirements well.

   In this document we attempt to review the design space for reliable
   multicast protocols intended for bulk data transfer.  The term bulk
   data transfer should be taken as having broad meaning - the main
   limitations are that the data stream is continuous and long lived -



Handley, et al.              Informational                      [Page 1]

RFC 2887     Multicast Design Space for Bulk Data Transfer   August 2000


   constraints necessary for the forms of congestion control we
   currently understand.  The purpose of this review is to gather
   together an overview of the field and to make explicit the
   constraints imposed by particular mechanisms. The aim is to provide
   guidance to the standardization process for protocols and protocol
   building blocks.  In doing this, we cluster potential solutions into
   a number of loose categories - real protocols may be composed of
   mechanisms from more than one of these clusters.

   The main constraint on solutions is imposed by the need to scale to
   large receiver sets.  For small receiver sets the design space is
   much less restricted.

2.  Application Constraints

   Application requirements for reliable multicast (RM) are as broad and
   varied as the applications themselves.  However, there are a set of
   requirements that significantly affect the design of an RM protocol.
   A brief list includes:

   o  Does the application need to know that everyone received the data?

   o  Does the application need to constrain differences between
      receivers?

   o  Does the application need to scale to large numbers of receivers?

   o  Does the application need to be totally reliable?

   o  Does the application need ordered data?

   o  Does the application need to provide low-delay delivery?

   o  Does the application need to provide time-bounded delivery?

   o  Does the application need many interacting senders?

   o  Is the application data flow intermittent?

   o  Does the application need to work in the public Internet?

   o  Does the application need to work without a return path (e.g.
      satellite)?

   o  Does the application need to provide secure delivery?






Handley, et al.              Informational                      [Page 2]

RFC 2887     Multicast Design Space for Bulk Data Transfer   August 2000


   In the context of standardizing bulk data transfer protocols, we can
   rule out applications with multiple interacting senders and
   intermittent data flows.  It is not that these applications are
   unimportant, but that we do not yet have effective congestion control
   for such applications.

2.1.  Did everyone receive the data?

   In many applications a logically defined unit or units of data is to
   be delivered to multiple clients, e.g., a file or a set of files, a
   software package, a stock quote or package of stock quotes, an event
   notification, a set of slides, a frame or block from a video.  An
   application data unit (ADU) is defined to be a logically separable
   unit of data that is useful to the application. In some cases, an
   application data unit may be short enough to fit into a single packet
   (e.g., an event notification or a stock quote), whereas in other
   cases an application data unit may be much longer than a packet
   (e.g., a software package).

   A protocol may optionally provide delivery confirmation to ensure
   reliable delivery, i.e., a mechanism for receivers to inform the
   sender when data has been delivered.  There are two types of
   confirmation, at the application data unit level and at the packet
   level. Application data unit confirmation is useful at the
   application level, e.g., to inform the application about receiver
   progress and to decide when to stop sending packets about a
   particular application data unit.  Packet confirmation is useful at
   the transport level, e.g., to inform the transport level when it can
   release buffer space being used for storing packets for which
   delivery has been confirmed.

   Some applications have a strong requirement for confirmation that all
   the receivers got an ADU, or if not, to be informed of which specific
   receivers failed to receive the entire ADU. Examples include
   applications where receivers pay for data, and reliable file-system
   replication.  Other applications do not have such a requirement.  An
   example is the distribution of free software.

   If the application does need to know that every receiver got the ADU,
   then a positive acknowledgment must be received from every receiver,
   although it may be possible to aggregate these acknowledgments.  If
   the application needs to know precisely which receivers failed to get
   the ADU, additional constraints are placed on acknowledgment
   aggregation.

   It should be noted that different mechanisms can be used for ADU-
   level confirmation and packet-level confirmation in the same
   application.  For example, an ADU-level confirmation mechanism using



Handley, et al.              Informational                      [Page 3]

RFC 2887     Multicast Design Space for Bulk Data Transfer   August 2000


   positive acknowledgments may sit on top of a packet-level NACK or
   FEC-based transport.  Typically this only makes sense when ADUs are
   significantly larger than a single packet.

2.2.  Constraining differences

   Some applications need to constrain differences between receivers so
   that the data reception characteristics for all receivers falls
   within some range.  An example is a stock price feed, where it is
   unacceptable for a receiver to suffer delivery that is delayed
   significantly more than any other receiver.

   This requirement is difficult to satisfy without harming performance.
   Typically solutions involve not sending more than a limited amount of
   new data until positive acknowledgments have been received from all
   the receivers.  Such a solution does not cope with network and end-
   system failures well.

2.3.  Receiver Set Scaling

   There are many applications for RM that do not need to scale to large
   numbers of receivers.  For such applications, a range of solutions
   may be available that are not available for applications where
   scaling to large receiver sets is a requirement.

   A protocol must achieve good throughput of application data units to
   receivers.  This means that most data that is delivered to receivers
   is useful in recovering the application data unit that they are
   trying to receive. A protocol must also provide good congestion
   control to fairly share the available network resources between all
   applications.  Receiver set scaling is one of the most important
   constraints in meeting these requirements, because it strictly limits
   the mechanisms that can be used to achieve these requirements to
   those that will efficiently scale to a large receiver population.
   Acknowledgement packets have been employed by many systems to achieve
   these goals, but it is important to understand the strength and
   limitations of different ways of using such packets.

   In a very small system, it may be acceptable to have the receivers
   acknowledge every packet.  This approach provides the sender with the
   maximum amount of information about reception conditions at all the
   receivers, information that can be used both to achieve good
   throughput and to achieve congestion control.








Handley, et al.              Informational                      [Page 4]

RFC 2887     Multicast Design Space for Bulk Data Transfer   August 2000


   For larger systems, such "flat ACK" schemes cause acknowledge
   implosions at the sender.  Attempts have been made to reduce this
   problem by sending aggregate ACKs infrequently [RMWT98, BC94], but it
   is very difficult to incorporate effective congestion control into
   such protocols because of the spareceness of feedback.

   Using negative acknowledgments (NACKs) instead of ACKs reduces this
   problem to one of NACK implosion (only from the receivers missing the
   packets), and because the sender really only needs to know that at
   least one receiver is missing data in order to achieve good
   throughput, various NACK suppression mechanisms can be applied.

   An alternative to NACKs is ACK aggregation, which can be done by
   arranging the receivers into a logical tree, so that each leaf sends
   ACKs to its parent which aggregates them, and passes them on up the
   tree.  Tree-based protocols scale well, but tree formation can be
   problematic.

   Other ACK topologies such as rings are also possible, but are often
   more difficult to form and maintain than trees are.  An alternative
   strategy is to add mechanisms to routers so that they can help out in
   achieving good throughput or in reducing the cost of achieving good
   throughput.

   All these solutions improve receiver set scaling, but they all have
   limits of one form or another.  One class of solutions scales to an
   infinite number of receivers by having no feedback channel whatsoever
   in order to achieve good throughput.  These open-loop solutions take
   the initial data and encode it using an FEC-style mechanism.  This
   encoded data is transmitted in a continuous stream.  Receivers then
   join the session and receive packets until they have sufficient
   packets to decode the original data, at which point they leave the
   session.

   Thus, it is clear that the intended scale of the session constrains
   the possible solutions.  All solutions will work for very small
   sessions, but as the intended receive set increases, the range of
   possible solutions that can be deployed safely decreases.

   It should also be noted that hybrids of these mechanisms are
   possible, and that using one mechanism at the packet-level and a
   different (typically higher overhead) solution at the ADU level may
   also scale reasonably if the ADUs are large compared to packets.








Handley, et al.              Informational                      [Page 5]

RFC 2887     Multicast Design Space for Bulk Data Transfer   August 2000


2.4.  Total vs Semi-reliable

   Many applications require delivery of application data units to be
   totally reliable; if any of the application data unit is missing,
   none of the received portion of the application data unit is useful.
   File transfer applications are a good example of applications
   requiring total reliability.

   However, some applications do not need total reliability.  An example
   is audio broadcasting, where missing packets reduce the quality of
   the received audio but do not render it unusable.  Such applications
   can sometimes get by without any additional reliability over native
   IP reliability, but often having a semi-reliable multicast protocol
   is desirable.

2.5.  Time-bounded Delivery

   Many applications just require data to be delivered to the receivers
   as fast as possible.  They have no absolute deadline for delivery.

   However, some applications have hard delivery constraints - if the
   data does not arrive at the receiver by a certain time, there is no
   point in delivering it at all.  Such time-boundedness may be as a