Movatterモバイル変換

Network Working Group                                         B. AdamsonRequest for Comments: 5401                     Naval Research LaboratoryObsoletes:3941                                               C. BormannCategory: Standards Track                        Universitaet Bremen TZI                                                              M. Handley                                               University College London                                                               J. Macker                                               Naval Research Laboratory                                                           November 2008Multicast Negative-Acknowledgment (NACK) Building BlocksStatus of This Memo   This document specifies an Internet standards track protocol for the   Internet community, and requests discussion and suggestions for   improvements.  Please refer to the current edition of the "Internet   Official Protocol Standards" (STD 1) for the standardization state   and status of this protocol.  Distribution of this memo is unlimited.Copyright Notice   Copyright (c) 2008 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 78 and the IETF Trust's Legal   Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document.   Please review these documents carefully, as they describe your rights   and restrictions with respect to this document.Abstract   This document discusses the creation of reliable multicast protocols   that utilize negative-acknowledgment (NACK) feedback.  The rationale   for protocol design goals and assumptions are presented.  Technical   challenges for NACK-based (and in some cases general) reliable   multicast protocol operation are identified.  These goals and   challenges are resolved into a set of functional "building blocks"   that address different aspects of reliable multicast protocol   operation.  It is anticipated that these building blocks will be   useful in generating different instantiations of reliable multicast   protocols.  This document obsoletesRFC 3941.Adamson, et al.             Standards Track                     [Page 1]

RFC 5401                   Multicast NACK BB               November 2008Table of Contents1. Introduction ....................................................21.1. Requirements Language ......................................42. Rationale .......................................................42.1. Delivery Service Model .....................................52.2. Group Membership Dynamics ..................................62.3. Sender/Receiver Relationships ..............................62.4. Group Size Scalability .....................................62.5. Data Delivery Performance ..................................72.6. Network Environments .......................................72.7. Intermediate System Assistance .............................83. Functionality ...................................................83.1. Multicast Sender Transmission .............................113.2. NACK Repair Process .......................................133.3. Multicast Receiver Join Policies and Procedures ...........263.4. Node (Member) Identification ..............................263.5. Data Content Identification ...............................273.6. Forward Error Correction (FEC) ............................283.7. Round-Trip Timing Collection ..............................293.8. Group Size Determination/Estimation .......................333.9. Congestion Control Operation ..............................343.10. Intermediate System Assistance ...........................344. NACK-Based Reliable Multicast Applicability ....................355. Security Considerations ........................................366. Changes fromRFC 3941 ..........................................387. Acknowledgements ...............................................388. References .....................................................398.1. Normative References ......................................398.2. Informative References ....................................391.  Introduction   Reliable multicast transport is a desirable technology for efficient   and reliable distribution of data to a group on the Internet.  The   complexities of group communication paradigms necessitate different   protocol types and instantiations to meet the range of performance   and scalability requirements of different potential reliable   multicast applications and users (see [RFC2357]).  This document   addresses the creation of reliable multicast protocols that utilize   negative-acknowledgment (NACK) feedback.  NACK-based protocols   generally entail less frequent feedback messaging than reliability   protocols based on positive acknowledgment (ACK).  The less frequent   feedback messaging helps simplify the problem of feedback implosion   as group size grows larger.  While different protocol instantiations   may be required to meet specific application and network architecture   demands [ArchConsiderations], there are a number of fundamental   components that may be common to these different instantiations.Adamson, et al.             Standards Track                     [Page 2]

RFC 5401                   Multicast NACK BB               November 2008   This document describes the framework and common "building block"   components relevant to multicast protocols that are based primarily   on NACK operation for reliable transport.  While this document   discusses a large set of reliable multicast components and issues   relevant to NACK-based reliable multicast protocol design, it   specifically addresses in detail the following building blocks, which   are not addressed in other IETF documents:   1.  NACK-based multicast sender transmission strategies,   2.  NACK repair process with timer-based feedback suppression, and   3.  Round-trip timing for adapting NACK and other timers.   NACK-based reliable multicast implementations SHOULD make use of   Forward Error Correction (FEC) erasure coding techniques, as   described in the FEC Building Block [RFC5052] document.  Packet-level   erasure coding allows missing packets from a given FEC block to be   recovered using the parity packets instead of classical,   individualized retransmission of original source data content.  For   this reason, this document refers to the protocol mechanisms for   reliability as a "repair process."  Note that NACK-based protocols   can reactively provide the parity packets in response to receiver   requests for repair rather than just proactively sending added FEC   parity content as part of the original transmission.  Hybrid   proactive/reactive use of FEC content is also possible with the   mechanisms described in this document.  Some classes of FEC coding,   such as Maximal Separable Distance (MDS) codes, allow senders to   dynamically implement deterministic, highly efficient receiver group   repair strategies as part of a NACK-based, selective automated   repeat-request (ARQ) scheme.   The potential relationships to other reliable multicast transport   building blocks (e.g., FEC, congestion control) and general issues   with NACK-based reliable multicast protocols are also discussed.   This document follows the guidelines provided in [RFC3269].   Statement of Intent   This memo contains descriptions of building blocks that can be   applied in the design of reliable multicast protocols utilizing   negative-acknowledgement (NACK) feedback.  [RFC3941] contains a   previous description of this specification.RFC 3941 was published   in the "Experimental" category.  It was the stated intent of the   Reliable Multicast Transport (RMT) working group at that time to   resubmit this specification as an IETF Proposed Standard in due   course.Adamson, et al.             Standards Track                     [Page 3]

RFC 5401                   Multicast NACK BB               November 2008   This Proposed Standard specification is thus based on [RFC3941] and   has been updated according to accumulated experience and growing   protocol maturity since the publication ofRFC 3941.  Said experience   applies both to this specification itself and to congestion control   strategies related to the use of this specification.   The differences between [RFC3941] and this document are listed inSection 6.1.1.  Requirements Language   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this   document are to be interpreted as described in [RFC2119].2.  Rationale   Each potential protocol instantiation using the building blocks   presented here (and in other applicable building block documents)   will have specific criteria that may influence individual protocol   design.  To support the development of applicable building blocks, it   is useful to identify and summarize driving general protocol design   goals and assumptions.  These are areas that each protocol   instantiation will need to address in detail.  Each building block   description in this document will include a discussion of the impact   of these design criteria.  The categories of design criteria   considered here include:   1.  Delivery Service Model,   2.  Group Membership Dynamics,   3.  Sender/Receiver Relationships,   4.  Group Size Scalability,   5.  Data Delivery Performance, and   6.  Network Environments.   All of these areas are at least briefly discussed.  Additionally,   other reliable multicast transport building block documents, such as   [RFC5052], have been created to address areas outside of the scope of   this document.  NACK-based reliable multicast protocol instantiations   may depend upon these other building blocks as well as the ones   presented here.  This document focuses on areas that are unique to   NACK-based reliable multicast but may be used in concert with the   other building block areas.  In some cases, a building block may beAdamson, et al.             Standards Track                     [Page 4]

RFC 5401                   Multicast NACK BB               November 2008   able to address a wide range of assumptions, while in other cases   there will be trade-offs required to meet different application needs   or operating environments.  Where necessary, building block features   are designed to be parametric to meet different requirements.  Of   course, an underlying goal will be to minimize design complexity and   to at least recommend default values for any such parameters that   meet a general purpose "bulk data transfer" requirement in a typical   Internet environment.  The forms of "bulk data transfer" covered here   include reliable transport of bulky, fixed-length, a priori static   content and also transmission of non-predetermined, perhaps streamed,   content of indefinite length.Section 3.5 discusses these different   forms of bulk data content in further detail.2.1.  Delivery Service Model   The implicit goal of a reliable multicast transport protocol is the   reliable delivery of data among a group of members communicating   using IP multicast datagram service.  However, the specific service   the application is attempting to provide can impact design decisions.   The most basic service model for reliable multicast transport is that   of "bulk transfer", which is a primary focus of this and other   related RMT working group documents.  However, the same principles in   protocol design may also be applied to other service models, e.g.,   more interactive exchanges of small messages such as with white-   boarding or text chat.  Within these different models there are   issues such as the sender's ability to cache transmitted data (or   state referencing it) for retransmission or repair.  The needs for   ordering and/or causality in the sequence of transmissions and   receptions among members in the group may be different depending upon   data content.  The group communication paradigm differs significantly   from the point-to-point model in that, depending upon the data   content type, some receivers may complete reception of a portion of   data content and be able to act upon it before other members have   received the content.  This may be acceptable (or even desirable) for   some applications but not for others.  These varying requirements   drive the need for a number of different protocol instantiation   designs.  A significant challenge in developing generally useful   building block mechanisms is accommodating even a limited range of   these capabilities without defining specific application-level   details.   Another factor impacting the delivery service model is the potential   for different receivers in the multicast group to have significantly   differing quality of network connectivity.  This may involve   receivers with very limited goodput due to connection rate or   substantial packet loss.  NACK-based protocol implementations may   wish to provide policies by which extremely poor-performing receivers   are excluded from the main group or migrated to a separate deliveryAdamson, et al.             Standards Track                     [Page 5]

RFC 5401                   Multicast NACK BB               November 2008   group.  Note that some application models may require that the entire   group be constrained to the performance of the "weakest member" to   satisfy operational requirements.  In either case, protocol designs   should consider this aspect of the reliable multicast delivery   service model.2.2.  Group Membership Dynamics   One area where group communication can differ from point-to-point   communications is that even if the composition of the group changes,   the "thread" of communication can still exist.  This contrasts with   the point-to-point communication model where, if either of the two   parties leave, the communication process (exchange of data) is   terminated (or at least paused).  Depending upon application goals,   senders and receivers participating in a reliable multicast transport   "session" may be able to join late, leave, and/or potentially rejoin   while the ongoing group communication "thread" still remains   functional and useful.  Also note that this can impact protocol   message content.  If "late joiners" are supported, some amount of   additional information may be placed in message headers to   accommodate this functionality.  Alternatively, the information may   be sent in its own message (on demand or intermittently) if the   impact to the overhead of typical message transmissions is deemed too   great.  Group dynamics can also impact other protocol mechanisms such   as NACK timing, congestion control operation, etc.2.3.  Sender/Receiver Relationships   The relationship of senders and receivers among group members   requires consideration.  In some applications, there may be a single   sender multicasting to a group of receivers.  In other cases, there   may be more than one sender or the potential for everyone in the   group to be a sender and receiver of data may exist.2.4.  Group Size Scalability   Native IP multicast [RFC1112] may scale to extremely large group   sizes.  It may be desirable for some applications to scale along with   the multicast infrastructure's ability to scale.  In its simplest   form, there are limits to the group size to which a NACK-based   protocol can be applied without the potential for the volume of NACK   feedback messages to overwhelm network capacity.  This is often   referred to as "feedback implosion".  Research suggests that NACK-   based reliable multicast group sizes on the order of tens of   thousands of receivers may operate with acceptable levels of feedback   to the sender using probabilistic, timer-based suppression techniques   [NormFeedback].  Instead of receivers immediately transmitting   feedback messages when loss is detected, these techniques specify useAdamson, et al.             Standards Track                     [Page 6]

RFC 5401                   Multicast NACK BB               November 2008   of purposefully-scaled, random back-off timeouts such that some   potential NACKing receivers can self-suppress their feedback upon   hearing messages from other receivers that have selected shorter   random timeout intervals.  However, there may be additional NACK   suppression heuristics that can be applied to enable these protocols   to scale to even larger group sizes.  In large scale cases, it may be   prohibitive for members to maintain state on all other members (in   particular, other receivers) in the group.  The impact of group size   needs to be considered in the development of applicable building   blocks.   Group size scalability may also be aided by intermediate system   assistance; seesection 2.7 below.2.5.  Data Delivery Performance   There is a trade-off between scalability and data delivery latency   when designing NACK-oriented protocols.  If probabilistic, timer-   based NACK suppression is to be used, there will be some delays built   into the NACK process to allow suppression to occur and to allow the   sender of data to identify appropriate content for efficient repair   transmission.  For example, back-off timeouts can be used to ensure   efficient NACK suppression and repair transmission, but this comes at   the cost of increased delivery latency and increased buffering   requirements for both senders and receivers.  The building blocks   SHOULD allow applications to establish bounds for data delivery   performance.  Note that application designers must be aware of the   scalability trade-off that is made when such bounds are applied.2.6.  Network Environments   The Internet Protocol has historically assumed a role of providing   service across heterogeneous network topologies.  It is desirable   that a reliable multicast protocol be capable of effectively   operating across a wide range of the networks to which general   purpose IP service applies.  The bandwidth available on the links   between the members of a single group today may vary between low   numbers of kbit/s for wireless links and multiple Gbit/s for high   speed LAN connections, with varying degrees of contention from other   flows.  Recently, a number of asymmetric network services including   56K/ADSL modems, CATV Internet service, satellite, and other wireless   communication services have begun to proliferate.  Many of these are   inherently broadcast media with potentially large "fan-out" to which   IP multicast service is highly applicable.  Additionally, policy   and/or technical issues may result in topologies where multicast   connectivity is limited to a source-specific multicast (SSM) model   from a specific source [RFC4607].  Receivers in the group may beAdamson, et al.             Standards Track                     [Page 7]

RFC 5401                   Multicast NACK BB               November 2008   restricted to unicast feedback for NACKs and other messages.   Consideration must be given, in building block development and   protocol design, to the nature of the underlying networks.2.7.  Intermediate System Assistance   Intermediate assistance from devices/systems with direct knowledge of   the underlying network topology may be used to increase the   performance and scalability of NACK-based reliable multicast   protocols.  Feedback aggregation and filtering of sender repair data   may be possible with NACK-based protocols using FEC-based repair   strategies as described in the present and other reliable multicast   transport building block documents.  However, there will continue to   be a number of instances where intermediate system assistance is not   available or practical.  Any building block components for NACK-   oriented reliable multicast SHALL be capable of operating without   such assistance.  However, it is RECOMMENDED that such protocols also   consider utilizing these features when available.3.  Functionality   The previous section has presented the role of protocol building   blocks and some of the criteria that may affect NACK-based reliable   multicast building block identification/design.  This section   describes different building block areas applicable to NACK-based   reliable multicast protocols.  Some of these areas are specific to   NACK-based protocols.  Detailed descriptions of such areas are   provided.  In other cases, the areas (e.g., node identifiers, forward   error correction (FEC), etc.) may be applicable to other forms of   reliable multicast.  In those cases, the discussion below describes   requirements placed on those general building block areas from the   standpoint of NACK-based reliable multicast.  Where applicable, other   building block documents are referenced for possible contribution to   NACK-based reliable multicast protocols.   For each building block, a notional "interface description" is   provided to illustrate any dependencies of one building block   component upon another or upon other protocol parameters.  A building   block component may require some form of "input" from another   building block component or other source to perform its function.   Any "inputs" required by a building block component and/or any   resultant "output" provided will be defined and described in each   building block component's interface description.  Note that the set   of building blocks presented here do not fully satisfy each other's   "input" and "output" needs.  In some cases, "inputs" for the building   blocks here must come from other building blocks external to this   document (e.g., congestion control or FEC).  In other cases NACK-Adamson, et al.             Standards Track                     [Page 8]

RFC 5401                   Multicast NACK BB               November 2008   based reliable multicast building block "inputs" must be satisfied by   the specific protocol instantiation or implementation (e.g.,   application data and control).   The following building block components relevant to NACK-based   reliable multicast are identified:   NORM (NACK-Oriented Reliable Multicast)-Specific   1.  Multicast Sender Transmission   2.  NACK Repair Process   3.  Multicast Receiver Join Policies and Procedures   General Purpose   1.  Node (Member) Identification   2.  Data Content Identification   3.  Forward Error Correction (FEC)   4.  Round-Trip Timing Collection   5.  Group Size Determination/Estimation   6.  Congestion Control Operation   7.  Intermediate System Assistance   8.  Ancillary Protocol Mechanisms   Figure 1 provides a pictorial overview of these building block areas   and some of their relationships.  For example, the content of the   data messages that a sender initially transmits depends upon the   "Node Identification", "Data Content Identification", and "FEC"   components, while the rate of message transmission will generally   depend upon the "Congestion Control" component.  Subsequently, the   receivers' response to these transmissions (e.g., NACKing for repair)   will depend upon the data message content and inputs from other   building block components.  Finally, the sender's processing of   receiver responses will feed back into its transmission strategy.   The components on the left side of this figure are areas that may be   applicable beyond NACK-based reliable multicast.  The more   significant of these components are discussed in other building block   documents, such as the FEC Building Block [RFC5052].  BriefAdamson, et al.             Standards Track                     [Page 9]

RFC 5401                   Multicast NACK BB               November 2008   descriptions of these areas and their roles in NACK-based reliable   multicast protocols are given below, and "RTT Collection" is   discussed in detail inSection 3.7 of this document.   The components on the right are seen as specific to NACK-based   reliable multicast protocols, most notably the NACK repair process.   These areas are discussed in detail below (most notably, "Multicast   Sender Transmission" and "NACK Repair Process" in Sections3.1 and   3.2).  Some other components (e.g., "Security") impact many aspects   of the protocol, and others may be more transparent to the core   protocol processing.  Where applicable, specific technical   recommendations are made for mechanisms that will properly satisfy   the goals of NACK-based reliable multicast transport for the   Internet.Adamson, et al.             Standards Track                    [Page 10]

RFC 5401                   Multicast NACK BB               November 2008                                 Application Data and Control                                              |                                              v       .---------------------.           .-----------------------.       | Node Identification |-------+-->|  Sender Transmission  |<---.       `---------------------'       |   `-----------------------'    |       .---------------------.       |        |  .------------------. |       | Data Identification |-------+        |  | Rcvr Join Policy | |       `---------------------'       |        V  `------------------' |       .---------------------.       |   .----------------------.     |    .->| Congestion Control  |-------+   | Receiver NACK        |     |    |  `---------------------'       |   | Repair Process       |     |    |  .---------------------.       |   | .------------------. |     |    |  |                     |-------'   | | NACK Initiation  | |     |    |  |        FEC          |-----.     | `------------------' |     |    |  |                     |--.  |     | .------------------. |     |    |  `---------------------'  |  |     | | NACK Content     | |     |    |  .---------------------.  |  |     | `------------------' |     |    `--|    RTT Collection   |--|--+---->| .------------------. |     |       |                     |--+  |     | | NACK Suppression | |     |       `---------------------'  |  |     | `------------------' |     |       .---------------------.  |  |     `----------------------'     |       |    Group Size Est.  |--|--'          |  .-----------------.  |       |                     |--+             |  |  Intermediate   |  |       `---------------------'  |             |  |  System Assist  |  |       .---------------------.  |             v  `-----------------'  |       |       Other         |  |        .-------------------------.  |       `---------------------'  `------->| Sender NACK Processing  |--'                                         |   and Repair Response   |                                         `-------------------------'                       ^                         ^                       |                         |                     .-----------------------------.                     |         (Security)          |                     `-----------------------------'     Figure 1: NACK-Based Reliable Multicast Building Block Framework3.1.  Multicast Sender Transmission   Reliable multicast senders will transmit data content to the   multicast session.  The data content will be application dependent.   The sender will transmit data content at a rate, and with message   sizes, determined by application and/or network architecture   requirements.  Any FEC encoding of sender transmissions SHOULD   conform with the guidelines of the FEC Building Block [RFC5052].   When congestion control mechanisms are needed (REQUIRED for general   Internet operation), the sender transmission rate SHALL be controlledAdamson, et al.             Standards Track                    [Page 11]

RFC 5401                   Multicast NACK BB               November 2008   by the congestion control mechanism.  In any case, it is RECOMMENDED   that all data transmissions from multicast senders be subject to rate   limitations determined by the application or congestion control   algorithm.  The sender's transmissions SHOULD make good utilization   of the available capacity (which may be limited by the application   and/or by congestion control).  As a result, it is expected there   will be overlap and multiplexing of new data content transmission   with repair content.  Other factors related to application operation   may determine sender transmission formats and methods.  For example,   some consideration needs to be given to the sender's behavior during   intermittent idle periods when it has no data to transmit.   In addition to data content, other sender messages or commands may be   employed as part of protocol operation.  These messages may occur   outside of the scope of application data transfer.  In NACK-based   reliable multicast protocols, reliability of such protocol messages   may be attempted by redundant transmission when positive   acknowledgement is prohibitive due to group size scalability   concerns.  Note that protocol design SHOULD provide mechanisms for   dealing with cases where such messages are not received by the group.   As an example, a command message might be redundantly transmitted by   a sender to indicate that it is temporarily (or permanently) halting   transmission.  At this time, it may be appropriate for receivers to   respond with NACKs for any outstanding repairs they require,   following the rules of the NACK procedure.  For efficiency, the   sender should allow sufficient time between the redundant   transmissions to receive any NACK responses from the receivers to   this command.   In general, when there is any resultant NACK or other feedback   operation, the timing of redundant transmission of control messages   issued by a sender and other NACK-based reliable multicast protocol   timeouts should be dependent upon the group greatest round-trip   timing (GRTT) estimate and any expected resultant NACK or other   feedback operation.  The sender GRTT is an estimate of the worst-case   round-trip timing from a given sender to any receivers in the group.   It is assumed that the GRTT interval is a conservative estimate of   the maximum span (with respect to delay) of the multicast group   across a network topology with respect to a given sender.  NACK-based   reliable multicast instantiations SHOULD be able to dynamically adapt   to a wide range of multicast network topologies.   Inputs:   1.  Application data and control.   2.  Sender node identifier.Adamson, et al.             Standards Track                    [Page 12]

RFC 5401                   Multicast NACK BB               November 2008   3.  Data identifiers.   4.  Segmentation and FEC parameters.   5.  Transmission rate.   6.  Application controls.   7.  Receiver feedback messages (e.g., NACKs).   Outputs:   1.  Controlled transmission of messages with headers uniquely       identifying data or repair content within the context of the       reliable multicast session.   2.  Commands indicating sender's status or other transport control       actions to be taken.3.2.  NACK Repair Process   A critical component of NACK-based reliable multicast protocols is   the NACK repair process.  This includes both the receiver's role in   detecting and requesting repair needs and the sender's response to   such requests.  There are four primary elements of the NACK repair   process:   1.  Receiver NACK process initiation,   2.  NACK suppression,   3.  NACK message content,   4.  Sender NACK processing and repair response.3.2.1.  Receiver NACK Process Initiation   The NACK process (cycle) will be initiated by receivers that detect a   need for repair transmissions from a specific sender to achieve   reliable reception.  When FEC is applied, a receiver should initiate   the NACK process only when it is known its repair requirements exceed   the amount of pending FEC transmission for a given coding block of   data content.  This can be determined at the end of the current   transmission block (if it is indicated) or upon the start of   reception of a subsequent coding block or transmission object.  This   implies the sender data content is marked to identify its FEC block   number and that ordinal relationship is preserved in order of   transmission.Adamson, et al.             Standards Track                    [Page 13]

RFC 5401                   Multicast NACK BB               November 2008   Alternatively, if the sender's transmission advertises the quantity   of repair packets it is already planning to send for a block, the   receiver may be able to initiate the NACK process earlier.  Allowing   receivers to initiate NACK cycles at any time they detect their   repair needs have exceeded pending repair transmissions may result in   slightly quicker repair cycles.  However, it may be useful to limit   NACK process initiation to specific events, such as at the end-of-   transmission of an FEC coding block or upon detection of subsequent   coding blocks.  This can allow receivers to aggregate NACK content   into a smaller number of NACK messages and provide some implicit   loose synchronization among the receiver set to help facilitate   effective probabilistic suppression of NACK feedback.  The receiver   MUST maintain a history of data content received from the sender to   determine its current repair needs.  When FEC is employed, it is   expected that the history will correspond to a record of pending or   partially-received coding blocks.   For probabilistic, timer-based suppression of feedback, the NACK   cycle should begin with receivers observing backoff timeouts.  In   conjunction with initiating this backoff timeout, it is important   that the receivers record the position in the sender's transmission   sequence at which they initiate the NACK cycle.  When the suppression   backoff timeout expires, the receivers should only consider their   repair needs up to this recorded transmission position in making the   decision to transmit or suppress a NACK.  Without this restriction,   suppression is greatly reduced as additional content is received from   the sender during the time a NACK message propagates across the   network to the sender and other receivers.   Inputs:   1.  Sender data content with sequencing identifiers from sender       transmissions.   2.  History of content received from sender.   Outputs:   1.  NACK process initiation decision.   2.  Recorded sender transmission sequence position.3.2.2.  NACK Suppression   An effective feedback suppression mechanism is the use of random   backoff timeouts prior to NACK transmission by receivers requiring   repairs [SrmFramework].  Upon expiration of the backoff timeout, a   receiver will request repairs unless its pending repair needs haveAdamson, et al.             Standards Track                    [Page 14]

RFC 5401                   Multicast NACK BB               November 2008   been completely superseded by NACK messages heard from other   receivers (when receivers are multicasting NACKs) or from some   indicator from the sender.  When receivers are unicasting NACK   messages, the sender may facilitate NACK suppression by forwarding a   representation of NACK content it has received to the group at large   or by providing some other indicator of the repair information it   will be subsequently transmitting.   For effective and scalable suppression performance, the backoff   timeout periods used by receivers should be independently, randomly   picked by receivers with a truncated exponential distribution   [McastFeedback].  This results in the majority of the receiver set   holding off transmission of NACK messages under the assumption that   the smaller number of "early NACKers" will supersede the repair needs   of the remainder of the group.  The mean of the distribution should   be determined as a function of the current estimate of the sender's   GRTT assessment and a group size estimate that is either determined   by other mechanisms within the protocol or is preset by the multicast   application.   A simple algorithm can be constructed to generate random backoff   timeouts with the appropriate distribution.  Additionally, the   algorithm may be designed to optimize the backoff distribution given   the number of receivers ("R") potentially generating feedback.  This   "optimization" minimizes the number of feedback messages (e.g., NACK)   in the worst-case situation where all receivers generate a NACK.  The   maximum backoff timeout ("T_maxBackoff") can be set to control   reliable delivery latency versus volume of feedback traffic.  A   larger value of "T_maxBackoff" will result in a lower density of   feedback traffic for a given repair cycle.  A smaller value of   "T_maxBackoff" results in shorter latency, which also reduces the   buffering requirements of senders and receivers for reliable   transport.   In the functions below, the "log()" function specified refers to the   "natural logarithm" and the "exp()" function is similarly based upon   the mathematical constant 'e' (a.k.a.  Euler's number) where "exp(x)"   corresponds to '"e"' raised to the power of '"x"'.  Given the   receiver group size ("groupSize") and maximum allowed backoff timeout   ("T_maxBackoff"), random backoff timeouts ("t'") with a truncated   exponential distribution can be picked with the following algorithm:   1.  Establish an optimal mean ("L") for the exponential backoff based       on the "groupSize":                           L = log(groupSize) + 1Adamson, et al.             Standards Track                    [Page 15]

RFC 5401                   Multicast NACK BB               November 2008   2.  Pick a random number ("x") from a uniform distribution over a       range of:                L                          L                   L        --------------------  to --------------------  +  ----------       T_maxBackoff*(exp(L)-1)  T_maxBackoff*(exp(L)-1)  T_maxBackoff   3.  Transform this random variate to generate the desired random       backoff time ("t'") with the following equation:       t' = T_maxBackoff/L * log(x * (exp(L) - 1) * (T_maxBackoff/L))   This "C" language function can be used to generate an appropriate   random backoff time interval:        double RandomBackoff(double T_maxBackoff, double groupSize)        {            double lambda = log(groupSize) + 1;            double x = UniformRand(lambda/T_maxBackoff) +                       lambda / (T_maxBackoff*(exp(lambda)-1));            return ((T_maxBackoff/lambda) *                    log(x*(exp(lambda)-1)*(T_maxBackoff/lambda)));        }  // end RandomBackoff()   where "UniformRand(double max)" returns random numbers with a uniform   distribution from the range of "0..max".  For example, based on the   POSIX "rand()" function, the following "C" code can be used:           double UniformRand(double max)           {               return (max * ((double)rand()/(double)RAND_MAX));           }   The number of expected NACK messages generated ("N") within the first   round-trip time for a single feedback event is approximately:                  N = exp(1.2 * L / (2*T_maxBackoff/GRTT))   Thus, the maximum backoff time can be adjusted to trade off worst-   case NACK feedback volume versus latency.  This is derived from the   equations given in [McastFeedback] and assumes "T_maxBackoff >=   GRTT", and "L" is the mean of the distribution optimized for the   given group size as shown in the algorithm above.  Note that other   mechanisms within the protocol may work to reduce redundant NACK   generation further.  It is suggested that "T_maxBackoff" be selected   as an integer multiple of the sender's current advertised GRTT   estimate such that:                   T_maxBackoff = K * GRTT; where K >= 1Adamson, et al.             Standards Track                    [Page 16]

RFC 5401                   Multicast NACK BB               November 2008   For general Internet operation, a default value of "K=4" is   RECOMMENDED for operation with multicast (to the group at large) NACK   delivery; a value of "K=6" is the RECOMMENDED default for unicast   NACK delivery.  Alternate values may be used to achieve desired   buffer utilization, reliable delivery latency, and group size   scalability trade-offs.   Given that ("K*GRTT") is the maximum backoff time used by the   receivers to initiate NACK transmission, other timeout periods   related to the NACK repair process can be scaled accordingly.  One of   those timeouts is the amount of time a receiver should wait after   generating a NACK message before allowing itself to initiate another   NACK backoff/transmission cycle ("T_rcvrHoldoff").  This delay should   be sufficient for the sender to respond to the received NACK with   repair messages.  An appropriate value depends upon the amount of   time for the NACK to reach the sender and the sender to provide a   repair response.  This MUST include any amount of sender NACK   aggregation period during which possible multiple NACKs are   accumulated to determine an efficient repair response.  These   timeouts are further discussed inSection 3.2.4.   There are also secondary measures that can be applied to improve the   performance of feedback suppression.  For example, the sender's data   content transmissions can follow an ordinal sequence of transmission.   When repairs for data content occur, the receiver can note that the   sender has "rewound" its data content transmission position by   observing the data object, FEC block number, and FEC symbol   identifiers.  Receivers SHOULD limit transmission of NACKs to only   when the sender's current transmission position exceeds the point to   which the receiver has incomplete reception.  This reduces premature   requests for repair of data the sender may be planning to provide in   response to other receiver requests.  This mechanism can be very   effective for protocol convergence in high loss conditions when   transmissions of NACKs from other receivers (or indicators from the   sender) are lost.  Another mechanism (particularly applicable when   FEC is used) is for the sender to embed an indication of impending   repair transmissions in current packets sent.  For example, the   indication may be as simple as an advertisement of the number of FEC   packets to be sent for the current applicable coding block.   Finally, some consideration might be given to using the NACKing   history of receivers to bias their selection of NACK backoff timeout   intervals.  For example, if a receiver has historically been   experiencing the greatest degree of loss, it may promote itself to   statistically NACK sooner than other receivers.  Note this requires   correlation over successive intervals of time in the loss experienced   by a receiver.  Such correlation MAY not always be present in   multicast networks.  This adjustment of backoff timeout selection mayAdamson, et al.             Standards Track                    [Page 17]

RFC 5401                   Multicast NACK BB               November 2008   require the creation of an "early NACK" slot for these historical   NACKers.  This additional slot in the NACK backoff window will result   in a longer repair cycle process that may not be desirable for some   applications.  The resolution of these trade-offs may be dependent   upon the protocol's target application set or network.   After the random backoff timeout has expired, the receiver will make   a decision on whether to generate a NACK repair request or not (i.e.,   it has been suppressed).  The NACK will be suppressed when any of the   following conditions has occurred:   1.  The accumulated state of NACKs heard from other receivers (or       forwarding of this state by the sender) is equal to or supersedes       the repair needs of the local receiver.  Note that the local       receiver should consider its repair needs only up to the sender       transmission position recorded at the NACK cycle initiation (when       the backoff timer was activated).   2.  The sender's data content transmission position "rewinds" to a       point ordinally less than that of the lowest sequence position of       the local receiver's repair needs.  (This detection of sender       "rewind" indicates the sender has already responded to other       receiver repair needs of which the local receiver may not have       been aware).  This "rewind" event can occur any time between 1)       when the NACK cycle was initiated with the backoff timeout       activation and 2) the current moment when the backoff timeout has       expired to suppress the NACK.  Another NACK cycle must be       initiated by the receiver when the sender's transmission sequence       position exceeds the receiver's lowest ordinal repair point.       Note it is possible that the local receiver may have had its       repair needs satisfied as a result of the sender's response to       the repair needs of other receivers and no further NACKing is       required.   If these conditions have not occurred and the receiver still has   pending repair needs, a NACK message is generated and transmitted.   The NACK should consist of an accumulation of repair needs from the   receiver's lowest ordinal repair point up to the current sender   transmission sequence position.  A single NACK message should be   generated and the NACK message content should be truncated if it   exceeds the payload size of single protocol message.  When such NACK   payload limits occur, the NACK content SHOULD contain requests for   the ordinally lowest repair content needed from the sender.Adamson, et al.             Standards Track                    [Page 18]

RFC 5401                   Multicast NACK BB               November 2008   Inputs:   1.  NACK process initiation decision.   2.  Recorded sender transmission sequence position.   3.  Sender GRTT.   4.  Sender group size estimate.   5.  Application-defined bound on backoff timeout period.   6.  NACKs from other receivers.   7.  Pending repair indication from sender (may be forwarded NACKs).   8.  Current sender transmission sequence position.   Outputs:   1.  Yes/no decision to generate NACK message upon backoff timer       expiration.3.2.3.  NACK Message Content   The content of NACK messages generated by reliable multicast   receivers will include information detailing their current repair   needs.  The specific information depends on the use and type of FEC   in the NACK repair process.  The identification of repair needs is   dependent upon the data content identification (seeSection 3.5   below).  At the highest level, the NACK content will identify the   sender to which the NACK is addressed and the data transport object   (or stream) within the sender's transmission that needs repair.  For   the indicated transport entity, the NACK content will then identify   the specific FEC coding blocks and/or symbols it requires to   reconstruct the complete transmitted data.  This content may consist   of FEC block erasure counts and/or explicit indication of missing   blocks or symbols (segments) of data and FEC content.  It should also   be noted that NACK-based reliable multicast can be effectively   instantiated without a requirement for reliable NACK delivery using   the techniques discussed here.3.2.3.1.  NACK and FEC Repair Strategies   Where FEC-based repair is used, the NACK message content will   minimally need to identify the coding block(s) for which repair is   needed and a count of erasures (missing packets) for the codingAdamson, et al.             Standards Track                    [Page 19]

RFC 5401                   Multicast NACK BB               November 2008   block.  An exact count of erasures implies the FEC algorithm is   capable of repairing any loss combination within the coding block.   This count may need to be adjusted for some FEC algorithms.   Considering that multiple repair rounds may be required to   successfully complete repair, an erasure count also implies that the   quantity of unique FEC parity packets the server has available to   transmit is essentially unlimited (i.e., the server will always be   able to provide new, unique, previously unsent parity packets in   response to any subsequent repair requests for the same coding   block).  Alternatively, the sender may "round-robin" transmit through   its available set of FEC symbols for a given coding block, and   eventually effect repair.  For the most efficient repair strategy,   the NACK content will need to also explicitly identify which symbols   (information and/or parity) the receiver requires to successfully   reconstruct the content of the coding block.  This will be   particularly true of small- to medium-size block FEC codes (e.g.,   Reed Solomon [FecSchemes]) that are capable of providing a limited   number of parity symbols per FEC coding block.   When FEC is not used as part of the repair process, or the protocol   instantiation is required to provide reliability even when the sender   has transmitted all available parity for a given coding block (or the   sender's ability to buffer transmission history is exceeded by the   "(delay*bandwidth*loss)" characteristics of the network topology),   the NACK content will need to contain explicit coding block and/or   segment loss information so that the sender can provide appropriate   repair packets and/or data retransmissions.  Explicit loss   information in NACK content may also potentially serve other   purposes.  For example, it may be useful for decorrelating loss   characteristics among a group of receivers to help differentiate   candidate congestion control bottlenecks among the receiver set.   When FEC is used and NACK content is designed to contain explicit   repair requests, there is a strategy where the receivers can NACK for   specific content that will help facilitate NACK suppression and   repair efficiency.  The assumptions for this strategy are that the   sender may potentially exhaust its supply of new, unique parity   packets available for a given coding block and be required to   explicitly retransmit some data or parity symbols to complete   reliable transfer.  Another assumption is that an FEC algorithm where   any parity packet can fill any erasure within the coding block (e.g.,   Reed Solomon) is used.  The goal of this strategy is to make maximum   use of the available parity and provide the minimal amount of data   and repair transmissions during reliable transfer of data content to   the group.Adamson, et al.             Standards Track                    [Page 20]

RFC 5401                   Multicast NACK BB               November 2008   When systematic FEC codes are used, the sender transmits the data   content of the coding block (and optionally some quantity of parity   packets) in its initial transmission.  Note that a systematic FEC   coding block is considered to be logically made up of the contiguous   set of source data vectors plus parity vectors for the given FEC   algorithm used.  For example, a systematic coding scheme that   provides for 64 data symbols and 32 parity symbols per coding block   would contain FEC symbol identifiers in the range of 0 to 95.   Receivers then can construct NACK messages requesting sufficient   content to satisfy their repair needs.  For example, if the receiver   has three erasures in a given received coding block, it will request   transmission of the three lowest ordinal parity vectors in the coding   block.  In our example coding scheme from the previous paragraph, the   receiver would explicitly request parity symbols 64 to 66 to fill its   three erasures for the coding block.  Note that if the receiver's   loss for the coding block exceeds the available parity quantity   (i.e., greater than 32 missing symbols in our example), the receiver   will be required to construct a NACK requesting all (32) of the   available parity symbols plus some additional portions of its missing   data symbols in order to reconstruct the block.  If this is done   consistently across the receiver group, the resulting NACKs will   comprise a minimal set of sender transmissions to satisfy their   repair needs.   In summary, the rule is to request the lower ordinal portion of the   parity content for the FEC coding block to satisfy the erasure repair   needs on the first NACK cycle.  If the available number of parity   symbols is insufficient, the receiver will also request the subset of   ordinally highest missing data symbols to cover what the parity   symbols will not fill.  Note this strategy assumes FEC codes such as   Reed-Solomon for which a single parity symbol can repair any erased   symbol.  This strategy would need minor modification to take into   account the possibly limited repair capability of other FEC types.   On subsequent NACK repair cycles where the receiver may receive some   portion of its previously requested repair content, the receiver will   use the same strategy, but only NACK for the set of parity and/or   data symbols it has not yet received.  Optionally, the receivers   could also provide a count of erasures as a convenience to the   sender.   Other types of FEC schemes may require alteration to the NACK and   repair strategy described here.  For example, some of the large block   or expandable FEC codes described in [RFC3453] may be less   deterministic with respect to defining optimal repair requests by   receivers or repair transmission strategies by senders.  For these   types of codes, it may be sufficient for receivers to NACK with an   estimate of the quantity of additional FEC symbols required toAdamson, et al.             Standards Track                    [Page 21]

RFC 5401                   Multicast NACK BB               November 2008   complete reliable reception and for the sender to respond   accordingly.  This apparent disadvantage, as compared to codes such   as Reed Solomon, may be offset by the reduced computational   requirements and/or ability to support large coding blocks for   increased repair efficiency that these codes can offer.   After receipt and accumulation of NACK messages during the   aggregation period, the sender can begin transmission of fresh   (previously untransmitted) parity symbols for the coding block based   on the highest receiver erasure count if it has a sufficient quantity   of parity symbols that were not previously transmitted.  Otherwise,   the sender MUST resort to transmitting the explicit set of repair   vectors requested.  With this approach, the sender needs to maintain   very little state on requests it has received from the group without   need for synchronization of repair requests from the group.  Since   all receivers use the same consistent algorithm to express their   explicit repair needs, NACK suppression among receivers is simplified   over the course of multiple repair cycles.  The receivers can simply   compare NACKs heard from other receivers against their own calculated   repair needs to determine whether they should transmit or suppress   their pending NACK messages.3.2.3.2.  NACK Content Format   The format of NACK content will depend on the protocol's data service   model and the format of data content identification the protocol   uses.  This NACK format also depends upon the type of FEC encoding   (if any) used.  Figure 2 illustrates a logical, hierarchical   transmission content identification scheme, denoting that the notion   of objects (or streams) and/or FEC blocking is optional at the   protocol instantiation's discretion.  Note that the identification of   objects is with respect to a given sender.  It is recommended that   transport data content identification is done within the context of a   sender in a given session.  Since the notion of session "streams" and   "blocks" is optional, the framework degenerates to that of typical   transport data segmentation and reassembly in its simplest form.       Session_               \_                 Sender_                        \_                          [Object/Stream(s)]_                                             \_                                               [FEC Blocks]_                                                            \_                                                              Symbols    Figure 2: Reliable Multicast Data Content Identification HierarchyAdamson, et al.             Standards Track                    [Page 22]

RFC 5401                   Multicast NACK BB               November 2008   The format of NACK messages should enable the following:   1.  Identification of transport data units required to repair the       received content, whether this is an entire missing object/stream       (or range), entire FEC coding block(s), or sets of symbols,   2.  Simple processing for NACK aggregation and suppression,   3.  Inclusion of NACKs for multiple objects, FEC coding blocks,       and/or symbols in a single message, and   4.  A reasonably compact format.   If the reliable multicast transport object/stream is identified with   an <objectId> and the FEC symbol being transmitted is identified with   an <fecPayloadId>, the concatenation of <objectId::fecPayloadId>   comprises a basic transport protocol data unit (TPDU) identifier for   symbols from a given source.  NACK content can be composed of lists   and/or ranges of these TPDU identifiers to build up NACK messages to   describe the receiver's repair needs.  If no hierarchical object   delineation or FEC blocking is used, the TPDU is a simple linear   representation of the data symbols transmitted by the sender.  When   the TPDU represents a hierarchy for purposes of object/stream   delineation and/or FEC blocking, the NACK content unit may require   flags to indicate which portion of the TPDU is applicable.  For   example, if an entire "object" (or range of objects) is missing in   the received data, the receiver will not necessarily know the   appropriate range of <sourceBlockNumbers> or <encodingSymbolIds> for   which to request repair and thus requires some mechanism to request   repair (or retransmission) of the entire unit represented by an   <objectId>.  The same is true if entire FEC coding blocks represented   by one or a range of <sourceBlockNumbers> have been lost.   Inputs:   1.  Sender identification.   2.  Sender data identification.   3.  Sender FEC object transmission information.   4.  Recorded sender transmission sequence position.   5.  Current sender transmission sequence position.  History of repair       needs for this sender.Adamson, et al.             Standards Track                    [Page 23]

RFC 5401                   Multicast NACK BB               November 2008   Outputs:   1.  NACK message with repair requests.3.2.4.  Sender NACK Processing and Repair Response   Upon reception of a repair request from a receiver in the group, the   sender will initiate a repair response procedure.  The sender may   wish to delay transmission of repair content until it has had   sufficient time to accumulate potentially multiple NACKs from the   receiver set.  This allows the sender to determine the most efficient   repair strategy for a given transport stream/object or FEC coding   block.  Depending upon the approach used, some protocols may find it   beneficial for the sender to provide an indicator of pending repair   transmissions as part of its current transmitted message content.   This can aid some NACK suppression mechanisms.  The amount of time to   perform this NACK aggregation should be sufficient to allow for the   maximum receiver NACK backoff window (""T_maxBackoff"" fromSection3.2.2) and propagation of NACK messages from the receivers to the   sender.  Note the maximum transmission delay of a message from a   receiver to the sender may be approximately "(1*GRTT)" in the case of   very asymmetric network topology with respect to transmission delay.   Thus, if the maximum receiver NACK backoff time is "T_maxBackoff =   K*GRTT", the sender NACK aggregation period should be equal to at   least:            T_sndrAggregate = T_maxBackoff + 1*GRTT = (K+1)*GRTT   Immediately after the sender NACK aggregation period, the sender will   begin transmitting repair content determined from the aggregate NACK   state and continue with any new transmission.  Also, at this time,   the sender should observe a "hold-off" period where it constrains   itself from initiating a new NACK aggregation period to allow   propagation of the new transmission sequence position due to the   repair response to the receiver group.  To allow for worst case   asymmetry, this "hold-off" time should be:                           T_sndrHoldoff = 1*GRTT   Recall that the receivers will also employ a "hold-off" timeout after   generating a NACK message to allow time for the sender's response.   Given a sender "<T_sndrAggregate>" plus "<T_sndrHoldoff>" time of   "(K+1)*GRTT", the receivers should use hold-off timeouts of:        T_rcvrHoldoff = T_sndrAggregate + T_sndrHoldoff = (K+2)*GRTTAdamson, et al.             Standards Track                    [Page 24]

RFC 5401                   Multicast NACK BB               November 2008   This allows for a worst-case propagation time of the receiver's NACK   to the sender, the sender's aggregation time, and propagation of the   sender's response back to the receiver.  Additionally, in the case of   unicast feedback from the receiver set, it may be useful for the   sender to forward (via multicast) a representation of its aggregated   NACK content to the group to allow for NACK suppression when there is   not multicast connectivity among the receiver set.   At the expiration of the "<T_sndrAggregate>" timeout, the sender will   begin transmitting repair messages according to the accumulated   content of NACKs received.  There are some guidelines with regards to   FEC-based repair and the ordering of the repair response from the   sender that can improve reliable multicast efficiency:   When FEC is used, it is beneficial that the sender transmit   previously untransmitted parity content as repair messages whenever   possible.  This maximizes the receiving nodes' ability to reconstruct   the entire transmitted content from their individual subsets of   received messages.   The transmitted object and/or stream data and repair content should   be indexed with monotonically increasing sequence numbers (within a   reasonably large ordinal space).  If the sender observes the   discipline of transmitting repair for the earliest content (e.g.,   ordinally lowest FEC blocks) first, the receivers can use a strategy   of withholding repair requests for later content until the sender   once again returns to that point in the object/stream transmission   sequence.  This can increase overall message efficiency among the   group and help keep repair cycles relatively synchronized without   dependence upon strict time synchronization among the sender and   receivers.  This also helps minimize the buffering requirements of   receivers and senders and reduces redundant transmission of data to   the group at large.   Inputs:   1.  Receiver NACK messages.   2.  Group timing information.   Outputs:   1.  Repair messages (FEC and/or Data content retransmission).   2.  Advertisement of current pending repair transmissions when       unicast receiver feedback is detected.Adamson, et al.             Standards Track                    [Page 25]

RFC 5401                   Multicast NACK BB               November 20083.3.  Multicast Receiver Join Policies and Procedures   Consideration should be given to the policies and procedures by which   new receivers join a group (perhaps where reliable transmission is   already in progress) and begin requesting repair.  If receiver joins   are unconstrained, the dynamics of group membership may impede the   application's ability to meet its goals for forward progression of   data transmission.  Policies that limit the opportunities for   receivers to begin participating in the NACK process may be used to   achieve the desired behavior.  For example, it may be beneficial for   receivers to attempt reliable reception from a newly-heard sender   only upon non-repair transmissions of data in the first FEC block of   an object or logical portion of a stream.  The sender may also   implement policies limiting the receivers from which it will accept   NACK requests, but this may be prohibitive for scalability reasons in   some situations.  Alternatively, it may be desirable to have a looser   transport synchronization policy and rely upon session management   mechanisms to limit group dynamics that can cause poor performance in   some types of bulk transfer applications (or for potential   interactive reliable multicast applications).   Inputs:   1.  Current object/stream data/repair content and sequencing       identifiers from sender transmissions.   Outputs:   1.  Receiver yes/no decision to begin receiving and NACKing for       reliable reception of data.3.4.  Node (Member) Identification   In a NACK-based reliable multicast protocol (or other multicast   protocols) where there is the potential for multiple sources of data,   it is necessary to provide some mechanism to uniquely identify the   sources (and possibly some or all receivers) within the group.   Receivers that send NACK messages to the group will need to identify   the sender to which the NACK is intended.  Identity based on arriving   packet source addresses is insufficient for several reasons.  These   reasons include routing changes for hosts with multiple interfaces   that result in different packet source addresses for a given host   over time, network address translation (NAT) or firewall devices, or   other transport/network bridging approaches.  As a result, some type   of unique source identifier <sourceId> field SHOULD be present in   packets transmitted by reliable multicast session members.Adamson, et al.             Standards Track                    [Page 26]

RFC 5401                   Multicast NACK BB               November 20083.5.  Data Content Identification   The data and repair content transmitted by a NACK-based reliable   multicast sender requires some form of identification in the protocol   header fields.  This identification is required to facilitate the   reliable NACK-oriented repair process.  These identifiers will also   be used in NACK messages generated.  This building block document   assumes two very general types of data that may comprise bulk   transfer session content.  One type is static, discrete objects of   finite size and the other is continuous non-finite streams.  A given   application may wish to reliably multicast data content using either   one or both of these paradigms.  While it may be possible for some   applications to further generalize this model and provide mechanisms   to encapsulate static objects as content embedded within a stream,   there are advantages in many applications to provide distinct support   for static bulk objects and messages with the context of a reliable   multicast session.  These applications may include content caching   servers, file transfer, or collaborative tools with bulk content.   Applications with requirements for these static object types can then   take advantage of transport layer mechanisms (i.e., segmentation/   reassembly, caching, integrated forward error correction coding,   etc.) rather than being required to provide their own mechanisms for   these functions at the application layer.   As noted, some applications may alternatively desire to transmit bulk   content in the form of one or more streams of non-finite size.   Example streams include continuous quasi-real-time message broadcasts   (e.g., stock ticker) or some content types that are part of   collaborative tools or other applications.  And, as indicated above,   some applications may wish to encapsulate other bulk content (e.g.,   files) into one or more streams within a multicast session.   The components described within this building block document are   envisioned to be applicable to both of these models with the   potential for a mix of both types within a single multicast session.   To support this requirement, the normal data content identification   should include a field to uniquely identify the object or stream   (e.g., <objectId>) within some reasonable temporal or ordinal   interval.  Note that it is not expected that this data content   identification will be globally unique.  It is expected that the   object/stream identifier will be unique with respect to a given   sender within the reliable multicast session and during the time that   sender is supporting a specific transport instance of that object or   stream.   Since "bulk" object/stream content usually requires segmentation,   some form of segment identification must also be provided.  This   segment identifier will be relative to any object or streamAdamson, et al.             Standards Track                    [Page 27]

RFC 5401                   Multicast NACK BB               November 2008   identifier that has been provided.  Thus, in some cases, NACK-based   reliable multicast protocol instantiations may be able to receive   transmissions and request repair for multiple streams and one or more   sets of static objects in parallel.  For protocol instantiations   employing FEC, the segment identification portion of the data content   identifier may consist of a logical concatenation of a coding block   identifier <sourceBlockNumber> and an identifier for the specific   data or parity symbol <encodingSymbolId> of the code block.  The FEC   Basic Schemes building block [FECSchemes] and descriptions of   additional FEC schemes that may be documented later provide a   standard message format for identifying FEC transmission content.   NACK-based reliable multicast protocol instantiations using FEC   SHOULD follow such guidelines.   Additionally, flags to determine the usage of the content identifier   fields (e.g., stream vs. object) may be applicable.  Flags may also   serve other purposes in data content identification.  It is expected   that any flags defined will be dependent upon individual protocol   instantiations.   In summary, the following data content identification fields may be   required for NACK-based reliable multicast protocol data content   messages:   1.  Source node identifier (<sourceId>).   2.  Object/Stream identifier (<objectId>), if applicable.   3.  FEC Block identifier (<sourceBlockNumber>), if applicable.   4.  FEC Symbol identifier (<encodingSymbolId>).   5.  Flags to differentiate interpretation of identifier fields or       identifier structure that implicitly indicates usage.   6.  Additional FEC transmission content fields per FEC Building       Block.   These fields have been identified because any generated NACK messages   will use these identifiers in requesting repair or retransmission of   data.3.6.  Forward Error Correction (FEC)   Multiple forward error correction (FEC) approaches using erasure   coding techniques have been identified that can provide great   performance enhancements to the repair process of NACK-oriented and   other reliable multicast protocols [FecBroadcast], [RmFec],Adamson, et al.             Standards Track                    [Page 28]

RFC 5401                   Multicast NACK BB               November 2008   [RFC3453].  NACK-based reliable multicast protocols can reap   additional benefits since FEC-based repair does not generally require   explicit knowledge of repair content within the bounds of its coding   block size (in symbols).  In NACK-based reliable multicast, parity   repair packets generated will generally be transmitted only in   response to NACK repair requests from receiving nodes.  However,   there are benefits in some network environments for transmitting some   predetermined quantity of FEC repair packets multiplexed with the   regular data symbol transmissions [FecHybrid].  This can reduce the   amount of NACK traffic generated with relatively little overhead cost   when group sizes are very large or the network connectivity has a   large "delay*bandwidth" product with some nominal level of expected   packet loss.  While the application of FEC is not unique to NACK-   based reliable multicast, these sorts of requirements may dictate the   types of algorithms and protocol approaches that are applicable.   A specific issue related to the use of FEC with NACK-based reliable   multicast is the mechanism used to identify the portion(s) of   transmitted data content to which specific FEC packets are   applicable.  It is expected that FEC algorithms will be based on   generating a set of parity repair packets for a corresponding block   of transmitted data packets.  Since data content packets are uniquely   identified by the concatenation of <sourceId::objectId::   sourceBlockNumber::encodingSymbolId> during transport, it is expected   that FEC packets will be identified in a similar manner.  The FEC   Building Block document [RFC5052] provides detailed recommendations   concerning application of FEC and standard formats for related   reliable multicast protocol messages.3.7.  Round-Trip Timing Collection   The measurement of packet propagation round-trip time (RTT) among   members of the group is required to support timer-based NACK   suppression algorithms, timing of sender commands or certain repair   functions, and congestion control operation.  The nature of the   round-trip information collected is dependent upon the type of   interaction among the members of the group.  In the case of "one-to-   many" 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 forAdamson, 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 keptAdamson, 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 20083.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 estimateAdamson, 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 determinationAdamson, 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 20084.  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 inRFC 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 inSection 2.4   and described further inSection 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 protocolAdamson, 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 beAdamson, 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 inSection 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 thatAdamson, 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 fromRFC 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 20088.  References8.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 2008Authors' 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.milAdamson, et al.             Standards Track                    [Page 42]