Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 5740

NACK-Oriented Reliable Multicast (NORM) Transport Protocol

Pages: 96
Proposed Standard
Obsoletes:  3940
Part 3 of 4 – Pages 47 to 65
First   Prev   Next

Top   ToC   RFC5740 - Page 47   prevText

4.3. Receiver Messages

The NORM message types generated by participating receivers consist of the NORM_NACK and NORM_ACK message types. NORM_NACK messages are sent to request repair of missing data content from sender transmission, and NORM_ACK messages are generated in response to certain sender commands including NORM_CMD(CC) and NORM_CMD(ACK_REQ).

4.3.1. NORM_NACK Message

The principal purpose of NORM_NACK messages is for receivers to request repair of sender content via selective, negative acknowledgment upon detection of incomplete data. NORM_NACK messages will be transmitted according to the rules of NORM_NACK generation and suppression described in Section 5.3. NORM_NACK messages also contain additional fields to provide feedback to the sender(s) for purposes of round-trip timing collection and congestion control. The payload of NORM_NACK messages contains one or more repair
Top   ToC   RFC5740 - Page 48
   requests for different objects or portions of those objects.  The
   NORM_NACK message format is as follows:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     |version| type=4|    hdr_len    |            sequence           |
     |                           source_id                           |
     |                           server_id                           |
     |           instance_id         |            reserved           |
     |                       grtt_response_sec                       |
     |                       grtt_response_usec                      |
     |               header extensions (if applicable)               |
     |                              ...                              |
     |                          nack_payload                         |
     |                              ...                              |

                    Figure 17: NORM_NACK Message Format

   The NORM common message header fields serve their usual purposes.
   The value of the "hdr_len" field for NORM_NACK messages without
   header extensions present is 6.

   The "server_id" field identifies the NORM sender to which the
   NORM_NACK message is destined.

   The "instance_id" field contains the current session identifier given
   by the sender identified by the "server_id" field in its sender
   messages.  The sender SHOULD ignore feedback messages containing an
   invalid "instance_id" value.

   The "grtt_response" fields contain an adjusted version of the
   timestamp from the most recently received NORM_CMD(CC) message for
   the indicated NORM sender.  The format of the "grtt_response" is the
   same as the "send_time" field of the NORM_CMD(CC).  The
   "grtt_response" value is relative to the "send_time" the source
   provided with a corresponding NORM_CMD(CC) command.  The receiver
   adjusts the source's NORM_CMD(CC) "send_time" timestamp by adding the
   time delta from when the receiver received the NORM_CMD(CC) to when
   the NORM_NACK is transmitted in response to calculate the value in
   the "grtt_response" field.  This is the "receive_to_response_delta"
Top   ToC   RFC5740 - Page 49
   value used in the following formula:
     grtt_response = NORM_CMD(CC) send_time + receive_to_response_delta

   The receiver SHALL set the "grtt_response" to a ZERO value, to
   indicate it has not yet received a NORM_CMD(CC) message from the
   indicated sender, and the sender MUST ignore the "grtt_response" in
   this message.

   For NORM-CC operation, the NORM-CC Feedback Header Extension, as
   described in the NORM_CMD(REPAIR_ADV} message description, is added
   to NORM_NACK messages to provide feedback on the receiver's current
   state with respect to congestion control operation.  Alternative
   header extensions for congestion control feedback MAY be defined for
   alternative congestion control schemes for NORM use in the future.

   The "reserved" field is for potential future NORM use and SHALL be
   set to ZERO for this version of the protocol.

   The "nack_payload" of the NORM_NACK message specifies the repair
   needs of the receiver with respect to the NORM sender indicated by
   the "server_id" field.  The receiver constructs repair requests based
   on the NORM_DATA and/or NORM_INFO segments it needs from the sender
   to complete reliable reception up to the sender's transmission
   position at the moment the receiver initiates the NACK procedure as
   described in Section 5.3.  A single NORM Repair Request consists of a
   list of items, ranges, and/or FEC coding block erasure counts for
   needed NORM_DATA and/or NORM_INFO content.  Multiple repair requests
   can be concatenated within the "nack_payload" field of a NORM_NACK
   message.  A single NORM Repair Request can possibly include multiple
   "items", "ranges", or "erasure_counts".  In turn, the "nack_payload"
   field MAY contain multiple repair requests.  A single NORM Repair
   Request has the following format:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     |      form     |     flags     |             length            |
     |                      repair_request_items                     |
     |                             ...                               |

                   Figure 18: NORM Repair Request Format

   The "form" field indicates the type of repair request items given in
   the "repair_request_items" list.  Possible values for the "form"
   field include:
Top   ToC   RFC5740 - Page 50
                      | Form               | Value |
                      | NORM_NACK_ITEMS    |   1   |
                      | NORM_NACK_RANGES   |   2   |
                      | NORM_NACK_ERASURES |   3   |

   A "form" value of NORM_NACK_ITEMS indicates each repair request item
   in the "repair_request_items" list is to be treated as an individual
   request.  A value of NORM_NACK_RANGES indicates the
   "repair_request_items" list consists of pairs of repair request items
   corresponding to the inclusive ranges of repair needs.  The
   NORM_NACK_ERASURES "form" indicates the repair request items are to
   be treated individually and the "encoding_symbol_id" portion of the
   "fec_payload_id" field of the repair request item (see below) is to
   be interpreted as an erasure count for the FEC coding block
   identified by the repair request item's "source_block_number".

   The "flags" field is currently used to indicate the level of data
   content for which the repair request items apply (i.e., an individual
   segment, entire FEC coding block, or entire transport object).
   Possible flag values include:

   | Flag              |  Value | Purpose                              |
   | NORM_NACK_SEGMENT |  0x01  | Indicates the listed segment(s) or   |
   |                   |        | range of segments needed as repair.  |
   | NORM_NACK_BLOCK   |  0x02  | Indicates the listed block(s) or     |
   |                   |        | range of blocks in entirety that are |
   |                   |        | needed as repair.                    |
   | NORM_NACK_INFO    |  0x04  | Indicates NORM_INFO is needed as     |
   |                   |        | repair for the listed object(s).     |
   | NORM_NACK_OBJECT  |  0x08  | Indicates the listed object(s) or    |
   |                   |        | range of objects in entirety are     |
   |                   |        | needed as repair.                    |

   When the NORM_NACK_SEGMENT flag is set, the "object_transport_id" and
   "fec_payload_id" fields are used to determine which sets or ranges of
   individual NORM_DATA segments are needed to repair content at the
   receiver.  When the NORM_NACK_BLOCK flag is set, this indicates the
   receiver is completely missing the indicated coding block(s), and
   that transmissions sufficient to repair the indicated block(s) in
   their entirety are needed.  When the NORM_NACK_INFO flag is set, this
   indicates the receiver is missing the NORM_INFO segment for the
   indicated "object_transport_id".  Note the NORM_NACK_INFO can be set
Top   ToC   RFC5740 - Page 51
   in combination with the NORM_NACK_BLOCK or NORM_NACK_SEGMENT flags,
   or can be set alone.  When the NORM_NACK_OBJECT flag is set, this
   indicates the receiver is missing the entire NormTransportObject
   referenced by the "object_transport_id".  This also implicitly
   requests any available NORM_INFO for the NormObject, if applicable.
   The "fec_payload_id" field is ignored when the flag NORM_NACK_OBJECT
   is set.

   The "length" field value is the length in bytes of the
   "repair_request_items" field.

   The "repair_request_items" field consists of a list of individual or
   range pairs of transport data unit identifiers in the following
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     |     fec_id    |   reserved    |      object_transport_id      |
     |                        fec_payload_id                         |
     |                              ...                              |

                Figure 19: NORM Repair Request Item Format

   The "fec_id" indicates the FEC type and can be used to determine the
   format of the "fec_payload_id" field.  The "reserved" field is kept
   for possible future use and SHALL be set to a ZERO value and ignored
   by NORM nodes processing NACK content.

   The "object_transport_id" corresponds to the NormObject for which
   repair is being requested, and the "fec_payload_id" identifies the
   specific FEC coding block and/or segment being requested.  When the
   NORM_NACK_OBJECT flag is set, the value of the "fec_payload_id" field
   is ignored.  When the NORM_NACK_BLOCK flag is set, only the FEC code
   block identifier portion of the "fec_payload_id" is to be

   The format of the "fec_payload_id" field depends upon the "fec_id"
   field value.

   When the receiver's repair needs dictate that different forms (mixed
   ranges and/or individual items) or types (mixed specific segments
   and/or blocks or objects in entirety) are needed to complete reliable
   transmission, multiple NORM Repair Requests with different "form" and
   or "flags" values can be concatenated within a single NORM_NACK
   message.  Additionally, NORM receivers SHALL construct NORM_NACK
   messages with their repair requests in ordinal order with respect to
Top   ToC   RFC5740 - Page 52
   "object_transport_id" and "fec_payload_id" values.  The
   "nack_payload" size SHALL NOT exceed the NormSegmentSize for the
   sender to which the NORM_NACK is destined.

   NORM_NACK Content Examples:

   In these examples, a small block, systematic FEC code ("fec_id" =
   129) is assumed with a user data block length of 32 segments.  In
   Example 1, a list of individual NORM_NACK_ITEMS repair requests is
   given.  In Example 2, a list of NORM_NACK_RANGES requests AND a
   single NORM_NACK_ITEMS request are concatenated to illustrate the
   possible content of a NORM_NACK message.  Note that FEC coding block
   erasure counts could also be provided in each case.  However, the
   erasure counts are not really necessary since the sender can easily
   determine the erasure count while processing the NACK content.
   However, the erasure count option can be useful for operation with
   other FEC codes or for intermediate system purposes.

    Example 1: NORM_NACK "nack_payload" for: Object 12, Coding Block 3,
                           Segments 2, 5, and 8
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     |   form = 1    | flags = 0x01  |       length  = 36            |
     |  fec_id = 129 |   reserved    |    object_transport_id = 12   |
     |                    source_block_number = 3                    |
     |    source_block_length = 32   |    encoding_symbol_id = 2     |
     |  fec_id = 129 |   reserved    |    object_transport_id = 12   |
     |                    source_block_number = 3                    |
     |    source_block_length = 32   |    encoding_symbol_id = 5     |
     |  fec_id = 129 |   reserved    |    object_transport_id = 12   |
     |                    source_block_number = 3                    |
     |    source_block_length = 32   |    encoding_symbol_id = 8     |
Top   ToC   RFC5740 - Page 53
    Example 2: NORM_NACK "nack_payload" for: Object 18, Coding Block 6,
   Segments 5, 6, 7, 8, 9, 10; and Object 19 NORM_INFO and Coding Block
                               1, Segment 3
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     |   form = 2    | flags = 0x01  |       length  = 24            |
     |  fec_id = 129 |   reserved    |    object_transport_id = 18   |
     |                    source_block_number = 6                    |
     |    source_block_length = 32   |    encoding_symbol_id = 5     |
     |  fec_id = 129 |   reserved    |    object_transport_id = 18   |
     |                    source_block_number = 6                    |
     |    source_block_length = 32   |    encoding_symbol_id = 10    |
     |   form = 1    | flags = 0x05  |       length  = 12            |
     |  fec_id = 129 |   reserved    |    object_transport_id = 19   |
     |                    source_block_number = 1                    |
     |    source_block_length = 32   |    encoding_symbol_id = 3     |

4.3.2. NORM_ACK Message

The NORM_ACK message is intended to be used primarily as part of NORM congestion control operation and round-trip timing measurement. The acknowledgment type NORM_ACK(CC) is provided for this purpose as described in the NORM_CMD(ACK_REQ) message description. The generation of NORM_ACK(CC) messages for round-trip timing estimation and congestion control operation is described in Section 5.5.1 and Section 5.5.2, respectively. However, some multicast applications can benefit from some limited form of positive acknowledgment for certain functions. A simple, scalable positive acknowledgment scheme is defined in Section 5.5.3, which can be leveraged by protocol implementations when appropriate. The NORM_CMD(FLUSH) can also be used for OPTIONAL collection of positive acknowledgment of reliable reception to a certain "watermark" transmission point from specific receivers using this mechanism. The NORM_ACK type NORM_ACK(FLUSH) is provided for this purpose and the format of the "nack_payload" for this acknowledgment type is given below. Beyond that, a range of application-defined "ack_type" values is provided for use at the NORM
Top   ToC   RFC5740 - Page 54
   application's discretion.  Implementations making use of application-
   defined positive acknowledgments MAY also make use of the
   "nack_payload" as needed, observing the constraint that the
   "nack_payload" field size be limited to a maximum of the
   NormSegmentSize for the sender to which the NORM_ACK is destined.
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     |version| type=5|    hdr_len    |          sequence             |
     |                           source_id                           |
     |                           server_id                           |
     |           instance_id         |    ack_type  |     ack_id     |
     |                       grtt_response_sec                       |
     |                       grtt_response_usec                      |
     |               header extensions (if applicable)               |
     |                              ...                              |
     |                   ack_payload (if applicable)                 |
     |                              ...                              |

                    Figure 20: NORM_ACK Message Format

   The NORM common message header fields serve their usual purposes.
   The value of the "hdr_len" field when no header extensions are
   present is 6.

   The "server_id", "instance_id", and "grtt_response" fields serve the
   same purpose as the corresponding fields in NORM_NACK messages.
   Header extensions can be applied to support congestion control
   feedback or other functions in the same manner.

   The "ack_type" field indicates the nature of the NORM_ACK message.
   This directly corresponds to the "ack_type" field of the
   NORM_CMD(ACK_REQ) message to which this acknowledgment applies.

   The "ack_id" field serves as a sequence number so the sender can
   verify a received NORM_ACK message actually applies to a current
   acknowledgment request.  The "ack_id" field is not used in the case
   of the NORM_ACK(CC) and NORM_ACK(FLUSH) acknowledgment types.

   The "ack_payload" format is a function of the "ack_type".  The
Top   ToC   RFC5740 - Page 55
   NORM_ACK(CC) message has no attached content.  Only the NORM_ACK
   header applies.  In the case of NORM_ACK(FLUSH), a specific
   "ack_payload" format is defined:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     |     fec_id    |   reserved    |      object_transport_id      |
     |                        fec_payload_id                         |
     |                              ...                              |

   The "object_transport_id" and "fec_payload_id" are used by the
   receiver to acknowledge applicable NORM_CMD(FLUSH) messages
   transmitted by the sender identified by the "server_id" field.

   The "ack_payload" of NORM_ACK messages for application-defined
   "ack_type" values is specific to the application but is limited in
   size to a maximum of the NormSegmentSize of the sender referenced by
   the "server_id".

4.4. General Purpose Messages

Some additional message formats are defined for general purpose in NORM multicast sessions whether the participant is acting as a sender and/or receiver within the group.

4.4.1. NORM_REPORT Message

This is an OPTIONAL message generated by NORM participants. This message can be used for periodic performance reports from receivers in experimental NORM implementations. The format of this message is currently undefined. Experimental NORM implementations MAY define NORM_REPORT formats as needed for test purposes. These report messages SHOULD be disabled for interoperability testing between different compliant NORM implementations.

5. Detailed Protocol Operation

This section describes the detailed interactions of senders and receivers participating in a NORM session. A simple synopsis of the protocol operation is given here: 1. The sender periodically transmits NORM_CMD(CC) messages as needed to initialize and collect round-trip timing and congestion control feedback from the receiver set.
Top   ToC   RFC5740 - Page 56
   2.  The sender transmits an ordinal set of NormObjects segmented in
       the form of NORM_DATA messages labeled with NormTransportIds and
       logically identified with FEC encoding block numbers and symbol
       identifiers.  When applicable, NORM_INFO messages MAY optionally
       precede the transmission of data content for NORM transport

   3.  As receivers detect missing content from the sender, they
       initiate repair requests with NORM_NACK messages.  The receivers
       track the sender's most recent objectTransportId::fecPayloadId
       transmit position and NACK only for content that is ordinally
       prior to that current transmit position.  The receivers schedule
       random backoff timeouts before generating NORM_NACK messages and
       wait an appropriate amount of time before repeating the NORM_NACK
       if their repair request is not satisfied.

   4.  The sender aggregates repair requests from the 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.  FEC parity content not previously
       transmitted 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 cycles for the same coding block, it resorts to an
       explicit repair strategy (possibly using parity content) to
       complete repairs.  (The use of explicit repair is an exception in
       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.

   5.  The sender transmits NORM_CMD(FLUSH) messages when it reaches the
       end of enqueued transmit content and pending repairs.  Receivers
       respond to the NORM_CMD(FLUSH) messages with NORM_NACK
       transmissions (following the same suppression backoff timeout
       strategy as for data) if they need further repair.

   6.  The sender transmissions are subject to rate control limits
       determined by congestion control mechanisms.  In the baseline
       NORM-CC operation, each sender in a NormSession maintains its own
       independent congestion control state.  Receivers provide
       congestion control feedback in NORM_NACK and NORM_ACK messages.
       NORM_ACK feedback for congestion control purposes is governed
       using a suppression mechanism similar to that for NORM_NACK

   While this overall concept is relatively simple, there are details to
   each of these aspects that need to be addressed for successful,
Top   ToC   RFC5740 - Page 57
   efficient, robust, and scalable NORM protocol operation.

5.1. Sender Initialization and Transmission

Upon startup, the NORM sender immediately begins sending NORM_CMD(CC) messages to collect round-trip timing and other information from the potential group. If NORM-CC congestion control operation is enabled, the NORM-CC Rate header extension MUST be included in these messages. Congestion control operation SHALL be observed at all times when not operating using dedicated resources, like in the general Internet. Even if congestion control operation is disabled at the sender, it can be desirable to use the NORM_CMD(CC) messaging to collect feedback from the group using the baseline NORM-CC feedback mechanisms. This proactive feedback collection can be used to establish a GRTT estimate prior to data transmission and potential NACK operation. In some cases, applications might need the sender to also proceed with data transmission immediately. In other cases, the sender might wish to defer data transmission until it has received some feedback or request from the receiver set indicating receivers are indeed present. Note, in some applications (e.g., web push), this indication MAY come out-of-band with respect to the multicast session via other means. As noted, the periodic transmission of NORM_CMD(CC) messages MAY precede actual data transmission in order to have an initial GRTT estimate. With inclusion of the OPTIONAL NORM FEC Object Transmission Information Header Extension (EXT_FTI), 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 receivers have received the FEC Object Transmission Information via other means. Additionally, applications MAY leverage the use of NORM_INFO messages associated with the session data objects in the session to provide application-specific context information for the session and data being transmitted. These mechanisms allow for operation with minimal pre-coordination among the senders and receivers. The NORM sender begins segmenting application-enqueued data into NORM_DATA segments and transmitting it to the group. For objects of type NORM_OBJECT_DATA and NORM_OBJECT_FILE, the segmentation algorithm described in FEC Building Block [RFC5052] is RECOMMENDED. For objects of type NORM_OBJECT_STREAM, segmentation will typically be into uniform FEC coding block sizes, with individual segment sizes controlled by the application. In most cases, the application and NORM implementation SHOULD strive to produce full-sized
Top   ToC   RFC5740 - Page 58
   (NormSegmentSize) segments when possible.  The rate of transmission
   is controlled via 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 as needed.
   When the sender reaches the end of data it has enqueued for
   transmission or any pending repairs, it transmits a series of
   NORM_CMD(FLUSH) messages at a rate of one per 2*GRTT_sender.  Similar
   to the end of each transmitted FEC coding block during transmission,
   receivers SHALL respond to these NORM_CMD(FLUSH) messages with
   additional repair requests as needed.  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 MAY attach an
   OPTIONAL "acking_node_list" to NORM_CMD(FLUSH) containing the
   NormNodeIds for receivers from which it expects explicit positive
   acknowledgment of reception.  The NORM_CMD(FLUSH) message MAY be also
   used for this OPTIONAL purpose any time prior to the end of data
   enqueued for transmission with the NORM_CMD(FLUSH) messages
   multiplexed with ongoing data transmissions.  The OPTIONAL NORM
   positive acknowledgment procedure is described in Section 5.5.3.

5.1.1. Object Segmentation Algorithm

NORM senders and receivers MUST use a common algorithm for logically segmenting transport data into FEC encoding blocks and symbols so appropriate NACKs can be constructed to request repair of missing data. NORM FEC coding blocks are comprised of multi-byte symbols (segments) transmitted in the payload of NORM_DATA messages. Each NORM_DATA message will contain one or more source or encoding symbols identified by the "fec_payload_id" field, and the NormSegmentSize sender parameter defines the maximum size (in bytes) of the "payload_data" field containing the content (a "segment"). The FEC encoding type and associated parameters govern the source block size (number of source symbols per coding block, etc.). NORM senders and receivers use these FEC parameters, along with the NormSegmentSize and transport object size to compute the source block structure for transport objects. These parameters are provided in the FEC Object Transmission Information for each object. The block partitioning algorithm described in the FEC Building Block [RFC5052] document is RECOMMENDED for use in computing a source block structure such that all source blocks are as close to being equal length as possible. This helps avoid the performance disadvantages of "short" FEC blocks. Note that this algorithm applies only to the statically sized NORM_OBJECT_DATA and NORM_OBJECT_FILE transport object types where the object size is fixed and predetermined. For NORM_OBJECT_STREAM objects, the object is segmented according to the maximum source block length given in the FEC Transmission Information, unless the FEC Payload ID indicates an alternative size for a given block.
Top   ToC   RFC5740 - Page 59

5.2. Receiver Initialization and Reception

For typical operation, NORM receivers will join a specified multicast group and listen on a specific port number for sender transmissions. As the NORM receiver receives NORM_DATA messages, it will establish buffering state and provide content to its application as appropriate for the given data type. The NORM protocol allows receivers to join and leave the group at will, although some applications might need receivers to be members of the group prior to start of data transmission. Thus, different NORM applications MAY use different policies to constrain the impact of new receivers joining the group in the middle of a session. For example, a useful implementation policy is for new receivers joining the group to limit or avoid repair requests for transport objects already in progress. The NORM sender implementation MAY impose additional constraints to limit the ability of receivers to disrupt reliable multicast performance by joining, leaving, and rejoining the group often. Different receiver "join policies" might be appropriate for different applications and/or scenarios. For general purpose operation, a 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 the first non-repair NORM_DATA or NORM_INFO message received upon joining the group is RECOMMENDED. For objects of type NORM_OBJECT_STREAM, it is RECOMMENDED the join policy constrain receivers to begin reliable reception at the current FEC coding block for which non-repair content is received. In some deployments, different multicast receivers might have differing quality of network connectivity. Some receivers may suffer significantly poorer performance with very limited goodput due to low connection rate or substantial packet loss. Similar to the "join policies" described above, a NORM sender implementation MAY choose to enforce different "service policies" to perhaps exclude exceptionally poorly performing (or otherwise badly behaving) receivers from the group. The sender implementation could choose to ignore NACKs from such receivers and/or force advancement of its logical "repair window" (i.e., enforcing a minimal level of service) and use the NORM_CMD(SQUELCH) message to advise those poor performers of its advance. Note in some cases, the application may need to support the "weakest member" regardless of the time needed to achieve reliable delivery. When implemented, the protocol instantiation SHOULD expose controls to the set of "join" and/or "service" policies available to support the needs of different applications.

5.3. Receiver NACK Procedure

When the receiver detects it is missing data from a sender's NORM transmissions, it initiates its NACKing procedure. The NACKing
Top   ToC   RFC5740 - Page 60
   procedure SHALL be initiated only at FEC coding block boundaries,
   NormObject boundaries, upon receipt of a NORM_CMD(FLUSH) message, or
   upon an "inactivity" timeout when NORM_DATA or NORM_INFO
   transmissions are no longer received from a previously active sender.
   The RECOMMENDED value of such an inactivity timeout is:

            T_inactivity = NORM_ROBUST_FACTOR * 2 * GRTT_sender

   where the GRTT_sender value corresponds to the GRTT estimate
   advertised in the "grtt" field of NORM sender messages.  A minimum
   T_inactivity value of 1 second is RECOMMENDED.  The NORM receiver
   SHOULD reset this inactivity timer and repeat NACK initiation upon
   timeout for up to NORM_ROBUST_FACTOR times or more depending upon the
   application's need for persistence by its receivers.  It is also
   important receivers rescale the T_inactivity timeout as the sender's
   advertised GRTT changes.

   The NACKing procedure begins with a random backoff timeout.  The
   duration of the backoff timeout is chosen using the "RandomBackoff"
   algorithm described in the Multicast NACK Building Block [RFC5401]
   document using (K_sender*GRTT_sender) for the maxTime parameter and
   the sender advertised group size (GSIZE_sender) as the groupSize
   parameter.  NORM senders provide values for GRTT_sender, K_sender and
   GSIZE_sender via the "grtt", "backoff", and "gsize" fields of
   transmitted messages.  The GRTT_sender value is determined by the
   sender based on feedback it has received from the group while the
   K_sender and GSIZE_sender values can be determined by application
   requirements and expectations or ancillary information.  The backoff
   factor K_sender MUST be greater than one to provide for effective
   feedback suppression.  A value of K_sender = 4 is RECOMMENDED for the
   Any Source Multicast (ASM) model, while a value of K_sender = 6 is
   RECOMMENDED for Single Source Multicast (SSM) operation.

       T_backoff = RandomBackoff(K_sender*GRTT_sender, GSIZE_sender)

   To avoid the possibility of NACK implosion in the case of sender or
   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 (K_sender-
   1)*GRTT_sender.  Otherwise, the backoff period is entered and the
   receiver MUST accumulate external pending repair state from NORM_NACK
   messages and NORM_CMD(REPAIR_ADV) messages received.  At the end of
   the backoff time, the receiver SHALL generate a NORM_NACK message
   only if the following conditions are met:
Top   ToC   RFC5740 - Page 61
   1.  The sender's current transmit position (in terms of
       objectTransportId::fecPayloadId) exceeds the earliest repair
       position of the receiver.

   2.  The repair state accumulated from NORM_NACK and
       NORM_CMD(REPAIR_ADV) messages does 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.

   If these conditions are met, the receiver immediately generates a
   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 begins a "holdoff" period
   during which it constrains itself to not re-initiate 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
   repair again.  The value of this "holdoff" timeout (T_rcvrHoldoff) as
   described in [RFC5401] is:
                  T_rcvrHoldoff =(K_sender+2)*GRTT_sender

   The NORM_NACK message contains repair request content beginning with
   the lowest ordinal repair position of the 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 sender's NormSegmentSize, the NACK content is truncated
   so the receiver only generates a single NORM_NACK message per NACK
   cycle for a given sender.  In summary, a single NACK message is
   generated containing the receiver's lowest ordinal repair needs.

   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
   ordinal parity "encoding_symbol_id" (i.e., "encoding_symbol_id" =
   "source_block_len") and request the number of FEC symbols
   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
   coding block.  Note the sender might have transmitted other
   different, additional parity 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
   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 SHALL request all available
   parity segments plus the ordinally highest missing data segments
   needed to satisfy its total erasure needs for the block.  The goal of
   this strategy is for the overall receiver set to request a lowest
Top   ToC   RFC5740 - Page 62
   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 suppression among
   the receivers even with uncorrelated packet loss.  This approach also
   does not demand 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
   NORM_NACK_OBJECT flags set as appropriate.  The request for
   retransmission of NORM_INFO is accomplished by setting the
   NORM_NACK_INFO flag in a corresponding repair request.

5.4. Sender NACK Processing and Response

The principal goal of the sender is to make forward progress in the transmission of data its application has enqueued. However, the sender will need to occasionally "rewind" its logical transmission point to satisfy the repair needs of receivers who have NACKed. Aggregation of multiple NACKs is used to determine an optimal 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 synchronization of the repair process even when receivers experience uncorrelated data loss.

5.4.1. Sender Repair State Aggregation

When a sender is in its normal state of transmitting new data and receives a NACK, it begins a procedure to accumulate NACK repair state from NORM_NACK messages before beginning repair transmissions. Note that this period of aggregating repair state does NOT interfere with its ongoing transmission of new data. As described in [RFC5401], the period of time during which the sender aggregates NORM_NACK messages is equal to: T_sndrAggregate = (K_sender + 1) * GRTT_sender where K_sender is the backoff scaling value advertised to the receivers, and GRTT_sender is the sender's current estimate of the group's greatest round-trip time. Note, for NORM unicast sessions, the T_sndrAggregate time can be set to ZERO since there is only one receiver. Similarly, the K_sender value SHOULD be set to ZERO for NORM unicast sessions to minimize repair latency. When this period ends, the sender "rewinds" by incorporating the accumulated repair state into its pending transmission state and begins transmitting repair messages. After pending repair
Top   ToC   RFC5740 - Page 63
   transmissions are completed, the 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 cycle,
   even if NORM_NACK messages arrive.  As described in [RFC5401], the
   value of this sender "holdoff" period is:

                     T_sndrHoldoff = (1 * GRTT_sender)

   If additional NORM_NACK messages are received during this sender
   "holdoff" period, the sender will immediately incorporate these late-
   arriving messages into its pending transmission state if, and only
   if, the NACK content is ordinally greater than the sender's current
   transmission position.  This "holdoff" time allows worst-case time
   for the sender to propagate its current transmission sequence
   position to the group, thus avoiding redundant repair transmissions.
   After the holdoff timeout expires, a new NACK accumulation period can
   be started (upon arrival of a NACK) in concert with the pending
   repair and new data transmission.  Recall 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 incorporating accumulated repair state
   into its transmission plan and subsequently "rewinding" to transmit
   the lowest ordinal repair data when the aggregation period expires.
   Again, this is conducted in concert with ongoing new data and/or
   pending repair transmissions.

5.4.2. Sender FEC Repair Transmission Strategy

The NORM sender SHOULD leverage transmission of FEC parity content for repair to the greatest extent possible. Recall that receivers use a strategy to request a lowest common denominator 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 can make use of the general erasure-filling capability of FEC-generated parity segments. The sender can determine the maximum erasure-filling needs for individual FEC coding blocks from the NORM_NACK messages received during the repair aggregation period. Then, if the sender has a sufficient number (less than or equal to the maximum erasure count) of previously unsent parity segments available for the applicable coding blocks, the sender can transmit these in lieu of the specific packets the receiver set has requested. The sender SHOULD NOT resort to explicit transmission of the receiver set's repair needs until after exhausting its supply of "fresh" (unsent) parity segments for a given coding block. In general, if a sufficiently powerful FEC code is used, the need for explicit repair will be an exception, and the
Top   ToC   RFC5740 - Page 64
   fulfillment of reliable multicast can be accomplished quite
   efficiently.  However, the ability to resort to explicit repair
   allows the protocol to be continue to operate under even very extreme

   NORM_DATA messages sent as repair transmissions SHALL be flagged with
   the NORM_FLAG_REPAIR flag.  This allows receivers to obey any
   policies limiting new receivers from joining the reliable
   transmission when only repair transmissions have been received.
   Additionally, the sender SHOULD flag NORM_DATA transmissions sent as
   explicit repair with the NORM_FLAG_EXPLICIT flag.

   Although NORM end system receivers do not make use of the
   NORM_FLAG_EXPLICIT flag, this message transmission status could be
   leveraged by intermediate systems wishing to "assist" NORM protocol
   performance.  If such systems are properly positioned with respect to
   reciprocal reverse-path multicast routing, they need to sub-cast only
   a sufficient count of non-explicit parity repairs to satisfy a
   multicast routing sub-tree's erasure-filling needs for a given FEC
   coding block.  When the sender has resorted to explicit repair, then
   the intermediate systems SHOULD sub-cast all of the explicit repair
   packets to those portions of the routing tree still requiring repair
   for a given coding block.  Note the intermediate systems will need to
   conduct repair state accumulation for sub-routes in a manner similar
   to the sender's repair state accumulation in order to have sufficient
   information to perform the sub-casting.  Additionally, the
   intermediate systems could perform NORM_NACK suppression/aggregation
   as it conducts this repair state accumulation for NORM repair cycles.
   The details of this type of operation are beyond the scope of this
   document, but this information is provided for possible future

5.4.3. Sender NORM_CMD(SQUELCH) Generation

If the sender receives a NORM_NACK message for repair of data it is no longer supporting, the sender generates a NORM_CMD(SQUELCH) message to advertise its repair window and squelch any receivers from additional NACKing of invalid data. The transmission rate of NORM_CMD(SQUELCH) messages is limited to once per 2*GRTT_sender. The "invalid_object_list" (if applicable) of the NORM_CMD(SQUELCH) message SHALL begin with the lowest "object_transport_id" from the invalid NORM_NACK messages received since the last NORM_CMD(SQUELCH) transmission. The list includes as many lower ordinal invalid "object_transport_ids" that can fit for the NORM_CMD(SQUELCH) payload size to less than or equal to the sender's NormSegmentSize parameter.
Top   ToC   RFC5740 - Page 65

5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation

When a 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 communication. A NORM sender implementation MAY use a separate port number from the NormSession port number as the source port for its transmissions. Thus, NORM receivers can direct any unicast feedback messages to this separate sender port number, distinct from the NORM session (or destination) port number. Then, the NORM sender implementation can discriminate unicast feedback messages from multicast feedback messages when there is a mix of multicast and unicast feedback receivers. The NORM_CMD(REPAIR_ADV) message is multicast to the receiver set by the sender. The 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 that the sender does not merely retransmit NACK content it receives, but instead transmits a representation of its aggregated repair state. The transmission of NORM_CMD(REPAIR_ADV) messages is subject to the sender transmit rate limit and NormSegmentSize limitation. When the NORM_CMD(REPAIR_ADV) message is of maximum size (as indicated by the flag NORM_REPAIR_ADV_FLAG_LIMIT), receivers SHALL consider the maximum ordinal transmission position value embedded in the message as the senders current transmission position and implicitly suppress requests for ordinally higher repair. For congestion control operation, the sender will also need to provide any information needed so dynamic congestion control feedback can be suppressed among receivers. This document specifies the NORM-CC Feedback Header Extension that is applied for baseline NORM-CC operation. If other congestion control mechanisms are used within a NORM implementation, other header extensions MAY be defined. Whatever content format is used for this purpose SHOULD ensure that maximum possible suppression state is conveyed to the receiver set.

(page 65 continued on part 4)

Next Section