[Babel-users] failing over faster?

[Dave Taht]

Thank ghu we aren't homenet! Wires are dead! :)

I will incorporate your comments later today. Until then, there's
pictures and data now up at:

http://blog.cerowrt.org/post/failing_over_faster/

I am quite puzzled as to how long it takes to fail over even in the
good cases. I guess I gotta take some packet captures.

On Mon, Apr 25, 2016 at 11:47 AM, Juliusz Chroboczek
<jch at pps.univ-paris-diderot.fr> wrote:
>> 8+ years ago, with ahcp and babel, and a network configured to use
>> that with a single static ip address on both the ethernet and wifi, I
>> could do that. My own networks were setup that way, anyway... I did it
>> all the time. It was wonderful. I never had to think about it.
>
> Dave, the plan is to do exactly that with shncpd and babeld -- think of
> shncpd as ahcpdv2.  Please try running babeld and shncpd (-M) on the host,
> and if it doesn't work as well as ahcpd, we'll fix it.
>
>> It was massively disconcerting to attempt to move back into the
>> "regular" world where wifi and ethernet were treated as distinct,
>> where taking an interface offline lost its address,
>
> Right.  One difference between ahcpd and shncpd -M is that the former uses
> a single address, while the latter uses one address per interface.  The
> workaround is to keep the interface up, even if it is unconnected.
> Since -M is out of spec anyway, I can be convinced to change that.
>
>> where taking a new /64 was considered mandatory,
>
> That's what -M is for.
>
>> and no host changes allowed,
>
> We're not Homenet, Dave, we're independent researchers.  Just because
> Homenet rejects something doesn't mean we shouldn't do the right thing.
> My personal opinion is that having reasonable support for unchanged hosts
> is a goodness, but we shouldn't shy from designing better hosts.
>
>> I've harped on a need for atomic updates, but I still think that
>> a userspace routing daemon simply can't react fast enough to a change in
>> an ethernet routing table to prevent no-route messages being sent to one
>> or more flows on a busy link when it goes down.
>
> Higher-layer protocols should be able to survive ICMP unreachable by
> retrying after a few jiffies.  TCP certainly does, and if your protocol
> doesn't, it's a bug in the protocol.
>
>> A newer problem that I haven't thunk much about before was that babel
>> aims for a stable route, so if I have 3 routes - one stable, but
>> lousy, and both the better routes flap twice in under 60 seconds or
>> so, we end up choosing the stablest route, sometimes for a very long
>> time.
>
> Yes, over the years babeld has been tuned to prefer stable routes.  Have
> you tried playing with -M?  I'm quite open to changing its default value.
>
> -- Juliusz



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org