6 ms·
The problem is there's no standard equivalent of the BSD sockets API for writing programs that communicate over QUIC. It'll always be niche outside the browser
by nly 3y ago
The problem is there's no standard equivalent of the BSD sockets API for writing programs that communicate over QUIC.
It'll always be niche outside the browser until this exists.
- jeffbee 3y agoNot 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 agoNo, 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 agoworth 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 agoI 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 agoBoth, 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 agoThe 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 agoI 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 agoHow would you make changes to the QUIC protocol then?
- jeffbee 3y agoI 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 agoWhich policies are you speaking of? How are they hidden? What would you like to tweak that you can't?
- 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 agoI 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.
- btown 3y agoSince 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. https://github.com/quinn-rs/quinn https://github.com/quinn-rs/quinn - and can interoperate with others who have made different choices. Alternately, if you need even higher performance, DPDK gives the abstractions you'd need; see e.g. https://dl.acm.org/doi/abs/10.1145/3565477.3569154 https://dl.acm.org/doi/abs/10.1145/3565477.3569154 on performance characteristics.
- 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 agoQUIC 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.
- dilyevsky 3y agoSame thing could be said about TLS (well if you ignore kTLS) yet it’s ubiquitous. All it needs is a openssl-type of library that’s easy to integrate