Media Over QUIC Working group IETF 118 Prague, Czech Republic November 2023 Working group chairs: Alan Frindell and Ted Hardie The Media over QUIC working group met twice during IETF 118, Monday November 6th, 2023 and Thursday, November 9th 2023. During the first meeting, the group reviewed the initial output of the Interop activities during the Hackathon and then agreed to continue those on Tuesday in order to make additional progress. Following this, the editor of the transport draft summarized the changes to the MoQ Transport draft since the -00 working group draft. After this, the group engaged in a discussion in how to map MoQT objects onto the transport. There was a lengthy discussion of implicit signals, explicit signals and an option to select a single mapping. The chairs proposed a statement for a show of hands: “The next draft of the MoQ Transport shall include a set of explicit signals for how the MoQ tracks, groups and objects map to transport constructs.” This was strongly supported in the room with 37 favoring this conclusion and none opposed. The group then reviewed issues related to subscription. Among the key conclusions: Those present in the room agreed that there would be no transport-level restrictions on track names and namespaces and that comparisons at the level should be bitwise exact comparisons. (Note that other parts of the system, such as catalog formats, may be more restrictive). There are multiple use cases which support the need for a single endpoint having multiple active subscriptions to the same track. When a client has multiple subscriptions, it will receive everything it subscribes to even if there are duplicates. The next draft will attempt to add an update/subscribe message, one whose uses might be to reduce the duplication without canceling and re-subscribing. The group agreed to re-title “Track ID” “Track Name Alias”going forward. In the section session the group began with a review of the updated interoperability information after the Tuesday extended hackathon. There are currently six implementations/; • MetaMoQLib: generic relay, clock server, chat, text client • MetaMoQBrowser: live streaming, videoconferencing, text client • Rust: transport, publisher, replay, clock server, web client • Google Quiche: chat client • moqtransport: chat server/client, clock server, gstreamer based video streaming • Cisco demo (2-way video): Two interactive video call was shown ( live in the room) • QuicR: Based on picoquic (raw QUIC - not WT), client/relay, some moqt-01 features are available, some are not. The group then review issues related to ANNOUNCE: For issues #225 and #227, there was a robust discussion of conflicting announcements across producers. The room supported adding an announce error code and token to the next draft as a mechanism for determining whether this approach works out. For issue #252, the room agreed that matching the behavior to the behavior agreed on Monday (bitwise comparison) was the right next step. For issue #319, the conclusion was that the draft needs to add a new frame to end an ANNOUNCE. Additionally, there was a principle stated that we should not rely on closing the session as the typical or optimal way to close state and close either an ANNOUNCE or SUBSCRIBE. The group then turned to issues related to the Catalog draft. Will first presented a pull request (#32) proposing a change in the catalog format update operation, in order to reuse JSON Patch. After discussion of the merits of this versus the existing mechanism, the group agreed that the next draft should include JSON Patch. The group then took up how to integration DRM information required for CMAF. The working group was asked a number of questions, one of which was whether this was too specific for a common catalog document format. The feedback was that the catalog format itself should not have these CMAF specific fields, but rather that it should be extensible and then the streaming format(s) which wanted to use DRM would define custom extensions to hold that information. The group then considered a pull request (#34) that responds to the issue of handling the case in which the namespace is absent, proposing that track names would inherit the namespace of the catalog track in which they were defined. This capability allows for relative naming, which aids in portability. This group agreed that this approach should be in the next draft. The group then tackled the quest of defining a bitrate (see issue #25), but it did not conclude during the meeting. As timing was beginning to be short, the group skipped the discussion of an IANA registry and moved to the discussion of using a metadata track to bind wall clock time to the media timeline. There were concerns and support expressed, but no conclusion. The group then agreed to issue a call for adoption on the draft after it had been updated to reflect the decision reached. Martin Duke then presented to issues related to parameter encodings. Issue #314 notes that there is a potential for a length mismatch in Varints used as parameter values: the parameter length and the first two bits of the parameter value both encode a length. The group agreed that this should be treated as an error when it occurred. For issue #210, it was agreed that the parameter reform in pull request #256 resolved this issue. Alan then led a discussion on the value of an interim in advance of IETF 119, and the group agreed that it would be useful. The chairs will present an option to the mailing list. Raw notes of each day are found below. Day 1 Administrivia (Chairs) Note well Agenda Bash Interop Readout Summary of MoQT Changes since -00 (Ian Swett) Mapping MoQT Object Model to Transport Subscription Issues 1 Namespace/Track Character Set 2 Subscription IDs 3 Resource Limits 4 Updating Subscriptions 5 Who picks the Track ID? Day 2 MoQT Issue Discussion 1 Follow up from Day 1 2 Parameter Reform 3 Announce Issues Brief Catalog Update (Will Law) WARP and CMAF Packaging Drafts (Will Law) As Time Permits Raw notes from the meeting below Update from Ian on Changes: • Subscribe hints added • Subscribe Rst and Fin messages were added Slide:Alan Presenting on Object Model to Stream Mapping Lacks consensus on how pulishers signal the intent to relay Option One: Implicit Signal
Option OneA : Stream per group…?
Option Two: Explicit Signal How to move forward?
Proposal: add implicit signal to the draft now. We can reconvene in 4-8 months to make final decision Discussion Ian: Is there a PR for the signal being proposed?
A: It is closed, so no.
Ian: An exlicit signal or the explicit signal?
A: An Cullen: One thing is that going back to he bug or feature - view as bug - easier t get to consensus. Reasonabe if they dont match to return. Never now how many layers there are. No one has a reason that they need it. Can signal if they need it later. Brings things closer together. Cullen: Explicit signal: rough consensus on this. On implicit singlaing there is reconnects, whatever is done wth this and errors needs system to not totally break. Will figure out implications. Need to work out the details. Priotities per stream, object not perscribe, can kick this down the meeting. Can match the implicit. This is fairly consistent with this. We have rough consensus and can reavulatuew at 119 and 120 Mo: can go forward with some explicit. Conseneus from earlier was around subscribers not being allowed to fan out to multiple subscribers in multiple different ways.We want to have a state of the delivery in the object itself. Suhas: Support the proposal. Good experiment to bring back to the WG. Focus on the publisher side of the preference setting,. There are only a few ways object model can be mapped and thus doesn’t block innovation - makes explicit attractive. OTOH Implicit leads to guess work - makes it relay implementation specific. May be reopen the discussion for subscribe preference later. Will: Full explicit signaling. Implicit is brittle. Small overhead. If we introduce data grams you could go to two bits. Want very few MOQ transport updates and want a lot of streaming updates. Ian: Dont do explicit signal because we don’t know what we’re doing and we will have to change it later. Ted: Fine with say8ng that implicit much match implicit. Cant trust that the relay will match the signal. Do you wait to get more resources or do you coalesce? Coalescing would be reasonable. The ssytem as a whole will fucntion better if it is talking to a downstream or client that…? Luke: If imlpicit doesnt match explicit it is just a bug. Q: Is it ok to go forward adding explicit to the draft? A: The problem is how you signal on the wire. If we can do it then I am for it. Does not like modes. Explicit signal is ok, wants something more flexible. From chat: Is the proposal something that must be used by all parties at all times?
A: Had not given thought. Mike English: The fact that we keep circling around in this discussion may be a sign that we dont have the right abstraction in groups and objects. Implicit should match explicit. Implicit signaling but group per stream. Caveat - reconnects. if we can we can make those talk more about what we want to do with QUIC streams or web transport priorities, and less about the structure of the container format or whatever our media happens to be we can get better layering by utilizing those to express intent about delivery, and then the streaming formats are free to experiment with different modes by building on top of that. Cullen: The relay should do what you tell them to do. Thats what implicit signaling means. Need something that is flexible enough to hit the apps we have today Will: The streaning format proposes a prioritzing that it believes is the correct format. The specs should say that every mode should forward in its own manner Jonathan: Likes the idea of expkoicit signal in the abstract. Needs to see what it is before I say if I like it. The way the publisher would have like the map of the streams if nothing had gone wrong. Thigs can go wrong which is why we have explict signal. Suhas: MOQ object model is very simple with not many options. Mo: Is stream per group suficent? No - dominant for video, does not work well enough for applications. You have to have a reorder buffer get groups out of order. If you want just linear delivery, then you could ask for a stream per track. Victor: While we are not sure what stream mapping will need, everyone agrees that group per object will need to be implemented. Explicit signalling: bad if you take a group and split it into objects. Luke: Try it out and see how it goes. Hard to let QUIC do more things. Good to be flexible, may not have a right answer. Ted Question: For the next draft itieration we propose a set of exlicit signals to allow for the mapping of the media properties and the transport properties
Will: should not use the word media - use object model
Luke: We’re not changing the properties of MOQ transport based on this mode right?
Mo: Is the question can you live with this design or do you prefer this design? Editing question live
Will: Is it how the objects map or how the groups and objects map?
Cullen: Map to quick streams? The next draft if the MoQ Transport shall include a set of explicit signals for gow the MoQ tracks, groups and objects mao to transport constructs. Yes 37 No 0 No Opinion 70 Subsribe Issues Are there restrictions on track names and namespaces?
Option 1: No Restrictions
Option 2: UTF-8
Option 3: URI FriendlyL RFC 3986, sections 2 and 3 Victor: no restrictions
Cullen: no restrictions - where in the system are there restrictions? Catalogue will probably be option 3. Moq transport should be option one.
Is that the generan consensus?
Harald: Do you compare these names? Be very sure that you dont get the names from two different sources. DNS is int heory a binary protocol.
Suhas: Transport layer goal is to have milions of connections coming through
Mo: agree with cullen - spec would have to say clearly where escape happens
Luke: meant to be human readable. as long as its hashable.
Christian: name should be strongly tied otherwise you have security issues.
Victor; Binary screens are strongly tied.
Christian: response: what happns if one client subscribes with emoji version and another subscribes with escape version? binary different, but if you packet them all the way to publish receive at the other end.
Suhas: Draft shoud say that by the time the bame comes to yhe MOQ transport we should be done with it. Valid point re: should be human readable. We use track names and track names best to be integers
Will: We have 2 streams that have the same names because we’ve allowed infinitely many encodings to derive a set of bytes. Is that a concern?
Cullen: how do you stop two people from using the same track name? Thats the answer to this question. Conclusion: we want exact binary comparison - option number one for the transport layer Ian will write a PR • Multiple Subscriptions #269
ç Luke: Do you subscribe or not?
Suhas: wee should allow multiple subscribes. General answer - Yes.
Will: What’s the intent when a client subscribes twice for the same track?
Alan: if somebody comes in and they want something older, you might need to issue a subscribe. There is a PR in flight, feel free to review. • Multiple Subscriptions and updating a subscription #269 Ted: Personal opinion - client will not always know that there is overlap. relay will give client exactly what it asks for. If the client figures out it is getting duplicates it cancels one. MUST NOT.
Cullen: Can live with what Ted said. Answer is different for live edge vs cash. Live edge - dedupe. Pulling out of cash - don’t dedupe. Difference is if suscribe arrived before the object or not.
Luke: Clarfiy relay cash filling example.
Suhas: Likes all the solutions. Proposes a solution that uses all three.
Alan: How to know when things are going to overlap? In favor of not sending duplicates if we don’t need to. MAY.
Will: Want determinism that if the client asks for something the relay gives it what it asks for.
Jonathan Rosenberg: Make before you break handoff for conference call.
Cullen: For upcoming version of the draft we should go with Teds solution. Simplest solution and we can fix it later if it doesnt work. Conclusion: When you subscribe to something the intent is to receive everything you subscribe to even if there are duplicates. Ted: we now know that you can have duplicates of subscribes and then an usubscribe and still do a make before break.
Julius: trivial to implement the subscription, keep it in. Not having it may leave to race conditions
Luke: Subscribe subscribe unsubscribe is not clean
Lucas: Is there a limit to subscribe?
Answered on next slide.
Cullen: No super strong argument either way. Easier to update exisitng subscription. Leaning to allow update.
Suhas: allow update.
Will: Update subscription. Not complex. Is the client expecting some notification in the objects such as track ID to change to indicate that these objects are the result of the updated subscription, or can the same track ID if or alias be used? Ian Question: Do we want this but we don’t want it in the next draft? Suhas: writing a draft doesnt mean we have to work on interop for that.
Luke: Easy to implement Write some text and get feedback. Conclusion: Attempt to add an update/subscribe message. • Multiple Subscriptions could cause resource exhaustion #272 Martin: Does web trans not have something we can leverage here?
Lucas: what are the different limits across the different hops and intermediaries and what happens when they don’t align?
A: Very complex, still working on this.
Will: fan of limit, is it absolute or concurrent?
Absolute
Suhas: Not against limit
Mo: Confused about the resource you are trying to protect. Can do another session. WOuld it make sense to have 1000 subs on one track?
Cullen: Limit need to enforce is the maximum number of concurrent subscribes that are open in the session at any given time.
Lucas: This is about concurrency but it doesnt sound that way. Volunteering to help with the text on this when you get to it.
Jordi: Needs to be concurrent because the subscribers use memory and this is a protection against an attack. • Who picks the “Track ID” - Off Ramp Edition #145
Proposal: rename Track ID to Track Name Alias
Cullen: In favor of this
Will: dont comprehend the use case of two different things. Preference to leave it out.
Cullen: In favor of two different things.
Suhas: MOQ is about pubsub on tracks Conclusion: PR needs to be reviewed. Session 2: Thu 5pm (Ballroom) Agenda bashing. Starting with the interop readout. Alan presenting the interop readout (6 implementations). Several test cases. Slide 3 presenting the test cases and results (between and across implementations) for each implementation. • MetaMoQLib: generic relay, clock server, chat, text client • MetaMoQBrowser: live streaming, videoconferencing, text client • Rust: transport, publisher, replay, clock server, web client • Google Quiche: chat client • moqtransport: chat server/client, clock server, gstreamer based video streaming • Cisco demo (2-way video): Two interactive video call was shown ( live in the room) • QuicR: Based on picoquic (raw QUIC - not WT), client/relay, some moqt-01 features are available, some are not. Announce Issues (Alan presenting) • 4 issues, #225 (conflicting announces across producers) and #227 (announces with same name in reconnect). Will commenting on the use of redundant publishers (time aligned, synchronized, inter-changeable). Ian confirming the use case. Jordi is not sure whether this is a transport issue or not, but either way it has to be considered. Alan showing three options. Cullen says we should allow for a conflict? Could be one of the options. Will is yet adding another option (turns out to be the same as option 3). Cullen: Deduping is trivial if it is on the same relay upong receiving the same object. Will says deduping is not trivial across relays. Ian also prefers allowing for dups. Suhas agrees. Victor, Luke are also commenting… Ted trying to summarize the solution forward. Adding an announce error code and token in the next draft (and see how it works out). • #252 (relay matching behavior negotiation): 3 options again. Ian says lets go with 2a. • #319 (subscriber rejecting announce): Luke says we need a message for announce_rst/fin as there might be other media flowing in the same session (we cannot close it prematurely). Catalog Issues (Will presenting) • Two PRs and proposals for existing issues. • JSON patch to update the catalog. RFC 6902/7396. Will showing the current and proposed operations. Suhas says lets go with what the draft currently has. Alan likes the other option better (reuse existing stuff). Luke also prefers to reuse stuff. Mike agrees. Cullen is questioning whether we actually need an update mechanism (are they really needed because of size or something else)? Will says updates are optional but could provide benefits for large catalogs. Cullen gives in. Decision is to merge the PR. • Issue #28. Encryption/DRM info for CMAF. Some DRM guy should confirm the parameters. Will is showing a diagram explaining things at the root level and inheritance features (less repetition compared to DASH/HLS). Will is listing 4 questions to the WG. Comments are along this might be too specific for a common catalog document. Also Cullen suggests not to use wall-gardened specs normatively. It was agreed not to proceed with the PR as-is but define extensibiliy mechanism to the core catalog. Move DRM specific things to extension spec or streaming format spec. • PR #34: Relative track names/inherited namespace. Noting the typo on the slide. Accepted. • Issue #25. Bitrate definition. Lots of comments. • Issue on IANA registery. Skipped. • Issue on metadata track. Used for binding the wallclock time with the media timeline. Mo has some concerns, Luke says we need this for VBR. • Calling for WG adoption. Adoption after the updates. Announce issues (Martin presenting) • Issue #314 (length mismatch) • Issue #210 (track request parameters) Interim discussions (Alan presenting) • Chairs will get back to the list with some options. Brisbane meeting will happen, though.