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

[Ondrej Zajicek <[e-mail]>]

On Fri, Apr 22, 2022 at 08:06:24PM +0200, Juliusz Chroboczek wrote:
> > 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 guess that how much that works in practice depends on many circumstances.

For example, consider this case: a mobile device connected by wifi to
local AP, with VPNs to two endpoints, one local (< 1ms base latency), one
in different town (~10ms base latency), but the communication is subject
to wifi latency, which is noisy (mostly ~1ms, but in <5% cases there is
100-1000ms spike). Then both exponencial running averages are random
variables with expected value shifted by 10 ms, but with big enough
variance than it may often come out in reverse.

(that is, btw, the real use case how i would use it)

It is true that exponential running average is nice and elegant
algorithm, so perhaps instead of using running minimum over many values,
one could just use minimum over small number of latest values (say 8-16)
as a pre-filter and use exponential average on result. I think that
computational cost is negligible for such change and it would suppress
effect of latency spikes common in wifi networks.


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


IMHO base-RTT-based cost make sense as a reasonable initial choice for
regular IGP on regular (wired) links for a geographically spread out
network (e.g. ISP backbone) in the absence of an explicit policy.

Also, it would make sense to use RTT as an AIGP metric in public BGP, as
it does not require coordination on metric scale and would eliminate some
routing oddities.

But in both these case one would probably suffice with static rtt
measurement during adjacency establishment instead of continuous
measurement.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: [e-mail])
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."