[Babel-users] ECMP on endpoints [was: babeld slashes...]

[Toke Høiland-Jørgensen]

Daniel Gröber <dxld at darkboxed.org> writes:

> 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 :)

Well, RIP can actually generate equal-cost routes with a fairly high
probability because its metric is less granular than Babel's. So ECMP is
more straight-forward, whereas with Babel the 'E' really has to be
'roughly equal', which is the thorny bit :)

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

FWIW it's slowly making its way into the Linux kernel. So hopefully some
day soon!

>> 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 :)

Well, it *is* fairly new (and probably still a bit rough around the
edges), so world domination is a way off yet. Let me know if you end up
playing with it, would be interesting to get some feedback!

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

Right, active probing is probably fine in this case...

-Toke