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)
QUIC is now RFC 9000
11–20 of 246 posts
Re: QUIC is now RFC 9000
#12Wake 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)
Both ends need to grok MPTCP. Which services and devices meet the requirement?
Re: QUIC is now RFC 9000
#13https://www.fastly.com/why-fastly-loves-quic-http3 is a 404 on this page fyi
A quick google search surfaces the correct link. My 10 second root cause analysis: they changed the title of the blog post. https://www.fastly.com/blog/why-fastly-loves-quic-http3
No, they just for some reasons missed /blog/ part in the path.
Re: QUIC is now RFC 9000
#14Should have waited for 9001. Oh my mistake, they have several RFCs from 8999-9002.
Over 9000!
Re: QUIC is now RFC 9000
#15Have previous protocols (TCP, UDP, etc) been in widespread use before their respective RFCs? The QUIC Wikipedia page[0] makes it sound like a substantial amount of traffic, due largely to Facebook, Google, and the Google Chrome browser, uses QUIC already. Facebook claims 75% of their traffic (for the app?) is via QUIC[1] [0]: https://en.wikipedia.org/wiki/QUIC [1]: https://engineering.fb.com/2020/10/21/networking-tra…
> Have previous protocols (TCP, UDP, etc) been in widespread use before their respective RFCs?
Yes. Many early RFCs were simply documenting things as they were, not specifications of how they should be.
Re: QUIC is now RFC 9000
#16Have previous protocols (TCP, UDP, etc) been in widespread use before their respective RFCs? The QUIC Wikipedia page[0] makes it sound like a substantial amount of traffic, due largely to Facebook, Google, and the Google Chrome browser, uses QUIC already. Facebook claims 75% of their traffic (for the app?) is via QUIC[1] [0]: https://en.wikipedia.org/wiki/QUIC [1]: https://engineering.fb.com/2020/10/21/networking-tra…
Yes. The first TCP RFC supplanted ~8 previous IEN specifications. All kinds of protocols have found wide use before their RFC.
Re: QUIC is now RFC 9000
#17Wake 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)
Both ends need to grok MPTCP. Which services and devices meet the requirement?
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.
Re: QUIC is now RFC 9000
#18Have previous protocols (TCP, UDP, etc) been in widespread use before their respective RFCs? The QUIC Wikipedia page[0] makes it sound like a substantial amount of traffic, due largely to Facebook, Google, and the Google Chrome browser, uses QUIC already. Facebook claims 75% of their traffic (for the app?) is via QUIC[1] [0]: https://en.wikipedia.org/wiki/QUIC [1]: https://engineering.fb.com/2020/10/21/networking-tra…
TCP is documented several times, in different states, starting at least in 1974. So depending on how you define "widespread" and "respective RFCs" you could probably argue for either position.
Re: QUIC is now RFC 9000
#19Wake 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.
[1] https://datatracker.ietf.org/doc/draft-deconinck-quic-multip...
Re: QUIC is now RFC 9000
#20Should have waited for 9001. Oh my mistake, they have several RFCs from 8999-9002.
Yeah, they form a "cluster" of documents: https://www.rfc-editor.org/cluster_info.php?cid=C430, so that the earlier-numbered RFCs can reference later ones. For instance, rfc9000 normatively refers to rfc9001 and rfc9002.