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

[Toke Høiland-Jørgensen]

Daniel Gröber <dxld at darkboxed.org> writes:

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

I meant read-only. I agree that the filters shouldn't be able to modify
the smoothed metric. Another question is if the smoothing should
incorporate any changes to the metric that the filters do? It probably
should, right?

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

The reason I say it doesn't is that the smoothing code updates the
smoothed metric of not just the new route being announced, but also of
all the routes it's being compared against. To do this in the nest case
I guess we'd need to have this logic inside babel_rte_better(), which
means we can't include the smoothed metric as an attribute. That may be
OK, but I'm not actually sure how the nest comparison works (when we
announce a new route, does the rte_better function get called pairwise
against every other candidate with the same prefix, or just against the
current best?).

-Toke