Babel RTT mechanism [Was: [RESEND PATCH v3] Babel: allow choosing link quality estimation] algorithm]

[Juliusz Chroboczek]

>> And babeld the reference implementation also allows enabling link quality
>> estimation and the RTT extension at the same time, matching the current
>> behavior of bird.

Exactly right.

> Considering that ETX estimates number of retransmissions, then for
> algorithm that takes into account both RTT and packet loss it makes more
> sense to have RTT metric multiplied by ETX coeficient?

The current algorithm is described here:

  https://datatracker.ietf.org/doc/html/draft-ietf-babel-rtt-extension

My intuition is that it doesn't matter much.  The goal is not to have an
accurate model of reality, the goal is to choose optimal paths.  And
I would guess that in any realistic topology, the two algorithms will
yield the same or almost the same set of paths.

It looks like your intuition is different from mine: that's exciting, and
it means that we need to design an experiment in order to find out who's
right.  Can you design a topology in which the algorithm described in the
draft and the algorithm that you propose yield different sets of paths,
and where your proposed algorithm leads to significantly better performance?

If it turns out that you're right, I'll be thrilled to write a successor
RFC, perhaps with you as co-author.

-- Juliusz