MOQ spent September 21–27 giving its relays directions and finding room for broadcast luggage.

The core transport document stayed on Draft 21. Around it, implementations shipped and a collection of individual drafts tackled the jobs a transport protocol leaves to somebody else.

There was a fresh implementation release train, a clustering extension, a proposal to stop unwanted namespace advertisements, separate drafts for a lighter transport layer and conferencing, and a new way to carry MPEG-2 Transport Stream.

The relay would like a map. MPEG-TS would like help with its suitcase.

Draft 22 waited by the door

At the September 21 IETF MOQ interim, the editors said Draft 21 was more than 99 percent moved text and navigation, with wire behavior and semantics equivalent to Draft 20. They planned to cut Draft 22 that day and expected it to remain equivalent to 20 and 21.

By the end of Sunday in Edmonton, the Datatracker still listed Draft 21 as the latest published revision.

The plan moved faster than the document.

The same interim slides described the Seattle interop as an “18/20 choose-your-own-adventure.” That is a surprisingly cheerful phrase for a room full of people trying to agree on exactly which bytes should cross a network.

moq.dev divided the chores

On September 23, the moq.dev release train moved a set of components forward together, including libmoq 0.6.0, moq-relay 0.15.0, obs-moq 0.6.0, moq-cli 0.12.0, moq-gst 0.4.0 and moq-ffi 0.4.0.

The release notes include real implementation work: DASH manifests from the timeline, subscriptions and fetches starting at specific frames, file publishing by demuxing rather than pretending a file is a captured media track, and reconnect handling for relay migration.

Less exciting than a new transport primitive, perhaps. Useful if your next task is to reconnect a publisher or play a file.

A day later, Luke Curley published moq-lite-06 and Hang-03.

moq-lite describes payload-agnostic 1-to-many fanout over QUIC. Hang builds a real-time conferencing model on top of it.

Both are individual Informational Internet-Drafts. Neither is an adopted MOQ Working Group mechanism.

Both also say, plainly, that the document was generated by an AI model from the implementation and is maintained alongside the code.

A protocol specification generated from running code may be the most 2026 sentence in this entire issue.

The relay mesh got directions

The MoQ Cluster Extension revision 01 landed on September 21.

It proposes relay meshes where namespace advertisements carry the Hop IDs they have traversed and an accumulated route cost. A receiver can use the path to detect loops, recognize advertisements that came from the same publisher, and choose among routes by cost. The cost can reflect a deployment’s priorities; it does not have to mean the fewest hops.

This is still an individual draft, not a Working Group standard.

The problem is pleasantly concrete: once several relays can advertise the same content, somebody needs to remember where the advertisement has already been.

A necktie-wearing data packet directs traffic through a relay mesh, holding a map beside a looping route and a direct route.
The proposed relay map remembers previous hops. The route cost decides which way to go.

Namespace advertising learned some manners

On September 24, the individual draft moq-solicit-00 proposed a small setup option with a useful message: please wait until I ask.

An endpoint can declare that namespace advertisements to it must be solicited. Peers that implement the extension must honor that request; older peers may still send unsolicited advertisements. A relay or publisher that only wants the namespaces it requested can avoid receiving a flood of PUBLISH_NAMESPACE messages it has no use for.

Even protocol advertisements eventually discover invitations.

The same batch included moq-flate-00, an individual proposal for DEFLATE-compressed tracks. Each subgroup is one raw DEFLATE stream, sync-flushed at object boundaries, so small repetitive payloads can share compression context without carrying that dependency into the next subgroup.

If an object goes missing, the consumer must abandon the rest of that subgroup. The next subgroup starts fresh. The proposal leaves MOQT’s wire format unchanged: compression happens in the payload, so relays can forward it without decompressing it.

MPEG-TS checked a bag

Also on September 24, Paul Gregoire of Red5 and Gwendal Simon of Quortex published MPEG-2 Transport Stream Packaging for MOQT revision 01.

The individual draft adds an mpeg2ts packaging value to the MOQT Streaming Format catalog and describes carriage of 188-byte MPEG-2 TS packets and 192-byte M2TS source packets. It also covers joining, switching, timing, random access and several carriage modes.

The goal is practical compatibility. A publisher can map an existing transport stream into MOQT, a relay can cache and forward the objects without parsing the transport stream, and a subscriber can reconstruct packets for equipment that still expects TS.

Modern transport meets broadcast luggage.

A necktie-wearing data packet waits at a baggage carousel as a battered broadcast suitcase with a film reel and cables emerges from a sleek network tunnel.
MPEG-TS has arrived. Naturally, it checked a bag.

The signal this week

The useful thread runs through the details: which route should a relay choose, which namespaces should it hear about, and how does an existing transport stream fit into MOQT?

The moq.dev releases put implementation work in people’s hands. The individual drafts put proposed answers on paper. Neither tells us that the ecosystem has settled on one answer.

For now, Draft 22 is still at the door. The relay has a proposed map. And MPEG-TS would still like someone to lift that bag.