[Babel-users] Babel instability in WLAN-SI

[Mitar]

Hi!

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

About VPN, I think ideally, we would want a metric for VPN links which:
- take RTT into the account
- take packet loss into the account
- take available bandwidth vs. used bandwidth into the account
- makes it clear that the link does not interfere with other links (so
no wireless interference)

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). Not sure how we could mark those links? Maybe we should
have multiple links available? Wired, VPN, VPN-per-use, wireless?

(Also, some VPN links go over wireless - like 4G wireless. So packet
loss and RTT and stuff still very applies.)

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

Why have you disabled packet-loss metric on VPN links? Just to lower
the overhead of sending packets over? We would prefer to have it on,
we do not care so much about that low overhead (fiber to homes in
Slovenia).

> 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?


Mitar

On Mon, Dec 14, 2015 at 10:53 AM, Juliusz Chroboczek
<jch at pps.univ-paris-diderot.fr> wrote:
>> BTW, how should VPN links be handled in this case? They are currently
>> marked as wired, but they can also experience packet loss. Does this
>> mean that bad VPN links can also cause huge amounts of control traffic?
>
> It depends.  How likely are they to lose two Hellos in a row?
>
> Babeld marks a wired link as down whenever it loses two out of three
> successive Hellos.  If this only happens occasionally (loss probability is
> below 2% or so), then it's fine.  If this happens often, then you should
> enable link quality estimation on them.
>
> In case of doubt, I suggest enabling link quality -- the really bad case
> is not having link quality estimation on lossy links, the opposite case
> (lq on lossless links) is inefficient but not too bad.  If you want
> a quick fix, just change your firmware to run link quality everywhere (-w).
>
> If very lossy tunnels are a common occurrence in your network, I'll
> implement a metric specifically for them.  But let's get your network
> running stably first.  (Nexedi are using babeld over a lot of tunnels, but
> their tunnels are lossless, which is why we implemented RTT-based routing
> for them.)
>
> -- Juliusz



-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m