4 ms·

Why are there two meanings of QUIC in the first place?

by pvorb 6y ago

tialaramex 6y ago
Some years back, Google had two experimental pieces of work to try to speed up HTTP named QUIC and SPDY (as in "Quick" and "Speedy"). The output from the experiments was new standardization efforts at the IETF. Google's SPDY, which was a binary HTTP protocol over TLS, eventually resulted in HTTP/2 which there's a fair chance you use today. The other idea, QUIC, is a much bigger lift. It replaces not just the HTTP protocol and TLS but the whole stack, even TCP. At the IETF this work was split into two pieces, the IETF's QUIC is just the TCP replacement, an encrypted connection-oriented reliable protocol. So the HTTP part of the problem is being standardised as HTTP/3 Google's QUIC "gQUiC" will be obsolete once the standardized protocol is finished. Right now a Chrome talking to e.g. GMail uses gQUIC, once the standards work is firmed up it'll speak HTTP/3 and then maybe a year later Google's sites will discontinue gQUIC because it's just maintenance effort with no residual value.
- m3at 6y ago
  Good and concise explanation thank you
- CppCoder 6y ago
  In here and in the article it sound as if QUIC or HTTP3 use or build a new Internet Protocol, while it was my understanding it _simply_ uses UDP to create a better version of TCP. Of course an all new IP would be great, but the issue is it would take very long for all the soft and hardware to support it and UDP is simply there. I would prefer for a new HTTP to go an all new way, leaving behind UDP and TCP and build something new. Then support fallback over HTTP1/2 until everything else caught up.
  - M2Ys4U 6y ago
    I don't think it's unreasonable to state that we will never deploy a new IP protocol again. At least not one that works over the general Internet - controlled intra-organisation networks might possibly be able to do so, but very rarely. There are too many broken machines on the Internet that assume all IP traffic is one of TCP, UDP and ICMP. And far too many are configured to screw up ICMP too. So new protocols MUST use TCP or UDP as their base layer instead of raw IP. So yes, QUIC uses UDP, but that should be considered an implementation detail. A hack for the lack of IP support on the Internet. HTTP/3 uses QUIC like HTTP/1 and HTTP/2 use TCP + TLS, but QUIC is not limited to use by HTTP/3. QUIC's development has been, basically, paused while HTTP/3 is finalised and then the IETF will pick up where it left off and work out how other higher-layer protocols will work using QUIC as the transport layer.
  - jbjohns 6y ago
    Well, I think UDP is about as minimal as can be when using IP. So it makes sense to use to design a potential TCP replacement. Having said that, I wish we could replace the "port" concept. With the size of address space IPV6 allows, 16 bits for ports is looking a bit small.
    - tialaramex 6y ago
      For a trivial connection-oriented protocol the ports are part of a 4-tuple (my-address, my-port, your-address, your-port) so the 16-bit port isn't a big problem there. It doesn't matter at all whether this port is being used for something else in regards to any other combination of remote address and port since that's not a match. And for fancier protocols it doesn't matter anyway because they have their own concept of a connection identifier. WireGuard for example doesn't care at all, packets arrive and either they're authenticated or they aren't, it silently discards all packets that aren't authenticated, QUIC optionally has a connection ID that can survive changing the 4-tuple as far as I remember. If you wish you did have more ports, the IPv6 address space makes it pretty cheap to just acquire more addresses on your network and use those, but I do not sense much appetite because people don't feel like they're short of ports. You do see people spinning up more addresses to not need SNI or similar. If you have sixty virtual machines on one hardware box, having sixty IPv6 addresses, one per VM, means now the packets for VM #4 and VM #18 are separated on the wire, which might be convenient but that doesn't feel like it's due to running out of ports, it's just more convenient.

Why are there two meanings of QUIC in the first place?

by pvorb 6y ago

Why are there two meanings of QUIC in the first place?

Some years back, Google had two experimental pieces of work to try to speed up HTTP named QUIC and SPDY (as in "Quick" and "Speedy"). The output from the experiments was new standardization efforts at the IETF. Google's SPDY, which was a binary HTTP protocol over TLS, eventually resulted in HTTP/2 which there's a fair chance you use today. The other idea, QUIC, is a much bigger lift. It replaces not just the HTTP protocol and TLS but the whole stack, even TCP. At the IETF this work was split into two pieces, the IETF's QUIC is just the TCP replacement, an encrypted connection-oriented reliable protocol. So the HTTP part of the problem is being standardised as HTTP/3 Google's QUIC "gQUiC" will be obsolete once the standardized protocol is finished. Right now a Chrome talking to e.g. GMail uses gQUIC, once the standards work is firmed up it'll speak HTTP/3 and then maybe a year later Google's sites will discontinue gQUIC because it's just maintenance effort with no residual value.

m3at 6y ago
Good and concise explanation thank you
CppCoder 6y ago
In here and in the article it sound as if QUIC or HTTP3 use or build a new Internet Protocol, while it was my understanding it _simply_ uses UDP to create a better version of TCP. Of course an all new IP would be great, but the issue is it would take very long for all the soft and hardware to support it and UDP is simply there. I would prefer for a new HTTP to go an all new way, leaving behind UDP and TCP and build something new. Then support fallback over HTTP1/2 until everything else caught up.
- M2Ys4U 6y ago
  I don't think it's unreasonable to state that we will never deploy a new IP protocol again. At least not one that works over the general Internet - controlled intra-organisation networks might possibly be able to do so, but very rarely. There are too many broken machines on the Internet that assume all IP traffic is one of TCP, UDP and ICMP. And far too many are configured to screw up ICMP too. So new protocols MUST use TCP or UDP as their base layer instead of raw IP. So yes, QUIC uses UDP, but that should be considered an implementation detail. A hack for the lack of IP support on the Internet. HTTP/3 uses QUIC like HTTP/1 and HTTP/2 use TCP + TLS, but QUIC is not limited to use by HTTP/3. QUIC's development has been, basically, paused while HTTP/3 is finalised and then the IETF will pick up where it left off and work out how other higher-layer protocols will work using QUIC as the transport layer.
- jbjohns 6y ago
  Well, I think UDP is about as minimal as can be when using IP. So it makes sense to use to design a potential TCP replacement. Having said that, I wish we could replace the "port" concept. With the size of address space IPV6 allows, 16 bits for ports is looking a bit small.
  - tialaramex 6y ago
    For a trivial connection-oriented protocol the ports are part of a 4-tuple (my-address, my-port, your-address, your-port) so the 16-bit port isn't a big problem there. It doesn't matter at all whether this port is being used for something else in regards to any other combination of remote address and port since that's not a match. And for fancier protocols it doesn't matter anyway because they have their own concept of a connection identifier. WireGuard for example doesn't care at all, packets arrive and either they're authenticated or they aren't, it silently discards all packets that aren't authenticated, QUIC optionally has a connection ID that can survive changing the 4-tuple as far as I remember. If you wish you did have more ports, the IPv6 address space makes it pretty cheap to just acquire more addresses on your network and use those, but I do not sense much appetite because people don't feel like they're short of ports. You do see people spinning up more addresses to not need SNI or similar. If you have sixty virtual machines on one hardware box, having sixty IPv6 addresses, one per VM, means now the packets for VM #4 and VM #18 are separated on the wire, which might be convenient but that doesn't feel like it's due to running out of ports, it's just more convenient.