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
operation. Similarly, the NORM_ACK_FLUSH is provided for use only in
NORM_ACKs generated in response to applicable NORM_CMD(FLUSH)
messages. NORM_CMD(ACK_REQ) messages with "ack_type" of NORM_ACK_CC
or NORM_ACK_FLUSH SHALL NOT be generated by the sender.
The NORM_ACK_RESERVED range of "ack_type" values is provided for
possible future NORM protocol use.
The NORM_ACK_APPLICATION range of "ack_type" values is provided so
that NORM applications may implement application-defined,
positively-acknowledged commands that are able to leverage internal
transmission and round-trip timing information available to the NORM
protocol implementation.
The "ack_id" provides a sequenced identifier for the given
NORM_CMD(ACK_REQ) message. This "ack_id" is returned in NORM_ACK
messages generated by the receivers so that the sender may associate
the response with its corresponding request.
The "reserved" field is reserved for possible future protocol use and
SHALL be set to ZERO by senders and ignored by receivers.
The "acking_node_list" field contains the NormNodeIds of the current
NORM receivers that are desired to provide positive acknowledge
(NORM_ACK) to this request. The packet payload length implies the
length of the "acking_node_list" and its length is limited to the
sender NormSegmentSize. The individual NormNodeId items are listed
in network (Big Endian) byte order. If a receiver’s NormNodeId is
included in the "acking_node_list", it SHALL schedule transmission of
a NORM_ACK message as described in Section 5.5.3.
4.2.3.7. NORM_CMD(APPLICATION) Message
This command allows the NORM application to robustly transmit
application-defined commands. The command message preempts any
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
the application to observe any response (if that is the application’s
purpose for the command) before it is repeated. Possible responses
may include initiation of data transmission, other
NORM_CMD(APPLICATION) messages, or even application-defined,
positively-acknowledge commands from other NormSession participants.
The transmission of these commands will preempt data transmission
when they are scheduled and may be multiplexed with ongoing data
transmission. This type of robustly transmitted command allows NORM
applications to define a complete set of session control mechanisms
with less state than the transfer of FEC encoded reliable content
requires while taking advantage of NORM transmission and round-trip
timing information.
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=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 7 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application-Defined Content |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD(APPLICATION) Message Format
The NORM common message header and NORM_CMD fields are interpreted as
previously described. The value of the NORM_CMD(APPLICATION)
"hdr_len" field when no header extensions are present is 4.
The "Application-Defined Content" area contains information in a
format at the discretion of the application. The size of this
payload SHALL be limited to a maximum of the sender’s NormSegmentSize
setting.
4.3. Receiver Messages
The NORM message types generated by participating receivers consist
of 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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 which contain
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 differential from when the receiver received the NORM_CMD(CC)
to when the NORM_NACK is transmitted to calculate the value in the
"grtt_response" field. This is the
"receive_to_response_differential" value used in the following
formula:
"grtt_response" = NORM_CMD(CC) "send_time" +
receive_to_response_differential
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
indicated sender and that the sender should 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 receivers current
state with respect to congestion control operation. Note that
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_content" 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 requires from the
sender in order 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 may be concatenated within the "nack_payload" field
of a NORM_NACK message. Note that 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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 that the
"repair_request_items" list consists of pairs of repair request items
that correspond to inclusive ranges of repair needs. And the
NORM_NACK_ERASURES "form" indicates that the repair request items are
to be treated individually and that 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 are required as repair. |
+------------------+-------+-----------------------------------------+
|NORM_NACK_BLOCK | 0x02 | Indicates the listed block(s) or range |
| | | of blocks in entirety are required as |
| | | repair. |
+------------------+-------+-----------------------------------------+
|NORM_NACK_INFO | 0x04 | Indicates that NORM_INFO is required as |
| | | repair for the listed object(s). |
+------------------+-------+-----------------------------------------+
|NORM_NACK_OBJECT | 0x08 | Indicates the listed object(s) or range |
| | | of objects in entirety are required 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
requires transmissions sufficient to repair the indicated block(s) in
their entirety. 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 may be set in
combination with the NORM_NACK_BLOCK or NORM_NACK_SEGMENT flags, or
may 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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 required 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 may 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,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. As
mentioned in the NORM_CMD(ACK_REQ) message description, the
acknowledgment type NORM_ACK_CC is provided for this purpose. The
generation of NORM_ACK(CC) messages for round-trip timing estimation
and congestion-control operation is described in Sections 5.5.1 and
5.5.2, respectively. However, some multicast applications may
benefit from some limited form of positive acknowledgment for certain
functions. A simple, scalable positive acknowledgment scheme is
defined in Section 5.5.3 that can be leveraged by protocol
implementations when appropriate. The NORM_CMD(FLUSH) may 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 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