QUIC

What’s wrong with TCP?

• Latency and performance are limited by design
  • 2+ RTT from handshake to first data
  • Head-of-line blocking limits parallel transmission common in modern Web
• Deployment of extensions and new features in TCP is (very) difficult (e.g. ECN)
  • TCP’s wire image is open to observation and modification
  • Middle-boxes tend not to pass traffic they can’t understand / manipulate
  • Changing TCP generally happens in the kernel: you need to be the OS vendor
• Mobility considerations (multipath / connection migration) are particularly hard
  • though MP-TCP makes a valiant effort

QUIC Transport and Cryptographic Handshake

QUIC 0-RTT Session Resumption

Head of Line Blocking and Multi-streaming

• Stream Multiplexing: data divided into frames and sent on independent streams
• Problem: HTTP/2 stream multiplexing on single TCP byte-stream causes loss on one stream to block all streams
• QUIC stream multiplexing ensures that lost packets carrying data for an individual stream only impact that specific stream
  • → Data received on each stream is reassembled and delivered to the application independently

QUIC Connection Migration

• NAT rebinding more likely for UDP
  • QUIC identifies a connection based on the Server and Client Connection ID even when the source address or port changes.
  • Connection IDs are chosen by each side and exchanged encrypted after the handshake.
• Connection migration can also be used for mobility handovers
  • PATH challenge is sent for confirmation and avoid attacks

QUIC in the HTTP(s) Protocol Stack

Layering? It’s complicated

TLS uses QUIC. But! The QUIC handshake uses TLS. Drawing this as “layers” complicates the picture → the layering is temporal, not compositional. Better to consider QUIC from a system design perspective.

QUIC Handshake, simplified

Why is QUIC always encrypted?

• Encryption supports not only security/privacy but also deployability
  • QUIC is designed with the goal to minimize unintentional exposure
  • All QUIC packet information that are visible on path is authenticated by endpoints
  • Reduces risk of ossification by middle-boxes that make assumption and thereby impose restrictions on the wire image
• More dynamic evolution and innovation based on extensibility and user-space implementations
  • Minimal set of protocol invariants that must remain unchanged between versions
  • Versions can be used to change “everything” but the invariants
  • Transport parameter can (secretly) negotiate new features as well as frames or packet type
• Bold prediction: QUIC is the last change to “what packets look like” we’ll deploy at layer 4 this century
  • because the machinery underneath is now much easier to change

The Wire Image

From RFC 8546:

“The wire image of the set of protocols in use for a given communication is the view of that set of protocols as observed by an entity not participating in the communication. It is the sequence of packets sent by each participant in the communication, including the content of those packets and metadata about the observation itself: the time at which each packet is observed and the vantage point of the observer.”

More poetically:

The wire image is the shadow a protocol casts on the Internet, and everything you can know from that shadow.

Practically, QUIC is the first protocol with an engineered wire image at layer 4 (to expose nothing except connection ID and the bits of the TLS handshake that cannot be protected because of physics). The trend (esp. post-Snowden) is to make the wire image less observable.

Network Management Challenges with Encrypted Protocols

QUIC is designed, in large part, to defeat middle-boxes.

“Restoring the end-to-end principle by encryption, because it’s harder to ignore than strong language in an RFC”

A lot of middle-box behaviors are problematic.

• e.g. transparent data exfiltration detection is technically indistinguishable from state-scale citizen surveillance

Some of it (e.g. passive aggregate latency measurement) is less threatening.

Can we design support for reasonable use cases directly into the protocol?

Explicit Metadata Exposure: the QUIC Spin Bit

“Spin Bit” in the short header can be used to estimate the Round Trip Time (RTT) between the client and server:

• Client reflects the spin bit from the last received packet
• Server “spins” the bit state (0<->1)
• The network observes transitions and measures the time between two transitions
• Specified, but not widely deployed

Takeaways

• QUIC is not just “the web over UDP”; it’s a platform for evolving layer 4 for the next forty years.
• Encryption serves privacy, but it serves evolvability more.
• SOCK_STREAM / SOCK_DGRAM are 40 years old.

If you’re writing applications directly over the transport layer, expect more rapid API changes.

• Encrypted transport protocols reduce the effectiveness of in-network functionality
• Near term: explicit cooperation in enterprises, co-design in large content networks.
• Longer term: design of in-network cooperation directly into the wire image?

QUIC packets are carried in UDP datagrams. Why does QUIC rely on another transport protocol?

UDP is a well-established protocol that is widely supported by the Internet. A the same time, it adds fairly minimal overhead to packets. By using UDP, QUIC can avoid middlebox interference. Middleboxes are often configured to drop packets with unknown protocol numbers. By using UDP, QUIC can avoid this problem without changes to the Internet infrastructure while avoiding unnecessary overhead.

If another transport protocol is needed, why not use TCP?

TCP adds too much overhead and would interfere with the design goals of QUIC. For example, TCP requires a 3- way handshake to set up a connection, which adds significant latency. QUIC uses an improved, faster, handshake, but if it were to run on top of TCP, these benefits would be lost. In addition, middleboxes often interfere with TCP connections or inspect them deeply and QUIC would need to ensure to update all TCP headers properly to avoid problems.

In essence, QUIC aims to replace TCP, and thus running it on top of TCP would defeat the purpose.

In TCP and UDP, connections are identified by the 5-tuple of (source IP, destination IP, source port, destination port, protocol). QUIC uses an explicit connection ID instead. Explain at least one advantage of this approach

In TCP, changing either the IP or port means that a new connection needs to be set up. This is problematic when switching from one network to another, e.g. from WiFi to Cellular. With QUIC, we can continue to use the same connection, even if the IP address changes.