Why is the need of Retransmission Control (RXC)?How to enable RXC?

Why is the need of Retransmission Control (RXC)?How to enable RXC?

book

Article ID: KB0090894

calendar_today

Updated On:

Products Versions
TIBCO Rendezvous -
Not Applicable -

Description

Resolution:
Motivation
-------------

A receiving daemon is classified as a Chronically-lossy receiver when it consistently misses many packets.  Chronically-lossy receiver causes many retransmission requests.  When a sender daemon retransmits excessively, its data send rate can increase dramatically, which in turn can exhaust network bandwidth.  Hence, the effects of a chronically-lossy receiver may include wasted network bandwidth, wasted CPU resources, and decreased performance of the entire distributed application system.

Retransmission Control (RXC) is a feature of the sending daemon that can help ameliorate the adverse effects of chronically-lossy receivers and locate problem hosts.  When RXC is enabled, it can suppress retransmissions to chronically-lossy receivers, conserving network and CPU resources.

How to enable RXC?
-------------------------

By using one or both parameters, described below, in the sending daemon:

(a). rxc-max-loss

When this parameter is above 0 (value is expressed in percentage which ranges from 0, 100 inclusive), RXC feature is enable; the sending daemon measures loss statistics and compares them against this max. loss threshold to determine a receiver is categorized as chronically-lossy or not.  By default this parameter is set to 0 which means that RXC feature is disabled.  If a receiver daemon is classified as chronically-lossy, the sending daemon will suppress retransmission to the chronically-lossy daemons, meaning that the sending daemon ignores retransmission requests from that receiver.  Sending daemon will issue the RETRANSMISSION.OUTBOUND.SUPPRESSED advisory when it suppresses retransmission requests.

This above paragraph holds true unless -rxc-send-threshold (described below) is also specified.

(b). rxc-send-threshold

In some deployments, it might be acceptable to retransmit to chronically-lossy receivers if the sender’s bandwidth usage remains low.  This parameter is for this flexibility.

For each service, the sending daemon measures its outbound bandwidth usage in bit per seconds.  The sending daemon will not suppress retransmissions to chronically-lossy receivers until its outbound bandwidth usage exceeds –rxc-send-threshold.

In other words, when this parameter is absent (zero value is the default), sending daemon always suppress chronically-lossy receivers.  When this parameter presents and its value is greater than 0, sending daemon only suppress chronically-lossy receivers when the send rate is above –rxc-send-threshold value.  

When the network in questions is back to normal in term of bandwidth availability/functionality and that the receiver daemon is no longer classified as “chronically-lossy”, the sender daemon will resume its retransmission functionality.

Details can be found in Chapter 4 (Rendezvous Daemon) of the TIBCO Rendezvous Administration Guide.

Issue/Introduction

Why is the need of Retransmission Control (RXC)?How to enable RXC?