rfc2887.txt

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


RFC 2887     Multicast Design Space for Bulk Data Transfer   August 2000


   unknown.  In contrast, exponentially weighted random timers work well
   across a large range of session sizes with good worst case delay
   characteristics.

   Either form of random timer based mechanism can be supplemented by
   router-support where it is available.  Sender triggered NACK
   mechanisms (e.g. [HC97]) are more difficult to integrate with
   router-based support mechanisms.

4.3.  Replication

   Some RM protocols can be designed so as to not need explicit
   reliability mechanisms except in comparatively rare cases.  An
   example is in a multicast game, where the position of a moving object
   is continuously multicast.  This positional stream does not require
   additional reliability because a new position superseding the old one
   will be sent before any retransmission could take place.  However,
   when the moving object interacts with other objects or stops moving,
   then an explicit reliability mechanism is required to reliably send
   the interaction information or last position.

   It is not just games that can be built in this manner - the NTE
   shared text editor[HC97] uses just such a mechanism with changes to a
   line of text.  For every change the whole line is sent, and so long
   as the user keeps typing no explicit reliability mechanism is needed.
   The major advantage of replication is that it is not susceptible to
   spatially uncorrelated packet loss.  With a traditional ACK or NACK
   based protocol, the probability of any particular packet being
   received by all the receivers in a large group can be very low.  This
   leads to high retransmission rates.      In contrast, replicated
   streams do not suffer as the size of the receiver group increases -
   different receivers lose different packets, but this does not
   increase network traffic.

4.4.  Packet-level Forward Error Correction

   Forward Error Correction (FEC) is a well known technique for
   protecting data against corruption.  For reliable multicast it is
   most useful in the form of erasure codes.

   The simplest form of packet-level FEC is to take a group of packets
   that is to be sent, and to XOR the packets together to form a
   newpacket which is also sent.  If there were three original packets
   plus the XOR packet sent, then if a receiver is missing any one of
   the original data packets, but receives the XOR packet, then it can
   reproduce the missing original packet.





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


   More general erasure codes exist [BKKKLZ95], [Ri97], [LMSSS97] that
   allow the generation of n encoding packets from k original data
   packets.  In such cases, so long as at least k of the n encoding
   packets are received, then the k original data packets can be
   reproduced.

   To apply FEC the sender groups data packets into rounds, and encoding
   packets are produced based on all the data packets in a round. A
   round may consist of all data packets in an entire application data
   unit in some cases, whereas in other cases it may consist of a group
   of data packets that make up only a small portion of an application
   data unit.

   Using erasure codes to repair packet loss is a significant
   improvement over simple retransmission because the dependency on
   which packets have been lost is removed.  Thus, the amount of repair
   traffic required to repair spatially uncorrelated packet loss is
   considerably lessened.

   We can divide packet-level FEC schemes into two categories: proactive
   FEC and reactive FEC.  The difference between the two is that for
   proactive FEC the sender decides a priori how many encoding packets
   to send for each round of data packets, whereas for reactive FEC the
   sender initially transmits only the original data packets for each
   round.  Then, the sender uses feedback from the receivers to compute
   how many packets were lost by the receiver that experienced the most
   loss in each round, and then only that number of additional encoding
   packets are sent for that round.  These encoding packets will then
   also serve to repair loss at the other receivers that are missing
   fewer packets.  The receivers report via ACKs or NACKs how many
   packets are missing from each round. With NACKs, only the receiver
   missing the most packets need send a NACK for this round, so this is
   used to weight the random timers in the NACK calculation.

   Proactive and reactive FEC can be combined, e.g., a certain amount of
   proactive FEC can be sent for each round and if there are receivers
   that experience more loss than can be overcome by this for some
   rounds then they can request and receive additional encoding packets
   for these rounds.

   FEC is very effective at reducing the repair traffic for packet loss.
   However, it requires that the data to be sent to be grouped into
   rounds, which can add to end-to-end latency.  For bulk-data
   applications this is typically not a problem, but this may be an
   issue for interactive applications where replication may be a better
   solution.





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


4.5.  Layered FEC

   An alternative use of packet level FEC is possible when data is
   spread across several multicast groups [RVC98], [BLMR98].  In such
   cases, the original k data packets are used to generate n encoding
   packets, where n is much larger than k.  The n encoded packets are
   then striped across multiple multicast groups.  When a receiver
   wishes to receive the original data it joins one or more of the
   multicast groups, and receives the encoding packets.  Once it has
   received k different encoding packets, the receiver can then leave
   all the multicast groups and reconstruct the original data.

   The primary importance of such a layering is that it allows different
   receivers to be able to receive the traffic at different rates
   according to the available capacity.  Such schemes do not require any
   form of feedback from the receivers to the sender to ensure good
   throughput, and therefore the need for good throughput does not
   constrain the size of the receiver set.  However, to perform adequate
   network congestion control using receiver joins and leaves in this
   manner may require coordination between members that are behind the
   same congested link from the sender.  As described in the next
   section, [RVC98] suggests such a layered congestion control scheme.

5.  Congestion Control Mechanisms

   The basic delivery model of the Internet is best-effort service.  No
   guarantees are given as to throughput, delay or packet loss.  End-
   systems are expected to be adaptive, and to reduce their transmission
   rate to a level appropriate for the congestion state of the network.
   Although increasingly the Internet will start to support reserved
   bandwidth and differentiated service classes for specialist
   applications, unless an end-system knows explicitly that it has
   reserved bandwidth, it must still perform congestion control.

   Broadly speaking, there are five classes of single-sender multicast
   congestion control solution:

   o  Sender-controlled, one group.

      A single multicast group is used for data distribution.  Feedback
      from the group members is used to control the rate of this group.
      The goal is to transmit at a rate dictated by the slowest
      receiver.








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


   o  Sender-controlled, multiple groups.

      One initial multicast group is adaptively subdivided into multiple
      subgroups with subdivisions centered on congestion points in the
      network.  Application-level relays buffer data from a group nearer
      the original sender, and retransmit it at a slower rate into a
      group further from the original sender.  In this way, different
      receivers can receiver the data at different rates.  Sender-based
      congestion control takes place between the members of a subgroup
      and their relay.

   o  Receiver-controlled, one group.

      A single multicast group is used for data distribution.  The
      receivers determine if the sender is transmitting too rapidly for
      the current congestion state of the network, and they leave the
      group if this is the case.

   o  Receiver-controlled, layered organization.

      A layered approach for how to combine this scheme with a
      congestion control protocol that requires no receiver feedback is
      described in [RVC98].  The sender stripes data across multiple
      multicast groups simultaneously.  Receivers join and leave these
      layered groups depending on their measurements of the congestion
      state of the network, so that the amount of data being received is
      always appropriate. However, this scheme relies on receivers to
      join and leave the different multicast groups in a coordinated
      fashion behind a bottleneck link, and it has not yet been
      completely confirmed that this approach will scale in practice to
      the Internet.  As a result, more work on this congestion control
      mechanism would be beneficial.

   o  Router-based congestion control.

      It is possible to add additional mechanisms to multicast routers
      to assist in multicast congestion control.  Such mechanisms could
      include:

      o  Conditional joins (a multicast join that specifies a loss rate
         above which it is acceptable for the router to reject the
         join).

      o  Router filtering of traffic that exceeds a reasonable rate.
         This may include mechanisms for filtering traffic at different
         points in the network at different rates depending on local
         congestion conditions [LVS99].




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


      o  Fair queuing schemes combined with end-to-end adaptation.

      Router-based schemes generally require more state in network
      routers than has traditionally been acceptable for backbone
      routers.  Thus, in the near-term, such schemes are only likely to
      be applicable for intranet solutions.

   For reliable multicast protocols, it is important to consider
   congestion control at the same time as reliability is being
   considered.  The same mechanisms that are used to provide reliability
   will sometimes be used to provide congestion control.

   In the case of receiver-based congestion control, open-loop delivery
   using FEC is the likely choice for achieving good throughput for
   bulk- data transfer.  This is because open-loop delivery requires no
   feedback from receivers, and thus it is a perfect match with a
   receiver-based congestion-control mechanism that operates without
   feedback from receivers.

6.  Security Considerations

   Generally speaking, security considerations have relatively little
   effect on constraining the design space for reliable multicast
   protocols.  The primary issues constraining the design space are all
   related to receiver-set scaling.  For authentication of the source
   and of data integrity, receiver-set scaling is not a significant
   issue.  However, for data encryption, key distribution and
   particularly re-keying may be significantly affected by receiver-set
   scaling.  Tree and graph based re-keying solutions[WHA98,WGL97] would
   appear to be appropriate solutions to these problems.  It is not
   clear however that such re-keying solutions need to directly affect
   the design of the data distribution part of a reliable multicast
   protocol.

   The primary question to consider for the security of reliable
   multicast protocols is the role of third-parties.  If nodes other
   than the original source of the data are allowed to send or resend
   data packets, then the security model for the protocol must take this
   into account.  In particular, it must be clear whether such third
   parties are trusted or untrusted.  A requirement for trusted third
   parties can make protocols difficult to deploy on the Internet.

   Untrusted third parties (such as receivers that retransmit the data)
   may be used so long as the data authentication mechanisms take this
   into account.  Typically this means that the original sender
   digitally signs and timestamps the data, and that the third parties
   resend this signed timestamped payload unmodified.




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


   Unlike unicast protocols, denial-of-service attacks on multicast
   transport state are easy if the protocol design does not take such
   attacks into account.  This is because any receiver can join the
   session, and can then produce feedback that influences the progress
   of a session involving many other receivers.  Hence protection
   against denial-of-service attacks on reliable multicast protocols
   must be carefully considered.  A receiver that requests
   retransmission of every packet, or that refuses to acknowledge
   packets in an ACK-based protocol can potentially bring a reliable
   multicast session to a standstill.  Senders must have appropriate
   policy to deal with such conditions, and if necessary, evict the
   receiver from the group.  A single receiver masquerading as a large
   number of receivers may still be an issue under such circumstances
   with protocols that support NACK-like functionality.  Providing
   unique "keys" to each NACKer when they first NACK using a unicast
   response might potentially prevent such attacks.

   Denial-of-service attacks caused by traffic flooding are however
   somewhat easier to protect against than with unicast.  Unwanted
   senders can simply be pruned from the distribution tree using the
   mechanisms implemented in IGMP v3[CDT99].

7.  Conclusions

   In this document we present an overview of the design space for