6 ms·

> Since it lives on top of UDP, I believe all you need is SOCK_DGRAM, right? The rest of QUIC can be in a userspace library ergonomically designed for your prog

by rewmie 3y ago

> Since it lives on top of UDP, I believe all you need is SOCK_DGRAM, right? The rest of QUIC can be in a userspace library ergonomically designed for your programming language e.g. (...) I think that OP's point is that there's no standard equivalent of the BSD sockets API for writing programs that communicate over QUIC, which refers to the userspace library you've referred to. A random project hosted in GitHub is not the same as a standard API.

pests 3y ago
> no standard equivalent of the BSD sockets API Did they not answer that question? It uses the BSD sockets API with SOCK_DGRAM? Right, that random project is not a standard API - its built using a standard API. You wouldn't expect BSD sockets to have HTTP built in... so you can find third-party random projects for HTTP implmented with BSD sockets just like you can find QUIC implmented with BSD sockets.
- jlokier 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. 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
- rewmie 3y ago
  > Did they not answer that question? It uses the BSD sockets API with SOCK_DGRAM? No, that does not answer the question, nor is it a valid answer to the question. Being able to send UDP datagrams is obviously not the same as establishing a QUIC connection. You're missing the whole point of the importance of having a standard API to establish network connections. > Right, that random project is not a standard API - its built using a standard API. Again, that's irrelevant and misses the whole point. Having access to a standard API to establish QUIC connections is as fundamental as having access to a standard API to establish a TCP connection. > so you can find third-party random projects for HTTP (...) The whole point of specifying standard APIs is to not have to search for and rely on random third-party projects to handle a fundamental aspect of your infrastructure.

by rewmie 3y ago

pests 3y ago

> no standard equivalent of the BSD sockets API Did they not answer that question? It uses the BSD sockets API with SOCK_DGRAM? Right, that random project is not a standard API - its built using a standard API. You wouldn't expect BSD sockets to have HTTP built in... so you can find third-party random projects for HTTP implmented with BSD sockets just like you can find QUIC implmented with BSD sockets.

jlokier 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. 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
rewmie 3y ago
> Did they not answer that question? It uses the BSD sockets API with SOCK_DGRAM? No, that does not answer the question, nor is it a valid answer to the question. Being able to send UDP datagrams is obviously not the same as establishing a QUIC connection. You're missing the whole point of the importance of having a standard API to establish network connections. > Right, that random project is not a standard API - its built using a standard API. Again, that's irrelevant and misses the whole point. Having access to a standard API to establish QUIC connections is as fundamental as having access to a standard API to establish a TCP connection. > so you can find third-party random projects for HTTP (...) The whole point of specifying standard APIs is to not have to search for and rely on random third-party projects to handle a fundamental aspect of your infrastructure.