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

61–70 of 246 posts

Re: QUIC is now RFC 9000

#61

Post by randomifcpfan »

yangl1996 wrote: post #44
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.

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

Yes, exactly. See this lwn article for more discussion of ossification: https://lwn.net/Articles/745590/

Re: QUIC is now RFC 9000

#62

Post by ec109685 »

ivan4th wrote: post #11

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 is a shame it’s not more widely deployed. It makes so much sense to be able to seamlessly handle transition from Wifi to Cellular.

It feels like Google is supporting some notion of this given Meet has seamless handoff as you leave Wifi.

Re: QUIC is now RFC 9000

#63

Post by anticensor »

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…

> By nature of being above UDP, QUIC is layer 5 or higher.

QUIC could also be encapsulated into IP without UDP, with a small modification: always use the framed mode. Hence it is actually a layer 4 protocol.

Re: QUIC is now RFC 9000

#64

Post by cormacrelf »

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…

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 assumptions and doing these optimisations that weren’t compatible with new developments, or worse, dropping traffic with new, unrecognised TCP options.

In comparison QUIC is almost 100% encrypted, and exposes comparatively little data for routers to ossify on. So even if network cards start optimising, they can only do so much damage because they are given very little information. For example, there is no way for them to do their own special per-stream flow control, because the stream identifier is encrypted. The only things visible are the UDP src/dest port, the QUIC connection ID, and a minimal set of flags. Most important is that the flow control information is encrypted, which is one of the main things TCP couldn’t improve on due to ossification.

That’s not to say the number of implementations stops being a problem — just means that you can actually use QUIC version numbers and negotiate features at the endpoints and ignore anybody along the routes. So you can get adoption of new ideas much more quickly.

Quick illustration of the things no longer visible to network operators: https://blog.apnic.net/wp-content/uploads/2019/03/quic-fig2...., from https://blog.apnic.net/2019/03/04/a-quick-look-at-quic/

Re: QUIC is now RFC 9000

#65

Post by skissane »

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…

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

I can't see why a user-space library couldn't hook the Berkeley sockets API calls and redirect them to a user-space implementation for IPPROTO_QUIC sockets. You may need to use some trick to distinguish native kernel sockets from user-space-implemented ones. (e.g. if you know the kernel only allocates FDs in a given range, use numbers outside that range to identify your user-space-implemented sockets). Someone could add a framework for doing this to the C library.

Actually I believe Windows has a built-in facility for doing this. To implement a new transport protocol in Winsock, you need to provide a transport provider DLL. Normally you'll also have a kernel-mode device driver, which the transport provider DLL calls, and the meat of the protocol implementation will be in that kernel-mode device driver not in the transport provider DLL. But I don't think it has to be that way – I don't believe there is anything stopping a Winsock transport provider from being written entirely in user-space.

Re: QUIC is now RFC 9000

#66

Post by lxgr »

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…

> By nature of being above UDP, QUIC is layer 5 or higher.

That doesn't seem like a fair characterization. In some TLS-based VPNs, IP is sent over TLS – does that make it a layer 7 protocol?

Re: QUIC is now RFC 9000

#67

Post by bonzini »

azernik wrote: post #60
detaro wrote: post #57

Earlier quoted context omitted.

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.

Which is an example of ossification, in this case at the IP level.

Re: QUIC is now RFC 9000

#68

Post by bonzini »

ekidd wrote: post #21
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? As other people have noted, yes. One of the interesting facts about the IETF is that they actually require two existing implementations in order to advance from an RFC to an official "Internet Standard": The IETF Standards Process (RFC 2026, updated by RFC 6410) requires at least two independent and inter-operable implement…

There are less than 100 Internet Standards (https://www.rfc-editor.org/standards).

Re: QUIC is now RFC 9000

#69

Post by ninepoints »

I wish the QUIC design was datagram-first... so many client/server implementations don't implement the datagram extension properly because it's... well an extension, and for most applications, reliable sequencing should be eschewed in favor of client-side reassembly. IMO QUIC was far too influenced by the legacy of how HTTP works when there was an opportunity to leapfrog a generation of bad decisions.

Re: QUIC is now RFC 9000

#70

Post by rofrol »

ninepoints wrote: post #69

I wish the QUIC design was datagram-first... so many client/server implementations don't implement the datagram extension properly because it's... well an extension, and for most applications, reliable sequencing should be eschewed in favor of client-side reassembly. IMO QUIC was far too influenced by the legacy of how HTTP works when there was an opportunity to leapfrog a generation of bad decisions.

Can you elaborate more? Is there some more information about this datagram-first?
Post reply on HN