Multicast Negative-Acknowledgment (NACK) Building Blocks
RFC 5401

" transmission, it may be that only the sender requires RTT
   knowledge of the GRTT and/or RTT knowledge of only a portion of the
   group.  Here, the GRTT information might be collected in a reasonably
   scalable manner.  For congestion control operation, it is possible
   that each receiver in the group may need knowledge of its individual
   RTT.  In this case, an alternative RTT collection scheme may be
   utilized where receivers collect individual RTT measurements with
   respect to the sender(s) and advertise them to the group or
   sender(s).  Where it is likely that exchange of reliable multicast
   data will occur among the group on a "many-to-many" basis, there are
   alternative measurement techniques that might be employed for

Adamson, et al.             Standards Track                    [Page 29]
RFC 5401                   Multicast NACK BB               November 2008

   increased efficiency [DelayEstimation].  In some cases, there might
   be absolute time synchronization available among the participating
   hosts that may simplify RTT measurement.  There are trade-offs in
   multicast congestion control design that require further
   consideration before a universal recommendation on RTT (or GRTT)
   measurement can be specified.  Regardless of how the RTT information
   is collected (and more specifically GRTT) with respect to congestion
   control or other requirements, the sender will need to advertise its
   current GRTT estimate to the group for various NACK timeouts used by
   receivers.

3.7.1.  One-to-Many Sender GRTT Measurement

   The goal of this form of RTT measurement is for the sender to
   estimate the GRTT among the receivers who are actively participating
   in NACK-based reliable multicast operation.  The set of receivers
   participating in this process may be the entire group or some subset
   of the group determined from another mechanism within the protocol
   instantiation.  An approach to collect this GRTT information follows.

   The sender periodically polls the group with a message (independent
   or "piggy-backed" with other transmissions) containing a "<sendTime>"
   timestamp relative to an internal clock at the sender.  Upon
   reception of this message, the receivers will record this
   "<sendTime>" timestamp and the time (referenced to their own clocks)
   at which it was received "<recvTime>".  When the receiver provides
   feedback to the sender (either explicitly or as part of other
   feedback messages depending upon protocol instantiation
   specification), it will construct a "response" using the formula:

             grttResponse = sendTime + (currentTime - recvTime)

   where the "<sendTime>" is the timestamp from the last probe message
   received from the source and the ("<currentTime> - <recvTime>") is
   the amount of time differential since that request was received until
   the receiver generated the response.

   The sender processes each receiver response by calculating a current
   RTT measurement for the receiver from whom the response was received
   using the following formula:

                   RTT_rcvr = currentTime - grttResponse

   During each periodic "GRTT" probing interval, the source keeps the
   peak round-trip timing measurement ("RTT_peak") from the set of
   responses it has received.  A conservative estimate of "GRTT" is kept

Adamson, et al.             Standards Track                    [Page 30]
RFC 5401                   Multicast NACK BB               November 2008

   to maximize the efficiency of redundant NACK suppression and repair
   aggregation.  The update to the source's ongoing estimate of "GRTT"
   is done observing the following rules:

   1.  If a receiver's response round-trip time ("RTT_rcvr") is greater
       than the current "GRTT" estimate, the "GRTT" is immediately
       updated to this new peak value:

                              GRTT = RTT_rcvr

   2.  At the end of the response collection period (i.e., the GRTT
       probe interval), if the recorded "peak" response ("RTT_peak") is
       less than the current GRTT estimate, the GRTT is updated to:

                       GRTT = MAX(0.9*GRTT, RTT_peak)

   3.  If no feedback is received, the sender "GRTT" estimate remains
       unchanged.

   4.  At the end of the response collection period, the peak tracking
       value ("RTT_peak") is reset to ZERO for subsequent peak
       detection.

   The GRTT collection period (i.e., period of probe transmission) could
   be fixed at a value on the order of that expected for group
   membership and/or network topology dynamics.  For robustness, more
   rapid probing could be used at protocol startup before settling to a
   less frequent, steady-state interval.  Optionally, an algorithm may
   be developed to adjust the GRTT collection period dynamically in
   response to the current estimate of GRTT (or variations in it) and to
   an estimation of packet loss.  The overhead of probing messages could
   then be reduced when the GRTT estimate is stable and unchanging, but
   be adjusted to track more dynamically during periods of variation
   with correspondingly shorter GRTT collection periods.  GRTT
   collection MAY also be coupled with collection of other information
   for congestion control purposes.

   In summary, although NACK repair cycle timeouts are based on GRTT, it
   should be noted that convergent operation of the protocol does not
   depend upon highly accurate GRTT estimation.  The current mechanism
   has proved sufficient in simulations and in the environments where
   NACK-based reliable multicast protocols have been deployed to date.
   The estimate provided by the given algorithm tracks the peak envelope
   of actual GRTT (including operating system effect as well as network
   delays) even in relatively high loss connectivity.  The steady-state
   probing/update interval may potentially be varied to accommodate
   different levels of expected network dynamics in different
   environments.

Adamson, et al.             Standards Track                    [Page 31]
RFC 5401                   Multicast NACK BB               November 2008

3.7.2.  One-to-Many Receiver RTT Measurement

   In this approach, receivers send messages with timestamps to the
   sender.  To control the volume of these receiver-generated messages,
   a suppression mechanism similar to that described for NACK
   suppression my be used.  The "age" of receivers' RTT measurement
   should be kept by receivers and used as a metric in competing for
   feedback opportunities in the suppression scheme.  For example,
   receiver who have not made any RTT measurement or whose RTT
   measurement has aged most should have precedence over other
   receivers.  In turn, the sender may have limited capacity to provide
   an "echo" of the receiver timestamps back to the group, and it could
   use this RTT "age" metric to determine which receivers get
   precedence.  The sender can determine the "GRTT" as described in
   3.7.1 if it provides sender timestamps to the group.  Alternatively,
   receivers who note their RTT is greater than the sender GRTT can
   compete in the feedback opportunity/suppression scheme to provide the
   sender and group with this information.

3.7.3.  Many-to-Many RTT Measurement

   For reliable multicast sessions that involve multiple senders, it may
   be useful to have RTT measurements occur on a true "many-to-many"
   basis rather than have each sender independently tracking RTT.  Some
   protocol efficiency can be gained when receivers can infer an
   approximation of their RTT with respect to a sender based on RTT
   information they have on another sender and that other sender's RTT
   with respect to the new sender of interest.  For example, for
   receiver "a" and senders "b" and "c", it is likely that:

                    RTT(a<->b) <= RTT(a<->c)) + RTT(b<->c)

   Further refinement of this estimate can be conducted if RTT
   information is available to a node concerning its own RTT with
   respect to a small subset of other group members and if information
   concerning RTT among those other group members is learned by the node
   during protocol operation.

3.7.4.  Sender GRTT Advertisement

   To facilitate deterministic protocol operation, the sender should
   robustly advertise its current estimation of "GRTT" to the receiver
   set.  Common, robust knowledge of the sender's current operating GRTT
   estimate among the group will allow the protocol to progress in its
   most efficient manner.  The sender's GRTT estimate can be robustly
   advertised to the group by simply embedding the estimate into all
   pertinent messages transmitted by the sender.  The overhead of this
   can be made quite small by quantizing (compressing) the GRTT estimate

Adamson, et al.             Standards Track                    [Page 32]
RFC 5401                   Multicast NACK BB               November 2008

   to a single byte of information.  The following C-language functions
   allow this to be done over a wide range ("RTT_MIN" through "RTT_MAX")
   of GRTT values while maintaining a greater range of precision for
   small values and less precision for large values.  Values of 1.0e-06
   seconds and 1000 seconds are RECOMMENDED for "RTT_MIN" and "RTT_MAX"
   respectively.  NACK-based reliable multicast applications may wish to
   place an additional, smaller upper limit on the GRTT advertised by
   senders to meet application data delivery latency constraints at the
   expense of greater feedback volume in some network environments.

       unsigned char QuantizeGrtt(double grtt)
       {
           if (grtt > RTT_MAX)
               grtt = RTT_MAX;
           else if (grtt < RTT_MIN)
               grtt = RTT_MIN;
           if (grtt < (33*RTT_MIN))
               return ((unsigned char)(grtt / RTT_MIN) - 1);
           else
               return ((unsigned char)(ceil(255.0 -
                                       (13.0 * log(RTT_MAX/grtt)))));
       }

       double UnquantizeRtt(unsigned char qrtt)
       {
           return ((qrtt <= 31) ?
                   (((double)(qrtt+1))*(double)RTT_MIN) :
                   (RTT_MAX/exp(((double)(255-qrtt))/(double)13.0)));
       }

   Note that this function is useful for quantizing GRTT times in the
   range of 1 microsecond to 1000 seconds.  Of course, NACK-based
   reliable multicast protocol implementations may wish to further
   constrain advertised GRTT estimates (e.g., limit the maximum value)
   for practical reasons.

3.8.  Group Size Determination/Estimation

   When NACK-based reliable multicast protocol operation includes
   mechanisms that excite feedback from the group at large (e.g.,
   congestion control), it may be possible to roughly estimate the group
   size based on the number of feedback messages received with respect
   to the distribution of the probabilistic suppression mechanism used.
   Note the timer-based suppression mechanism described in this document
   does not require a very accurate estimate of group size to perform
   adequately.  Thus, a rough estimate, particularly if conservatively
   managed, may suffice.  Group size may also be determined
   administratively.  In absence of any group size determination

Adamson, et al.             Standards Track                    [Page 33]
RFC 5401                   Multicast NACK BB               November 2008

   mechanism, a default group size value of 10,000 is RECOMMENDED for
   reasonable management of feedback given the scalability of expected
   NACK-based reliable multicast usage.  This conservative estimate
   (over-estimate) of group size in the algorithms described above will
   result in some added latency to the NACK repair process if the actual
   group size is smaller but with a guarantee of feedback implosion
   protection.  The study of the timer-based feedback suppression
   mechanism described in [McastFeedback] and [NormFeedback] showed that
   the group size estimate need only be with an order-of-magnitude to
   provide effective suppression performance.

3.9.  Congestion Control Operation

   Congestion control that fairly shares available network capacity with
   other reliable multicast and TCP instantiations is REQUIRED for
   general Internet operation.  The TCP-Friendly Multicast Congestion
   Control (TFMCC) [TfmccPaper] or Pragmatic General Multicast
   Congestion Control (PGMCC) [PgmccPaper] techniques can be applied to
   NACK-based reliable multicast operation to meet this requirement.
   The former technique has been further documented in [RFC4654] and has
   been successfully applied in the NACK-Oriented Reliable Multicast
   Protocol (NORM) [RFC3940].

3.10.  Intermediate System Assistance

   NACK-based multicast protocols may benefit from general purpose
   intermediate system assistance.  In particular, additional NACK
   suppression where intermediate systems can aggregate NACK content (or
   filter duplicate NACK content) from receivers as it is relayed toward
   the sender could enhance NORM group size scalability.  For NACK-based
   reliable multicast protocols using FEC, it is possible that
   intermediate systems may be able to filter FEC repair messages to
   provide an intelligent "subcast" of repair content to different legs
   of the multicast topology depending on the repair needs learned from
   previous receiver NACKs.  Similarly, intermediate systems could
   monitor receiver NACKs and provide repair transmissions on-demand in
   response if sufficient state on the content being transmitted was
   being maintained.  This can reduce the latency and volume of repair
   transmissions when the intermediate system is associated with a
   network link that is particularly problematic with respect to packet
   loss.  These types of assist functions would require intermediate
   system interpretation of transport data unit content identifiers and
   flags.  NACK-based protocol designs should consider the potential for
   intermediate system assistance in the specification of protocol
   messages and operations.  It is likely that intermediate systems
   assistance will be more pragmatic if message parsing requirements are
   modest and if the amount of state an intermediate system is required
   to maintain is relatively small.

Adamson, et al.             Standards Track                    [Page 34]
RFC 5401                   Multicast NACK BB               November 2008

4.  NACK-Based Reliable Multicast Applicability

   The Multicast NACK building block applies to protocols wishing to
   employ negative acknowledgement to achieve reliable data transfer.
   Properly designed NACK-based reliable multicast protocols offer
   scalability advantages for applications and/or network topologies
   where, for various reasons, it is prohibitive to construct a higher
   order delivery infrastructure above the basic Layer 3 IP multicast
   service (e.g., unicast or hybrid unicast/multicast data distribution
   trees).  Additionally, the multicast scalability property of NACK-
   based protocols [RmComparison], [RmClasses] is applicable where broad
   "fan-out" is expected for a single network hop (e.g., cable-TV data
   delivery, satellite, or other broadcast communication services).
   Furthermore, the simplicity of a protocol based on "flat" group-wide
   multicast distribution may offer advantages for a broad range of
   distributed services or dynamic networks and applications.  NACK-
   based reliable multicast protocols can make use of reciprocal (among
   senders and receivers) multicast communication under the any-source
   multicast (ASM) model defined in RFC 1112 [RFC1112], and are capable
   of scalable operation in asymmetric topologies, such as source-
   specific multicast (SSM) [RFC4607], where there may only be unicast
   routing service from the receivers to the sender(s).

   NACK-based reliable multicast protocol operation is compatible with
   transport layer forward error correction coding techniques as
   described in [RFC3453] and congestion control mechanisms such as
   those described in [TfmccPaper] and [PgmccPaper].  A principal
   limitation of NACK-based reliable multicast operation involves group
   size scalability when network capacity for receiver feedback is very
   limited.  It is possible that, with proper protocol design, the
   intermediate system assistance techniques mentioned in Section 2.4
   and described further in Section 3.10 can allow NACK-based approaches
   to scale to larger group sizes.  NACK-based reliable multicast
   operation is also governed by implementation buffering constraints.
   Buffering greater than that required for typical point-to-point
   reliable transport (e.g., TCP) is recommended to allow for disparity
   in the receiver group connectivity and to allow for the feedback
   delays required to attain group size scalability.

   Prior experimental work included various protocol instantiations that
   implemented some of the concepts described in this building block
   document.  This includes the Pragmatic General Multicast (PGM)
   protocol described in [RFC3208] as well as others that were
   documented or deployed outside of IETF activities.  While the PGM
   protocol specification and some other approaches encompassed many of
   the goals of bulk data delivery as described here, this NACK-based
   building block provides a more generalized framework so that
   different application needs can be met by different protocol

Adamson, et al.             Standards Track                    [Page 35]
RFC 5401                   Multicast NACK BB               November 2008

   instantiation variants.  The NACK-based building block approach
   described here includes compatibility with the other protocol
   mechanisms including FEC and congestion control that are described in
   other IETF reliable multicast building block documents.  The NACK
   repair process described in this document can provide performance
   advantages compared to PGM when both are deployed on a pure end-to-
   end basis without intermediate system assistance.  The round-trip
   timing estimation described here and its use in the NACK repair
   process allow protocol operation to more automatically adapt to
   different network environments or operate within environments where
   connectivity is dynamic.  Use of the FEC payload identification
   techniques described in the FEC building block [RFC5052] and specific
   FEC instantiations allow protocol instantiations more flexibility as
   FEC techniques evolve than the specific sequence number data
   identification scheme described in the PGM specification.  Similar
   flexibility is expected if protocol instantiations are designed to
   modularly invoke (at design time, if not run-time) the appropriate
   congestion control building block for different application or
   deployment purposes.

5.  Security Considerations

   NACK-based reliable multicast protocols are expected to be subject to
   the same security vulnerabilities as other IP and IP multicast
   protocols.  However, unlike point-to-point (unicast) transport
   protocols, it is possible that one badly behaving participant can
   impact the transport service experience of others in the group.  For
   example, a malicious receiver node could intentionally transmit NACK
   messages to cause the sender(s) to unnecessarily transmit repairs
   instead of making forward progress with reliable transfer.  Also,
   group-wise messaging to support congestion control or other aspects
   of protocol operation may be subject to similar vulnerabilities.
   Thus, it is highly RECOMMENDED that security techniques such as
   authentication and data integrity checks be applied for NACK-based
   reliable multicast deployments.  Protocol instantiations using this
   building block MUST identify approaches to security that can be used
   to address these and other security considerations.

   NACK-based reliable multicast is compatible with IP security (IPsec)
   authentication mechanisms [RFC4301] that are RECOMMENDED for
   protection against session intrusion and denial of service attacks.
   A particular threat for NACK-based protocols is that of NACK replay
   attacks, which could prevent a multicast sender from making forward
   progress in transmission.  Any standard IPsec mechanisms that can
   provide protection against such replay attacks are RECOMMENDED for
   use.  The IETF Multicast Security (MSEC) Working Group has developed
   a set of recommendations in its "Multicast Extensions to the Security
   Architecture for the Internet Protocol" [IpsecExtensions] that can be

Adamson, et al.             Standards Track                    [Page 36]
RFC 5401                   Multicast NACK BB               November 2008

   applied to appropriately extend IPsec mechanisms to multicast
   operation.  An appendix of this document specifically addresses the
   NACK-Oriented Reliable Multicast protocol service model.  As complete
   support for IPsec multicast operation may potentially follow reliable
   multicast deployment, NACK-based reliable multicast protocol
   instantiations SHOULD consider providing support for their own NACK
   replay attack protection when network layer mechanisms are not
   available.  This MAY be necessary when IPsec implementations are used
   that do not provide multicast replay attack protection when multiple
   sources are present.

   For NACK-based multicast deployments with large receiver groups using
   IPsec, approaches might be developed that use shared, common keys for
   receiver-originated protocol messages to maintain a practical number
   of IPsec Security Associations (SAs).  However, such group-based
   authentication may not be sufficient unless the receiver population
   can be completely trusted.  Additionally, this can make
   identification of badly behaving (although authenticated) receiver
   nodes problematic as such nodes could potentially masquerade as other
   receivers in the group.  In deployments such as this, one SHOULD
   consider use of source-specific multicast (SSM) instead of any-source
   multicast (ASM) models of multicast operation.  SSM operation can
   simplify security challenges in a couple of ways:

   1.  A NACK-based protocol supporting SSM operation can eliminate
       direct receiver-to-receiver signaling.  This dramatically reduces
       the number of security associations that need to be established.

   2.  The SSM sender(s) can provide a centralized management point for
       secure group operation for its respective data flow as the sender
       alone is required to conduct individual host authentication for
       each receiver when group-based authentication does not suffice or
       is not pragmatic to deploy.

   When individual host authentication is required, then it is possible
   receivers could use a digital signature on the IPsec Encapsulating
   Security Protocol (ESP) payload as described in [RFC4359].  Either an
   identity-based signature system or a group-specific public key
   infrastructure could avoid per-receiver state at the sender(s).
   Additionally, implementations MUST also support policies to limit the
   impact of extremely or exceptionally poor-performing (due to bad
   behavior or otherwise) receivers upon overall group operation if this
   is acceptable for the relevant application.

   As described in Section 3.4, deployment of NACK-based reliable
   multicast in some network environments may require identification of
   group members beyond that of IP addressing.  If protocol-specific
   security mechanisms are developed, then it is RECOMMENDED that

Adamson, et al.             Standards Track                    [Page 37]
RFC 5401                   Multicast NACK BB               November 2008

   protocol group member identifiers are used as selectors (as defined
   in [RFC4301]) for the applicable security associations.  When IPsec
   is used, it is RECOMMENDED that the protocol implementation verify
   that the source IP addresses of received packets are valid for the
   given protocol source identifier in addition to usual IPsec
   authentication.  This would prevent a badly behaving (although
   authorized) member from spoofing messages from other legitimate
   members, provided that individual host authentication is supported.

   The MSEC Working Group has also developed automated group keying
   solutions that are applicable to NACK-based reliable multicast
   security.  For example, to support IPsec or other security
   mechanisms, the Group Secure Association Key Management Protocol
   [RFC4535] MAY be used for automated group key management.  The
   technique it identifies for "Group Establishment for Receive-Only
   Members" may be application NACK-based reliable multicast SSM
   operation.

6.  Changes from RFC 3941

   This section lists the changes between the Experimental version of
   this specification, [RFC3941], and this version:

   1.  Change of title to avoid confusion with NORM Protocol
       specification,

   2.  Updated references to related, updated RMT Building Block
       documents, and

   3.  More detailed security considerations.

7.  Acknowledgements

   (and these are not Negative)

   The authors would like to thank George Gross, Rick Jones, and Joerg
   Widmer for their valuable comments on this document.  The authors
   would also like to thank the RMT working group chairs, Roger Kermode
   and Lorenzo Vicisano, for their support in development of this
   specification, and Sally Floyd for her early inputs into this
   document.

Adamson, et al.             Standards Track                    [Page 38]
RFC 5401                   Multicast NACK BB               November 2008

8.  References

8.1.  Normative References

   [RFC1112]             Deering, S., "Host extensions for IP
                         multicasting", STD 5, RFC 1112, August 1989.

   [RFC2119]             Bradner, S., "Key words for use in RFCs to
                         Indicate Requirement Levels", BCP 14, RFC 2119,
                         March 1997.

   [RFC4607]             Holbrook, H. and B. Cain, "Source-Specific
                         Multicast for IP", RFC 4607, August 2006.

8.2.  Informative References

   [ArchConsiderations]  Clark, D. and D. Tennenhouse, "Architectural
                         Considerations for a New Generation of
                         Protocols", Proc. ACM SIGCOMM, pp. 201-208,
                         September 1990.

   [DelayEstimation]     Ozdemir, V., Muthukrishnan, S., and I. Rhee,
                         "Scalable, Low-Overhead Network Delay
                         Estimation", NCSU/AT&T White Paper,
                         February 1999.

   [FECSchemes]          Watson, M., "Basic Forward Error Correction
                         (FEC) Schemes", Work in Progress, July 2008.

   [FecBroadcast]        Metzner, J., "An Improved Broadcast
                         Retransmission Protocol", IEEE Transactions on
                         Communications Vol. Com-32, No. 6, June 1984.

   [FecHybrid]           Gossink, D. and J. Macker, "Reliable Multicast
                         and Integrated Parity Retransmission with
                         Channel Estimation", IEEE Globecomm 1998, 1998.

   [FecSchemes]          Lacan, J., Roca, V., Peltotalo, J., and S.
                         Peltotalo, "Reed-Solomon Forward Error
                         Correction (FEC) Schemes", Work in Progress,
                         November 2007.

   [IpsecExtensions]     Weis, B., Gross, G., and D. Ignjatic,
                         "Multicast Extensions to the Security
                         Architecture for the Internet Protocol", Work
                         in Progress, June 2008.

Adamson, et al.             Standards Track                    [Page 39]
RFC 5401                   Multicast NACK BB               November 2008

   [McastFeedback]       Nonnenmacher, J. and E. Biersack, "Optimal
                         Multicast Feedback", IEEE Infocom p. 964,
                         March/April 1998.

   [NormFeedback]        Adamson, B. and J. Macker, "Quantitative
                         Prediction of NACK-Oriented Reliable Multicast
                         (NORM) Feedback", IEEE MILCOM 2002,
                         October 2002.

   [PgmccPaper]          Rizzo, L., "pgmcc: A TCP-Friendly Single-Rate
                         Multicast Congestion Control Scheme", ACM
                         SIGCOMM 2000, August 2000.

   [RFC2357]             Mankin, A., Romanov, A., Bradner, S., and V.
                         Paxson, "IETF Criteria for Evaluating Reliable
                         Multicast Transport and Application Protocols",
                         RFC 2357, June 1998.

   [RFC3208]             Speakman, T., Crowcroft, J., Gemmell, J.,
                         Farinacci, D., Lin, S., Leshchiner, D., Luby,
                         M., Montgomery, T., Rizzo, L., Tweedly, A.,
                         Bhaskar, N., Edmonstone, R., Sumanasekera, R.,
                         and L. Vicisano, "PGM Reliable Transport
                         Protocol Specification", RFC 3208,
                         December 2001.

   [RFC3269]             Kermode, R. and L. Vicisano, "Author Guidelines
                         for Reliable Multicast Transport (RMT) Building
                         Blocks and Protocol Instantiation documents",
                         RFC 3269, April 2002.

   [RFC3453]             Luby, M., Vicisano, L., Gemmell, J., Rizzo, L.,
                         Handley, M., and J. Crowcroft, "The Use of
                         Forward Error Correction (FEC) in Reliable
                         Multicast", RFC 3453, December 2002.

   [RFC3940]             Adamson, B., Bormann, C., Handley, M., and J.
                         Macker, "Negative-acknowledgment (NACK)-
                         Oriented Reliable Multicast (NORM) Protocol",
                         RFC 3940, November 2004.

   [RFC3941]             Adamson, B., Bormann, C., Handley, M., and J.
                         Macker, "Negative-Acknowledgment (NACK)-
                         Oriented Reliable Multicast (NORM) Building
                         Blocks", RFC 3941, November 2004.

Adamson, et al.             Standards Track                    [Page 40]
RFC 5401                   Multicast NACK BB               November 2008

   [RFC4301]             Kent, S. and K. Seo, "Security Architecture for
                         the Internet Protocol", RFC 4301,
                         December 2005.

   [RFC4359]             Weis, B., "The Use of RSA/SHA-1 Signatures
                         within Encapsulating Security Payload (ESP) and
                         Authentication Header (AH)", RFC 4359,
                         January 2006.

   [RFC4535]             Harney, H., Meth, U., Colegrove, A., and G.
                         Gross, "GSAKMP: Group Secure Association Key
                         Management Protocol", RFC 4535, June 2006.

   [RFC4654]             Widmer, J. and M. Handley, "TCP-Friendly
                         Multicast Congestion Control (TFMCC): Protocol
                         Specification", RFC 4654, August 2006.

   [RFC5052]             Watson, M., Luby, M., and L. Vicisano, "Forward
                         Error Correction (FEC) Building Block",
                         RFC 5052, August 2007.

   [RmClasses]           Levine, B. and J. Garcia-Luna-Aceves, "A
                         Comparison of Known Classes of Reliable
                         Multicast Protocols", Proc. International
                         Conference on Network Protocols (ICNP-
                         96) Columbus, OH, October 1996.

   [RmComparison]        Pingali, S., Towsley, D., and J. Kurose, "A
                         Comparison of Sender-Initiated and Receiver-
                         Initiated Reliable Multicast Protocols", Proc.
                         INFOCOMM San Francisco, CA, October 1993.

   [RmFec]               Macker, J., "Reliable Multicast Transport and
                         Integrated Erasure-based Forward Error
                         Correction", IEEE MILCOM 1997, October 1997.

   [SrmFramework]        Floyd, S., Jacobson, V., McCanne, S., Liu, C.,
                         and L. Zhang, "A Reliable Multicast Framework
                         for Light-weight Sessions and Application Level
                         Framing", Proc. ACM SIGCOMM, August 1995.

   [TfmccPaper]          Widmer, J. and M. Handley, "Extending Equation-
                         Based Congestion Control to Multicast
                         Applications", ACM SIGCOMM 2001, August 2001.

Adamson, et al.             Standards Track                    [Page 41]
RFC 5401                   Multicast NACK BB               November 2008

Authors' Addresses

   Brian Adamson
   Naval Research Laboratory
   Washington, DC  20375

   EMail: adamson@itd.nrl.navy.mil

   Carsten Bormann
   Universitaet Bremen TZI
   Postfach 330440
   D-28334 Bremen, Germany

   EMail: cabo@tzi.org

   Mark Handley
   University College London
   Gower Street
   London,   WC1E 6BT
   UK

   EMail: M.Handley@cs.ucl.ac.uk

   Joe Macker
   Naval Research Laboratory
   Washington, DC  20375

   EMail: macker@itd.nrl.navy.mil

Adamson, et al.             Standards Track                    [Page 42]