congestion control scheme (NORM-CC), based on the TCP-Friendly
Multicast Congestion Control (TFMCC) scheme of [19] is described in
Section 5.5.2 of this document. The NORM_CMD(CC) message is usually
transmitted as part of NORM-CC congestion control operation. A NORM
header extension is defined below to be used with the NORM_CMD(CC)
message to support NORM-CC operation. Different header extensions
may be defined for the NORM_CMD(CC) (and/or other NORM messages as
needed) to support alternative congestion control schemes in the
future. If NORM is operated in a private network with congestion
control operation disabled, the NORM_CMD(CC) message is then used for
GRTT measurement only and may optionally be sent less frequently than
with congestion control operation.
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 = 4 | reserved | cc_sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| send_time_sec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| send_time_usec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_node_list (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD(CC) Message Format
The NORM common message header and standard NORM_CMD fields serve
their usual purposes.
The "reserved" field is for potential future use and should be set to
ZERO in this version of the NORM protocol.
The "cc_sequence" field is a sequence number applied by the sender.
For NORM-CC operation, it is used to provide functionality equivalent
to the "feedback round number" (fb_nr)described in [19]. The most
recently received "cc_sequence" value is recorded by receivers and
can be fed back to the sender in congestion control feedback
generated by the receivers for that sender. The "cc_sequence" number
can also be used in NORM implementations to assess how recently a
receiver has received NORM_CMD(CC) probes from the sender. This can
be useful instrumentation for complex or experimental multicast
routing environments.
The "send_time" field is a timestamp indicating the time that the
NORM_CMD(CC) message was transmitted. This consists of a 64-bit
field containing 32-bits with the time in seconds ("send_time_sec")
and 32-bits with the time in microseconds ("send_time_usec") since
some reference time the source maintains (usually 00:00:00, 1 January
1970). The byte ordering of the fields is "Big Endian" network
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
their response as the "grtt_response" portion of NORM_ACK and
NORM_NACK messages generated. This allows the sender to evaluate
round-trip times to different receivers for congestion control and
other (e.g., GRTT determination) purposes.
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
group of the sender’s current transmission rate. This is used along
with the loss detection "sequence" field of all NORM sender messages
and the NORM_CMD(CC) GRTT collection process to support NORM-CC
congestion control operation. The format of this header extension 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| het = 128 | reserved | send_rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM-CC Rate Header Extension Format (EXT_RATE)
The "send_rate" field indicates the sender’s current transmission
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
base 10 exponent (order of magnitude) information in the least
significant portion. The 12-bit mantissa portion of the field is
scaled such that a floating point value of 0.0 corresponds to 0 and a
floating point value of 10.0 corresponds to 4096. Thus:
send_rate = (((int)(Value_mantissa * 4096.0 / 10.0 + 0.5)) << 4) |
Value_exponent;
For example, to represent a transmission rate of 256kbps (3.2e+04
bytes per second), the lower 4 bits of the 16-bit field contain a
value of 0x04 to represent the exponent while the upper 12 bits
contain a value of 0x51f as determined from the equation given above:
send_rate = (((int)((3.2 * 4096.0 / 10.0) + 0.5)) << 4) | 4;
= (0x51f << 4) | 0x4
= 0x51f4
To decode the "send_rate" field, the following equation can be used:
value = (send_rate >> 4) * 10.0 / 4096.0 *
power(10.0, (send_rate & x000f))
Note the maximum transmission rate that can be represented by this
scheme is approximately 9.99e+15 bytes per second.
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
extension also implies that NORM receivers should respond according
to the procedures described in Section 5.5.2. The "cc_node_list"
consists of a list of NormNodeIds and their associated congestion
control status. This includes the current limiting receiver (CLR)
node, any potential limiting receiver (PLR) nodes that have been
identified, and some number of receivers for which congestion control
status is being provided, most notably including the receivers’
current RTT measurement. The maximum length of the "cc_node_list"
provides for at least the CLR and one other receiver, but may be
configurable for more timely feedback to the group. The list length
can be inferred from the length of the NORM_CMD(CC) message.
Each item in the "cc_node_list" is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_flags | cc_rtt | cc_rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Congestion Control Node List Item Format
The "cc_node_id" is the NormNodeId of the receiver which the item
represents.
The "cc_flags" field contains flags indicating the congestion control
status of the indicated receiver. The following flags are defined:
+------------------+-------+------------------------------------------+
| Flag | Value | Purpose |
+------------------+-------+------------------------------------------+
|NORM_FLAG_CC_CLR | 0x01 | Receiver is the current limiting |
| | | receiver (CLR). |
+------------------+-------+------------------------------------------+
|NORM_FLAG_CC_PLR | 0x02 | Receiver is a potential limiting |
| | | receiver (PLR). |
+------------------+-------+------------------------------------------+
|NORM_FLAG_CC_RTT | 0x04 | Receiver has measured RTT with respect |
| | | to sender. |
+------------------+-------+------------------------------------------+
|NORM_FLAG_CC_START| 0x08 | Sender/receiver is in "slow start" phase |
| | | of congestion control operation (i.e., |
| | | The receiver has not yet detected any |
| | | packet loss and the "cc_rate" field is |
| | | the receiver’s actual measured receive |
| | | rate). |
+------------------+-------+------------------------------------------+
|NORM_FLAG_CC_LEAVE| 0x10 | Receiver is imminently leaving the |
| | | session and its feedback should not be |
| | | considered in congestion control |
| | | operation. |
+------------------+-------+------------------------------------------+
The "cc_rtt" contains a quantized representation of the RTT as
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
"cc_flags" field. This one byte field is a quantized representation
of the RTT using the algorithm described in the NORM Building Block
document [4]. The "cc_rate" field contains a representation of the
receiver’s current calculated (during steady-state congestion control
operation) or twice its measured (during the "slow start" phase)
congestion control rate. This field is encoded and decoded using the
same technique as described for the NORM_CMD(CC) "send_rate" field.
4.2.3.5. NORM_CMD(REPAIR_ADV) Message
The NORM_CMD(REPAIR_ADV) message is used by the sender to "advertise"
its aggregated repair state from NORM_NACK messages accumulated
during a repair cycle and/or congestion control feedback received.
This message is sent only when the sender has received NORM_NACK
and/or NORM_ACK(CC) (when congestion control is enabled) messages via
unicast transmission instead of multicast. By "echoing" this
information to the receiver set, suppression of feedback can be
achieved even when receivers are unicasting that feedback instead of
multicasting it among the group [13].
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 = 5 | flags | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| repair_adv_payload |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD(REPAIR_ADV) Message Format
The "instance_id", "grtt", "backoff", "gsize", and "flavor" fields
serve the same purpose as in other NORM_CMD messages. The value of
the "hdr_len" field when no extensions are present is 4.
The "flags" field provide information on the NORM_CMD(REPAIR_ADV)
content. There is currently one NORM_CMD(REPAIR_ADV) flag defined:
NORM_REPAIR_ADV_FLAG_LIMIT = 0x01
This flag is set by the sender when it is unable to fit its full
current repair state into a single NormSegmentSize. If this flag is
set, receivers should limit their NACK response to generating NACK
content only up through the maximum ordinal transmission position
(objectId::fecPayloadId) included in the "repair_adv_content".
When congestion control operation is enabled, a header extension may
be applied to the NORM_CMD(REPAIR_ADV) representing the most limiting
(in terms of congestion control feedback suppression) congestion
control response. This allows the NORM_CMD(REPAIR_ADV) message to
suppress receiver congestion control responses as well as NACK
feedback messages. The field is defined as a header extension so
that alternative congestion control schemes may be used with NORM
without revision to this document. A NORM-CC Feedback Header
Extension (EXT_CC) is defined to encapsulate congestion control
feedback within NORM_NACK, NORM_ACK, and NORM_CMD(REPAIR_ADV)
messages. If another congestion control technique (e.g., Pragmatic
General Multicast Congestion Control (PGMCC) [20]) is used within a
NORM implementation, an additional header extension MAY need to be
defined to encapsulate any required feedback content. The NORM-CC
Feedback Header Extension format is:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| het = 3 | hel = 3 | cc_sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_flags | cc_rtt | cc_loss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_rate | cc_reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM-CC Feedback Header Extension (EXT_CC) Format
The "cc_sequence" field contains the current greatest "cc_sequence"
value receivers have received in NORM_CMD(CC) messages from the
sender. This information assists the sender in congestion control
operation by providing an indicator of how current ("fresh") the
receiver’s round-trip measurement reference time is and whether the
receiver has been successfully receiving recent congestion control
probes. For example, if it is apparent the receiver has not been
receiving recent congestion control probes (and thus possibly other
messages from the sender), the sender may choose to take congestion
avoidance measures. For NORM_CMD(REPAIR_ADV) messages, the sender
SHALL set the "cc_sequence" field value to the value set in the last
NORM_CMD(CC) message sent.
The "cc_flags" field contains bits representing the receiver’s state
with respect to congestion control operation. The possible values
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
controlling (suppressing as necessary) their congestion control
feedback. For NORM_CMD(REPAIR_ADV) messages, the NORM_FLAG_CC_RTT
should be set only when all feedback messages received by the sender
have the flag set. Similarly, the NORM_FLAG_CC_CLR or
NORM_FLAG_CC_PLR should be set only when no feedback has been
received from non-CLR or non-PLR receivers. And the
NORM_FLAG_CC_LEAVE should be set only when all feedback messages the
sender has received have this flag set. These heuristics for setting
the flags in NORM_CMD(REPAIR_ADV) ensure the most effective
suppression of receivers providing unicast feedback messages.
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
received RTT measurement information. When a receiver has received
RTT measurement information, it shall set the "cc_rtt" value
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 "cc_rtt"
field value to the largest non-CLR/non-PLR RTT it has measured from
receivers for the current feedback round.
The "cc_loss" field represents the receiver’s current packet loss
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
packet loss. The 16-bit "cc_loss" value is calculated by the
following formula:
"cc_loss" = decimal_loss_fraction * 65535.0
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
received from receivers for the current feedback round.
The "cc_rate" field represents the receivers current local congestion
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
the corresponding sender and the NORM_FLAG_CC_START is set in the
"cc_flags’ field. Otherwise, the receiver calculates a congestion
control rate based on its loss measurement and RTT measurement
information (even if default) for the "cc_rate" field. For
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
received from receivers for the current feedback round.
The "cc_reserved" field is reserved for future NORM protocol use.
Currently, senders SHALL set this field to ZERO, and receivers SHALL
ignore the content of this field.
The "repair_adv_payload" is in exactly the same form as the
"nack_content" of NORM_NACK messages and can be processed by
receivers for suppression purposes in the same manner, with the
exception of the condition when the NORM_REPAIR_ADV_FLAG_LIMIT is
set.
4.2.3.6. NORM_CMD(ACK_REQ) Message
The NORM_CMD(ACK_REQ) message is used by the sender to request
acknowledgment from a specified list of receivers. This message is
used in providing a lightweight positive acknowledgment mechanism
that is OPTIONAL for use by the reliable multicast application. A
range of acknowledgment request types is provided for use at the
application’s discretion. Provision for application-defined,
positively-acknowledged commands allows the application to
automatically take advantage of transmission and round-trip timing
information available to the NORM protocol. The details of the NORM
positive acknowledgment process including transmission of the
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)
message is:
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 = 6 | reserved | ack_type | ack_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| acking_node_list |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD(ACK_REQ) Message Format
The NORM common message header and standard NORM_CMD fields serve
their usual purposes. The value of the "hdr_len" field for
NORM_CMD(ACK_REQ) messages with no header extension present is 4.
The "ack_type" field indicates the type of acknowledgment being
requested and thus implies rules for how the receiver will treat this
request. The following "ack_type" values are defined and are also
used in NORM_ACK messages described later:
+---------------------+--------+---------------------------------+
| ACK Type | Value | Purpose |
+---------------------+--------+---------------------------------+
|NORM_ACK_CC | 1 | Used to identify NORM_ACK |
| | | messages sent in response to |
| | | NORM_CMD(CC) messages. |
+---------------------+--------+---------------------------------+
|NORM_ACK_FLUSH | 2 | Used to identify NORM_ACK |
| | | messages sent in response to |
| | | NORM_CMD(FLUSH) messages. |
+---------------------+--------+---------------------------------+
|NORM_ACK_RESERVED | 3-15 | Reserved for possible future |
| | | NORM protocol use. |
+---------------------+--------+---------------------------------+
|NORM_ACK_APPLICATION | 16-255 | Used at application’s |
| | | discretion. |
+---------------------+--------+---------------------------------+