Subject: [babel] RTT consensus

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 26 Jul 2019 13:07:37 +0200

1. There appears to be consensus that we keep the current µs granularity.

Good.

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

The alternative is to define a new TLV that contains just a transmit
timestamp and deprecate (but not obsolete -- no flag day) the current
transmit timestamp sub-TLV (attached to a Hello).

We need more thought.

---

From: David Schinazi <[email-masked]>
Date: Fri, 26 Jul 2019 13:40:53 -0400

1. I also prefer keeping microseconds for now

2. I'd recommend keeping this as is and leveraging unscheduled hellos,
since that should work and is backwards compatible. But I don't have a
strong
opinion here since I haven't implemented the RTT extension.

David

On Fri, Jul 26, 2019 at 7:07 AM Juliusz Chroboczek <[email-masked]> wrote:

> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 26 Jul 2019 22:13:06 +0200

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

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

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 30 Jul 2019 16:43:52 -0400

> 1. There appears to be consensus that we keep the current µs granularity.

This was the consensus in the room in Montreal and I haven't seen any
opposition to it but to be sure it's confirmed on this mailing list,
I'll wait until this coming Saturday to formally declare consensus on
that point.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 31 Jul 2019 11:50:18 +0200

> I'll wait until this coming Saturday to formally declare consensus on

Oh, sorry Donald, the title of the mail was badly chosen -- I was merely
attemtping to summarise the Montréal meeting, in order to prompt people to
react if they disagree, not to declare consensus, which is obviously not
my job.

Apologies for the misunderstanding.

-- Juliusz

---

From: Dave Taht <[email-masked]>
Date: Wed, 31 Jul 2019 06:39:07 -0700

Well, I think we do have consensus.

-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 31 Jul 2019 18:01:02 -0400

No problem.

Thanks,
Donald