[PATCH 0/3] babel: Add support for the RTT extension

[Daniel Gröber]

Hi Toke,

On Mon, Feb 27, 2023 at 12:14:23AM +0100, Toke Høiland-Jørgensen wrote:
> > To clarify: it's really only the metric smoothing patch that's in conflict
> > with my patch. I would advocate for merging only the other two patches for
> > now while we figure out how to rework the smoothing on top of my patch. I'm
> > happy to do the rework we just need to come up with a plan for that :)
> 
> Hmm, I think the way to handle this is basically:
> 
> - Add the smoothed metric as a new route attribute (so it's also
>   available to filters)

I think doing that is a bad idea. If we keep filters from changing this we
might just be able to optimize by only announcing smooted metric updates
when the resulting route would actually be better than the currently
selected one.

If we let filters meddle with this however that becomes impossible. Unless
you were thinking of a r/o attribute?

> - Change babel_rte_better() to incorporate the smoothed metric (from the
>   attribute) in its comparison
> - Change the decay logic to be timer-based instead of calculating the
>   smoothed metric on demand
> 
> That last bit is probably the biggest change. We can't really do the
> cached on-demand calculation of the smoothed metric if we're sticking it
> in an attribute.

Can you elaborate on why you think that's not possible? The way I see it
there isn't much harm in the smooted metric attribute being outdated so
long as we ensure we announce an update if an actually better route comes
along.

Suggesting this kind of seems like we're brining back the select_route
function, but I think we can do it in a way that only looks at the route
that changed without iterating over all of them, the nest will do that bit
for us now.

--Daniel