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

[Dave Taht]

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.

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)

 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.