Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

QUIC is now RFC 9000

fastly.com

Post reply on HN
Print view View original

51–60 of 246 posts

Re: QUIC is now RFC 9000

#51

Post by throwawaaarrgh »

jeltz wrote: post #48
throwawaaarrgh wrote: post #35

> 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…

Why can't QUIC be implemented in the Kernel? Just because something can be implemented in user space does not mean that it has to.

Anything can be implemented in a kernel. But unless it's natively supported in other kernels, networks, and systems, that just means that one kernel is easier to work with.

The big idea behind TCP/IP is that it's a stack which you can use anywhere and everywhere. Not just any network, but any host. To do that, you need it to be portable and ubiquitous. And there is no protocol above OSI layer 4 that is ubiquitous. By nature of being above UDP, QUIC is layer 5 or higher. And it's got more features than other protocols do, meaning it needs more functions.

So not only is it unlikely that it'll be supported like the layer 4 protocols, it's unlikely to be supported by the Berkeley/POSIX sockets API, the one portable network interface specification for every operating system. One solution to all this would be to make QUIC a layer 4 protocol and update the sockets API. But nobody wants to do this because it's hard.

So, we could just have everyone add a layer 5 protocol to their stack, implement it in kernels, NICs, routers, etc, update the sockets API, and wait a few years for adoption. But will that happen? Or will the industry just go "let userspace handle it" like with TLS?

Re: QUIC is now RFC 9000

#52

Post by detaro »

inetknght wrote: post #50
throwawaaarrgh wrote: post #35

> 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…

> 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 lot of extra work) TLS is available in the Linux kernel. https://www.kernel.org/doc/html/latest/networking/tls.html

That is merely offloading for the transfer after userland has handled the entire connection setup, key exchange etc.

Re: QUIC is now RFC 9000

#53

Post by jeltz »

throwawaaarrgh wrote: post #51
jeltz wrote: post #48

Earlier quoted context omitted.

Why can't QUIC be implemented in the Kernel? Just because something can be implemented in user space does not mean that it has to.

Anything can be implemented in a kernel. But unless it's natively supported in other kernels, networks, and systems, that just means that one kernel is easier to work with. The big idea behind TCP/IP is that it's a stack which you can use anywhere and everywhere. Not just any network, but any host. To do that, you need it to be portable and ubiquitous. And there is no protocol above OSI layer 4 that is ubiquitous. By…

I really do not see how the layers matter. They are just an artificial categorization. E.g. SCTP is both a layer 4 protocol and a layer 5 protocol (SCTP-over-UDP) and as far as I can tell from some quick googling at least both Linux and FreeBSD implement both in their kernels. What matters is if various libcs add QUIC or not.

And the Linux kernel implements other layer 5 protcols like WireGuard.

Re: QUIC is now RFC 9000

#54

Post by fierro »

d110af5ccf wrote: post #49
throwawaaarrgh wrote: post #35

> 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…

> Every app has to implement it itself No? I'll just link against one of the cross platform libraries that implements it, the same as for any other networking protocol. (Ex https://github.com/microsoft/msquic ) Also see: https://github.com/quicwg/base-drafts/wiki/Implementations > same as for TLS, making fewer apps implement it without a lot of extra work ... do you not just link against a relevant networking library…

my guy out here rolling his own TLS implementation

Re: QUIC is now RFC 9000

#55

Post by DaiPlusPlus »

wmf wrote: post #41
DaiPlusPlus wrote: post #39

Earlier quoted context omitted.

You're forgetting the rest of userspace that exists between the application and the kernel. > moving transport into the app, along with encryption, solves it This is only a good idea if the application's development moves faster than both the kernel and the rest of the userspace platform - which is a fine strategy if you're targeting old or obsolete platforms, but probably a bad idea if you're targeting currently-sup…

Let's be honest; we're talking about Chrome here. Chrome auto-updates and Windows (pre-10) did not so bugs will be fixed faster in Chrome. Everybody else is along for the ride.

Right - so in Chrome's case then Google using QUIC as an in-app service is probably fine, as indeed, I trust Google to ship fixes and updates much faster than Microsoft. Also it's far more likely that enterprises have Windows Updates blocked or delayed than Chrome updates - and with Microsoft updates you have to wait for Patch Tuesday every month unless it's something really bad.

My point still stands though, that if you aren't prepared to support an "evergreen" software product for the life of your users, then you should still support OS-provided services, even if you do have your own QUIC support baked-in to your product.

Re: QUIC is now RFC 9000

#56

Post by petre »

throwawaaarrgh wrote: post #35

> 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…

There is also SCTP at layer 4 but it doesn't get much use outside certain domains, so certain OSes have deprecated it.

Also as others pointed out applications will just use a library as they do now with OpenSSL.

Re: QUIC is now RFC 9000

#57

Post by detaro »

petre wrote: post #56
throwawaaarrgh wrote: post #35

> 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…

There is also SCTP at layer 4 but it doesn't get much use outside certain domains, so certain OSes have deprecated it. Also as others pointed out applications will just use a library as they do now with OpenSSL.

because of the ossification that makes it hard/impossible to use.

Re: QUIC is now RFC 9000

#58

Post by dcow »

ucarion wrote: post #45
infogulch wrote: post #31

Earlier quoted context omitted.

Curious, why isn't it numbered the other way? My programming brain is telling me that if you're reading rfc9000 you can't reference rfc9001 because it hasn't been initialized yet. :D

Perhaps I should clarify: rfc9001 normatively refers to rfc9000 (and vice versa). There are cyclical references between RFCs, so there isn't any topological ordering. It works out because RFCs convey ideas, not code. The authors and editors take care to make sure the cyclical dependencies don't imply circular definitions or other incoherences.

It works in code too. It’s the difference between declaration and initialization. Very commonly existence of a symbol is declared in a header so that it can be referenced only later does the real implementation get linked in.

Re: QUIC is now RFC 9000

#59

Post by vincnetas »

snuxoll wrote: post #24
infogulch wrote: post #4

Should have waited for 9001. Oh my mistake, they have several RFCs from 8999-9002.

Is QUIC really worthy of the over 9000 meme? I can’t help but feel we wasted a once in a lifetime opportunity.

To be used as 9000 meme it should have been "over 9000"

https://en.wikipedia.org/wiki/It%27s_Over_9000!

Re: QUIC is now RFC 9000

#60

Post by azernik »

detaro wrote: post #57
petre wrote: post #56

Earlier quoted context omitted.

There is also SCTP at layer 4 but it doesn't get much use outside certain domains, so certain OSes have deprecated it. Also as others pointed out applications will just use a library as they do now with OpenSSL.

because of the ossification that makes it hard/impossible to use.

I assume you're referring to the disuse of SCTP?

That's not because of ossification, it's because of middleware boxes like NATs and firewalls that will refuse to pass anything that isn't TCP, UDP, or ICMP.

Post reply on HN