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
NACK
Click on the red underlined text to get to the source
... provide for repair transmission of data and/or FEC content in
response to NACK messages received from the receiver group.
...
... requirements lead to adaptation of
negative acknowledgment (NACK) based protocol schemes when feedback
for reliability is required [9 ...
... 9]. NORM is a protocol centered around
the use of selective NACKs to request repairs of missing data. NORM
provides for the use of packet-level forward error correction ...
... multicast repair requests and
repair transmissions [11] in a NACK-oriented protocol. The principal
factor in NORM ...
... FEC symbols are sent only in
response to receiver repair requests (NACKs) and thus normally little
or no additional transmission overhead is imposed due to FEC ...
... stream and need to
ascertain contextual information on the current content being
transmitted. The NACK process for NORM_INFO will be described later.
When the NORM ...
... sender. The
NORM_NACK messages are generated to request repair of detected data
transmission losses. Receivers generally detect losses by tracking
...
... timer-based probabilistic suppression
techniques as for NORM_NACK messages to avoid feedback implosion. In
order to meet potential application requirements for positive
...
... +--------------------+-----------------------------------------------+
|NORM_NACK | Receiver message used to request repair of |
| | missing transmitted content. |
...
... protection from message "replay" attacks, particularly of NORM_NACK
or other feedback messages. In this case, the receiver node ...
... is also referred to as R_max in [19]). This value is used to control
timing of the NACK repair process and other aspects of protocol
operation as described in this document. The algorithm for encoding ...
... timer value used in the timer-based NORM NACK
feedback suppression. This 4-bit field supports values from 0-15
...
... 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
representation of the sender ...
... join policy where it is desired that newly joining
receivers only begin participating in the NACK process upon receipt
of new (non-repair) data content. NORM ...
... content is actually available for the associated object. Thus,
receivers will NACK for retransmission of NORM_INFO only when it is
...
... Receivers with insufficient storage capability may wish to forego
reliable reception (i.e., not NACK for) of the indicated object. In
the case of objects of type NORM_OBJECT_STREAM ...
... | | | current repair window in |
| | | response to out-of-range NACKs |
| | | from receivers. |
...
... applicable receivers will be excited for acknowledgment or repair
requests (NACKs) _and_ that the corresponding NACKs are delivered to
the sender ...
... receivers will be excited for acknowledgment or repair
requests (NACKs) _and_ that the corresponding NACKs are delivered to
the sender. If a NORM ...
... the sender. If a NORM_NACK message interrupts the flush process, the
sender will re-initiate the flush process after any resulting repair
...
... range,
they SHALL initiate the NORM NACK Repair Process as described in
Section 5.3. If receivers have no outstanding repair needs, no
...
... FEC block and parity content
is not yet available. An "explicit-only" repair request consists of
NACK content for the applicable "source_block_number" which does not
include any requests for parity-based repair. This allows NORM
sender applications to "flush" an ongoing stream ...
... resumes 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 ...
... FEC code is
assumed here. Normal receiver NACK initiation and construction is
discussed in detail in Section 5.3. The OPTIONAL "acking_node ...
... CMD(SQUELCH) command is transmitted in response to outdated
or invalid NORM_NACK content received by the sender. Invalid
NORM ...
... sender. Invalid
NORM_NACK content consists of repair requests for NormObjects for
which the sender is unable or unwilling to provide repair. This
...
... lowest invalid NormTransportId greater than the current "repair
window" start from the invalid NACK(s) that prompted the generation
of the squelch. The length of the list is limited by the sender's
...
... sender's current repair
window and an "invalid object list" beginning with the index of the
logically earliest invalid repair request from the offending NACK
message which initiated the squelch transmission.
...
... sender SHALL ensure that the list begins with a NormObjectId that
is greater than or equal to the lowest ordinal invalid NormObjectId
from the NACK message(s) that prompted the NORM_CMD(SQUELCH)
...
... sender's repair window. This insures convergence of the squelch
process, even if multiple invalid NACK/ squelch iterations are
required. This explicit description of invalid content within the
sender ...
... its aggregated repair state from NORM_NACK messages accumulated
during a repair cycle and/or congestion control feedback received.
...
... 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
...
... 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".
...
... suppress receiver congestion control responses as well as NACK
feedback messages. The field is defined as a header extension so
...
... 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
...
... NORM_ACK message types. NORM_NACK messages are sent
to request repair of missing data content from sender transmission
...
... sender content via selective, negative
acknowledgment upon detection of incomplete data. NORM_NACK messages
will be transmitted according to the rules of NORM_NACK ...
... NACK messages
will be transmitted according to the rules of NORM_NACK generation
and suppression described in Section 5.3. NORM_NACK ...
... NACK generation
and suppression described in Section 5.3. NORM_NACK messages also
contain additional fields to provide feedback to the sender(s) for
...
... The payload of NORM_NACK messages contains one or more repair
requests for different objects or portions of those objects. The
NORM ...
... requests for different objects or portions of those objects. The
NORM_NACK message format is as follows:
...
... message header fields serve their usual purposes.
The value of the "hdr_len" field for NORM_NACK messages without
header extensions present is 6.
...
... NORM sender to which the
NORM_NACK message is destined.
The "instance_id" field contains the current session identifier ...
...
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
...
... CMD(REPAIR_ADV} message description, is added
to NORM_NACK messages to provide feedback on the receivers current
state with respect to congestion control ...
...
The "nack_content" of the NORM_NACK message specifies the repair
needs of the receiver with respect to the NORM sender ...
... sender's
transmission position at the moment the receiver initiates the NACK
Procedure as described in Section 5.3. A single NORM Repair Request
...
... payload" field
of a NORM_NACK message. Note that a single NORM Repair Request can
possibly include multiple "items", "ranges ...
...
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 ...
... 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
...
... 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
...
... +------------------+-------+-----------------------------------------+
|NORM_NACK_SEGMENT | 0x01 | Indicates the listed segment(s) or range ...
... +------------------+-------+-----------------------------------------+
|NORM_NACK_BLOCK | 0x02 | Indicates the listed block(s) or range |
| | | of blocks in entirety are required as |
...
... +------------------+-------+-----------------------------------------+
|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 |
...
... 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 ...
... SEGMENT flags, or
may be set alone. When the NORM_NACK_OBJECT flag is set, this
indicates the receiver is missing the entire NormTransportObject
...
... segment being requested. When the
NORM_NACK_OBJECT flag is set, the value of the "fec_payload_id" field
is ignored. When the NORM ...
... payload_id" field
is ignored. When the NORM_NACK_BLOCK flag is set, only the FEC code
block identifier ...
... "form" and or "flags" values can be concatenated within a single
NORM_NACK message. Additionally, NORM receivers SHALL construct
NORM ...
... NORM receivers SHALL construct
NORM_NACK messages with their repair requests in ordinal order with
respect to "object_transport_id" and "fec_payload ...
... segments. In
Example 1, a list of individual NORM_NACK_ITEMS repair requests is
given. In Example 2, a list of NORM_NACK ...
... NACK_ITEMS repair requests is
given. In Example 2, a list of NORM_NACK_RANGES requests _and_ a
single NORM ...
... RANGES requests _and_ a
single NORM_NACK_ITEMS request are concatenated to illustrate the
possible content of a NORM_NACK ...
... 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 ...
... The "server_id", "instance_id", and "grtt_response" fields serve the
same purpose as the corresponding fields in NORM_NACK messages. And
header extensions may be applied to support congestion control ...
... sender, they initiate
repair requests with NORM_NACK messages. Note the receivers track
the sender ...
... 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
...
... receivers schedule random backoff timeouts before
generating NORM_NACK messages and wait an appropriate amount of
time before repeating the NORM_NACK ...
... NACK messages and wait an appropriate amount of
time before repeating the NORM_NACK if their repair request is not
satisfied.
...
... NORM_CMD(FLUSH) messages with NORM_NACK
transmissions (following the same suppression backoff timeout
strategy as for data) if they require further repair.
...
... congestion control purposes is governed
using a suppression mechanism similar to that for NORM_NACK
messages.
...
... collection can be used to establish a GRTT estimate prior to data
transmission and potential NACK operation.
In some cases, applications may wish for the sender ...
... FEC encoding blocks and symbols so
that appropriate NACKs can be constructed to request repair of
missing data. NORM FEC ...
... T_backoff = RandomBackoff(Ksender*GRTTsender, GSIZEsender)
To avoid the possibility of NACK implosion in the case of sender or
network ...
... 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
...
... the backoff time, the receiver SHALL generate a NORM_NACK message
only if the following conditions are met:
...
... 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 ...
... receiver immediately generates a
NORM_NACK message when the backoff timeout expires. Otherwise, the
receiver's NACK ...
... 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
...
...
The NORM_NACK message contains repair request content beginning with
lowest ordinal repair position of the receiver up through the coding
...
... for the sender. If the size of the NORM_NACK content exceeds the
sender's NormSegmentSize, the NACK ...
... NACK content exceeds the
sender's NormSegmentSize, the NACK content is truncated so that the
receiver only generates a single NORM ...
... receiver only generates a single NORM_NACK message per NACK cycle for
a given sender. In summary, a single NACK ...
... NACK cycle for
a given sender. In summary, a single NACK message is generated
containing the receiver's lowest ordinal repair needs.
...
... sender to construct the most efficient repair
transmission segment set and enables effective NACK suppression among
the receivers even with uncorrelated packet loss ...
... NACK_BLOCK or
NORM_NACK_OBJECT flags set as appropriate. The request for
retransmission of NORM ...
... NORM_INFO is accomplished by setting the
NORM_NACK_INFO flag in a corresponding repair request.
...
... receivers who have NACKed. Aggregation
of multiple NACKs is used to determine an optimal repair strategy
when a NACK ...
... NACKs is used to determine an optimal repair strategy
when a NACK event occurs. Since receivers initiate the NACK process
...
... when a NACK event occurs. Since receivers initiate the NACK process
on coding block or object boundaries, there is some loose degree of
synchronization ...
... state of transmitting new data and
receives a NACK, it begins a procedure to accumulate NACK repair
state ...
... transmitting new data and
receives a NACK, it begins a procedure to accumulate NACK repair
state from NORM ...
... state from NORM_NACK messages before beginning repair transmissions.
Note that this period of aggregating repair state does _not_
...
... aggregation cycle,
even if NORM_NACK messages arrive. As described in [4], the value of
this sender ...
...
If additional NORM_NACK messages are received during this sender
"holdoff" period, the sender ...
... sender will immediately incorporate these "late
messages" into its pending transmission state ONLY if the NACK
content is ordinally greater than the sender's current transmission
...
... group,
thus avoiding redundant repair transmissions. After the holdoff
timeout expires, a new NACK accumulation period can be begun (upon
arrival of a NACK) in concert with the pending repair and new data
...
... timeout expires, a new NACK accumulation period can be begun (upon
arrival of a NACK) in concert with the pending repair and new data
transmission. Recall that receivers are not to initiate the NACK ...
... 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'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
...
... 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 ...
... individual FEC coding blocks from the NORM_NACK messages received
during the repair aggregation period. Then, if the sender ...
... Additionally, the intermediate systems could perform additional
NORM_NACK suppression/aggregation as it conducts this repair state
...
... If the sender receives a NORM_NACK message for repair of data it is
no longer supporting, the sender generates a NORM ...
... 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 the sender ...
... receivers. Note the sender does not merely retransmit NACK content
it receives, but instead transmits a representation of its aggregated
repair state ...
... timestamp is embedded in the feedback
message (NORM_NACK or NORM_ACK). The adjustment adds the amount of
...
... GRTT feedback even if no
NORM_NACK messages are being sent. If operating without congestion
control in a closed network, the NORM ...
... GRTT measurement feedback when
NORM_NACK messages are generated since no NORM_ACK messages are
...
... 4]. The same backoff factor K = Ksender MAY be used as
with NORM_NACK suppression. However, in cases where the application
purposefully specifies a very small Ksender backoff factor to
minimize the NACK ...
... NACK suppression. However, in cases where the application
purposefully specifies a very small Ksender backoff factor to
minimize the NACK repair process latency (trading off group size
scalability), it may still be desirable to maintain a larger backoff
...
... congestion control feedback, since there may often be a
larger volume of congestion control feedback than NACKs in many cases
and congestion control feedback latency ...
...
3) When the T_backoff is greater than 1*GRTT. This prevents NACK
implosion in the event of sender or network ...
... interrupted in response to negative acknowledgment repair requests
(NACKs) received from receivers during the acknowledgment period.
The NORM ...
... watermark transmission point. All receivers SHALL interpret the
watermark point provided in the request NACK for repairs if needed as
for NORM_CMD ...
... IP multicast protocol implementation
may be generally subject to, the NACK-based feedback of NORM may be
exploited by replay attacks ...
... Adamson, B., Bormann, C., Handley, M., and J. Macker, "Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks", RFC 3941exp ...