What made it work best (and rock stable) was using LTE only, or ADSL only connections having same ping to aggregator (VPS) and have the VPS as near as possible. (latency wise)
I did not had the time to set up multiple redundant aggregators, so my SPOF was the VPS some times. Maybe there is a solution out there.
So far my experience a year ago. Our provider then offered a way cheaper managed solution, thats why we stopped using it.
> If MPTCP is not supported, OpenMPTCProuter can also use Multi-link VPN (MLVPN) or Glorytun UDP with multipath support.
It’s unclear to me from a brief look why they use mptcp as a backend for bonding
Initially I was amazed by MPTCP and wondered why it had so little adoption. As I looked into the papers I slowly figured out why. With different links (WLAN, LAN, LTE) their real world characteristics are too different for efficient aggregation. It is the head of line blocking problem times ten.
It might be fine as a back up link, but there are other problems like the limit to TCP and middelboxes dropping unknowns packets. The challenges outnumber the benefits for consumers and in data centers there are other technologies to aggregate links that operate on a level below TCP.
And given that it’s the next evolution of TCP and a requirement for HTTP/3 it seems like the opposite direction of better QUIC compatibility is likely.
Allowing bypassing it breaks their policy.
If you own your own network then you don’t need to worry about middle boxes interfering with quic or http.
Over bonded networks bitrate are typically under 40mbit, and usually under 20
Of course none of this uses tcp.
When you're using TCP, you can enable MPTCP for free and make your connections faster and more stable. If you're not using TCP, there are alternatives, but then MPTCP is completely irrelevant anyway. You can use QUIC if you want to bypass shitty middleboxes, for instance, as that has similar features but smuggles itself past shitty middleboxes by being marked as UDP (which also makes it more likely to get dropped when the network is congested, unfortunately).
Once a session establishes a route, maintain it. Add logic to prioritize routes by session importance.
Doing it at the packet level in theory gives you the ability to exploit the aggregate bandwidth for any session but as OP noted you still have all the latency problems and middleboxes getting in the way.
QUIC by the way solves the middlebox problem and you could put individual QUIC streams on separate connections to solve the head of line blocking that can appear but I feel like that’s closer to the TCP session thing where you only benefit the use cases that set up multiple streams. HTTP3 where this does happen may not benefit though because bandwidth tends to not be a problem if your rich enough to afford multiple links in the first place (ie more latency sensitive). This could be useful in places if you build a custom end to end solution for video streaming where you put the time-sensitive parts of the video on the lowest latency link and let the rest of the video buffer across all links. It’s a very niche use case though and not worth the effort I think.
I'm hoping that with QUIC, there will be a way to use it's migration feature to load balance more accurately (no need to wait for new flows to start). But, right now there is no way for a middlebox to tell if the server end of an individual flow supports migration, as this is only visible to the client.
I was using copper internet from local ISP paired with cellular and starlink. Starlink went out for 30 seconds every few minutes but when it worked, it was the fastest of the bunch.
I rented a cheap VPS in the city to use as the other end of this router. The setup worked well overall, I was getting work done along with downloading games with sizes above 100G without worrying too much
There are a lot of configuration options and the stability of them can be an issue. I've found using XRay VLESS for the Proxy and Glorytun TCP for VPN to offer the best overall speed and reliability. (Edit: I've disabled SQM too). It's possible to mostly bypass the VPN by enabling proxy UDP over XRay but I found that breaks various bypass rules, e.g. so that Netflix connections always go over 5G, as some content has restriction from being accessed by my VPS data center IP.
Port forwarding is also a bit hit and miss; I have configured my 2 WAN routers to use the OMR router as a DMZ and then if I want to play a game, or enable remote access, I will use the bypass feature so that the device's MAC goes through my FTTC connection. UPnP works correctly in this scenario which is handy for consoles.
Fortunately Starlink got more reliable so I stopped needing it. Bonding disparate network connections has a lot of really funky behaviors. In practice the biggest problem is the Speedify VPNs kept getting flagged as spammy: running your own OpenMPTCrouter endpoint fixes that.
It's great tech which can reach out and bite you in the bum at random. In my case it was a 10x drop in throughput by out of order packet arrival and effects on window and flow control.