Hacker News Reader

Comment by romed | Hacker News Reader

This post groks QUIC. The most important thing about QUIC is it frees applications from the tyranny of the kernel TCP state machine. Today all TCP sockets (at least, on Linux) are subject to the same system-wide parameters of the TCP state machine, none of which are appropriate for any particular application. With QUIC we will finally have each application in control of its own retry timers and other parameters. That is going to be quite beneficial, especially on mobile where packet loss is so common.

View on HN

setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, ...)

setsockopt(fd, SOL_SOCKET, SO_SNDTIMEO, ...)

I'm not dismissing QUIC, but it is in your control to redefine those defaults. Maybe in 2020 we'll be grappling back toward [sane] defaults.

Those do not affect TCP state machine parameters like RTO(min), ATO, and TLP timeout. These are internal to the kernel and are either static, or can only be set systemwide. For example the minimum delayed ack timeout in Linux is just 40ms and can't be changed except by recompiling the kernel. 40ms is a totally inappropriate number for ATO in a datacenter or other low-latency setting. Other numbers like RTO(min) are specified in RFCs as 200ms, again completely inappropriate in a low-latency setting.

QUIC also frees us from other outdated misfeatures of TCP such as timestamps in milliseconds when they should be in microseconds.

Again, as someone who does not completely grok QUIC I am not dismissing it. I was hoping if some parameters were not exposed work would be put toward making these available through existing interfaces.

Linux network maintainers have repeatedly rejected attempts by Eric Dumazet and others to expose delack_min and other parameters to userspace. This is the kernel tyranny to which I refer.

Notably many of the people whose proposals have been shot down by linux netdev are currently working on QUIC.

Somewhat related: I do hope userspace network stacks get easier to stand up (with strict testing). It would be nice to move an attack surface like that out of the kernel.

How does QUIC compare to HTTP/2 over SCTP?

IETF - A Comparison between SCTP and QUIC [0]

0. https://tools.ietf.org/html/draft-joseph-quic-comparison-qui...

QUIC is somewhat comparable to SCTP. But in both situations you wouldn't be using HTTP/2 on top of it. One of the main points of HTTP/2 is multiplexing several streams over a single transport stream. This isn't needed anymore with QUIC or SCTP, since they already perform stream multiplexing. The only thing which is left is transferring HTTP semantics over those QUIC or SCTP streams. The most simple way to do that would be doing HTTP/1.1 over them. However as far as I know (haven't read the latest state) QUIC uses a more sophisticated mechanism, which also provides header compression and caching across multiple streams, similar to HTTP/2. So it adopted some parts of HTTP/2, but isn't really HTTP/2 over QUIC/SCTP.

You can tweak rto_min per route, with ip route.

Yep, but it would be inadvisable to set it lower than the peer’s delayed ACK timeout, unless you want to just always resend every packet.

For a webserver won't that just be the default route most of the time? It's effectively a systemwide tune at that point.

The shorter timeout would likely be for downstream app servers in the same datacenter, not for the general internet. That is, adding a route for a specific network not because the default route doesn't work, but for tuning that setting only for that network.

Reply on news.ycombinator.com