Hi Toke, On Sat, Apr 16, 2022 at 10:50:13PM +0200, Toke Høiland-Jørgensen wrote: > > I have been doing a bit of looking for literature about distributed > > multipath routing algorithms too and there certainly does seem to be > > quite some papers that would be applicable to babel. So we're not > > entirely in untrodden territory. I'll probably not have time for any > > of that though. > > Sure, I'm not disputing you can probably get something that will work > for your usecase. I'm just being (maybe too?) pessimistic about whether > this would be generally useful (i.e., upstreamable) for babel/bird as a > whole. Happy to be proven wrong, of course :)
I mean RIP of all things already has an ecmp option in bird, so I don't think there's an argument that having this for babel is any less useful if it's acceptable there :) > > Ah yes, I have. Ideed that could work but I would like the addresses to > > stay constant as connectivity comes/goes. > > Yeah, the end-to-end solution to that would be MPTCP and/or QUIC. Which > needs support from the server side, so not really a full solution in > itself. One can dream, though! Yeah. I'm still hoping MPTCP will go mainline one of these days. > Well, please allow me to plug another project I'm involved in: the > "passive ping" (pping) utility. This was originally written by Kathy > Nichols as a libpcap-based utility, but I have a PhD student who is > working on a BPF-based version specifically designed to be run in the > background processing all traffic: > > https://github.com/xdp-project/bpf-examples/tree/master/pping Very interesting! I was looking for something that implements exactly this approach a while ago and spent an entire afternoon googling without finding anything. Well good to know I'm not crazy and it actually exists :) > The utility will parse packet headers, match outgoing to incoming > packets and compute an RTT (using TCP timestamps and/or ICMP sequence > numbers). This way you can continuously monitor the latency on a link > without injecting any measurement traffic. We've yet to run any > comprehensive analysis using this, but the tool itself should work as-is > (famous last words) :) The main problem in my deployment is that I have multiple edge routers, being multihomed and all so I can't easily guarantee both flow directions hitting the same router. For the physical network it would work since I have a central router there, but for any clients attached via tunnels to the edge routers that's not the case. I think for a small scale network such as mine active probing would probably be fine and while I haven't thought about it in-depth yet I think that could be made to work even if I see only one flow direction. --Daniel _______________________________________________ Babel-users mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
