0930-0945 Administrivia
0945-1015 DoS/Resource Protection (Mike)
1015-1100 Advertising (Will)
1100-1145 SWITCH (Will/Ali/Gwendal)
1145-1245 Lunch
1245-1345 Client-initiated and publisher-initiated server-side ABR
(Will)
1345-1415 ABR (Ian)
1415-1430 Break
1430-1445 ABR summary (Martin/Alan)
1445-1515 Secure Objects (Cullen)
1515-1600 Extensibility (Ian)
1600-1700 Parking Lot/Editors’ Time
Agenda bashing: Take some of the joining fetch at the end of the of
today's agenda to enable off line discussion.
Scribes for the morning: Zafer and Cullen
Scribes for the afternoon: Ye-Kui and Gwendal
Collaborative effort with Ian and Meta.
Q1: The question: Do we need a separate draft for this?
Q2: Specifity (see the slides for details)
Q3: Load-Bearing Mitigations
Mike English: I prefer using a table. The problem and its
mitigation, mapped in a table.
Will: Writing numbers down is very difficult. Numbers will age
quickly. Let implementers do it.
Decision: Mike English will write a separate draft by March 1 (e.g.,
security considerations for operators). Focus on DOS for now.
Will: You can see Gwendal's specific implementation for MSF. This
presentation is not specific to MSF.
Luke: The ads can be served by an HTTP server as well.
Will: I'm not showing beaconing today but it can be via HTTP or MOQ.
Christian: Beaconing and/or reporting shall be part of the architecture.
Cullen: In longer term, applications server could use the new group
request up to the original publisher to allow very variable size groups.
This will not happen in short term as it is not how current tools chains
work.
Some discussion on beaconing and feedback of who saw what ads. Will will
update diagram on slide 2 to propose MoQ based architecture for
reporting what ads were seen.
Will: There will be an ad pool, users will go into buckets. Depending on
which bucket the user is in, the ad served from that bucket. With MOQ we
have a trusted connection and we can use backchannel to collect
information knowing who is talking to us.
Christian: Feedback of advertisement has many more privacy and security
issues. We should have a design for this.
Luke: It is nice to see beaconing on the diagram. (Slide 3)
Gwendal: Same arch. works for blackout management. How to blackout
certain areas / regions.
Ali: The server side insertion may be more successful. Most traditional
companies do server-side, since client-side management of ads may be
problematic.
Mo: Request a resource or request a composed resource? Names of the
resources are different than what publisher uses?
Alan: We can't break the uniqueness property. Either it should be
cohort-based or subscribe with a unique id.
Will: Anyone subscribing to 1234 will get the same binary. These ads are
cachable. Customized output streams.
Alan: You can't change the content based on the parameters.
Suhas: This arch. fits into MOQ? (Will: Yes)
Gwendal: I put the slides how we can use SCTE to manage/insert ads.
Yasser: How can you identify the ad whether national or local?
Will: If the regional is broken, you can show the national ad.
Cullen: Priority of ads are always higher.
Gwendal: We have a demo based on this architecture using SCTE.
Cullen: What is the purpose of SSAI? Try and reduce the odds of a bad
player choosing not to play the ads.
Luke: The ad server is the entity that provides the tokens and controls
the streaming. The client cannot escape the ads.
Ali: Isn't that a dependency? It was discussed in MPEG-DASH. MPD will be
provided and client will manage, did not work well. We should not pursue
this approach.
Christian: You can never force a client to do something. The big
question is if the relay should be ad-aware or not? Collecting feedback
or messing with the content?
Mo: Question about fetch. Is fetch prohibited during getting an ad?
Luke: DVR is the number one problem.
Gwendal: I support this idea for A/B watermarking.
Mo: Most worried about uniqueness of the objects. A composition server
(even it is a generic). A composed track is a new track.
Will: Composition will be deterministic and will have a different full
track name.
Luke: Substitute should be on the client instead of doing it on the
relay.
Will: We can't trust the client to make the A/B watermarking, relay can
do it. Or for blackout management.
Suhas: Mo was talking about the composition in the context of a
conferencing application. Uniqueness property should be satisfied.
Victor: Naming as application relay is not good. Global state ends up
implementing a custom logic on the relay.
Will: Name can be bike-sheddable. The idea is to take inputs present
them as a different output.
Alan: This idea will exist in the world. I don't think it is the time to
wire this into the draft. It requires more implementation experience.
Will: We can implement by ourselves but everyone will do its own
implementation. That's why we need a generic feature now to prevent
this. We already started telling how relays should behave.
Alan: We should be targeting extensions first. Do we want to slow down
MOQ v1?
Cullen: What are the requirements of A/B watermarking
Will: Create a permutation for a unique user. A relay should support
this.
Cullen: Lots of reasons to have an application relay server. Ad
insertion is always first-class feature but can we do that without
modifying the current protocol?
Mike English: This is a required capability but can be implemented in
the future.
Yasser: Simplicity is good. Today we have multiple beaconing to
cllaborate the data from multile audit paths. Even if this gets
implemented, they will look for other ways to implement their solution.
Gwendal: Substitute is number one priority for me for A/B watermarking
besides ads.
Will: Enough consensus that we do not need it for V1. I do not want to
slow down V1.
Actions:
11:04 - 10 minute break
Cullen: Some of the things presented here don't make sense to me. I have
very strong evidence current mechanisms work for us.
Will: We have use cases that current mechanisms don't work.
Ali: Consecutive switches are complicated. Using 3 messages for doing a
switch makes it more complicated.
Mike: raised issue that if you switch near start of new group, switch
time make be delayed a whole group length over other approaches
Zafer: explained how a thing a bit like a joining fetch can help reduce
switch times and is implemented in MoQTail - have demo
Alan: raise issue of when does relay have "next common group". Perhaps
it is have object 0 of next group after what currently sending both
group.
Luke: G-switch is relay's point of view? (Gwendal: yes)
Cullen: I don't get how the relay knows which client received which
object. There may be a huge time difference between when relay sends the
object and the client receives it.
Luke: The relay needs to store the ACK position of every stream.
Cullen: I would be more comfortable if it only swap the forward flags.
Conclusions
Still unclear what are the requirements, concerns and impact. More
discussion on Switch at end of the day.
1st presentation by Will (12:58):
Will clarified that client herein means the end subscriber.
Alan: It seems that there is a combination of a fallback mechanism and
an ABR mechanism.
Magnus (and Cullen): The multiple tracks can make the estimation of
throughput a complicated process
Ali: Alternative tracks, e.g., of different bitrates, might have
different priorities.
Mo: there is no good algorihtm to decide what tracks to send and what
bandwidth to allocate for each track with respect to client's wishes.
Will (and Ian): Such algorithms exist (typically YouTube)
Luke: Is the client asking for the tracks or is it entirely Relay-side?
Will: Client is not involved in this one?
Ian: Is ABR more of an implementation issue or a standard issue, i.e.,
do we really need to specify concrete mechanisms for ABR?
2nd presentation by Will (13:19)
Slides:
https://datatracker.ietf.org/meeting/interim-2026-moq-03/materials/slides-interim-2026-moq-03-sessa-publisher-initiated-server-side-abr-using-a-defined-extension-w-law-00
Cullen: It would be good for the original publisher to express the peak
bitrate as they have a better view of what it can be than a relay that
is only observing the traffic seen.
Victor: Is there any overlap between the first approach and the switch
approach/proposal?
Will clarified that there are different business cases for these two
different ABR approaches described in these two presentations.
Victor: The publisher sending the information makes more sense
Luke: The 1st approach is a pretty one. Client must be able to say that
they cannot consume some tracks.
Ian: It is the right direction. Group boundaries is good. The filter is
really useful here.
Gwendal: A slight change to the switch message could achieve similar
functionalities.
Suhas: A good direction. Also for video conferencing use cases.
Ali: Should support both client-initiated and server-initiated cases.
Victor: Maybe Publisher-only is more important. Do we need to
communicate the buffer size of the player?
Alan: Still concerned about initial startup due to relay waiting. But I
do see a general agreement in the group of this being in the right
direction, just unclear when would the writeup of the PR(s) would be
available, reviews and potential issues to be found, etc.
Mo: Use the track filter! It is the simplest way to define all
information to support the decision to switch.
Alan: There is information needed that is missing in the filtering
system.
Ian will present ABR, editors will synthesize.
Gwendal: It would be useful to have more parameters than just bitrate
for ABR decisions.
Cullen: Should we use Namespace for Track Group, or should we explictly
indicate the variants of the Track Group
Victor: Different players may use different subsets. For example, can or
can not do AV1, can only do less than 4K etc.
Will/Ye-Kui: If the client cannot play some of the tracks, the namespace
would not be enough to define Track Group. More parameters are needed
for a client/player to choose from within a switching track group.
Ye-Kui: Should the Relays subscribe to all tracks in the Track Group?
Ian: Not necessarily, but Relay should be prepared.
Tim: This is basically deciding based on bandwidth. Ian: Yes. Tim: Then
priority is not really taken into consideration?
Mo: Instead of defining metrics exclusively, those should be left for
applications.
Ali: Quality is also function of the client display, so a publisher
metric is not sufficient. Mixed codecs make rate selection complicated.
Luke: Having different thresholds for switching to and switching from
could be useful.
Cullen: Can we do all these with filters?
Ian: In the case where we add video conferencing with 4 video sessions
and each session could do ABR across 3 resolutions it gets complicated,
as a nested filtering would be needed.
Suhas: The proposal seems fine.
ABR summary (Martin/Alan)
3 proposals: Track filter -- SWITCH -- Ian/Will overlapping
Ian/Will overlapping: Separate draft extending MOQT
Will: Switching and ABR are different. We must land server-side ABR
as part of MOQT v1.
Ali: I can write a draft to explain all details of ABR switching.
Alan: Better to not have ABR in MOQT v1 for now, unless drafts and
implementations prove things are perfect on time before the
publication of v1, in which case it would be included then.
Mo: From the experience of Filter, the design team will take a lot
of time
Will: Filter and switch are different too. These are independent. We
cannot have MOQT without ABR
Cullen: ABR has been identified as a requirement of MOQT v1 since
day 1. Also it is important to know whether the filter PR will land.
Suhas: Switch is close to ABR and we could do this together.
Victor: ABR clearly depends on SWITCH. Joining fetch is related.
Server-side ABR and Subscribe_namespace are prone to challenges
Mike English: Client-side ABR through SWITCH could be sufficient for
MOQTv1
Ian: I could write a PR by tomorrow to add something based on filter
to enable basic ABR cases.
Chairs: we'll start with the draft for server side ABR. In case the
solution is mature enough prior to MOQT has been progressed the solution
can be merged.
Alan read the Sept. version. The latest version was submitted yesterday.
Quite a few people have read a version of the draft in the past six
months.
Chairs: A call for WG adoption will be issued soon.
TLV to TV (#1184):
Group decision: Go for it. Will use TV. Will clean up places where we
are inconsistent like last thing in message. Will clean up things not
allowed in a given type of message are a protocol error.
Unknown setup options and extension negotiation (#1407):
Cullen: Can some extension headers be required to understand?
Ye-Kui: The answer should be yes, as there can be parameters that a
content provider or media encoder add that are required to be processed
and if someone does not understand them you should not try to consume
the content at all.
Victor: It seems making sense for track extensions, but probably not for
object extensions.
Agreed to have two-byte type, and for track extensions only.
Extension allocations (#855, #1268): Agreed to land the PR with both
options.
Error code handling (#1175, #1231)
Single message vs single API + composite messages
Cullen: What matters are where are the data buffered and relay behavior.
Will: Joining a track is the most common use case. Lacking a single
message for this to me is an architectural flaw of MOQT.
Paul: +1 to Will
Victor: There is disconnect between what actually happens on the wire
and what people want to happen.
Gwendal: There does not seem to be an issue with a single API. The
number of messages doesn't matter.
Suhas: HoLB is the main issue. The current flexiblity is more composable
for business logic.
Luke: This comes down to intent. SUBSCRIBE wants to skip groups, do
stuff out of order. Having the first group with split semantics is
weird.
Ye-Kui: What is better for the most common use cases?
Cullen: Keep the relays as cheap as possible.
Mo: Reliability is the most important -- current design is best.
Ian: Like a single message. Having multiple messages to use in
combination can gets very complicated.
HoLB
Victor: Currently some aspects related to priorities are awkward.
Gwendal: SUBSCRIBE Latest Group is not magic if the objects are not in
cache. Can use different tracks if you want separable objects.
Will: Missing objects is very rare. It's all or nothing.
Ian: +1 to Will. Joining FETCH is an optimization over SUBSCRIBE+FETCH,
but it's crappy -- it doesn't always save an RTT!
Cullen: We need FETCH filters.
Will: HoLB can be useful, but we've reinvented HTTP/1. We should break
up FETCH.
Suhas: If I don't care about FETCH guarantees, add features to FETCH.
Will: reordered FETCH streams would be a net gain.
Mo: If you want more streams, send more FETCH.
NEW_GROUP_REQUEST
Victor: This depends on the application having a priori knowledge.
Should not optimize for apps that don't know.
Luke: Always request, if it's ignored so be it.
Ian: You don't need Joining Fetch for this.
Alan: Nobody cares about this problem great.
Alan: What is the temperature of the room about all this?
Victor: Years of work on join latency, this is a common problem. By E2E
principle, push the complexity on top of SUBSCRIBE/FETCH to the
endpoints. Keep the building blocks primitive. You can play games to
avoid HoLB.
Martin: We should do something here.
Will: This should be a separate draft.
Martin: SGTM
Gwendal: +1, ABR is more important
Luke: NGR is the fastest thing, hands down. Let people get the first
group.
Cullen: we need to write down the problem
Zafer: +1 to Luke
Victor: None of the proposals look great.
Mike E: Implementions can lie to serve a group as SUBSCRIBE. But there
are limits to how much you can do that.
Martin: We will discuss solutions tomorrow.
Alan: summary -- mixed feedback on single message, HoLB thinks it's a
problem, no one cares about the rest.
Offline discussion.