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

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
  Can an endpoint issue more than one subscribe to the same track?
  Yes, there are plenty of use cases.

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.