draft-ietf-rmt-pi-norm-revised-05.txt   draft-ietf-rmt-pi-norm-revised-06.txt 
Reliable Multicast Transport (RMT) B. Adamson Reliable Multicast Transport (RMT) B. Adamson
Working Group NRL Working Group NRL
Internet-Draft C. Bormann Internet-Draft C. Bormann
Expires: 31 December 2007 Universitaet Bremen TZI Expires: 31 July 2008 Universitaet Bremen TZI
M. Handley M. Handley
UCL UCL
J. Macker J. Macker
NRL NRL
NACK-Oriented Reliable Multicast (NORM) Protocol NACK-Oriented Reliable Multicast (NORM) Protocol
draft-ietf-rmt-pi-norm-revised-05 draft-ietf-rmt-pi-norm-revised-06
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 37 skipping to change at page 1, line 37
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 December 31, 2007. This Internet-Draft will expire on July 31, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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" mechanisms to allow for operation with minimal "a priori"
skipping to change at page 4, line 12 skipping to change at page 4, line 12
6.1.2.5. Authentication and Encryption. . . . . . . . . . . . . . 87 6.1.2.5. Authentication and Encryption. . . . . . . . . . . . . . 87
6.1.2.6. Availability . . . . . . . . . . . . . . . . . . . . . . 87 6.1.2.6. Availability . . . . . . . . . . . . . . . . . . . . . . 87
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 88
8. Suggested Use . . . . . . . . . . . . . . . . . . . . . . . . . . 89 8. Suggested Use . . . . . . . . . . . . . . . . . . . . . . . . . . 89
9. Changes from RFC3940. . . . . . . . . . . . . . . . . . . . . . . 89 9. Changes from RFC3940. . . . . . . . . . . . . . . . . . . . . . . 89
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . 90 10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . 90
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
11.1. Normative References. . . . . . . . . . . . . . . . . . . . . 90 11.1. Normative References. . . . . . . . . . . . . . . . . . . . . 90
11.2. Informative References. . . . . . . . . . . . . . . . . . . . 91 11.2. Informative References. . . . . . . . . . . . . . . . . . . . 91
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 93 12. Authors Addresses . . . . . . . . . . . . . . . . . . . . . . . 93
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 94 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 94
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,
scalable, and robust bulk data (e.g., computer files, transmission of scalable, and robust bulk data (e.g., computer files, transmission of
persistent data) transfer across possibly heterogeneous IP networks persistent data) transfer across possibly heterogeneous IP networks
skipping to change at page 7, line 7 skipping to change at page 7, line 7
simply to provide a "hint" to receivers in NormSessions serving simply to provide a "hint" to receivers in NormSessions serving
multiple types of content as to what type of storage should be multiple types of content as to what type of storage should be
allocated for received content (i.e., memory or file storage). Other allocated for received content (i.e., memory or file storage). Other
than that distinction, the two are identical, providing for reliable than that distinction, the two are identical, providing for reliable
transport of finite (but potentially very large) units of content. transport of finite (but potentially very large) units of content.
These static data and file services are anticipated to be useful for These static data and file services are anticipated to be useful for
multicast-based cache applications with the ability to reliably multicast-based cache applications with the ability to reliably
provide transmission of large quantities of static data. Other types provide transmission of large quantities of static data. Other types
of static data/file delivery services might make use of these of static data/file delivery services might make use of these
transport object types, too. The use of the NORM_OBJECT_STREAM type transport object types, too. The use of the NORM_OBJECT_STREAM type
is at the application's discretion and could be used to carry static is at the applications discretion and could be used to carry static
data or file content also. The NORM reliable stream service opens up data or file content also. The NORM reliable stream service opens up
additional possibilities such as serialized reliable messaging or additional possibilities such as serialized reliable messaging or
other unbounded, perhaps dynamically produced content. The other unbounded, perhaps dynamically produced content. The
NORM_OBJECT_STREAM provides for reliable transport analogous to that NORM_OBJECT_STREAM provides for reliable transport analogous to that
of the Transmission Control Protocol (TCP), although NORM receivers of the Transmission Control Protocol (TCP), although NORM receivers
will be able to begin receiving stream content at any point in time. will be able to begin receiving stream content at any point in time.
The applicability of this feature will depend upon the application. The applicability of this feature will depend upon the application.
The NORM protocol also allows for a small amount of "out-of-band" The NORM protocol also allows for a small amount of "out-of-band"
data (sent as NORM_INFO messages) to be attached to the data content data (sent as NORM_INFO messages) to be attached to the data content
objects transmitted by the sender. This readily-available "out-of- objects transmitted by the sender. This readily-available "out-of-
band" data allows multicast receivers to quickly and efficiently band" data allows multicast receivers to quickly and efficiently
determine the nature of the corresponding data, file, or stream bulk determine the nature of the corresponding data, file, or stream bulk
content being transmitted. This allows application-level control of content being transmitted. This allows application-level control of
the receiver node's participation in the current transport activity. the receiver nodes participation in the current transport activity.
This also allows the protocol to be flexible with minimal pre- This also allows the protocol to be flexible with minimal pre-
coordination among senders and receivers. The NORM_INFO content is coordination among senders and receivers. The NORM_INFO content is
designed to be atomic in that its size MUST fit into the payload designed to be atomic in that its size MUST fit into the payload
portion of a single NORM message. portion of a single NORM message.
NORM does _not_ provide for global or application-level NORM does _not_ provide for global or application-level
identification of data content within in its message headers. Note identification of data content within in its message headers. Note
the NORM_INFO out-of-band data mechanism could be leveraged by the the NORM_INFO out-of-band data mechanism could be leveraged by the
application for this purpose if desired, or identification could application for this purpose if desired, or identification could
alternatively be embedded within the data content. NORM does alternatively be embedded within the data content. NORM does
skipping to change at page 8, line 32 skipping to change at page 8, line 32
techniques for efficient multicast repair and optional proactive techniques for efficient multicast repair and optional proactive
transmission robustness [14]. FEC-based repair can be used to transmission robustness [14]. FEC-based repair can be used to
greatly reduce the quantity of reliable multicast repair requests and greatly reduce the quantity of reliable multicast repair requests and
repair transmissions [15] in a NACK-oriented protocol. The principal repair transmissions [15] in a NACK-oriented protocol. The principal
factor in NORM scalability is the volume of feedback traffic factor in NORM scalability is the volume of feedback traffic
generated by the receiver set to facilitate reliability and generated by the receiver set to facilitate reliability and
congestion control. NORM uses probabilistic suppression of redundant congestion control. NORM uses probabilistic suppression of redundant
feedback based on exponentially distributed random backoff timers. feedback based on exponentially distributed random backoff timers.
The performance of this type of suppression relative to other The performance of this type of suppression relative to other
techniques is described in [16]. NORM dynamically measures the techniques is described in [16]. NORM dynamically measures the
group's roundtrip timing status to set its suppression and other groups roundtrip timing status to set its suppression and other
protocol timers. This allows NORM to scale well while maintaining protocol timers. This allows NORM to scale well while maintaining
reliable data delivery transport with low latency relative to the reliable data delivery transport with low latency relative to the
network topology over which it is operating. network topology over which it is operating.
Feedback messages can be either multicast to the group at large or Feedback messages can be either multicast to the group at large or
sent via unicast routing to the sender. In the case of unicast sent via unicast routing to the sender. In the case of unicast
feedback, the sender "advertises" the feedback state to the group to feedback, the sender "advertises" the feedback state to the group to
facilitate feedback suppression. In typical Internet environments, facilitate feedback suppression. In typical Internet environments,
it is expected that the NORM protocol will readily scale to group it is expected that the NORM protocol will readily scale to group
sizes on the order of tens of thousands of receivers. A study of the sizes on the order of tens of thousands of receivers. A study of the
skipping to change at page 10, line 6 skipping to change at page 10, line 6
preclude multiple sender nodes concurrently transmitting within the preclude multiple sender nodes concurrently transmitting within the
context of a single NORM session (i.e., many- to-many operation), any context of a single NORM session (i.e., many- to-many operation), any
type of interactive coordination among NORM senders is assumed to be type of interactive coordination among NORM senders is assumed to be
controlled by the application or higher protocol layer. There are controlled by the application or higher protocol layer. There are
some optional mechanisms specified in this document that can be some optional mechanisms specified in this document that can be
leveraged for such application layer coordination. leveraged for such application layer coordination.
As previously noted, NORM allows for reliable transmission of three As previously noted, NORM allows for reliable transmission of three
different basic types of data content. The first type is different basic types of data content. The first type is
NORM_OBJECT_DATA, which is used for static, persistent blocks of data NORM_OBJECT_DATA, which is used for static, persistent blocks of data
content maintained in the sender's application memory storage. The content maintained in the senders application memory storage. The
second type is NORM_OBJECT_FILE, which corresponds to data stored in second type is NORM_OBJECT_FILE, which corresponds to data stored in
the sender's non-volatile file system. The NORM_OBJECT_DATA and the senders non-volatile file system. The NORM_OBJECT_DATA and
NORM_OBJECT_FILE types both represent "NormObjects" of finite but NORM_OBJECT_FILE types both represent "NormObjects" of finite but
potentially very large size. The third type of data content is potentially very large size. The third type of data content is
NORM_OBJECT_STREAM, which corresponds to an ongoing transmission of NORM_OBJECT_STREAM, which corresponds to an ongoing transmission of
undefined length. This is analogous to the reliable stream service undefined length. This is analogous to the reliable stream service
provide by TCP for unicast data transport. The format of the stream provide by TCP for unicast data transport. The format of the stream
content is application-defined and may be byte or message oriented. content is application-defined and may be byte or message oriented.
The NORM protocol provides for "flushing" of the stream to expedite The NORM protocol provides for "flushing" of the stream to expedite
delivery or possibly enforce application message boundaries. NORM delivery or possibly enforce application message boundaries. NORM
protocol implementations may offer either (or both) in-order delivery protocol implementations may offer either (or both) in-order delivery
of the stream data to the receive application or out-of-order (more of the stream data to the receive application or out-of-order (more
skipping to change at page 10, line 42 skipping to change at page 10, line 42
in response to repair requests, but some number may be sent in response to repair requests, but some number may be sent
proactively at the end each encoding block to increase the robustness proactively at the end each encoding block to increase the robustness
of transmission. When non-systematic FEC codes are used, all symbols of transmission. When non-systematic FEC codes are used, all symbols
sent consist of FEC encoding parity content. In this case, the sent consist of FEC encoding parity content. In this case, the
receiver must receive a sufficient number of symbols to reconstruct receiver must receive a sufficient number of symbols to reconstruct
(via FEC decoding) the original user data for the given block. In (via FEC decoding) the original user data for the given block. In
this document, the terms "symbol" and "segment" are used this document, the terms "symbol" and "segment" are used
interchangeably. interchangeably.
Transmitted NormObjects are temporarily yet uniquely identified Transmitted NormObjects are temporarily yet uniquely identified
within the NormSession context using the given sender's NormNodeId, within the NormSession context using the given senders NormNodeId,
NormInstanceId, and a temporary NormObjectTransportId. Depending NormInstanceId, and a temporary NormObjectTransportId. Depending
upon the implementation, individual NORM senders may manage their upon the implementation, individual NORM senders may manage their
NormInstanceIds independently, or a common NormInstanceId may be NormInstanceIds independently, or a common NormInstanceId may be
agreed upon for all participating nodes within a session if needed as agreed upon for all participating nodes within a session if needed as
a session identifier. NORM NormObjectTransportId data content a session identifier. NORM NormObjectTransportId data content
identifiers are sender-assigned and applicable and valid only during identifiers are sender-assigned and applicable and valid only during
a NormObject's actual _transport_ (i.e., for as long as the sender is a NormObjects actual _transport_ (i.e., for as long as the sender is
transmitting and providing repair of the indicated NormObject). For transmitting and providing repair of the indicated NormObject). For
a long-lived session, the NormObjectTransportId field can wrap and a long-lived session, the NormObjectTransportId field can wrap and
previously-used identifiers may be re-used. Note that globally previously-used identifiers may be re-used. Note that globally
unique identification of transported data content is not provided by unique identification of transported data content is not provided by
NORM and, if required, must be managed by the NORM application. The NORM and, if required, must be managed by the NORM application. The
individual segments or symbols of the NormObject are further individual segments or symbols of the NormObject are further
identified with FEC payload identifiers which include coding block identified with FEC payload identifiers which include coding block
and symbol identifiers. These are discussed in detail later in this and symbol identifiers. These are discussed in detail later in this
document. document.
skipping to change at page 11, line 34 skipping to change at page 11, line 34
transmission overhead. This option may be sensible for certain transmission overhead. This option may be sensible for certain
network conditions and can allow for robust, asymmetric multicast network conditions and can allow for robust, asymmetric multicast
(e.g., unidirectional routing, satellite, cable) [19] with reduced (e.g., unidirectional routing, satellite, cable) [19] with reduced
receiver feedback, or, in some cases, no feedback. receiver feedback, or, in some cases, no feedback.
A sender message of type NORM_INFO is also defined and is used to A sender message of type NORM_INFO is also defined and is used to
carry OPTIONAL "out-of-band" context information for a given carry OPTIONAL "out-of-band" context information for a given
transport object. A single NORM_INFO message can be associated with transport object. A single NORM_INFO message can be associated with
a NormObject. Because of its atomic nature, missing NORM_INFO a NormObject. Because of its atomic nature, missing NORM_INFO
messages can be NACKed and repaired with a slightly lower delay messages can be NACKed and repaired with a slightly lower delay
process than NORM's general FEC-encoded data content. NORM_INFO may process than NORMs general FEC-encoded data content. NORM_INFO may
serve special purposes for some bulk transfer, reliable multicast serve special purposes for some bulk transfer, reliable multicast
applications where receivers join the group mid-stream and need to applications where receivers join the group mid-stream and need to
ascertain contextual information on the current content being ascertain contextual information on the current content being
transmitted. The NACK process for NORM_INFO will be described later. transmitted. The NACK process for NORM_INFO will be described later.
When the NORM_INFO message type is used, its transmission should When the NORM_INFO message type is used, its transmission should
precede transmission of any NORM_DATA message for the associated precede transmission of any NORM_DATA message for the associated
NormObject. NormObject.
The sender also generates messages of type NORM_CMD to assist in The sender also generates messages of type NORM_CMD to assist in
certain protocol operations such as congestion control, end-of- certain protocol operations such as congestion control, end-of-
skipping to change at page 12, line 27 skipping to change at page 12, line 27
it is possible that even participants acting principally as data it is possible that even participants acting principally as data
receivers MAY transmit NORM_CMD messages. However, it is RECOMMENDED receivers MAY transmit NORM_CMD messages. However, it is RECOMMENDED
that this is not done within the context of the NORM multicast that this is not done within the context of the NORM multicast
session unless congestion control is addressed. For example, many session unless congestion control is addressed. For example, many
receiver nodes transmitting NORM_CMD messages simultaneously can receiver nodes transmitting NORM_CMD messages simultaneously can
cause congestion for the destination(s). cause congestion for the destination(s).
All sender transmissions are subject to rate control governed by a All sender transmissions are subject to rate control governed by a
peak transmission rate set for each participant by the application. peak transmission rate set for each participant by the application.
This can be used to limit the quantity of multicast data transmitted This can be used to limit the quantity of multicast data transmitted
by the group. When NORM's congestion control algorithm is enabled by the group. When NORMs congestion control algorithm is enabled
the rate for senders is automatically adjusted. In some networks, it the rate for senders is automatically adjusted. In some networks, it
may be desirable to establish minimum and maximum bounds for the rate may be desirable to establish minimum and maximum bounds for the rate
adjustment depending upon the application even when dynamic adjustment depending upon the application even when dynamic
congestion control is enabled. However, in the case of the general congestion control is enabled. However, in the case of the general
Internet, congestion control policy SHALL be observed that is Internet, congestion control policy SHALL be observed that is
compatible with coexistent TCP flows. compatible with coexistent TCP flows.
NORM receivers generate messages of type NORM_NACK or NORM_ACK in NORM receivers generate messages of type NORM_NACK or NORM_ACK in
response to transmissions of data and commands from a sender. The response to transmissions of data and commands from a sender. The
NORM_NACK messages are generated to request repair of detected data NORM_NACK messages are generated to request repair of detected data
skipping to change at page 18, line 18 skipping to change at page 18, line 18
Message Value Message Value
NORM_INFO 1 NORM_INFO 1
NORM_DATA 2 NORM_DATA 2
NORM_CMD 3 NORM_CMD 3
NORM_NACK 4 NORM_NACK 4
NORM_ACK 5 NORM_ACK 5
NORM_REPORT 6 NORM_REPORT 6
The 8-bit "hdr_len" field indicates the number of 32-bit words that The 8-bit "hdr_len" field indicates the number of 32-bit words that
comprise the given message's header portion. This is used to comprise the given messages header portion. This is used to
facilitate header extensions that may be applied. The presence of facilitate header extensions that may be applied. The presence of
header extensions are implied when the "hdr_len" value is greater header extensions are implied when the "hdr_len" value is greater
than the base value for the given message "type". than the base value for the given message "type".
The "sequence" field is a 16-bit value that is set by the message The "sequence" field is a 16-bit value that is set by the message
originator as a monotonically increasing number incremented with each originator as a monotonically increasing number incremented with each
NORM message transmitted. Note that two independent "sequence" NORM message transmitted. Note that two independent "sequence"
spaces MUST be maintained. One sequence space SHALL be kept for NORM spaces MUST be maintained. One sequence space SHALL be kept for NORM
sender messages (NORM_INFO, NORM_DATA, and NORM_CMD) generated, and a sender messages (NORM_INFO, NORM_DATA, and NORM_CMD) generated, and a
separate, independent "sequence" space SHALL be kept for NORM separate, independent "sequence" space SHALL be kept for NORM
skipping to change at page 18, line 48 skipping to change at page 18, line 48
sequence numbered. An independent sequence space MUST be used for sequence numbered. An independent sequence space MUST be used for
receiver messages because when receivers generate unicast NORM_NACK receiver messages because when receivers generate unicast NORM_NACK
or NORM_ACK messages, those messages will not be visible to the group or NORM_ACK messages, those messages will not be visible to the group
at large that may be performing loss estimation. Also, NORM at large that may be performing loss estimation. Also, NORM
congestion control is applied only to sender messages. The size of congestion control is applied only to sender messages. The size of
the "sequence" field is intended to be sufficient to allow detection the "sequence" field is intended to be sufficient to allow detection
of a reasonable range of packet loss within the delay-bandwidth of a reasonable range of packet loss within the delay-bandwidth
product of expected network connections. product of expected network connections.
The "source_id" field is a 32-bit value identifying the node that The "source_id" field is a 32-bit value identifying the node that
sent the message. A participant's NORM node identifier (NormNodeId) sent the message. A participants NORM node identifier (NormNodeId)
can be set according to application needs but unique identifiers must can be set according to application needs but unique identifiers must
be assigned within a single NormSession. In some cases, use of the be assigned within a single NormSession. In some cases, use of the
host IP address or a hash of it can suffice, but alternative host IP address or a hash of it can suffice, but alternative
methodologies for assignment and potential collision resolution of methodologies for assignment and potential collision resolution of
node identifiers within a multicast session need to be considered. node identifiers within a multicast session need to be considered.
For example, the "source identifier" mechanism defined in the Real- For example, the "source identifier" mechanism defined in the Real-
Time Protocol (RTP) specification [22] may be applicable to use for Time Protocol (RTP) specification [22] may be applicable to use for
NORM node identifiers. At this point in time, the protocol makes no NORM node identifiers. At this point in time, the protocol makes no
assumptions about how these unique identifiers are actually assigned. assumptions about how these unique identifiers are actually assigned.
NORM Header Extensions NORM Header Extensions
When header extensions are applied, they follow the message type's When header extensions are applied, they follow the message types
base header and precede any payload portion. There are two formats base header and precede any payload portion. There are two formats
for header extensions, both of which begin with an 8-bit "het" for header extensions, both of which begin with an 8-bit "het"
(header extension type) field. One format is provided for variable- (header extension type) field. One format is provided for variable-
length extensions with "het" values in the range from 0 through 127. length extensions with "het" values in the range from 0 through 127.
The other format is for fixed length (one 32-bit word) extensions The other format is for fixed length (one 32-bit word) extensions
with "het" values in the range from 128 through 255. These formats with "het" values in the range from 128 through 255. These formats
are given here: are 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
skipping to change at page 22, line 36 skipping to change at page 22, line 36
The "instance_id" field contains a value generated by the sender to The "instance_id" field contains a value generated by the sender to
uniquely identify its current instance of participation in the uniquely identify its current instance of participation in the
NormSession. This allows receivers to detect when senders have NormSession. This allows receivers to detect when senders have
perhaps left and rejoined a session in progress. When a sender perhaps left and rejoined a session in progress. When a sender
(identified by its "source_id") is detected to have a new (identified by its "source_id") is detected to have a new
"instance_id", the NORM receivers SHOULD drop their previous state on "instance_id", the NORM receivers SHOULD drop their previous state on
the sender and begin reception anew, or at least treat this the sender and begin reception anew, or at least treat this
"instance" as a new, separate sender. "instance" as a new, separate sender.
The "grtt" field contains a non-linear quantized representation of The "grtt" field contains a non-linear quantized representation of
the sender's current estimate of group round-trip time (GRTT) (this the senders current estimate of group round-trip time (GRTT) (this
is also referred to as R_max in [24]). This value is used to control is also referred to as R_max in [24]). This value is used to control
timing of the NACK repair process and other aspects of protocol timing of the NACK repair process and other aspects of protocol
operation as described in this document. Normally, the advertised operation as described in this document. Normally, the advertised
"grtt" value will correspond to what the sender has measured based on "grtt" value will correspond to what the sender has measured based on
feedback from the group, but, at low transmission rates, the feedback from the group, but, at low transmission rates, the
advertised "grtt" SHALL be set to MAX(grttMeasured, 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 NORM Building Block and decoding this field is described in the RMT NORM Building Block
document [3]. document [3].
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 receiver set of the backoff timeout. The "backoff" field informs the receiver set of the
sender's backoff factor parameter "Ksender". Recommended values and senders 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. The "gsize" field contains a description in Section 5.3. The "gsize" field contains a
representation of the sender's current estimate of group size. This representation of the senders current estimate of group size. This
4-bit field can roughly represent values from ten to 500 million 4-bit field can roughly represent values from ten to 500 million
where the most significant bit value of 0 or 1 represents a mantissa where the most significant bit value of 0 or 1 represents a mantissa
of 1 or 5, respectively and the three least significant bits of 1 or 5, respectively and the three least significant bits
incremented by one represent a base 10 exponent (order of magnitude). incremented by one represent a base 10 exponent (order of magnitude).
For examples, a field value of "0x0" represents 1.0e+01 (10), a value For examples, a field value of "0x0" represents 1.0e+01 (10), a value
of "0x8" represents 5.0e+01 (50), a value of "0x1" represents 1.0e+02 of "0x8" represents 5.0e+01 (50), a value of "0x1" represents 1.0e+02
(100), and a value of "0xf" represents 5.0e+08. For NORM feedback (100), and a value of "0xf" represents 5.0e+08. For NORM feedback
suppression purposes, the group size does not need to be represented suppression purposes, the group size does not need to be represented
with a high degree of precision. The group size may even be with a high degree of precision. The group size may even be
estimated somewhat conservatively (i.e., overestimated) to maintain estimated somewhat conservatively (i.e., overestimated) to maintain
skipping to change at page 26, line 22 skipping to change at page 26, line 22
Example FEC Payload ID Field ("fec_payload_id") Format Example FEC Payload ID Field ("fec_payload_id") Format
for Small Block, Systematic Codes ("fec_id" = 129) for Small Block, Systematic Codes ("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 given by the FEC Basic Schemes
document [25]. for the Small Block Systematic FEC Scheme identified document [25]. for the Small Block Systematic FEC Scheme identified
by a "fec_id" value of 129. The "source_block_number" identifies the by a "fec_id" value of 129. The "source_block_number" identifies the
coding block's relative position with a NormObject. Note that, for coding blocks relative position with a NormObject. Note that, for
NormObjects of type NORM_OBJECT_STREAM, the "source_block_number" may NormObjects of type NORM_OBJECT_STREAM, the "source_block_number" may
wrap for very long lived sessions. The "source_block_len" indicates wrap for very long lived sessions. The "source_block_len" indicates
the number of user data segments in the identified coding block. the number of user data segments in the identified coding block.
Given the "source_block_len" information of how many symbols of Given the "source_block_len" information of how many symbols of
application data are contained in the block, the receiver can application data are contained in the block, the receiver can
determine whether the attached segment is data or parity content and determine whether the attached segment is data or parity content and
treat it appropriately. Some applications may dynamically "shorten" treat it appropriately. Some applications may dynamically "shorten"
code blocks when the pending information content is not predictable code blocks when the pending information content is not predictable
(e.g. real-time message streams). In that case, the (e.g. real-time message streams). In that case, the
"source_block_len" value given for an "encoding_symbol_id" that "source_block_len" value given for an "encoding_symbol_id" that
skipping to change at page 26, line 52 skipping to change at page 26, line 52
identifies which specific symbol (segment) within the coding block identifies which specific symbol (segment) within the coding block
the attached payload conveys. Depending upon the value of the the attached payload conveys. Depending upon the value of the
"encoding_symbol_id" and the associated "source_block_len" parameters "encoding_symbol_id" and the associated "source_block_len" parameters
for the block, the symbol (segment) referenced may be a user data or for the block, the symbol (segment) referenced may be a user data or
an FEC parity segment. For systematic codes, encoding symbols an FEC parity segment. For systematic codes, encoding symbols
numbered less than the source_block_len contain original application numbered less than the source_block_len contain original application
data while segments greater than or equal to source_block_len contain data while segments greater than or equal to source_block_len contain
parity symbols calculated for the block. The concatenation of parity symbols calculated for the block. The concatenation of
object_transport_id::fec_payload_id can be viewed as a unique object_transport_id::fec_payload_id can be viewed as a unique
transport protocol data unit identifier for the attached segment with transport protocol data unit identifier for the attached segment with
respect to the NORM sender's instance within a session. respect to the NORM senders instance within a session.
Additional FEC Object Transmission Information (as described in the Additional FEC Object Transmission Information (as described in the
FEC Building Block document [4]) is required to properly receive and FEC Building Block document [4]) is required to properly receive and
decode NORM transport objects. This information MAY be provided as decode NORM transport objects. This information MAY be provided as
out-of-band session information. However, in some cases, it may be out-of-band session information. However, in some cases, it may be
useful for the sender to include this information "in-band" to useful for the sender to include this information "in-band" to
facilitate receiver operation with minimal preconfiguration. For facilitate receiver operation with minimal preconfiguration. For
this purpose, the NORM FEC Object Transmission Information Header this purpose, the NORM FEC Object Transmission Information Header
Extension (EXT_FTI) is defined. This header extension MAY be applied Extension (EXT_FTI) is defined. This header extension MAY be applied
to NORM_DATA and NORM_INFO messages to provide this necessary to NORM_DATA and NORM_INFO messages to provide this necessary
skipping to change at page 28, line 32 skipping to change at page 28, line 32
FEC schemes. FEC schemes.
The 48-bit "object_size" serves the purpose described previously. The 48-bit "object_size" serves the purpose described previously.
The "fec_instance_id" corresponds to the "FEC Instance ID" described The "fec_instance_id" corresponds to the "FEC Instance ID" described
in the FEC Building Block document [4]. In this case, the in the FEC Building Block document [4]. In this case, the
"fec_instance_id" is a value corresponding to the particular type of "fec_instance_id" is a value corresponding to the particular type of
Small Block Systematic Code being used (e.g., Reed-Solomon GF(2^8), Small Block Systematic Code being used (e.g., Reed-Solomon GF(2^8),
Reed-Solomon GF(2^16), etc). The standardized assignment of FEC Reed-Solomon GF(2^16), etc). The standardized assignment of FEC
Instance ID values is described in [4]. The "segment_size" field Instance ID values is described in [4]. The "segment_size" field
indicates the sender's current setting for maximum message payload indicates the senders current setting for maximum message payload
content (in bytes). This allows receivers to allocate appropriate content (in bytes). This allows receivers to allocate appropriate
buffering resources and to determine other information in order to buffering resources and to determine other information in order to
properly process received data messaging. Typically, FEC parity properly process received data messaging. Typically, FEC parity
symbol segments will be of this size. symbol segments will be of this size.
The "fec_max_block_len" indicates the current maximum number of user The "fec_max_block_len" indicates the current maximum number of user
data segments per FEC coding block to be used by the sender during data segments per FEC coding block to be used by the sender during
the session. This allows receivers to allocate appropriate buffer the session. This allows receivers to allocate appropriate buffer
space for buffering blocks transmitted by the sender. space for buffering blocks transmitted by the sender.
skipping to change at page 29, line 49 skipping to change at page 29, line 49
When the "payload_len" value is non-zero, the "payload_msg_start" When the "payload_len" value is non-zero, the "payload_msg_start"
field, when it is set to a non-zero value, indicates that the field, when it is set to a non-zero value, indicates that the
associated "payload_data" content contains an application-defined associated "payload_data" content contains an application-defined
message boundary (start-of-message). When such a message boundary is message boundary (start-of-message). When such a message boundary is
indicated, the first byte of an application-defined message, with indicated, the first byte of an application-defined message, with
respect to the "payload_data" field, will be found at an offset of respect to the "payload_data" field, will be found at an offset of
"payload_msg_start - 1" bytes. Thus, if a NORM_OBJECT_STREAM "payload_msg_start - 1" bytes. Thus, if a NORM_OBJECT_STREAM
NORM_DATA payload contains the start of an application message at the NORM_DATA payload contains the start of an application message at the
first byte of the "payload_data" field, the value of the first byte of the "payload_data" field, the value of the
"payload_msg_start" field will be '1'. Again, if the value of the "payload_msg_start" field will be ’1’. Again, if the value of the
"payload_msg_start" field is ZERO, no message boundary is indicated. "payload_msg_start" field is ZERO, no message boundary is indicated.
It is RECOMMENDED that NORM implementations provide sender stream It is RECOMMENDED that NORM implementations provide sender stream
applications with a capability to mark message boundaries in this applications with a capability to mark message boundaries in this
manner. Similarly, the NORM receiver SHOULD enable the application manner. Similarly, the NORM receiver SHOULD enable the application
to recover such message boundary information. This enables NORM to recover such message boundary information. This enables NORM
receivers to "synchronize" with transmitted message stream content in receivers to "synchronize" with transmitted message stream content in
a meaningful way (i.e., meaningful to the application) at any time, a meaningful way (i.e., meaningful to the application) at any time,
whether joining the session late, or departing the session and whether joining the session late, or departing the session and
returning. returning.
and "payload_offset" fields indicate the size and relative position and "payload_offset" fields indicate the size and relative position
(within the stream) of the source content contained in the (within the stream) of the source content contained in the
"payload_data" field. Note that for long-lived streams, the "payload_data" field. Note that for long-lived streams, the
"payload_offset" field may wrap. "payload_offset" field may wrap.
The "payload_data" field contains the original application source or The "payload_data" field contains the original application source or
parity content for the symbol identified by the "fec_payload_id". parity content for the symbol identified by the "fec_payload_id".
The length of this field SHALL be limited to a maximum of the The length of this field SHALL be limited to a maximum of the
sender's NormSegmentSize bytes as given in the FTI for the object. senders NormSegmentSize bytes as given in the FTI for the object.
Note the length of this field for messages containing parity content Note the length of this field for messages containing parity content
will always be of length NormSegmentSize. When encoding data will always be of length NormSegmentSize. When encoding data
segments of varying sizes, the FEC encoder SHALL assume ZERO value segments of varying sizes, the FEC encoder SHALL assume ZERO value
padding for data segments with length less than the NormSegmentSize. padding for data segments with length less than the NormSegmentSize.
It is RECOMMENDED that a sender's NormSegmentSize generally be It is RECOMMENDED that a sender’s NormSegmentSize generally be
constant for the duration of a given sender's term of participation constant for the duration of a given sender’s term of participation
in the session, but may possibly vary on a per-object basis. The in the session, but may possibly vary on a per-object basis. The
NormSegmentSize is expected to be configurable by the sender NormSegmentSize is expected to be configurable by the sender
application prior to session participation as needed for network application prior to session participation as needed for network
topology maximum transmission unit (MTU) considerations. For IPv6, topology maximum transmission unit (MTU) considerations. For IPv6,
MTU discovery may be possibly leveraged at session startup to perform MTU discovery may be possibly leveraged at session startup to perform
this configuration. The "payload_data" content may be delivered this configuration. The "payload_data" content may be delivered
directly to the application for source symbols (when systematic FEC directly to the application for source symbols (when systematic FEC
encoding is used) or upon decoding of the FEC block. For encoding is used) or upon decoding of the FEC block. For
NORM_OBJECT_FILE and NORM_OBJECT_STREAM objects, the data segment NORM_OBJECT_FILE and NORM_OBJECT_STREAM objects, the data segment
length and offset can be calculated using the block paritioning length and offset can be calculated using the block paritioning
algorithm described in the FEC Building Block document [4]. For algorithm described in the FEC Building Block document [4]. For
NORM_OBJECT_STREAM objects, the length and offset is obtained from NORM_OBJECT_STREAM objects, the length and offset is obtained from
the segment's corresponding "payload_len" and "payload_offset" the segments corresponding "payload_len" and "payload_offset"
fields. fields.
4.2.2. NORM_INFO Message 4.2.2. NORM_INFO Message
The NORM_INFO message is used to convey OPTIONAL, application- The NORM_INFO message is used to convey OPTIONAL, application-
defined, "out-of-band" context information for transmitted defined, "out-of-band" context information for transmitted
NormObjects. An example NORM_INFO use for bulk file transfer is to NormObjects. An example NORM_INFO use for bulk file transfer is to
place MIME type information for the associated file, data, or stream place MIME type information for the associated file, data, or stream
object into the NORM_INFO payload. Receivers may use the NORM_INFO object into the NORM_INFO payload. Receivers may use the NORM_INFO
content to make a decision as whether to participate in reliable content to make a decision as whether to participate in reliable
skipping to change at page 33, line 21 skipping to change at page 33, line 21
| | | outstanding repair requests from | | | | outstanding repair requests from |
| | | receivers). May also be | | | | receivers). May also be |
| | | optionally used to collect | | | | optionally used to collect |
| | | positive acknowledgment of | | | | positive acknowledgment of |
| | | reliable reception from subset | | | | reliable reception from subset |
| | | of receivers. | | | | of receivers. |
+----------------------+--------+----------------------------------+ +----------------------+--------+----------------------------------+
|NORM_CMD(EOT) | 2 | Used to indicate sender | |NORM_CMD(EOT) | 2 | Used to indicate sender |
| | | permanent end-of-transmission. | | | | permanent end-of-transmission. |
+----------------------+--------+----------------------------------+ +----------------------+--------+----------------------------------+
|NORM_CMD(SQUELCH) | 3 | Used to advertise sender's | |NORM_CMD(SQUELCH) | 3 | Used to advertise senders |
| | | current repair window in | | | | current repair window in |
| | | response to out-of-range NACKs | | | | response to out-of-range NACKs |
| | | from receivers. | | | | from receivers. |
+----------------------+--------+----------------------------------+ +----------------------+--------+----------------------------------+
|NORM_CMD(CC) | 4 | Used for GRTT measurement and | |NORM_CMD(CC) | 4 | Used for GRTT measurement and |
| | | collection of congestion control | | | | collection of congestion control |
| | | feedback. | | | | feedback. |
+----------------------+--------+----------------------------------+ +----------------------+--------+----------------------------------+
|NORM_CMD(REPAIR_ADV) | 5 | Used to advertise sender's | |NORM_CMD(REPAIR_ADV) | 5 | Used to advertise senders |
| | | aggregated repair/feedback state | | | | aggregated repair/feedback state |
| | | for suppression of unicast | | | | for suppression of unicast |
| | | feedback from receivers. | | | | feedback from receivers. |
+----------------------+--------+----------------------------------+ +----------------------+--------+----------------------------------+
|NORM_CMD(ACK_REQ) | 6 | Used to request application- | |NORM_CMD(ACK_REQ) | 6 | Used to request application- |
| | | defined positive acknowledgment | | | | defined positive acknowledgment |
| | | from a list of receivers | | | | from a list of receivers |
| | | (OPTIONAL). | | | | (OPTIONAL). |
+----------------------+--------+----------------------------------+ +----------------------+--------+----------------------------------+
|NORM_CMD(APPLICATION) | 7 | Used for application-defined | |NORM_CMD(APPLICATION) | 7 | Used for application-defined |
skipping to change at page 35, line 39 skipping to change at page 35, line 39
fields, the NORM_CMD(FLUSH) message contains fields to identify the fields, the NORM_CMD(FLUSH) message contains fields to identify the
current status and logical transmit position of the sender. current status and logical transmit position of the sender.
The "fec_id" field indicates the FEC type used for the flushing The "fec_id" field indicates the FEC type used for the flushing
"object_transport_id" and implies the size and format of the "object_transport_id" and implies the size and format of the
"fec_payload_id" field. Note the "hdr_len" value for the "fec_payload_id" field. Note the "hdr_len" value for the
NORM_CMD(FLUSH) message is 4 plus the size of the "fec_payload_id" NORM_CMD(FLUSH) message is 4 plus the size of the "fec_payload_id"
field when no header extensions are present. field when no header extensions are present.
The "object_transport_id" and "fec_payload_id" fields indicate the The "object_transport_id" and "fec_payload_id" fields indicate the
sender's current logical "transmit position". These fields are senders current logical "transmit position". These fields are
interpreted in the same manner as in the NORM_DATA message type. interpreted in the same manner as in the NORM_DATA message type.
Upon receipt of the NORM_CMD(FLUSH), receivers are expected to check Upon receipt of the NORM_CMD(FLUSH), receivers are expected to check
their completion state _through_ (including) this transmission their completion state _through_ (including) this transmission
position. If receivers have outstanding repair needs in this range, position. If receivers have outstanding repair needs in this range,
they SHALL initiate the NORM NACK Repair Process as described in they SHALL initiate the NORM NACK Repair Process as described in
Section 5.3. If receivers have no outstanding repair needs, no Section 5.3. If receivers have no outstanding repair needs, no
response to the NORM_CMD(FLUSH) is generated. response to the NORM_CMD(FLUSH) is generated.
For NORM_OBJECT_STREAM objects using systematic FEC codes, receivers For NORM_OBJECT_STREAM objects using systematic FEC codes, receivers
MUST request "explicit-only" repair of the identified MUST request "explicit-only" repair of the identified
skipping to change at page 37, line 34 skipping to change at page 37, line 34
4.2.3.3. NORM_CMD(SQUELCH) Message 4.2.3.3. NORM_CMD(SQUELCH) Message
The NORM_CMD(SQUELCH) command is transmitted in response to outdated The NORM_CMD(SQUELCH) command is transmitted in response to outdated
or invalid NORM_NACK content received by the sender. Invalid or invalid NORM_NACK content received by the sender. Invalid
NORM_NACK content consists of repair requests for NormObjects for NORM_NACK content consists of repair requests for NormObjects for
which the sender is unable or unwilling to provide repair. This which the sender is unable or unwilling to provide repair. This
includes repair requests for outdated objects, aborted objects, or includes repair requests for outdated objects, aborted objects, or
those objects which the sender previously transmitted marked with the those objects which the sender previously transmitted marked with the
NORM_FLAG_UNRELIABLE flag. This command indicates to receivers what NORM_FLAG_UNRELIABLE flag. This command indicates to receivers what
content is available for repair, thus serving as a description of the content is available for repair, thus serving as a description of the
sender's current "repair window". Receivers SHALL not generate senders current "repair window". Receivers SHALL not generate
repair requests for content identified as invalid by a repair requests for content identified as invalid by a
NORM_CMD(SQUELCH). NORM_CMD(SQUELCH).
The NORM_CMD(SQUELCH) command is sent once per 2*GRTT at the most. The NORM_CMD(SQUELCH) command is sent once per 2*GRTT at the most.
The NORM_CMD(SQUELCH) advertises the current "repair window" of the The NORM_CMD(SQUELCH) advertises the current "repair window" of the
sender by identifying the earliest (lowest) transmission point for sender by identifying the earliest (lowest) transmission point for
which it will provide repair, along with an encoded list of objects which it will provide repair, along with an encoded list of objects
from that point forward that are no longer valid for repair. This from that point forward that are no longer valid for repair. This
mechanism allows the sender application to cancel or abort mechanism allows the sender application to cancel or abort
transmission and/or repair of specific previously enqueued objects. transmission and/or repair of specific previously enqueued objects.
The list also contains the identifiers for any objects within the The list also contains the identifiers for any objects within the
repair window that were sent with the NORM_FLAG_UNRELIABLE flag set. repair window that were sent with the NORM_FLAG_UNRELIABLE flag set.
In normal conditions, it is expected the NORM_CMD(SQUELCH) will be In normal conditions, it is expected the NORM_CMD(SQUELCH) will be
needed infrequently, and generally only to provide a reference repair needed infrequently, and generally only to provide a reference repair
window for receivers who have fallen "out-of-sync" with the sender window for receivers who have fallen "out-of-sync" with the sender
due to extremely poor network conditions. due to extremely poor network conditions.
The starting point of the invalid NormObject list begins with the The starting point of the invalid NormObject list begins with the
lowest invalid NormTransportId greater than the current "repair lowest invalid NormTransportId greater than the current "repair
window" start from the invalid NACK(s) that prompted the generation window" start from the invalid NACK(s) that prompted the generation
of the squelch. The length of the list is limited by the sender's of the squelch. The length of the list is limited by the senders
NormSegmentSize. This allows the receivers to learn the status of NormSegmentSize. This allows the receivers to learn the status of
the sender's applicable object repair window with minimal the senders applicable object repair window with minimal
transmission of NORM_CMD(SQUELCH) commands. The format of the transmission of NORM_CMD(SQUELCH) commands. The format of the
NORM_CMD(SQUELCH) message is: NORM_CMD(SQUELCH) message is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence | |version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id | | source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 38, line 36 skipping to change at page 38, line 36
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| invalid_object_list | | invalid_object_list |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD(SQUELCH) Message Format NORM_CMD(SQUELCH) Message Format
In addition to the NORM common message header and standard NORM_CMD In addition to the NORM common message header and standard NORM_CMD
fields, the NORM_CMD(SQUELCH) message contains fields to identify the fields, the NORM_CMD(SQUELCH) message contains fields to identify the
earliest logical transmit position of the sender's current repair earliest logical transmit position of the senders current repair
window and an "invalid object list" beginning with the index of the window and an "invalid object list" beginning with the index of the
logically earliest invalid repair request from the offending NACK logically earliest invalid repair request from the offending NACK
message which initiated the squelch transmission. The value of the message which initiated the squelch transmission. The value of the
"hdr_len" field when no extensions are present is 4 plus the size of "hdr_len" field when no extensions are present is 4 plus the size of
the "fec_payload_id" field that is dependent upon the FEC scheme the "fec_payload_id" field that is dependent upon the FEC scheme
identified by the "fec_id" field. identified by the "fec_id" field.
The "object_transport_id" and "fec_payload_id" fields are The "object_transport_id" and "fec_payload_id" fields are
concatenated to indicate the beginning of the sender's current repair concatenated to indicate the beginning of the senders current repair
window (i.e., the logically earliest point in its transmission window (i.e., the logically earliest point in its transmission
history for which the sender can provide repair). The "fec_id" field history for which the sender can provide repair). The "fec_id" field
implies the size and format of the "fec_payload_id" field. This implies the size and format of the "fec_payload_id" field. This
serves as an advertisement of a "synchronization point" for receivers serves as an advertisement of a "synchronization point" for receivers
to request repair. Note, that while an "encoding_symbol_id" may be to request repair. Note, that while an "encoding_symbol_id" may be
included in the "fec_payload_id" field, the sender's repair window included in the "fec_payload_id" field, the senders repair window
SHOULD be aligned on FEC coding block boundaries and thus the SHOULD be aligned on FEC coding block boundaries and thus the
"encoding_symbol_id" SHOULD be zero. "encoding_symbol_id" SHOULD be zero.
The "invalid_object_list" is a list of 16-bit NormTransportIds that, The "invalid_object_list" is a list of 16-bit NormTransportIds that,
although they are within the range of the sender's current repair although they are within the range of the senders current repair
window, are no longer available for repair from the sender. For window, are no longer available for repair from the sender. For
example, a sender application may dequeue an out-of-date object even example, a sender application may dequeue an out-of-date object even
though it is still within the repair window. The total size of the though it is still within the repair window. The total size of the
"invalid_object_list" content is can be determined from the packet's "invalid_object_list" content is can be determined from the packets
payload length and is limited to a maximum of the NormSegmentSize of payload length and is limited to a maximum of the NormSegmentSize of
the sender. Thus, for very large repair windows, it is possible that the sender. Thus, for very large repair windows, it is possible that
a single NORM_CMD(SQUELCH) message may not be capable of listing the a single NORM_CMD(SQUELCH) message may not be capable of listing the
entire set of invalid objects in the repair window. In this case, entire set of invalid objects in the repair window. In this case,
the sender SHALL ensure that the list begins with a NormObjectId that the sender SHALL ensure that the list begins with a NormObjectId that
is greater than or equal to the lowest ordinal invalid NormObjectId is greater than or equal to the lowest ordinal invalid NormObjectId
from the NACK message(s) that prompted the NORM_CMD(SQUELCH) from the NACK message(s) that prompted the NORM_CMD(SQUELCH)
generation. The NormObjectIds in the "invalid_object_list" MUST be generation. The NormObjectIds in the "invalid_object_list" MUST be
greater than the "object_transport_id" marking the beginning of the greater than the "object_transport_id" marking the beginning of the
sender's repair window. This insures convergence of the squelch senders repair window. This insures convergence of the squelch
process, even if multiple invalid NACK/ squelch iterations are process, even if multiple invalid NACK/ squelch iterations are
required. This explicit description of invalid content within the required. This explicit description of invalid content within the
sender's current window allows the sender application (most notably senders current window allows the sender application (most notably
for discrete "object" based transport) to arbitrarily invalidate for discrete "object" based transport) to arbitrarily invalidate
(i.e., dequeue) portions of enqueued content (e.g., certain objects) (i.e., dequeue) portions of enqueued content (e.g., certain objects)
for which it no longer wishes to provide reliable transport. for which it no longer wishes to provide reliable transport.
4.2.3.4. NORM_CMD(CC) Message 4.2.3.4. NORM_CMD(CC) Message
The NORM_CMD(CC) messages contains fields to enable sender-to- The NORM_CMD(CC) messages contains fields to enable sender-to-
receiver group greatest round-trip time (GRTT) measurement and to receiver group greatest round-trip time (GRTT) measurement and to
excite the group for congestion control feedback. A baseline NORM excite the group for congestion control feedback. A baseline NORM
congestion control scheme (NORM-CC), based on the TCP-Friendly congestion control scheme (NORM-CC), based on the TCP-Friendly
skipping to change at page 41, line 16 skipping to change at page 41, line 16
1970). The byte ordering of the fields is "Big Endian" network 1970). The byte ordering of the fields is "Big Endian" network
order. Receivers use this timestamp adjusted by the amount of delay order. Receivers use this timestamp adjusted by the amount of delay
from the time they received the NORM_CMD(CC) message to the time of from the time they received the NORM_CMD(CC) message to the time of
their response as the "grtt_response" portion of NORM_ACK and their response as the "grtt_response" portion of NORM_ACK and
NORM_NACK messages generated. This allows the sender to evaluate NORM_NACK messages generated. This allows the sender to evaluate
round-trip times to different receivers for congestion control and round-trip times to different receivers for congestion control and
other (e.g., GRTT determination) purposes. other (e.g., GRTT determination) purposes.
To facilitate the baseline NORM-CC scheme described in Section 5.5.2, To facilitate the baseline NORM-CC scheme described in Section 5.5.2,
a NORM-CC Rate header extension (EXT_RATE) is defined to inform the a NORM-CC Rate header extension (EXT_RATE) is defined to inform the
group of the sender's current transmission rate. This is used along group of the senders current transmission rate. This is used along
with the loss detection "sequence" field of all NORM sender messages with the loss detection "sequence" field of all NORM sender messages
and the NORM_CMD(CC) GRTT collection process to support NORM-CC and the NORM_CMD(CC) GRTT collection process to support NORM-CC
congestion control operation. The format of this header extension is congestion control operation. The format of this header extension is
as follows: as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| het = 128 | reserved | send_rate | | het = 128 | reserved | send_rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM-CC Rate Header Extension Format (EXT_RATE) NORM-CC Rate Header Extension Format (EXT_RATE)
The "send_rate" field indicates the sender's current transmission The "send_rate" field indicates the senders current transmission
rate in bytes per second. The 16-bit "send_rate" field consists of rate in bytes per second. The 16-bit "send_rate" field consists of
12 bits of mantissa in the most significant portion and 4 bits of 12 bits of mantissa in the most significant portion and 4 bits of
base 10 integer exponent (E) information in the least significant base 10 integer exponent (E) information in the least significant
portion. The 12-bit mantissa portion of the field is scaled such portion. The 12-bit mantissa portion of the field is scaled such
that a base 10 mantissa (M) floating point value of 0.0 corresponds that a base 10 mantissa (M) floating point value of 0.0 corresponds
to 0 and a value of 10.0 corresponds to 4096 in the upper 12 bits of to 0 and a value of 10.0 corresponds to 4096 in the upper 12 bits of
the 16-bit "send_rate" field . Thus: the 16-bit "send_rate" field . Thus:
send_rate = (((int)(M * 4096.0 / 10.0 + 0.5)) << 4) | E; send_rate = (((int)(M * 4096.0 / 10.0 + 0.5)) << 4) | E;
skipping to change at page 42, line 19 skipping to change at page 42, line 19
scheme is approximately 9.99e+15 bytes per second. scheme is approximately 9.99e+15 bytes per second.
When this extension is present, a "cc_node_list" may be attached as When this extension is present, a "cc_node_list" may be attached as
the payload of the NORM_CMD(CC) message. The presence of this header the payload of the NORM_CMD(CC) message. The presence of this header
extension also implies that NORM receivers should respond according extension also implies that NORM receivers should respond according
to the procedures described in Section 5.5.2. The "cc_node_list" to the procedures described in Section 5.5.2. The "cc_node_list"
consists of a list of NormNodeIds and their associated congestion consists of a list of NormNodeIds and their associated congestion
control status. This includes the current limiting receiver (CLR) control status. This includes the current limiting receiver (CLR)
node, any potential limiting receiver (PLR) nodes that have been node, any potential limiting receiver (PLR) nodes that have been
identified, and some number of receivers for which congestion control identified, and some number of receivers for which congestion control
status is being provided, most notably including the receivers' status is being provided, most notably including the receivers
current RTT measurement. The maximum length of the "cc_node_list" current RTT measurement. The maximum length of the "cc_node_list"
provides for at least the CLR and one other receiver, but may be provides for at least the CLR and one other receiver, but may be
configurable for more timely feedback to the group. The list length configurable for more timely feedback to the group. The list length
can be inferred from the length of the NORM_CMD(CC) message. can be inferred from the length of the NORM_CMD(CC) message.
Each item in the "cc_node_list" is in the following format: Each item in the "cc_node_list" is in the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 43, line 21 skipping to change at page 43, line 21
|NORM_FLAG_CC_PLR | 0x02 | Receiver is a potential limiting | |NORM_FLAG_CC_PLR | 0x02 | Receiver is a potential limiting |
| | | receiver (PLR). | | | | receiver (PLR). |
+-------------------+-------+------------------------------------------+ +-------------------+-------+------------------------------------------+
|NORM_FLAG_CC_RTT | 0x04 | Receiver has measured RTT with respect | |NORM_FLAG_CC_RTT | 0x04 | Receiver has measured RTT with respect |
| | | to sender. | | | | to sender. |
+-------------------+-------+------------------------------------------+ +-------------------+-------+------------------------------------------+
|NORM_FLAG_CC_START | 0x08 | Sender/receiver is in "slow start" phase | |NORM_FLAG_CC_START | 0x08 | Sender/receiver is in "slow start" phase |
| | | of congestion control operation (i.e., | | | | of congestion control operation (i.e., |
| | | The receiver has not yet detected any | | | | The receiver has not yet detected any |
| | | packet loss and the "cc_rate" field is | | | | packet loss and the "cc_rate" field is |
| | | the receiver's actual measured receive | | | | the receivers actual measured receive |
| | | rate). | | | | rate). |
+-------------------+-------+------------------------------------------+ +-------------------+-------+------------------------------------------+
|NORM_FLAG_CC_LEAVE | 0x10 | Receiver is imminently leaving the | |NORM_FLAG_CC_LEAVE | 0x10 | Receiver is imminently leaving the |
| | | session and its feedback should not be | | | | session and its feedback should not be |
| | | considered in congestion control | | | | considered in congestion control |
| | | operation. | | | | 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 NORM Building Block of the RTT using the algorithm described in the NORM Building Block
document [3]. The "cc_rate" field contains a representation of the document [3]. The "cc_rate" field contains a representation of the
receiver's current calculated (during steady-state congestion control receivers current calculated (during steady-state congestion control
operation) or twice its measured (during the "slow start" phase) operation) or twice its measured (during the "slow start" phase)
congestion control rate. This field is encoded and decoded using the congestion control rate. This field is encoded and decoded using the
same technique as described for the NORM_CMD(CC) "send_rate" field. same 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 "advertise" The NORM_CMD(REPAIR_ADV) message is used by the sender to "advertise"
its aggregated repair state from NORM_NACK messages accumulated its aggregated repair state from NORM_NACK messages accumulated
during a repair cycle and/or congestion control feedback received. during a repair cycle and/or congestion control feedback received.
This message is sent only when the sender has received NORM_NACK This message is sent only when the sender has received NORM_NACK
skipping to change at page 45, line 23 skipping to change at page 45, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_rate | cc_reserved | | cc_rate | cc_reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM-CC Feedback Header Extension (EXT_CC) Format NORM-CC Feedback Header Extension (EXT_CC) Format
The "cc_sequence" field contains the current greatest "cc_sequence" The "cc_sequence" field contains the current greatest "cc_sequence"
value receivers have received in NORM_CMD(CC) messages from the value receivers have received in NORM_CMD(CC) messages from the
sender. This information assists the sender in congestion control sender. This information assists the sender in congestion control
operation by providing an indicator of how current ("fresh") the operation by providing an indicator of how current ("fresh") the
receiver's round-trip measurement reference time is and whether the receivers round-trip measurement reference time is and whether the
receiver has been successfully receiving recent congestion control receiver has been successfully receiving recent congestion control
probes. For example, if it is apparent the receiver has not been probes. For example, if it is apparent the receiver has not been
receiving recent congestion control probes (and thus possibly other receiving recent congestion control probes (and thus possibly other
messages from the sender), the sender may choose to take congestion messages from the sender), the sender may choose to take congestion
avoidance measures. For NORM_CMD(REPAIR_ADV) messages, the sender avoidance measures. For NORM_CMD(REPAIR_ADV) messages, the sender
SHALL set the "cc_sequence" field value to the value set in the last SHALL set the "cc_sequence" field value to the value set in the last
NORM_CMD(CC) message sent. NORM_CMD(CC) message sent.
The "cc_flags" field contains bits representing the receiver's state The "cc_flags" field contains bits representing the receivers state
with respect to congestion control operation. The possible values with respect to congestion control operation. The possible values
for the "cc_flags" field are those specified for the NORM_CMD(CC) for the "cc_flags" field are those specified for the NORM_CMD(CC)
message node list item flags. These fields are used by receivers in message node list item flags. These fields are used by receivers in
controlling (suppressing as necessary) their congestion control controlling (suppressing as necessary) their congestion control
feedback. For NORM_CMD(REPAIR_ADV) messages, the NORM_FLAG_CC_RTT feedback. For NORM_CMD(REPAIR_ADV) messages, the NORM_FLAG_CC_RTT
should be set only when all feedback messages received by the sender should be set only when all feedback messages received by the sender
have the flag set. Similarly, the NORM_FLAG_CC_CLR or have the flag set. Similarly, the NORM_FLAG_CC_CLR or
NORM_FLAG_CC_PLR should be set only when no feedback has been NORM_FLAG_CC_PLR should be set only when no feedback has been
received from non-CLR or non-PLR receivers. And the received from non-CLR or non-PLR receivers. And the
NORM_FLAG_CC_LEAVE should be set only when all feedback messages the NORM_FLAG_CC_LEAVE should be set only when all feedback messages the
skipping to change at page 46, line 8 skipping to change at page 46, line 8
The "cc_rtt" field SHALL be set to a default maximum value and the The "cc_rtt" field SHALL be set to a default maximum value and the
NORM_FLAG_CC_RTT flag SHALL be cleared when no receiver has yet NORM_FLAG_CC_RTT flag SHALL be cleared when no receiver has yet
received RTT measurement information. When a receiver has received received RTT measurement information. When a receiver has received
RTT measurement information, it shall set the "cc_rtt" value RTT measurement information, it shall set the "cc_rtt" value
accordingly and set the NORM_FLAG_CC_RTT flag in the "cc_flags" accordingly and set the NORM_FLAG_CC_RTT flag in the "cc_flags"
field. For NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the field. For NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the
"cc_rtt" field value to the largest non-CLR/non-PLR RTT it has "cc_rtt" field value to the largest non-CLR/non-PLR RTT it has
measured from receivers for the current feedback round. measured from receivers for the current feedback round.
The "cc_loss" field represents the receiver's current packet loss The "cc_loss" field represents the receivers current packet loss
fraction estimate for the indicated source. The loss fraction is a fraction estimate for the indicated source. The loss fraction is a
value from 0.0 to 1.0 corresponding to a range of zero to 100 percent value from 0.0 to 1.0 corresponding to a range of zero to 100 percent
packet loss. The 16-bit "cc_loss" value is calculated by the packet loss. The 16-bit "cc_loss" value is calculated by the
following formula: following formula:
"cc_loss" = decimal_loss_fraction * 65535.0 "cc_loss" = decimal_loss_fraction * 65535.0
For NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the "cc_loss" For NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the "cc_loss"
field value to the largest non-CLR/non-PLR loss estimate it has field value to the largest non-CLR/non-PLR loss estimate it has
received from receivers for the current feedback round. received from receivers for the current feedback round.
The "cc_rate" field represents the receivers current local congestion The "cc_rate" field represents the receivers current local congestion
control rate. During "slow start", when the receiver has detected no control rate. During "slow start", when the receiver has detected no
loss, this value is set to twice the actual rate it has measured from loss, this value is set to twice the actual rate it has measured from
the corresponding sender and the NORM_FLAG_CC_START is set in the the corresponding sender and the NORM_FLAG_CC_START is set in the
"cc_flags' field. Otherwise, the receiver calculates a congestion "cc_flags field. Otherwise, the receiver calculates a congestion
control rate based on its loss measurement and RTT measurement control rate based on its loss measurement and RTT measurement
information (even if default) for the "cc_rate" field. For information (even if default) for the "cc_rate" field. For
NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the "cc_loss" NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the "cc_loss"
field value to the lowest non-CLR/non-PLR "cc_rate" report it has field value to the lowest non-CLR/non-PLR "cc_rate" report it has
received from receivers for the current feedback round. received from receivers for the current feedback round.
The "cc_reserved" field is reserved for future NORM protocol use. The "cc_reserved" field is reserved for future NORM protocol use.
Currently, senders SHALL set this field to ZERO, and receivers SHALL Currently, senders SHALL set this field to ZERO, and receivers SHALL
ignore the content of this field. ignore the content of this field.
skipping to change at page 46, line 48 skipping to change at page 46, line 48
exception of the condition when the NORM_REPAIR_ADV_FLAG_LIMIT is exception of the condition when the NORM_REPAIR_ADV_FLAG_LIMIT is
set. set.
4.2.3.6. NORM_CMD(ACK_REQ) Message 4.2.3.6. NORM_CMD(ACK_REQ) Message
The NORM_CMD(ACK_REQ) message is used by the sender to request The NORM_CMD(ACK_REQ) message is used by the sender to request
acknowledgment from a specified list of receivers. This message is acknowledgment from a specified list of receivers. This message is
used in providing a lightweight positive acknowledgment mechanism used in providing a lightweight positive acknowledgment mechanism
that is OPTIONAL for use by the reliable multicast application. A that is OPTIONAL for use by the reliable multicast application. A
range of acknowledgment request types is provided for use at the range of acknowledgment request types is provided for use at the
application's discretion. Provision for application-defined, applications discretion. Provision for application-defined,
positively-acknowledged commands allows the application to positively-acknowledged commands allows the application to
automatically take advantage of transmission and round-trip timing automatically take advantage of transmission and round-trip timing
information available to the NORM protocol. The details of the NORM information available to the NORM protocol. The details of the NORM
positive acknowledgment process including transmission of the positive acknowledgment process including transmission of the
NORM_CMD(ACK_REQ) messages and the receiver response (NORM_ACK) are NORM_CMD(ACK_REQ) messages and the receiver response (NORM_ACK) are
described in Section 5.5.3. The format of the NORM_CMD(ACK_REQ) described in Section 5.5.3. The format of the NORM_CMD(ACK_REQ)
message is: message is:
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
skipping to change at page 48, line 24 skipping to change at page 48, line 24
| | | messages sent in response to | | | | messages sent in response to |
| | | NORM_CMD(CC) messages. | | | | NORM_CMD(CC) messages. |
+---------------------+--------+----------------------------------+ +---------------------+--------+----------------------------------+
|NORM_ACK_FLUSH | 2 | Used to identify NORM_ACK | |NORM_ACK_FLUSH | 2 | Used to identify NORM_ACK |
| | | messages sent in response to | | | | messages sent in response to |
| | | NORM_CMD(FLUSH) messages. | | | | NORM_CMD(FLUSH) messages. |
+---------------------+--------+----------------------------------+ +---------------------+--------+----------------------------------+
|NORM_ACK_RESERVED | 3-15 | Reserved for possible future | |NORM_ACK_RESERVED | 3-15 | Reserved for possible future |
| | | NORM protocol use. | | | | NORM protocol use. |
+---------------------+--------+----------------------------------+ +---------------------+--------+----------------------------------+
|NORM_ACK_APPLICATION | 16-255 | Used at application's | |NORM_ACK_APPLICATION | 16-255 | Used at applications |
| | | discretion. | | | | discretion. |
+---------------------+--------+----------------------------------+ +---------------------+--------+----------------------------------+
The NORM_ACK_CC value is provided for use only in NORM_ACKs generated The NORM_ACK_CC value is provided for use only in NORM_ACKs generated
in response to the NORM_CMD(CC) messages used in congestion control in response to the NORM_CMD(CC) messages used in congestion control
operation. Similarly, the NORM_ACK_FLUSH is provided for use only in operation. Similarly, the NORM_ACK_FLUSH is provided for use only in
NORM_ACKs generated in response to applicable NORM_CMD(FLUSH) NORM_ACKs generated in response to applicable NORM_CMD(FLUSH)
messages. NORM_CMD(ACK_REQ) messages with "ack_type" of NORM_ACK_CC messages. NORM_CMD(ACK_REQ) messages with "ack_type" of NORM_ACK_CC
or NORM_ACK_FLUSH SHALL NOT be generated by the sender. or NORM_ACK_FLUSH SHALL NOT be generated by the sender.
skipping to change at page 49, line 10 skipping to change at page 49, line 10
the response with its corresponding request. the response with its corresponding request.
The "reserved" field is reserved for possible future protocol use and The "reserved" field is reserved for possible future protocol use and
SHALL be set to ZERO by senders and ignored by receivers. SHALL be set to ZERO by senders and ignored by receivers.
The "acking_node_list" field contains the NormNodeIds of the current The "acking_node_list" field contains the NormNodeIds of the current
NORM receivers that are desired to provide positive acknowledge NORM receivers that are desired to provide positive acknowledge
(NORM_ACK) to this request. The packet payload length implies the (NORM_ACK) to this request. The packet payload length implies the
length of the "acking_node_list" and its length is limited to the length of the "acking_node_list" and its length is limited to the
sender NormSegmentSize. The individual NormNodeId items are listed sender NormSegmentSize. The individual NormNodeId items are listed
in network (Big Endian) byte order. If a receiver's NormNodeId is in network (Big Endian) byte order. If a receivers NormNodeId is
included in the "acking_node_list", it SHALL schedule transmission of included in the "acking_node_list", it SHALL schedule transmission of
a NORM_ACK message as described in Section 5.5.3. a NORM_ACK message as described in Section 5.5.3.
4.2.3.7. NORM_CMD(APPLICATION) Message 4.2.3.7. NORM_CMD(APPLICATION) Message
This command allows the NORM application to robustly transmit This command allows the NORM application to robustly transmit
application-defined commands. The command message preempts any application-defined commands. The command message preempts any
ongoing data transmission and is repeated up to NORM_ROBUST_FACTOR ongoing data transmission and is repeated up to NORM_ROBUST_FACTOR
times at a rate of once per 2*GRTT. This rate of repetition allows times at a rate of once per 2*GRTT. This rate of repetition allows
the application to observe any response (if that is the application's the application to observe any response (if that is the applications
purpose for the command) before it is repeated. Possible responses purpose for the command) before it is repeated. Possible responses
may include initiation of data transmission, other may include initiation of data transmission, other
NORM_CMD(APPLICATION) messages, or even application-defined, NORM_CMD(APPLICATION) messages, or even application-defined,
positively-acknowledge commands from other NormSession participants. positively-acknowledge commands from other NormSession participants.
The transmission of these commands will preempt data transmission The transmission of these commands will preempt data transmission
when they are scheduled and may be multiplexed with ongoing data when they are scheduled and may be multiplexed with ongoing data
transmission. This type of robustly transmitted command allows NORM transmission. This type of robustly transmitted command allows NORM
applications to define a complete set of session control mechanisms applications to define a complete set of session control mechanisms
with less state than the transfer of FEC encoded reliable content with less state than the transfer of FEC encoded reliable content
requires while taking advantage of NORM transmission and round-trip requires while taking advantage of NORM transmission and round-trip
skipping to change at page 50, line 7 skipping to change at page 50, line 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD(APPLICATION) Message Format NORM_CMD(APPLICATION) Message Format
The NORM common message header and NORM_CMD fields are interpreted as The NORM common message header and NORM_CMD fields are interpreted as
previously described. The value of the NORM_CMD(APPLICATION) previously described. The value of the NORM_CMD(APPLICATION)
"hdr_len" field when no header extensions are present is 4. "hdr_len" field when no header extensions are present is 4.
The "Application-Defined Content" area contains information in a The "Application-Defined Content" area contains information in a
format at the discretion of the application. The size of this format at the discretion of the application. The size of this
payload SHALL be limited to a maximum of the sender's NormSegmentSize payload SHALL be limited to a maximum of the senders NormSegmentSize
setting. setting.
4.3. Receiver Messages 4.3. Receiver Messages
The NORM message types generated by participating receivers consist The NORM message types generated by participating receivers consist
of NORM_NACK and NORM_ACK message types. NORM_NACK messages are sent of NORM_NACK and NORM_ACK message types. NORM_NACK messages are sent
to request repair of missing data content from sender transmission to request repair of missing data content from sender transmission
and NORM_ACK messages are generated in response to certain sender and NORM_ACK messages are generated in response to certain sender
commands including NORM_CMD(CC) and NORM_CMD(ACK_REQ). commands including NORM_CMD(CC) and NORM_CMD(ACK_REQ).
skipping to change at page 51, line 47 skipping to change at page 51, line 47
by the sender identified by the "server_id" field in its sender by the sender identified by the "server_id" field in its sender
messages. The sender SHOULD ignore feedback messages which contain messages. The sender SHOULD ignore feedback messages which contain
an invalid "instance_id" value. an invalid "instance_id" value.
The "grtt_response" fields contain an adjusted version of the The "grtt_response" fields contain an adjusted version of the
timestamp from the most recently received NORM_CMD(CC) message for timestamp from the most recently received NORM_CMD(CC) message for
the indicated NORM sender. The format of the "grtt_response" is the the indicated NORM sender. The format of the "grtt_response" is the
same as the "send_time" field of the NORM_CMD(CC). The same as the "send_time" field of the NORM_CMD(CC). The
"grtt_response" value is _relative_ to the "send_time" the source "grtt_response" value is _relative_ to the "send_time" the source
provided with a corresponding NORM_CMD(CC) command. The receiver provided with a corresponding NORM_CMD(CC) command. The receiver
adjusts the source's NORM_CMD(CC) "send_time" timestamp by adding the adjusts the sources NORM_CMD(CC) "send_time" timestamp by adding the
time delta from when the receiver received the NORM_CMD(CC) to when time delta from when the receiver received the NORM_CMD(CC) to when
the NORM_NACK is transmitted in response to calculate the value in the NORM_NACK is transmitted in response to calculate the value in
the "grtt_response" field. This is the "receive_to_response_delta" the "grtt_response" field. This is the "receive_to_response_delta"
value used in the following formula: value used in the following formula:
grtt_response = NORM_CMD(CC) send_time + receive_to_response_delta grtt_response = NORM_CMD(CC) send_time + receive_to_response_delta
The receiver SHALL set the "grtt_response" to a ZERO value, to The receiver SHALL set the "grtt_response" to a ZERO value, to
indicate that it has not yet received a NORM_CMD(CC) message from the indicate that it has not yet received a NORM_CMD(CC) message from the
indicated sender and that the sender should ignore the indicated sender and that the sender should ignore the
skipping to change at page 52, line 27 skipping to change at page 52, line 27
defined for alternative congestion control schemes for NORM use in defined for alternative congestion control schemes for NORM use in
the future. the future.
The "reserved" field is for potential future NORM use and SHALL be The "reserved" field is for potential future NORM use and SHALL be
set to ZERO for this version of the protocol. set to ZERO for this version of the protocol.
The "nack_content" of the NORM_NACK message specifies the repair The "nack_content" of the NORM_NACK message specifies the repair
needs of the receiver with respect to the NORM sender indicated by needs of the receiver with respect to the NORM sender indicated by
the "server_id" field. The receiver constructs repair requests based the "server_id" field. The receiver constructs repair requests based
on the NORM_DATA and/or NORM_INFO segments it requires from the on the NORM_DATA and/or NORM_INFO segments it requires from the
sender in order to complete reliable reception up to the sender's sender in order to complete reliable reception up to the senders
transmission position at the moment the receiver initiates the NACK transmission position at the moment the receiver initiates the NACK
Procedure as described in Section 5.3. A single NORM Repair Request Procedure as described in Section 5.3. A single NORM Repair Request
consists of a list of items, ranges, and/or FEC coding block erasure consists of a list of items, ranges, and/or FEC coding block erasure
counts for needed NORM_DATA and/or NORM_INFO content. Multiple counts for needed NORM_DATA and/or NORM_INFO content. Multiple
repair requests may be concatenated within the "nack_payload" field repair requests may be concatenated within the "nack_payload" field
of a NORM_NACK message. Note that a single NORM Repair Request can of a NORM_NACK message. Note that a single NORM Repair Request can
possibly include multiple "items", "ranges", or "erasure_counts". In possibly include multiple "items", "ranges", or "erasure_counts". In
turn, the "nack_payload" field may contain multiple repair requests. turn, the "nack_payload" field may contain multiple repair requests.
A single NORM Repair Request has the following format: A single NORM Repair Request has the following format:
skipping to change at page 53, line 22 skipping to change at page 53, line 22
A "form" value of NORM_NACK_ITEMS indicates each repair request item A "form" value of NORM_NACK_ITEMS indicates each repair request item
in the "repair_request_items" list is to be treated as an individual in the "repair_request_items" list is to be treated as an individual
request. A value of NORM_NACK_RANGES indicates that the request. A value of NORM_NACK_RANGES indicates that the
"repair_request_items" list consists of pairs of repair request items "repair_request_items" list consists of pairs of repair request items
that correspond to inclusive ranges of repair needs. And the that correspond to inclusive ranges of repair needs. And the
NORM_NACK_ERASURES "form" indicates that the repair request items are NORM_NACK_ERASURES "form" indicates that the repair request items are
to be treated individually and that the "encoding_symbol_id" portion to be treated individually and that the "encoding_symbol_id" portion
of the "fec_payload_id" field of the repair request item (see below) of the "fec_payload_id" field of the repair request item (see below)
is to be interpreted as an "erasure count" for the FEC coding block is to be interpreted as an "erasure count" for the FEC coding block
identified by the repair request item's "source_block_number". identified by the repair request items "source_block_number".
The "flags" field is currently used to indicate the level of data The "flags" field is currently used to indicate the level of data
content for which the repair request items apply (i.e., an individual content for which the repair request items apply (i.e., an individual
segment, entire FEC coding block, or entire transport object). segment, entire FEC coding block, or entire transport object).
Possible flag values include: Possible flag values include:
+------------------+-------+------------------------------------------+ +------------------+-------+------------------------------------------+
| Flag | Value | Purpose | | Flag | Value | Purpose |
+------------------+-------+------------------------------------------+ +------------------+-------+------------------------------------------+
|NORM_NACK_SEGMENT | 0x01 | Indicates the listed segment(s) or range | |NORM_NACK_SEGMENT | 0x01 | Indicates the listed segment(s) or range |
skipping to change at page 55, line 5 skipping to change at page 55, line 5
repair is being requested and the "fec_payload_id" identifies the repair is being requested and the "fec_payload_id" identifies the
specific FEC coding block and/or segment being requested. When the specific FEC coding block and/or segment being requested. When the
NORM_NACK_OBJECT flag is set, the value of the "fec_payload_id" field NORM_NACK_OBJECT flag is set, the value of the "fec_payload_id" field
is ignored. When the NORM_NACK_BLOCK flag is set, only the FEC code is ignored. When the NORM_NACK_BLOCK flag is set, only the FEC code
block identifier portion of the "fec_payload_id" is to be block identifier portion of the "fec_payload_id" is to be
interpreted. interpreted.
The format of the "fec_payload_id" field depends upon the "fec_id" The format of the "fec_payload_id" field depends upon the "fec_id"
field value. field value.
When the receiver's repair needs dictate that different forms (mixed When the receivers repair needs dictate that different forms (mixed
ranges and/or individual items) or types (mixed specific segments ranges and/or individual items) or types (mixed specific segments
and/or blocks or objects in entirety) are required to complete and/or blocks or objects in entirety) are required to complete
reliable transmission, multiple NORM Repair Requests with different reliable transmission, multiple NORM Repair Requests with different
"form" and or "flags" values can be concatenated within a single "form" and or "flags" values can be concatenated within a single
NORM_NACK message. Additionally, NORM receivers SHALL construct NORM_NACK message. Additionally, NORM receivers SHALL construct
NORM_NACK messages with their repair requests in ordinal order with NORM_NACK messages with their repair requests in ordinal order with
respect to "object_transport_id" and "fec_payload_id" values. The respect to "object_transport_id" and "fec_payload_id" values. The
"nack_payload" size SHALL NOT exceed the NormSegmentSize for the "nack_payload" size SHALL NOT exceed the NormSegmentSize for the
sender to which the NORM_NACK is destined. sender to which the NORM_NACK is destined.
skipping to change at page 58, line 4 skipping to change at page 58, line 4
benefit from some limited form of positive acknowledgment for certain benefit from some limited form of positive acknowledgment for certain
functions. A simple, scalable positive acknowledgment scheme is functions. A simple, scalable positive acknowledgment scheme is
defined in Section 5.5.3 that can be leveraged by protocol defined in Section 5.5.3 that can be leveraged by protocol
implementations when appropriate. The NORM_CMD(FLUSH) may be used implementations when appropriate. The NORM_CMD(FLUSH) may be used
for OPTIONAL collection of positive acknowledgment of reliable for OPTIONAL collection of positive acknowledgment of reliable
reception to a certain "watermark" transmission point from specific reception to a certain "watermark" transmission point from specific
receivers using this mechanism. The NORM_ACK type NORM_ACK_FLUSH is receivers using this mechanism. The NORM_ACK type NORM_ACK_FLUSH is
provided for this purpose and the format of the "nack_payload" for provided for this purpose and the format of the "nack_payload" for
this acknowledgment type is given below. Beyond that, a range of this acknowledgment type is given below. Beyond that, a range of
application-defined "ack_type" values is provided for use at the NORM application-defined "ack_type" values is provided for use at the NORM
application's discretion. Implementations making use of application- applications discretion. Implementations making use of application-
defined positive acknowledgments may also make use the "nack_payload" defined positive acknowledgments may also make use the "nack_payload"
as needed, observing the constraint that the "nack_payload" field as needed, observing the constraint that the "nack_payload" field
size be limited to a maximum of the NormSegmentSize for the sender to size be limited to a maximum of the NormSegmentSize for the sender to
which the NORM_ACK is destined. which the NORM_ACK is destined.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=5| hdr_len | sequence | |version| type=5| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 60, line 18 skipping to change at page 60, line 18
2) The sender transmits an ordinal set of NormObjects segmented 2) The sender transmits an ordinal set of NormObjects segmented
in the form of NORM_DATA messages labeled with in the form of NORM_DATA messages labeled with
NormTransportIds and logically identified with FEC encoding NormTransportIds and logically identified with FEC encoding
block numbers and symbol identifiers. NORM_INFO messages block numbers and symbol identifiers. NORM_INFO messages
may optionally precede the transmission of data content for may optionally precede the transmission of data content for
NORM transport objects. NORM transport objects.
3) As receivers detect missing content from the sender, they 3) As receivers detect missing content from the sender, they
initiate repair requests with NORM_NACK messages. Note the initiate repair requests with NORM_NACK messages. Note the
receivers track the sender's most recent receivers track the senders most recent
objectId::fecPayloadId transmit position and NACK _only_ for objectId::fecPayloadId transmit position and NACK _only_ for
content ordinally prior to that transmit position. The content ordinally prior to that transmit position. The
receivers schedule random backoff timeouts before generating receivers schedule random backoff timeouts before generating
NORM_NACK messages and wait an appropriate amount of time NORM_NACK messages and wait an appropriate amount of time
before repeating the NORM_NACK if their repair request is before repeating the NORM_NACK if their repair request is
not satisfied. not satisfied.
4) The sender aggregates repair requests from the receivers and 4) The sender aggregates repair requests from the receivers and
logically "rewinds" its transmit position to send logically "rewinds" its transmit position to send
appropriate repair messages. The sender sends repairs for appropriate repair messages. The sender sends repairs for
skipping to change at page 64, line 7 skipping to change at page 64, line 7
receivers to start reliable reception at the current FEC coding block receivers to start reliable reception at the current FEC coding block
for which non-repair content is received. for which non-repair content is received.
For typical operation, it is expected that NORM receivers will join a For typical operation, it is expected that NORM receivers will join a
specified multicast group and/or listen on an specific port number specified multicast group and/or listen on an specific port number
for sender transmissions. As the NORM receiver receives NORM_DATA for sender transmissions. As the NORM receiver receives NORM_DATA
messages it will provide content to its application as appropriate. messages it will provide content to its application as appropriate.
5.3. Receiver NACK Procedure 5.3. Receiver NACK Procedure
When the receiver detects it is missing data from a sender's NORM When the receiver detects it is missing data from a senders NORM
transmissions, it initiates its NACKing procedure. The NACKing transmissions, it initiates its NACKing procedure. The NACKing
procedure SHALL be initiated _only_ at FEC coding block boundaries, procedure SHALL be initiated _only_ at FEC coding block boundaries,
NormObject boundaries, upon receipt of a NORM_CMD(FLUSH) message, or NormObject boundaries, upon receipt of a NORM_CMD(FLUSH) message, or
upon an "inactivity" timeout when NORM_DATA or NORM_INFO upon an "inactivity" timeout when NORM_DATA or NORM_INFO
transmissions are no longer received from a previously active sender. transmissions are no longer received from a previously active sender.
The RECOMMENDED value of such an inactivity timeout is: The RECOMMENDED value of such an inactivity timeout is:
T_inactivity = NORM_ROBUST_FACTOR * 2 * GRTTSender T_inactivity = NORM_ROBUST_FACTOR * 2 * GRTTSender
where the "GRTTsender" value corresponds to the GRTT estimate where the "GRTTsender" value corresponds to the GRTT estimate
advertised in the "grtt" field of NORM sender messages. A minimum advertised in the "grtt" field of NORM sender messages. A minimum
"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 the timeout for up to NORM_ROBUST_FACTOR times or more depending upon the
application's need for persistence by its receivers. It is also applications 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. senders 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 NORM Building Block document [3] using algorithm described in the NORM Building Block document [3] using
(Ksender*GRTTsender) for the "maxTime" parameter and the sender (Ksender*GRTTsender) for the "maxTime" parameter and the sender
advertised group size (GSIZEsender) as the "groupSize" parameter. advertised group size (GSIZEsender) as the "groupSize" parameter.
NORM senders provide values for GRTTsender, Ksender and GSIZEsender NORM senders provide values for GRTTsender, Ksender and GSIZEsender
via the "grtt", "backoff", and "gsize" fields of transmitted via the "grtt", "backoff", and "gsize" fields of transmitted
messages. The GRTTsender value is determined by the sender based on messages. The GRTTsender value is determined by the sender based on
feedback it has received from the group while the Ksender and feedback it has received from the group while the Ksender and
skipping to change at page 65, line 6 skipping to change at page 65, line 6
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 and (Ksender-1)*GRTTsender. Otherwise, the backoff period is entered and
the receiver MUST accumulate external pending repair state from the receiver MUST accumulate external pending repair state from
NORM_NACK messages and NORM_CMD(REPAIR_ADV) messages received. At NORM_NACK messages and NORM_CMD(REPAIR_ADV) messages received. At
the end of the backoff time, the receiver SHALL generate a NORM_NACK the end of the backoff time, the receiver SHALL generate a NORM_NACK
message only if the following conditions are met: message only if the following conditions are met:
1) The sender's current transmit position (in terms of 1) The senders current transmit position (in terms of
objectId::fecPayloadId) exceeds the earliest repair position objectId::fecPayloadId) exceeds the earliest repair position
of the receiver. of the receiver.
2) The repair state accumulated from NORM_NACK and 2) The repair state accumulated from NORM_NACK and
NORM_CMD(REPAIR_ADV) messages do not equal or supersede the NORM_CMD(REPAIR_ADV) messages do not equal or supersede the
receiver's repair needs up to the sender transmission receivers repair needs up to the sender transmission
position at the time the NACK procedure (backoff timeout) position at the time the NACK procedure (backoff timeout)
was initiated. 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 receivers 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 reinitiate the NACKing during which it constrains itself to not reinitiate 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 [3] is: as described in [3] is:
T_rcvrHoldoff =(Ksender+2)*GRTTsender T_rcvrHoldoff =(Ksender+2)*GRTTsender
The NORM_NACK message contains repair request content beginning with The NORM_NACK message contains repair request content beginning with
lowest ordinal repair position of the receiver up through the coding lowest ordinal repair position of the receiver up through the coding
block prior to the most recently heard ordinal transmission position block prior to the most recently heard ordinal transmission position
for the sender. If the size of the NORM_NACK content exceeds the for the sender. If the size of the NORM_NACK content exceeds the
sender's NormSegmentSize, the NACK content is truncated so that the senders NormSegmentSize, the NACK content is truncated so that the
receiver only generates a single NORM_NACK message per NACK cycle for receiver only generates a single NORM_NACK message per NACK cycle for
a given sender. In summary, a single NACK message is generated a given sender. In summary, a single NACK message is generated
containing the receiver's lowest ordinal repair needs. containing the receivers lowest ordinal repair needs.
For each partially-received FEC coding block requiring repair, the For each partially-received FEC coding block requiring repair, the
receiver SHALL, on its _first_ repair attempt for the block, request receiver SHALL, on its _first_ repair attempt for the block, request
the parity portion of the FEC coding block beginning with the lowest the parity portion of the FEC coding block beginning with the lowest
ordinal _parity_ "encoding_symbol_id" (i.e., "encoding_symbol_id" = ordinal _parity_ "encoding_symbol_id" (i.e., "encoding_symbol_id" =
"source_block_len") and request the number of FEC symbols "source_block_len") and request the number of FEC symbols
corresponding to its data segment erasure count for the block. On corresponding to its data segment erasure count for the block. On
_subsequent_ repair cycles for the same coding block, the receiver _subsequent_ repair cycles for the same coding block, the receiver
SHALL request only those repair symbols from the first set it has not SHALL request only those repair symbols from the first set it has not
yet received up to the remaining erasure count for that applicable yet received up to the remaining erasure count for that applicable
coding block. Note that the sender may have provided other coding block. Note that the sender may have provided other
different, additional parity segments for other receivers that could different, additional parity segments for other receivers that could
also be used to satisfy the local receiver's erasure-filling needs. also be used to satisfy the local receivers erasure-filling needs.
In the case where the erasure count for a partially-received FEC In the case where the erasure count for a partially-received FEC
coding block exceeds the maximum number of parity symbols available coding block exceeds the maximum number of parity symbols available
from the sender for the block (as indicated by the NORM_DATA from the sender for the block (as indicated by the NORM_DATA
"fec_num_parity" field), the receiver SHALL request all available "fec_num_parity" field), the receiver SHALL request all available
parity segments plus the ordinally highest missing data segments parity segments plus the ordinally highest missing data segments
required to satisfy its total erasure needs for the block. The goal required to satisfy its total erasure needs for the block. The goal
of this strategy is for the overall receiver set to request a lowest of this strategy is for the overall receiver set to request a lowest
common denominator set of repair symbols for a given FEC coding common denominator set of repair symbols for a given FEC coding
block. This allows the sender to construct the most efficient repair block. This allows the sender to construct the most efficient repair
transmission segment set and enables effective NACK suppression among transmission segment set and enables effective NACK suppression among
skipping to change at page 66, line 49 skipping to change at page 66, line 49
state from NORM_NACK messages before beginning repair transmissions. state from NORM_NACK messages before beginning repair transmissions.
Note that this period of aggregating repair state does _not_ Note that this period of aggregating repair state does _not_
interfere with its ongoing transmission of new data. interfere with its ongoing transmission of new data.
As described in [3], the period of time during which the sender As described in [3], the period of time 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 [3], the value of even if NORM_NACK messages arrive. As described in [3], the value of
this sender "holdoff" period is: this sender "holdoff" 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
messages" into its pending transmission state ONLY if the NACK messages" into its pending transmission state ONLY if the NACK
content is ordinally greater than the sender's current transmission content is ordinally greater than the senders current transmission
position. This "holdoff" time allows worst case time for the sender position. This "holdoff" time allows worst case time for the sender
to propagate its current transmission sequence position to the group, to propagate its current transmission sequence position to the group,
thus avoiding redundant repair transmissions. After the holdoff thus avoiding redundant repair transmissions. After the holdoff
timeout expires, a new NACK accumulation period can be begun (upon timeout expires, a new NACK accumulation period can be begun (upon
arrival of a NACK) in concert with the pending repair and new data arrival of a NACK) in concert with the pending repair and new data
transmission. Recall that receivers are not to initiate the NACK transmission. Recall that receivers are not to initiate the NACK
repair process until the sender's logical transmission position repair process until the senders logical transmission position
exceeds the lowest ordinal position of their repair needs. With the exceeds the lowest ordinal position of their repair needs. With the
new NACK aggregation period, the sender repeats the same process of new NACK aggregation period, the sender repeats the same process of
incorporating accumulated repair state into its transmission plan and incorporating accumulated repair state into its transmission plan and
subsequently "rewinding" to transmit the lowest ordinal repair data subsequently "rewinding" to transmit the lowest ordinal repair data
when the aggregation period expires. Again, this is conducted in when the aggregation period expires. Again, this is conducted in
concert with ongoing new data and/or pending repair transmissions. concert with ongoing new data and/or pending repair transmissions.
5.4.2. Sender FEC Repair Transmission Strategy 5.4.2. Sender FEC Repair Transmission Strategy
The NORM sender should leverage transmission of FEC parity content The NORM sender should leverage transmission of FEC parity content
for repair to the greatest extent possible. Recall that the for repair to the greatest extent possible. Recall that the
receivers use a strategy to request a lowest common denominator of receivers use a strategy to request a lowest common denominator of
explicit repair (including parity content) in the formation of their explicit repair (including parity content) in the formation of their
NORM_NACK messages. Before falling back to explicitly satisfying NORM_NACK messages. Before falling back to explicitly satisfying
different receivers' repair needs, the sender can make use of the different receivers repair needs, the sender can make use of the
general erasure-filling capability of FEC-generated parity segments. general erasure-filling capability of FEC-generated parity segments.
The sender can determine the maximum erasure filling needs for The sender can determine the maximum erasure filling needs for
individual FEC coding blocks from the NORM_NACK messages received individual FEC coding blocks from the NORM_NACK messages received
during the repair aggregation period. Then, if the sender has a during the repair aggregation period. Then, if the sender has a
sufficient number (less than or equal to the maximum erasure count) sufficient number (less than or equal to the maximum erasure count)
of previously unsent parity segments available for the applicable of previously unsent parity segments available for the applicable
coding blocks, the sender can transmit these in lieu of the specific coding blocks, the sender can transmit these in lieu of the specific
packets the receiver set has requested. Only after exhausting its packets the receiver set has requested. Only after exhausting its
supply of "fresh" (unsent) parity segments for a given coding block supply of "fresh" (unsent) parity segments for a given coding block
should the sender resort to explicit transmission of the receiver should the sender resort to explicit transmission of the receiver
set's repair needs. In general, if a sufficiently powerful FEC code sets repair needs. In general, if a sufficiently powerful FEC code
is used, the need for explicit repair will be an exception, and the is used, the need for explicit repair will be an exception, and the
fulfillment of reliable multicast can be accomplished quite fulfillment of reliable multicast can be accomplished quite
efficiently. However, the ability to resort to explicit repair efficiently. However, the ability to resort to explicit repair
allows the protocol to be reliable under even very extreme allows the protocol to be reliable under even very extreme
circumstances. circumstances.
NORM_DATA messages sent as repair transmissions SHALL be flagged with NORM_DATA messages sent as repair transmissions SHALL be flagged with
the NORM_FLAG_REPAIR flag. This allows receivers to obey any the NORM_FLAG_REPAIR flag. This allows receivers to obey any
policies that limit new receivers from joining the reliable policies that limit new receivers from joining the reliable
transmission when only repair transmissions have been received. transmission when only repair transmissions have been received.
Additionally, the sender SHOULD additionally flag NORM_DATA Additionally, the sender SHOULD additionally flag NORM_DATA
transmissions sent as explicit repair with the NORM_FLAG_EXPLICIT transmissions sent as explicit repair with the NORM_FLAG_EXPLICIT
flag. flag.
Although NORM end system receivers do not make use of the Although NORM end system receivers do not make use of the
NORM_FLAG_EXPLICIT flag, this message transmission status could be NORM_FLAG_EXPLICIT flag, this message transmission status could be
leveraged by intermediate systems wishing to "assist" NORM protocol leveraged by intermediate systems wishing to "assist" NORM protocol
performance. If such systems are properly positioned with respect to performance. If such systems are properly positioned with respect to
reciprocal reverse-path multicast routing, they need to sub-cast only reciprocal reverse-path multicast routing, they need to sub-cast only
a sufficient count of non-explicit parity repairs to satisfy a a sufficient count of non-explicit parity repairs to satisfy a
multicast routing sub-tree's erasure filling needs for a given FEC multicast routing sub-trees erasure filling needs for a given FEC
coding block. When the sender has resorted to explicit repair, then coding block. When the sender has resorted to explicit repair, then
the intermediate systems should sub-cast all of the explicit repair the intermediate systems should sub-cast all of the explicit repair
packets to those portions of the routing tree still requiring repair packets to those portions of the routing tree still requiring repair
for a given coding block. Note the intermediate systems will be for a given coding block. Note the intermediate systems will be
required to conduct repair state accumulation for sub-routes in a required to conduct repair state accumulation for sub-routes in a
manner similar to the sender's repair state accumulation in order to manner similar to the senders repair state accumulation in order to
have sufficient information to perform the sub-casting. have sufficient information to perform the sub-casting.
Additionally, the intermediate systems could perform additional Additionally, the intermediate systems could perform additional
NORM_NACK suppression/aggregation as it conducts this repair state NORM_NACK suppression/aggregation as it conducts this repair state
accumulation for NORM repair cycles. The detail of this type of accumulation for NORM repair cycles. The detail of this type of
operation are beyond the scope of this document, but this information operation are beyond the scope of this document, but this information
is provided for possible future consideration. is provided for possible future consideration.
5.4.3. Sender NORM_CMD(SQUELCH) Generation 5.4.3. Sender NORM_CMD(SQUELCH) Generation
If the sender receives a NORM_NACK message for repair of data it is If the sender receives a NORM_NACK message for repair of data it is
no longer supporting, the sender generates a NORM_CMD(SQUELCH) no longer supporting, the sender generates a NORM_CMD(SQUELCH)
message to advertise its repair window and squelch any receivers from message to advertise its repair window and squelch any receivers from
additional NACKing of invalid data. The transmission rate of additional NACKing of invalid data. The transmission rate of
NORM_CMD(SQUELCH) messages is limited to once per 2*GRTT. The NORM_CMD(SQUELCH) messages is limited to once per 2*GRTT. The
"invalid_object_list" (if applicable) of the NORM_CMD(SQUELCH) "invalid_object_list" (if applicable) of the NORM_CMD(SQUELCH)
message SHALL begin with the lowest "object_transport_id" from the message SHALL begin with the lowest "object_transport_id" from the
invalid NORM_NACK messages received since the last NORM_CMD(SQUELCH) invalid NORM_NACK messages received since the last NORM_CMD(SQUELCH)
transmission. Lower ordinal invalid "object_transport_ids" should be transmission. Lower ordinal invalid "object_transport_ids" should be
included only while the NORM_CMD(SQUELCH) payload is less than the included only while the NORM_CMD(SQUELCH) payload is less than the
sender's NormSegmentSize parameter. senders NormSegmentSize parameter.
5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation 5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation
When a NORM sender receives NORM_NACK messages from receivers via When a NORM sender receives NORM_NACK messages from receivers via
unicast transmission, it uses NORM_CMD(REPAIR_ADV) messages to unicast transmission, it uses NORM_CMD(REPAIR_ADV) messages to
advertise its accumulated repair state to the receiver set since the advertise its accumulated repair state to the receiver set since the
receiver set is not directly sharing their repair needs via multicast receiver set is not directly sharing their repair needs via multicast
communication. A NORM sender implementation MAY use a separate port communication. A NORM sender implementation MAY use a separate port
number from the NormSession port number as the source port for its number from the NormSession port number as the source port for its
transmissions. Thus NORM receivers can direct any _unicast_ feedback transmissions. Thus NORM receivers can direct any _unicast_ feedback
skipping to change at page 70, line 30 skipping to change at page 70, line 30
time the receiver held the timestamp before generating its response. time the receiver held the timestamp before generating its response.
Upon receipt of this adjusted timestamp, the sender is able to Upon receipt of this adjusted timestamp, the sender is able to
calculate the round-trip time to that receiver. 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 NORM GRTT. The algorithm and methodology are described in the NORM
Building Block document [3] in the section entitled "One-to-Many Building Block document [3] in the section entitled "One-to-Many
Sender GRTT Measurement". A conservative estimate helps feedback Sender GRTT Measurement". A conservative estimate helps feedback
suppression at a small cost in overall protocol repair delay. The suppression at a small cost in overall protocol repair delay. The
sender's current estimate of GRTT is advertised in the "grtt" field senders current estimate of GRTT is advertised in the "grtt" field
found in all NORM sender messages. The advertised GRTT is also found in all NORM sender messages. The advertised GRTT is also
limited to a minimum of the nominal inter-packet transmission time limited to a minimum of the nominal inter-packet transmission time
given the sender's current transmission rate and system clock given the senders current transmission rate and system clock
granularity. The reason for this additional limit is to keep the granularity. The reason for this additional limit is to keep the
receiver somewhat "event driven" by making sure the sender has had receiver somewhat "event driven" by making sure the sender has had
adequate time to generate any response to repair requests from adequate time to generate any response to repair requests from
receivers given transmit rate limitations due to congestion control receivers given transmit rate limitations due 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 described messages, the receivers respond to NORM_CMD(CC) messages as described
in Section 5.5.2, "NORM Congestion Control Operation". The 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
skipping to change at page 72, line 24 skipping to change at page 72, line 24
p = The loss event fraction of the CLR. p = The loss event fraction of the CLR.
To support congestion control feedback collection and operation, the To support congestion control feedback collection and operation, the
NORM sender periodically transmits NORM_CMD(CC) command messages. NORM sender periodically transmits NORM_CMD(CC) command messages.
NORM_CMD(CC) messages are multiplexed with NORM data and repair NORM_CMD(CC) messages are multiplexed with NORM data and repair
transmissions and serve several purposes: transmissions and serve several purposes:
1) Stimulate explicit feedback from the general receiver set to 1) Stimulate explicit feedback from the general receiver set to
collect congestion control information. collect congestion control information.
2) Communicate state to the receiver set on the sender's 2) Communicate state to the receiver set on the senders
current congestion control status including details of the current congestion control status including details of the
CLR. CLR.
3) Initiate rapid (immediate) feedback from the CLR in order to 3) Initiate rapid (immediate) feedback from the CLR in order to
closely track the dynamics of congestion control for that closely track the dynamics of congestion control for that
current "worst path" in the group multicast topology. current "worst path" in the group multicast topology.
The format of the NORM_CMD(CC) message is describe in Section 4.2.3 The format of the NORM_CMD(CC) message is describe in Section 4.2.3
of this document. The NORM_CMD(CC) message contains information to of this document. The NORM_CMD(CC) message contains information to
allow measurement of RTTs, to inform the group of the congestion allow measurement of RTTs, to inform the group of the congestion
skipping to change at page 74, line 25 skipping to change at page 74, line 25
entry be the first in the list for implementation efficiency. entry be the first in the list for implementation efficiency.
Additional entries in the list are used to provide sender-measured Additional entries in the list are used to provide sender-measured
individual RTT estimates to receivers in the group. The number of individual RTT estimates to receivers in the group. The number of
additional entries in this list is dependent upon the percentage of additional entries in this list is dependent upon the percentage of
control traffic the sender application is willing to send with control traffic the sender application is willing to send with
respect to user data message transmissions. More entries in the list respect to user data message transmissions. More entries in the list
may allow the sender to be more responsive to congestion control may allow the sender to be more responsive to congestion control
dynamics. The length of the list may be dynamically determined dynamics. The length of the list may be dynamically determined
according to the current transmission rate and scheduling of according to the current transmission rate and scheduling of
NORM_CMD(CC) messages. The maximum length of the list corresponds to NORM_CMD(CC) messages. The maximum length of the list corresponds to
the sender's NormSegmentSize parameter for the session. The the senders NormSegmentSize parameter for the session. The
inclusion of additional entries in the list based on receiver inclusion of additional entries in the list based on receiver
feedback are prioritized with following rules: feedback are prioritized with following rules:
1) Receivers that have not yet been provided a RTT measurement 1) Receivers that have not yet been provided a RTT measurement
get first priority. Of these, those with the greatest loss get first priority. Of these, those with the greatest loss
fraction receive precedence for list inclusion. fraction receive precedence for list inclusion.
2) Secondly, receivers that have previously been provided a RTT 2) Secondly, receivers that have previously been provided a RTT
measurement are included with receivers yielding the lowest measurement are included with receivers yielding the lowest
calculated congestion rate getting precedence. calculated congestion rate getting precedence.
skipping to change at page 76, line 11 skipping to change at page 76, line 11
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 congestion control feedback timeout expires (this is similar
to the TFMCC feedback round number), to 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 4) "Suppressing" congestion control feedback is heard from
another receiver (in a NORM_ACK or NORM_NACK) or via a another 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 receivers feedback is "suppressed" if the rate of the
competing feedback (Rfb) is sufficiently close to or less competing feedback (Rfb) is sufficiently close to or less
than the local receiver's calculated rate (Rcalc). The than the local receiver’s calculated rate (Rcalc). The
local receiver's feedback is canceled when: local receiver’s feedback is canceled when:
Rcalc > (0.9 * Rfb) Rcalc > (0.9 * Rfb)
Also note receivers that have not yet received an RTT Also note receivers that have not yet received an RTT
measurement from the sender are suppressed only by other measurement from the sender are suppressed only by other
receivers that have not yet measured RTT. Additionally, receivers that have not yet measured RTT. Additionally,
receivers whose RTT estimate has "aged" considerably (i.e., receivers whose RTT estimate has "aged" considerably (i.e.,
they haven't been included in the NORM_CMD(CC) they havent been included in the NORM_CMD(CC)
"cc_node_list" in a long time) may wish to compete as a "cc_node_list" in a long time) may wish to compete as a
receiver with no prior RTT measurement after some long term receiver with no prior RTT measurement after some long term
expiration period. expiration period.
When the backoff timer expires, the receiver SHALL generate a When the backoff timer expires, the receiver SHALL generate a
NORM_ACK(RTT) message to provide feedback to the sender and group. NORM_ACK(RTT) message to provide feedback to the sender and group.
This message may be multicast to the group for most effective This message may be multicast to the group for most effective
suppression in ASM topologies or unicast to the sender depending upon suppression in ASM topologies or unicast to the sender depending upon
how the NORM protocol is deployed and configured. how the NORM protocol is deployed and configured.
skipping to change at page 77, line 5 skipping to change at page 77, line 5
via this header extension. via this header extension.
During slow start (when the receiver has not yet detected loss from During slow start (when the receiver has not yet detected loss from
the sender), the receiver uses a value equal to two times its the sender), the receiver uses a value equal to two times its
measured rate from the sender in the "cc_rate" field. For steady- measured rate from the sender in the "cc_rate" field. For steady-
state congestion control operation, the receiver "cc_rate" value is state congestion control operation, the receiver "cc_rate" value is
from the equation-based value using its current loss event estimate from the equation-based value using its current loss event estimate
and sender<->receiver RTT information. (The GRTT is used when the and sender<->receiver RTT information. (The GRTT is used when the
receiver has not yet measured its individual RTT). receiver has not yet measured its individual RTT).
The "cc_loss" field value reflects the receiver's current loss event The "cc_loss" field value reflects the receivers current loss event
estimate with respect to the sender in question. estimate with respect to the sender in question.
When the receiver has a valid individual RTT measurement, it SHALL When the receiver has a valid individual RTT measurement, it SHALL
include this value in the "cc_rtt" field. The NORM_FLAG_CC_RTT MUST include this value in the "cc_rtt" field. The NORM_FLAG_CC_RTT MUST
be set when the "cc_rtt" field is valid. be set when the "cc_rtt" field is valid.
After a congestion control feedback message is generated or when the After a congestion control feedback message is generated or when the
feedback is suppressed, a non-CLR receiver begins a "holdoff" timeout feedback is suppressed, a non-CLR receiver begins a "holdoff" timeout
period during which it will restrain itself from providing congestion period during which it will restrain itself from providing congestion
control feedback, even if NORM_CMD(CC) messages are received from the control feedback, even if NORM_CMD(CC) messages are received from the
skipping to change at page 77, line 48 skipping to change at page 77, line 48
The sender processes congestion control feedback from the receivers The sender processes congestion control feedback from the receivers
and selects the CLR based on the lowest rate receiver. Receiver and selects the CLR based on the lowest rate receiver. Receiver
rates are either determined directly from the slow start "cc_rate" rates are either determined directly from the slow start "cc_rate"
provided by the receiver in the NORM-CC Feedback header extension or provided by the receiver in the NORM-CC Feedback header extension or
by performing the equation-based calculation using individual RTT and by performing the equation-based calculation using individual RTT and
loss estimates ("cc_loss") as feedback is received. loss estimates ("cc_loss") as feedback is received.
The sender can calculate a current RTT for a receiver (RTT_rcvrNew) The sender can calculate a current RTT for a receiver (RTT_rcvrNew)
using the "grtt_response" timestamp included in feedback messages. using the "grtt_response" timestamp included in feedback messages.
When the "cc_rtt" value in a response is not valid, the sender simply When the "cc_rtt" value in a response is not valid, the sender simply
uses this RTT_rcvrNew value as the receiver's current RTT (RTT_rcvr). uses this RTT_rcvrNew value as the receivers current RTT (RTT_rcvr).
For non-CLR and non-PLR receivers, the sender can use the "cc_rtt" For non-CLR and non-PLR receivers, the sender can use the "cc_rtt"
value provided in the NORM-CC Feedback header extension as the value provided in the NORM-CC Feedback header extension as the
receiver's previous RTT measurement (RTT_rcvrPrev) to smooth receivers previous RTT measurement (RTT_rcvrPrev) to smooth
according to: according to:
RTT_rcvr = 0.5 * RTT_rcvrPrev + 0.5 * RTT_rcvrNew RTT_rcvr = 0.5 * RTT_rcvrPrev + 0.5 * RTT_rcvrNew
For CLR receivers where feedback is received more regularly, the For CLR receivers where feedback is received more regularly, the
sender SHOULD maintain a more smoothed RTT estimate upon new feedback sender SHOULD maintain a more smoothed RTT estimate upon new feedback
from the CLR where: from the CLR where:
RTT_clr = 0.9 * RTT_clr + 0.1 * RTT_clrNew RTT_clr = 0.9 * RTT_clr + 0.1 * RTT_clrNew
skipping to change at page 80, line 15 skipping to change at page 80, line 15
5.5.3. NORM Positive Acknowledgment Procedure 5.5.3. NORM Positive Acknowledgment Procedure
NORM provides options for the source application to request positive NORM provides options for the source application to request positive
acknowledgment (ACK) of NORM_CMD(FLUSH) and NORM_CMD(ACK_REQ) acknowledgment (ACK) of NORM_CMD(FLUSH) and NORM_CMD(ACK_REQ)
messages from members of the group. There are some specific messages from members of the group. There are some specific
acknowledgment requests defined for the NORM protocol and a range of acknowledgment requests defined for the NORM protocol and a range of
acknowledgment request types that are left to be defined by the acknowledgment request types that are left to be defined by the
application. One predefined acknowledgment type is the application. One predefined acknowledgment type is the
NORM_ACK_FLUSH type. This acknowledgment is used to determine if NORM_ACK_FLUSH type. This acknowledgment is used to determine if
receivers have achieved completion of reliable reception up through a receivers have achieved completion of reliable reception up through a
specific logical transmission point with respect to the sender's specific logical transmission point with respect to the senders
sequence of transmission. The NORM_ACK_FLUSH acknowledgment may be sequence of transmission. The NORM_ACK_FLUSH acknowledgment may be
used to assist in application flow control when the sender has used to assist in application flow control when the sender has
information on a portion of the receiver set. Another predefined information on a portion of the receiver set. Another predefined
acknowledgment type is NORM_ACK(CC), which is used to explicitly acknowledgment type is NORM_ACK(CC), which is used to explicitly
provide congestion control feedback in response to NORM_CMD(CC) provide congestion control feedback in response to NORM_CMD(CC)
messages transmitted by the sender for NORM-CC operation. Note the messages transmitted by the sender for NORM-CC operation. Note the
NORM_ACK(CC) response does NOT follow the positive acknowledgment NORM_ACK(CC) response does NOT follow the positive acknowledgment
procedure described here. The NORM_CMD(ACK_REQ) and NORM_ACK procedure described here. The NORM_CMD(ACK_REQ) and NORM_ACK
messages contain an "ack_type" field to identify the type of messages contain an "ack_type" field to identify the type of
acknowledgment requested and provided. A range of "ack_type" values acknowledgment requested and provided. A range of "ack_type" values
skipping to change at page 81, line 22 skipping to change at page 81, line 22
The ACK process is self-limiting and avoids ACK implosion in that: The ACK process is self-limiting and avoids ACK implosion in that:
1) Only a single NORM_CMD(ACK_REQ) message is generated once per 1) Only a single NORM_CMD(ACK_REQ) message is generated once per
(2*GRTT), and, (2*GRTT), and,
2) The size of the "acking_node_list" of NormNodeIds from which 2) The size of the "acking_node_list" of NormNodeIds from which
acknowledgment is requested is limited to a maximum of the acknowledgment is requested is limited to a maximum of the
sender NormSegmentSize setting per round of the positive sender NormSegmentSize setting per round of the positive
acknowledgment process. acknowledgment process.
Because the size of the included list is limited to the sender's Because the size of the included list is limited to the senders
NormSegmentSize setting, multiple NORM_CMD(ACK_REQ) rounds may be NormSegmentSize setting, multiple NORM_CMD(ACK_REQ) rounds may be
required to achieve responses from all receivers specified. The required to achieve responses from all receivers specified. The
content of the attached NormNodeId list will be dynamically updated content of the attached NormNodeId list will be dynamically updated
as this process progresses and NORM_ACK responses are received from as this process progresses and NORM_ACK responses are received from
the specified receiver set. As the sender receives valid responses the specified receiver set. As the sender receives valid responses
(i.e., matching watermark point or "ack_id") from receivers, it SHALL (i.e., matching watermark point or "ack_id") from receivers, it SHALL
eliminate those receivers from the subsequent NORM_CMD(ACK_REQ) eliminate those receivers from the subsequent NORM_CMD(ACK_REQ)
message "acking_node_list" and add in any pending receiver message "acking_node_list" and add in any pending receiver
NormNodeIds while keeping within the NormSegmentSize limitation of NormNodeIds while keeping within the NormSegmentSize limitation of
the list size. Each receiver is queried a maximum number of times the list size. Each receiver is queried a maximum number of times
skipping to change at page 85, line 10 skipping to change at page 85, line 10
properly process the IPSec-secured packets from the sender. The NORM properly process the IPSec-secured packets from the sender. The NORM
receiver(s) SHALL also use a common, second IPSec SA (common Security receiver(s) SHALL also use a common, second IPSec SA (common Security
Parameter Index (SPI) and encryption key) configured for ESP Parameter Index (SPI) and encryption key) configured for ESP
operation with the option for data origination authentication operation with the option for data origination authentication
enabled. Similar to the NORM sender, is is RECOMMENDED this IPSec enabled. Similar to the NORM sender, is is RECOMMENDED this IPSec
ESP SA be also configured to provide confidentiality protection for ESP SA be also configured to provide confidentiality protection for
IP packets containing NORM protocol messages. The receivers MUST IP packets containing NORM protocol messages. The receivers MUST
have an IPSec SPD entry configured to process outbound NORM/UDP have an IPSec SPD entry configured to process outbound NORM/UDP
packets directed to the NORM sender source address and port number packets directed to the NORM sender source address and port number
using this second SA. As noted for NORM unicast feedback, the using this second SA. As noted for NORM unicast feedback, the
sender's transmission port number SHOULD be distinct from the senders transmission port number SHOULD be distinct from the
multicast session port number to allow discrimination between unicast multicast session port number to allow discrimination between unicast
and multicast feedback messages when access to the IP destination and multicast feedback messages when access to the IP destination
address is not possible (e.g., a user-space NORM implementation). address is not possible (e.g., a user-space NORM implementation).
For processing of packets from receivers, the NORM sender SHALL be For processing of packets from receivers, the NORM sender SHALL be
configured with this common, second SA (and the corresponding SPD configured with this common, second SA (and the corresponding SPD
entry needed) in order to properly process messages from the entry needed) in order to properly process messages from the
receiver. Note that built-in IPSec replay attack protection for this receiver. Note that built-in IPSec replay attack protection for this
second SA at the sender MUST be disabled. second SA at the sender MUST be disabled.
Multiple receivers using a common IPSec SA for traffic directed to Multiple receivers using a common IPSec SA for traffic directed to
skipping to change at page 85, line 36 skipping to change at page 85, line 36
receivers. This can be accomplished with high assurance of security, receivers. This can be accomplished with high assurance of security,
even with the limited size (16-bits) of this field, because even with the limited size (16-bits) of this field, because
1) NORM receiver NACK and non-CLR ACK feedback messages are 1) NORM receiver NACK and non-CLR ACK feedback messages are
sparse. sparse.
2) The more frequent NORM ACK feedback from CLR or PLR nodes 2) The more frequent NORM ACK feedback from CLR or PLR nodes
are only a small set of receivers for which the sender must are only a small set of receivers for which the sender must
keep more persistent replay attack state. keep more persistent replay attack state.
3) NORM NACK feedback messages that precede the sender's 3) NORM NACK feedback messages that precede the senders
current repair window do not significantly impact protocol current repair window do not significantly impact protocol
operation (generation of NORM_CMD(SQUELCH) is limited) and operation (generation of NORM_CMD(SQUELCH) is limited) and
could be in fact ignored. This means the sender can prune could be in fact ignored. This means the sender can prune
any replay attack state for receivers that precede the any replay attack state for receivers that precede the
current repair window. current repair window.
4) NORM ACK messages correspond to either a specific sender 4) NORM ACK messages correspond to either a specific sender
"ack_id", the sender "cc_sequence" for ACKs sent in response "ack_id", the sender "cc_sequence" for ACKs sent in response
to NORM_CMD(CC), or the sender's current repair window in to NORM_CMD(CC), or the senders current repair window in
the case of ACKs sent in response to NORM_CMD(FLUSH). Thus, the case of ACKs sent in response to NORM_CMD(FLUSH). Thus,
the sender can prune any replay attack state for receivers the sender can prune any replay attack state for receivers
that precede the current applicable sequence or repair that precede the current applicable sequence or repair
window space. window space.
Note that use of ESP confidentiality, as RECOMMENDED, for secure NORM Note that use of ESP confidentiality, as RECOMMENDED, for secure NORM
protocol operation makes it more difficult for adversaries to conduct protocol operation makes it more difficult for adversaries to conduct
effective replay attacks. Additionally, it should be noted that a effective replay attacks. Additionally, it should be noted that a
NORM sender implementation with access to the full ESP protocol NORM sender implementation with access to the full ESP protocol
header could also use the ESP sequence information to make this form header could also use the ESP sequence information to make this form
skipping to change at page 89, line 25 skipping to change at page 89, line 25
weather satellite compressed imagery updates servicing a large group weather satellite compressed imagery updates servicing a large group
of receivers and a generic web content reliable "push" application. of receivers and a generic web content reliable "push" application.
In addition, this framework approach has some design features making In addition, this framework approach has some design features making
it attractive for bulk transfer in asymmetric and wireless it attractive for bulk transfer in asymmetric and wireless
internetwork applications. NORM is capable of successfully operating internetwork applications. NORM is capable of successfully operating
independent of network structure and in environments with high packet independent of network structure and in environments with high packet
loss, delay, and misordering. Hybrid proactive/reactive FEC-based loss, delay, and misordering. Hybrid proactive/reactive FEC-based
repairing improve protocol performance in some multicast scenarios. repairing improve protocol performance in some multicast scenarios.
A sender-only repair approach often makes additional engineering A sender-only repair approach often makes additional engineering
sense in asymmetric networks. NORM's unicast feedback capability may sense in asymmetric networks. NORMs unicast feedback capability may
be suitable for use in asymmetric networks or in networks where only be suitable for use in asymmetric networks or in networks where only
unidirectional multicast routing/delivery service exists. Asymmetric unidirectional multicast routing/delivery service exists. Asymmetric
architectures supporting multicast delivery are likely to make up an architectures supporting multicast delivery are likely to make up an
important portion of the future Internet structure (e.g., important portion of the future Internet structure (e.g.,
DBS/cable/PSTN hybrids) and efficient, reliable bulk data transfer DBS/cable/PSTN hybrids) and efficient, reliable bulk data transfer
will be an important capability for servicing large groups of will be an important capability for servicing large groups of
subscribed receivers. subscribed receivers.
9. Changes from RFC3940 9. Changes from RFC3940
skipping to change at page 90, line 36 skipping to change at page 90, line 36
11.1. Normative References 11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC [2] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
1112, August 1989. 1112, August 1989.
[3] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Multicast [3] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Multicast
Negative-Acknowledgement (NACK) Building Blocks", draft-ietf-rmt-bb- Negative-Acknowledgement (NACK) Building Blocks", draft-ietf-rmt-bb-
norm-revised-03, July 2007. norm-revised-04, July 2007.
[4] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction [4] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction
(FEC) Building Block", draft-ietf-rmt-fec-bb-revised-07, April 2007. (FEC) Building Block", RFC 5052, August 2007.
[5] J. Widmer and M. Handley, "TCP-Friendly Multicast Congestion [5] J. Widmer and M. Handley, "TCP-Friendly Multicast Congestion
Control (TFMCC) Protocol Specification", RFC 4654, August 2006. Control (TFMCC) Protocol Specification", RFC 4654, August 2006.
[6] S. Kent and K. Seo, "Security Architecture for the Internet [6] S. Kent and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005. Protocol", RFC 4301, December 2005.
[7] S. Kent, "IP Encapsulating Security Payload (ESP)", RFC 4303, [7] S. Kent, "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005. December 2005.
skipping to change at page 91, line 46 skipping to change at page 91, line 46
[17] J. Macker, B. Adamson, "Quantitative Prediction of Nack Oriented [17] J. Macker, B. Adamson, "Quantitative Prediction of Nack Oriented
Reliable Multicast (NORM) Feedback", Proc. IEEE MILCOM 2002, October Reliable Multicast (NORM) Feedback", Proc. IEEE MILCOM 2002, October
2002. 2002.
[18] H.W. Holbrook, "A Channel Model for Multicast", Ph.D. [18] H.W. Holbrook, "A Channel Model for Multicast", Ph.D.
Dissertation, Stanford University, Department of Computer Science, Dissertation, Stanford University, Department of Computer Science,
Stanford, California, August 2001. Stanford, California, August 2001.
[19] D. Gossink, J. Macker, "Reliable Multicast and Integrated Parity [19] D. Gossink, J. Macker, "Reliable Multicast and Integrated Parity
Retransmission with Channel Estimation", IEEE GLOBECOMM 98', Retransmission with Channel Estimation", IEEE GLOBECOMM 98,
September 1998. September 1998.
[20] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., [20] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S.,
and M. Luby, "Reliable Multicast Transport Building Blocks for One- and M. Luby, "Reliable Multicast Transport Building Blocks for One-
to-Many Bulk-Data Transfer", RFC 3048, January 2001. to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[21] Mankin, A., Romanow, A., Bradner, S., and V. Paxson, "IETF [21] Mankin, A., Romanow, A., Bradner, S., and V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and Application Criteria for Evaluating Reliable Multicast Transport and Application
Protocols", RFC 2357, June 1998. Protocols", RFC 2357, June 1998.
skipping to change at page 92, line 26 skipping to change at page 92, line 26
[23] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [23] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real Time Transport Protocol", RFC 3711, March Norrman, "The Secure Real Time Transport Protocol", RFC 3711, March
2004. 2004.
[24] J. Widmer and M. Handley, "Extending Equation-Based Congestion [24] J. Widmer and M. Handley, "Extending Equation-Based Congestion
Control to Multicast Applications", Proc ACM SIGCOMM 2001, San Diego, Control to Multicast Applications", Proc ACM SIGCOMM 2001, San Diego,
August 2001. August 2001.
[25] Watson, M., "Basic Forward Error Correction (FEC) Schemes", [25] Watson, M., "Basic Forward Error Correction (FEC) Schemes",
Internet-Draft draft-ietf-rmt-bb-fec-basic-schemes-revised-03, Internet-Draft draft-ietf-rmt-bb-fec-basic-schemes-revised-04,
February 2007. November 2007.
[26] L. Rizzo, "pgmcc: A TCP-Friendly Single-Rate Multicast [26] L. Rizzo, "pgmcc: A TCP-Friendly Single-Rate Multicast
Congestion Control Scheme", Proc ACM SIGCOMM 2000, Stockholm, August Congestion Control Scheme", Proc ACM SIGCOMM 2000, Stockholm, August
2000. 2000.
[27] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose, "Modeling TCP [27] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose, "Modeling TCP
Throughput: A Simple Model and its Empirical Validation", Proc ACM Throughput: A Simple Model and its Empirical Validation", Proc ACM
SIGCOMM 1998. SIGCOMM 1998.
[28] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group [28] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group
skipping to change at page 93, line 5 skipping to change at page 93, line 5
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[30] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: [30] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP:
Group Secure Association Key Management Protocol", RFC 4535, June Group Secure Association Key Management Protocol", RFC 4535, June
2006. 2006.
[31] Adamson, B. and J. Macker, "A TCP-Friendly, Rate-based Mechanism [31] Adamson, B. and J. Macker, "A TCP-Friendly, Rate-based Mechanism
for NACK-Oriented Reliable Multicast Congestion Control", IEEE for NACK-Oriented Reliable Multicast Congestion Control", IEEE
GLOBECOMM 2001, November 2001. GLOBECOMM 2001, November 2001.
12. Authors' Addresses 12. Authors Addresses
Brian Adamson Brian Adamson
Naval Research Laboratory Naval Research Laboratory
Washington, DC, USA, 20375 Washington, DC, USA, 20375
EMail: adamson@itd.nrl.navy.mil EMail: adamson@itd.nrl.navy.mil
Carsten Bormann Carsten Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
skipping to change at page 94, line 7 skipping to change at page 94, line 7
EMail: M.Handley@cs.ucl.ac.uk EMail: M.Handley@cs.ucl.ac.uk
Joe Macker Joe Macker
Naval Research Laboratory Naval Research Laboratory
Washington, DC, USA, 20375 Washington, DC, USA, 20375
EMail: macker@itd.nrl.navy.mil EMail: macker@itd.nrl.navy.mil
13. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 100 change blocks. 
104 lines changed or deleted 104 lines changed or added

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