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