draft-ietf-rmt-pi-norm-revised-07.txt   draft-ietf-rmt-pi-norm-revised-08.txt 
Network Working Group B. Adamson Network Working Group B. Adamson
Internet-Draft Naval Research Laboratory Internet-Draft Naval Research Laboratory
Intended status: Standards Track C. Bormann Intended status: Standards Track C. Bormann
Expires: April 27, 2009 Universitaet Bremen TZI Expires: June 20, 2009 Universitaet Bremen TZI
M. Handley M. Handley
University College London University College London
J. Macker J. Macker
Naval Research Laboratory Naval Research Laboratory
October 24, 2008 December 17, 2008
NACK-Oriented Reliable Multicast Protocol NACK-Oriented Reliable Multicast Protocol
draft-ietf-rmt-pi-norm-revised-07 draft-ietf-rmt-pi-norm-revised-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 27, 2009. This Internet-Draft will expire on June 20, 2009.
Abstract Abstract
This document describes the messages and procedures of the Negative- This document describes the messages and procedures of the Negative-
ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) Protocol. ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) Protocol.
This protocol is designed to provide end-to-end reliable transport of This protocol is designed to provide end-to-end reliable transport of
bulk data objects or streams over generic IP multicast routing and bulk data objects or streams over generic IP multicast routing and
forwarding services. NORM uses a selective, negative acknowledgment forwarding services. NORM uses a selective, negative acknowledgment
mechanism for transport reliability and offers additional protocol mechanism for transport reliability and offers additional protocol
mechanisms to allow for operation with minimal a priori coordination mechanisms to allow for operation with minimal a priori coordination
skipping to change at page 3, line 42 skipping to change at page 3, line 42
5.4. Sender NACK Processing and Response . . . . . . . . . . . 62 5.4. Sender NACK Processing and Response . . . . . . . . . . . 62
5.4.1. Sender Repair State Aggregation . . . . . . . . . . . 63 5.4.1. Sender Repair State Aggregation . . . . . . . . . . . 63
5.4.2. Sender FEC Repair Transmission Strategy . . . . . . . 64 5.4.2. Sender FEC Repair Transmission Strategy . . . . . . . 64
5.4.3. Sender NORM_CMD(SQUELCH) Generation . . . . . . . . . 65 5.4.3. Sender NORM_CMD(SQUELCH) Generation . . . . . . . . . 65
5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation . . . . . . . . 65 5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation . . . . . . . . 65
5.5. Additional Protocol Mechanisms . . . . . . . . . . . . . . 66 5.5. Additional Protocol Mechanisms . . . . . . . . . . . . . . 66
5.5.1. Greatest Round-trip Time Collection . . . . . . . . . 66 5.5.1. Greatest Round-trip Time Collection . . . . . . . . . 66
5.5.2. NORM Congestion Control Operation . . . . . . . . . . 67 5.5.2. NORM Congestion Control Operation . . . . . . . . . . 67
5.5.3. NORM Positive Acknowledgment Procedure . . . . . . . . 75 5.5.3. NORM Positive Acknowledgment Procedure . . . . . . . . 75
5.5.4. Group Size Estimate . . . . . . . . . . . . . . . . . 77 5.5.4. Group Size Estimate . . . . . . . . . . . . . . . . . 77
6. Security Considerations . . . . . . . . . . . . . . . . . . . 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 77
6.1. Baseline Secure NORM Operation . . . . . . . . . . . . . . 79 6.1. Baseline Secure NORM Operation . . . . . . . . . . . . . . 79
6.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 80 6.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 79
6.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 82 6.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 82
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83
7.1. Explicit IANA Assignment Guidelines . . . . . . . . . . . 83 7.1. Explicit IANA Assignment Guidelines . . . . . . . . . . . 83
8. Suggested Use . . . . . . . . . . . . . . . . . . . . . . . . 84 8. Suggested Use . . . . . . . . . . . . . . . . . . . . . . . . 84
9. Changes from RFC3940 . . . . . . . . . . . . . . . . . . . . . 85 9. Changes from RFC3940 . . . . . . . . . . . . . . . . . . . . . 84
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 85 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 85
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
11.1. Normative References . . . . . . . . . . . . . . . . . . . 86 11.1. Normative References . . . . . . . . . . . . . . . . . . . 85
11.2. Informative References . . . . . . . . . . . . . . . . . . 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 86
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 88
Intellectual Property and Copyright Statements . . . . . . . . . . 90 Intellectual Property and Copyright Statements . . . . . . . . . . 90
1. Introduction and Applicability 1. Introduction and Applicability
The Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM) The Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM)
protocol is designed to provide reliable transport of data from one protocol is designed to provide reliable transport of data from one
or more sender(s) to a group of receivers over an IP multicast or more sender(s) to a group of receivers over an IP multicast
network. The primary design goals of NORM are to provide efficient, network. The primary design goals of NORM are to provide efficient,
skipping to change at page 9, line 8 skipping to change at page 9, line 8
to computer resource usage, the NORM protocol does NOT require that to computer resource usage, the NORM protocol does NOT require that
state be kept on all receivers in the group. NORM senders maintain state be kept on all receivers in the group. NORM senders maintain
state only for receivers providing explicit congestion control state only for receivers providing explicit congestion control
feedback. However, NORM receivers must maintain state for each feedback. However, NORM receivers must maintain state for each
active sender. This may constrain the number of simultaneous senders active sender. This may constrain the number of simultaneous senders
in some uses of NORM. in some uses of NORM.
1.3. Environmental Requirements and Considerations 1.3. Environmental Requirements and Considerations
All of the environmental requirements and considerations that apply All of the environmental requirements and considerations that apply
to the RMT Multicast NACK Building Block to the RMT Multicast NACK Building Block [RFC5401], FEC Building
[I-D.ietf-rmt-bb-norm-revised], FEC Building Block [RFC5052], and Block [RFC5052], and TCP-Friendly Multicast Congestion Control
TCP-Friendly Multicast Congestion Control (TFMCC) Building Block (TFMCC) Building Block [RFC4654], also apply to the NORM protocol.
[RFC4654], also apply to the NORM protocol.
The NORM protocol SHALL be capable of operating in an end-to-end The NORM protocol SHALL be capable of operating in an end-to-end
fashion with no assistance from intermediate systems beyond basic IP fashion with no assistance from intermediate systems beyond basic IP
multicast group management, routing, and forwarding services. While multicast group management, routing, and forwarding services. While
the techniques utilized in NORM are principally applicable to flat, the techniques utilized in NORM are principally applicable to flat,
end-to-end IP multicast topologies, they could also be applied in the end-to-end IP multicast topologies, they could also be applied in the
sub-levels of hierarchical (e.g., tree-based) multicast distribution sub-levels of hierarchical (e.g., tree-based) multicast distribution
if so desired. NORM can make use of reciprocal (among senders and if so desired. NORM can make use of reciprocal (among senders and
receivers) multicast communication under the Any-Source Multicast receivers) multicast communication under the Any-Source Multicast
(ASM) model defined in [RFC1112], but SHALL also be capable of (ASM) model defined in [RFC1112], but SHALL also be capable of
skipping to change at page 13, line 9 skipping to change at page 13, line 9
is controlled using the same timer-based probabilistic suppression is controlled using the same timer-based probabilistic suppression
techniques as for "NORM_NACK" messages to avoid feedback implosion. techniques as for "NORM_NACK" messages to avoid feedback implosion.
In order to meet potential application requirements for positive In order to meet potential application requirements for positive
acknowledgment from receivers, other "NORM_ACK" messages are defined acknowledgment from receivers, other "NORM_ACK" messages are defined
and available for use. and available for use.
2.2. Protocol Building Blocks 2.2. Protocol Building Blocks
The operation of the NORM protocol is based primarily upon the The operation of the NORM protocol is based primarily upon the
concepts presented in the Multicast NACK Building Block document concepts presented in the Multicast NACK Building Block document
[I-D.ietf-rmt-bb-norm-revised]. This includes the basic NORM [RFC5401]. This includes the basic NORM architecture and the data
architecture and the data transmission, repair, and feedback transmission, repair, and feedback strategies discussed in that
strategies discussed in that document. Additional reliable multicast document. Additional reliable multicast building blocks, as
building blocks are applied in creating the full NORM protocol described in [RFC3048], are applied in creating the full NORM
instantiation as described in [RFC3048]. NORM also makes use of protocol instantiation . NORM also makes use of Forward Error
Forward Error Correction encoding techniques for repair messaging and Correction encoding techniques for repair messaging and optional
optional transmission robustness as described in [RFC3453]. NORM transmission robustness as described in [RFC3453]. NORM uses the FEC
uses the FEC Payload ID as specified by the FEC Building Block Payload ID as specified by the FEC Building Block document [RFC5052].
document [RFC5052]. Additionally, for congestion control, this Additionally, for congestion control, this document fully specifies a
document fully specifies a baseline congestion control mechanism baseline congestion control mechanism (NORM-CC) based on the TCP-
(NORM-CC) based on the TCP-Friendly Multicast Congestion Control Friendly Multicast Congestion Control (TFMCC) scheme of [TfmccPaper]
(TFMCC) scheme of [TfmccPaper] and [RFC4654]. and [RFC4654].
2.3. Design Tradeoffs 2.3. Design Tradeoffs
While the various features of NORM are designed to provide some While the various features of NORM are designed to provide some
measure of general purpose utility, it is important to emphasize the measure of general purpose utility, it is important to emphasize the
understanding that "no one size fits all" in the reliable multicast understanding that "no one size fits all" in the reliable multicast
transport arena. There are numerous engineering trade-offs involved transport arena. There are numerous engineering trade-offs involved
in reliable multicast transport design and this requires an increased in reliable multicast transport design and this requires an increased
awareness of application and network architecture considerations. awareness of application and network architecture considerations.
Performance requirements affecting design can include: group size, Performance requirements affecting design can include: group size,
skipping to change at page 14, line 15 skipping to change at page 14, line 15
Large buffer sizes allow the NORM protocol to perform most Large buffer sizes allow the NORM protocol to perform most
efficiently in large delay-bandwidth topologies and allow for longer efficiently in large delay-bandwidth topologies and allow for longer
feedback suppression backoff timeouts. This yields improved group feedback suppression backoff timeouts. This yields improved group
size scalability. NORM can operate with reduced buffering but at a size scalability. NORM can operate with reduced buffering but at a
cost of decreased efficiency (lower relative goodput) and reduced cost of decreased efficiency (lower relative goodput) and reduced
group size scalability. group size scalability.
3. Conformance Statement 3. Conformance Statement
This Protocol Instantiation document, in conjunction with the RMT This Protocol Instantiation document, in conjunction with the RMT
Building Block documents of [I-D.ietf-rmt-bb-norm-revised] and Building Block documents of [RFC5401] and [RFC5052], completely
[RFC5052], completely specifies a working reliable multicast specifies a working reliable multicast transport protocol that
transport protocol that conforms to the requirements described in RFC conforms to the requirements described in RFC 2357 [RFC2357].
2357 [RFC2357].
This document specifies the following message types and mechanisms This document specifies the following message types and mechanisms
which are REQUIRED in complying NORM protocol implementations: which are REQUIRED in complying NORM protocol implementations:
+------------------------+------------------------------------------+ +------------------------+------------------------------------------+
| Message Type | Purpose | | Message Type | Purpose |
+------------------------+------------------------------------------+ +------------------------+------------------------------------------+
| "NORM_DATA" | Sender message for application data | | "NORM_DATA" | Sender message for application data |
| | transmission. Implementations must | | | transmission. Implementations must |
| | support at least one of the | | | support at least one of the |
skipping to change at page 21, line 27 skipping to change at page 21, line 27
is also referred to as "R_max" in [TfmccPaper]). This value is used is also referred to as "R_max" in [TfmccPaper]). This value is used
to control timing of the NACK repair process and other aspects of to control timing of the NACK repair process and other aspects of
protocol operation as described in this document. Normally, the protocol operation as described in this document. Normally, the
advertised "grtt" value will correspond to what the sender has advertised "grtt" value will correspond to what the sender has
measured based on feedback from the group, but, at low transmission measured based on feedback from the group, but, at low transmission
rates, the advertised "grtt" SHALL be set to "MAX(grttMeasured, rates, the advertised "grtt" SHALL be set to "MAX(grttMeasured,
NormSegmentSize/senderRate)" where the "NormSegmentSize" is sender's NormSegmentSize/senderRate)" where the "NormSegmentSize" is sender's
segment size in bytes and the "senderRate" is the sender's current segment size in bytes and the "senderRate" is the sender's current
transmission rate in bytes per second. The algorithm for encoding transmission rate in bytes per second. The algorithm for encoding
and decoding this field is described in the RMT Multicast NACK and decoding this field is described in the RMT Multicast NACK
Building Block document [I-D.ietf-rmt-bb-norm-revised]. Building Block document [RFC5401].
The "backoff" field value is used by receivers to determine the The "backoff" field value is used by receivers to determine the
maximum backoff timer value used in the timer-based NORM NACK maximum backoff timer value used in the timer-based NORM NACK
feedback suppression. This 4-bit field supports values from 0-15 feedback suppression. This 4-bit field supports values from 0-15
which is multiplied by the sender GRTT to determine the maximum which is multiplied by the sender GRTT to determine the maximum
backoff timeout. The "backoff" field informs the receivers of the backoff timeout. The "backoff" field informs the receivers of the
sender's backoff factor parameter "Ksender". Recommended values and sender's backoff factor parameter "Ksender". Recommended values and
their use are described in the NORM receiver NACK procedure their use are described in the NORM receiver NACK procedure
description in Section 5.3. description in Section 5.3.
skipping to change at page 23, line 48 skipping to change at page 23, line 48
of-range with the current state kept for a given source). During the of-range with the current state kept for a given source). During the
course of its transmission within a NORM session, an object is course of its transmission within a NORM session, an object is
uniquely identified by the concatenation of the sender "source_id" uniquely identified by the concatenation of the sender "source_id"
and the given "object_transport_id". Note that "NORM_INFO" messages and the given "object_transport_id". Note that "NORM_INFO" messages
associated with the identified object carry the same associated with the identified object carry the same
"object_transport_id" value. "object_transport_id" value.
The "fec_payload_id" identifies the attached "NORM_DATA" "payload" The "fec_payload_id" identifies the attached "NORM_DATA" "payload"
content. The size and format of the "fec_payload_id" field depends content. The size and format of the "fec_payload_id" field depends
upon the FEC type indicated by the "fec_id" field. These formats are upon the FEC type indicated by the "fec_id" field. These formats are
given in the descriptions of specific FEC schemes as described in the given in the descriptions of specific FEC schemes such as those
IETF FEC Basic Schemes document I-d described in the IETF FEC Basic Schemes
[I-D.ietf-rmt-bb-fec-basic-schemes-revised] or additional FEC Scheme [I-D.ietf-rmt-bb-fec-basic-schemes-revised] specification or in
documents that may be defined. As an example, the format of the additional FEC Scheme documents that may be defined. As an example,
"fec_payload_id" format for Small Block, Systematic codes ("fec_id" = the format of the "fec_payload_id" format for Small Block, Systematic
129) is given here: codes ("fec_id" = 129) from the FEC Basic Schemes
[I-D.ietf-rmt-bb-fec-basic-schemes-revised] specification is given
here:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number | | source_block_number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_len | encoding_symbol_id | | source_block_len | encoding_symbol_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example: FEC Payload Id Format for "fec_id" = 129 Example: FEC Payload Id Format for "fec_id" = 129
In this example FEC payload identifier, the "source_block_number", In this example FEC payload identifier, the "source_block_number",
"source_block_len", and "encoding_symbol_id" fields correspond to the "source_block_len", and "encoding_symbol_id" fields correspond to the
"Source Block Number", "Source Block Length, and "Encoding Symbol ID" "Source Block Number", "Source Block Length, and "Encoding Symbol ID"
fields of the FEC Payload ID format given by the FEC Basic Schemes fields of the FEC Payload ID format for Small Block Systematic FEC
document [I-D.ietf-rmt-bb-fec-basic-schemes-revised] for Small Block Schemes identified by a "fec_id" value of 129 as specified by the FEC
Systematic FEC Schemes identified by a "fec_id" value of 129. The Basic Schemes [I-D.ietf-rmt-bb-fec-basic-schemes-revised] document .
"source_block_number" identifies the coding block's relative position The "source_block_number" identifies the coding block's relative
with a NormObject. Note that, for NormObjects of type position with a NormObject. Note that, for NormObjects of type
"NORM_OBJECT_STREAM", the "source_block_number" may wrap for very "NORM_OBJECT_STREAM", the "source_block_number" may wrap for very
long lived sessions. The "source_block_len" indicates the number of long lived sessions. The "source_block_len" indicates the number of
user data segments in the identified coding block. Given the user data segments in the identified coding block. Given the
"source_block_len" information of how many symbols of application "source_block_len" information of how many symbols of application
data are contained in the block, the receiver can determine whether data are contained in the block, the receiver can determine whether
the attached segment is data or parity content and treat it the attached segment is data or parity content and treat it
appropriately. Some applications may dynamically "shorten" code appropriately. Some applications may dynamically "shorten" code
blocks when the pending information content is not predictable (e.g. blocks when the pending information content is not predictable (e.g.
real-time message streams). In that case, the "source_block_len" real-time message streams). In that case, the "source_block_len"
value given for an "encoding_symbol_id" that contains FEC parity value given for an "encoding_symbol_id" that contains FEC parity
skipping to change at page 42, line 15 skipping to change at page 42, line 15
| | | session and its feedback should | | | | session and its feedback should |
| | | not be considered in congestion | | | | not be considered in congestion |
| | | control operation. | | | | control operation. |
+----------------------+-------+------------------------------------+ +----------------------+-------+------------------------------------+
The "cc_rtt" contains a quantized representation of the RTT as The "cc_rtt" contains a quantized representation of the RTT as
measured by the sender with respect to the indicated receiver. This measured by the sender with respect to the indicated receiver. This
field is valid only if the "NORM_FLAG_CC_RTT" flag is set in the field is valid only if the "NORM_FLAG_CC_RTT" flag is set in the
"cc_flags" field. This one byte field is a quantized representation "cc_flags" field. This one byte field is a quantized representation
of the RTT using the algorithm described in the Multicast NACK of the RTT using the algorithm described in the Multicast NACK
Building Block document [I-D.ietf-rmt-bb-norm-revised]. Building Block document [RFC5401].
The "cc_rate" field contains a representation of the receiver's The "cc_rate" field contains a representation of the receiver's
current calculated (during steady-state congestion control operation) current calculated (during steady-state congestion control operation)
or twice its measured (during the slow start phase) congestion or twice its measured (during the slow start phase) congestion
control rate. This field is encoded and decoded using the same control rate. This field is encoded and decoded using the same
technique as described for the "NORM_CMD(CC)" "send_rate" field. technique as described for the "NORM_CMD(CC)" "send_rate" field.
4.2.3.5. NORM_CMD(REPAIR_ADV) Message 4.2.3.5. NORM_CMD(REPAIR_ADV) Message
The "NORM_CMD(REPAIR_ADV)" message is used by the sender to The "NORM_CMD(REPAIR_ADV)" message is used by the sender to
skipping to change at page 61, line 8 skipping to change at page 61, line 8
""T_inactivity"" value of 1 second is RECOMMENDED. The NORM receiver ""T_inactivity"" value of 1 second is RECOMMENDED. The NORM receiver
SHOULD reset this inactivity timer and repeat NACK initiation upon SHOULD reset this inactivity timer and repeat NACK initiation upon
timeout for up to "NORM_ROBUST_FACTOR" times or more depending upon timeout for up to "NORM_ROBUST_FACTOR" times or more depending upon
the application's need for persistence by its receivers. It is also the application's need for persistence by its receivers. It is also
important that receivers rescale the ""T_inactivity"" timeout as the important that receivers rescale the ""T_inactivity"" timeout as the
sender's advertised GRTT changes. sender's advertised GRTT changes.
The NACKing procedure begins with a random backoff timeout. The The NACKing procedure begins with a random backoff timeout. The
duration of the backoff timeout is chosen using the "RandomBackoff" duration of the backoff timeout is chosen using the "RandomBackoff"
algorithm described in the Multicast NACK Building Block document algorithm described in the Multicast NACK Building Block document
[I-D.ietf-rmt-bb-norm-revised] using ("Ksender*GRTTsender") for the [RFC5401] using ("Ksender*GRTTsender") for the "maxTime" parameter
"maxTime" parameter and the sender advertised group size and the sender advertised group size ("GSIZEsender") as the
("GSIZEsender") as the "groupSize" parameter. NORM senders provide "groupSize" parameter. NORM senders provide values for "GRTTsender",
values for "GRTTsender", "Ksender" and "GSIZEsender" via the "grtt", "Ksender" and "GSIZEsender" via the "grtt", "backoff", and "gsize"
"backoff", and "gsize" fields of transmitted messages. The fields of transmitted messages. The "GRTTsender" value is determined
"GRTTsender" value is determined by the sender based on feedback it by the sender based on feedback it has received from the group while
has received from the group while the "Ksender" and "GSIZEsender" the "Ksender" and "GSIZEsender" values may determined by application
values may determined by application requirements and expectations or requirements and expectations or ancillary information. The backoff
ancillary information. The backoff factor ""Ksender"" MUST be factor ""Ksender"" MUST be greater than "one" to provide for
greater than "one" to provide for effective feedback suppression. A effective feedback suppression. A value of "K = 4" is RECOMMENDED
value of "K = 4" is RECOMMENDED for the Any Source Multicast (ASM) for the Any Source Multicast (ASM) model while a value of "K = 6" is
model while a value of "K = 6" is RECOMMENDED for Single Source RECOMMENDED for Single Source Multicast (SSM) operation.
Multicast (SSM) operation.
Thus: Thus:
T_backoff = RandomBackoff(Ksender*GRTTsender, GSIZEsender) T_backoff = RandomBackoff(Ksender*GRTTsender, GSIZEsender)
To avoid the possibility of NACK implosion in the case of sender or To avoid the possibility of NACK implosion in the case of sender or
network failure during SSM operation, the receiver SHALL network failure during SSM operation, the receiver SHALL
automatically suppress its NACK and immediately enter the "holdoff" automatically suppress its NACK and immediately enter the "holdoff"
period described below when "T_backoff" is greater than period described below when "T_backoff" is greater than
"(Ksender-1)*GRTTsender". Otherwise, the backoff period is entered "(Ksender-1)*GRTTsender". Otherwise, the backoff period is entered
and the receiver MUST accumulate external pending repair state from and the receiver MUST accumulate external pending repair state from
skipping to change at page 61, line 52 skipping to change at page 61, line 50
the time the NACK procedure (backoff timeout) was initiated. the time the NACK procedure (backoff timeout) was initiated.
If these conditions are met, the receiver immediately generates a If these conditions are met, the receiver immediately generates a
"NORM_NACK" message when the backoff timeout expires. Otherwise, the "NORM_NACK" message when the backoff timeout expires. Otherwise, the
receiver's NACK is considered to be "suppressed" and the message is receiver's NACK is considered to be "suppressed" and the message is
not sent. At this time, the receiver begins a "holdoff" period not sent. At this time, the receiver begins a "holdoff" period
during which it constrains itself to not re-initiate the NACKing during which it constrains itself to not re-initiate the NACKing
process. The purpose of this timeout is to allow the sender worst- process. The purpose of this timeout is to allow the sender worst-
case time to respond to the repair needs before the receiver requests case time to respond to the repair needs before the receiver requests
repair again. The value of this "holdoff" timeout ("T_rcvrHoldoff") repair again. The value of this "holdoff" timeout ("T_rcvrHoldoff")
as described in [I-D.ietf-rmt-bb-norm-revised] is: as described in [RFC5401] is:
T_rcvrHoldoff =(Ksender+2)*GRTTsender T_rcvrHoldoff =(Ksender+2)*GRTTsender
The "NORM_NACK" message contains repair request content beginning The "NORM_NACK" message contains repair request content beginning
with lowest ordinal repair position of the receiver up through the with lowest ordinal repair position of the receiver up through the
coding block prior to the most recently heard ordinal transmission coding block prior to the most recently heard ordinal transmission
position for the sender. If the size of the "NORM_NACK" content position for the sender. If the size of the "NORM_NACK" content
exceeds the sender's NormSegmentSize, the NACK content is truncated exceeds the sender's NormSegmentSize, the NACK content is truncated
so that the receiver only generates a single "NORM_NACK" message per so that the receiver only generates a single "NORM_NACK" message per
NACK cycle for a given sender. In summary, a single NACK message is NACK cycle for a given sender. In summary, a single NACK message is
generated containing the receiver's lowest ordinal repair needs. generated containing the receiver's lowest ordinal repair needs.
For each partially-received FEC coding block requiring repair, the For each partially-received FEC coding block requiring repair, the
skipping to change at page 63, line 19 skipping to change at page 63, line 17
uncorrelated data loss. uncorrelated data loss.
5.4.1. Sender Repair State Aggregation 5.4.1. Sender Repair State Aggregation
When a sender is in its normal state of transmitting new data and When a sender is in its normal state of transmitting new data and
receives a NACK, it begins a procedure to accumulate NACK repair receives a NACK, it begins a procedure to accumulate NACK repair
state from "NORM_NACK" messages before beginning repair state from "NORM_NACK" messages before beginning repair
transmissions. Note that this period of aggregating repair state transmissions. Note that this period of aggregating repair state
does NOT interfere with its ongoing transmission of new data. does NOT interfere with its ongoing transmission of new data.
As described in [I-D.ietf-rmt-bb-norm-revised], the period of time As described in [RFC5401], the period of time during which the sender
during which the sender aggregates "NORM_NACK" messages is equal to: aggregates "NORM_NACK" messages is equal to:
T_sndrAggregate = (Ksender+1)*GRTT T_sndrAggregate = (Ksender+1)*GRTT
where ""Ksender"" is the same backoff scaling value used by the where ""Ksender"" is the same backoff scaling value used by the
receivers, and "GRTT" is the sender's current estimate of the group's receivers, and "GRTT" is the sender's current estimate of the group's
greatest round-trip time. Note that for NORM unicast sessions the greatest round-trip time. Note that for NORM unicast sessions the
""T_sndrAggregate"" time can be set to ZERO since there is only one ""T_sndrAggregate"" time can be set to ZERO since there is only one
receiver. Similarly, the ""Ksender"" value should be set to ZERO for receiver. Similarly, the ""Ksender"" value should be set to ZERO for
NORM unicast sessions to minimize repair latency. NORM unicast sessions to minimize repair latency.
When this period ends, the sender "rewinds" by incorporating the When this period ends, the sender "rewinds" by incorporating the
accumulated repair state into its pending transmission state and accumulated repair state into its pending transmission state and
begins transmitting repair messages. After pending repair begins transmitting repair messages. After pending repair
transmissions are completed, the sender continues with new transmissions are completed, the sender continues with new
transmissions of any enqueued data. Also, at this point in time, the transmissions of any enqueued data. Also, at this point in time, the
sender begins a "holdoff" timeout during which time the sender sender begins a "holdoff" timeout during which time the sender
constrains itself from initiating a new repair aggregation cycle, constrains itself from initiating a new repair aggregation cycle,
even if "NORM_NACK" messages arrive. As described in even if "NORM_NACK" messages arrive. As described in [RFC5401], the
[I-D.ietf-rmt-bb-norm-revised], the value of this sender "holdoff" value of this sender "holdoff" period is:
period is:
T_sndrHoldoff = (1*GRTT) T_sndrHoldoff = (1*GRTT)
If additional "NORM_NACK" messages are received during this sender If additional "NORM_NACK" messages are received during this sender
"holdoff" period, the sender will immediately incorporate these late- "holdoff" period, the sender will immediately incorporate these late-
arriving messages into its pending transmission state ONLY if the arriving messages into its pending transmission state ONLY if the
NACK content is ordinally greater than the sender's current NACK content is ordinally greater than the sender's current
transmission position. This "holdoff" time allows worst case time transmission position. This "holdoff" time allows worst case time
for the sender to propagate its current transmission sequence for the sender to propagate its current transmission sequence
position to the group, thus avoiding redundant repair transmissions. position to the group, thus avoiding redundant repair transmissions.
After the holdoff timeout expires, a new NACK accumulation period can After the holdoff timeout expires, a new NACK accumulation period can
skipping to change at page 66, line 50 skipping to change at page 66, line 47
Then, when the receivers generate feedback messages to the sender, an Then, when the receivers generate feedback messages to the sender, an
adjusted version of the sender timestamp is embedded in the feedback adjusted version of the sender timestamp is embedded in the feedback
message ("NORM_NACK" or "NORM_ACK"). The adjustment adds the amount message ("NORM_NACK" or "NORM_ACK"). The adjustment adds the amount
of time the receiver held the timestamp before generating its of time the receiver held the timestamp before generating its
response. Upon receipt of this adjusted timestamp, the sender is response. Upon receipt of this adjusted timestamp, the sender is
able to calculate the round-trip time to that receiver. able to calculate the round-trip time to that receiver.
The round-trip time for each receiver is fed into an algorithm that The round-trip time for each receiver is fed into an algorithm that
weights and smoothes the values for a conservative estimate of the weights and smoothes the values for a conservative estimate of the
GRTT. The algorithm and methodology are described in the Multicast GRTT. The algorithm and methodology are described in the Multicast
NACK Building Block document [I-D.ietf-rmt-bb-norm-revised] in the NACK Building Block document [RFC5401] in the section entitled "One-
section entitled "One-to-Many Sender GRTT Measurement". A to-Many Sender GRTT Measurement". A conservative estimate helps
conservative estimate helps guarantee feedback suppression at a small guarantee feedback suppression at a small cost in overall protocol
cost in overall protocol repair delay. The sender's current estimate repair delay. The sender's current estimate of GRTT is advertised in
of GRTT is advertised in the "grtt" field found in all NORM sender the "grtt" field found in all NORM sender messages. The advertised
messages. The advertised GRTT is also limited to a minimum of the GRTT is also limited to a minimum of the nominal inter-packet
nominal inter-packet transmission time given the sender's current transmission time given the sender's current transmission rate and
transmission rate and system clock granularity. The reason for this system clock granularity. The reason for this additional limit is to
additional limit is to keep the receiver somewhat event-driven by keep the receiver somewhat event-driven by making sure the sender has
making sure the sender has had adequate time to generate any response had adequate time to generate any response to repair requests from
to repair requests from receivers given transmit rate limitations due receivers given transmit rate limitations due to congestion control
to congestion control or configuration. or configuration.
When the NORM-CC Rate header extension is present in "NORM_CMD(CC)" When the NORM-CC Rate header extension is present in "NORM_CMD(CC)"
messages, the receivers respond to "NORM_CMD(CC)" messages as messages, the receivers respond to "NORM_CMD(CC)" messages as
described in Section 5.5.2, "NORM Congestion Control Operation". The described in Section 5.5.2, "NORM Congestion Control Operation". The
"NORM_CMD(CC)" messages are periodically generated by the sender as "NORM_CMD(CC)" messages are periodically generated by the sender as
described for congestion control operation. This provides for described for congestion control operation. This provides for
proactive, but controlled, feedback from the group in the form of proactive, but controlled, feedback from the group in the form of
"NORM_ACK" messages. This provides for GRTT feedback even if no "NORM_ACK" messages. This provides for GRTT feedback even if no
"NORM_NACK" messages are being sent. If operating without congestion "NORM_NACK" messages are being sent. If operating without congestion
control in a closed network, the "NORM_CMD(CC)" messages may be sent control in a closed network, the "NORM_CMD(CC)" messages may be sent
skipping to change at page 68, line 18 skipping to change at page 68, line 15
multicast topology and adjust the sender rate accordingly. The multicast topology and adjust the sender rate accordingly. The
receiver with loss and RTT estimates that correspond to the lowest receiver with loss and RTT estimates that correspond to the lowest
resulting calculated transmission rate is identified as the "current resulting calculated transmission rate is identified as the "current
limiting receiver" (CLR). In the case of a tie (where candidate CLRs limiting receiver" (CLR). In the case of a tie (where candidate CLRs
are within 10% of the same calculated rate), the receiver with the are within 10% of the same calculated rate), the receiver with the
largest RTT value SHOULD be designated as the CLR. largest RTT value SHOULD be designated as the CLR.
As described in [TcpModel], a steady-state sender transmission rate, As described in [TcpModel], a steady-state sender transmission rate,
to be "friendly" with competing TCP flows can be calculated as: to be "friendly" with competing TCP flows can be calculated as:
S S
Rsender = -------------------------------------------------------------- Rsender = ----------------------------------------------------------
tRTT*(sqrt((2/3)*p) + 12 * sqrt((3/8)*p) * p * (1 + 32*(p^2))) tRTT*(sqrt((2/3)*p) + 12 * sqrt((3/8)*p) * p * (1 + 32*(p^2)))
where where
"S" = nominal transmitted packet size. (In NORM, the "nominal" "S" = nominal transmitted packet size. (In NORM, the "nominal"
packet size can be determined by the sender as an exponentially packet size can be determined by the sender as an exponentially
weighted moving average (EWMA) of transmitted packet sizes to account weighted moving average (EWMA) of transmitted packet sizes to account
for variable message sizes). for variable message sizes).
"tRTT" = RTT estimate of the current "current limiting receiver" "tRTT" = RTT estimate of the current "current limiting receiver"
skipping to change at page 71, line 29 skipping to change at page 71, line 22
form of a "NORM_ACK" to this message. When a "NORM_CMD(CC)" is form of a "NORM_ACK" to this message. When a "NORM_CMD(CC)" is
received, non-CLR or non-PLR nodes initiate random feedback backoff received, non-CLR or non-PLR nodes initiate random feedback backoff
timeouts similar to that used when the receiver initiates a repair timeouts similar to that used when the receiver initiates a repair
cycle (see Section 5.3) in response to detection of data loss. The cycle (see Section 5.3) in response to detection of data loss. The
backoff timeout for the congestion control response is generated as backoff timeout for the congestion control response is generated as
follows: follows:
T_backoff = RandomBackoff(K*GRTTsender, GSIZEsender) T_backoff = RandomBackoff(K*GRTTsender, GSIZEsender)
The ""RandomBackoff()"" algorithm provides a truncated exponentially The ""RandomBackoff()"" algorithm provides a truncated exponentially
distributed random number and is described in the Multicast NACK distributed random number and is described in the Multicast NACK
Building Block document [I-D.ietf-rmt-bb-norm-revised]. The same Building Block document [RFC5401]. The same backoff factor "K =
backoff factor "K = Ksender" MAY be used as with "NORM_NACK" Ksender" MAY be used as with "NORM_NACK" suppression. However, in
suppression. However, in cases where the application purposefully cases where the application purposefully specifies a very small
specifies a very small "Ksender" backoff factor to minimize the NACK "Ksender" backoff factor to minimize the NACK repair process latency
repair process latency (trading off group size scalability), it is (trading off group size scalability), it is RECOMMENDED that a larger
RECOMMENDED that a larger backoff factor for congestion control backoff factor for congestion control feedback is maintained, since
feedback is maintained, since there may often be a larger volume of there may often be a larger volume of congestion control feedback
congestion control feedback than NACKs in many cases and some than NACKs in many cases and some congestion control feedback latency
congestion control feedback latency may be tolerable where reliable may be tolerable where reliable delivery latency is not. As
delivery latency is not. As previously noted, a backoff factor value previously noted, a backoff factor value of "K = 4" is generally
of "K = 4" is generally recommended for ASM operation and "K = 6" for recommended for ASM operation and "K = 6" for SSM operation. A
SSM operation. A receiver SHALL cancel the backoff timeout and thus receiver SHALL cancel the backoff timeout and thus its pending
its pending transmission of a "NORM_ACK(RTT)" message under the transmission of a "NORM_ACK(RTT)" message under the following
following conditions: conditions:
1. The receiver generates another feedback message ("NORM_NACK" or 1. The receiver generates another feedback message ("NORM_NACK" or
other "NORM_ACK") before the congestion control feedback timeout other "NORM_ACK") before the congestion control feedback timeout
expires (these messages will convey the current congestion expires (these messages will convey the current congestion
control feedback information), control feedback information),
2. A "NORM_CMD(CC)" or other receiver feedback with an ordinally 2. A "NORM_CMD(CC)" or other receiver feedback with an ordinally
greater "cc_sequence" field value is received before the greater "cc_sequence" field value is received before the
congestion control feedback timeout expires (this is similar to congestion control feedback timeout expires (this is similar to
the TFMCC feedback round number), the TFMCC feedback round number),
3. When the "T_backoff" is greater than "1*GRTTsender". This 3. When the "T_backoff" is greater than "1*GRTTsender". This
prevents NACK implosion in the event of sender or network prevents NACK implosion in the event of sender or network
failure, failure,
4. "Suppressing" congestion control feedback is heard from another 4. "Suppressing" congestion control feedback is heard from another
receiver (in a "NORM_ACK" or "NORM_NACK") or via a receiver (in a "NORM_ACK" or "NORM_NACK") or via a
"NORM_CMD(REPAIR_ADV)" message from the sender. The local "NORM_CMD(REPAIR_ADV)" message from the sender. The local
receiver's feedback is "suppressed" if the rate of the competing receiver's feedback is "suppressed" if the rate of the competing
feedback ("Rfb") is sufficiently close to or less than the local feedback ("Rfb") is sufficiently close to or less than the local
receiver's calculated rate ("Rcalc"). The local receiver's receiver's calculated rate ("Rcalc"). The local receiver's
feedback is canceled when "Rcalc > (0.9 * Rfb)". Also note feedback is canceled when "Rcalc > (0.9 * Rfb)". Also note
receivers that have not yet received an RTT measurement from the receivers that have not yet received an RTT measurement from the
sender are suppressed only by other receivers that have not yet sender are suppressed only by other receivers that have not yet
measured RTT. Additionally, receivers whose RTT estimate has measured RTT. Additionally, receivers whose RTT estimate has
skipping to change at page 86, line 9 skipping to change at page 85, line 35
Toni Paila, Michael Luby, and Joerg Widmer for their valuable input Toni Paila, Michael Luby, and Joerg Widmer for their valuable input
and comments on this document. The authors would also like to thank and comments on this document. The authors would also like to thank
the RMT working group chairs, Roger Kermode and Lorenzo Vicisano, for the RMT working group chairs, Roger Kermode and Lorenzo Vicisano, for
their support in development of this specification, and Sally Floyd their support in development of this specification, and Sally Floyd
for her early input into this document. for her early input into this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-rmt-bb-norm-revised]
Adamson, B., Bormann, C., London, U., and J. Macker,
"Multicast Negative-Acknowledgment (NACK) Building
Blocks", draft-ietf-rmt-bb-norm-revised-07 (work in
progress), September 2008.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989. RFC 1112, August 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
skipping to change at page 86, line 38 skipping to change at page 86, line 12
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006. IP", RFC 4607, August 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 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Correction (FEC) Building Block", RFC 5052, August 2007. Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5401] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"Multicast Negative-Acknowledgment (NACK) Building
Blocks", RFC 5401, November 2008.
11.2. Informative References 11.2. Informative References
[FecHybrid] [FecHybrid]
Gossink, D. and J. Macker, "Reliable Multicast and Gossink, D. and J. Macker, "Reliable Multicast and
Integrated Parity Retransmission with Channel Estimation", Integrated Parity Retransmission with Channel Estimation",
IEEE Globecomm , 1998. IEEE Globecomm , 1998.
[I-D.ietf-rmt-bb-fec-basic-schemes-revised] [I-D.ietf-rmt-bb-fec-basic-schemes-revised]
Watson, M., "Basic Forward Error Correction (FEC) Watson, M., "Basic Forward Error Correction (FEC)
Schemes", draft-ietf-rmt-bb-fec-basic-schemes-revised-05 Schemes", draft-ietf-rmt-bb-fec-basic-schemes-revised-06
(work in progress), July 2008. (work in progress), October 2008.
[McastFeedback] [McastFeedback]
Nonnenmacher, J. and E. Biersack, "Optimal Multicast Nonnenmacher, J. and E. Biersack, "Optimal Multicast
Feedback", IEEE INFOCOM, p. 964, March/April 1998. Feedback", IEEE INFOCOM, p. 964, March/April 1998.
[MdpToolkit] [MdpToolkit]
Macker, J. and B. Adamson, "The Multicast Dissemination Macker, J. and B. Adamson, "The Multicast Dissemination
Protocol (MDP) Toolkit", Proc. IEEE MILCOM , October 1999. Protocol (MDP) Toolkit", Proc. IEEE MILCOM , October 1999.
[Mdpcc] Adamson, B. and J. Macker, "A TCP-Friendly, Rate-based [Mdpcc] Adamson, B. and J. Macker, "A TCP-Friendly, Rate-based
skipping to change at page 88, line 28 skipping to change at page 87, line 51
"Negative-acknowledgment (NACK)-Oriented Reliable "Negative-acknowledgment (NACK)-Oriented Reliable
Multicast (NORM) Protocol", RFC 3940, November 2004. Multicast (NORM) Protocol", RFC 3940, November 2004.
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross,
"GSAKMP: Group Secure Association Key Management "GSAKMP: Group Secure Association Key Management
Protocol", RFC 4535, June 2006. Protocol", RFC 4535, June 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast
Congestion Control (TFMCC): Protocol Specification",
RFC 4654, August 2006.
[RmComparison] [RmComparison]
Pingali, S., Towsley, D., and J. Kurose, "A Comparison of Pingali, S., Towsley, D., and J. Kurose, "A Comparison of
Sender-Initiated and Receiver-Initiated Reliable Multicast Sender-Initiated and Receiver-Initiated Reliable Multicast
Protocols", Proc. INFOCOMM, San Francisco CA, Protocols", Proc. INFOCOMM, San Francisco CA,
October 1993. October 1993.
[TcpModel] [TcpModel]
Padhye, J., Firoiu, V., Towsley, D., and J. Kurose, Padhye, J., Firoiu, V., Towsley, D., and J. Kurose,
"Modeling TCP Throughput: A Simple Model and its Empirical "Modeling TCP Throughput: A Simple Model and its Empirical
Validation", ACM SIGCOMM , 1998. Validation", ACM SIGCOMM , 1998.
 End of changes. 30 change blocks. 
104 lines changed or deleted 96 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/