Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

Introduction — IETF 126 Starts in Vienna Tomorrow
What Is MOQT — Pushing Pub/Sub Down to the Transport Layer
The Spec Today — the Wire Changes Every Two Months
Reality Check 1 — the Largest Relay Is Stuck at draft-07
Reality Check 2 — the First Proposer's Fork, moq-lite
So, Is It Time to Drop WebRTC Yet — No
Verdict — When to Look, When to Wait
Closing
References

Introduction — IETF 126 Starts in Vienna Tomorrow

Starting tomorrow (July 18, 2026), IETF 126 opens in Vienna, Austria. Looking at the agenda, the Media over QUIC (MoQ) working group has booked sessions on July 20 (Mon), 23 (Thu), and 24 (Fri) — three times in one week. And eleven days earlier, on July 6, the core document, draft-ietf-moq-transport, was updated to its nineteenth revision (-19). It's a 149-page document.

While standardization races ahead on one side, deployment reality sits in an odd place. The largest MoQ relay anyone can connect to on today's internet — the one Cloudflare turned on in August 2025 — is still pinned to a draft-07 subset. And Luke Curley, the first author of this protocol's -00 revision, is now running a separate fork called moq-lite.

How far the spec has come, where deployment actually stands, and what that gap says — I checked all three against primary sources (datatracker metadata, the draft text itself, vendor documentation) and laid it out below.

What Is MOQT — Pushing Pub/Sub Down to the Transport Layer

MOQT (Media over QUIC Transport) is a publish/subscribe protocol running on top of QUIC and WebTransport. To carry over the -19 abstract's own wording, it leverages QUIC's streams, datagrams, prioritization, and partial reliability to work both point-to-point and through intermediate relays, aiming for scalable, low-latency delivery. There's one more interesting sentence — "Despite the name, MOQT is media agnostic and can be used for a wide range of use cases." That's notable because the working group charter (revised April 2025) actually scopes the group as a media-delivery solution for live streaming, gaming, and media conferencing — meaning the document itself has grown more ambitious than its own charter.

The data model is layered. A Track contains Groups, a Group contains Objects, and within a Group, Objects can be bundled into Subgroups. The example the spec gives shows the design intent well — when sending high/low-resolution video with a codec that has temporal scalability, you split tracks by resolution (so receivers can pick based on bandwidth), map independently decodable picture sequences to Groups (random-access points = join points), map temporal layers to Subgroups (so when bandwidth runs short, the priority mechanism favors lower layers), and send one frame as one Object.

There are three modes of operation. SUBSCRIBE receives objects arriving from now on (live viewing), FETCH requests a past range (rewind, VOD-style access), and PUBLISH is a push model where the publisher pushes without waiting for a subscription request. This structure lets relays do fan-out and caching without understanding the media content — without knowing the codec, the container, or (by design) even end-to-end encryption keys. The end-to-end key establishment mechanism itself is something the charter explicitly puts out of scope.

This is where the design's promise ends. One architecture combining WebRTC's low-latency interactivity with HLS/DASH's CDN scalability — this is even the phrasing Cloudflare's own announcement uses. The problem starts from here.

The Spec Today — the Wire Changes Every Two Months

Looking at the recent revision cadence from datatracker submission records:

Revision	Submission date
draft-16	2026-01-13
draft-17	2026-03-02
draft-18	2026-05-12
draft-19	2026-07-06

Roughly once every two months, timed to IETF meetings. What matters isn't the frequency but the content. Reading the change log in the document (Appendix A) shows that the wire format and message set are still moving at this stage.

Going from -18 to -19 (May → July 2026), a Range Filter was added to subscriptions, multiple concurrent subscriptions on a single track became allowed, the PUBLISH_BLOCKED message was renamed to PUBLISH_SKIPPED, and the exception clause that let relays reorder or drop objects was removed. The step before that, -17 to -18, was bigger — unifying the moqt:// URI scheme, splitting SUBSCRIBE_NAMESPACE into SUBSCRIBE_NAMESPACE and SUBSCRIBE_TRACKS, removing the PUBLISH_OK message type (absorbed as an alias of REQUEST_OK), introducing delta encoding for FETCH responses, and allowing 7-byte varints. Names change, messages disappear, encodings change. As of -19, control messages number 18 types, from SETUP to PUBLISH_SKIPPED.

Version-negotiation policy is also worth knowing. The final RFC's ALPN will be moqt, but draft implementations use draft-numbered ALPNs like moqt-19. And every draft before -15 used a single ALPN, moq-00, negotiating the version inside the SETUP message. In short, different draft generations diverge starting at the ALPN string itself, so there is structurally no interoperability across drafts unless a server deliberately implements multiple generations at once.

Timeline targets are stated explicitly. The WG milestones put IESG submission of the transport protocol (MOQT) and Common Access Token-based authentication at December 31, 2026, and the WARP streaming format, LOC container format, and Privacy Pass authentication that sit on top of it at March 31, 2027. Target dates are just target dates, but at minimum the working group's own plan is to lock the underlying protocol by the end of this year.

Reality Check 1 — the Largest Relay Is Stuck at draft-07

Cloudflare announced the launch of its MoQ relay network on August 22, 2025. According to their own announcement, it's the first MoQ relay network where every Cloudflare server across more than 330 cities acts as a relay, and it's a technology preview (currently free) anyone can connect to at the relay.cloudflare.mediaoverquic.com endpoint. Figures like "sub-second" latency are also in the announcement, but that's a vendor's own description, and no benchmark with stated measurement conditions has been published.

There's a more important sentence in the announcement. Cloudflare's relay implementation is a subset of draft-ietf-moq-transport-07, which, in their words, has become the "de facto interoperability target among several open source projects." Cloudflare is candid about why they stopped at -07 even though the latest draft at launch time was already well ahead — instead of chasing a moving target, they decided to stop there and put their effort into deploying the relay network itself.

That state holds today. The Cloudflare MoQ documentation (updated April 21, 2026) still states support for the draft-07 subset. What's more interesting is the Known Issues item in that same document. Cloudflare's implementation includes one extra field, a Subscribe ID, in the subgroup header that draft-07 doesn't have.

What draft-ietf-moq-transport-07 defines:  What the Cloudflare implementation actually sends:

STREAM_HEADER_SUBGROUP Message {           STREAM_HEADER_SUBGROUP Message {
  Track Alias (i),                           Subscribe ID (i),      <- extra field
  Group ID (i),                              Track Alias (i),
  Subgroup ID (i),                           Group ID (i),
  Publisher Priority (8),                    Subgroup ID (i),
}                                            Publisher Priority (8),
                                           }

The document states this is a leftover artifact from an earlier draft and will be fixed in a future release. In other words, today's "de facto standard" is not draft-07 alone — it's draft-07 with one specific implementation's deviation layered on top. This is the interoperability reality of a protocol four years into standardization, as of July 2026 — and the interop test partners listed in the announcement (Luke Curley's moq.dev, Lorenzo Miniero's imquic, Meta's Moxygen, moq-rs, moq-js, Norsk, Vindral) all targeted this same draft-07 neighborhood as a result.

Put this together with the ALPN policy from the spec section above and the conclusion is clear. If you implement a client to today's latest spec (-19), you can't even negotiate a connection with the only publicly reachable relay at scale.

Reality Check 2 — the First Proposer's Fork, moq-lite

Opening draft-ietf-moq-transport-00 (July 2023) on datatracker shows the first author is L. Curley (then at Twitch). The author list for -19 is Cisco's Nandakumar, Google's Vasiliev and Swett, and Meta's Frindell — Curley's name is not there. He now maintains a personal draft called draft-lcurley-moq-lite, whose most recent revision (-05) is dated June 30, 2026, and runs 40 pages. Set next to MOQT's 149 pages, that alone is a message.

The fork's rationale is spelled out unusually bluntly in the moq-lite draft's Rationale section. To paraphrase — he fully believes in MoQ's motivation and potential, but designing this kind of experimental protocol by committee has been hard, and MoqTransport has become too complex. Too many messages, too many optional modes, too many half-baked features. The standardization process is actually getting in the way of real-world experimentation, and instead of arguing over hypothetical applications, real applications need to get built. So moq-lite strips everything down to "the bare minimum needed for real-time applications that want to replace WebRTC." Even things he agrees are good ideas, like group order, he left out, saying he'd add them "when actually needed," and the draft itself states outright that "this document represents the current state, not the final state."

Looking at how structurally different it actually is:

The data model is Broadcast → Track → Group → Frame — there's no subgroup layer like MOQT's, and Object has been renamed to Frame to match media terminology.
There are exactly six bidirectional stream types: Announce, Subscribe, Fetch, Track, Probe, and Goaway. Compare that to MOQT's 18 control message types.
On the other hand, there's something MOQT doesn't have — -05 defines four transport bindings: QUIC, WebTransport, plus Qmux over TCP/TLS and Qmux over WebSocket. There's a TCP fallback baked into the spec for networks where QUIC is blocked and browsers without WebTransport (Safari). Datagrams are only supported over the QUIC/WebTransport bindings.

The First MoQ CDN, which Curley wrote the day after Cloudflare's launch, shows this view even more bluntly. By his count (as of August 2025), the moq-transport repository had accumulated 650+ issues and 500+ PRs, and he estimates the underlying networking layer is "at least 3 more years" from becoming an RFC. His comparison point is QUIC — Google started deploying it in 2012, started standardizing it in 2015, and the RFC came out in 2021. And QUIC had a mountain of production data to refine the spec against, while MoQ so far only has demo-level usage experience. For what it's worth, he states that Cloudflare's own relay code is a fork of his Rust implementation (his claim — Cloudflare's announcement does not state a code lineage). His post also lays out the limitations at launch time: no authentication, no ANNOUNCE support (so no broadcast start/end discovery), and no Safari support.

To sum up, the MoQ ecosystem today has two branches. The IETF track (MOQT, targeting IESG submission by end of 2026) and the moq-lite track (a personal draft + working implementation + demos he runs himself). The two branches share concepts and terminology but are not wire-compatible.

So, Is It Time to Drop WebRTC Yet — No

It's true that MoQ's own goal is to replace WebRTC (the moq-lite draft states this explicitly). But as of July 2026, there are three reasons you can't switch over yet.

First, browser coverage. MOQT requires WebTransport in the browser, and Safari's WebTransport still isn't complete. Per Cloudflare's own documentation, Safari only got an early (not yet fully functional) implementation behind a developer flag starting with 18.4 (March 31, 2025). The same document's conclusion is telling — until Safari has full WebTransport, some MoQ use cases have to fall back to WebRTC or WebSocket. As long as you have to fall back to the thing you're supposedly replacing, that's not replacement — it's running in parallel.

Second, operational maturity. The public relay is an unauthenticated tech preview (an unguessable path name is currently the access control), and the standard, as shown above, is still at a stage where message names are changing. This isn't the stage to put SLA-bound traffic like video conferencing or live commerce on top of it.

Third, a cost that arrives quietly. Receiving media over QUIC also means the CPU cost structure on the receive path differs from TCP+TLS. I covered this with measurement data yesterday in QUIC Receiver CPU Cost and Kernel QUIC — worth reading alongside this one if you're evaluating MoQ on the server side.

Meanwhile, where today's real-time stack stands has already been covered elsewhere — WebRTC media infrastructure and the WHIP/WHEP ecosystem in WebRTC Media Infrastructure 2026, and real-time web transport options including WebTransport in Realtime Web in 2026. Why a stack like voice AI, where bidirectional conversational latency is everything, still runs on WebRTC today connects to the context in AI Voice 2026 as well. For MoQ to replace these, the standard has to be finished, browser coverage has to be there, and operational features like authentication and billing all have to be filled in — none of that is done yet.

Verdict — When to Look, When to Wait

Cases where it's worth experimenting now:

You own a live-streaming pipeline (ingest → fan-out) directly and are actually hitting the scaling cost of a WebRTC SFU or the latency floor of LL-HLS. A proof of concept is achievable today with the free preview relay and open-source implementations.
You have a stake in the protocol itself — this is the last window where feedback can still shape the spec. Per the WG milestones, it moves to IESG by the end of this year.

Cases where waiting is the right call:

Media traffic with a production SLA attached. An unauthenticated preview relay, a wire format that changes every two months, incompatibility across drafts — any one of these three is reason enough on its own.
A service where full browser coverage, including Safari, is required. You can't start without a WebTransport fallback plan.
Any decision that has to rest on "MoQ has better/worse latency than WebRTC" — there's no public comparison measurement yet with stated conditions. Read a vendor announcement's latency claims as marketing copy.

Closing

To sum up: the MOQT spec has reached -19 and the working group is targeting IESG submission within the year, but the wire format still moves with every revision. Deployment's center of gravity, meanwhile, sits around draft-07 — the largest public relay stopped there and became the de facto interoperability target, and even that has a documented wire deviation. And the protocol's original proposer is running a fork one-sixth the length, arguing that "experimentation has to come before the standard."

This picture looks less like a sign of failure than the normal pain of protocol standardization — QUIC, too, had nine years between deployment and RFC. Still, the practical engineering conclusion is clear. MoQ today is something to watch and experiment with, not something to migrate to. Two checkpoints are worth marking — the outcome of next week's MoQ sessions at IETF 126, and whether the IESG submission actually happens at the end of 2026.