MoQ notes
24 July 2023, IETF 117, San Francisco
Monday Session III

  1. Administrivia and Document Update - Alan and Ted - 10 minutes
    MoQ documents will be moved into the GitHub repo once the WG agrees
    that they are ready

  2. MoQ Transport Issues - Ian Swett - 60 minutes
    Ian is the new editor for MoQ Transport (slides)

Slides describe ways of working he will use for the draft.

Suhas: agree proposals are confusing as currently posted, due to
uncertainty in past

Luke: Underlying issue is there are too many PRs.

Victor: PRs need to have a corresponding issue

Ian: Any suggestions?

Cullen: Please have a call with existing author teams to discuss
previous norms.

Ian: QUIC Failover is out of scope for this draft. Do we need editorial
text about it, or is current good enough?

Mo: MoQ fallback doesn't make sense, fallback will be at a higher level.
I will write a PR.

Slide: Client chooses Track ID?

Ian: should clients choose the Track ID in the SUBSCRIBE, instead of
server in SUBSCRIBE_OK.

Jonathan Rosenberg: Do we trust the client to not pick an ID that

Cullen: +1 to Jonathan. Some CDNs have global IDs. Race condition is a
bummer, but we need to leverage existing architectures and makes relays
perform better.

Suhas: We originally started on the client, and after 6 weeks of
discussion moved it to the server. Head-of-line blocking problem is well
solved with buffering, not a big deal.

Will: +1 to Cullen on unique IDs. But we can make it work with client
picking. Only has to be unique in the session, and server can translate.

Luke: Track ID is like QPACK. You can reference an index before acked.
Bummer to have to buffer stuff where you don't know what it is.

Cullen: Agree with Luke, but you can just discard. The solution is
prevent sending until ready.

Ian: Another RTT?

Cullen: Not necessarily, it's complicated

Victor: I favor client-generated IDs. Not just buffering, but also
global UIDs are likely to be really large integers.

Alan (no hat): Track ID is like QUIC stream ID -- predictable, rules to
follow. Build an alias mechanism for servers that care that much.

Mo: Not enough details have been captured. We should follow up on the
list. RTP lessons about collisions, etc led to this but it assumes a
central server. It all falls apart with a hierarchy of relays.

Slide: Split control and data streams (#138, #137, #105)

Cullen: I thought they were split?

Luke: Any message can be sent over any stream for any reason. Objects
SHOULD be sent with prerequisites

Cullen: What is a control message? Not a concept in this draft. But we
should split control and data, whatever that means.

Luke: OBJECT and SUBSCRIBE can be on the same stream

Cullen: That's nuts

Ian: I will try to write something

Alan: You're planning to say what message can go on what stream?

Mo: Not all control msgs on the same stream, please. Sometimes msg is
tied to the context of a stream.

Christian: Control stream is a great simplification. One track could
have thousands of streams and they might not send them all. Could result
in loss of control msgs!

Suhas: Christian +1. One control stream per track. Then can close one
stream when the track closes, which is very clean.

Lucas: This is different from HTTP/3's single control stream. Need to
work through failure modes. But yes, this simplifies.

Ian: Will try to enumerate problems and figure path forward.

Streaming format negotiation (#208)

Victor: well known catalog format names or SUBSCRIBE lists acceptable

Will: I have slide, there are 4 solutions

Ian: Is this in scope for Transport drafts?

Will: No, unless there are baseline rules for interop. But the catalog
is a format thing.

Victor: Transport should have an answer for format negotiation.

Ted: Odd if "matching" is media-dependent. Should address in this layer.
If longest match or first match is the different, it will be confusing.
Syntax should be in transport

Suhas: Ted +1. Streaming format, catalog format, ? format.

Cullen: Victor proposal is good. If there's a common catalog draft, this
should go there. Otherwise, the framework should be in transport.

Ian: fine keeping it in transport

#222 Clean Subscribe Termination

There is no "FIN". Don't want to discuss. Just think about options here.

#204 SUBSCRIBE ambiguity

Alan: two clients have different namespaces where A is substring of B,
leading to identical full track names. How does server match correctly.

Multiple solutions in the issue.

Suhas: If two collide, the last one wins.

Will: Is this really a problem? Don't confuse announcing with discovery.
You declare your authority for a prefix. I give the whole track ID.

Will: First one should win

Luke: What is the ANNOUNCE for? Why are prefixes a thing? I don't want
prefix routing. You request a full string.

Ted: A namespace + ID. Tuple must be unique. Put them in separate fields
so (, ill0) is different from (, 0). Just
do delimiters.

Cullen: what if they're exactly the same

Ted: go outside the system if both claim Google. Someone is lying, using
cryptography. It's an attack, not an accidental collision.

Cullen: not an attack, happens all the time. If auth failed, we're
already done. client are falling off and rejoining and reannounce with
same stuff. Clients should never announce the same URI, but relays
shouldn't have to enforce because client reboots are common

Alan: this is about the prefix case, not exact match

Cullen: we can't even agree about exact match!

Ted: Client keeps dropping to meetecho. Why not resume QUIC connection?

Cullen: not going to same relay!

Ted: let's focus on the reconnect/exact match problem. Shouldn't
duplicate QUIC reconnect semantics in MoQ layer.

Cullen: prefix problem seems silly, but the HA issue is real. Will file
a new one.

Victor: Ted +1. Use tuples. For reconnect, last one should win

  1. WARP Draft Overview and Updates - Will Law - 20 minutes

First attempt at streaming format over MoQ transport

#1: how to publish multiple formats

2: WARP is CMAF only?

3 are WARP and LOC actually different enough? We can merge them

Ian: Would there one or more required formats if more than CMAF?

Will: we can either have profiles, or require, that decoders support

Cullen: Adding WARP stuff to LOC is good. We need to express
compatibility. i.e. WARP means something specific. Maybe different RFCs?

Will: agreed. Streaming formats, or profiles in one format?

Victor: Can mix tracks in different formats! Also, have to define
profiles tailored to use cases.

(Streaming format architecture slide)

Suhas: yes, separate catalog draft. Not sure how other things should be
split in documents

Will: Draft for catalog, draft for CMAF, for LOC, maybe one for WARP

Ted: Why not just create a compound format for all packaging types? Why
make WARP one thing?

Will: That's the proposal

Ted: So why unify WARP and LOC?

Will: Because they duplicate all the layers.

Ted: Catalog draft can say how format drafts use the catalog format.

Will: We're talking past each other

(new harmonized catalog format)
Jonathan Lennox: timestamps have to be aligned in CMAF and LOC

Victor: we need a unified timing format anyway

Suhas: Example #5 is an advanced use case, do the simple ones first

Jordi: what is "lipsync" vs type-aligned?

Mo: it's another signal to indicate they are precisely aligned, but
we'll get rid of that

Suhas: timeAligned is for simulcast, libsynced puts them together

Mo: I strongly support this overall direction. The catalog is a media
format! I don't get packaging format/streaming format distinction

Victor: CATALOG usefully communicates alternative versions. Format vs.
quality vs. hardware vs language -- all goes in the catalog

Ali: Who reads the "init" in base64?

Will: the client parses it, describes the content

Ali: who has a use case for combining different formats? seems like a
mess for lipsync, etc

Will: could keep them separate, but why prevent others?

Alan: is the unified CATALOG tied to the transport, or are new catalog
formats OK?

Will: We can force everyone on one, but that's constraining, maybe have
an interface?

Jonathan: LOC should combine with offer/answer for LOCO/LOCA.

We're done!

26 July 2023, IETF 117, San Francisco
Wednesday Session III
Note takers: Mo Zanaty, Ali Begen, Spencer Dawkins


  1. WARP Issues - Will Law - 35 minutes
  2. MoQ Transport Issues Follow up - Ian Swett - 20 minutes
  3. MoQ Usages - Suhas Nandakumar - 10 minutes
  4. Low Overhead Container - Mo Zanaty - 10 minutes
  5. Prioritization Results - Ali Begen - 10 minutes
  6. Interim Scheduling and Wrap Up - Alan and Ted - 5 minutes


  1. WARP Issues - Will Law - 35 minutes

Issue #7: Multiple catalog formats/versions
Ian Swett: (Missed comment)
Suhas Nandakumar: Are we talking about catalog format or streaming
Will Law: Catalog format.
Luke Curley: I would like a URL that can configure/identify the format.

Ali Begen: Client may need a menu of all formats available before
requesting one.
Spencer Dawkins: Architecture draft should cover some of these
architectural issues. I don't want to slow down any of this, but I'd ask
the chairs to give that some thought.
Cullen Jennings: This seems like a minor issue that we can punt to
Ted Hardie: After some implementation experience, we may know better if
we need a "catalog of catalogs".

Issue #7 cont: Publish multiple streaming formats
Four different options/proposals.
Suhas Nandakumar: Option 4 is the more REST-ful way.
Philip Hallam-Baker: Reminds me of HTTP. Prefer option 2.
Luke Curley: +1 to Ted. Option 2.
Will Law: Is the catalog a fixed well known name?
Luke Curley: Not necessarily. The question is whether we need to support
the client who don't know what to ask for.
Victor Vasiliev: Mutually exclusive options. Options 2 and 4 are
Ian Swett: Clients that know what they want is straightforward. Another
case is clients ask what's best for me? Inclined to support option 2.
Cullen Jennings: Downside of option 3 is these catalogs may come from
different sources so don't embed them, just refer.
Spencer Dawkins: Are all of the catalog formats registered in IANA?
Will Law: yes, that's inferred for options 2, 3, and 4.
Victor Vasiliev: Refering to other catalogs raises the problem of how to
merge them. So embed (option 3) is not so bad.
Will Law: Merging binary and text catalogs doesn't seem straightforward.
Prefers option 1 (arguing blinds clients will be too rare).
Chairs: Poll if blind client use case should be supported: 21 Yes, 14
No. No clear consensus.

Issue #2: Track description captures media format info
Luke Curley: Keep them separate.
Victor Vasiliev: Separate.
(Mostly agreed to have it separate)

Issue #14: SVC
Suhas Nandakumar: Optional in LOC. So only add if needed.
Cullen Jennings: Not used in streaming, but used in conferencing. We
will need track relationships / dependencies eventually.
Victor Vasiliev: Container must deal with this, not necessarily catalog.

Ali Begen: No need in WARP. If LOC needs it, fine.
Luke Curley: Bigger question is whether layers are tracks or not.
Harald Alvestrand: Can't avoid SVC. Let codec handle it.
Christian Huitema: Relays should not be cognizant of this. Cleaner to
have each layer in track.
Mo Zanaty: Layers in different tracks must be fed to the same decoder in
proper order, so something in a catalog must signal that for a client to
do the right thing. But maybe just theoritcal with no deployment.

Issue #8: Content protection (skipped)
Additional catalog questions (skipped)
Chairs: Take remaining issues to the list, and we can follow up at an

  1. MoQ Transport Issues Follow up - Ian Swett - 20 minutes

Proposed process
Spencer Dawkins: Weekly summaries are available for any GitHub repos
that the activity summary JSON names. I haven't looked to see if all the
new repos are included yet, but I've talked with the chairs about this
in the past, and we'll make ssure the right thing happens.
Ian Swett: Maybe we can plan a weekly deadline day in time for useful
weekly summaries.
(Spontaneous humming ensued. Actually, not spontaneous, chair-induced.)

Issue #228: Relay routing of Announce messages
Alan Frindell (no hat): Exploring chat clients. Announce tells where to
route a subscribe, but nothing says where to route announce. We say punt
this to app logic.
Victor Vasiliev: Chat apps can have 1 or more servers that sync
Suhas Nandakumar: App logic, should be outside MOQ protocol.
Luke Curley: Like HTTP push promise, please subscribe.
Cullen Jennings: Relay to relay distribution is out of scope. Is there
info missing from Announce?
Alan Frindell: Client to relay interaction must interop?
Cullen Jennings: Yes, client to relay is absolutely in scope.
Will Law: Relay validation is up to relay implementation.
Christian Huitema: (missed)

  1. MoQ Usages - Cullen Jennings - 10 minutes

Mapping App Media to MOQ Object Model
Mapping MOQ Object Model to QUIC Streams
Bernard Aboba: Agree with Cullen's suggestion to gain implementation
experience first.
Jonathan Rosenberg: Once we map MOQ Objects to QUIC streams in the Relay
network, that is carved in stone.
Will Law: Any interest left in Datagrams?
Cullen Jennings: Yes. Need to experiment to see if datagrams outperform
single packet streams.
(cant see name, can others?): How are we going to evaluate / decide the
best option(s)?
Cullen Jennings: Perceptual user impact should be a goal.
Suhas Nandakumar: Relays may need to modify MOQT to QUIC mapping.

  1. Low Overhead Container - Mo Zanaty - 10 minutes

Talking about CMAF overhead (especially for audio). Simple, low-overhead
container might be what is needed for many RTC apps.
MOQ object header, LOC header and LOC payload.
Will remove the catalog part and move it to the common draft.
Draft to be renamed to webcodecs.
Some open issues: sequence/timestampe in LOC header vs. MOQ object
header, in-band/out-of-band video parameters.
Chairs: Move to common WG repo.

  1. Prioritization Results - Ali Begen - 10 minutes

(skipped due to time)
See the longer version of the talk at the SF video meetup:

  1. Interim Scheduling and Wrap Up - Alan and Ted - 5 minutes

Proposed interim in Boston in late September or early October. 25 can do
in person, 2 can do remote.