[babel] Rationale for mixed unicast/multicast Hellos

[Juliusz Chroboczek <[e-mail]>]

> I still think we would do better, in the limited cases where Unicast
> hellos are needed because broadcast/multicast hellos are not possible
> (secure links between neighbors or NBMA links) to just serialize any
> hellos that would have been broadcast on those links with the
> serialization feature enabled on a link-by-link basis.

I know that's your use case, Margaret, but I'm trying to design a protocol
extension that meets the three uses cases outlined in my mail dated
3 April 2017.  I'll get into a little more detail below.

> It has the benefit of being very simple to implement, and being
> completely compatible with the current protocol.

Agreed.

> Why do we want to support a mix of unicast and multicast hellos on
> a single link?

The basic issue is that multicast Hellos are the only way to perform
in-band discovery.  (Not a concern for you, Margaret, since you do
out-of-band discovery in your implementation.)

Consider an implementation that performs authentication by sending all the
protocol traffic over unicast and protecting it with DTLS.  Such an
implementation would send updates aggregated into large unicast packets,
and occasionally piggyback a Hello/IHU pair into such a unicast packet.
However, it would still want to announce itself to any new peers, so
occasionally it would send an unauthentified multicast Hello on each
interface.

Now it would be possible to require that Hellos be sent to all peers on an
interface, whether over multicast or multiple unicast, so that seqnos
remain in sync.  (I believe you're the one who suggested that, Margaret,
or at least you're the person who gave me the idea.)  I've considered
that, but it has four problems: it complicates the implementation by
adding a special case to the packet scheduler, it requires sending extra
traffic to some unicast peers (think battery-powered devices that have
a higher update interval than other peers), it breaks multicast
link-quality estimation (in 802.11, ETX only works well over multicast),
and finally it breaks the RTT extension (which is only effective if Hello
and IHU are sent in the same packet, so the receiver can correlate
timestamps).

Altogether, I think that adding a new packet type for Unicast Hellos is
the right tradeoff: it makes a weakly compatible protocol change (legacy
implementations will fail to associate with unicast-only peers, but
nothing will break), and finally it's conceptually manageable, without any
fragile special cases.

-- Juliusz