Juliusz Chroboczek <jch@irif.fr> 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