Re: [babel] RTT consensus

[Juliusz Chroboczek <[e-mail]>]

> 2. There is some misgivings about attaching transmit timestamps to Hello
>    packets

As an additional data point, I've just implemented sending unscheduled
Hellos whenever an IHU is sent in a packet without a regular Hello.  My
conclusion is that a new TLV is unnecessary if we can assume that everyone
implements receiving of unscheduled Hellos correctly.  (In particular, if
the Hello history is empty, then we must be careful to set a tiny timeout
if we receive an unscheduled Hello, since the sender's Hello rate is unknown.)

For the interested bodies, here's the detail.  There are two main patches:

  https://github.com/jech/babeld/commit/0db7e63b976643dc9b943772ab50473ee4db74bf

This restructures the Hello formatting code so that it knows how to format
unicast and unscheduled Hellos (previously, babeld could parse such Hellos
but couldn't send them).  It also adds a flag to the send_*_hello
functions that tells them what to do if there already is a Hello in the
packet (either split the packet or ignore the new Hello).

  https://github.com/jech/babeld/commit/bc26b858c27fa535ee4507970bb3957f2a2b9b06

This inserts an unscheduled Hello whenever we ship out an IHU in a packet
without a Hello.

Additionally, the following patch fixes the loss estimator to handle the
case where a neighbour only sends unscheduled Hellos of a given kind
(unicast or multicast).  In that case, we must expire the history quickly,
since we don't know the sender's sending rate, and might underestimate the
loss rate otherwise (and therefore spuriously select a bad link).

  https://github.com/jech/babeld/commit/928454f51e80caf8f16fb5b01b8c8b53fe245bec

-- Juliusz