---
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](https://bird.network.cz/pipermail/bird-users/2023-October/017164.html). 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](https://bird.network.cz/pipermail/bird-users/2023-October/017216.html):
>  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](https://bird.network.cz/pipermail/bird-users/2024-July/017764.html):
> 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](https://bird.network.cz/pipermail/bird-users/2024-July/017764.html):
> 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](https://bird.network.cz/pipermail/bird-users/2024-July/017766.html):
> 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](https://bird.network.cz/pipermail/bird-users/2024-July/017766.html):
> 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:
```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:
```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:
```babeld
interface crxnbandura type tunnel rtt-min 10 rtt-max 1000 max-rtt-penality 192
```

## Other networks

### re6st mesh network

The [re6st mesh network](https://lab.nexedi.com/nexedi/re6stnet) [uses](https://alioth-lists.debian.net/pipermail/babel-users/2024-July/004176.html) the default value (10ms) as `rtt-min`, 500ms as `rtt-max`, 5000 as `rtt-cost` and 125 as `rtt-decay`. As noted by [Juliusz](https://alioth-lists.debian.net/pipermail/babel-users/2024-July/004179.html), 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.
