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.