QUIC is now RFC 9000

Post by Narishma » Fri, May 28, 2021, 1:06 PM UTC

alblue wrote: post #81

throwawaaarrgh wrote: post #51

Earlier quoted context omitted.

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…

> The big idea behind TCP/IP is that it's a stack which you can use anywhere and everywhere For what its worth, Windows 3.x did not come with a TCP/IP stack installed; it was an optional extra. (In the days before Windows 3.x you had to pay for the TCP/IP stack from your network card vendor as an optional extra.) It wasn’t until Win95 that the OS came bundled with TCP/IP by default, and you could still install other…

Post by detaro » Fri, May 28, 2021, 1:24 PM UTC

azernik wrote: post #103

bonzini wrote: post #67

Earlier quoted context omitted.

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

From context, I assumed detaro was referring to an ossification of SCTP .

Post by [deleted] » Fri, May 28, 2021, 1:39 PM UTC

cormacrelf wrote: post #64

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

Post by Orphis » Fri, May 28, 2021, 1:53 PM UTC

10000truths wrote: post #125

zozbot234 wrote: post #117

Earlier quoted context omitted.

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

NAT is a hack that only ever existed due to IP address exhaustion, and I’ve yet to find a good reason why congestion control and QoS handling in a router needs anything beyond what is already in the IP headers. SCTP’s flexibility is irrelevant since nobody uses it, arguably because of how much the Internet has ossified around TCP and UDP.

Post by Orphis » Fri, May 28, 2021, 2:02 PM UTC

jeltz wrote: post #53

throwawaaarrgh wrote: post #51

Earlier quoted context omitted.

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.