QUIC and WebTransport

A short introduction to TCP/IP

If you are already familiar with TCP/IP, TCP, and UDP, skip ahead to Why one ordered stream can hurt.

When a student connects to the lecture, their packets usually pass through several networks. A router forwards each packet toward its destination. IP, the Internet Protocol, provides the addresses and delivery rules that make this possible. An IP address identifies a network interface, such as the one the student is using to connect.

A packet contains a header, which describes how to handle it, and a payload, the data it carries. Layers nest: the payload of an IP packet can contain a UDP datagram, whose payload contains QUIC packets. The receiving software unwraps those layers.

An address gets traffic to a host. A port helps the host direct that traffic to the appropriate transport endpoint. A server may listen for QUIC on UDP port 443 while serving TCP connections on TCP port 443: the transport protocol is part of the distinction. DNS translates a name such as relay.example into addresses the client can try. The client then uses an address to try connecting to the relay.

IP delivery is best effort. Packets can be lost, duplicated, reordered, or delayed. A full queue in a router is one reason for loss. Each link has a maximum transmission unit, or MTU: its largest IP packet size. The path MTU is the smallest link MTU along the route. Sending one large application message does not make the network carry it as one arbitrarily large packet. See the IPv6 specification for packet-size constraints.

Why one ordered stream can hurt

Imagine sending camera video and captions through a single ordered byte stream. A packet containing video bytes goes missing. Later caption bytes arrive, but the receiver cannot expose them through that stream until the missing earlier bytes are recovered. This is head-of-line blocking.

For a file, waiting for the missing bytes makes sense: we want the whole file in order. For our lecture, the captions may still be useful while the camera video catches up. Putting both on one stream makes them wait together.

Independent streams

QUIC provides multiple reliable, ordered byte streams within one connection. Loss affecting one stream does not impose that stream’s delivery order on another. A stream still has its own ordering: later bytes in that same stream wait for missing earlier bytes.

A byte stream has no built-in message boundaries. If the publisher writes two objects, the receiver cannot assume two reads will return those two objects. MOQT supplies framing so the receiver can find where each object starts and ends. RFC 9000 §2.2 explains this distinction.

All those streams still share the connection’s bandwidth. If the network gets congested, they have less capacity to share.

QUIC applies flow-control limits to both individual streams and their combined data. A receiver that stops consuming one stream can therefore hold up other streams if the connection-wide limit is exhausted. See RFC 9000 §4.1 and RFC 9002 §7.

MoQ uses these streams to separate content that can be useful on its own. In the next chapter, we’ll see how publishers group that content.

What a lost packet holds up

Suppose camera bytes use stream A and captions use stream B. The offsets below are illustrative byte positions, not MoQ object IDs.

Here, the captions can continue while the camera stream waits. If packet 11 had carried bytes from both streams, both would have a gap to fill. The sender may also slow down the whole connection in response to the loss.

Reliability can have an ending

Sometimes the viewer no longer needs the bytes we’re trying to recover. QUIC lets the sender reset a stream, and lets the receiver ask it to stop. We can use this to give up on old video and spend the connection’s capacity on a newer picture.

Suppose an old camera group is still incomplete when the publisher has a new group with everything needed to start decoding again. We could keep repairing the old group, or cancel it and move on. The application chooses when catching up matters more than seeing every picture.

Where datagrams fit

QUIC’s DATAGRAM extension provides messages that are not retransmitted by QUIC when lost. They share the connection’s security and congestion control. They do not promise arrival or ordering, and their size is constrained by the path and negotiated limits.

QUIC does not split a DATAGRAM frame across packets. If an application’s message is too large, it must choose another mapping or define its own fragmentation and reassembly. That also means deciding what to do when one fragment is missing. See RFC 9221 §5.

That can suit a small, replaceable sensor update. It is less convenient for a large video frame that cannot fit in a datagram. A protocol must define how content maps onto these tools; “uses UDP” alone says very little about reliability.

A QUIC datagram is also different from a UDP packet. QUIC adds its own framing, encryption, and congestion behavior on top of UDP.

Migration and multipath

Suppose a publisher has both cellular and satellite access. It could switch to cellular when satellite service becomes poor, or use both links at once. These are different transport capabilities.

Connection migration lets a QUIC connection move to a new network path while keeping the connection alive, subject to validation and the peer’s migration settings. Base QUIC sends application data on one path at a time. Migration can preserve a session when a device changes networks, though detecting and validating the new path can still interrupt delivery. See RFC 9000 §9.

The multipath extension allows one QUIC connection to use several paths simultaneously. Both endpoints must support and negotiate it. This is separate from the MOQT specification; we refer here to QUIC multipath draft-21, which is still awaiting RFC publication at the time of writing.

Having two links also creates a scheduling decision: which data should use which path? The extension leaves that policy to implementations. A path with spare capacity may have too much delay for an urgent frame. Sending successive parts of a stream over paths with different delays can also make later bytes wait for earlier ones. More capacity alone doesn’t ensure lower playback latency.

An application can instead open separate MoQ connections and decide which one carries each subscription. Those are separate sessions, rather than multiple paths inside one QUIC connection. The moq.dev article On a Boat discusses both approaches. Check the chosen implementation’s support before relying on either in a deployment.

Security belongs to the connection

Running over UDP does not mean sending plaintext. QUIC uses Transport Layer Security (TLS) 1.3, the security protocol also used by HTTPS, to authenticate the server and establish keys that protect packets. With a relay in the middle, the publisher-to-relay and relay-to-viewer connections have separate protection. Hiding the content from the relay itself requires another layer, which we will discuss in the security chapter. See RFC 9001 §4.

WebTransport is the browser doorway

Browser JavaScript does not generally get a raw QUIC socket. WebTransport exposes streams and datagrams to web applications. For the MOQT mapping described in this edition, the browser uses WebTransport over HTTP/3; native software can use QUIC directly.

HTTP/3 is HTTP mapped onto QUIC. Using WebTransport over HTTP/3 does not mean making a new HTTP request for every media object. Once established, the WebTransport session exposes streams and datagrams for the application. See RFC 9114 and the WebTransport API specification.

WebTransport transports application bytes. It does not know that those bytes represent a subscription, an Opus packet, or a camera frame. A MoQ implementation still has to implement the protocol above it.

A fallback changes the tradeoffs

The moq.dev stack documents a WebSocket fallback. This can help reach networks where the preferred transport is unavailable. It does not preserve all of QUIC’s independent-stream behavior: TCP provides one reliable, ordered byte stream. When the fallback carries all its work over that stream, missing bytes can hold up later bytes belonging to unrelated work.

When testing a player, record which transport it actually used. Otherwise, you can spend a long time explaining “QUIC performance” while measuring a different path.

When the player won’t start, check the connection first, then the MoQ session, then the media. A client might reach the server but speak the wrong protocol version, or receive content its decoder can’t use.

Reading a QUIC packet

The rest of this chapter looks inside the transport. You can continue to Tracks, Groups and Objects now and return here when you want to read packet fields.

A QUIC frame is a transport instruction inside a QUIC packet. It is unrelated to a video frame, which represents a picture. A packet can carry several QUIC frames, including stream data from different streams.

For the full frame layouts, see RFC 9000 §19. The DATAGRAM frame is defined in RFC 9221.

Three numbers answer different questions: a packet number identifies a transmission within its packet-number space; a stream ID identifies a stream; a byte offset locates data within that stream. When lost stream data is sent again, it travels in a new packet, with a new packet number. It retains its position in the stream. See RFC 9000 §13.3 for how QUIC retransmits information.

flowchart TD
  accTitle: From a MoQ object to network packets
  accDescr: A MoQ object is framed into stream bytes. Parts of the stream are carried in QUIC STREAM frames, which travel inside QUIC packets, UDP datagrams, and IP packets. These boundaries need not align.
  O["MoQ object: metadata and payload"] --> B["Bytes on a QUIC stream"]
  B --> F["STREAM frames: stream ID, offset, bytes"]
  F --> Q["QUIC packets: frames and packet protection"]
  Q --> U["UDP datagrams"]
  U --> I["IP packets across the network"]

This diagram shows the direct-QUIC stream mapping. One object can span many packets; one packet can contain bytes from more than one object. The receiver reconstructs stream bytes before the MoQ parser reconstructs objects. WebTransport adds its own session and stream framing above QUIC.

sequenceDiagram
    accTitle: A fresh QUIC connection using TLS 1.3
    accDescr: The client sends ClientHello in Initial packets. The server sends ServerHello in Initial packets and its certificate and Finished in Handshake packets. The client verifies the server and sends Finished. The server confirms the handshake with HANDSHAKE_DONE.
    participant C as Client
    participant S as Server
    C->>S: Initial: CRYPTO carrying ClientHello
    S->>C: Initial: CRYPTO carrying ServerHello
    S->>C: Handshake: encrypted extensions, certificate, CertificateVerify, Finished
    Note over C: Verify server identity and handshake
    C->>S: Handshake: CRYPTO carrying Finished
    Note over S: Verify client Finished
    S->>C: 1-RTT: HANDSHAKE_DONE
    C->>S: 1-RTT: application frames
    S->>C: 1-RTT: application frames