4 ms·

Not having a system API is the entire point of QUIC. The only reason QUIC needs to exist is because the sockets API and the system TCP stacks are too ossified t

Not having a system API is the entire point of QUIC. The only reason QUIC needs to exist is because the sockets API and the system TCP stacks are too ossified to be improved. If you move that boundary then QUIC will inevitably suffer from the same ossification that TCP displays today.

tsimionescu 3y ago
No, the reason QUIC exists is that TCP is ossified at the level of middle boxes on the internet. If it had been possible to modify TCP with just some changes in the Linux, BSD and Windows kernels, it would have been done.
- gjvc 3y ago
  worth defining "middlebox" """ A middlebox is a computer networking device that transforms, inspects, filters, and manipulates traffic for purposes other than packet forwarding. Examples of middleboxes include firewalls, network address translators (NATs), load balancers, and deep packet inspection (DPI) devices. """ https://en.wikipedia.org/wiki/Middlebox https://en.wikipedia.org/wiki/Middlebox
- Dylan16807 3y ago
  I don't know about that. Without middlebox problems we might have used SCTP as a basis and upgraded it. But it's so different from TCP that I doubt we would have done it as a modification of TCP.
- lima 3y ago
  Both, really. The OS-level ossification isn't quite as bad as the middleboxes, but is still glacially slow and bad enough to justify QUIC on its own. Case in point: the whole TCP Fast Open drama.
xg15 3y ago
The alternative is that either browsers will be the only users of QUIC - or that each application is required to bring its own QUIC implementation embedded into the binary. If ossification was bad if every router and firewall has its own TCP stack, have fun in a world where every app has its own QUIC stack.
- jeffbee 3y ago
  I am not seeing the problem with every participant linking in their own QUIC implementations. The problem of ossification is there is way too much policy hidden on the kernel side of the sockets API, and vanishingly few applications are actually trying to make contact with Mars, which is the use-case for which those policies are tuned.
  - xg15 3y ago
    How would you make changes to the QUIC protocol then?
    - jeffbee 3y ago
      I wouldn't. I would write down the protocol in a good and extensible way, the first time. It's no good throwing something into the world with the assumption that you can fix the protocol later.
  - sophacles 3y ago
    Which policies are you speaking of? How are they hidden? What would you like to tweak that you can't?
    - theptip 3y ago
      Presumably all the sysctls? http://www.linux-admins.net/2010/09/linux-tcp-tuning.html?m=1 http://www.linux-admins.net/2010/09/linux-tcp-tuning.html?m=... & associated traffic shaping algorithms?
    - jeffbee 3y ago
      There are a billion timers inside the kernel, not all of which can be changed. Some of them are #defined even. In these days when machines are very large and always have several applications running, having an external network stack in the kernel violates the end-to-end principle. All of the policy about congestion, retrying, pacing, shaping, and flow control belong inside the application. https://en.wikipedia.org/wiki/End-to-end_principle https://en.wikipedia.org/wiki/End-to-end_principle
xg15 3y ago
> because the sockets API and the system TCP stacks are too ossified to be improved What part of the sockets API specifically do you think is ossified? Also, that doesn't seem to have kept the kernel devs from introducing new IO APIs like io_uring.
mmis1000 3y ago
I think the point of QUIC is 'if the implementation other using is problematic, I can use my own. And no random middlebox will prevent me from doing so' instead of `everyone must bring their own QUIC implementation.` There is a slight different here. It's the difference between 'the right to do' and 'the requirement to do'. While at same time. You must use 'system tcp implementation' and you are not allowed to use custom one. Because even system allow it (maybe require root permission or something), the middlebox won't.
rewmie 3y ago
> Not having a system API is the entire point of QUIC. The only reason QUIC needs to exist is because the sockets API and the system TCP stacks are too ossified to be improved. I don't think your take is correct. The entire point if QUIC was that you could not change TCP without introducing breaking changes, not that there were system APIs for TCP. Your point is also refuted by the fact that QUIC is built over UDP. As far as I can tell there is no real impediment to provide a system API for QUIC.

tsimionescu 3y ago

No, the reason QUIC exists is that TCP is ossified at the level of middle boxes on the internet. If it had been possible to modify TCP with just some changes in the Linux, BSD and Windows kernels, it would have been done.

gjvc 3y ago
worth defining "middlebox" """ A middlebox is a computer networking device that transforms, inspects, filters, and manipulates traffic for purposes other than packet forwarding. Examples of middleboxes include firewalls, network address translators (NATs), load balancers, and deep packet inspection (DPI) devices. """ https://en.wikipedia.org/wiki/Middlebox https://en.wikipedia.org/wiki/Middlebox
Dylan16807 3y ago
I don't know about that. Without middlebox problems we might have used SCTP as a basis and upgraded it. But it's so different from TCP that I doubt we would have done it as a modification of TCP.
lima 3y ago
Both, really. The OS-level ossification isn't quite as bad as the middleboxes, but is still glacially slow and bad enough to justify QUIC on its own. Case in point: the whole TCP Fast Open drama.

xg15 3y ago

The alternative is that either browsers will be the only users of QUIC - or that each application is required to bring its own QUIC implementation embedded into the binary. If ossification was bad if every router and firewall has its own TCP stack, have fun in a world where every app has its own QUIC stack.

jeffbee 3y ago
I am not seeing the problem with every participant linking in their own QUIC implementations. The problem of ossification is there is way too much policy hidden on the kernel side of the sockets API, and vanishingly few applications are actually trying to make contact with Mars, which is the use-case for which those policies are tuned.
- xg15 3y ago
  How would you make changes to the QUIC protocol then?
  - jeffbee 3y ago
    I wouldn't. I would write down the protocol in a good and extensible way, the first time. It's no good throwing something into the world with the assumption that you can fix the protocol later.
- sophacles 3y ago
  Which policies are you speaking of? How are they hidden? What would you like to tweak that you can't?
  - theptip 3y ago
    Presumably all the sysctls? http://www.linux-admins.net/2010/09/linux-tcp-tuning.html?m=1 http://www.linux-admins.net/2010/09/linux-tcp-tuning.html?m=... & associated traffic shaping algorithms?
  - jeffbee 3y ago
    There are a billion timers inside the kernel, not all of which can be changed. Some of them are #defined even. In these days when machines are very large and always have several applications running, having an external network stack in the kernel violates the end-to-end principle. All of the policy about congestion, retrying, pacing, shaping, and flow control belong inside the application. https://en.wikipedia.org/wiki/End-to-end_principle https://en.wikipedia.org/wiki/End-to-end_principle

xg15 3y ago

> because the sockets API and the system TCP stacks are too ossified to be improved What part of the sockets API specifically do you think is ossified? Also, that doesn't seem to have kept the kernel devs from introducing new IO APIs like io_uring.

mmis1000 3y ago

I think the point of QUIC is 'if the implementation other using is problematic, I can use my own. And no random middlebox will prevent me from doing so' instead of `everyone must bring their own QUIC implementation.` There is a slight different here. It's the difference between 'the right to do' and 'the requirement to do'. While at same time. You must use 'system tcp implementation' and you are not allowed to use custom one. Because even system allow it (maybe require root permission or something), the middlebox won't.

rewmie 3y ago

> Not having a system API is the entire point of QUIC. The only reason QUIC needs to exist is because the sockets API and the system TCP stacks are too ossified to be improved. I don't think your take is correct. The entire point if QUIC was that you could not change TCP without introducing breaking changes, not that there were system APIs for TCP. Your point is also refuted by the fact that QUIC is built over UDP. As far as I can tell there is no real impediment to provide a system API for QUIC.