[Babel-users] the routing atomic update wet paint - because *I* care

[Henning Rogge]

On Mon, Apr 6, 2015 at 7:22 PM, Dave Taht <dave.taht at gmail.com> wrote:
> Well, I tried the patches and they did not work (as expected), but I
> think we are closer. I will try to create some test cases using ip
> route to do what I want, and get back to folk when I have time. I have
> a ton of other reasons to want to grok the netlink code more deeply.

Strange... I definitely had some (ipv6) cases which ran fine with the
new kernel but badly with the old one.

> I note that I called this thread "wet paint" - It was sunday, I had
> nothing to do but watch benchmarks run - I would like atomic updates
> to work. I keep poking at it as to why it doesn't. I do not know if it
> is a common meme outside the US to see a sign that says "wet paint"
> and to go touch it, to make sure.
>
> The ongoing FIB tree rework going into linux 4.0 and 4.1 struck me as
> a starting point to improve the kernel API (if needed), if we can´t
> find a way to make it work better. I am NOT pressuring to get it in
> any user space routing code presently! What I am trying to do is
> figure out how to fix the kernel (if needed), or do it more right in
> the routing daemons. (and by jove if we need kernel mods, there be an
> API to figure out if a newer API is available)

I don't even think the API is bad... its just badly documented.

And libnl(1/2/3?) was painful enough that I decided not to use it at
all for olsrd2.

>  Linux TCP has sprouted the ability to handle massive re-ordering
> (order, megabytes) and there has been a ton of work on things like
> QUIC that are also highly tolerant, as well as things like torrent,
> which already handle it.
>
> Babel (dont know about OLSR) finds a "usable" path, then tunes to a
> better one, but each tuning step (particularly at high rates) can lose
> packets, which cause rate reductions. Ideally would like to never lose
> packets while tuning happens.
>
> The most common case where I see an interruption in flows is when I go
> back from a wlan to an ethernet, under load, so being able to modify a
> route atomically to switch devices on the route was my end goal. The
> simple test I came up with earlier in the thread was not, but seemed
> useful.

olsrd2 ist a common linkstate protocol... it collects all the
information about the links and runs a dijkstra on them... then use
the result to setup the new version of the routes. The whole process
runs asynchronous, I don't wait for the kernel return codes, I just
setup all the necessary changes and then parse the netlink feedback
later.

Henning