Guys, we all miss the ITS OVER 9000 memes.
QUIC is now RFC 9000
111–120 of 246 posts
Re: QUIC is now RFC 9000
#112Earlier quoted context omitted.
I have spoken with Daniel Stenberg about this and if I recall correctly he disagreed and said that the QUIC which ended up being standardized is quite different from Google's QUIC.
I'd be interested in knowing what major design directions were changed/deleted/added.
For example, gQUIC has its own custom encryption "QUIC crypto" while as you will see in these RFCs the final IETF QUIC design uses the existing TLS 1.3 (existing now, it didn't exist when Google made gQUIC) for encryption.
Or at a philosophical level, gQUIC is an HTTP replacement, it doesn't do anything else except a better HTTP, so it doesn't need to care about any features you might want for, say, SMTP or IMAP or IRC unless it wanted them for HTTP. gQUIC knows about HTTP headers. But the IETF QUIC is a replacement for TCP not HTTP. That's why there's an entire HTTP/3 standard in this bundle of RFCs which sits on top of QUIC as its first "customer".
Re: QUIC is now RFC 9000
#113'QUIC' is quarter-inch cartridge. I approve of the name-change. Two computer technologies with the same name is A Bad Thing.
Re: QUIC is now RFC 9000
#114... Vegeta memes incoming
Re: QUIC is now RFC 9000
#115After all the TCP and UDP specific attacks (SYN Floods and Reflection-Amplification), I am really curious which QUIC-specific DoS attacks will be created by some talented hackers.
At least the security considerations of the QUIC RFC are ~18 pages long, so this might take some time.
Re: QUIC is now RFC 9000
#116> QUIC was developed through a collaborative and iterative standardization process at the IETF after almost five years, 26 face-to-face meetings, 1,749 issues, and many thousands of emails.
26 face-to-face meeting in 5 years is an extremely low number; I'm glad to see that the developers of the Internet embrace remote work :)
Re: QUIC is now RFC 9000
#117> The internet transport ecosystem has been ossified for decades now, and QUIC breaks out of this ossification But it's still just a layer on top of UDP, and still implemented at the application, like in the past. So how is the ossification broken? Every app has to implement it itself rather than calling a syscall and letting the OS deal with its complexities (same as for TLS, making fewer apps implement it without a…
The “ossification” that QUIC deals with is primarily about internet routers who decide to dig into their IP packets. https://http3-explained.haxx.se/en/why-quic/why-ossification Many have optimisations around TCP and long-standing TCP characteristics, which they are able to do because the TCP headers are unencrypted. This led to TCP being difficult to improve, because of all the implementations out there making assum…
> The “ossification” that QUIC deals with is primarily about internet routers who decide to dig into their IP packets.
Being 'opaque' to the network is not a foolproof choice, since it also makes stuff like NAT, congestion control and QoS a lot less robust. By exposing connection identifiers to the network, SCTP gains a lot of flexibility wrt. such scenarios compared to QUIC.
Re: QUIC is now RFC 9000
#118Google is not Requesting For Comments at all. It is imposing its things. Despite the fancy number, this is not an RFC at all, in the ancient sense of the acronym, nor it has the same design principles of simplicity and orthogonality.
Although Google did come up with the original specification their influence over the IETF specifications is not overarching nor absolute; gQUIC is substantially different from IETF QUIC which has caused Google themselves to have implementation and interop issues in their deployments. OS vendors, CDNs, academic researchers, and individuals have all contributed to the resulting specifications that have emerged in a standards body that is by far the most open as the requisite to participate is a functioning email address. All matters and decision making are publicly available for observation and scrutiny.
There is no requirement for people to implement this protocol and it won't be appropriate to every use case that exists today. TCP, UDP, HTTP/1.1, and HTTP/2 are not going away - all continue to undergo standardisation, research, and new implementations.
(Disclosure: I'm not a Google employee, but I have participated in the QUIC and httpbis working groups)
Re: QUIC is now RFC 9000
#119> QUIC was developed through a collaborative and iterative standardization process at the IETF after almost five years, 26 face-to-face meetings, 1,749 issues, and many thousands of emails. 26 face-to-face meeting in 5 years is an extremely low number; I'm glad to see that the developers of the Internet embrace remote work :)
IETF work is conducted mostly on email lists, hence the "many thousands of emails".
For some newer work like QUIC, GitHub is used to maintain a more to-the-minute shared view of the documents, and then again as mentioned in the text you quoted, GitHub Issues and PRs are used to manage the document, particularly by the most active participants.
https://github.com/quicwg/base-drafts - of course raising issues or PRs for them now won't do anything useful for you, because these RFCs were published. But you can see there were thousands of commits, one of the last being Martin Thompson's minor typographical tweaks summarised as "DOES IT NEVER END?!?".
Re: QUIC is now RFC 9000
#120Earlier quoted context omitted.
The “ossification” that QUIC deals with is primarily about internet routers who decide to dig into their IP packets. https://http3-explained.haxx.se/en/why-quic/why-ossification Many have optimisations around TCP and long-standing TCP characteristics, which they are able to do because the TCP headers are unencrypted. This led to TCP being difficult to improve, because of all the implementations out there making assum…
> The “ossification” that QUIC deals with is primarily about internet routers who decide to dig into their IP packets. Being 'opaque' to the network is not a foolproof choice, since it also makes stuff like NAT, congestion control and QoS a lot less robust. By exposing connection identifiers to the network, SCTP gains a lot of flexibility wrt. such scenarios compared to QUIC.
Correct me if I'm wrong, but bypassing NAT, congestion control and QoS is also a benefit when you want to build things like P2P services where you want a direct connection between peers and full control over the connection itself. QUIC will help a lot with those use cases.