Subject: [babel] Unicast Hellos -- conclusions so far

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 07 Apr 2017 16:59:07 +0200

Thanks to all for the discussion.  Here's my current thinking:

1. There are two kinds of Hellos, explicitly distinguished.  They are
called Hello and Unicast Hello.  Hello MUST be sent over multicast or
multi-unicast, Unicast Hello MUST be sent over unicast.  On the sending
side, there's a per-interface seqno for Hello, and a per-peer seqno for
Unicast Hello.  It is legal to never send Unicast Hellos, in which case
the per-peer seqno is not needed.

2. The on-the-wire encoding remains to be determined.  Markus and myself
are in favour of a separate TLV, David prefers a flag in Hello, Toke and
Margaret havn't expressed an opinion (these are the people who are known
to have an implementation).  I'll treat this point in a separate mail.

3. The interval field carries a promise to send a Hello of the same type
within the given interval.  (The alternative, a Hello of any kind within
the interval, is not useful -- it doesn't allow to do link estimation
reliably.)

4. Unicast Hellos are allowed to set Interval to 0, meaning that this is
an unscheduled Hello (used e.g. for carrying a timestamp sub-TLV, not
necessarily for link maintenance) and we don't promise to send another
one.  I haven't decided whether allow Interval 0 in ordinary (multicast)
Hellos.

5. Informational algorithms for Appendix A2:

  for wired links:
    - perform 2/3 for multicast hellos;
    - perform 2/3 for unicast hellos;
    - assume link is up if either instance of 2/3 says it's up.

  for wireless links:
    - perform ETX for multicast hellos;
    - perform 2/3 for unicast hellos;
    - if multicast ETX is finite, use that;
    - otherwise, if unicast 2/3 says the link is up, assume the link is up
      but with a horribly high cost.

We'll want to have at least two independent interoperable implementations
in time for Prague.  Do we have consensus?

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Fri, 07 Apr 2017 09:17:18 -0700

I agree with this plan.

Regarding allowing Interval = 0, I think the rationale to allow or
disallow them applies equally to unicast and multicast, so it
should be allowed or disallowed equally for both types of Hellos.
Or tell me if I'm missing something.

David

> On Apr 7, 2017, at 07:59, Juliusz Chroboczek <[email-masked]> wrote:
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

---

From: Teco Boot <[email-masked]>
Date: Sat, 8 Apr 2017 10:01:09 +0200

> Op 7 apr. 2017, om 16:59 heeft Juliusz Chroboczek <[email-masked]> het volgende geschreven:
> 

Appendix A2 is for Cost Computation, right? 
Link Up depends on IHU.
OK, link from Hello sender to Hello receiver is assumed up.

Or is this "Link Up" equivalent to "it has recently heard a Hello" 
in rfc6126bis section-2.1? I couldn't find a precise definition 
that quickly. What means recently?

>      but with a horribly high cost.

Same comment.

Teco

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 08 Apr 2017 16:14:05 +0200

> that quickly.

Yes, that's what I meant.

> What means recently?

In the reference implementation -- within three times the interval
advertised by the most recent Hello.

-- Juliusz

---

From: [email-masked]
Date: Sat, 8 Apr 2017 10:26:21 -0400

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.

It has the benefit of being very simple to implement, and being completely compatible with the current protocol.  Why do we want to support a mix of unicast and multicast hellos on a single link?

Margaret

Sent from my iPhone

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 08 Apr 2017 17:29:49 +0200

> 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

---

From: Ted Lemon <[email-masked]>
Date: Sat, 8 Apr 2017 19:32:17 -0400

> out-of-band discovery in your implementation.)

Is there actually a need for in-band discovery if you have HNCP?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 09 Apr 2017 02:11:04 +0200

> Is there actually a need for in-band discovery if you have HNCP?

Babel is used in places where HNCP doesn't run (such as wireless community
meshes).  Even if HNCP is available, in-band discovery makes for better
fate-sharing properties.  And I'm rather attached to having the coupling
between the protocols as loose as possible -- right now the coupling is
very clean and elegant, see slide 7 of

    https://www.ietf.org/proceedings/93/slides/slides-93-homenet-2.pdf

I think that giving up on in-band discovery would make Babel a much more
limited protocol.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Sat, 8 Apr 2017 20:56:18 -0400

On Apr 8, 2017, at 8:11 PM, Juliusz Chroboczek <[email-masked]> wrote:
> Even if HNCP is available, in-band discovery makes for better
> fate-sharing properties.

Right, forgot about that.  Thanks.   :)

---

From: Gabriel Kerneis <[email-masked]>
Date: Tue, 18 Apr 2017 15:38:42 +0200

On Fri, Apr 7, 2017 at 4:59 PM, Juliusz Chroboczek <[email-masked]> wrote:
> one.

This needs clarification. What should a receiver do upon seeing a first
Hello with Interval=42 followed, in a timely manner, by one with Interval=0:

   - does the latter hello count as a fulfillment of the promise made by
   the former one?
   - does it cancel the promise made by the former one?
   - is it simply ignored as far as link estimation is concerned?

Best,
Gabriel

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 18 Apr 2017 16:19:15 +0200

> This needs clarification.

Yes.

> What should a receiver do upon seeing a first Hello with Interval=42
> followed, in a timely manner, by one with Interval=0:

> * does the latter hello count as a fulfillment of the promise made by the
>   former one?
> * does it cancel the promise made by the former one?
> * is it simply ignored as far as link estimation is concerned?

I'd say 1 + 3: it fulfills the promise but doesn't establish a new deadline.

-- Juliusz