Minutes IETF118: moq: Mon 12:00
minutes-118-moq-202311061200-01

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.