Den 2015-12-15 kl. 00:33, skrev Mitar: > Hi! > > On Mon, Dec 14, 2015 at 11:39 AM, Juliusz Chroboczek > <[email protected]> wrote: >> 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. > Hm, isn't computation on WiFi links exactly the same? > >> Does your RTT increase at the same time as packet loss? If so, we could >> probably do without packet loss. > Not really. At least on the fiber links (which are most of our VPN > links) it does not. Doesn't a lost packet contribute to RTT with (an appropriate value of) infinity? >> (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.) > Currently it seems that the routes over VPN are dropped while we would > prefer them to stay up, even if there is a slight packet loss. > >>> 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. > Hm, are we talking here about packet-loss or delay-based routing > (RTT)? I understand that RTT metric is experimental, but I was talking > about packet-loss, why is that not enabled. Or am I missing something? > >> 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 > Or we have a very short buffer. ;-) > > But yes, maybe our recent instability in VPN links is more to the > problems with routing we have, then really link instability. > > But we do have VPN links which go between countries. We have observed > really crazy stuff on for example links between Croatia and Slovenia. > Sometimes extra 100 ms appears on the link, because they have some > issues at Internet exchanges, for example (so delay is added at the > Internet exchange). > > I do not think that VPN links should be seen as Ethernet. For Ethernet > I agree that if you loose two packets you have probably issues. But > for VPN you have stuff in between, from bad ISPs, to MTU issues which > make some packets get lost (especially while PMTU is in progress). > >> 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.) > We have been using ETX with OLSRv1 on tunnels without visible issues. > > What do you use for ETX? ETX = 1 / (d_f x d_r) is for unicast (as > described in the A High-Throughput Path Metric for Multi-Hop Wireless > Routing paper). To my knowledge for multicast you should use ETX = 1 / > d_f (as described in the > High-Throughput Multicast Routing Metrics in Wireless Mesh Networks paper). > > So we know ETX equations for both unicast and multicast. Maybe Babel > should support both? > > > Mitar >
-- Christian Huldt
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
