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.
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
