3 ms·

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 a

by tveita 8y ago

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. [1] https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ [2] https://datatracker.ietf.org/doc/draft-ietf-quic-http/ https://datatracker.ietf.org/doc/draft-ietf-quic-http/

breatheoften 8y ago
> 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?
- tveita 8y ago
  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.
jganetsk 8y ago
"handshakes and rate control start" 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.

by tveita 8y ago

breatheoften 8y ago

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

tveita 8y ago
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.

jganetsk 8y ago

"handshakes and rate control start" 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.