datatracker.ietf.org
Sign in
Version 5.4.0, 2014-04-22
Report a bug

The Reliable Multicast Design Space for Bulk Data Transfer
RFC 2887

Document type: RFC - Informational (August 2000)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Document shepherd: No shepherd assigned

IESG State: RFC 2887 (Informational)
Responsible AD: (None)
Send notices to: No addresses provided

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

[include full document text]