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

[Toke Høiland-Jørgensen <[e-mail]>]

Juliusz Chroboczek <[e-mail]> writes:

>> 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.)

I'd be delighted to hear the (real?) explanation for that!

>> 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.

Juliusz, I also seem to recall you mentioning to me at some point that
the RTT increasing due to congestion actually makes the RTT extension
useful as a way of picking the least-congested route as well (as a kind
of unintentional side effect due to exactly what Ondrej mentioned
above). Or am I misremembering?

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

I assume you meant 'running minimum' here?

>> 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.

Note that the RTT-based cost algorithm doesn't replace the ETX/k-from-j,
it just adds an additional configurable penalty on top.

>> 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.

I implemented the RTT extension the same way in Bird: The 'tunnel'
interface type just sets a default RTT cost or 96 (and is otherwise
identical to 'wired'), and there's a separate config option to
explicitly set the RTT cost. In fact, I just mirrored all the babeld
config options related to RTT, just adapted to Bird syntax :)

However, there is no explicit config option in Bird for the metric
computation algorithm (i.e., ETX/k-from-j). I guess we should add one :)

BTW, I'm also planning to add some infrastructure to Bird to
automatically guess the interface type, and have Babel use that to set a
reasonable default. I believe babeld has something similar (although I
seem to recall something about the wireless detection having bitrotted
slightly? Or was that only the channel information?).

-Toke