5 ms·

QUIC is roughly TCP-equivalent not HTTP-equivalent, and we do have a BSD sockets API for TCP. You might be thinking of HTTP/3 rather than QUIC; HTTP/3 actually

QUIC is roughly TCP-equivalent not HTTP-equivalent, and we do have a BSD sockets API for TCP. You might be thinking of HTTP/3 rather than QUIC; HTTP/3 actually is HTTP-equivalent. You can turn the OP's question around. Every modern OS kernel provides an efficient, shared TCP stack. It isn't normal to implement TCP separately in each application or as a userspace library, although this is done occasionally. Yet we currently expect QUIC to be implemented separately in each application, and the mechanisms which are in the OS kernel for TCP are implemented in the applications for QUIC. So why don't we implement TCP separately in each application, the way it's done with QUIC? Although there were some advantages to this while the protocol was experimental and being stabilised, and for compatibility when running new applications on older OSes, arguably QUIC should be moved into the OS kernel to sit alongide TCP now that it's stable. The benefit of having Chrome, Firefox et al stabilise HTTP/3 and QUIC were good, but that potentially changes when the protocol is stable but there are thousands of applications, each with their own QUIC implementation doing congestion control differently, scheduling etc, and no cooperation with each other the way the OS kernel does with TCP streams from concurrent applications. Currently we are trending towards a mix of good and poor QUIC implementations on the network (in terms of things like congestion control and packet flow timing), rather than a few good ones as happens with TCP because modern kernels all have good quality implementations of TCP.

adwn 3y ago
Isn't the point of QUIC to offer high performance and flexibility at the same time? For these requirements, a one-size-fits-all API is rarely the way to go, so individual user-space implementations make sense. Compare this to file IO: For, many programs, the open/read/write/close FD API is sufficient, but if you require more throughput or control, its better to use a lower-level kernel interface and implement the missing functionality in user-space, tailored to your particular needs.
- londons_explore 3y ago
  Like what exactly? Are all the cool Devs sending nvme write commands straight to the SSD now for more control?
pests 3y ago
> QUIC is roughly TCP-equivalent not HTTP-equivalent, and we do have a BSD sockets API for TCP. You might be thinking of HTTP/3 rather than QUIC; HTTP/3 actually is HTTP-equivalent. No, I understand QUIC is a transport and HTTP/3 is the next HTTP protocol that runs over QUIC. I was saying QUIC can be userspace just like HTTP is userspace over kernel TCP API. We haven't moved HTTP handling into the kernel so what makes QUIC special? I think it is just too early to expect every operating system to have a standard API for this. We didn't have TCP api's built-in originally either.
- Dylan16807 3y ago
  > We haven't moved HTTP handling into the kernel so what makes QUIC special? I feel like they answered that, but I'll try rewording it. What makes TCP special that we put it in the kernel? A lot more of those answers apply to QUIC than to HTTP. > I think it is just too early to expect every operating system to have a standard API for this. We didn't have TCP api's built-in originally either. Okay, if you're comparing to TCP by saying it's too early then it sounds like you do already see the reasons in favor.
  - PoignardAzur 3y ago
    > What makes TCP special that we put it in the kernel? A lot more of those answers apply to QUIC than to HTTP. I mean, that seems like GP's point. There's no profound reason TCP should be implemented in the kernel, besides trying to fit every form of IO into Unix's "everything is a file descriptor" philosophy. If QUIC works in userspace, that's fine. If it ain't broke, don't fix it.
    - Dylan16807 3y ago
      > I mean, that seems like GP's point. Huh, you think so? I'd be a bit surprised if that was the intent, because TCP obviously is in the kernel, so if their point blatantly disagrees with preexisting decisions in every OS then that's something that needs to be addressed before we can talk about QUIC.
- 3y ago
btown 3y ago
It occurs to me that QUIC could benefit from a single kernel-level coordinator that can be plugged for cooperation - for instance, a dynamic bandwidth-throttling implementation a la https://tripmode.ch/ https://tripmode.ch/ for slower connections where the coordinator can look at pre-encryption QUIC headers, not just the underlying (encrypted) UDP packets. So perhaps I was hasty to say that you just need SOCK_DGRAM after all!
- Animats 3y ago
  But then Google couldn't prioritize ad content.
Nullabillity 3y ago
> So why don't we implement TCP separately in each application, the way it's done with QUIC? Because TCP also does multiplexing, which must be handled in some central coordinating service. QUIC doesn't suffer from that since it offloads that to UDP. You wouldn't use a system TLS implementation either (well, technically SChannel/NetworkTransport exist, but you're vastly better off ignoring them).
- nly 3y ago
  Offloads that to UDP is a nice way of saying "you get random packet drops determined by some router between A and B"
  - Nullabillity 3y ago
    That's going to happen regardless, that's just the nature of Ethernet, or even just existing in reality. TCP has to deal with the same thing. Either way the solution is the same: acks and retransmissions.
lmm 3y ago
> So why don't we implement TCP separately in each application, the way it's done with QUIC? Because library/dependency management sucked at the time, and OSes competed for developers by trying to offer more libraries; on the other side we were less worried about EEE because cross-platform codebases were rare and usually involved extensive per-OS code with #ifdefs or the like. I don't think we would or should put TCP in the kernel if it was being made today.
- topspin 3y ago
  > Because library/dependency management sucked at the time It still sucks. Thus Docker et al.
  - lmm 3y ago
    Only in Python (and C/C++). No one else wants the overheard of Docker.
evgpbfhnr 3y ago
QUIC is TLS-equivalent, not TCP-equivalent. The analogy you're looking for is something like openssl's SSL_* API and.. it's coming for QUIC: https://www.openssl.org/docs/manmaster/man7/openssl-quic.html https://www.openssl.org/docs/manmaster/man7/openssl-quic.htm... There are dozen of libs to do it right now but I expect ultimately distro folks will want to consolidate it all to avoid redundant dependencies, so we'll probably end up with openssl/gnutls/libressl doing it eventually and most apps using that. Note there were talks to add it in-kernel like kTLS, but since the certificate handling is difficult that part will be offloaded to userspace as it is with kTLS -- you won't ever get an interface like connect() and forget about it.
- rewmie 3y ago
  > QUIC is TLS-equivalent, not TCP-equivalent. From Wikipedia[1]: "QUIC improves performance of connection-oriented web applications that are currently using TCP.[QUIC] is designed to obsolete TCP at the transport layer for many applications, thus earning the protocol the occasional nickname "TCP/2"." Also taken from the wiki page: "QUIC aims to be nearly equivalent to a TCP connection but with much-reduced latency." Here is the only relevant bit regarding TLS: "As most HTTP connections will demand TLS, QUIC makes the exchange of setup keys and supported protocols part of the initial handshake process. When a client opens a connection, the response packet includes the data needed for future packets to use encryption. This eliminates the need to set up the TCP connection and then negotiate the security protocol via additional packets." [1] https://en.m.wikipedia.org/wiki/QUIC https://en.m.wikipedia.org/wiki/QUIC
  - evgpbfhnr 3y ago
    The RFCs for QUIC (RFC 9000 and RFC 9001) mandate encryption. Some random stackoverflow answer[1] claims there are implementations that ignore this and allow "QUIC without encryption", but I'd argue that it's not QUIC anymore -- in my opinion it'd be harmful to implement in the kernel. [1] https://stackoverflow.com/a/72828565/2332808 https://stackoverflow.com/a/72828565/2332808
    - 3y ago

adwn 3y ago

Isn't the point of QUIC to offer high performance and flexibility at the same time? For these requirements, a one-size-fits-all API is rarely the way to go, so individual user-space implementations make sense. Compare this to file IO: For, many programs, the open/read/write/close FD API is sufficient, but if you require more throughput or control, its better to use a lower-level kernel interface and implement the missing functionality in user-space, tailored to your particular needs.

londons_explore 3y ago
Like what exactly? Are all the cool Devs sending nvme write commands straight to the SSD now for more control?

pests 3y ago

> QUIC is roughly TCP-equivalent not HTTP-equivalent, and we do have a BSD sockets API for TCP. You might be thinking of HTTP/3 rather than QUIC; HTTP/3 actually is HTTP-equivalent. No, I understand QUIC is a transport and HTTP/3 is the next HTTP protocol that runs over QUIC. I was saying QUIC can be userspace just like HTTP is userspace over kernel TCP API. We haven't moved HTTP handling into the kernel so what makes QUIC special? I think it is just too early to expect every operating system to have a standard API for this. We didn't have TCP api's built-in originally either.

Dylan16807 3y ago
> We haven't moved HTTP handling into the kernel so what makes QUIC special? I feel like they answered that, but I'll try rewording it. What makes TCP special that we put it in the kernel? A lot more of those answers apply to QUIC than to HTTP. > I think it is just too early to expect every operating system to have a standard API for this. We didn't have TCP api's built-in originally either. Okay, if you're comparing to TCP by saying it's too early then it sounds like you do already see the reasons in favor.
- PoignardAzur 3y ago
  > What makes TCP special that we put it in the kernel? A lot more of those answers apply to QUIC than to HTTP. I mean, that seems like GP's point. There's no profound reason TCP should be implemented in the kernel, besides trying to fit every form of IO into Unix's "everything is a file descriptor" philosophy. If QUIC works in userspace, that's fine. If it ain't broke, don't fix it.
  - Dylan16807 3y ago
    > I mean, that seems like GP's point. Huh, you think so? I'd be a bit surprised if that was the intent, because TCP obviously is in the kernel, so if their point blatantly disagrees with preexisting decisions in every OS then that's something that needs to be addressed before we can talk about QUIC.
3y ago

btown 3y ago

It occurs to me that QUIC could benefit from a single kernel-level coordinator that can be plugged for cooperation - for instance, a dynamic bandwidth-throttling implementation a la https://tripmode.ch/ https://tripmode.ch/ for slower connections where the coordinator can look at pre-encryption QUIC headers, not just the underlying (encrypted) UDP packets. So perhaps I was hasty to say that you just need SOCK_DGRAM after all!

Animats 3y ago
But then Google couldn't prioritize ad content.

Nullabillity 3y ago

> So why don't we implement TCP separately in each application, the way it's done with QUIC? Because TCP also does multiplexing, which must be handled in some central coordinating service. QUIC doesn't suffer from that since it offloads that to UDP. You wouldn't use a system TLS implementation either (well, technically SChannel/NetworkTransport exist, but you're vastly better off ignoring them).

nly 3y ago
Offloads that to UDP is a nice way of saying "you get random packet drops determined by some router between A and B"
- Nullabillity 3y ago
  That's going to happen regardless, that's just the nature of Ethernet, or even just existing in reality. TCP has to deal with the same thing. Either way the solution is the same: acks and retransmissions.

lmm 3y ago

> So why don't we implement TCP separately in each application, the way it's done with QUIC? Because library/dependency management sucked at the time, and OSes competed for developers by trying to offer more libraries; on the other side we were less worried about EEE because cross-platform codebases were rare and usually involved extensive per-OS code with #ifdefs or the like. I don't think we would or should put TCP in the kernel if it was being made today.

topspin 3y ago
> Because library/dependency management sucked at the time It still sucks. Thus Docker et al.
- lmm 3y ago
  Only in Python (and C/C++). No one else wants the overheard of Docker.

evgpbfhnr 3y ago

QUIC is TLS-equivalent, not TCP-equivalent. The analogy you're looking for is something like openssl's SSL_* API and.. it's coming for QUIC: https://www.openssl.org/docs/manmaster/man7/openssl-quic.html https://www.openssl.org/docs/manmaster/man7/openssl-quic.htm... There are dozen of libs to do it right now but I expect ultimately distro folks will want to consolidate it all to avoid redundant dependencies, so we'll probably end up with openssl/gnutls/libressl doing it eventually and most apps using that. Note there were talks to add it in-kernel like kTLS, but since the certificate handling is difficult that part will be offloaded to userspace as it is with kTLS -- you won't ever get an interface like connect() and forget about it.

rewmie 3y ago
> QUIC is TLS-equivalent, not TCP-equivalent. From Wikipedia[1]: "QUIC improves performance of connection-oriented web applications that are currently using TCP.[QUIC] is designed to obsolete TCP at the transport layer for many applications, thus earning the protocol the occasional nickname "TCP/2"." Also taken from the wiki page: "QUIC aims to be nearly equivalent to a TCP connection but with much-reduced latency." Here is the only relevant bit regarding TLS: "As most HTTP connections will demand TLS, QUIC makes the exchange of setup keys and supported protocols part of the initial handshake process. When a client opens a connection, the response packet includes the data needed for future packets to use encryption. This eliminates the need to set up the TCP connection and then negotiate the security protocol via additional packets." [1] https://en.m.wikipedia.org/wiki/QUIC https://en.m.wikipedia.org/wiki/QUIC
- evgpbfhnr 3y ago
  The RFCs for QUIC (RFC 9000 and RFC 9001) mandate encryption. Some random stackoverflow answer[1] claims there are implementations that ignore this and allow "QUIC without encryption", but I'd argue that it's not QUIC anymore -- in my opinion it'd be harmful to implement in the kernel. [1] https://stackoverflow.com/a/72828565/2332808 https://stackoverflow.com/a/72828565/2332808
  - 3y ago