Fwd: Re: [babel] RFT: Babel RTT extension in Bird

[Toke Høiland-Jørgensen]

Forwarding on behalf of Juliusz since he's not subscribed to bird-users.

-Toke


-------- Original Message --------
From: Juliusz Chroboczek <jch at irif.fr>
Sent: 22 April 2022 20:06:24 CEST
To: Ondrej Zajicek <santiago at crfreenet.org>
Cc: "Toke Høiland-Jørgensen" <toke at toke.dk>, bird-users at network.cz, babel-users at alioth-lists.debian.net, babel at ietf.org
Subject: Re: [babel] RFT: Babel RTT extension in Bird

> That seems like an interesting idea, especially for things like
> automatically switching between multiple Wireguard tunnel concentrators.

That's exactly the application that it was designed for.  For some
background, please see

  https://arxiv.org/pdf/1403.3488.pdf

(I never managed to publish this paper, and rightly so -- it's not a very
good paper, since I don't fully understand why the smoothing+hysteresis
works as well as it does.)

> Did not yet checked the code how smoothing is done here, but seems to me
> that considering:
> 
> 1) There is baseline RTT from distance / speed of propagation
> 2) There is one-side noise from congestion
> 3) The metric should be based on 1) and suppress effects of 2)
> 
> It would make sense to use something like running minimum instead of
> running average.

Yes, it would make sense.  The reason why we calculate an exponential
average is that it is cheaper to compute, and works quite well in
practice.  The goal here is not to compute an accurate metric, it is to
reliably choose the best route: the metric only needs to be accurate
enough to ensure that the right route is being picked.

I agree that we should compare with a running average.  I might do so if
I ever decide to revive that paper.

> There is one thing that is IMHO a bit strange, type wired/wireless/tunnel
> option is just an indirect way of set k-from-j / ETX / RTT-based cost
> algorithm.

[...]

> But RTT-based cost have applications that are unrelated to tunnels.

I'd be very interested if you could give me some examples, in case
I decide to revive the paper above.

> Seems to me that it would make sense to have a direct option to set the
> cost algorithm (and just that), while the 'type' option would provide
> reasonable default for that (and possibly other options).

In babeld (the standalone implementation of Babel, the interface type is
a macro that sets both the base metric and the metric algorithm; the two
can be set separately if desired by the user.  However, we have found that
the "interface type" abstraction is easier to get right for our users.

-- Juliusz