rfc2887.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   result of real-time constraints such as with audio or video
   streaming, or as the result of new data superseding old data.  In
   both cases, the requirement is for the application to have a greater
   degree of control over precisely what the application sends at which
   time than might be required with applications such as file transfer.

   Time-bounded delivery usually also implies a semi-reliable protocol,
   but the converse does not necessarily hold.

3.  Network Constraints

   The properties of the network in which the application is being
   deployed may themselves constrain the reliable multicast design
   space.

3.1.  Internet vs Intranet

   In principle the Internet and intranets are the same.  In practice
   however, the fact that an intranet is under one administration might
   allow for solutions to be configured that can not easily be done in
   the public Internet.  Thus, if the data is of very high value, it
   might be appropriate to enhance the routers to provide assistance to
   a reliable multicast transport protocol.  In the public Internet, it
   is less likely that the additional expense required to support this
   state in the routers would be acceptable.



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


3.2.  Return Path

   In principle, when feedback is required from receivers, this feedback
   can be multicast or unicast.  Multicast feedback has advantages,
   especially in NACK-based protocols where it is valuable for NACK
   suppression.  However, it is not clear at this time whether all ISPs
   will allow all members of a session to send to that session.  If
   multicast feedback is not allowed, then unicast feedback can almost
   always be substituted, although often at the expense of additional
   messages and mechanisms.

   Some networks may not allow any form of feedback however.  The
   primary example of this occurs with satellite broadcasts where the
   back channel may be very narrow or even non-existent.  For such
   networks the solution space is very constrained - only FEC-based
   encodings have any real chance of working.  If the receivers are
   direct satellite receivers, then no congestion control is needed, but
   it is dangerous to make such assumptions because it is possible for a
   satellite hop to feed downstream networks.  Thus, congestion control
   still needs to be considered with solutions that do not have a return
   path.

3.3.  Network Assistance

   A reliable multicast protocol must involve mechanisms running in end
   hosts, and must involve routers forwarding multicast packets.
   However under some circumstances, it is possible to rely on some
   additional degree of assistance from network elements.  Broadly
   speaking we can cluster RM protocols into four classes depending on
   the degree of support received from other network elements.

   No Additional Support
      The routers merely forward packets, and only the sender and
      receivers have any reliable multicast protocol state.

   Layered Approaches
      Data is split across multiple multicast groups.  Receivers join
      appropriate groups to receive only the traffic they require.  This
      may in some cases require fast join or leave functionality from
      the routers, and may require more forwarding state in the routers.

   Server-based Approaches
      Additional nodes are used to assist with data delivery or feedback
      aggregation.  These additional nodes might not be normal senders
      or receivers, and may be present on the distribution or feedback
      tree only to provide assistance to the reliable multicast
      protocol.  They would not otherwise receive the multicast traffic.




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


   Router-based Approaches
      With router-based approaches, routers on the normal data
      distribution tree from the sender to the receivers assist in the
      delivery of data or feedback aggregation or suppression.  As
      routers can directly influence multicast routing, they have more
      control over which traffic goes to which group members than
      server-based approaches.  However routers do not normally have a
      large amount of spare memory or processing power, which restricts
      how much functionality can be placed in the routers.  In addition,
      router code is normally more difficult to upgrade than application
      code, so router-based approaches need to be very general as they
      are more difficult to deploy and to change.

4.  Good Throughput Mechanisms

   Two main concerns that a RM protocol must address are congestion
   control and good throughput.  Packet loss plays a major role with
   respect to both concerns.  The primary symptom of congestion in many
   networks is packet loss. The primary obstacle that must be overcome
   to achieve good throughput is packet loss.  Thus, measuring and
   reacting to packet loss is crucial to address both concerns. RM
   solutions that address these concerns can be roughly categorized as
   using one or more of the following techniques:

   o  Data packet acknowledgment.

   o  Negative acknowledgment of missing data packets.

   o  Redundancy allowing not all packets to be received.

   These techniques themselves can be usefully subdivided, so that we
   can examine the parts of the requirement space in which each
   mechanism can be deployed.  In this section, we focus on using these
   mechanisms for achieving good throughput, and in the next section we
   focus on using these mechanisms for congestion control.

4.1.  ACK-based Mechanisms

   The simplest ACK-based mechanism involves every receiver sending an
   ACK packet for every data packet it receives and resending packets
   that are lost by any receiver.  Such mechanisms are limited to very
   small receiver groups by the implosion of ACKs received at the
   sender, and for this reason they are impractical for most
   applications.







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


   Putting multiple ACKs into a single data packet [RMWT98] reduces the
   implosion problem by a constant amount, allowing slightly larger
   receiver groups.  However a limit is soon reached whereby feedback to
   the sender is too infrequent for sender-based congestion control
   mechanisms to work reliably.

   Arranging the receivers into a ring [WKM94] whereby an "ACK-token" is
   passed around the ring prevents the implosion problem for data.
   However ring creation and maintenance may itself be problematic.
   Also if ring creation does not take into account network topology
   (something which is difficult to achieve in practice), then the
   number of ACK packets crossing the network backbone for each data
   packet sent may increase O(n) with the number of receivers.

4.1.1.  Tree-based ACK Mechanisms

   Arranging the receivers into a tree [MWB+98, KCW98] whereby receivers
   generate ACKs to a parent node, which aggregates those ACKs to its
   parent in turn, is both more robust and more easily configured than a
   ring.  The ACK-tree is typically only used for ACK-aggregation - data
   packets are multicast from the sender to the receivers as normal.
   Trees are easier to construct than rings because more local
   information can be used in their construction.  Also they can be more
   fault tolerant than rings because node failures only affect a subset
   of receivers, each of which can easily and locally decide to by-pass
   its parent and report directly to the node one level higher in the
   tree.  With good ACK-tree formation, tree-based ACK mechanisms have
   the potential to be one of the most scalable RM solutions.

   To be simple to deploy, tree-based protocols must be self-organizing
   - the receivers must form the tree themselves using local information
   in a scalable manner.  Such mechanisms are possible, but are not
   trivial.  The main scaling limitations of tree-based protocols
   therefore come from the tree formation and maintenance mechanisms
   rather than from the use of ACKs.  Without such a scalable and
   automatic tree-formation mechanism, tree-based protocols must rely on
   manual configuration, which significantly limits their applicability
   (often to intranets) and (due to the complexity of configuration)
   their scalability.

   Orthogonal to the issue of tree formation is the issue of subtree
   retransmission.  With appropriate router mechanisms, or the use of
   multiple multicast groups, it is possible to allow the intermediate
   tree nodes to retransmit missing data to the nodes below them in the
   tree rather than relying on the original sender to retransmit the
   data.  This relies on there being a good correlation at the point of
   the intermediate node between the ACK tree and the actual data tree,
   as well as there being a mechanism to constrain the retransmission to



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


   the subtree.  A good automatic tree formation mechanism combined with
   the use of administrative scoped multicast groups might provide such
   a solution. Without such tree formation mechanisms, subtree
   retransmission is difficult to deploy in large groups in the public
   internet.       This could also be solved by the use of transport-
   level router mechanisms to assist or perform retransmission, although
   existing router mechanisms [FLST98] support NACK-based rather than
   ACK-based protocols.

   Another important issue is the nature of the aggregation performed at
   interior nodes on the ACK-tree.  Such nodes could:

   1. aggregate ACKs by sending a single ACK when all their children
      have ACKed,

   2. aggregate ACKs by listing all the children that have ACKed,

   3. send an aggregated ACK with a NACK-like exception list.

   For data packets, 1. is clearly more scalable, and should be
   preferred.  However if the sender needs to know exactly which
   receivers received the data, 2. and 3. provide this information.
   Fortunately, there is usually no need to do this on a per-packet
   basis, but rather on a per-ADU basis.  Doing 1. on a per packet
   basis, and 3. on a per ADU basis is the most scalable solution for
   applications that need this information, and suffers virtually no
   disadvantage compared to the other solutions used on a per-packet
   basis.

4.2.  NACK-based mechanisms

   Instead of sending an ACK for every data packet received, receivers
   can send a negative acknowledgment (NACK) for every data packet they
   discover they did not receive.  This has a number of advantages over
   ACK-based mechanisms:

   o  The sender no longer needs to know exactly how many receivers
      there are.  This removes the topology-building phase needed for
      ring- or tree-style ACK-based algorithms.

   o  Fault-tolerance is made somewhat simpler by making receivers
      responsible for reliability.

   o  Sender state can be significantly reduced because the sender does
      not need to keep track of the receivers state.






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


   o  Only a single NACK is needed from any receiver to indicate a
      packet that is missing by any number of receivers.  Thus NACK
      suppression is possible.

   The disadvantages are that it is more difficult for the sender to
   know that it can free transmission buffers, and that additional
   session level mechanisms are needed if the sender really needs to
   know if a particular receiver actually received all the data.
   However for many applications, neither of these is an issue.

4.2.1.  NACK Suppression

   The key differences between NACK-based protocols is in how NACK-
   suppression is performed.  The goal is for only one NACK to reach the
   sender (or a node that can resend the missing data) as soon as
   possible after the loss is first noticed, and for only one copy of
   the missing data to be received by those nodes needing
   retransmission.

   Different mechanisms come close to satisfying these goals in
   different ways.

   o  SRM [FJM95] uses random timers weighted by the round trip time
      between the sender and each node missing the data.  This is
      effective, but requires computing the RTT to each receiver before
      suppression works properly.

   o  NTE [HC97] uses a sender-triggered mechanism based on random keys
      and sliding masks.  This does not require random timers, and works
      for very large sessions, but makes it difficult to provide the
      constant low-level stream of feedback needed to perform congestion
      control.

   o  AAP [Ha99] uses exponentially distributed random timers and is
      effective for large sessions without needing to compute the RTT to
      each receiver.

   o  PGM [FLST98] and LMS [PPV98] use additional mechanisms in routers
      to suppress duplicate NACKs.  In the case of PGM, router
      assistance suppliments SRM-stype random timers and localizes the
      suppression so that the whole group does not need suppressing.

   The most general of these mechanisms is probably exponentially
   weighted random timers.  Although SRM style timers can reduce
   feedback delay, they are harder to use correctly in situations where
   all the RTTs are not known, or where the number of respondees is





Handley, et al.              Informational                     [Page 11]