4 ms·

QUIC does things TCP will never do. Firstly QUIC is a combination of SSL + TCP. This allows it put the SSL handshake into the TCP handshake - thus reducing th

QUIC does things TCP will never do. Firstly QUIC is a combination of SSL + TCP. This allows it put the SSL handshake into the TCP handshake - thus reducing the overhead of starting an SSL connection. It also leverages SSL session reuse to avoid the TCP 3 package handshake completely. As others have mentioned, QUIC is optimised for something that HTTP/2 does often that TCP does not support very well - multiple child streams over the one connection. In general, it is true that TCP is highly optimised, but it is only optimised for one use case: a long lived single flow over a low error rate connection to a single destination. That was the predominate type of connection back in the FTP and early web days. But is hasn't been that way for a while now. HTTP is short lived, video goes to multi destinations, HTTP/2 and multi media in general has multiple flows. Wireless only appears to be low error rate because the physical layer had to cover up it's shortcomings otherwise TCP's performance became abysmal. TCP hasn't remained king of the mountain because its fantastic protocol that can't be improved. On the contrary - looks to be the simplest thing it's inventors could come up with. It even lacked round trip time measurement - which is something I suspect that would have killed it if an extension hadn't saved it. TCP has remained king of the mountain purely because it appears to be near impossible to replace. Now that Google has done it, I expect we will see a lot more experimentation in this area.

ktpsns 8y ago
Nice review. Just a theoretical question: Wasn't IPsec supposed to do the encryption right in the IP layer? I wonder how this compares with the handshake roundtrip time needed (for IPsec, for TCP).
- pas 8y ago
  Well, the problem is complex. For security you need integrity, authenticity and anonimity/secrecy. Crypto of course is the way we implement all that, via keys and other kind of information theoretic tokens that somehow build upon a pre-shared secret. You need an anchor, a mutual trust foundation to build your secure channel upon. If you want to put security on/into IP, you suddenly need the whole key management thing, and if you want it to be automatic, you need to somehow cobble together the assignment, provisioning, allocation, publication, revocation of keys with IP addresses (or hostnames, domain names, and you just put DNS into IP). Eventually it means either you need manual key management (thus IPsec becames a hard to manage old rusty and poorly supported concept from an old era) or you just descended into the recursive pit of all hells of circular dependencies. Sure, it can be done, we can put keys into DNS, and we can use that, but then we're back to QUIC or DTLS basically.
- rocqua 8y ago
  The issue is that IP is generally handeled by the OS. This means that IPsec also needs to be handled by the OS. The thing is, how you set up (mutual) authentication is very much an application level thing. Do you want certs, an SSH key, passwords, hardware tokens, SIM based authentication, or something else? These aren't things the OS can decide, and they aren't so simple we could tell the OS what we want with a few flags.
- dcbadacd 8y ago
  Doesn't IPsec suffer from legacy cruft and outdated implementations?
baq 8y ago
Genuine question: why not SCTP then?
- MaxBarraclough 8y ago
  Looking at this comment, it may be to do with ISPs refusing to route it properly: https://news.ycombinator.com/item?id=18429404 https://news.ycombinator.com/item?id=18429404
- jchb 8y ago
  I wondered the same - if we are going to have QUIC over UDP, why not SCTP over UDP (https://tools.ietf.org/html/rfc6951 https://tools.ietf.org/html/rfc6951)? I did a quick read on the subject and main argument for QUIC seems to be zero roundtrip session establishment - using TLS session resumption. SCTP uses a 4-way handshake. Also found this comment from 2015: https://news.ycombinator.com/item?id=9639824 https://news.ycombinator.com/item?id=9639824, and this ietf draft: https://tools.ietf.org/html/draft-joseph-quic-comparison-quic-sctp-00 https://tools.ietf.org/html/draft-joseph-quic-comparison-qui...
remcob 8y ago
> Wireless only appears to be low error rate because the physical layer had to cover up it's shortcomings otherwise TCP's performance became abysmal. It then seems that optimized protocols like QUIC could benefit from disabling this lower level error correction. Is this at all possible? Do the wireless physical protocols allow for such a thing? Do the operating systems offer it as a flag?
- kaetemi 8y ago
  The Wi-Fi extender I'm using allows disabling some option related to that. TCP becomes absolutely unusable.

ktpsns 8y ago

Nice review. Just a theoretical question: Wasn't IPsec supposed to do the encryption right in the IP layer? I wonder how this compares with the handshake roundtrip time needed (for IPsec, for TCP).

pas 8y ago
Well, the problem is complex. For security you need integrity, authenticity and anonimity/secrecy. Crypto of course is the way we implement all that, via keys and other kind of information theoretic tokens that somehow build upon a pre-shared secret. You need an anchor, a mutual trust foundation to build your secure channel upon. If you want to put security on/into IP, you suddenly need the whole key management thing, and if you want it to be automatic, you need to somehow cobble together the assignment, provisioning, allocation, publication, revocation of keys with IP addresses (or hostnames, domain names, and you just put DNS into IP). Eventually it means either you need manual key management (thus IPsec becames a hard to manage old rusty and poorly supported concept from an old era) or you just descended into the recursive pit of all hells of circular dependencies. Sure, it can be done, we can put keys into DNS, and we can use that, but then we're back to QUIC or DTLS basically.
rocqua 8y ago
The issue is that IP is generally handeled by the OS. This means that IPsec also needs to be handled by the OS. The thing is, how you set up (mutual) authentication is very much an application level thing. Do you want certs, an SSH key, passwords, hardware tokens, SIM based authentication, or something else? These aren't things the OS can decide, and they aren't so simple we could tell the OS what we want with a few flags.
dcbadacd 8y ago
Doesn't IPsec suffer from legacy cruft and outdated implementations?

baq 8y ago

Genuine question: why not SCTP then?

MaxBarraclough 8y ago
Looking at this comment, it may be to do with ISPs refusing to route it properly: https://news.ycombinator.com/item?id=18429404 https://news.ycombinator.com/item?id=18429404
jchb 8y ago
I wondered the same - if we are going to have QUIC over UDP, why not SCTP over UDP (https://tools.ietf.org/html/rfc6951 https://tools.ietf.org/html/rfc6951)? I did a quick read on the subject and main argument for QUIC seems to be zero roundtrip session establishment - using TLS session resumption. SCTP uses a 4-way handshake. Also found this comment from 2015: https://news.ycombinator.com/item?id=9639824 https://news.ycombinator.com/item?id=9639824, and this ietf draft: https://tools.ietf.org/html/draft-joseph-quic-comparison-quic-sctp-00 https://tools.ietf.org/html/draft-joseph-quic-comparison-qui...

remcob 8y ago

> Wireless only appears to be low error rate because the physical layer had to cover up it's shortcomings otherwise TCP's performance became abysmal. It then seems that optimized protocols like QUIC could benefit from disabling this lower level error correction. Is this at all possible? Do the wireless physical protocols allow for such a thing? Do the operating systems offer it as a flag?

kaetemi 8y ago
The Wi-Fi extender I'm using allows disabling some option related to that. TCP becomes absolutely unusable.