3 - 4 - 6 - 8 - A - B - C - D - E - F - G - H - I - J - L - M - N - O - P - Q - R - S - T - U - V - W
receiver
Click on the red underlined text to get to the source
... multicast session participation with minimal coordination
among senders and receivers. NORM allows senders and receivers ...
... protocol message
headers contain some common information allowing receivers to easily
synchronize to senders throughout the lifetime ...
... sender transmitting bulk data content to a group of receivers.
However, the protocol MAY operate with multiple senders within the
...
... protocol, it is anticipated that multiple senders will transmit
independent of one another and receivers will maintain state as
necessary for each sender ...
... NORM_OBJECT_FILE is
simply to provide a "hint" to receivers in NormSessions serving
multiple types of content as to what type of storage should be
allocated for received content (i.e., memory or file storage ...
... of the Transmission Control Protocol (TCP), although NORM receivers
will be able to begin receiving stream ...
... sender. This readily-available "out-of-
band" data allows multicast receivers to quickly and efficiently
determine the nature of the corresponding data, file, or stream bulk
...
... content being transmitted. This allows application-level control of
the receiver node's participation in the current transport activity.
...
... This also allows the protocol to be flexible with minimal pre-
coordination among senders and receivers. The NORM_INFO content is
designed to be atomic in that its size MUST fit into the payload ...
... in an efficient manner. Other similar protocol control mechanisms
(e.g., session termination, receiver synchronization, etc.) are
specified so that reliable multicast application variants may
...
... FEC content in
response to NACK messages received from the receiver group.
Mechanisms for "out-of-band ...
... scalability is the volume of feedback traffic
generated by the receiver set to facilitate reliability and
congestion control ...
... NORM protocol will readily scale to group
sizes on the order of tens of thousands of receivers. A study of the
quantity of feedback for this type of protocol is described in [13].
...
... single TCP connection, even with relatively large numbers of
receivers. Thus, depending upon the network topology, it is possible
that NORM ...
... NORM protocol does _not_ require that state be
kept on all receivers in the group. NORM senders maintain state ...
... NORM senders maintain state only
for receivers providing explicit congestion control feedback. NORM
receivers must maintain state ...
... for receivers providing explicit congestion control feedback. NORM
receivers must maintain state for each active sender ...
... NORM can make use of reciprocal (among senders and
receivers) multicast communication under the Any-Source Multicast
...
... A NormSession is comprised of participants (NormNodes) acting as
senders and/or receivers. NORM senders transmit data content in the
form of NormObjects to the session ...
... form of NormObjects to the session destination address and the NORM
receivers attempt to reliably receive the transmitted content using
negative acknowledgments to request repair. Each NormNode within a
...
... senders and to distinguish feedback information from different
receivers. There are two reserved NormNodeId values. A value of
0x00000000 is considered an invalid NormNodeId value and a value of
0xffffffff is a "wildcard ...
... segments of the stream to the
receiver application. In either case, NORM sender and receiver
...
... receiver application. In either case, NORM sender and receiver
implementations provide buffering to facilitate repair of the stream ...
... FEC encoding parity content. In this case, the
receiver must receive a sufficient number of symbols to reconstruct
(via FEC decoding) the original user data ...
... transferred. By default, redundant FEC symbols are sent only in
response to receiver repair requests (NACKs) and thus normally little
or no additional transmission overhead ...
... satellite, cable) [15] with reduced
receiver feedback, or, in some cases, no feedback.
A sender message ...
... serve special purposes for some bulk transfer, reliable multicast
applications where receivers join the group mid-stream ...
... congestion control, end-of-
transmission flushing, round trip time estimation, receiver
synchronization, and optional positive acknowledgment requests or
application defined commands. The transmission of NORM_CMD ...
... NORM_NACK messages are generated to request repair of detected data
transmission losses. Receivers generally detect losses by tracking
the sequence of transmission from a sender. Sequencing information
...
... order to meet potential application requirements for positive
acknowledgment from receivers, other NORM_ACK messages are defined
...
... NORM_ACK messages are defined
and available for use. All sender and receiver transmissions are
subject to rate control governed by a peak transmission rate ...
... governed by any buffer constraints of the sender and receiver
applications. NORM protocol implementations SHOULD be designed to
...
... This is because NORM feedback suppression is based upon randomly-
delayed transmissions from the receiver set, rather than immediately
transmitted feedback. There are definitive tradeoffs between buffer
...
... NORM_CMD(FLUSH) | Sender command to excite receivers for repair |
| | requests in lieu of ongoing NORM_DATA |
...
... | | unicast feedback messages are detected. Used |
| | to control/suppress excessive receiver |
| | feedback in asymmetric multicast topologies ...
... |NORM_NACK | Receiver message used to request repair of |
| | missing transmitted content. |
+--------------------+-----------------------------------------------+
...
... |NORM_ACK | Receiver message used to proactively provide |
| | feedback for congestion control purposes. |
...
... NORM_NACK
or other feedback messages. In this case, the receiver node should
maintain a monotonically increasing "sequence" field space for each
...
... Object
Transmission Information (EXT_FTI) header extension. This allows
NORM receivers to automatically allocate resources and properly
perform FEC decoding without the need for pre-configuration ...
... NORM_OBJECT_FILE and NORM_OBJECT_DATA, these fields are unnecessary
since the receiver can calculate the payload length and offset
information from the "fec_payload ...
... sender to
uniquely identify its current instance of participation in the
NormSession. This allows receivers to detect when senders have
perhaps left and rejoined a session ...
... sender
(identified by its "source_id") is detected to have a new
"instance_id", the NORM receivers SHOULD drop their previous state on
the sender ...
... 4].
The "backoff" field value is used by receivers to determine the
maximum backoff timer value used in the timer ...
... sender GRTT to determine the maximum
backoff timeout. The "backoff" field informs the receiver set of the
sender's backoff factor parameter "Ksender". Recommended values and
...
... sender's backoff factor parameter "Ksender". Recommended values and
their use are described in the NORM receiver NACK procedure
description in Section 5.3. The "gsize" field contains a
...
... The "flags" field contains a number of different binary flags
providing information and hints regarding how the receiver should
handle the identified object. Defined flags in this field include:
...
... NORM_FLAG_EXPLICIT | 0x02 | Indicates a repair segment intended to |
| | | meet a specific receiver erasure, as |
| | | compared to parity segments provided by |
...
... NORM_FLAG_REPAIR is set when the associated message is a repair
transmission. This information can be used by receivers to help
observe a join policy where it is desired that newly joining
...
... observe a join policy where it is desired that newly joining
receivers only begin participating in the NACK process upon receipt
...
... NORM_INFO
content is actually available for the associated object. Thus,
receivers will NACK for retransmission of NORM ...
... sender wishes to transmit an object with only "best effort" delivery
and will not supply repair transmissions for the object. NORM
receivers SHOULD NOT execute repair requests for objects marked with
the NORM_FLAG_UNRELIABLE flag. Note that receivers ...
... NORM
receivers SHOULD NOT execute repair requests for objects marked with
the NORM_FLAG_UNRELIABLE flag. Note that receivers may inadvertently
request repair of such objects when all segments (or info content)
...
... NORM
stream. This allows NORM receiver applications to "synchronize" with
NORM senders and to be able to properly interpret application layer ...
... bit field size provides
an adequate enough sequence space to avoid object confusion amongst
receivers and sources (i.e., receivers SHOULD re-synchronize with a
server when receiving ...
... an adequate enough sequence space to avoid object confusion amongst
receivers and sources (i.e., receivers SHOULD re-synchronize with a
server when receiving object sequence identifiers ...
... segments in the identified coding block. Given the
"source_block_len" information of how many symbols of application
data are contained in the block, the receiver can determine whether
the attached segment is data or parity content and treat it
...
... useful for the sender to include this information "in band" to
facilitate receiver operation with minimal preconfiguration. For
this purpose, the NORM FEC ...
... NORM_OBJECT_FILE and
NORM_OBJECT_DATA. This information is used by receivers to determine
storage requirements and/or allocate storage for the received object.
...
... storage requirements and/or allocate storage for the received object.
Receivers with insufficient storage capability may wish to forego
reliable reception (i.e., not NACK ...
... to the receiver group. In turn, the receivers SHOULD use this
information to allocate a stream buffer ...
... sender's current setting for maximum message payload
content (in bytes). This allows receivers to allocate appropriate
buffering resources and to determine other information in order to
...
... sender during
the session. This allows receivers to allocate appropriate buffer
space for buffering ...
... object into the NORM_INFO payload. Receivers may use the NORM_INFO
content to make a decision as whether to participate in reliable
...
... contain a flag to indicate the availability of NORM_INFO for a given
NormObject. NORM receivers may NACK for retransmission of NORM ...
... NORM_DATA messages. These values allow the
receiver to prepare appropriate buffering, etc, for further
transmissions from the sender ...
... payload_data" field contains sender application-
defined content which can be used by receiver applications for
various purposes as described above.
...
... | | | (Assists in robustly initiating |
| | | outstanding repair requests from|
| | | receivers). May also be |
| | | optionally used to collect |
| | | positive acknowledgment of |
...
... | | | positive acknowledgment of |
| | | reliable reception from subset |
| | | of receivers. |
+----------------------+-------------+---------------------------------+
|NORM ...
... range NACKs |
| | | from receivers. |
+----------------------+-------------+---------------------------------+
|NORM ...
... | | | for suppression of unicast |
| | | feedback from receivers. |
+----------------------+-------------+---------------------------------+
|NORM ...
... ACK_REQ) | 6 | Used to request application- |
| | | defined positive acknowledgment |
| | | from a list of receivers |
| | | (OPTIONAL). |
+----------------------+-------------+---------------------------------+
...
... GRTT to excite the
receiver set for any outstanding repair requests up to and including
the transmission point indicated within the NORM_CMD ...
... The number of repeats is equal to NORM_ROBUST_FACTOR unless a list of
receivers from which explicit positive acknowledgment is expected
("acking_node_list") is given. In that case, the "acking_node ...
... greater the NORM_ROBUST_FACTOR, the greater the probability that all
applicable receivers will be excited for acknowledgment or repair
requests (NACKs) _and_ that the corresponding NACKs ...
... transmissions are completed.
Note that receivers also employ a timeout mechanism to self-initiate
NACKing (if there are outstanding repair needs) when no messages of
any type are received from a sender ...
... NORM_CMD(FLUSH) transmissions and a longer timeout for receivers to
self-initiate the terminal NACK ...
... 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,
they SHALL initiate the NORM ...
... NORM NACK Repair Process as described in
Section 5.3. If receivers have no outstanding repair needs, no
response to the NORM_CMD ...
... NORM_OBJECT_STREAM objects using systematic FEC codes, receivers
MUST request "explicit-only" repair of the identified
"source_block_number" if the given "encoding ...
... stream transmission and passes the end of the pending coding
block, subsequent NACKs from receivers SHALL request parity-based
repair as usual. Note that the use of a systematic FEC code is
...
... repair as usual. Note that the use of a systematic FEC code is
assumed here. Normal receiver NACK initiation and construction is
discussed in detail ...
... discussed in detail in Section 5.3. The OPTIONAL "acking_node_list"
field contains a list of NormNodeIds for receivers from which the
sender is requesting explicit positive acknowledgment of reception up
...
... sender reaches permanent
end-of-transmission with respect to the NormSession and will not
respond to further repair requests. This allows receivers to
gracefully reach closure of operation with this sender (without
...
... NORM_CMD(FLUSH) commands to provide a
high assurance of reception by the receiver set.
0 1 2 3
...
... header extensions present is 4. The "reserved" field is reserved for
future use and MUST be set to an all ZERO value. Receivers MUST
ignore the "reserved" field.
...
... sender previously transmitted marked with the
NORM_FLAG_UNRELIABLE flag. This command indicates to receivers what
content is available for repair, thus serving as a description of the
sender ...
... content is available for repair, thus serving as a description of the
sender's current "repair window". Receivers SHALL not generate
repair requests for content identified as invalid by a
NORM ...
... CMD(SQUELCH) will be
needed infrequently, and generally only to provide a reference repair
window for receivers who have fallen "out-of-sync" with the sender
due to extremely poor network conditions ...
... of the squelch. The length of the list is limited by the sender's
NormSegmentSize. This allows the receivers to learn the status of
the sender's applicable object repair window with minimal
...
... payload_id" field. This
serves as an advertisement of a "synchronization point" for receivers
to request repair. Note, that while an "encoding_symbol_id" may be
...
... CC) messages contains fields to enable sender-to-
receiver group greatest round-trip time (GRTT ...
... 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 ...
... sender in congestion control feedback
generated by the receivers for that sender. The "cc_sequence" number
can also be used in NORM ...
... can also be used in NORM implementations to assess how recently a
receiver has received NORM_CMD(CC ...
... byte ordering of the fields is "Big Endian" network
order. Receivers use this timestamp adjusted by the amount of delay
...
... sender to evaluate
round-trip times to different receivers for congestion control and
other (e.g., GRTT ...
... 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"
...
... node_list"
consists of a list of NormNodeIds and their associated congestion
control status. This includes the current limiting receiver (CLR)
node ...
... PLR) nodes that have been
identified, and some number of receivers for which congestion control
status is being provided, most notably including the receivers ...
... receivers for which congestion control
status is being provided, most notably including the receivers'
current RTT measurement. The maximum length of the "cc_node ...
... 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
...
... The "cc_flags" field contains flags indicating the congestion control
status of the indicated receiver. The following flags are defined:
+------------------+-------+------------------------------------------+
...
... CLR | 0x01 | Receiver is the current limiting |
| | | receiver (CLR). |
+------------------+-------+------------------------------------------+
...
... PLR | 0x02 | Receiver is a potential limiting |
| | | receiver (PLR). |
+------------------+-------+------------------------------------------+
...
... | | | of congestion control operation (i.e., |
| | | 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 |
| | | rate). |
+------------------+-------+------------------------------------------+
...
... |NORM_FLAG_CC_LEAVE| 0x10 | Receiver is imminently leaving the |
| | | session and its feedback should not be |
...
... RTT as
measured by the sender with respect to the indicated receiver. This
field is valid only if the NORM ...
... document [4]. The "cc_rate" field contains a representation of the
receiver's current calculated (during steady-state congestion control
...
... 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
...
... 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 ...
... current repair state into a single NormSegmentSize. If this flag is
set, receivers should limit their NACK response to generating NACK
...
... NORM_CMD(REPAIR_ADV) message to
suppress receiver congestion control responses as well as NACK
...
...
The "cc_sequence" field contains the current greatest "cc_sequence"
value receivers have received in NORM_CMD(CC ...
... congestion control
operation by providing an indicator of how current ("fresh") the
receiver's round-trip measurement reference time is and whether the
receiver ...
... receiver's round-trip measurement reference time is and whether the
receiver has been successfully receiving recent congestion control
...
... congestion control
probes. For example, if it is apparent the receiver has not been
receiving recent congestion control ...
...
The "cc_flags" field contains bits representing the receiver's state
with respect to congestion control ...
... CC)
message node list item flags. These fields are used by receivers in
controlling (suppressing as necessary) their congestion control
...
... NORM_CMD(REPAIR_ADV) ensure the most effective
suppression of receivers providing unicast feedback messages.
...
... NORM_FLAG_CC_RTT flag SHALL be cleared when no receiver has yet
received RTT measurement information. When a receiver ...
... receiver has yet
received RTT measurement information. When a receiver has received
RTT measurement information, it shall set the "cc_rtt" value
...
... PLR RTT it has measured from
receivers for the current feedback round.
The "cc_loss" field represents the receiver ...
... 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
...
... CLR/non-PLR loss estimate it has
received from receivers for the current feedback round.
The "cc_rate" field represents the receivers ...
... receivers for the current feedback round.
The "cc_rate" field represents the receivers current local congestion
control rate. During "slow start", when the receiver ...
... 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 ...
... 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
...
... 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 ...
... NORM protocol use.
Currently, senders SHALL set this field to ZERO, and receivers SHALL
ignore the content of this field.
...
... 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
...
... 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 ...
...
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_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 "acking_node_list" field contains the NormNodeIds of the current
NORM receivers that are desired to provide positive acknowledge
(NORM_ACK ...
... in network (Big Endian) byte order. If a receiver's NormNodeId is
included in the "acking_node_list", it SHALL schedule transmission of
...
... Receiver Messages ...
... principal purpose of NORM_NACK messages is for receivers to
request repair of sender content via selective, negative
acknowledgment ...
... CC) "send_time" timestamp by adding the
time differential from when the receiver received the NORM_CMD(CC ...
... 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 ...
... to NORM_NACK messages to provide feedback on the receivers current
state with respect to congestion control operation. Note that
...
... NORM_NACK message specifies the repair
needs of the receiver with respect to the NORM sender indicated by
the "server_id" field. The receiver ...
... 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 ...
... 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 ...
... segments are needed to repair content at the
receiver. When the NORM_NACK_BLOCK flag is set, this indicates 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 ...
... NORM_NACK_INFO flag is set, this indicates
the receiver is missing the NORM_INFO segment for the indicated
...
... NORM_NACK_OBJECT flag is set, this
indicates the receiver is missing the entire NormTransportObject
referenced by the "object_transport_id". This also implicitly
...
... field value.
When the receiver's repair needs dictate that different forms (mixed
ranges and/or individual items) or types (mixed specific segments ...
... 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 ...
... transport_id" and "fec_payload_id" are used by the
receiver to acknowledge applicable NORM_CMD(FLUSH) messages
...
... NORM participants. This
message could be used for periodic performance reports from receivers
in experimental NORM ...
... This section describes the detailed interactions of senders and
receivers participating in a NORM session. A simple synopsis of
...
... to initialize and collect roundtrip timing and congestion control
feedback from the receiver set.
2) The sender ...
... transport objects.
3) As receivers detect missing content from the sender, they initiate
repair requests with NORM ...
... repair requests with NORM_NACK messages. Note the receivers track
the sender's most recent objectId::fecPayloadId transmit position
...
... and NACK _only_ for content ordinally prior to that transmit
position. The receivers schedule random backoff timeouts before
generating NORM_NACK ...
...
4) The sender aggregates repair requests from the receivers and
logically "rewinds" its transmit position to send appropriate
repair messages. The sender ...
... NORM_CMD(FLUSH) messages when it reaches the
end of enqueued transmit content and pending repairs. Receivers
respond to the NORM_CMD ...
... sender may
wish to defer data transmission until it has received some feedback
or request from the receiver set indicating that receivers are indeed
present. Note, in some applications (e.g., web push), this
...
... wish to defer data transmission until it has received some feedback
or request from the receiver set indicating that receivers are indeed
present. Note, in some applications (e.g., web push), this
indication may come out-of-band ...
... sender message
headers can contain all information necessary to prepare receivers
for subsequent reliable reception. This includes FEC coding
...
... sender NormSegmentSize, and other information. If
this header extension is not used, it is presumed that receivers have
received the FEC Object Transmission Information ...
... being transmitted. These mechanisms allow for operation with minimal
pre-coordination among the senders and receivers.
The NORM sender ...
... 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 ...
... NORM_CMD(FLUSH) messages at a rate of one per 2*GRTT. Receivers may
respond to these NORM_CMD ...
... requests. 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 ...
... to NORM_CMD(FLUSH) containing the NormNodeIds for receivers from
which it expects explicit positive acknowledgment of reception. The
NORM ...
... source block size (number of source symbols per coding block). NORM
senders and receivers use these FEC parameters, along with the
NormSegmentSize and transport ...
... Receiver Initialization and Reception ...
... the group at will. However, some applications may be constrained
such that receivers need to be members of the group prior to start of
...
... data transmission. NORM applications may use different policies to
constrain the impact of new receivers joining the group in the middle
of a session ...
... of a session. For example, a useful implementation policy is for new
receivers joining the group to limit or avoid repair requests for
transport ...
... implementation may wish to impose additional constraints to limit the
ability of receivers to disrupt reliable multicast performance by
...
... performance by
joining, leaving, and rejoining the group often. Different receiver
"join policies" may be appropriate for different applications and/or
...
... join policies" may be appropriate for different applications and/or
scenarios. For general purpose operation, 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
...
... STREAM it is RECOMMENDED that the join policy constrain
receivers to start reliable reception at the current FEC coding block
...
... 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 (Ksender-
1)*GRTTsender. Otherwise, the backoff period is entered and the
receiver MUST accumulate external pending repair state from NORM_NACK ...
... NORM_CMD(REPAIR_ADV) messages received. At the end of
the backoff time, the receiver SHALL generate a NORM_NACK message
...
... sender's current transmit position (in terms of
objectId::fecPayloadId) exceeds the earliest repair position of
the receiver.
2) The repair state ...
... NORM_CMD(REPAIR_ADV) messages do not equal or supersede the
receiver's repair needs up to the sender transmission position at
the time the NACK ...
... NACK procedure (backoff timeout) was initiated.
If these conditions are met, the receiver immediately generates a
NORM_NACK ...
... 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 ...
... 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 reinitiate the NACKing
process. The purpose of this timeout is to allow the sender ...
... 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 [4 ...
... NORM_NACK message contains repair request content beginning with
lowest ordinal repair position of the receiver up through the coding
block prior to the most recently heard ordinal transmission position
for the sender ...
... sender's NormSegmentSize, the NACK content is truncated so that the
receiver only generates a single NORM_NACK message per NACK ...
... sender. In summary, a single NACK message is generated
containing the receiver's lowest ordinal repair needs.
For each partially-received FEC ...
... 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
...
... 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
...
... sender may have provided other
different, additional parity segments for other receivers that could
also be used to satisfy the local receiver's erasure-filling needs.
...
... 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
...
... 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 ...
... segments
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
common denominator set of repair symbols for a given FEC coding
...
... segment set and enables effective NACK suppression among
the receivers even with uncorrelated packet loss. This approach also
requires no synchronization ...
... packet loss. This approach also
requires no 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
...
... sender must occasionally "rewind" its logical transmission point to
satisfy the repair needs of receivers who have NACKed. Aggregation
of multiple NACKs ...
... 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
...
... on coding block or object boundaries, there is some loose degree of
synchronization of the repair process even when receivers experience
uncorrelated data loss.
...
...
where "Ksender" is the same backoff scaling value used by the
receivers, and "GRTT" is the sender's current estimate of the group ...
... arrival of a NACK) in concert with the pending repair and new data
transmission. Recall that receivers are not to initiate the NACK
repair process until the sender ...
... FEC parity content
for repair to the greatest extent possible. Recall that the
receivers use a strategy to request a lowest common denominator of
explicit repair (including parity content) in the formation of their
NORM ...
... 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 ...
... coding blocks, the sender can transmit these in lieu of the specific
packets the receiver set has requested. Only after exhausting its
supply of "fresh" (unsent) parity segments for a given coding block
...
... segments for a given coding block
should the sender resort to explicit transmission of the receiver
set's repair needs. In general, if a sufficiently powerful FEC code
...
... DATA messages sent as repair transmissions SHALL be flagged with
the NORM_FLAG_REPAIR flag. This allows receivers to obey any
policies that limit new receivers from joining the reliable
...
... NORM_FLAG_REPAIR flag. This allows receivers to obey any
policies that limit new receivers from joining the reliable
transmission when only repair transmissions have been received.
Additionally, the sender ...
...
Although NORM end system receivers do not make use of the
NORM_FLAG_EXPLICIT flag, this message transmission status could be
...
... NORM_CMD(SQUELCH)
message to advertise its repair window and squelch any receivers from
additional NACKing of invalid data. The transmission rate ...
... 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 ...
... state to the receiver set since the
receiver set is not directly sharing their repair needs via multicast
communication. The NORM ...
... CMD(REPAIR_ADV) message is multicast to the
receiver set by the sender. The payload portion of this message has
...
... receiver message payload.
Receivers are then able to perform feedback suppression in the same
manner as with NORM_NACK ...
... NORM_NACK messages directly received from other
receivers. Note the sender does not merely retransmit NACK content
...
... NORM_CMD(REPAIR_ADV) message is of maximum
size, receivers SHALL consider the maximum ordinal transmission
position value embedded in the message as the senders "current"
...
... need to provide information so that dynamic congestion control
feedback can be suppressed as needed among receivers. This document
specifies the NORM-CC ...
...
For NORM receivers to appropriately scale backoff timeouts and the
senders to use proper corresponding timeouts, the participants must
...