"confusion between QUIC-the-transport-protocol, and QUIC-the-HTTP-binding. I and others have seen a number of folks not closely involved in this work conflating the two, even though they're now separate things."
Well, yeah, they have the same name. My first reaction to the headline was that lots of software isn't ready for http over udp.
The protocol differences are miniscule as well, pretty much a version bit and ever so slightly slimmed header requirements IIRC. I remember reading it and thinking "cool, generalized QUIC... looks like I can built an HTTP-like transport with it and that's it".
As for the HTTP over UDP, indeed - there is a reason Chrome has the ability to race a TCP connection alongside QUIC opens :).
AIUI, the QUIC protocol [1] will be a general-purpose transport protocol built on top of UDP that offers multiple independent streams with encryption. For the application it's like it can open as many TCP connections as it wants, without the extra overhead from handshakes and rate control start.
HTTP-over-QUIC [2] specifies how to talk HTTP 2 over the QUIC protocol, with some adjustments like using "native" QUIC streams instead of multiplexing streams over a TCP stream, and adjusting the header compression to allow more out-of-order operations.
> For the applications it’s like you can open as many TCP connections as you want without extra overhead from handshakes and rate control start.
This sounds a fascinating claim — is the idea that the programming model when implementing QUIC server applications will allow one to easily aggregate distinct server endpoints which automatically share or amortize the overhead of establishing encryption and congestion detection between all the logical streams used by the application across all the involved nodes?
I mean just between two endpoints, sorry for being imprecise. So instead of opening X TCP connections to a server to run requests in parallel, you'd use one QUIC connection with multiple streams. Much like HTTP 2 does, but using UDP instead of TCP so streams can be ordered and retransmitted separately.
This is a common way to describe congestion control which is a bit simple and reductive.
Given 2 endpoints on the network, you want to compute a congestion window for the entire flow rather than per-stream. Because
1) You can more accurately compute a single congestion window given aggregate stats from N streams rather than computing N congestion windows given stats from 1 stream each.
2) The congestion window is a shared resource across streams, which permits better network utilization
The other benefit of QUIC, coming from multiplexing streams over UDP rather than TCP, is that the "blast radius" arising from the consequences of a lost packet is better contained. It only impacts the stream that contained the packet; the rest of the flow can make progress uninhibited. So head-of-line blocking is not as severe.
QUIC offers a bunch of features HTTP wants. So this binding is about how you use those features. In some places HTTP/2 had a feature that QUIC now does better, in others QUIC offers something completely new.
Rebinding is an example of the latter. When you change networks (and thus addresses) in QUIC it can update the ongoing connection seamlessly.
Well, yeah, they have the same name. My first reaction to the headline was that lots of software isn't ready for http over udp.