BondingShouldBeFree VPN

[Jonas Lochmann]

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.

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

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

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

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

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