Wake me up when multipath support is included... Till then I prefer TCP b/c I can use MPTCP to utilize all of my rural LTE bandwidth for each single flow (e.g. downloading a file)
Similarly, there is steady progress on a multipath extension to QUIC[1]. There is also a website https://multipath-quic.org [2] covering advances in multipath quic. Multipath capability, like TLS, like the standard congestion control, will never be included in RFC9000 / QUIC core. But it's advancing.
And, I'd guess, based off the connection-less nature of QUIC (and it's UDP underpinnings), it stands a good chance of being significantly better than MTCP.
[1] https://datatracker.ietf.org/doc/draft-deconinck-quic-multip...
Would that work for you?
SCTP would have been great for all sorts of applications other than QUIC too. It's got built in multihoming for seamless handoff in mobile environments to keep a persistent connection across e.g. WiFi and cellular. Want multiple streams with no HoL blocking? SCTP is message based and can deliver multiple "streams" simultaneously over a single connection and you get free message boundaries to boot instead of just a plain stream like TCP. Want unordered datagrams? It's got that too. Even partial reliability for a subset of messages in a connection, i.e. reliable metadata for an unreliable live low latency video stream. The four way handshake also basically eliminates the potential impact of a SYN flood.
From what I can tell from the QUIC RFC, it also supports this. See section 9, "Connection Migration" (https://www.rfc-editor.org/rfc/rfc9000.html#name-connection-...).
When your phone or whatever switches network, it can initiate a connection migration. Assuming it's the client, which would be the common case.
Also, why do you need MPTCP for this? Aren't there simpler methods for this kind of setup, like LACP? Or is OpenMPTCProuter, like OpenVPN, one of those things that everybody uses because everybody else does, with more informal documentation and help?
I haven't done this myself but it looks like OpenBSD would support LACP out-of-the-box w/ the aggr(4) or trunk(4) devices. See https://man.openbsd.org/aggr.4, https://man.openbsd.org/trunk.4, and https://undeadly.org/cgi?action=article;sid=20190710071440. I presume standard Linux distros have similar support.
EDIT: To be clear, AFAIU you'd also need to combine the LACP pseudo-devices w/ something like tpmr(4) and etherip(4) to actually bridge the peers. See https://www.undeadly.org/cgi?action=article;sid=201908022358... which describes tpmr(4) as providing a simpler complement for use in LACP-over-IP setups, where the normal bridge(4) device would require too much additional configuration. Again, I presume Linux has analogs.
The problem OpenMPTCPRouter solves is this: you do
curl -O https://somewhere.example.com/largefile.tar.gz
(just a single TCP flow) with 3x50Mbps LTE links, or, better, 80Gbps+40Gbps+30Gbps links and you get a bit less than 150Mbps download speed.
LACP doesn't solve it at all for several reasons.
1) LACP assigns each flow to a single network interface so as to avoid packet reordering
2) Even if you use other bonding mode that can spread the flows over several network interfaces, you'll get low throughput due to the aforementioned reordering and also due to the congestion control, more on that below.
Bonding works well when you have several "equal" links, which is not the case with LTE, where the speed may be quite different across the links and also vary with time.
Last but far from least, there is congestion control mechanism which is present both in QUIC and (MP)TCP, which makes sure the transfer is as fast as possible without harming other connections on the same link(s). This mechanism as it is used in QUIC and plain TCP is not very good at handling multiple aggregated unequal links, so no matter which way you do the aggregation on L2 (bonding) or L3 (things like glorytun), the performance is going to be suboptimal.
What MPTCP does is establishing a separate subflow (think TCP subconnection) for each of the available paths, with its own separate congestion control, and spreading the main flow over multiple subflows byte-by-byte in an optimal way. This gives maximum possible utilization of all of the available links, and prevents the congestion in an optimal way, too.
Apple took a little bit too long to make it available for applications on iOS, so it didn't line up with my access to large numbers of end users and full control of the server stack, so I sadly don't have any experience with it, but it's there.
From reading the specs a while ago, I believe QUIC ended up with support for changing IPs, but not multiple IPs simultaneously, and I believe the server only can change IPs during session establishment, not with an established session.
It feels like Google is supporting some notion of this given Meet has seamless handoff as you leave Wifi.