Hacker News Reader

Comment by jeffbee | Hacker News Reader

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.

View on HN

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.

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

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.

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.

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.

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.

How would you make changes to the QUIC protocol then?

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.

Which policies are you speaking of? How are they hidden? What would you like to tweak that you can't?

Presumably all the sysctls?

http://www.linux-admins.net/2010/09/linux-tcp-tuning.html?m=...

& associated traffic shaping algorithms?

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

Can you point me to an example of a timer in the kernel that is not settable/tunable that should be? My experience in looking at such things suggests that most of the #defined bits are because RFCs define the protocol that way.

As for network stack per application: you're more than welcome to so so a myriad of ways - linux provides many different ways to pull raw IP, or raw ethernet into userspace (e.g. xdp, tun/tap devices, dpdk, and so on). It's not like you're being forced to use the kernel stack from lack of supported alternatives.

User-space apps have a lot more avenues for timely updates than middleboxes or kernel-space implementations do though, and developers have lots of experience with it. If middleboxes actually received timely updates and bugfixes, there would be no ossification in the first place, and a lot of other experiments would have panned out much better, much sooner than QUIC has (e.g. TCP Fast Open might not have been DOA.)

There's also a lot of work on interop testing for QUIC implementations; I think new implementations are strongly encouraged to join the effort: https://interop.seemann.io/

> 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.

This is already being done with event loops (libuv) and HTTP frameworks. I don't see why this would be a huge issue. It's also a boon for security and keeping software up-to-date because it's a lot easier to patch userspace apps than it is to roll out a new kernel patch across multiple kernels and force everyone to upgrade.

> 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.

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.

> 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.

Reply on news.ycombinator.com