BondingShouldBeFree Open-source Network Aggregation & Redundancy Solution

[Chester A. Unal]

On 23/05/2026 17:34, Jonas Lochmann wrote:
> Am Sat, May 23, 2026 at 02:03:17PM +0000, schrieb Chester A. Unal:
>> Daniel, Jonas.
>>
>> I've been keeping track of MP-QUIC for a while now. The RFC is still a
>> draft but there's a working group and they're making steady progress, last
>> I checked a few months ago. I'm waiting for the RFC to finalise and have a
>> proper implementation ready before I try it.
> 
> I am also waiting to see the end result. Not only what the implementations
> provide but how common its deployment will be.
> 
> With OpenWrt and IPv6, it works out of the box to let the clients know
> that they are in multiple IPv6 subnets and the clients pick one IP
> per subnet. I once developed a local proxy server application that
> randomly chose one source IP/subnet per TCP socket because the default
> address selection is deterministic and does not distribute load over
> multiple links. However, with a good MP-QUIC result, the usage of
> multiple uplinks would work automatically in this case, without my
> extra proxy server and maybe with load distribution within one stream.
> Failover is already part of the regular QUIC.

True. The problem with MPTCP is, and this should apply to MP-QUIC too, the
host that creates the connections usually does not have access to the
multiple paths. It's usually a router in between that does. That's why,
even if every host on the internet supported MPTCP or MP-QUIC, you'd still
need to run a proxy programme on your router to be able to utilise multiple
paths.

So if we had MPTCP supported everywhere, all that's needed to change in my
solution is to just change the configuration of the proxy programme from
forwarding the traffic to a remote server to directly creating the
connections. Anything else is still needed for the bonding functionality.
But even then, you wouldn't be able to include UDP traffic in the bond
without a remote server, read below for why.

> 
>> MPTCP has been a proper RFC since 2020. I'm in close contact with Matthieu
>> who's maintaining the Linux kernel implementation. I had led to a few MPTCP
>> bug fixes in the Linux kernel also. Apparently, someone from Cloudflare was
>> interested in enabling MPTCP on their global network, but that chap was
>> laid off at the end of 2025 so Matthieu's not sure what's going to happen
>> there.
> 
> I know that the technology is available. I just do not own an ecosystem
> (Browser vendor + Website operator = Google) where I could deploy it.
> Cloudflare using it would be helpful in general, but QUIC reduces the
> benefits of MPTCP.
> 
>> You could say that, but there are many variables in the BSBF solution which
>> differ from your average VPN provider for the purpose of providing bonded
>> network access.
> 
> I know. Still, I already heard of the idea of tunneling traffic using
> MPTCP to a relay with good connectivity. This is of course something
> that random VPN companies do not offer.

I don't do tunnelling, only proxying so there's no room for TCP-over-TCP
meltdown. And UDP payload is proxied over (MP)TCP streams to the remote
server, a feature of the vless proxying protocol.

> 
>>> You can run the server-side yourself, so from what I understood the
>>> "sale" here is mostly for a (open) protocol stack to implement
>>> asymmetric link aggregation (as opposed to using proprietary,
>>> vendor-specific solutions to do the same thing, eg. MikroTik)
>>
>> Yes. The BSBF solution also includes server-side setup so if you're a
>> company that wants to provide network bonding to your clients, you just use
>> both the BSBF server and client solutions.
> 
> The post first looked like some VPN selling advertisement, but I realized
> now that it is not.
> 
>> On top of that, I've got concepts of a plan to make the server-side very
>> easy to scale (moving away from using a VPS as server-side). So I'm looking
>> for a company with a global network to partner with.
> 
> I wish you good luck with the search. I assume that this is the wrong
> mailing list for this goal.

Cheers. Once I achieve this, all the cons of having connecting to a remote
server will be no more, and I'll still be able to keep the pro of
supporting bonding UDP traffic.

> 
>> I worked for a company in South Africa for a while. This is how it went
>> there: The clients that want bonded network access, where they are, go to
>> an ISP. The ISP, being the middle man, use our bonding solution and provide
>> it to their client. Hospitals, industrial businesses, and events streamers
>> were the usual suspects. Ever heard of BCX? They were the biggest client of
>> my SA company a few months back. I and my SA company ended things two
>> months ago, they had bigger problems in the company and the head chap had
>> different ideas how to do bonding.
> 
> Did the clients ask for bonding or just for reliable connectivity?

Both. We had clients who wanted it for their event venue where they had 3
cellular carriers. There, the interest was to have as much bandwidth as
possible to provide to the attendees. So they were mostly interested in
aggregation, and the redundancy was a by-product.

We had streamers / Google Meet users / Zoom users where the interest was
more on reliability so, for that, the use of the redundant scheduler of
MPTCP made more sense as that sends the same traffic across every path.

> 
> Details of the bonding would be interesting - if you can share this
> at the mailing list.

I'm going to write a technical summary on the project documentation page
soon.

> 
>> Jonas, I'm working on spinning up a company where I start selling a full
>> solution. What are your circumstances? Would you like to band together?
> 
> My focus is the network security field. Maintaining networks for
> customers is currently only a side project. So right now, I am not
> open for this idea.

Understood. Feel free to try this solution out for your customers.

Chester A.