Subject: Re: [babel] [Babel-users] some thoughts towards babel-1.9

From: David Schinazi <[email-masked]>
Date: Mon, 12 Dec 2016 10:27:59 -0800

Dave,

Thanks for writing this up, it's an interesting read.
I agree with you on the topic of multicast. My implementation sends
everything unicast, with the exception of Hellos. I'm interested in
working on a way to allow unicast Hellos. I read your thoughts here:
https://github.com/dtaht/rabeld/blob/master/babel_unicast_hello.md <https://github.com/dtaht/rabeld/blob/master/babel_unicast_hello.md>

and was thinking that we might be able to make this even simpler,
by adding a new "I support unicast Hellos" bit in the IHU Reserved field.
That way when a node appears on a link, they send a multicast Hello,
and get IHUs in response. If all the IHUs have this bit, then the router
can go into unicast Hello mode. Similarly, when a node sees a new
neighbor, it sends it an IHU with this bit and if it receives a unicast
Hello from that node it knows they are supported, otherwise falls back
to multicast. You could then have different intervals for multicast and
unicast Hellos, with the multicast one being potentially much higher.

This proposal stays in the spirit of current Hellos as a measure for
packet loss rate. If as you describe this isn't a great metric, we
could take this thought process even further and simply get rid of
Hellos for link quality estimation. You would still have multicast Hellos
to detect new peers, but you can estimate by-directional reachability
simply by noticing of you receive any Babel packet from a host, and
IHU for the reverse direction. This makes particular sense if you were
able to query your link-layer for information on how many
retransmissions are required on average to reach that host, and what
rate the Wi-Fi chip is operating at.

Thoughts?
David

> On Dec 12, 2016, at 09:25, Dave Taht <[email-masked]> wrote:
> 
> I've long been testing a few out of tree patches for babel and long
> have had the intent to try a few more once the first phase of the
> make-wifi-fast work was completed - which it mostly is, so far as lede
> is concerned ( https://lwn.net/Articles/705884/ ) - and babel-1.8
> stablized.
> 
> I wrote up some of my thinking then in:
> 
> https://github.com/dtaht/rabeld/blob/master/rabel.md
> 
> back when we were having powersave issues affecting multicast (which I
> hope is now fixed), but I've partially deployed the "mo' unicast"
> patch around my testbed with no ill results.
> 
> Another thing that has come up a lot lately is the default gateway
> failing for some reason or another, tighter integration with
> babel-pinger might help.
> 
> And lastly, I had a chance to look at some packet captures from the
> wlan-slovenia network, which is essentially flat, and is sending 14
> packets worth of route information on a regular basis. Finding ways to
> attenuate and create covering routes, and make DV more DV would be
> nice.
> 
> I'd also written up some partially crazy thoughts towards a unicast
> hello extension in the same repo.
> 
> -- 
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> http://blog.cerowrt.org
> 
> _______________________________________________
> Babel-users mailing list
> [email-masked]
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 13 Dec 2016 04:21:51 +0900

> On 13.12.2016, at 3.27, David Schinazi <[email-masked]> wrote:
..

> unicast Hellos, with the multicast one being potentially much higher.

Personally I like the idea of having very infrequent multicast hellos and common unicast ones (if called for). The extra complexity is the only downside I see in this scheme. 

I am not even sure you need separate mode for it in the specification ('all IHUs'; tricky on e.g. adhoc); you can simply locally configure a long-ish multicast hello interval, and opt for shorter unicast hellos if you feel like it with consenting peers (that have indicated consent by sending IHU with uhello support).

Mandating two separate modes should not be necessary but for QoL it might be an implementation option anyway. Depends on how many orders of magnitude fewer you would make normal hello interval as opposed to uhello one. 

So the question becomes then whether it is worth having uhello support bit + separate uhello message in the specification (+ some edits related to it), and then leave their implementation details open.

> rate the Wi-Fi chip is operating at.

I am not a fan of using multicast for estimating unicast link quality anyway. Typically, multicast drop rates are higher (IIRC, cannot be bothered to look up a reference right now, sorry, it is 4am) than unicast ones. Therefore estimates generated from uhellos would be better anyway.

Cheers,

-Markus