rfc3048.txt

RFC 的详细文档！

Whetten, et al.              Informational                      [Page 5]

RFC 3048                  RMT Building Blocks               January 2001


      how router assist can provide fine grained congestion control for
      ALC protocols.  Router assist protocols can be designed to
      complement all protocol families described above.

   Note that the distinction in protocol families in not necessarily
   precise and mutually exclusive.  Actual protocols may use a
   combination of the mechanisms belonging to different classes.  For
   example, hybrid NACK/ACK based protocols (such as [WBPM98]) are
   possible.  Other examples are protocols belonging to class 1 through
   3 that take advantage of router support.

2.  Building Blocks Rationale

   As specified in RFC 2357 [MRBP98], no single reliable multicast
   protocol will likely meet the needs of all applications.  Therefore,
   the IETF expects to standardize a number of protocols that are
   tailored to application and network specific needs.  This document
   concentrates on the requirements for "one-to-many bulk-data
   transfer", but in the future, additional protocols and building-
   blocks are expected that will address the needs of other types of
   applications, including "many-to- many" applications.  Note that
   bulk-data transfer does not refer to the timeliness of the data,
   rather it states that there is a large amount of data to be
   transferred in a session.  The scope and approach taken for the
   development of protocols for these additional scenarios will depend
   upon large part on the success of the "building-block" approach put
   forward in this document.

2.1.  Building Blocks Advantages

   Building a large piece of software out of smaller modular components
   is a well understood technique of software engineering.  Some of the
   advantages that can come from this include:

   o  Specification Reuse.  Modules can be used in multiple protocols,
      which reduces the amount of development time required.

   o  Reduced Complexity.  To the extent that each module can be easily
      defined with a simple API, breaking a large protocol in to smaller
      pieces typically reduces the total complexity of the system.

   o  Reduced Verification and Debugging Time.  Reduced complexity
      results in reduced time to debug the modules.  It is also usually
      faster to verify a set of smaller modules than a single larger
      module.






Whetten, et al.              Informational                      [Page 6]

RFC 3048                  RMT Building Blocks               January 2001


   o  Easier Future Upgrades.  There is still ongoing research in
      reliable multicast, and we expect the state of the art to continue
      to evolve.  Building protocols with smaller modules allows them to
      be more easily upgraded to reflect future research.

   o  Common Diagnostics.  To the extent that multiple protocols share
      common packet headers, packet analyzers and other diagnostic tools
      can be built which work with multiple protocols.

   o  Reduces Effort for New Protocols.  As new application requirements
      drive the need for new standards, some existing modules may be
      reused in these protocols.

   o  Parallelism of Development.  If the APIs are defined clearly, the
      development of each module can proceed in parallel.

2.2.  Building Block Risks

   Like most software specification, this technique of breaking down a
   protocol in to smaller components also brings tradeoffs.  After a
   certain point, the disadvantages outweigh the advantages, and it is
   not worthwhile to further subdivide a problem.  These risks include:

   o  Delaying Development.  Defining the API for how each two modules
      inter-operate takes time and effort.  As the number of modules
      increases, the number of APIs can increase at more than a linear
      rate.  The more tightly coupled and complex a component is, the
      more difficult it is to define a simple API, and the less
      opportunity there is for reuse.  In particular, the problem of how
      to build and standardize fine grained building blocks for a
      transport protocol is a difficult one, and in some cases requires
      fundamental research.

   o  Increased Complexity.  If there are too many modules, the total
      complexity of the system actually increases, due to the
      preponderance of interfaces between modules.

   o  Reduced Performance.  Each extra API adds some level of processing
      overhead.  If an API is inserted in to the "common case" of packet
      processing, this risks degrading total protocol performance.

   o  Abandoning Prior Work.  The development of robust transport
      protocols is a long and time intensive process, which is heavily
      dependent on feedback from real deployments.  A great deal of work
      has been done over the past five years on components of protocols
      such as RMTP-II, SRM, and PGM.  Attempting to dramatically re-
      engineer these components risks losing the benefit of this prior
      work.



Whetten, et al.              Informational                      [Page 7]

RFC 3048                  RMT Building Blocks               January 2001


2.3.  Building Block Requirements

   Given these tradeoffs, we propose that a building block must meet the
   following requirements:

   o  Wide Applicability.  In order to have confidence that the
      component can be reused, it should apply across multiple protocol
      families and allow for the component's evolution.

   o  Simplicity.  In order to have confidence that the specification of
      the component APIs will not dramatically slow down the standards
      process, APIs must be simple and straight forward to define.  No
      new fundamental research should be done in defining these APIs.

   o  Performance.  To the extent possible, the building blocks should
      attempt to avoid breaking up the "fast track", or common case
      packet processing.

3.  Protocol Components

   This section proposes a functional decomposition of RM bulk-data
   protocols from the perspective of the functional components provided
   to an application by a transport protocol.  It also covers some
   components that while not necessarily part of the transport protocol,
   are directly impacted by the specific requirements of a reliable
   multicast transport.  The next section then specifies recommended
   building blocks that can implement these components.

   Although this list tries to cover all the most common transport-
   related needs of one-to-many bulk-data transfer applications, new
   application requirements may arise during the process of
   standardization, hence this list must not be interpreted as a
   statement of what the transport layer should provide and what it
   should not.  Nevertheless, it must be pointed out that some
   functional components have been deliberately omitted since they have
   been deemed irrelevant to the type of application considered (i.e.,
   one-to-many bulk-data transfer).  Among these are advanced message
   ordering (i.e., those which cannot be implemented through a simple
   sequence number) and atomic delivery.

   It is also worth mentioning that some of the functional components
   listed below may be required by other functional components and not
   directly by the application (e.g., membership knowledge is usually
   required to implement ACK-based reliability).

   The following list covers various transport functional components and
   splits them in sub-components.




Whetten, et al.              Informational                      [Page 8]

RFC 3048                  RMT Building Blocks               January 2001


   o  Data Reliability (ensuring good throughput)    |
                          | - Loss Detection/Notification
                          | - Loss Recovery
                          | - Loss Protection

   o  Congestion Control  |
                          | - Congestion Feedback
                          | - Rate Regulation
                          | - Receiver Controls

   o  Security

   o  Group membership    |
                          | - Membership Notification
                          | - Membership Management

   o  Session Management  |
                          | - Group Membership Tracking
                          | - Session Advertisement
                          | - Session Start/Stop
                          | - Session Configuration/Monitoring

   o  Tree Configuration

   Note that not all components are required by all protocols, depending
   upon the fully defined service that is being provided by the
   protocol.  In particular, some minimal service models do not require
   many of these functions, including loss notification, loss recovery,
   and group membership.

3.1.  Sub-Components Definition

   Loss Detection/Notification.  This includes how missing packets are
   detected during transmission and how knowledge of these events are
   propagated to one or more agents which are designated to recover from
   the transmission error.  This task raises major scalability issues
   and can lead to feedback implosion and poor throughput if not
   properly handled.  Mechanisms based on TRACKs (tree-based positive
   acknowledgements) or NACKs (negative acknowledgements) are the most
   widely used to perform this function.  Mechanisms based on a
   combination of TRACKs and NACKs are also possible.

   Loss Recovery.  This function responds to loss notification events
   through the transmission of additional packets, either in the form of
   copies of those packets lost or in the form of FEC packets.  The
   manner in which this function is implemented can significantly affect
   the scalability of a protocol.




Whetten, et al.              Informational                      [Page 9]

RFC 3048                  RMT Building Blocks               January 2001


   Loss Protection.  This function attempts to mask packet-losses so
   that they don't become Loss Notification events.  This function can
   be realized through the pro-active transmission of FEC packets.  Each
   FEC packet is created from an entire application data unit [LMSSS97]
   or a portion of an application data unit [RV97], [BKKKLZ95], a fact
   that allows a receiver to recover from some packet loss without
   further retransmissions.  The number of losses that can be recovered
   from without requiring retransmission depends on the amount of FEC
   packets sent in the first place.  Loss protection can also be pushed
   to the extreme when good throughput is achieved without any Loss
   Detection/Notification and Loss Recovery functionality, as in the ALC
   family of protocols defined above.

   Congestion Feedback.  For sender driven congestion control protocols,
   the receiver must provide some type of feedback on congestion to the
   sender.  This typically involves loss rate and round trip time
   measurements.

   Rate Regulation.  Given the congestion feedback, the sender then must
   adjust its rate in a way that is fair to the network.  One proposal
   that defines this notion of fairness and other congestion control
   requirements is [Whetten99].

   Receiver Controls.  In order to avoid allowing a receiver that has an
   extremely slow connection to the sender to stop all progress within
   single rate schemes, a congestion control algorithm will often
   require receivers to leave groups.  For multiple rate approaches,
   receivers of all connection speeds can have data delivered to them
   according to the rate of their connection without slowing down other
   receivers.

   Security.  Security for reliable multicast contains a number of
   complex and tricky issues that stem in large part from the IP
   multicast service model.  In this service model, hosts do not send
   traffic to another host, but instead elect to receive traffic from a
   multicast group. This means that any host may join a group and
   receive its traffic.  Conversely, hosts may also leave a group at any
   time.  Therefore, the protocol must address how it impacts the
   following security issues:

   o  Sender Authentication (since any host can send to a group),

   o  Data Encryption (since any host can join a group)

   o  Transport Protection (denial of service attacks, through
      corruption of transport state, or requests for unauthorized
      resources)




Whetten, et al.              Informational                     [Page 10]