Juliusz Chroboczek <j...@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
