Re: [Cerowrt-devel] [Babel-users] more wet paint - babel unicast IHU for short-rtt path optimization

[Dave Taht <dave.taht@gmail.com>]

On Tue, Apr 7, 2015 at 1:28 PM, Juliusz Chroboczek
<jch@pps.univ-paris-diderot.fr> wrote:
>> My understanding of the babeld code is that unicast code is in there
>> but not used, and if it were used, it would not work against existing
>> babel daemons. ?
>
> You MAY send any Babel TLV over unicast except a Hello.  Hellos MUST be
> sent over multicast.  The receiver doesn't care (except for Hellos).
>
> Look at message.c, function send_ihu.  around line 1693.  If there's
> already a unicast TLV queued, then the IHU is appended to that, and sent
> over unicast.  Otherwise, the IHU is appended to the multicast buffer.

cool.

> There would be no problem sending all IHUs over unicast, but it would
> probably cause additional NDs.

On idle networks it would have an added cost of 1ND per idle station per
minute (? dont remember how long the ND cache lasts). Otherwise, free.

>A more productive endeavour would be to
> send updates over unicast when there are few neighbours on a given
> interface, but I'm afraid it might cause Babel more difficult to debug.

That would give the needed packet volley for free on larger networks.
(see item 8 on TL;DR :) )

A timestamp is not defined for updates, presently. Do you fragment?
Would an IHU be bundled with an update?

Reading the tcpdump code (almost done updating it for tcpdump git
head, maybe another hour) was most productive in understanding
the guts of the protocol, btw. I guess I am better at reading code than
RFCs.

>
> -- Juliusz



-- 
Dave Täht
We CAN make better hardware, ourselves, beat bufferbloat, and take
back control of the edge of the internet! If we work together, on
making it:

https://www.kickstarter.com/projects/onetswitch/onetswitch-open-source-hardware-for-networking