Subject: [babel] Unicast Hellos again

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 04 Feb 2018 16:28:52 +0100

Hi,

I'm looking at my implementation of rfc6126bis, and I'm still not sure
I like Uniast Hellos.

The current specification says that Unicast Hellos MAY be silently
ignored, and that an implementation SHOULD send periodic Multicast Hellos.
But then, if an implementation sends Multicast Hellos, why would it
additionally send Unicast Hellos?

Note further that:

  (1) ordinary Hellos can be sent over unicast, although they must be sent to
      all neighbours on a given interface at roughly the same time;
  (2) Unicast Hellos cannot be used for discovery, so an implementation
      needs to use Multicast Hellos at any rate unless discovery is
      performed by means outside of the protocol (e.g. statically
      configured set of neighbours).  Note however that discovery can be
      done using unscheduled Hellos.

Toke, David, I'm particularly interested in hearing about your implementation
experiences.

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Mon, 05 Feb 2018 09:06:06 -0800

Hi Juliusz,

For the Homenet use case, I would consider using unscheduled multicast hellos
for discovery and unicast hellos (over DTLS) for bidirectional reachability detection.
You could adapt this for other use cases by replacing unscheduled multicast hellos
by an out-of-band discovery mechanism when suitable. This gives you the flexibility
of not having to send hellos to all neighbors on one link at the same frequency. I see this
as pretty useful on a Wi-Fi link where some of your neighbors are plugged in to power
and listening for Wi-Fi 100% of the time but some other battery-powered neighbors
keep their radios off significant portions of the time and would rather not process packets
nearly as often.

I don't have real-world experience measuring these performance tradeoffs, but the
Babel over DTLS interop should be a good way to confirm that it works.

David

> On Feb 4, 2018, at 07:28, Juliusz Chroboczek <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 06 Feb 2018 21:18:22 +0100

David Schinazi <[email-masked]> writes:

> Hi Juliusz,
>
> For the Homenet use case, I would consider using unscheduled multicast
> hellos for discovery and unicast hellos (over DTLS) for bidirectional
> reachability detection. You could adapt this for other use cases by
> replacing unscheduled multicast hellos by an out-of-band discovery
> mechanism when suitable. This gives you the flexibility of not having
> to send hellos to all neighbors on one link at the same frequency. I
> see this as pretty useful on a Wi-Fi link where some of your neighbors
> are plugged in to power and listening for Wi-Fi 100% of the time but
> some other battery-powered neighbors keep their radios off significant
> portions of the time and would rather not process packets nearly as
> often.

Yeah, more or less what David is saying: For my (planned) use case, I
also assume out of band discovery; and having the flexibility to not
send hellos to everyone at the same time seems like a useful feature to
have :)

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 07 Feb 2018 13:56:24 +0100

>> reachability detection.

I think this might cause two problems:

  (1) it would break interoperability with implementations that ignore
      unicast Hellos, which is explicitly allowed by the current spec;
  (2) it breaks link-quality estimation over wifi, since unicast packets
      are sent with ARQ.

I'm not sure if (1) is a problem -- perhaps we don't care about
interoperability with non-Homenet routers --, but (2) certainly is.

> For my (planned) use case, I also assume out of band discovery; and
> having the flexibility to not send hellos to everyone at the same time
> seems like a useful feature to have :)

I have no problem with out-of-band discovery, which I think is a reasonable
thing to do in many environments (point-to-point VPNs being the obvious
example).  What does bother me is that there is no way to know whether the
link partner does grok Unicast Hellos -- if you've done out-of-band
discovery and the peer ignores your Unicast Hellos you're out of luck.

(Note further that in the obvious case -- point-to-point links -- you've
got only one link partner, so you might as well send Multicast Hellos over
Unicast.)

So my current thinking (which is likely to change) is that we done one of
the following:

  (1) either we make reception (but not emission) of Unicast Hellos compulsory,
      or at least a strongly worded SHOULD;
  (2) or we drop Unicast Hellos from rfc6126bis, say that implementations
      MUST silently ignore Hellos with the Unicast bit set, and define
      Unicast Hellos in draft-hoiland-schinazi-babel-unicast-hellos.

Note that neither of these actually changes the protocol -- they just make
it clear whether we're serious about Unicast Hellos (case 1) or whether we
merely consider them as a compatible extension that should only be used in
closed environments such as Homenet.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Feb 2018 11:25:53 -0500

>  (2) it breaks link-quality estimation over wifi, since unicast packets

Is there a way to detect the latency caused by ARQ?

---

From: David Schinazi <[email-masked]>
Date: Wed, 07 Feb 2018 09:23:42 -0800

Hi Juliusz, Ted,

Responses inline.

Thanks,
David

>> On Feb 7, 2018, at 04:56, Juliusz Chroboczek <[email-masked]> wrote:
>> 

Since we're using security here, not interoperating with devices that
do not support our security scheme is a feature, not a bug. One could
imagine having the document that specifies the security scheme for
Babel (DTLS or otherwise) mandate unicast hello support.

>>  (2) it breaks link-quality estimation over wifi, since unicast packets

I know this is evil, but technically there's nothing preventing us from
sending a Babel Unicast Hello over DTLS over multicast - all other
nodes will drop it since the decryption will fail.

>> discovery and the peer ignores your Unicast Hellos you're out of luck.

I think it's safe to assume that the out-of-band discovery mechanism
will contain additional information. One example of such information
is the public key of the peer used for DTLS, another is the fact that
the peer supports Babel, and yet another is the fact that the peer
supports unicast hellos. If you have out of band discovery you move
away from the general Babel mindset of "any two Babel nodes in the
universe can interoperate" and into the world of "these nodes are part
of this system and Babel is a tool at their disposal".

>> closed environments such as Homenet.

I would vote for option (1) as I see unicast hellos as an important part of Babel,
but I do agree that this is independent of the protocol itself. While the examples
we describe above use unicast hellos in closed systems, I have an intuition that
unicast hellos will be useful for open systems as well - though I'll concede that
I don't have code or data to back that up.

> On Feb 7, 2018, at 08:25, Ted Lemon <[email-masked]> wrote:
> 

You could implement link-quality estimation even with ARQ by measuring
properties such as latency. Juliusz raises the point that operational
experience has shown that drop rate of multicast works very well for
babel over Wi-Fi, while these other metrics have yet to be proven.
I believe they eventually will be, but we haven't implemented them yet.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 07 Feb 2018 19:25:04 +0100

Added Dave to CC, removed Toke and David who follow the list assiduously.

> Is there a way to detect the latency caused by ARQ?

You should speak to Toke and Dave.

draft-jonglez-babel-rtt-extension gives you microsecond granularity
(thanks to Dave, who complained about the initial version using multiples
of 10ms).  Wifi uses timeouts on the order of 20 to 100 µs, if memory
serves.

Not sure how well that would work in userspace on a general-purpose OS,
though.  You might suffer from jitter on the order of 1ms due to
scheduling, so you'd need to work out a smart filtering algorithm to work
around that.  I'm not aware of any papers on the subject, perhaps Toke'll
know.

The right solution, IMHO, would be to grab the kernel's data and use that
directly.  I've been wanting to try it out for ages, but keep getting
sidetracked by silly concerns such as security ;-)

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Feb 2018 13:45:19 -0500

> around that.  I'm not aware of any papers on the subject, perhaps Toke'll

In my experience at least, when the link is lossy, you see plenty of delays longer than 1ms.   So it might still be useful, even if it's not perfect.

But yeah, if there were a way to get the details from the kernel, that would obviously be better.

---

From: Teco Boot <[email-masked]>
Date: Thu, 8 Feb 2018 06:53:45 +0100

> But yeah, if there were a way to get the details from the kernel, that would obviously be better.

Depending on OS, insight info on link quality is available. E.g. Linux:
user@host:~# iw wlan0 station xxx
Station xxx (on wlan0)
        inactive time:  2777 ms
        rx bytes:       7489506
        rx packets:     18217
        tx bytes:       28571
        tx packets:     402
        tx retries:     36
        tx failed:      0
        rx drop misc:   5
        signal:         -35 [-40, -37] dBm
        signal avg:     -35 [-40, -37] dBm
        Toffset:        18446743862051617833 us
        tx bitrate:     48.0 MBit/s
        rx bitrate:     24.0 MBit/s
        expected throughput:    33.507Mbps
        mesh llid:      0
        mesh plid:      0
        mesh plink:     ESTAB
        mesh local PS mode:     ACTIVE
        mesh peer PS mode:      ACTIVE
        mesh non-peer PS mode:  ACTIVE
        authorized:     yes
        authenticated:  yes
        associated:     yes
        preamble:       long
        WMM/WME:        yes
        MFP:            yes
        TDLS peer:      no
        DTIM period:    2
        beacon interval:5000
        connected time: 9452 seconds

If a link is not used, e.g. better path available or no user traffic, link quality measurement needs some probing. Unicast hello's help measuring link quality.

Teco

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 08 Feb 2018 09:51:13 +0100

Ted:

>> In my experience at least, when the link is lossy, you see plenty of
>> delays longer than 1ms.  So it might still be useful, even if it's not
>> perfect.

Go for it, by all means, Ted.  The timestamping code is already there [1],
all that's needed is to do the right tweaks to neighbour_rxcost and
neighbour_cost in neighbour.c.

[1] https://arxiv.org/pdf/1403.3488

> user@host:~# iw wlan0 station xxx

Yep, that's something that I've been wanting to do for a long time.
Babeld currently uses the old wireless-tools ioctls for speaking to the
WiFi stack, it needs to use netlink instead.  That would fix the issue of
babeld not being able to automatically determine the channel of interfaces
in AP mode, and would give us access to all the nifty netlink data.

> If a link is not used, e.g. better path available or no user traffic,
> link quality measurement needs some probing. Unicast hello's help
> measuring link quality.

You don't need Unicast hellos for that.  You can send some empty Babel
packets (just the packet header), and if you need larger packets, you can
send some PadN TLVs.

What Unicast hellos bring to the table is a second (seqno, timeout) pair
that is per-neighbour rather than per-interface.  I am still not convinced
that's something we need.

-- Juliusz

---

From: Dave Taht <[email-masked]>
Date: Thu, 8 Feb 2018 08:59:20 -0800

> in AP mode, and would give us access to all the nifty netlink data.

There is working netlink code for this in iw and olsrv2. I have to
admit that I found it really hard to understand vs the simple ioctl,
but I've got a mite better at netlink since I last looked at it.

> packets (just the packet header), and if you need larger packets, you can

My general thought was to also leverage a route update, timestamping
and requesting arq on the first and last packet.

-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619