Chapter 11
References and Reading
On this page
Want to dig into a topic? Start with a question in the table below. You’ll find protocol specifications, moq.dev guides, and articles that expand on the chapters.
The rest of the chapter groups sources by topic and gives a reading route through MOQT draft-21. At the end, we list the research dates and what to check when updating the book.
Choose a source by the question
You don’t need to read the whole specification before trying the demo. Use the project guide to get it running, then look up protocol details as questions come up.
| You want to… | Start here | Keep in mind |
|---|---|---|
| Understand the transport promises | TCP specification and QUIC overview | TCP bytes, QUIC streams, and MoQ objects are different units |
| Explore implementations and demos | MoQ Alliance: Get started | Check each project’s supported protocol revision and media format |
| Start a local player | moq.dev quick start | Its implementation model is not identical to the pinned MOQT draft |
| Explain blocked audio | MDN autoplay guide | Browser policy can prevent playback after successful delivery |
| Inspect a QUIC trace visually | qvis | Your implementation must export a compatible trace |
| Resolve a request or stream rule | Draft-21 stream usage | Read the version used by your implementation |
The protocol baseline
This edition follows Media over QUIC Transport, draft-21, published September 8, 2026. The chapter links use that version. You can find newer revisions on the document status page and follow the wider work through the MoQ working group.
Read the object model before the wire-message tables. You’ll then know what the track, group, and object identifiers refer to when you encounter them in a message.
A route through the MOQT specification
Start with the question you are trying to answer. These links all refer to draft-21, so their terminology and section numbers belong to the same edition.
| Question | Where to read |
|---|---|
| What identifies a piece of content? | Objects (§2.1) and track naming (§2.4.1) |
| How do groups and subgroups organize it? | Subgroups (§2.2) and groups (§2.3) |
| How do I follow new content or request older objects? | Subscriptions (§3.1), fetch (§3.2), and joining an ongoing track (§3.5) |
| How are publications discovered? | Namespace discovery (§4) |
| Which work gets sent first, and when does it stop? | Priorities (§5.1) and delivery timeouts (§5.2) |
| What happens when peers connect? | Session establishment (§6.2), initialization (§6.3), and stream usage (§6.4) |
| What can a relay retain and forward? | Caching relays (§7.1) and relay object handling (§7.7) |
Read the explanatory sections first, then use control messages (§9) when you need field layouts. The words MUST, SHOULD, and MAY express requirement levels when a specification adopts BCP 14, which comprises RFC 2119 and RFC 8174. In particular, a recommendation is not a guarantee that every implementation will behave identically.
The transport underneath
RFC 9000 defines QUIC’s transport, including streams, flow control, and cancellation. RFC 9001 describes its use of TLS. RFC 9002 covers loss detection and congestion control.
RFC 9221 defines the QUIC DATAGRAM extension. Read it when deciding whether a small payload should be retried or replaced, and when checking message-size constraints.
QUIC multipath draft-21 describes using several network paths within one connection. It is a separate extension from MOQT. Its publication status was checked on September 23, 2026; it was in the RFC Editor queue.
Browser interfaces
The W3C WebTransport specification describes the browser API for streams and datagrams. Its presence does not remove the need for a protocol library above it.
The W3C WebCodecs specification describes low-level codec interfaces. It explains how to configure a decoder and release frames when you’re done with them. Playback scheduling still belongs to the player.
The WebRTC comparison
The early comparison uses the W3C WebRTC specification for the browser interface. The network behavior comes from IETF documents: RFC 8835, section 3.4 covers connection establishment with ICE and relay support, while section 3.5 identifies the media and data transports.
For media, WebRTC uses SRTP, the secure form of the Real-time Transport Protocol. Data channels use SCTP, the Stream Control Transmission Protocol, carried inside DTLS, Datagram Transport Layer Security. You do not need to learn these packet formats to understand the comparison; the distinction is that WebRTC specifies how these pieces fit together for real-time communication.
RFC 7667, section 3.7 explains how a media server can forward selected streams in a WebRTC conference.
Architectural background
Cloudflare’s MoQ: Refactoring the Internet’s real-time media stack (August 2025), by Mike English and Renan Dincer, explains why streaming systems combine different protocols, then describes MoQ’s layers and follows content through a relay network.
Its implementation discussion targets draft-07, and its message names and scheduling examples predate this book’s draft-21 baseline. Use the pinned draft for those details.
Finding an implementation
The MoQ Alliance’s Get started with MoQ guide collects browser demos, native media tools, and transport libraries in several languages. Use it to choose a starting point for your own system. Follow each project’s own documentation for setup and compatibility; the directory includes implementations targeting different draft revisions.
The moq.dev implementation
Start with moq.dev and the concepts guide. Then read the separate explanations of moq-lite, hang, and transport choices.
For experiments, use the setup and development documentation. For a reachable relay, read the production guide. These pages describe a particular project and can evolve independently of this book’s IETF baseline.
Read moq.dev with a specific question
These moq.dev articles and guides are useful companions to the chapters:
| Question | Material | Read alongside |
|---|---|---|
| Why separate delivery from the browser’s media stack? | Replacing WebRTC (2023) | The opening WebRTC comparison |
| How can subscribers share a limited uplink? | On a Boat (2026) | Relays and Distribution |
| Can subscriber choices reduce publisher work? | Concepts | Relays and Distribution |
| How does a conference use publications? | Conferencing | Publishing and Subscribing |
| Why can datagrams still arrive late? | Never* use Datagrams (2024) | Latency and Congestion |
| Which age limit does this implementation apply? | moq-lite subscriptions | Latency and Congestion |
| What is inside a delivered media payload? | hang | Media and the Browser |
| How do existing WebRTC tools connect? | RTC gateways | The detailed WebRTC comparison |
| What must agree between different stacks? | Standards support | Your First MoQ System |
| How do multiple relays find upstream content? | Relay clustering | Relays and Distribution |
The priority examples and backfill behavior in On a Boat describe the moq.dev stack. Its higher-number-first priorities differ from draft-21’s lower-number-first convention.
The older blog posts describe the software available at the time. This also applies to the 2024 Meetecho gateway demo linked in chapter 1. Use the current project guides for browser support and setup, and draft-21 for the protocol details explained here.
Editorial approach and limitations
The initial protocol review was on September 16, 2026. Technical explanations and setup links were checked again on September 22, 2026. Protocol details refer to draft-21, and examples using moq.dev features say so.
The latency numbers in this book are examples, not measurements. We haven’t tested every linked demo or browser. Try your chosen software on the devices and networks you plan to support.
Keeping an edition accurate
When updating the book, record the new research date and protocol revision together. Review terminology, setup, subscription behavior, timeout semantics, and the media-format boundary before changing the edition badge.
Keep examples identified as examples. If you add benchmarks, publish the workload, hardware, network conditions, implementation versions, and measurement points. If you add runnable SDK code, pin dependencies and verify it against the corresponding relay. State what you tested and what the results showed.