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

[Daniel Gröber]

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