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

41–50 of 246 posts

Re: QUIC is now RFC 9000

#41

Post by wmf »

DaiPlusPlus wrote: post #39
wmf wrote: post #37

Earlier quoted context omitted.

I think from their perspective the (Windows and Android) kernel is what causes ossification so moving transport into the app, along with encryption, solves it.

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.

Re: QUIC is now RFC 9000

#43

Post by gumby »

hydrox24 wrote: post #10

Have 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?

In general, yes: modern RFCs should address existing practice.

The very early RFCs were just that: requests for comments, i.e. memos. Sometimes reflection on existing practice, sometimes design discussions.

For your specific examples (TCP and UDP): they were part of a redesign of the Internet protocols (well a redesign of the ARPANET's protocols TBH, NCP, with the intent of enabling smooth internetworking). So those RFCs reflected the specification of new protocols, though some experimentation had been done.

I remember the transition day. The first machines, IIRC were ITS machines that some had hoped would not make the transition at all! I don't believe there were any Unix machines on the net that day -- Berkeley sockets hadn't yet been released.

Re: QUIC is now RFC 9000

#44

Post by yangl1996 »

wmf wrote: post #37
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…

I think from their perspective the (Windows and Android) kernel is what causes ossification so moving transport into the app, along with encryption, solves it.

There are also the "middle boxes" that networking researchers talk a lot about. Such devices sit in the middle of a link and easily become unhappy if the packets transmitted do not fit some (possibly outdated or buggy) predefined scheme. Think of cooperate firewalls with "deep pack inspection" that intelligently shut down connections they do not like. Once all middle box vendors start to assume a certain way that a protocol (say, TCP) should behave, it's impossible to change the protocol because it will break the middle boxes.

Encrypting QUIC datagrams prevents middle box vendors from assuming anything about QUIC (at least the encrypted part), so that QUIC can change if there's a need in the future without worrying about supporting legacy middle boxes. Although I do agree using UDP does not allow QUIC to break out from any ossification in UDP itself.

Re: QUIC is now RFC 9000

#45

Post by ucarion »

infogulch wrote: post #31
ucarion wrote: post #20

Earlier quoted context omitted.

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.

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.

Re: QUIC is now RFC 9000

#46

Post by wmf »

jiggawatts wrote: post #42
xxpor wrote: post #32

And anyone who ever operated a stateful firewall cried a little bit inside.

I would argue that with 200 Gbps NICs starting to become mainstream, the era of stateful firewalls in general is over...

No see, the NIC now includes a stateful firewall so you can implement it at each server at line rate.

Re: QUIC is now RFC 9000

#47

Post by skissane »

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). Which also increases context switching

Nowhere does RFC9000 say that it has to be implemented in user-space. A kernel-space implementation of QUIC would be conforming. Any OS kernel project (whether open source or proprietary) which would like to develop one is free to do so.

Re: QUIC is now RFC 9000

#48

Post by jeltz »

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.

Re: QUIC is now RFC 9000

#49

Post by d110af5ccf »

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 at this point? If not, why?!

Re: QUIC is now RFC 9000

#50

Post by inetknght »

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

Post reply on HN