babel-rtt-options-en.md 8.5 KB
layout: page
title: Babel's RTT options
permalink: /blog/babel-rtt-options-en/
keywords: babel,babel rtt,babeld,babeld rtt,bird rtt,bird babel rtt
description: How can I set babel's RTT function? What do rtt-min, rtt-max and rtt-cost / max-rtt-penalty mean?
lang: en
feed: true
date: 2024-07-17 23:00:00 +0100
Babel is a "plug-and-play" routing protocol and has a Round Trip Time (RTT) feature. This feature makes it possible to determine the costs to the neighboring nodes based on the RTT. The RTT is the time it takes a packet to get to the other node and back.
Encounter with RTT
When I first heard about it, I naturally thought it was a great feature and didn't think you could set more than “off” or “on” for the RTT feature. However, there are actually four adjustable options with documentation. However, this documentation can be difficult to understand for beginners like me. However, there is a mailing list where you can get help.
bird's babel implementation gets the RTT feature
The RTT feature was initially only available in babeld - the reference implementation. However, it was also implemented in bird with version 2.14. I myself was interested in babel RTT because I use bird as routing daemon and babel as IGP in dn42. I am also a participant in CRXN, which relies entirely on babel as its primary routing protocol.
RX costs = RTT
There are a total of four configuration options: rtt-min, rtt-max, rtt-cost in bird or max-rtt-penalty in babeld and rtt-decay.
When I configured the RTT for the CRXN for the first time, I was very happy to have found the following snippet (unfortunately I can no longer remember where): rxcost 1 rtt-min 1 rtt-max 1001 max-rtt-penalty 1000. In short, this line has the effect that the RX costs are equal to the round trip time and do not go any higher from an RTT of 1s.
Juliusz, the developer of babel, wrote about this:
It is of course possible that these values are not appropriate in your network; however, I fear that the extremely aggressive values that you describe above may cause unnecessary oscillations, especially since BIRD does not yet implement hysteresis on metrics.
From that moment on, I have been thinking about which values would be more practical or better. However, as I am quite lazy and can't play with networks all day, it took me some time to ask further.
Configuration options
In order to choose good parameters, however, it is necessary to understand what the individual configuration options mean:
rtt-min
rtt-min specifies the RTT from which the RTT should influence the RX costs. So if the current RTT is below rtt-min, the RX costs are not changed.
Juliusz said:
rtt-min should be chosen so that all links below rtt-min are local -- the idea is that below rtt-min, it's not worth optimising the path. The default value (10ms) should be fine in most networks.
Example: An rtt-min of 10ms means that the RTT only influences the RX costs when the RTT is greater than 10ms. So if the RTT is currently 6ms, the RX costs remain unaffected by the RTT. However, if the current RTT is 30ms, for example, the costs are increased.
Choice: The rtt-min should be chosen so that it is not smaller than the minimum local RTT. So if two computers in the same data center have an RTT of 4ms, the rtt-min should not be less than 4ms. I personally would not make the rtt-min smaller than the default value of 10ms.
rtt-max
rtt-max specifies from which RTT onwards the RX costs should no longer be influenced - i.e. from which RTT onwards the maximum RTT-specific costs should be added.
Juliusz said:
rtt-max should be larger than all good links in your network -- the idea is that above rtt-max, it's no longer worth optimising the path. In your case, you might want to increase the value to 350ms or so.
Example: If rtt-max is 120ms and the current RTT is 150ms, the RX cost is already at its maximum and will not increase. From rtt-max onwards, all links are "equally bad" and should be avoided.
Choice: The rtt-max should be chosen so that it represents the maximum RTT (preferably with a little room for variation) in the network. So if the maximum RTT in the network varies between 100ms and 130ms, you could choose 150ms as the rtt-max.
rtt-cost / max-rtt-penalty
With rtt-max I wrote that RTL-specific costs are added to the RX costs, but never mentioned how large these actually are. This can be specified with rtt-cost in bird or max-rtt-penalty in babeld. If the RTT is greater than rtt-max, the value of rtt-cost is added to the RX costs. Otherwise, the value is added linearly scaled starting at the RTT of rtt-min.
Juliusz said:
Max-rtt-penalty controls how much Babel will prefer routes with many links but low RTT to routes with few links but hight RTT. The default is fairly conservative, meaning that RTT has only a very small influence on routing. You should set it to 96*n where n is the maximum number of extra links that you're willing to take in order to avoid one high-RTT link.
Example:
The RX costs are configured with 96, the rtt-cost with 100 and rtt-max with 500. The RTT is now 643ms. This means that the RTT is greater than rtt-max and therefore the full rtt-cost is added to the RX costs. The effective cost is therefore 96+100=196.
Choice: It applies that rtt-cost/(rtt-max-rtt-min) indicates the RTT interval in which the RX costs increase by one. For example, with rtt-min of 10, rtt-max of 1000 and rtt-cost of 192, the RX costs increase by one every 5ms in the RTT. You should also bear in mind that too high a value and the use of an incomplete RTT implementation could lead to oscillations and, in the worst case, to route flapping. I therefore personally recommend setting the rtt-cost lower than the rtt-max.
rtt-decay
rtt-decay specifies the extent to which older RTT samples should be taken into account when calculating the RTT. A higher decay means that older RTT samples should be discarded or no longer taken into account. A low decay, on the other hand, means that more older RTT samples should be taken into account.
Juliusz said:
As to rtt-decay, the default value should be fine unless you have a mobile network. Increase it in order to react faster to RTT variations, at the risk of route flaps every time the network has a hiccup.
Choice: If in doubt, use the default value. If you are on the move (e.g. mobile phone or WLAN in train), it is advisable to increase the decay (e.g. to 150).
Konfiguration
In the following examples, the interface crxnbandura is configured with rtt-min of 10ms, rtt-max of 1000ms or 1s, rtt-cost of 192 and rtt-decay of 60.
bird:
protocol babel {
interface "crxnbandura" {
type tunnel;
rtt cost 192;
rtt min 10 ms;
rtt max 1000 ms;
rtt decay 60;
};
ipv6 { /* Stuff */ }
}
For bird, it is possible to select either ms for milliseconds or s for seconds as the unit. It is mandatory to specify a unit.
babeld:
interface crxnbandura type tunnel
interface crxnbandura rtt-min 10
interface crxnbandura rtt-max 1000
interface crxnbandura max-rtt-penality 192
Or in short form:
interface crxnbandura type tunnel rtt-min 10 rtt-max 1000 max-rtt-penality 192
Other networks
re6st mesh network
The re6st mesh network uses the default value (10ms) as rtt-min, 500ms as rtt-max, 5000 as rtt-cost and 125 as rtt-decay. As noted by Juliusz, you should bear in mind that 5000 as rtt-cost is quite high.
My values
As I am currently still experimenting myself, it is difficult for me to make a recommendation. Currently I use 10ms as rtt-min, 1000ms as rtt-max and 2 * 96 as rtt-cost in the CRXN. It should be said that the rtt-max value is probably excessively high, as I have a maximum link RTT of around 350ms. I am also considering switching to 3 * 96 for rtt-cost to better reflect the actual RTT.