---
layout: page
title: Babel's RTT Optionen
permalink: /blog/babel-rtt-options-de/
keywords: babel,babel rtt,babeld,babeld rtt,bird rtt,bird babel rtt
description: Wie kann man babel's RTT-Funktion einstellen? Was bedeutet `rtt-min`, `rtt-max` und `rtt-cost` / `max-rtt-penalty`?
lang: de
feed: true
date: 2024-07-17 23:00:00 +0100
---

Babel ist ein "Plug-und-Play" Routing Protokoll und hat ein Round Trip Time (RTT) Feature. Dieses Feature ermöglicht es, die Kosten zu den benachbarten Knoten anhand der RTT zu bestimmen. Dabei ist die RTT die Zeit, welche ein Paket braucht, zum anderen Knoten hin und zurückzukommen.

## Begegnung mit RTT

Als ich das erste Mal davon gehört habe, fand ich die Funktion natürlich sehr toll und dachte nicht, dass man beim RTT Feature mehr als "aus" oder "ein" einstellen kann. Tatsächlich gibt es jedoch vier einstellbare Optionen mit Dokumentation. Diese Dokumentation kann für Anfänger in diesem Bereich, wie mir, jedoch schwer zu verstehen sein. Es gibt jedoch eine Mailingliste, auf der man sehr nette Hilfe erhält.

## bird's babel Implementierung bekommt das RTT Feature 

Das RTT Feature war anfangs nur in babeld - der Referenzimplementierung - verfügbar. Es wurde jedoch auch mit [Version 2.14 in bird implementiert](https://bird.network.cz/pipermail/bird-users/2023-October/017164.html). Ich selber hatte Interesse an babel RTT, da ich im dn42 bird als Routing Dämon und babel als IGP verwende. Des Weiteren bin ich Teilnehmer im CRXN, welches als primäres Routing Protokoll ganz auf babel setzt.

## RX Kosten = RTT

Es gibt insgesamt vier Konfigurationsoptionen: `rtt-min`, `rtt-max`, `rtt-cost` in bird bzw. `max-rtt-penalty` in babeld und `rtt-decay`.

Als ich für das CRXN das RTT das erste Mal konfigurierte, war ich sehr froh, folgenden Schnipsel gefunden zu haben (ich kann mich leider nicht mehr erinnern, wo): `rxcost 1 rtt-min 1 rtt-max 1001 max-rtt-penalty 1000`. Diese Zeile bewirkt kurz gesagt, dass die RX-Kosten gleich der Round Trip Time sind und ab einer RTT von 1s nicht mehr höher gehen.

Juliusz, der Entwickler von babel, [schrieb dazu](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.

Seit diesem Moment an habe ich überlegt, welche Werte sinnvoller bzw. besser wären. Da ich jedoch recht faul bin und nicht den ganzen Tag mit Netzwerken spielen kann, hat es einige Zeit gedauert, bis ich weiter nachgefragt habe.

## Konfigurationsoptionen

Um gute Parameter zu wählen, ist es jedoch notwendig, zu verstehen, was die einzelnen Konfigurationsoptionen bedeuten:

### `rtt-min`

`rtt-min` gibt an, ab welchem RTT, das RTT die RX-Kosten beeinflussen sollen. Wenn der aktuelle RTT also unter `rtt-min` ist, werden die RX-Kosten nicht verändert.

Juliusz [sagte dazu](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.

Beispiel: Ein `rtt-min` von 10ms bedeutet, dass das RTT die RX-Kosten erst beeinflusst, wenn der RTT größer 10ms. Wenn der RTT aktuell also aktuell 6ms ist, bleiben die RX-Kosten vom RTT unbeeinflusst. Wenn der aktuelle RTT allerdings beispielsweise 30ms ist, werden die Kosten erhöht.

Wahl: Das `rtt-min` sollte so gewählt werden, dass es nicht kleiner ist als die minimale lokale RTT ist. Wenn also zwei Computer im gleichen Datenzentrum eine RTT von 4ms aufweisen, sollte die `rtt-min` nicht kleiner als 4ms sein. Ich persönlich würde des Weiteren die `rtt-min` nicht kleiner als den Standardwert von 10ms machen.

### `rtt-max`

`rtt-max` gibt an, ab welchem RTT die RX-Kosten nicht mehr beeinflusst werden sollen - also ab welchem RTT die maximalen RTT-spezifischen Kosten addiert werden sollen.

Juliusz [sagte dazu](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.

Beispiel: Wenn `rtt-max` 120ms und der aktuelle RTT 150ms ist, dass, die RX-Kosten bereits maximal sind und nicht mehr steigen. Ab dem `rtt-max` sind alle Links "gleich schlecht" und sollten vermieden werden.

Wahl: Das `rtt-max` sollte so gewählt werden, dass es die maximale RTT (am besten mit etwas Luft nach oben) im Netzwerk darstellt. Wenn die maximale RTT im Netzwerk also zwischen 100ms und 130ms variiert, so könnte man 150ms als `rtt-max` wählen.

### `rtt-cost` / `max-rtt-penalty`

Bei `rtt-max` habe ich geschrieben, dass RTL-spezifische Kosten zu den RX-Kosten addiert werden, jedoch nie erwähnt, wie groß diese eigentlich sind. Dies kann man mit `rtt-cost` in bird bzw. `max-rtt-penalty` in babeld festlegen. Wenn der RTT größer als `rtt-max` ist, wird zu den RX-Kosten also der Wert von `rtt-cost` addiert. Ansonsten wird der Wert beginnend beim RTT von `rtt-min` linear skaliert addiert.

Juliusz [sagte dazu](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.

Beispiel:
Die RX-Kosten sind mit `96` konfiguriert, die `rtt-cost` mit `100` und `rtt-max` mit `500`. Die RTT ist nun 643ms. Dies bedeutet, dass die RTT größer als `rtt-max` ist und somit die volle `rtt-cost` auf die RX-Kosten addiert werden. Die effektiven Kosten belaufen sich also auf 96+100=196.

Wahl: Es gilt, dass `rtt-cost`/(`rtt-max`-`rtt-min`) angibt, in welchem Intervall abhängig vom RTT sich die RX-Kosten erhöhen. Bei `rtt-min` von 10, `rtt-max` von 1000 und `rtt-cost` von 192, erhöhen sich beispielsweise die RX-Kosten jede 5ms im RTT um Eins. Des Weiteren sollte man bedenken, dass ein zu hoher Wert und die Verwendung von einer nicht vollständigen RTT Implementierung zu Schwingungen und im schlimmsten Fall dann auch zu Route Flapping führen könnte. Ich persönlich empfehle daher, die `rtt-cost` niedriger als die `rtt-max` zu wählen.

### `rtt-decay`

`rtt-decay` gibt an, inwiefern ältere RTT Proben bei der Berechnung des RTT berücksichtigt werden sollen. Ein höheres Decay bedeutet, dass ältere RTT Proben verworfen bzw. nicht mehr berücksichtigt werden sollen. Ein niedriges Decay bedeutet dagegen, dass mehr ältere RTT Proben berücksichtigt werden sollen.

Juliusz [sagte dazu](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.

Wahl: Im Zweifelsfall: Nehme den Standardwert. Wenn du mobil (beispielsweise Mobilfunk oder Bahn-WLAN) unterwegs bist, empfiehlt es sich, das Decay zu erhöhen (beispielsweise auf 150).

## Konfiguration

In folgenden Beispielen wird das Interface `crxnbandura` mit `rtt-min` von 10ms, `rtt-max` mit 1000ms bzw. 1s, `rtt-cost` von 192 und `rtt-decay` von 60 konfiguriert.

bird:
```bird
protocol babel {
    interface "crxnbandura" {
        type tunnel;
        rtt cost 192;
        rtt min 10 ms;
        rtt max 1000 ms;
        rtt decay 60;
    };

    ipv6 { /* Stuff */ }
}
```
Bei bird besteht die Möglichkeit als Einheit entweder `ms` für Milisekunden oder `s` für Sekunden zu wählen. Es ist verpflichtend eine Einheit anzugeben.

babeld:
```babeld
interface crxnbandura type tunnel
interface crxnbandura rtt-min 10
interface crxnbandura rtt-max 1000
interface crxnbandura max-rtt-penality 192
```
Oder in Kurzform:
```babeld
interface crxnbandura type tunnel rtt-min 10 rtt-max 1000 max-rtt-penality 192
```

## Andere Netzwerke

### re6st mesh network

Das [re6st mesh network](https://lab.nexedi.com/nexedi/re6stnet) [verwendet](https://alioth-lists.debian.net/pipermail/babel-users/2024-July/004176.html) den Standardwert (10ms) als `rtt-min`, 500ms als `rtt-max`, 5000 als `rtt-cost` und 125 als `rtt-decay`. Dabei sollte man, wie von [Juliusz angemerkt](https://alioth-lists.debian.net/pipermail/babel-users/2024-July/004179.html), bedenken, dass 5000 als `rtt-cost` recht hoch ist.

## Meine Werte

Da ich aktuell selber noch experimentiere, kann ich selber nur schlecht eine Empfehlung abgeben. **Aktuell** verwende ich im CRXN 10ms als `rtt-min`, 1000ms als `rtt-max` und 2 * 96 als `rtt-cost`. Dazu sollte man sagen, dass der `rtt-max` Wert vermutlich übertrieben ist, da ich als maximale Link RTT etwa 350ms habe. Des Weiteren überlege ich auf 3 * 96 für `rtt-cost` umzusteigen, um die tatsächliche RTT besser widerzuspiegeln.
