3 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 actuall

by 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.
rewmie 3y ago
> I was saying QUIC can be userspace just like (...) I think you're too hung up on "can" when that's way besides OP's point. The point is that providing access to fundamental features through a standard API is of critical importance. If QUIC is already massively adopted them there is no reason whatsoever to not provide a standard API. If QUIC was indeed developed to support changes then there is even fewer arguments to not provide a standard API.

by pests 3y ago

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.

rewmie 3y ago

> I was saying QUIC can be userspace just like (...) I think you're too hung up on "can" when that's way besides OP's point. The point is that providing access to fundamental features through a standard API is of critical importance. If QUIC is already massively adopted them there is no reason whatsoever to not provide a standard API. If QUIC was indeed developed to support changes then there is even fewer arguments to not provide a standard API.