RFC 5740
NACK-Oriented Reliable Multicast (NORM) Transport Protocol
4.3. Receiver Messages
The NORM message types generated by participating receivers consist of the NORM_NACK and NORM_ACK message types. NORM_NACK messages are sent to request repair of missing data content from sender transmission, and NORM_ACK messages are generated in response to certain sender commands including NORM_CMD(CC) and NORM_CMD(ACK_REQ).4.3.1. NORM_NACK Message
The principal purpose of NORM_NACK messages is for receivers to request repair of sender content via selective, negative acknowledgment upon detection of incomplete data. NORM_NACK messages will be transmitted according to the rules of NORM_NACK generation and suppression described in Section 5.3. NORM_NACK messages also contain additional fields to provide feedback to the sender(s) for purposes of round-trip timing collection and congestion control. The payload of NORM_NACK messages contains one or more repair
requests for different objects or portions of those objects. The NORM_NACK message format is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |version| type=4| hdr_len | sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | server_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | instance_id | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | grtt_response_sec | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | grtt_response_usec | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | header extensions (if applicable) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | nack_payload | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17: NORM_NACK Message Format The NORM common message header fields serve their usual purposes. The value of the "hdr_len" field for NORM_NACK messages without header extensions present is 6. The "server_id" field identifies the NORM sender to which the NORM_NACK message is destined. The "instance_id" field contains the current session identifier given by the sender identified by the "server_id" field in its sender messages. The sender SHOULD ignore feedback messages containing an invalid "instance_id" value. The "grtt_response" fields contain an adjusted version of the timestamp from the most recently received NORM_CMD(CC) message for the indicated NORM sender. The format of the "grtt_response" is the same as the "send_time" field of the NORM_CMD(CC). The "grtt_response" value is relative to the "send_time" the source provided with a corresponding NORM_CMD(CC) command. The receiver adjusts the source's NORM_CMD(CC) "send_time" timestamp by adding the 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 "grtt_response" field. This is the "receive_to_response_delta"
value used in the following formula:
grtt_response = NORM_CMD(CC) send_time + receive_to_response_delta
The receiver SHALL set the "grtt_response" to a ZERO value, to
indicate it has not yet received a NORM_CMD(CC) message from the
indicated sender, and the sender MUST ignore the "grtt_response" in
this message.
For NORM-CC operation, the NORM-CC Feedback Header Extension, as
described in the NORM_CMD(REPAIR_ADV} message description, is added
to NORM_NACK messages to provide feedback on the receiver's current
state with respect to congestion control operation. Alternative
header extensions for congestion control feedback MAY be defined for
alternative congestion control schemes for NORM use in the future.
The "reserved" field is for potential future NORM use and SHALL be
set to ZERO for this version of the protocol.
The "nack_payload" of the NORM_NACK message specifies the repair
needs of the receiver with respect to the NORM sender indicated by
the "server_id" field. The receiver constructs repair requests based
on the NORM_DATA and/or NORM_INFO segments it needs from the sender
to complete reliable reception up to the sender's transmission
position at the moment the receiver initiates the NACK 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 counts for
needed NORM_DATA and/or NORM_INFO content. Multiple repair requests
can be concatenated within the "nack_payload" field of a NORM_NACK
message. A single NORM Repair Request can possibly include multiple
"items", "ranges", or "erasure_counts". In turn, the "nack_payload"
field MAY contain multiple repair requests. A single NORM Repair
Request has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| form | flags | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| repair_request_items |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: NORM Repair Request Format
The "form" field indicates the type of repair request items given in
the "repair_request_items" list. Possible values for the "form"
field include:
+--------------------+-------+
| Form | Value |
+--------------------+-------+
| NORM_NACK_ITEMS | 1 |
| NORM_NACK_RANGES | 2 |
| NORM_NACK_ERASURES | 3 |
+--------------------+-------+
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
request. A value of NORM_NACK_RANGES indicates the
"repair_request_items" list consists of pairs of repair request items
corresponding to the inclusive ranges of repair needs. The
NORM_NACK_ERASURES "form" indicates the repair request items are to
be treated individually and the "encoding_symbol_id" portion 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
identified by the repair request item's "source_block_number".
The "flags" field is currently used to indicate the level of data
content for which the repair request items apply (i.e., an individual
segment, entire FEC coding block, or entire transport object).
Possible flag values include:
+-------------------+--------+--------------------------------------+
| Flag | Value | Purpose |
+-------------------+--------+--------------------------------------+
| NORM_NACK_SEGMENT | 0x01 | Indicates the listed segment(s) or |
| | | range of segments needed as repair. |
| NORM_NACK_BLOCK | 0x02 | Indicates the listed block(s) or |
| | | range of blocks in entirety that are |
| | | needed as repair. |
| NORM_NACK_INFO | 0x04 | Indicates NORM_INFO is needed as |
| | | repair for the listed object(s). |
| NORM_NACK_OBJECT | 0x08 | Indicates the listed object(s) or |
| | | range of objects in entirety are |
| | | needed as repair. |
+-------------------+--------+--------------------------------------+
When the NORM_NACK_SEGMENT flag is set, the "object_transport_id" and
"fec_payload_id" fields are used to determine which sets or ranges of
individual NORM_DATA segments are needed to repair content at the
receiver. When the NORM_NACK_BLOCK flag is set, this indicates the
receiver is completely missing the indicated coding block(s), and
that transmissions sufficient to repair the indicated block(s) in
their entirety are needed. When the NORM_NACK_INFO flag is set, this
indicates the receiver is missing the NORM_INFO segment for the
indicated "object_transport_id". Note the NORM_NACK_INFO can be set
in combination with the NORM_NACK_BLOCK or NORM_NACK_SEGMENT flags, or can be set alone. When the NORM_NACK_OBJECT flag is set, this indicates the receiver is missing the entire NormTransportObject referenced by the "object_transport_id". This also implicitly requests any available NORM_INFO for the NormObject, if applicable. The "fec_payload_id" field is ignored when the flag NORM_NACK_OBJECT is set. The "length" field value is the length in bytes of the "repair_request_items" field. The "repair_request_items" field consists of a list of individual or range pairs of transport data unit identifiers in the following format. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fec_id | reserved | object_transport_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fec_payload_id | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19: NORM Repair Request Item Format The "fec_id" indicates the FEC type and can be used to determine the format of the "fec_payload_id" field. The "reserved" field is kept for possible future use and SHALL be set to a ZERO value and ignored by NORM nodes processing NACK content. The "object_transport_id" corresponds to the NormObject for which repair is being requested, and the "fec_payload_id" identifies 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 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 interpreted. The format of the "fec_payload_id" field depends upon the "fec_id" field value. When the receiver's repair needs dictate that different forms (mixed ranges and/or individual items) or types (mixed specific segments and/or blocks or objects in entirety) are needed to complete reliable transmission, multiple NORM Repair Requests with different "form" and or "flags" values can be concatenated within a single NORM_NACK message. Additionally, NORM receivers SHALL construct NORM_NACK messages with their repair requests in ordinal order with respect to
"object_transport_id" and "fec_payload_id" values. The
"nack_payload" size SHALL NOT exceed the NormSegmentSize for the
sender to which the NORM_NACK is destined.
NORM_NACK Content Examples:
In these examples, a small block, systematic FEC code ("fec_id" =
129) is assumed with a user data block length of 32 segments. In
Example 1, a list of individual NORM_NACK_ITEMS repair requests is
given. In Example 2, a list of NORM_NACK_RANGES requests AND a
single NORM_NACK_ITEMS request are concatenated to illustrate the
possible content of a NORM_NACK message. Note that FEC coding block
erasure counts could also be provided in each case. However, the
erasure counts are not really necessary since the sender can easily
determine the erasure count while processing the NACK content.
However, the erasure count option can be useful for operation with
other FEC codes or for intermediate system purposes.
Example 1: NORM_NACK "nack_payload" for: Object 12, Coding Block 3,
Segments 2, 5, and 8
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| form = 1 | flags = 0x01 | length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_length = 32 | encoding_symbol_id = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_length = 32 | encoding_symbol_id = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_length = 32 | encoding_symbol_id = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example 2: NORM_NACK "nack_payload" for: Object 18, Coding Block 6,
Segments 5, 6, 7, 8, 9, 10; and Object 19 NORM_INFO and Coding Block
1, Segment 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| form = 2 | flags = 0x01 | length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_length = 32 | encoding_symbol_id = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_length = 32 | encoding_symbol_id = 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| form = 1 | flags = 0x05 | length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id = 129 | reserved | object_transport_id = 19 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_length = 32 | encoding_symbol_id = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.2. NORM_ACK Message
The NORM_ACK message is intended to be used primarily as part of NORM
congestion control operation and round-trip timing measurement. The
acknowledgment type NORM_ACK(CC) is provided for this purpose as
described in the NORM_CMD(ACK_REQ) message description. The
generation of NORM_ACK(CC) messages for round-trip timing estimation
and congestion control operation is described in Section 5.5.1 and
Section 5.5.2, respectively. However, some multicast applications
can benefit from some limited form of positive acknowledgment for
certain functions. A simple, scalable positive acknowledgment scheme
is defined in Section 5.5.3, which can be leveraged by protocol
implementations when appropriate. The NORM_CMD(FLUSH) can also be
used for OPTIONAL collection of positive acknowledgment of reliable
reception to a certain "watermark" transmission point from specific
receivers using this mechanism. The NORM_ACK type NORM_ACK(FLUSH) is
provided for this purpose and the format of the "nack_payload" for
this acknowledgment type is given below. Beyond that, a range of
application-defined "ack_type" values is provided for use at the NORM
application's discretion. Implementations making use of application- defined positive acknowledgments MAY also make use of the "nack_payload" as needed, observing the constraint that the "nack_payload" field size be limited to a maximum of the NormSegmentSize for the sender to which the NORM_ACK is destined. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |version| type=5| hdr_len | sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | server_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | instance_id | ack_type | ack_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | grtt_response_sec | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | grtt_response_usec | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | header extensions (if applicable) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ack_payload (if applicable) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 20: NORM_ACK Message Format The NORM common message header fields serve their usual purposes. The value of the "hdr_len" field when no header extensions are present is 6. The "server_id", "instance_id", and "grtt_response" fields serve the same purpose as the corresponding fields in NORM_NACK messages. Header extensions can be applied to support congestion control feedback or other functions in the same manner. The "ack_type" field indicates the nature of the NORM_ACK message. This directly corresponds to the "ack_type" field of the NORM_CMD(ACK_REQ) message to which this acknowledgment applies. The "ack_id" field serves as a sequence number so the sender can verify a received NORM_ACK message actually applies to a current acknowledgment request. The "ack_id" field is not used in the case of the NORM_ACK(CC) and NORM_ACK(FLUSH) acknowledgment types. The "ack_payload" format is a function of the "ack_type". The
NORM_ACK(CC) message has no attached content. Only the NORM_ACK
header applies. In the case of NORM_ACK(FLUSH), a specific
"ack_payload" format is defined:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_id | reserved | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload_id |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "object_transport_id" and "fec_payload_id" are used by the
receiver to acknowledge applicable NORM_CMD(FLUSH) messages
transmitted by the sender identified by the "server_id" field.
The "ack_payload" of NORM_ACK messages for application-defined
"ack_type" values is specific to the application but is limited in
size to a maximum of the NormSegmentSize of the sender referenced by
the "server_id".
4.4. General Purpose Messages
Some additional message formats are defined for general purpose in
NORM multicast sessions whether the participant is acting as a sender
and/or receiver within the group.
4.4.1. NORM_REPORT Message
This is an OPTIONAL message generated by NORM participants. This
message can be used for periodic performance reports from receivers
in experimental NORM implementations. The format of this message is
currently undefined. Experimental NORM implementations MAY define
NORM_REPORT formats as needed for test purposes. These report
messages SHOULD be disabled for interoperability testing between
different compliant NORM implementations.
5. Detailed Protocol Operation
This section describes the detailed interactions of senders and
receivers participating in a NORM session. A simple synopsis of the
protocol operation is given here:
1. The sender periodically transmits NORM_CMD(CC) messages as needed
to initialize and collect round-trip timing and congestion
control feedback from the receiver set.
2. The sender transmits an ordinal set of NormObjects segmented in
the form of NORM_DATA messages labeled with NormTransportIds and
logically identified with FEC encoding block numbers and symbol
identifiers. When applicable, NORM_INFO messages MAY optionally
precede the transmission of data content for NORM transport
objects.
3. As receivers detect missing content from the sender, they
initiate repair requests with NORM_NACK messages. The receivers
track the sender's most recent objectTransportId::fecPayloadId
transmit position and NACK only for content that is ordinally
prior to that current transmit position. The receivers schedule
random backoff timeouts before generating NORM_NACK messages and
wait an appropriate amount of time before repeating the NORM_NACK
if their repair request is not satisfied.
4. The sender aggregates repair requests from the receivers and
logically "rewinds" its transmit position to send appropriate
repair messages. The sender sends repairs for the earliest
ordinal transmit position first and maintains this ordinal repair
transmission sequence. FEC parity content not previously
transmitted for the applicable FEC coding block is used for
repair transmissions to the greatest extent possible. If the
sender exhausts its available FEC parity content on multiple
repair cycles for the same coding block, it resorts to an
explicit repair strategy (possibly using parity content) to
complete repairs. (The use of explicit repair is an exception in
general protocol operation, but the possibility does exist for
extreme conditions). The sender immediately assumes transmission
of new content once it has sent pending repairs.
5. The sender transmits NORM_CMD(FLUSH) messages when it reaches the
end of enqueued transmit content and pending repairs. Receivers
respond to the NORM_CMD(FLUSH) messages with NORM_NACK
transmissions (following the same suppression backoff timeout
strategy as for data) if they need further repair.
6. The sender transmissions are subject to rate control limits
determined by congestion control mechanisms. In the baseline
NORM-CC operation, each sender in a NormSession maintains its own
independent congestion control state. Receivers provide
congestion control feedback in NORM_NACK and NORM_ACK messages.
NORM_ACK feedback for congestion control purposes is governed
using a suppression mechanism similar to that for NORM_NACK
messages.
While this overall concept is relatively simple, there are details to
each of these aspects that need to be addressed for successful,
efficient, robust, and scalable NORM protocol operation.5.1. Sender Initialization and Transmission
Upon startup, the NORM sender immediately begins sending NORM_CMD(CC) messages to collect round-trip timing and other information from the potential group. If NORM-CC congestion control operation is enabled, the NORM-CC Rate header extension MUST be included in these messages. Congestion control operation SHALL be observed at all times when not operating using dedicated resources, like in the general Internet. Even if congestion control operation is disabled at the sender, it can be desirable to use the NORM_CMD(CC) messaging to collect feedback from the group using the baseline NORM-CC feedback mechanisms. This proactive feedback collection can be used to establish a GRTT estimate prior to data transmission and potential NACK operation. In some cases, applications might need the sender to also proceed with data transmission immediately. In other cases, the sender might wish to defer data transmission until it has received some feedback or request from the receiver set indicating receivers are indeed present. Note, in some applications (e.g., web push), this indication MAY come out-of-band with respect to the multicast session via other means. As noted, the periodic transmission of NORM_CMD(CC) messages MAY precede actual data transmission in order to have an initial GRTT estimate. With inclusion of the OPTIONAL NORM FEC Object Transmission Information Header Extension (EXT_FTI), the NORM protocol sender message headers can contain all information necessary to prepare receivers for subsequent reliable reception. This includes FEC coding parameters, the sender NormSegmentSize, and other information. If this header extension is not used, it is presumed receivers have received the FEC Object Transmission Information via other means. Additionally, applications MAY leverage the use of NORM_INFO messages associated with the session data objects in the session to provide application-specific context information for the session and data being transmitted. These mechanisms allow for operation with minimal pre-coordination among the senders and receivers. The NORM sender begins segmenting application-enqueued data into NORM_DATA segments and transmitting it to the group. For objects of type NORM_OBJECT_DATA and NORM_OBJECT_FILE, the segmentation algorithm described in FEC Building Block [RFC5052] is RECOMMENDED. For objects of type NORM_OBJECT_STREAM, segmentation will typically be into uniform FEC coding block sizes, with individual segment sizes controlled by the application. In most cases, the application and NORM implementation SHOULD strive to produce full-sized
(NormSegmentSize) segments when possible. The rate of transmission is controlled via congestion control mechanisms or is a fixed rate if desired for closed network operations. The receivers participating in the multicast group provide feedback to the sender as needed. When the sender reaches the end of data it has enqueued for transmission or any pending repairs, it transmits a series of NORM_CMD(FLUSH) messages at a rate of one per 2*GRTT_sender. Similar to the end of each transmitted FEC coding block during transmission, receivers SHALL respond to these NORM_CMD(FLUSH) messages with additional repair requests as needed. A protocol parameter NORM_ROBUST_FACTOR determines the number of flush messages sent. If receivers request repair, the repair is provided, and flushing occurs again at the end of repair transmission. The sender MAY attach an OPTIONAL "acking_node_list" to NORM_CMD(FLUSH) containing the NormNodeIds for receivers from which it expects explicit positive acknowledgment of reception. The NORM_CMD(FLUSH) message MAY be also used for this OPTIONAL purpose any time prior to the end of data enqueued for transmission with the NORM_CMD(FLUSH) messages multiplexed with ongoing data transmissions. The OPTIONAL NORM positive acknowledgment procedure is described in Section 5.5.3.5.1.1. Object Segmentation Algorithm
NORM senders and receivers MUST use a common algorithm for logically segmenting transport data into FEC encoding blocks and symbols so appropriate NACKs can be constructed to request repair of missing data. NORM FEC coding blocks are comprised of multi-byte symbols (segments) transmitted in the payload of NORM_DATA messages. Each NORM_DATA message will contain one or more source or encoding symbols identified by the "fec_payload_id" field, and the NormSegmentSize sender parameter defines the maximum size (in bytes) of the "payload_data" field containing the content (a "segment"). The FEC encoding type and associated parameters govern the source block size (number of source symbols per coding block, etc.). NORM senders and receivers use these FEC parameters, along with the NormSegmentSize and transport object size to compute the source block structure for transport objects. These parameters are provided in the FEC Object Transmission Information for each object. The block partitioning algorithm described in the FEC Building Block [RFC5052] document is RECOMMENDED for use in computing a source block structure such that all source blocks are as close to being equal length as possible. This helps avoid the performance disadvantages of "short" FEC blocks. Note that this algorithm applies only to the statically sized NORM_OBJECT_DATA and NORM_OBJECT_FILE transport object types where the object size is fixed and predetermined. For NORM_OBJECT_STREAM objects, the object is segmented according to the maximum source block length given in the FEC Transmission Information, unless the FEC Payload ID indicates an alternative size for a given block.
5.2. Receiver Initialization and Reception
For typical operation, NORM receivers will join a specified multicast group and listen on a specific port number for sender transmissions. As the NORM receiver receives NORM_DATA messages, it will establish buffering state and provide content to its application as appropriate for the given data type. The NORM protocol allows receivers to join and leave the group at will, although some applications might need receivers to be members of the group prior to start of data transmission. Thus, different NORM applications MAY use different policies to constrain the impact of new receivers joining the group in the middle of a session. For example, a useful implementation policy is for new receivers joining the group to limit or avoid repair requests for transport objects already in progress. The NORM sender implementation MAY impose additional constraints to limit the ability of receivers to disrupt reliable multicast performance by joining, leaving, and rejoining the group often. Different receiver "join policies" might be appropriate for different applications and/or scenarios. For general purpose operation, a default policy where receivers are allowed to request repair only for coding blocks with a NormTransportId and FEC coding block number greater than or equal to the first non-repair NORM_DATA or NORM_INFO message received upon joining the group is RECOMMENDED. For objects of type NORM_OBJECT_STREAM, it is RECOMMENDED the join policy constrain receivers to begin reliable reception at the current FEC coding block for which non-repair content is received. In some deployments, different multicast receivers might have differing quality of network connectivity. Some receivers may suffer significantly poorer performance with very limited goodput due to low connection rate or substantial packet loss. Similar to the "join policies" described above, a NORM sender implementation MAY choose to enforce different "service policies" to perhaps exclude exceptionally poorly performing (or otherwise badly behaving) receivers from the group. The sender implementation could choose to ignore NACKs from such receivers and/or force advancement of its logical "repair window" (i.e., enforcing a minimal level of service) and use the NORM_CMD(SQUELCH) message to advise those poor performers of its advance. Note in some cases, the application may need to support the "weakest member" regardless of the time needed to achieve reliable delivery. When implemented, the protocol instantiation SHOULD expose controls to the set of "join" and/or "service" policies available to support the needs of different applications.5.3. Receiver NACK Procedure
When the receiver detects it is missing data from a sender's NORM transmissions, it initiates its NACKing procedure. The NACKing
procedure SHALL be initiated only at FEC coding block boundaries,
NormObject boundaries, upon receipt of a NORM_CMD(FLUSH) message, or
upon an "inactivity" timeout when NORM_DATA or NORM_INFO
transmissions are no longer received from a previously active sender.
The RECOMMENDED value of such an inactivity timeout is:
T_inactivity = NORM_ROBUST_FACTOR * 2 * GRTT_sender
where the GRTT_sender value corresponds to the GRTT estimate
advertised in the "grtt" field of NORM sender messages. A minimum
T_inactivity value of 1 second is RECOMMENDED. The NORM receiver
SHOULD reset this inactivity timer and repeat NACK initiation upon
timeout for up to NORM_ROBUST_FACTOR times or more depending upon the
application's need for persistence by its receivers. It is also
important receivers rescale the T_inactivity timeout as the sender's
advertised GRTT changes.
The NACKing procedure begins with a random backoff timeout. The
duration of the backoff timeout is chosen using the "RandomBackoff"
algorithm described in the Multicast NACK Building Block [RFC5401]
document using (K_sender*GRTT_sender) for the maxTime parameter and
the sender advertised group size (GSIZE_sender) as the groupSize
parameter. NORM senders provide values for GRTT_sender, K_sender and
GSIZE_sender via the "grtt", "backoff", and "gsize" fields of
transmitted messages. The GRTT_sender value is determined by the
sender based on feedback it has received from the group while the
K_sender and GSIZE_sender values can be determined by application
requirements and expectations or ancillary information. The backoff
factor K_sender MUST be greater than one to provide for effective
feedback suppression. A value of K_sender = 4 is RECOMMENDED for the
Any Source Multicast (ASM) model, while a value of K_sender = 6 is
RECOMMENDED for Single Source Multicast (SSM) operation.
Thus:
T_backoff = RandomBackoff(K_sender*GRTT_sender, GSIZE_sender)
To avoid the possibility of NACK implosion in the case of sender or
network failure during SSM operation, the receiver SHALL
automatically suppress its NACK and immediately enter the "holdoff"
period described below when T_backoff is greater than (K_sender-
1)*GRTT_sender. Otherwise, the backoff period is entered and the
receiver MUST accumulate external pending repair state from NORM_NACK
messages and NORM_CMD(REPAIR_ADV) messages received. At the end of
the backoff time, the receiver SHALL generate a NORM_NACK message
only if the following conditions are met:
1. The sender's current transmit position (in terms of
objectTransportId::fecPayloadId) exceeds the earliest repair
position of the receiver.
2. The repair state accumulated from NORM_NACK and
NORM_CMD(REPAIR_ADV) messages does not equal or supersede the
receiver's repair needs up to the sender transmission position at
the time the NACK procedure (backoff timeout) was initiated.
If these conditions are met, the receiver immediately generates a
NORM_NACK message when the backoff timeout expires. Otherwise, the
receiver's NACK is considered to be "suppressed" and the message is
not sent. At this time, the receiver begins a "holdoff" period
during which it constrains itself to not re-initiate the NACKing
process. The purpose of this timeout is to allow the sender worst-
case time to respond to the repair needs before the receiver requests
repair again. The value of this "holdoff" timeout (T_rcvrHoldoff) as
described in [RFC5401] is:
T_rcvrHoldoff =(K_sender+2)*GRTT_sender
The NORM_NACK message contains repair request content beginning with
the lowest ordinal repair position of the receiver up through the
coding block prior to the most recently heard ordinal transmission
position for the sender. If the size of the NORM_NACK content
exceeds the sender's NormSegmentSize, the NACK content is truncated
so the receiver only generates a single NORM_NACK message per NACK
cycle for a given sender. In summary, a single NACK message is
generated containing the receiver's lowest ordinal repair needs.
For each partially received FEC coding block requiring repair, the
receiver SHALL, on its FIRST repair attempt for the block, request
the parity portion of the FEC coding block beginning with the lowest
ordinal parity "encoding_symbol_id" (i.e., "encoding_symbol_id" =
"source_block_len") and request the number of FEC symbols
corresponding to its data segment erasure count for the block. On
subsequent repair cycles for the same coding block, the receiver
SHALL request only those repair symbols from the first set it has not
yet received up to the remaining erasure count for that applicable
coding block. Note the sender might have transmitted other
different, additional parity segments for other receivers that could
also be used to satisfy the local receiver's erasure-filling needs.
In the case where the erasure count for a partially received FEC
coding block exceeds the maximum number of parity symbols available
from the sender for the block (as indicated by the NORM_DATA
"fec_num_parity" field), the receiver SHALL request all available
parity segments plus the ordinally highest missing data segments
needed to satisfy its total erasure needs for the block. The goal of
this strategy is for the overall receiver set to request a lowest
common denominator set of repair symbols for a given FEC coding block. This allows the sender to construct the most efficient repair transmission segment set and enables effective NACK suppression among the receivers even with uncorrelated packet loss. This approach also does not demand synchronization among the receiver set in their repair requests for the sender. For FEC coding blocks or NormObjects missed in their entirety, the NORM receiver constructs repair requests with NORM_NACK_BLOCK or NORM_NACK_OBJECT flags set as appropriate. The request for retransmission of NORM_INFO is accomplished by setting the NORM_NACK_INFO flag in a corresponding repair request.5.4. Sender NACK Processing and Response
The principal goal of the sender is to make forward progress in the transmission of data its application has enqueued. However, the sender will need to occasionally "rewind" its logical transmission point to satisfy the repair needs of receivers who have NACKed. Aggregation of multiple NACKs is used to determine an optimal repair strategy when a NACK event occurs. Since receivers initiate the NACK process on coding block or object boundaries, there is some loose degree of synchronization of the repair process even when receivers experience uncorrelated data loss.5.4.1. Sender Repair State Aggregation
When a sender is in its normal state of transmitting new data and receives a NACK, it begins a procedure to accumulate NACK repair state from NORM_NACK messages before beginning repair transmissions. Note that this period of aggregating repair state does NOT interfere with its ongoing transmission of new data. As described in [RFC5401], the period of time during which the sender aggregates NORM_NACK messages is equal to: T_sndrAggregate = (K_sender + 1) * GRTT_sender where K_sender is the backoff scaling value advertised to the receivers, and GRTT_sender is the sender's current estimate of the group's greatest round-trip time. Note, for NORM unicast sessions, the T_sndrAggregate time can be set to ZERO since there is only one receiver. Similarly, the K_sender value SHOULD be set to ZERO for NORM unicast sessions to minimize repair latency. When this period ends, the sender "rewinds" by incorporating the accumulated repair state into its pending transmission state and begins transmitting repair messages. After pending repair
transmissions are completed, the sender continues with new transmissions of any enqueued data. Also, at this point in time, the sender begins a "holdoff" timeout during which time the sender constrains itself from initiating a new repair aggregation cycle, even if NORM_NACK messages arrive. As described in [RFC5401], the value of this sender "holdoff" period is: T_sndrHoldoff = (1 * GRTT_sender) If additional NORM_NACK messages are received during this sender "holdoff" period, the sender will immediately incorporate these late- arriving messages into its pending transmission state if, and only if, the NACK content is ordinally greater than the sender's current transmission position. This "holdoff" time allows worst-case time for the sender to propagate its current transmission sequence position to the group, thus avoiding redundant repair transmissions. After the holdoff timeout expires, a new NACK accumulation period can be started (upon arrival of a NACK) in concert with the pending repair and new data transmission. Recall receivers are not to initiate the NACK repair process until the sender's logical transmission position exceeds the lowest ordinal position of their repair needs. With the new NACK aggregation period, the sender repeats the same process of incorporating accumulated repair state into its transmission plan and subsequently "rewinding" to transmit the lowest ordinal repair data when the aggregation period expires. Again, this is conducted in concert with ongoing new data and/or pending repair transmissions.5.4.2. Sender FEC Repair Transmission Strategy
The NORM sender SHOULD leverage transmission of FEC parity content for repair to the greatest extent possible. Recall that receivers use a strategy to request a lowest common denominator of explicit repair (including parity content) in the formation of their NORM_NACK messages. Before falling back to explicitly satisfying different receivers' repair needs, the sender can make use of the general erasure-filling capability of FEC-generated parity segments. The sender can determine the maximum erasure-filling needs for individual FEC coding blocks from the NORM_NACK messages received during the repair aggregation period. Then, if the sender has a sufficient number (less than or equal to the maximum erasure count) of previously unsent parity segments available for the applicable coding blocks, the sender can transmit these in lieu of the specific packets the receiver set has requested. The sender SHOULD NOT resort to explicit transmission of the receiver set's repair needs until after exhausting its supply of "fresh" (unsent) parity segments for a given coding block. In general, if a sufficiently powerful FEC code is used, the need for explicit repair will be an exception, and the
fulfillment of reliable multicast can be accomplished quite efficiently. However, the ability to resort to explicit repair allows the protocol to be continue to operate under even very extreme circumstances. NORM_DATA messages sent as repair transmissions SHALL be flagged with the NORM_FLAG_REPAIR flag. This allows receivers to obey any policies limiting new receivers from joining the reliable transmission when only repair transmissions have been received. Additionally, the sender SHOULD flag NORM_DATA transmissions sent as explicit repair with the NORM_FLAG_EXPLICIT flag. Although NORM end system receivers do not make use of the NORM_FLAG_EXPLICIT flag, this message transmission status could be leveraged by intermediate systems wishing to "assist" NORM protocol performance. If such systems are properly positioned with respect to reciprocal reverse-path multicast routing, they need to sub-cast only a sufficient count of non-explicit parity repairs to satisfy a multicast routing sub-tree's erasure-filling needs for a given FEC coding block. When the sender has resorted to explicit repair, then the intermediate systems SHOULD sub-cast all of the explicit repair packets to those portions of the routing tree still requiring repair for a given coding block. Note the intermediate systems will need to conduct repair state accumulation for sub-routes in a manner similar to the sender's repair state accumulation in order to have sufficient information to perform the sub-casting. Additionally, the intermediate systems could perform NORM_NACK suppression/aggregation as it conducts this repair state accumulation for NORM repair cycles. The details of this type of operation are beyond the scope of this document, but this information is provided for possible future consideration.5.4.3. Sender NORM_CMD(SQUELCH) Generation
If the sender receives a NORM_NACK message for repair of data it is no longer supporting, the sender generates a NORM_CMD(SQUELCH) message to advertise its repair window and squelch any receivers from additional NACKing of invalid data. The transmission rate of NORM_CMD(SQUELCH) messages is limited to once per 2*GRTT_sender. The "invalid_object_list" (if applicable) of the NORM_CMD(SQUELCH) message SHALL begin with the lowest "object_transport_id" from the invalid NORM_NACK messages received since the last NORM_CMD(SQUELCH) transmission. The list includes as many lower ordinal invalid "object_transport_ids" that can fit for the NORM_CMD(SQUELCH) payload size to less than or equal to the sender's NormSegmentSize parameter.
5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation
When a NORM sender receives NORM_NACK messages from receivers via unicast transmission, it uses NORM_CMD(REPAIR_ADV) messages to advertise its accumulated repair state to the receiver set since the receiver set is not directly sharing their repair needs via multicast communication. A NORM sender implementation MAY use a separate port number from the NormSession port number as the source port for its transmissions. Thus, NORM receivers can direct any unicast feedback messages to this separate sender port number, distinct from the NORM session (or destination) port number. Then, the NORM sender implementation can discriminate unicast feedback messages from multicast feedback messages when there is a mix of multicast and unicast feedback receivers. The NORM_CMD(REPAIR_ADV) message is multicast to the receiver set by the sender. The payload portion of this message has content in the same format as the NORM_NACK receiver message payload. Receivers are then able to perform feedback suppression in the same manner as with NORM_NACK messages directly received from other receivers. Note that the sender does not merely retransmit NACK content it receives, but instead transmits a representation of its aggregated repair state. The transmission of NORM_CMD(REPAIR_ADV) messages is subject to the sender transmit rate limit and NormSegmentSize limitation. When the NORM_CMD(REPAIR_ADV) message is of maximum size (as indicated by the flag NORM_REPAIR_ADV_FLAG_LIMIT), receivers SHALL consider the maximum ordinal transmission position value embedded in the message as the senders current transmission position and implicitly suppress requests for ordinally higher repair. For congestion control operation, the sender will also need to provide any information needed so dynamic congestion control feedback can be suppressed among receivers. This document specifies the NORM-CC Feedback Header Extension that is applied for baseline NORM-CC operation. If other congestion control mechanisms are used within a NORM implementation, other header extensions MAY be defined. Whatever content format is used for this purpose SHOULD ensure that maximum possible suppression state is conveyed to the receiver set.
(page 65 continued on part 4)
