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.
Some notes about HTTP/3
11–20 of 181 posts
Re: Some notes about HTTP/3
#12This 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…
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.
Re: Some notes about HTTP/3
#13I feel like the adoption of HTTP/3 is going to be much much slower than HTTP/2... Besides Google Cloud do any of the major cloud providers have UDP load balancers?
As browsers adopt it I'm sure uptake will be significant given the advantages. I'm looking forward to IP roaming.
as a security person I'm looking forward to massive holes in IP roaming implementations.
Re: Some notes about HTTP/3
#14This 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…
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.
Re: Some notes about HTTP/3
#15I feel like the adoption of HTTP/3 is going to be much much slower than HTTP/2... Besides Google Cloud do any of the major cloud providers have UDP load balancers?
Corporate web proxies/filters will likely lag as well. https://support.forcepoint.com/KBArticle?id=000015410
Re: Some notes about HTTP/3
#16Wish we could just use SCTP instead: https://en.m.wikipedia.org/wiki/Stream_Control_Transmission_...
Re: Some notes about HTTP/3
#17Most of the deadliest DDoS attacks happen over UDP. Spoofing, reflection and amplification just to name a few. Many businesses just deny UDP to protect themself against the on going DDoS threats.
I feel this move won't make internet a better and safer place, but let's see.
Re: Some notes about HTTP/3
#18I feel like the adoption of HTTP/3 is going to be much much slower than HTTP/2... Besides Google Cloud do any of the major cloud providers have UDP load balancers?
The protocol has been designed so that both the endpoints of a stream can seamlessly change IP addresses. This ought to make load balancing easier?
Re: Some notes about HTTP/3
#19Wish we could just use SCTP instead: https://en.m.wikipedia.org/wiki/Stream_Control_Transmission_...
I'm curious, how does SCTP tunneled over UDP compare to QUIC?
Re: Some notes about HTTP/3
#20> Their second upgrade they called QUIC (pronounced "quick"), which is being standardized as HTTP/3.
Isn't QUIC new transport layer protocol based on UDP and, if I remember correctly, HTTP/3 will be HTTP bindings for QUIC?
You might think this is nitpicking, but HTTP is application layer protocol, so it's little bit confusing to me.