[Babel-users] Babel instability in WLAN-SI

[Juliusz Chroboczek]

> So luckily we do know which links are wireless and which are VPN, so
> we could configure that in the Babel configuration.

Cool.

> About VPN, I think ideally, we would want a metric for VPN links which:
> - take RTT into the account

Already implemented, as you know.

> - take packet loss into the account

I'd like more evidence that this is needed.  Estimating packet loss is
very slow (since we're computing a metric from what is just a discrete,
one-bit signal), so it slows down convergence.  Hopefully we can get away
without it.

Does your RTT increase at the same time as packet loss?  If so, we could
probably do without packet loss.

(Recall that the goal is not to have an accurate model of the real
world -- the goal is to have traffic flow according to optimal paths.  If
the traffic is going where you want it to go, there's no need to add more
complexity to babeld.)

> - take available bandwidth vs. used bandwidth into the account

I'm very much open to that, but I don't have good ideas about how to
implement it.  Hopefully the dynamic reconfiguration interface (planned
for 2016) will allow you to implement that outside of babeld.

> - makes it clear that the link does not interfere with other links (so
> no wireless interference)

Already implemented, there's

  interface tun42 channel noninterfering

and the stronger

  interface tun42 channel noninterfering faraway true

Please check the manual page.

> Also, at some installations maintainers prefer to use WiFi links if
> available, instead of VPN (because VPN can go over links where you pay
> by usage).

  in if tun42 metric 384
  out if tun42 metric 384

Note that this adds 384 to the natural metric -- it doesn't override the
natural metric.  (You can either say "in" and "out" on one side, or just
"out" on both sides.  Don't do in/out on both sides, since this will
increase the metric twice.)

(Confusingly enough, "in" applies to packets going out, and "out" applies
to packets going in.  That's because data traffic flows opposite to
control information.)

> The last point is something I am unclear what happens if we mark VPN
> link as wireless and we use BabelZ?

Babeld will fail to detect the channel the VPN is on, and assume
"channel interfering", which is not what you want.  Note however that

  interface tun42 wired true link-quality true

will do what you want.

> Why have you disabled packet-loss metric on VPN links?

Because it's an experimental feature, that hasn't had enough real-world
deployment.  It works beautifully in our tests, it works beautifully in
Nexedi's network, and if it works as well in your network, I'll enable it
by default.

Please see http://arxiv.org/pdf/1403.3488v1.pdf for a detailed explanation
of the reasons why it makes me nervous.

> Just to lower the overhead of sending packets over? We would prefer to
> have it on

No, the overhead is negligible.  Please feel free to enable it, and let us
know how well it works.

>> Obviously, this is not recommended, since doing link quality estimation
>> on wired links is sub-optimal.

> What do you mean here? That quality is not computed optimally, or that
> it is sub-optimal from the perspective of link use (because it
> consumes the bandwidth to measure the link quality)? I do not see why
> computation of link quality would not work on the wired links as well
> as on WiFi?

Two reasons.

First, it slows down reaction to link failures.  If you're on an Ethernet,
and you lose two packets in a row, you can be pretty sure the link is
down -- so you might as well drop the neighbour straight away without
waiting for the link quality estimator to converge.

Second, the link quality estimator uses ETX, which is optimised for
multicast Hellos over WiFi links (it's quadratic in loss rate).
A different formula should be used for lossy wired links and for unicast
wireless tunnels.  (But then, perhaps ETX works well enough on tunnels --
I have no idea.)

-- Juliusz