Multicast Negative-Acknowledgment (NACK) Building Blocks
obsoletes
- rfc-3941 — Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks
Extracted elements (31)
FEC erasure coding is termed a 'repair process' rather than retransmission because any parity packet can fill any erasure within its coding block, enabling deterministic repair strategies without explicit per-receiver loss knowledge. Hybrid proactive/reactive FEC use is possible, and reactive parity delivery in response to NACKs minimizes wasted bandwidth.
NACK-based protocols are preferred over ACK-based protocols for reliable multicast because they generate less frequent feedback messaging, simplifying the feedback implosion problem. Probabilistic timer-based suppression enables scalability to group sizes on the order of tens of thousands of receivers.
NACK process initiation is beneficially limited to specific events such as end-of-transmission of an FEC coding block or detection of a subsequent block. This allows receivers to aggregate NACK content into fewer messages and provides loose synchronization among the receiver set to facilitate effective probabilistic suppression.
The building blocks approach is used because different protocol instantiations are required for different application and network architecture demands, yet fundamental components are common across instantiations. Building blocks can be combined and parameterized to address a wide range of requirements while defaulting to a general-purpose 'bulk data transfer' configuration.
The lowest-ordinal-parity-first NACK strategy is chosen so that all receivers in the group use the same consistent algorithm to express repair needs, simplifying NACK suppression across multiple repair cycles. Receivers can directly compare NACKs heard from others against their own calculated repair needs to decide whether to suppress.
Large block or expandable FEC codes (e.g., RFC 3453) may be less deterministic than Reed-Solomon for specifying optimal repair requests. For such codes, receivers may NACK with an erasure count estimate rather than explicit symbol identifiers, and senders respond accordingly. The reduced determinism may be offset by lower computational requirements or larger coding block support.
Source-Specific Multicast (SSM) topologies may restrict receivers to unicast NACK feedback. When unicast delivery is used, the recommended K value for T_maxBackoff increases from 4 to 6, and the sender should forward a multicast representation of its aggregated NACK content to enable receiver suppression among groups lacking direct multicast connectivity.
Any building block components for NACK-oriented reliable multicast SHALL be capable of operating without intermediate system assistance. It is RECOMMENDED that protocols also consider utilizing intermediate system assistance features when available.
Congestion control that fairly shares available network capacity with other reliable multicast and TCP instantiations is REQUIRED for general Internet operation. TFMCC or PGMCC techniques can be applied to NACK-based reliable multicast to meet this requirement.
For general Internet operation, K=4 is RECOMMENDED for T_maxBackoff with multicast NACK delivery, and K=6 is RECOMMENDED for unicast NACK delivery, where T_maxBackoff = K * GRTT. Alternate values may be used to trade off buffer utilization, delivery latency, and group size scalability.
In the absence of any group size determination mechanism, a default group size value of 10,000 is RECOMMENDED. This conservative over-estimate guarantees feedback implosion protection; the suppression algorithm is effective with group size accuracy to within an order of magnitude.
NACK-based reliable multicast implementations SHOULD make use of Forward Error Correction (FEC) erasure coding techniques as described in RFC 5052. Packet-level erasure coding allows missing packets from a given FEC block to be recovered using parity packets instead of classical, individualized retransmission.
NACK-based reliable multicast protocol instantiations using FEC SHOULD follow the standard message format guidelines for identifying FEC transmission content as provided in the FEC Building Block (RFC 5052) and associated FEC scheme documents.
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 already be planning to transmit in response to other receiver requests.
Some type of unique source identifier <sourceId> field SHOULD be present in packets transmitted by reliable multicast session members. Identity based solely on arriving packet source addresses is insufficient due to routing changes, NAT devices, multiple interfaces, and other network bridging approaches.
The building blocks SHOULD allow applications to establish bounds for data delivery performance. Application designers must be aware of the scalability trade-off that is made when such bounds are applied, as tighter bounds increase feedback volume.
The receiver MUST maintain a history of data content received from the sender to determine its current repair needs. When FEC is employed, this history corresponds to a record of pending or partially-received coding blocks.
Values of 1.0e-06 seconds and 1000 seconds are RECOMMENDED for RTT_MIN and RTT_MAX respectively in GRTT quantization. NACK-based multicast applications may impose an additional smaller upper limit on advertised GRTT to meet delivery latency constraints at the expense of greater feedback volume.
When a NACK message must be truncated due to payload limits, the NACK content SHOULD contain requests for the ordinally lowest repair content needed from the sender. A single NACK message should be generated per cycle.
When congestion control mechanisms are needed, which is REQUIRED for general Internet operation, the sender transmission rate SHALL be controlled by the congestion control mechanism. All data transmissions from multicast senders are RECOMMENDED to be subject to rate limitations determined by the application or congestion control algorithm.
When the sender has insufficient previously untransmitted parity symbols for a coding block, the sender MUST resort to transmitting the explicit set of repair vectors requested by receivers rather than fresh parity symbols.
Data content identification requires: source node identifier <sourceId>, object/stream identifier <objectId>, FEC block identifier <sourceBlockNumber>, FEC symbol identifier <encodingSymbolId>, and flags to differentiate field usage. The same fields appear in both data messages and NACK messages requesting repair.
GRTT is quantized to a single byte for low-overhead embedding in sender messages. The encoding uses linear quantization for small values (grtt < 33*RTT_MIN) and logarithmic quantization for larger values, implemented via QuantizeGrtt() and UnquantizeRtt() functions covering the range RTT_MIN to RTT_MAX.
GRTT update rules: (1) if RTT_rcvr exceeds current GRTT, immediately set GRTT = RTT_rcvr; (2) at end of probe interval if peak RTT_peak < current GRTT, set GRTT = MAX(0.9*GRTT, RTT_peak); (3) if no feedback received, GRTT is unchanged; (4) reset peak tracking value RTT_peak to zero at end of each probe interval.
Sender NACK aggregation period T_sndrAggregate = (K+1)*GRTT accumulates NACKs from the receiver set before initiating repair. Sender hold-off T_sndrHoldoff = 1*GRTT follows. Receiver hold-off T_rcvrHoldoff = (K+2)*GRTT accounts for worst-case NACK propagation, sender aggregation time, and repair response propagation back to the receiver.
The Group Round-Trip Timing (GRTT) is the sender's estimate of the worst-case round-trip time from a given sender to any receiver in the group. NACK suppression timeouts, repair aggregation periods, receiver hold-off timers, and sender command timing all scale as multiples of GRTT. The sender robustly advertises GRTT by embedding it in all pertinent transmitted messages.
The NACK Repair Process comprises four primary elements: (1) receiver NACK process initiation, (2) NACK suppression via random backoff timers, (3) NACK message content identifying repair needs, and (4) sender NACK processing and repair response. This is the critical component distinguishing NACK-based reliable multicast protocols.
Timer-based NACK suppression uses randomly picked backoff timeouts with a truncated exponential distribution parameterized by groupSize and T_maxBackoff. The optimal mean is L = log(groupSize) + 1, and the expected NACK count within one GRTT is approximately N = exp(1.2 * L / (2 * T_maxBackoff / GRTT)).
Transport Protocol Data Unit (TPDU) identifiers are formed by concatenating <objectId::fecPayloadId> per sender. NACK content is composed of lists and/or ranges of TPDU identifiers, enabling compact description of repair needs spanning entire missing objects, FEC coding blocks, or individual symbols.
When FEC is used and receivers construct explicit repair requests, the rule is to request the lowest ordinal parity symbols first to fill erasures on the first NACK cycle. If available parity is insufficient, also request the ordinally highest missing data symbols. On subsequent cycles, request only symbols not yet received, applying the same strategy.
Security is identified as a cross-cutting concern affecting all building block components including sender transmission, the NACK repair process, and intermediate system assistance. The building block framework explicitly depicts Security as underlying the entire protocol stack. Specific security mechanisms are left to individual protocol instantiations.