[babel] Summary of the top-secret unicast Hellos meeting

[Juliusz Chroboczek <[e-mail]>]

Dear all,

TL;DR version: we keep unicast Hellos but make them optional.  We write
this up in the rfc6126bis draft, and see how well it reads.  We then
request feedback on the list.

You may now skip the rest of this mail.

First, some background.  Hellos in Babel carry a monotonically increasing
sequence number (seqno) which must be synchronised between sender and
receiver.  Since there is a single seqno per outgoing interface, every
Hello MUST be sent to all neighbours on each interface -- either over
multicast (RFC 6126) or over exhaustive unicast (allowed in rfc6126bis,
insight due to Margaret).  There is some desire -- expressed most vocally
by David and Toke -- to send Hellos over unicast to different neighbours
at different times, which requires either getting rid of the seqno or
adding a per-neighbour outgoing counter in addition to the per-interface
counter.

Russ White sent me a series of (private) mails that gave some insight into
the issue.  In general, the Babel protocol specifies only very loose
coupling between sender and receiver, which makes the protocol easy to
evolve in a compatible manner.  Not so with the Hello sub-protocol: the
sender and receiver seqnos are tightly coupled, which makes this
sub-protocol difficult to evolve.  I think this analysis is spot on.

We started the meeting with me giving some background into the problem
(roughly speaking the two paragraphs above).  We then did some
brainstorming about what solutions we see: a new type of "unicast" Hello
(David and Toke's proposal, in the current version of the draft).  A new
type of seqno-less Hello (my proposal, but it has a serious flaw -- Hello
and seqno-less Hello would support different sets of sub-TLVs).  Removing
the seqno from Hellos and bumping the protocol version number to 3
(Matthieu's proposal, rejected since we're happy with version 2).  As well
as some more convoluted ideas (names of the authors withheld in order to
protect the guilty, but I'll be happy to gossip over a beer).

During this discussion, there were a few interesting insights.  Margaret
expressed some doubts about the usefulness of different Hello intervals
for different neighbours.  She noted that our intuition that one should
reduce the Hello interval for marginal neighbours might be incorrect:
quite the opposite, since with a shorter interval short-term outages might
be spuriously detected as link drops.  Agreed, although the length of the
window is not necessarily related to the interval.  More experimentation
and experience is needed.

David expressed some ideas about using driver data instead of Hello drop
rate.  We agreed that this might be mentioned in Appendix C, but is only
reasonable for implementors that control the whole OS.  (I wonder who that
can be.)

Matthieu suggests that we might want to test both multicast and unicast
reachability before using a neighbour for routing, since unicast-only link
failures happen sometimes.  David noticied that IHU does that.  Matthieu
noticed that IHU can be sent over multicast too (and is in the reference
implementation, ndlr).

IHU with AE 0 is used by David over unicast only.  He's in favour of
leaving it in the protocol, but forbidding it for multicast.  I disagree,
I'll write that up on the list.

At this point, the discussion was moving away from the Unicast hellos, so
we decided that we don't have an idea that is significantly better than
the current David-Toke proposal (there was one dissenting voice).  We went
back to my mail of yesterday evening, and there was clear consensus on the
following two points:

  - we leave unicast Hellos in (no to proposal 1);
  - we don't delegate them to a future ducument (no to proposal 2).

Right now, the document contains a mild contradiction: you MUST be able to
parse unicast Hellos, but you are allowed to essentially ignore them.  We
have agreed that we're going to tweak the document to make unicast Hellos
more optional, and see whether we can make it so it gives more convincing
advice to the implementor.

Therefore, we'll try to write up proposal 3 -- keep the packet format, but
make it somewhat more optional.  The actual protocol will remain mostly
unchanges, only the level of MUST-ness will shift.

Thanks to everyone,

-- Juliusz