RTT Multiplier

The RTT Multiplier is a value used in the calculation of SRT Latency. It reflects the relationship between the degree of congestion on a network and the Round Trip Time. As network congestion increases, the rate of exchange of SRT control packets (as well as retransmission of lost packets) also increases. Each of these exchanges is limited by the RTT for that channel, and so to compensate SRT Latency must be increased. The factor that determines this increase is the RTT Multiplier, such that:

SRT Latency = RTT Multiplier * RTT

The RTT Multiplier is an indication, based on the characteristics of the current link, of the maximum number of times SRT will try to resend a packet before giving up. On a fairly good network (0.1 to 0.2% loss), with no burst loss, a “rule of thumb” for this value would be approximately 4. Generally speaking, the overhead needed to cope with continuous packet loss is really quite low at low loss rates.

Important Considerations

As described in the section on Packet Loss Rate, SRT retransmissions result from two types of packet loss: Constant Loss, where a channel is losing packets at a constant rate, and Burst Loss, where a channel is losing multiple consecutive packets. 

Depending on your specific network conditions, your Latency and Bandwidth Overhead need to change. Latency is a function of your round trip time and an RTT multiplier value, which is relatively constant, depending on the background loss rate. If you've got a Constant Loss, it gives you a certain unique value for Latency. But there's a second dependency. If you lose a whole group of consecutive packets (Burst Loss) you need additional Bandwidth Overhead to recover from it.

Consider two scenarios. In the first, you're losing a specific number of packets over a given period of time. For example, you are constantly losing 5% of the packets, but distributed over time. And that increases the chances that retransmitted packets might be lost. To overcome this constant, distributed packet loss, increasing the Latency value helps because it increases the chances of recovering retransmitted packets.

And then we have the other scenario where a you lose an entire block of packets. For example, not a single packet is received over a period of 100 milliseconds. Once the link is back, your stream picks up where it left off, transferring let’s say at 10 megabits/sec. But you have to retransmit that missing block of 100 milliseconds on top of the stream. And maybe there is still some packet loss, so more retransmissions. So you have a large amount of data to be transported within the latency buffer window. You may have to double the data rate for a short period of time.

These two scenarios have different overhead requirements (for retransmissions) depending on your network delay, and so they dominate at different latencies. For a lower latency the overhead due to burst loss is going to dominate. For higher latency, the overhead due to continuous loss of traffic would dominate. If you have a high network loss rate, you need more latency to recover, but then you don't have to worry so much about burst loss. But at a low network loss rate, over a long period of time there is a statistical probability that a burst loss may happen instantaneously, lasting for tens of milliseconds. To manage such bursts, you have to be able to transmit at very high rates in a very short period of time, because your SRT latency in these cases is usually very low — you can't get something for nothing. If you don't set your overhead to be high at very low SRT latencies, then you won't be able to recover quickly enough when there is a large outage.

The table below shows estimated RTT Multiplier, Bandwidth Overhead, and SRT Latency values based on a model that considers the constant loss scenario. Constant loss requires higher overhead values as packet loss increases. This phenomenon informs the values below.

Note

As noted above, the table below assumes constant loss. However, in the event of burst loss, a higher overhead is required when the RTT multiplier is low, otherwise SRT cannot recover the lost data within one RTT period.

Note

The numbers in this table are intended as conservative guidance for achieving the greatest reliability possible. They are based on a model using an earlier version of SRT. Keep in mind that certain devices have better SRT performance profiles than others, and newer SRT versions may incorporate more efficient retransmission algorithms.