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 <j...@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 _______________________________________________ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
