Request for Comments: 3941 NRL
Category: Experimental C. Bormann
Universitaet Bremen TZI
M. Handley
UCL
J. Macker
NRL
November 2004
Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM)
Building Blocks
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document discusses the creation of negative-acknowledgment
(NACK)-oriented reliable multicast (NORM) protocols. The rationale
for NORM goals and assumptions are presented. Technical challenges
for NACK-oriented (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 NORM protocol operation. It is anticipated that
these building blocks will be useful in generating different
instantiations of reliable multicast protocols.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rationale. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Delivery Service Model . . . . . . . . . . . . . . . . . 4
2.2. Group Membership Dynamics . . . . . . . . . . . . . . . . 5
2.3. Sender/Receiver Relationships . . . . . . . . . . . . . . 5
2.4. Group Size Scalability. . . . . . . . . . . . . . . . . . 6
2.5. Data Delivery Performance . . . . . . . . . . . . . . . . 6
2.6. Network Environments. . . . . . . . . . . . . . . . . . . 6
2.7. Router/Intermediate System Assistance . . . . . . . . . . 7
3. Functionality. . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. NORM Sender Transmission. . . . . . . . . . . . . . . . . 10
3.2. NORM Repair Process . . . . . . . . . . . . . . . . . . . 11
3.2.1. Receiver NACK Process Initiation . . . . . . . . . 11
3.2.2. NACK Suppression . . . . . . . . . . . . . . . . . 13
3.2.3. NACK Content . . . . . . . . . . . . . . . . . . . 17
3.2.3.1. NACK and FEC Repair Strategies. . . . . . 17
3.2.3.2. NACK Content Format . . . . . . . . . . . 20
3.2.4. Sender Repair Response . . . . . . . . . . . . . . 21
3.3. NORM Receiver Join Policies and Procedures. . . . . . . . 23
3.4. Reliable Multicast Member Identification. . . . . . . . . 24
3.5. Data Content Identification . . . . . . . . . . . . . . . 24
3.6. Forward Error Correction (FEC). . . . . . . . . . . . . . 26
3.7. Round-trip Timing Collection. . . . . . . . . . . . . . . 27
3.7.1. One-to-Many Sender GRTT Measurement. . . . . . . . 27
3.7.2. One-to-Many Receiver RTT Measurement . . . . . . . 29
3.7.3. Many-to-Many RTT Measurement . . . . . . . . . . . 29
3.7.4. Sender GRTT Advertisement. . . . . . . . . . . . . 30
3.8. Group Size Determination/Estimation . . . . . . . . . . . 31
3.9. Congestion Control Operation. . . . . . . . . . . . . . . 31
3.10 Router/Intermediate System Assistance . . . . . . . . . . 31
3.11 NORM Applicability. . . . . . . . . . . . . . . . . . . . 31
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 32
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1. Normative References. . . . . . . . . . . . . . . . . . . 33
6.2. Informative References. . . . . . . . . . . . . . . . . . 33
7. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 35
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 36
1. Introduction
Reliable multicast transport is a desirable technology for the
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 [3]. This
document addresses the creation of negative-acknowledgment (NACK)-
oriented reliable multicast (NORM) protocols. While different
protocol instantiations may be required to meet specific application
and network architecture demands [4], there are a number of
fundamental components that may be common to these different
instantiations. This document describes the framework and common
"building block" components relevant to multicast protocols based
primarily on NACK operation for reliable transport. While this
document discusses a large set of reliable multicast components and
issues relevant to NORM protocol design, it specifically addresses in
detail the following building blocks which are not addressed in other
IETF documents:
1) NORM sender transmission strategies,
2) NACK-oriented repair process with timer-based feedback
suppression, and
3) Round-trip timing for adapting NORM timers.
The potential relationships to other reliable multicast transport
building blocks (Forward Error Correction (FEC), congestion control)
and general issues with NORM protocols are also discussed. This
document is a product of the IETF RMT WG and follows the guidelines
provided in RFC 3269 [5]. 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 BCP 14, RFC 2119 [1].
Statement of Intent
This memo contains part of the definitions necessary to fully specify
a Reliable Multicast Transport protocol in accordance with RFC 2357.
As per RFC 2357, the use of any reliable multicast protocol in the
Internet requires an adequate congestion control scheme.
While waiting for such a scheme to be available, or for an existing
scheme to be proven adequate, the Reliable Multicast Transport
working group (RMT) publishes this Request for Comments in the
"Experimental" category.
It is the intent of RMT to re-submit this specification as an IETF
Proposed Standard as soon as the above condition is met.
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,
6) Network Environments, and
7) Router/Intermediate System Interactions.
All of these areas are at least briefly discussed. Additionally,
other reliable multicast transport building block documents such as
[9] have been created to address areas outside of the scope of this
document. NORM 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 NORM but may be used in concert
with the other building block areas. In some cases, a building block
may be able 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.
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.
A 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 services 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.
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 [2] 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-oriented protocol
can apply without NACK implosion problems. Research suggests that
NORM group sizes on the order of tens of thousands of receivers may
operate with modest feedback to the sender using probabilistic,
timer-based suppression techniques [7]. However, the potential for
router assistance and/or other NACK suppression heuristics may enable
these protocols to scale to very large 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.
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 for the
sender of data to identify appropriate content for efficient repair
transmission. For example, backoff timeouts can be used to ensure
efficient NACK suppression and repair transmission, but this comes at
a 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 single source multicast (SSM) model from
a specific source [8]. Receivers in the group may be 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. Router/Intermediate System Assistance
While intermediate assistance from devices/systems with direct
knowledge of the underlying network topology may be used to leverage
the performance and scalability of reliable multicast protocols,
there will continue to be a number of instances where this 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 NORM building block
identification/design. This section describes different building
block areas applicable to NORM protocols. Some of these areas are
specific to NACK-oriented 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 other general building
block areas from the standpoint of NACK-oriented reliable multicast.
Where applicable, other building block documents are referenced for
possible contribution to NORM 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 NORM
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 NORM are
identified:
(NORM-Specific)
1) NORM Sender Transmission
2) NORM Repair Process
3) NORM Receiver Join Policies
(General Purpose)
4) Node (member) Identification
5) Data Content Identification
6) Forward Error Correction (FEC)
7) Round-trip Timing Collection
8) Group Size Determination/Estimation
9) Congestion Control Operation
10) Router/Intermediate System Assistance
11) 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.
Application Data and Control
|
v
.---------------------. .-----------------------.
| Node Identification |----------->| Sender Transmission |<------.
`---------------------’ _.-’ `-----------------------’ |
.---------------------. _.-’ .’ | .--------------. |
| Data Identification |--’ .’’ | | Join Policy | |
`---------------------’ .’ ’ v `--------------’ |
.---------------------. .’ ’ .------------------------. |
.->| Congestion Control |-’ ’ | Receiver NACK | |
| `---------------------’ .’ | Repair Process | |
| .---------------------. .’ | .------------------. | |
| | FEC |’. | | NACK Initiation | | |
| `---------------------’` `._ | `------------------’ | |
| .---------------------. ``. `-._ | .------------------. | |
`--| RTT Collection |._` ` `->| | NACK Content | | |
`---------------------’ .`- ` | `------------------’ | |
.---------------------. \ `-`._ | .------------------. | |
| Group Size Est. |---.-`---`->| | NACK Suppression | | |
`---------------------’`. ` ` | `------------------’ | |
.---------------------. ` ` ` `------------------------’ |
| Other | ` ` ` | .-----------------. |
`---------------------’ ` ` ` | |Router Assistance| |
`. ` ` v `-----------------’ |
`.`’ .-------------------------. |
`>| Sender NACK Processing |_____/
| and Repair Response |
`-------------------------’
^ ^
| |
.-----------------------------.
| (Security) |
`-----------------------------’
Fig. 1 - NORM Building Block Framework
The components on the left side of this figure are areas that may be
applicable beyond NORM. The most significant of these components are
discussed in other building block documents such as [9]. A brief