4.9. Transport LBT-RM Reliability Options

4.9.1. LBT-RM Datagram Loss Resulting in Unrecovered Message Loss

The key options that control the effort that an LBT-RM receiver will make to recover from datagram loss are transport_lbtrm_nak_backoff_interval and transport_lbtrm_nak_generation_interval. Timers for both start when loss is detected. The following timeline illustrates a case where a receiver is notified of unrecoverable message loss following repeated datagram loss.

Set transport_lbtrm_nak_backoff_interval to the NAK service time that could be reasonably expected from the receiver's location in the network plus some cushion for network congestion. Set transport_lbtrm_nak_generation_interval to the latency budget established for the transport layer. See our whitepaper Topics in High Performance Messaging for background on latency budgets. See also Reducing Loss Recovery Latencies

4.9.2. LBT-RM Source Ignoring NAKs for Efficiency

Bandwidth efficiency of an LBT-RM source may be improved by avoiding useless retransmissions. Consider the case of an LBT-RM source that has received a NAK for a datagram that it has just retransmitted. It's likely that the NAK and the retransmission "crossed in the mail." Hence it's likely that the receiver generating the NAK will have already received the retransmission just sent. If so, there's no need for the source to send another retransmission so the NAK can be safely ignored. Consider the timeline illustrated in Figure 4-6.

This shows NAKs for a given datagram being ignored for transport_lbtrm_ignore_interval following the retransmission of that datagram. (The successive NAKs received by the source in Figure 4-6 indicate that more than one receiver is subscribed to the source's topic.) NAKs will be serviced as normal following the passage of the interval. When ignoring a NAK, the source sends a NCF (NAK ConFirmation) instead of a retransmission, which starts a NAK suppression interval at the receiver. (See Figure 4-7.)

4.9.3. LBT-RM Receiver Suppressing NAK Generation

LBT-RM sources want receivers to be notified that their NAKs have been heard. Prompt notification via a retransmission or NCF can suppress useless NAK generation. There are a variety of circumstances where the source does not send a retransmission in response to a receiver's NAK. For example, as shown in Figure 4-6, NAKs received during the ignore interval do not generate retransmissions. Another example would be if previous retransmissions have used up all the retransmission bandwidth for the current rate limiter interval. See Figure 4-7 for a depiction of how a receiver responds to a NCF.

Following the receipt of an NCF, a receiver suppresses all NAK generation until transport_lbtrm_nak_suppress_interval passes. NAK generation resumes with the usual transport_lbtrm_nak_backoff_interval if repair was not received during the suppression interval.

4.9.4. transport_lbtrm_ignore_interval (source)

The interval to ignore NAKs after a retransmission is sent. This option affects the transport session underlying the source rather than the source itself. The transport session uses the value from the first source created on the session and ignores subsequent sources. Refer to Source Configuration and Transport Sessions for additional information.

4.9.5. transport_lbtrm_nak_backoff_interval (receiver)

For LBT-RM sessions only. The maximum interval between transmissions of a single NAK. The actual time the receiver will wait to NAK again is random. The algorithm used to determine the time range is (1/2 * backoff_interval - 3/2 * backoff_interval). This can result in a wait interval longer than the specified value. This option affects the transport session underlying the receiver rather than the receiver itself. The transport session uses the value from the first receiver created on the session and ignores subsequent receivers. Refer to Receiver Configuration and Transport Sessions and Interrelated Configuration Options for additional information.

4.9.6. transport_lbtrm_nak_generation_interval (receiver)

For LBT-RM sessions only. The maximum time that a piece of data may be outstanding before the data is unrecoverably lost. Although the minimum valid value is 5 milliseconds, larger values are advisable. This option affects the transport session underlying the receiver rather than the receiver itself. The transport session uses the value from the first receiver created on the session and ignores subsequent receivers. Refer to Receiver Configuration and Transport Sessions and Interrelated Configuration Options for additional information.

4.9.7. transport_lbtrm_nak_initial_backoff_interval (receiver)

For LBT-RM sessions only. The interval between loss detection and transmission of the first NAK. The actual time the receiver will wait to NAK is random. The algorithm used to determine the time range is (1/2 * initial_backoff_interval - 3/2 * initial_backoff_interval). This can result in a wait interval longer than the specified value. A value of 0 indicates that the receiver should immediately send a NAK. Users should be fully aware of the implications of this before using a value of 0.

4.9.8. transport_lbtrm_nak_suppress_interval (receiver)

For LBT-RM sessions only. The maximum interval to suppress sending NAKs after an NCF or a NAK from another receiver. This option affects the transport session underlying the receiver rather than the receiver itself. The transport session uses the value from the first receiver created on the session and ignores subsequent receivers. Refer to Receiver Configuration and Transport Sessions for additional information.

4.9.9. transport_lbtrm_receiver_socket_buffer (context)

Value used to set SO_RCVBUF value of the LBT-RM receiver multicast socket. In some cases the OS will not allow all of this value to be used. See the section on socket buffer sizes for platform-dependent information. See also our white paper Topics in High Performance Messaging for background and guidelines on UDP buffer sizing.

4.9.10. transport_lbtrm_send_naks (receiver)

For LBT-RM sessions only. This flag indicates whether LBT-RM should send negative acknowledgements (NAKs) for missing packets or not. This option affects the transport session underlying the receiver rather than the receiver itself. The transport session uses the value from the first receiver created on the session and ignores subsequent receivers. Refer to Receiver Configuration and Transport Sessions for additional information.

4.9.11. transport_lbtrm_source_socket_buffer (context)

Value used to set SO_SNDBUF value of the LBT-RM send multicast socket. In some cases the OS will not allow all of this value to be used. See the section on socket buffer sizes for platform-dependent information. A value of 0 instructs UM to use the OS default.

4.9.12. transport_lbtrm_transmission_window_limit (source)

Caps the total amount of memory that a transmission window uses, which includes data and overhead. For example, if the transport_lbtrm_transmission_window_size is 24 MB (default) and the source sends 20 byte messages with the "flush" flag, the actual amount of memory used can approximate 300 MB. The default value of this option does not limit the transmission window.

4.9.13. transport_lbtrm_transmission_window_size (source)

The maximum amount of buffered data that the LBT-RM source is allowed to retain for retransmissions. The minimum valid value is 65,536 bytes. This option affects the transport session underlying the source rather than the source itself. The transport session uses the value from the first source created on the session and ignores subsequent sources. Refer to Source Configuration and Transport Sessions for additional information.