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)
It will never ever be included. That's not how protocols & specs work. They are modular and build off of one another. The linked article includes some examples: RFC9001 is "Using TLS to secure QUIC", RFC9002 is "QUIC Loss Detection and Congestion Control." These are expected capabilities of most users, but they are still defined out of the core spec.
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.
Sorry for incorrect wording. I don't need multipath to be present in the same spec as the QUIC core. What I meant is when I will be able to have slightly less then 150Mbps over QUIC for e.g. a single file if I have 3x50Mbps connections. MPTCP can do that for me, even if the server doesn't support it as I can use something like OpenMPTCPRouter [1]. I hope multipath QUIC will be able to do that too, but it's not ready for production use yet, if I understand correctly.
Posted a detailed explanation slightly above... Glorytun will not work to well with TCP b/c it doesn't provide separate congestion control for each path like MPTCP does.
I just really wish Google would have built QUIC on top of SCTP. They had the clout, and opportunity to push for real end-to-end SCTP support across the internet. Tunnel it over UDP for IPv4 and userspace implementations but use native SCTP where possible like over IPv6 before middleboxes abound that only support TCP, UDP, and ICMP. There's too many NAT implementations, firewalls, etc that don't support SCTP on IPv4 but that's not set in stone for IPv6 yet.
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.
Plenty other people and organizations want that too. QUIC at IETF was far from just Google doing something, and large parts of the relevant communities agree on the middlebox issue, people pushing "but we need to be able to mess with traffic!!!" are luckily waay in the minority there.
I use OpenMPTCPRouter [1]. It's a bit of kitchen sink so I'm thinking of replacing it with something simpler, but the basic idea is that you have a TCP->MPTCP converter running on your router and MPTCP->TCP converter running on some cloud instance.
Wouldn't QUIC work all the same with that setup, considering that you're not using MPTCP end-to-end? Or do you have a SOCKS or HTTP proxy on the other side of the aggregated links?
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?
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.
OpenMPTCPRouter uses shadowsocks [1] and its ss-redir as a kind of a transparent TCP proxy. The advantage of shadowsocks is that it creates separate outgoing TCP connection for each one it proxies, resulting in substantially better performance than SOCKS. And, of course, shadowsocks has MPTCP[2] support.
The problem OpenMPTCPRouter solves is this: you do
(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.
I don't know about services, but MPTCP is available on Apple's OSes and out of tree patches for Linux and FreeBSD (at least I don't think it's been merged into the main tree for either of those).
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.
I actually believe it's their AI gap filling approach that may account for better perceived handoffs there. It was introduced on duo, and was supposed to hit meet sometime.
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...
[2] https://multipath-quic.org/