RFC 9000
Overview
▶QUIC is a general-purpose transport protocol built on UDP that provides features previously split across TCP, TLS, and HTTP/2. It offers encrypted, authenticated, multiplexed transport with per-stream flow control and loss recovery, reducing connection setup latency to 0-1 RTT.
For 3GPP, QUIC is significant as the underlying transport for HTTP/3 and as a potential future alternative to SCTP+IPsec or TCP+TLS for control plane signaling.
Connection Establishment
▶QUIC combines the transport and cryptographic handshakes, achieving 1-RTT for initial connections and 0-RTT for resumed connections. The TLS 1.3 handshake is carried within QUIC CRYPTO frames.
Client Server │ │ │──Initial [CRYPTO: ClientHello]────►│ 1-RTT │ │ Handshake │◄─Initial [CRYPTO: ServerHello]─────│ │◄─Handshake [CRYPTO: EncExt, │ │ Cert, CertVerify, Finished]──────│ │ │ │──Handshake [CRYPTO: Finished]─────►│ │──1-RTT [Application Data]─────────►│ │◄─1-RTT [Application Data]──────────│ │ │ │ === 0-RTT Resumption === │ │──Initial + 0-RTT [Early Data]─────►│ │◄─Initial + Handshake──────────────│
Stream Multiplexing
▶QUIC streams are lightweight, independently flow-controlled communication channels within a connection. Unlike TCP, packet loss on one stream does not block other streams.
| Stream Type | ID Pattern | Initiator | Direction |
|---|---|---|---|
| Client bidirectional | 0, 4, 8, ... | Client | Both |
| Server bidirectional | 1, 5, 9, ... | Server | Both |
| Client unidirectional | 2, 6, 10, ... | Client | Client→Server |
| Server unidirectional | 3, 7, 11, ... | Server | Server→Client |
Connection Migration
▶QUIC uses Connection IDs rather than the 4-tuple (src IP, src port, dst IP, dst port) to identify connections. This allows connections to survive IP address changes — critical for mobile devices switching between Wi-Fi and cellular.
- Connection ID: Variable-length identifier chosen by each endpoint, included in every packet header
- Path validation: PATH_CHALLENGE/PATH_RESPONSE frames verify the new path before migrating
- NAT rebinding: QUIC handles NAT rebinding gracefully without connection interruption
- Preferred address: Server can advertise a preferred address for the client to migrate to
Loss Detection & Congestion Control
▶QUIC separates loss detection from congestion control, allowing pluggable congestion control algorithms. Loss detection uses packet number spaces per encryption level and ACK frames with explicit acknowledgment ranges.
- No retransmission ambiguity: Each QUIC packet has a unique, monotonically increasing packet number
- ACK ranges: ACK frames report multiple received ranges, providing better loss information than TCP SACK
- PTO (Probe Timeout): Replaces TCP RTO with more aggressive loss detection
Security Properties
▶QUIC mandates TLS 1.3 encryption for all application data. Even most header fields are encrypted after the handshake. Connection IDs and packet numbers receive header protection to prevent linkability.
3GPP Relevance
▶- HTTP/3 foundation: QUIC is the mandatory transport for HTTP/3, being evaluated for future SBI transport
- Middlebox challenges: QUIC's pervasive encryption may conflict with 3GPP network functions that inspect transport headers (DPI, QoS enforcement)
- Connection migration: Natural fit for mobile networks where UEs frequently change IP addresses
- UDP-based: May require firewall/policy updates in operator networks that restrict UDP traffic
- Alternative to SCTP: QUIC's multi-streaming could eventually replace SCTP for some 3GPP signaling protocols