An FAQ on QUIC

The SNIA Networking Storage Forum‘s recent live webcast “QUIC – Will It Replace TCP/IP” was a fascinating presentation that was both highly-rated and well-attended. Lars Eggert, technical director of networking at NetApp and current chair of the IETF working group that is delivering this new Internet protocol, explained the history of the protocol, how it is being adopted today, and what the future of QUIC deployment is likely to be. The session generated numerous questions. Here are answers to both the ones Lars had time to answer during the live event as well as those we didn’t get to.

Q. Is QUIC appropriate/targeted to non-HTTP uses like NFS, SMB, ISCSI, etc.?

A. Originally, when Google kicked off QUIC, the web was the big customer for this protocol. This is still the case at the moment, the entire protocol design is very much driven by carrying web traffic better than TLS over TCP can. However, there’s a strong interest from a bunch of organizations to run other applications and workloads on top of QUIC, for example, Microsoft has recently been talking about shipping SMB over QUIC. I fully expect we’re going to see other protocols that want to run on top of QUIC in the near future.

Q. Have you mentioned which browsers (or other software) support QUIC?

A. At the moment, Chrome, which supports Google QUIC, although that is quickly turning into IETF QUIC with every new Chrome release. Firefox is implementing IETF QUIC and I think is shipping it as part of their nightly builds. Everybody else is Chrome- or Chromium-based, so Microsoft Edge, Safari, etc. will all get it from Chrome and can then enable it at their leisure.

Q. How robust is QUIC to packets loss?

A. Currently, QUIC uses TCP congestion control algorithms, so it’s very comparable to TCP. And like TCP, it doesn’t do forward error correction, which was something that Google QUIC did initially.

Q. Can you explain the term “ossification”?

A. Basically, it means that that the network makes – often too narrow – assumptions about what “valid” traffic for a given protocol should look like, based on past and current traffic patterns. This limits evolvability of a protocol, i.e., the network “ossifies” that protocol. For example, TCP has only had a small set of TCP options that had been defined, and various middleboxes in the network therefore dropped TCP packets with options they didn’t recognize from the past. Some of these middleboxes might eventually be updated, but enough won’t be that TCP options – TCP’s main extension mechanism – has become much less useful than envisioned. The situation is worse when trying to redefine meaning for header bits that were originally specified as reserved. What we have learned from this is that a protocol must carefully limit the amount of plain text bits it exposes to the network if it wants to retain long-term evolvability, which is a key goal for QUIC.

Q. What does the acronym QUIC stand for?

A. It’s actually not an acronym anymore., When Jim Roskind came up with Google QUIC, it originally expanded to “Quick UDP Internet Connections,” but everyone since decided that QUIC is simply the name of the protocol and not an acronym anymore.

Q. Given that QUIC is still based on IP and UDP, wouldn’t the middlebox issues remain?

A. No, it wouldn’t, at least not to the degree it does for TCP. UDP is a very minimal protocol, and while middleboxes can drop UDP entirely, which would break QUIC, everything else they might do (rewrite IP addresses and port numbers for NAT), QUIC can handle. One caveat is that UDP was traditionally mostly used for DNS, so many middleboxes use shorter binding lifetimes for UDP flows, but QUIC can deal with that as well. Specifically, there are some measurements that UDP works on about 95% of all paths, and there’s some anecdotal evidence that where it doesn’t work it’s typically because it’s enterprise networks that just block UDP completely.

Q. Do you expect a push-back from network vendors or governments when they realize that they can no longer do deep packet inspection and modification?

A. Yes, we do, and we’ve seen it heavily already. So, the question is who can push harder. There’s a big group of US banks that showed up in the IETF to complain about TLS 1.3 enabling forward secrecy because, if I recall correctly, a whole bunch of their compliance checks were based around taking traces of TLS 1.1 and 1.2 and storing them then decrypting them later, which TLS 1.3 makes impossible. They were not happy, but it’s the right thing to do for the web.

Q. Can you explain where the latency/performance benefit comes from? Is it because UDP replaces TCP and a lightweight implementation is possible?

A. A lot of it comes from a faster handshake. You have these TLS session tickets that let you basically send your “GET” with the first handshake packet to the server and have the server return data within its first packets. That’s where a lot of the latency benefits come from. In terms of bulk throughput there’s actually not a whole lot of benefit because we’re just using TCP congestion control. So, if you want to push a lot of bytes performance is going to be more or less the same between QUIC and TCP. After a few hundred KB or so it doesn’t really matter anymore what you’re using. For very fast paths, e.g., in datacenters, until we see some NIC support for crypto offload and other QUIC operations, QUIC is not going to be able to compete with TCP when it comes to high-speed bulk data. QUIC adds another AES operation in addition to basic TLS which makes it hard to offload to current-generation NICs. This will change and I think this bottleneck will disappear, but at the moment QUIC is not your protocol if you want to do datacenter bulk data.

Q. Do you have any measurements comparing the energy/battery use of current QUIC implementations compared to the traditional stack for mobile platforms?

A. Not at the moment. Sorry.

Q. How do you guarantee reliability with QUIC? Wouldn’t we have to borrow from TCP here as well?

A. We’re borrowing exactly the same concepts that TCP uses for its reliability mechanisms. UDP, on the other hand, is built on the idea of “sending a packet and forgetting about it.” A message sent via UDP will be delivered to the recipient (not guaranteed, with some probability of success). QUIC detects and recovers from UDP loss.

Q. Understand and agree on not having protocol in kernel, and ability to rapidly evolve (QUIC update in application rollout). However, what about the security implications of this? It seems like it creates massive holes in the security paradigm

A. It depends. If you trust your kernel sure, but I think actually a lot of applications are happy to do that in the app and only trust the kernel with already encrypted data. So, it is changing the paradigm a little bit. But with TLS, until very recently, it already happened at the application layer. We’ve only recently seen TLS NIC support.

Q. Your layer diagram shows QUIC taking over some HTTP functions and/or changing the SAP between OSI layer 4 and layer 7. Will this be a problem to having other protocols such as SNMP, FTP, etc. adopting QUIC?

A. Yes, I think that might be an artifact in the diagram. This is something that changed in the working group. In the beginning, when we started standardizing QUIC, we talked about an application and QUIC, the application was the thing on top of HTTP and QUIC was providing HTTP semantics and a transport protocol. That view has now somewhat evolved. Now when we’re talking about an application and QUIC, HTTP is the application and QUIC the transport protocol for it – and there will be other applications on top of QUIC, so that diagram might have been a little bit stale or maybe I have not updated it in a while, but the model very much is that QUIC at this time intends to be a transport protocol that is general purpose although with a bunch of features that are inspired by features that the web needs, but that are hopefully useful for other protocols. So, there should be a relatively clean interface that other applications can layer on top of.

Q. Does QUIC provides a Forward Error Correction (FEC) option?

A. Not at the moment. Google QUIC did initially, but reported mixed results and therefore the current IETF QUIC does not use FEC. However, there’s now a better understanding of a different flavor of FEC that might actually be interesting. We’ve talked to some people that want to revisit that decision and maybe add FEC it back.

Q. How would QUIC apply for non-HTTP protocols? In particular, data-centric protocols like SMB, NFS or iSCSI?

A. If you can run over TCP, you can run over QUIC, because QUIC sort of degrades into TCP in a sense if you only use one stream, and then you use that one stream on one connection that you’re basically having TCP-like transfer protocols. If you can run on top of that, you can run on top of QUIC without changing your application protocol too much. If you want to take full advantage of QUIC, specifically the multiple parallel streams and prioritization and all that, you will need to change your application protocol. If you have an application protocol that can run on top of SCTP, that binding is going to be very similar to a QUIC binding.

Q. Do / Will corporate middleboxes block QUIC to preserve inspection abilities?

A. All the things CSOs rely on to protect enterprise networks become harder to use because they can’t see the traffic, let alone filter or block traffic. These changes pose challenges for regulated industries such as financial services where the organizations have to archive all incoming and outgoing communications for compliance purposes.

Q. Do standard HTTP engines/servers like Nginx support QUIC?

A. As of May 2019, Nginx announced starting the development for support of QUIC. Many other servers such as h2o, lightspeed, etc. will also start supporting QUIC.

Q. Do typical QUIC implementations support POSIX socket APIs yet? If not, is there a plan to incorporate POSIX API wrappers over QUIC APIs that may allow more POSIX compliant?

A. No QUIC stack that I know of has a POSIX abstraction API. Some have APIs that are somewhat inspired by POSIX, but not to a degree where you could simply link against a QUIC stack. One key reason is that if you want to maximize performance and minimize latencies, the POSIX abstractions actually get in your way and make it more difficult. Applications that want to optimize performance need to tie in very deeply and directly with their transport stacks.

Q. Does QUIC have a better future than Fibre Channel over Ethernet (FCoE) has had till now?

A. Those are two protocols with vastly different scopes of applicability. QUIC’s future certainly seems very bright at least in the web ecosystem – pretty much all players plan on migrating to HTTP/3 on top of QUIC.

Q. How does QUIC affect current hardware deployments?

A. I don’t see QUIC necessitating changes here.

Q. How is SNI handled for web hosting of multiple domains on one server?

A. QUIC uses the SNI in exactly the same way as TLS.

Q. How does QUIC perform compared to TCP for a locally scoped IoT network (or say ad hoc network made of mobile devices)?

A. I’m not aware of a comparison of QUIC and TCP/TLS traffic on IoT networks. I have deployed my QUIC stack on two embedded platforms (RIOT-OS and Particle DeviceOS), so it is feasible to deploy QUIC on at least the higher-end of embedded boards, but I have not had time to do a full performance analysis. (See https://eggert.org/papers/2020-ndss-quic-iot.pdf for what I measured.)

Q. Do end devices need to be adapted to QUIC, if yes, how?

A. No. If the system allows applications to send and receive UDP traffic, QUIC can be deployed on them.

Q. Is it possible to implement QUIC in an IoT environment considering the CPU and memory cost of QUIC and its code size?

A. Yes. I have a proof-of-concept of my QUIC stack on two IoT systems, where a simple client app, QUIC and TLS together use about 64KB of flash and maybe 10-20 KB of RAM. See https://eggert.org/papers/2020-ndss-quic-iot.pdf.

Q. Is the QUIC API exposed to applications (i.e., other than HTTP) a message-based (e.g., like UDP) or byte stream (e.g., like TCP)?

A. There really is no common QUIC API that multiple different stacks would all implement. Each stack defines its own API, which is tailored to the needs of the specific applications it intends to support.

Q. My understanding is that TCP is ‘consistent’ across all implementations, but I see individual versions from each vendor involved currently (and interop being tested, etc.) – why are individual/custom variants required?

A. All vendors are implementing the current version of IETF QUIC. QUIC makes it very easy to negotiate use of a private or proprietary variant during the standard handshake, and some vendors may eventually use that to migrate away from standard QUIC. We’re certainly testing that capability during interop, but I’m not aware of anyone planning on shipping proprietary versions at the moment.

Q. SMB over QUIC comment: I can’t speak for Microsoft, of course, but I have been through some of their presentations on SMB over QUIC. One feature of using QUIC is connection stability, particularly over WiFi. The QUIC connection can survive a transfer from one Access Point to another on different routers, for example.

A. Yes, QUIC uses connection identifiers instead of IP addresses and ports to identify connections, so QUIC connections can survive changes to those, such as when access networks are changed.

Q. So QUIC is basically utilizing UDP in a new way?

A. Not really. QUIC is using UDP to send packets just as any other application would.

Q. To be clearer on my security concerns. I’m thinking of malicious apps/actors doing /hiding data exfiltration inside the new QUIC environment/protocol/etc. ie the very problems with our legacy environment, also provides the ability to inspect and prevent inappropriate data transmission. How to do this with QUIC?

A. You need to have control of the endpoint and make the QUIC stack export TLS keying material.

Q. UDP + CC + TLS + HTTP = QUIC. What does “CC” stand for?

A. Congestion control.