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
sender
Click on the red underlined text to get to the source
... protocol is designed to provide reliable transport of data from one
or more sender(s) to a group of receivers over an IP multicast ...
... distributed multicast session participation with minimal coordination
among senders and receivers. NORM allows senders ...
... headers contain some common information allowing receivers to easily
synchronize to senders throughout the lifetime of a reliable
multicast session ...
... NORM protocol design is principally driven by the assumption of a
single sender transmitting bulk data content to a group of receivers ...
... group of receivers.
However, the protocol MAY operate with multiple senders within the
context of a single NormSession. In initial implementations of this
...
... context of a single NormSession. In initial implementations of this
protocol, it is anticipated that multiple senders will transmit
independent of one another and receivers will maintain state ...
... receivers will maintain state as
necessary for each sender. However, in future versions of NORM, it
...
... round-trip
time collection) may provide for alternate modes allowing more
efficient performance for applications requiring multiple senders.
NORM ...
... data (sent as NORM_INFO messages) to be attached to the data content
objects transmitted by the sender. This readily-available "out-of-
band" data allows multicast receivers ...
... transport activity.
This also allows the protocol to be flexible with minimal pre-
coordination among senders and receivers. The NORM_INFO content is
...
... transport identifiers
that are applicable only while the sender is transmitting and/or
repairing the given object. These transport ...
... identifiers
(NormTransportIds) are assigned in a monotonically increasing fashion
by each NORM sender during the course of a NormSession. Each sender
maintains its NormTransportId assignments independently so that
...
... (NormTransportIds) are assigned in a monotonically increasing fashion
by each NORM sender during the course of a NormSession. Each sender
maintains its NormTransportId assignments independently so that
individual NormObjects may be uniquely identified during transport ...
... sessions. The NORM
protocol provides mechanisms so that the sender application may
terminate transmission of data content and inform the group of this
...
... transport of
different types of data content (including potentially mixed types).
The senders enqueue and transmit bulk content in the form of static
data or files and/or non-finite, ongoing stream types. NORM senders ...
... senders enqueue and transmit bulk content in the form of static
data or files and/or non-finite, ongoing stream types. NORM senders
provide for repair transmission of data and/or FEC content in
...
... sender. In the case of unicast
feedback, the sender "advertises" the feedback state to the group to
...
... NORM
receivers must maintain state for each active sender. This may
constrain the number of simultaneous senders in some uses of NORM ...
... multicast distribution
if so desired. NORM can make use of reciprocal (among senders and
receivers) multicast ...
...
A NormSession is comprised of participants (NormNodes) acting as
senders and/or receivers. NORM senders transmit data content in the
...
... senders and/or receivers. NORM senders transmit data content in the
form of NormObjects to the session destination address ...
... identifiers
within a single NormSession to distinguish between possible multiple
senders and to distinguish feedback information from different
receivers. There are two reserved NormNodeId values. A value of
...
... 0xffffffff is a "wildcard" NormNodeId. While the protocol does not
preclude multiple sender nodes concurrently transmitting within the
...
... NORM session (i.e., many-to-many operation), any
type of interactive coordination among NORM senders is assumed to be
controlled by the application or higher protocol layer. There are
...
... NORM_OBJECT_DATA, which is used for static, persistent blocks of data
content maintained in the sender's application memory storage. The
second type is NORM_OBJECT_FILE, which corresponds to data stored in
...
... second type is NORM_OBJECT_FILE, which corresponds to data stored in
the sender's non-volatile file system. The NORM_OBJECT_DATA and
...
... stream to the
receiver application. In either case, NORM sender and receiver
implementations provide buffering ...
... All NormObjects are logically segmented into FEC coding blocks and
symbols for transmission by the sender. In NORM, an FEC encoding ...
... Transmitted NormObjects are temporarily yet uniquely identified
within the NormSession context using the given sender's NormNodeId,
NormInstanceId, and a temporary NormObjectTransportId. Depending
upon the implementation, individual NORM senders ...
... sender's NormNodeId,
NormInstanceId, and a temporary NormObjectTransportId. Depending
upon the implementation, individual NORM senders may manage their
NormInstanceIds independently, or a common NormInstanceId may be
agreed upon for all participating nodes ...
... NORM NormObjectTransportId data content
identifiers are sender-assigned and applicable and valid only during
a NormObject's actual _transport ...
... valid only during
a NormObject's actual _transport_ (i.e., for as long as the sender is
transmitting and providing repair of the indicated NormObject). For
...
...
A NORM sender primarily generates messages of type NORM_DATA. These
messages carry original data segments ...
... receiver feedback, or, in some cases, no feedback.
A sender message of type NORM_INFO is also defined and is used to
carry OPTIONAL "out-of-band ...
... NORM_CMD messages
from the sender is accomplished by one of three different procedures.
These procedures are: single, best effort unreliable transmission of
the command; repeated redundant transmissions of the command; and
...
... transmission losses. Receivers generally detect losses by tracking
the sequence of transmission from a sender. Sequencing information
is embedded in the transmitted data packets and end-of-transmission
...
... is embedded in the transmitted data packets and end-of-transmission
commands from the sender. NORM_ACK messages are generated in
...
... NORM_ACK messages are generated in
response to certain commands transmitted by the sender. In the
general (and most scalable) protocol mode, NORM_ACK messages ...
... ACK messages are sent
only in response to congestion control commands from the sender. The
feedback volume of these congestion control NORM ...
... 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 ...
... NORM's
congestion control algorithm is enabled the rate for senders is
automatically adjusted. In some networks, it may be desirable to
...
... governed by any buffer constraints of the sender and receiver
applications. NORM protocol implementations SHOULD be designed to
...
... +--------------------+-----------------------------------------------+
|NORM_DATA | Sender message for application data |
| | transmission. Implementations must support |
...
... |NORM_CMD(FLUSH) | Sender command to excite receivers for repair |
| | requests in lieu of ongoing NORM ...
... |NORM_CMD(SQUELCH) | Sender command to advertise its current valid |
| | repair window in response to invalid requests |
...
... |NORM_CMD(REPAIR_ADV)| Sender command to advertise current repair |
| | (and congestion control state ...
... NORM_CMD(CC) | Sender command used in collection of round |
| | trip timing and congestion control status |
...
... +----------------------+----------------------------------------------+
|NORM_INFO | Sender message for providing ancillary |
| | context information associated with NORM ...
... |NORM_CMD(EOT) | Sender command to indicate it has reached |
| | end-of-transmission and will no longer |
| | respond to repair requests. |
...
... NORM_CMD(ACK_REQ) | Sender command to support application- |
| | defined, positively acknowledged commands |
| | sent outside of the context ...
... |NORM_CMD(APPLICATION) | Sender command containing application-defined|
| | commands sent outside of the context of the |
...
... NORM_INFO, and NORM_DATA message types are generated by senders of
data content, and NORM_NACK ...
... nodes to detect packet losses in the transmission from a
sender and used in estimating raw packet loss for congestion control
...
... Sender Messages ...
... NORM_DATA message is expected to be the predominant type
transmitted by NORM senders. These messages are used to encapsulate
segmented data content for objects of type NORM ...
... "payload_len" and "payload_offset" fields allow senders to
arbitrarily vary the size of NORM_DATA payload ...
... field.
The "instance_id" field contains a value generated by the sender to
uniquely identify its current instance of participation in the
NormSession. This allows receivers ...
... uniquely identify its current instance of participation in the
NormSession. This allows receivers to detect when senders have
perhaps left and rejoined a session in progress. When a sender ...
... senders have
perhaps left and rejoined a session in progress. When a sender
(identified by its "source_id") is detected to have a new
"instance_id", the NORM receivers ...
... NORM receivers SHOULD drop their previous state on
the sender and begin reception anew.
The "grtt" field contains a non-linear quantized representation of
...
...
The "grtt" field contains a non-linear quantized representation of
the sender's current estimate of group round-trip time (GRTT ...
... feedback suppression. This 4-bit field supports values from 0-15
which is multiplied by the sender GRTT to determine the maximum
backoff timeout. The "backoff" field informs the receiver ...
... backoff timeout. The "backoff" field informs the receiver set of the
sender's backoff factor parameter "Ksender". Recommended values and
their use are described in the NORM receiver NACK ...
... NACK procedure
description in Section 5.3. The "gsize" field contains a
representation of the sender's current estimate of group size. This
4-bit ...
... | | | compared to parity segments provided by |
| | | the sender for general purpose (with |
| | | respect to an FEC coding block) erasure |
...
... of new (non-repair) data content. NORM_FLAG_EXPLICIT is used to mark
repair messages sent when the data sender has exhausted its ability
to provide "fresh" (previously untransmitted) parity segments as
...
... available for a given object. NORM_FLAG_UNRELIABLE is set when the
sender wishes to transmit an object with only "best effort" delivery
and will not supply repair transmissions for the object. NORM
receivers ...
... for those objects are not received (i.e., a gap in the
"object_transport_id" sequence is noted). In this case, the sender
should invoke the NORM_CMD ...
... 4.2.3. NORM_FLAG_FILE can be set as a "hint" from the sender that
the associated object should be stored in non-volatile storage.
...
... stream. This allows NORM receiver applications to "synchronize" with
NORM senders and to be able to properly interpret application layer
data when joining a NORM ...
... The "object_transport_id" field is a monotonically and incrementally
increasing value assigned by the sender to NormObjects being
transmitted. Transmissions and repair requests related to that
object use the same "object_transport ...
... session, an object is
uniquely identified by the concatenation of the sender "source_id"
and the given "object_transport_id". Note that NORM ...
... identifier for the attached segment with
respect to the NORM sender's instance within a session.
...
... out-of-band session information. However, in some cases, it may be
useful for the sender to include this information "in band" to
facilitate receiver operation with minimal preconfiguration. For
...
... size corresponds to the stream buffer size maintained by the NORM
sender). As an example, the format of the EXT_FTI for small block
systematic codes ("fec_id" = 129) is given here:
...
... STREAM, the "object_length"
field is used by the sender to indicate the size of its stream buffer
...
... 5]. The "segment_size" field
indicates the sender's current setting for maximum message payload
content (in bytes). This allows receivers ...
... user
data segments per FEC coding block to be used by the sender during
the session. This allows receivers ...
... buffer
space for buffering blocks transmitted by the sender.
The "fec_num_parity" corresponds to the "maximum number of encoding ...
... GF(2^16)) codes, this value indicates the maximum number
of parity segments available from the sender for the coding blocks.
This field MAY be interpreted differently for other systematic codes
as they are defined.
...
... the application content represented by the message payload. For
senders employing systematic FEC encoding, these fields contain
...
... payload_id".
The length of this field SHALL be limited to a maximum of the
sender's NormSegmentSize bytes as given in the FTI for the object.
Note the length of this field for messages containing parity content
will always be of length NormSegmentSize. When encoding ...
... padding for data segments with length less than the NormSegmentSize.
It is RECOMMENDED that a sender's NormSegmentSize generally be
constant for the duration of a given sender's term of participation
...
... It is RECOMMENDED that a sender's NormSegmentSize generally be
constant for the duration of a given sender's term of participation
in the session, but may possibly vary on a per-object basis. The
...
... in the session, but may possibly vary on a per-object basis. The
NormSegmentSize is expected to be configurable by the sender
application prior to session participation as needed for network
topology ...
... NORM_INFO content is limited to that of a single NormSegmentSize
for the given sender. This atomic nature allows the NORM_INFO to be
rapidly and efficiently repaired within the NORM ...
... receiver to prepare appropriate buffering, etc, for further
transmissions from the sender when NORM_INFO is the first message
received.
...
... The NORM_INFO "payload_data" field contains sender application-
defined content which can be used by receiver applications for
...
... NORM_CMD messages are transmitted by senders to perform a number of
different protocol functions. This includes functions such as
round-trip ...
... congestion control functions,
synchronization of sender/receiver repair "windows", and notification
...
... receiver repair "windows", and notification
of sender status. A core set of NORM_CMD messages is enumerated.
...
... CMD types may have dynamic
content attached. Any attached content will be limited to maximum
length of the sender NormSegmentSize to retain the atomic nature of
commands. All NORM_CMD ...
... |NORM_CMD(FLUSH) | 1 | Used to indicate sender |
| | | temporary end-of-transmission. |
| | | (Assists in robustly initiating |
...
... |NORM_CMD(EOT) | 2 | Used to indicate sender |
| | | permanent end-of-transmission. |
+----------------------+-------------+---------------------------------+
...
... |NORM_CMD(SQUELCH) | 3 | Used to advertise sender's |
| | | current repair window in |
| | | response to out-of-range ...
... |NORM_CMD(REPAIR_ADV) | 5 | Used to advertise sender's |
| | | aggregated repair/feedback state|
...
... The NORM_CMD(FLUSH) command is sent when the sender reaches the end
of all data content and pending repairs it has queued for
transmission. This may indicate a temporary or permanent end of data
...
... of all data content and pending repairs it has queued for
transmission. This may indicate a temporary or permanent end of data
transmission, but the sender is still willing to respond to repair
requests. This command is repeated once per 2*GRTT to excite the
...
... NACKs) _and_ that the corresponding NACKs are delivered to
the sender. If a NORM_NACK message interrupts the flush process, the
...
... NORM_NACK message interrupts the flush process, the
sender will re-initiate the flush process after any resulting repair
transmissions are completed.
...
... 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. This inactivity timeout is
related to 2*GRTT*NORM ...
... reliability. The penalty of a
large NORM_ROBUST_FACTOR value is potentially excess sender
NORM_CMD ...
... FEC coding block if systematic FEC codes are employed.
In this case, the sender will not yet be able to provide FEC parity
content as repair for the concurrent coding block and will be limited
...
... NORM_CMD(FLUSH) message contains fields to identify the
current status and logical transmit position of the sender.
The "fec_id" field indicates the FEC ...
... transport_id" and "fec_payload_id" fields indicate the
sender's current logical "transmit position". These fields are
interpreted in the same manner as in the NORM_DATA message ...
... "source_block_number" if the given "encoding_symbol_id" is less than
the "source_block_len". This condition indicates the sender has not
yet completed encoding the corresponding FEC ...
... 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 of transmission when
needed, even if in the middle of an FEC ...
... stream of transmission when
needed, even if in the middle of an FEC block. Once the sender
resumes stream transmission and passes the end of the pending coding
...
... field contains a list of NormNodeIds for receivers from which the
sender is requesting explicit positive acknowledgment of reception up
through the transmission point identified by the
"object_transport ...
... The NORM_CMD(EOT) command is sent when the sender reaches permanent
end-of-transmission with respect to the NormSession and will not
respond to further repair requests. This allows receivers ...
... respond to further repair requests. This allows receivers to
gracefully reach closure of operation with this sender (without
requiring any timeout) and free any resources that are no longer
needed. The NORM ...
... NORM_NACK content consists of repair requests for NormObjects for
which the sender is unable or unwilling to provide repair. This
includes repair requests for outdated objects, aborted objects, or
those objects which the sender ...
... sender is unable or unwilling to provide repair. This
includes repair requests for outdated objects, aborted objects, or
those objects which the sender previously transmitted marked with the
NORM_FLAG_UNRELIABLE flag. This command indicates to receivers ...
... receivers what
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) advertises the current "repair window" of the
sender by identifying the earliest (lowest) transmission point for
which it will provide repair, along with an encoded list of objects
from that point forward that are no longer valid ...
... from that point forward that are no longer valid for repair. This
mechanism allows the sender application to cancel or abort
transmission and/or repair of specific previously enqueued objects.
The list also contains the identifiers ...
... 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.
...
... start from the invalid NACK(s) that prompted the generation
of the squelch. The length of the list is limited by the sender's
NormSegmentSize. This allows the receivers to learn the status of
...
... NormSegmentSize. This allows the receivers to learn the status of
the sender's applicable object repair window with minimal
transmission of NORM_CMD ...
... NORM_CMD(SQUELCH) message contains fields to identify the
earliest logical transmit position of the 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 ...
... transport_id" and "fec_payload_id" fields are
concatenated to indicate the beginning of the sender's current repair
window (i.e., the logically earliest point in its transmission
history for which the sender ...
... sender's current repair
window (i.e., the logically earliest point in its transmission
history for which the sender can provide repair). The "fec_id" field
implies the size and format of the "fec_payload_id" field. This
...
... encoding_symbol_id" may be
included in the "fec_payload_id" field, the sender's repair window
SHOULD be aligned on FEC coding block boundaries and thus the
...
... bit NormTransportIds that,
although they are within the range of the sender's current repair
window, are no longer available for repair from the sender. For
...
... range of the sender's current repair
window, are no longer available for repair from the sender. For
example, a sender application may dequeue an out-of-date object even
...
... window, are no longer available for repair from the sender. For
example, a sender application may dequeue an out-of-date object even
though it is still within the repair window. The total size of the
"invalid_object_list" content is can be determined from the packet's
...
... payload length and is limited to a maximum of the NormSegmentSize of
the sender. Thus, for very large repair windows, it is possible that
a single NORM_CMD ...
... entire set of invalid objects in the repair window. In this case,
the 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 ...
... greater than the "object_transport_id" marking the beginning of the
sender's repair window. This insures convergence of the squelch
process, even if multiple invalid NACK ...
... NACK/ squelch iterations are
required. This explicit description of invalid content within the
sender's current window allows the sender application (most notably
for discrete "object" based transport ...
... required. This explicit description of invalid content within the
sender's current window allows the sender application (most notably
for discrete "object" based transport) to arbitrarily invalidate
...
... 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 ...
... 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
...
... CMD(CC) probes from the sender. This can
be useful instrumentation for complex or experimental multicast
routing ...
... NORM_NACK messages generated. This allows the sender to evaluate
round-trip times to different receivers ...
... 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 ...
... sender's current transmission rate. This is used along
with the loss detection "sequence" field of all NORM sender messages
and the NORM_CMD ...
... Header Extension Format (EXT_RATE)
The "send_rate" field indicates the sender's current transmission
rate in bytes per second. The 16-bit ...
... Receiver has measured RTT with respect |
| | | to sender. |
+------------------+-------+------------------------------------------+
|NORM ...
... 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 ...
... The NORM_CMD(REPAIR_ADV) message is used by the sender to "advertise"
its aggregated repair state from NORM ...
... during a repair cycle and/or congestion control feedback received.
This message is sent only when the sender has received NORM_NACK
...
... 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
...
... CC) messages from the
sender. This information assists the sender in congestion control
operation by providing an indicator of how current ("fresh") the
...
... congestion control probes (and thus possibly other
messages from the sender), the sender may choose to take congestion
avoidance measures. For NORM ...
... probes (and thus possibly other
messages from the sender), the sender may choose to take congestion
avoidance measures. For NORM_CMD ...
... 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 ...
... CC_RTT
should be set only when all feedback messages received by the sender
have the flag set. Similarly, the NORM_FLAG_CC ...
... 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 ...
... For NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the "cc_rtt"
field value to the largest non-CLR/non-PLR ...
... For NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the "cc_loss"
field value to the largest non-CLR/non-PLR ...
... 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 ...
... NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the "cc_loss"
field value to the lowest non-CLR/non-PLR ...
... 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.
...
... NORM_CMD(ACK_REQ) message is used by the sender to request
acknowledgment from a specified list of receivers. This message is
...
... 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.
...
... 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 ...
... format at the discretion of the application. The size of this
payload SHALL be limited to a maximum of the sender's NormSegmentSize
setting.
...
... NORM_NACK messages are sent
to request repair of missing data content from sender transmission
and NORM_ACK messages ...
... and NORM_ACK messages are generated in response to certain sender
commands including NORM_CMD ...
... NACK messages is for receivers to
request repair of sender content via selective, negative
acknowledgment upon detection of incomplete data. NORM_NACK ...
... NORM_NACK messages also
contain additional fields to provide feedback to the sender(s) for
purposes of round-trip timing collection and congestion control ...
... header extensions present is 6.
The "server_id" field identifies the NORM sender to which the
NORM_NACK ...
... 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
...
... 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.
...
... 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.
...
... 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 ...
... CMD(CC) message from the
indicated sender and that the sender should ignore the
"grtt_response" in this message.
...
... CC) message from the
indicated sender and that the sender should ignore the
"grtt_response" in this message.
...
... 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
...
... 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 ...
... 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 ...
... "nack_payload" size SHALL NOT exceed the NormSegmentSize for the
sender to which the NORM_NACK is destined.
...
... 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.
...
... "nack_payload" field size be limited to a maximum of the
NormSegmentSize for the sender to which the NORM_ACK is destined.
...
...
The "ack_id" field serves as a sequence number so that the sender can
verify that a NORM_ACK message ...
... NORM_CMD(FLUSH) messages
transmitted by the sender identified by the "server_id" field.
The "ack_payload ...
... ACK messages for application-defined
"ack_type" values is specific to the application but is limited in
size to a maximum the NormSegmentSize of the sender referenced by the
"server_id".
...
... NORM multicast sessions whether the participant is acting as a sender
and/or receiver within the group ...
...
This section describes the detailed interactions of senders and
receivers participating in a NORM ...
... receiver set.
2) The sender transmits an ordinal set of NormObjects segmented in
the form of NORM_DATA messages ...
...
3) As receivers detect missing content from the sender, they initiate
repair requests with NORM_NACK ...
... 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
...
... satisfied.
4) The sender aggregates repair requests from the receivers and
logically "rewinds" its transmit position to send appropriate
...
... receivers and
logically "rewinds" its transmit position to send appropriate
repair messages. The sender sends repairs for the earliest
ordinal transmit position first and maintains this ordinal repair
transmission sequence. Previously untransmitted FEC ...
... content for the applicable FEC coding block is used for repair
transmissions to the greatest extent possible. If the sender
exhausts its available FEC parity content on multiple repair
...
... general protocol operation, but the possibility does exist for
extreme conditions). The sender immediately assumes transmission
of new content once it has sent pending repairs.
...
... of new content once it has sent pending repairs.
5) The sender transmits NORM_CMD(FLUSH) messages when it reaches the
...
... strategy as for data) if they require further repair.
6) The sender transmissions are subject to rate control limits
determined by congestion control ...
... NORM-CC operation, each sender in a NormSession maintains its own
independent congestion control state ...
... Sender Initialization and Transmission ...
... Internet. Even if congestion control
operation is disabled at the sender, it may be desirable to use the
NORM_CMD ...
... NACK operation.
In some cases, applications may wish for the sender to also proceed
with data transmission immediately. In other cases, the sender may
...
... In some cases, applications may wish for the sender to also proceed
with data transmission immediately. In other cases, the sender may
wish to defer data transmission until it has received some feedback
or request from the receiver ...
... Object Transmission
Information Header Extension, the NORM protocol sender message
headers can contain all information necessary to prepare receivers ...
... for subsequent reliable reception. This includes FEC coding
parameters, the sender NormSegmentSize, and other information. If
this header extension is not used, it is presumed that receivers ...
... session and data
being transmitted. These mechanisms allow for operation with minimal
pre-coordination among the senders and receivers.
...
... receivers.
The NORM sender begins segmenting application-enqueued data into
NORM_DATA segments ...
... receivers
participating in the multicast group provide feedback to the sender
as needed. When the sender reaches the end of data it has enqueued
...
... multicast group provide feedback to the sender
as needed. When the sender reaches the end of data it has enqueued
for transmission or any pending repairs, it transmits a series of
...
... receivers request repair, the
repair is provided and flushing occurs again at the end of repair
transmission. The sender may attach an OPTIONAL "acking_node_list"
to NORM ...
... DATA message contains one source or encoding symbol and the
NormSegmentSize sender parameter defines the maximum symbol size in
bytes. The FEC encoding type ...
... encoding type and associated parameters govern the
source block size (number of source symbols per coding block). NORM
senders and receivers use these FEC parameters, along with the
...
... FEC
source block size (B_max) and the sender's NormSegmentSize, the block
segmentation for a given NORM transport ...
... group to limit or avoid repair requests for
transport objects already in progress. The NORM sender
implementation may wish to impose additional constraints to limit the
...
...
When the receiver detects it is missing data from a sender's NORM
transmissions, it initiates its NACKing procedure. The NACKing
...
... NORM Building Block document [4] using
(Ksender*GRTTsender) for the "maxTime" parameter and the sender
advertised group size (GSIZEsender) as the "groupSize" parameter.
...
... advertised group size (GSIZEsender) as the "groupSize" parameter.
NORM senders provide values for GRTTsender, Ksender and GSIZEsender
via the "grtt", "backoff", and "gsize" fields of transmitted
messages. The GRTTsender value is determined by the sender ...
... NORM senders provide values for GRTTsender, Ksender and GSIZEsender
via the "grtt", "backoff", and "gsize" fields of transmitted
messages. The GRTTsender value is determined by the sender based on
feedback it has received from the group while the Ksender and
...
...
To avoid the possibility of NACK implosion in the case of sender or
network failure during SSM ...
... only if the following conditions are met:
1) The sender's current transmit position (in terms of
objectId::fecPayloadId) exceeds the earliest repair position of
the receiver ...
... 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 procedure (backoff timeout) was initiated.
...
... 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 worst-
case time to respond to the repair needs before the receiver requests
...
... receiver up through the coding
block prior to the most recently heard ordinal transmission position
for the sender. If the size of the NORM_NACK content exceeds the
...
... NORM_NACK content exceeds the
sender's NormSegmentSize, the NACK content is truncated so that the
receiver ...
... NACK message per NACK cycle for
a given sender. In summary, a single NACK message is generated
containing the receiver ...
... SHALL request only those repair symbols from the first set it has not
yet received up to the remaining erasure count for that applicable
coding block. Note that the sender may have provided other
different, additional parity segments for other receivers ...
... FEC
coding block exceeds the maximum number of parity symbols available
from the sender for the block (as indicated by the NORM_DATA
"fec_num_parity" field), the receiver ...
... common denominator set of repair symbols for a given FEC coding
block. This allows the sender to construct the most efficient repair
transmission segment set and enables effective NACK ...
...
The principle goal of the sender is to make forward progress in the
transmission of data its application has enqueued. However, the
sender ...
... sender is to make forward progress in the
transmission of data its application has enqueued. However, the
sender must occasionally "rewind" its logical transmission point to
satisfy the repair needs of receivers ...
... receivers, and "GRTT" is the sender's current estimate of the group's
greatest round-trip time ...
... round-trip time.
When this period ends, the sender "rewinds" by incorporating the
accumulated repair state into its pending transmission state ...
... begins transmitting repair messages. After pending repair
transmissions are completed, the sender continues with new
transmissions of any enqueued data. Also, at this point in time, the
sender ...
... sender continues with new
transmissions of any enqueued data. Also, at this point in time, the
sender begins a "holdoff" timeout during which time the sender
constrains itself from initiating a new repair aggregation ...
... transmissions of any enqueued data. Also, at this point in time, the
sender begins a "holdoff" timeout during which time the sender
constrains itself from initiating a new repair aggregation cycle,
...
... NACK messages arrive. As described in [4], the value of
this sender "holdoff" period is:
T_sndrHoldoff = (1*GRTT ...
... If additional NORM_NACK messages are received during this sender
"holdoff" period, the sender will immediately incorporate these "late
...