[Moq] Re: Draftification

[Suhas Nandakumar <[e-mail]>]

I've re-read the related proposals on handling multiple tracks:
- SwitchFrom PRs (continuous, immediate, aligned, or combinations)
- SSTS (the earlier PR plus the standalone draft with a BW-aware default
algorithm)
- Top-Tracks Filler (most recently rebased)

A few thoughts:

- Both SSTS and Top-Tracks enable server-side track selection with room for
future variants.
- Their core algorithms are well-defined and have been vetted over several
months of discussion and supporting early implementations ( to address
feedback )
- New selection and switching strategies will certainly emerge; a clean
extensibility mechanism is what lets that happen without reopening the base.

MoQ needs a mechanism to select between tracks: in the common use cases, no
track is standalone — there is always a relationship and a decision point
that drives selection. This belongs in the core transport as the base
mechanism.

I support landing well-scoped top-n and SSTS functionality in the core
transport, with a defined extension mechanism that lets relay implementers
innovate with/without needing to surface every variant to the IETF. The
current text for both mechanisms is deliberately minimal and keeps clear
guardrails.

Leaving this out of the core transport has real downsides:
- It slows discussion and implementation experience on core multi-track
selection.
- It leaves a gap in the charter's coverage of large-scale streaming and
conferencing.
- It signals to passive participants from those industries that MoQ isn't
addressing their core requirements, which risks slowing adoption the longer
we defer it.

Cheers
Suhas


On Mon, Oct 12, 2026 at 4:48 PM Martin Duke <[e-mail]> wrote:

> Hi Cullen,
>
> Thanks for the submission. It's a bit late for people to digest this much
> text, but we'll at the very least put it in As Time Permits.
>
> Does this really affect SWITCH_FROM, given that that is in the core draft,
> not an extension? That is Alan's highest priority for this week and if it
> impacts SWITCH_FROM, that's something we'll have to talk about.
>
> On Mon, Oct 12, 2026 at 11:51 AM Cullen Fluffy Jennings <[e-mail]>
> wrote:
>
>>
>> In the past I have said we would need some changes made to the current
>> base transport draft to allow features like TopN and SSTS and similar to be
>> expressed as extensions.
>>
>> To facilitate the discussion of who we should do these in the base draft,
>> I had put together a PR for a framework in the base draft to support
>> extensions like this. PR is at
>>
>> https://github.com/moq-wg/moq-transport/pull/1982/
>>
>> and some slides that help explain it at
>>
>> https://cisco.app.box.com/s/q48fxo9zeibkvonlf42uncc16m9z891j
>>
>> The basic idea is that the the relay would keep track of “selection sets”
>> which are sets of tracks, then a subscriptions would have list of policy of
>> what extensible algorithm run against the selection set to decide which
>> tracks are selected or not. As tracks are selected or unselected, it
>> changes if they are forwarded or not and the timing of that is unified with
>> the switch from so that it do things like happen immediately or support
>> thinks like the switch being aligned with group boundaries.
>>
>> This PR does not change how Top-N, SSTS, or Switch From work but it
>> refactors them into something that fits into a common base framework that
>> in the base draft that allows these to be expressed as extensions.
>>
>> To be clear, I think the fastest thing to do is just include Top-N, SSTS,
>> or Switch From in the base framework but I think the better longer term
>> solution is the refactoring of them along the lines in the above PR.
>> Clearly this PR would need a bit of work to tweak some of the details but
>> it is more than complete enough to fully see the shape of the solution and
>> the big picture of how it works.
>>
>> I would like to ask for 45 minutes of agenda time on Wednesday to explain
>> this and another 45 minutes to discuss the above PR and slides. I think
>> resolving this issue has remained our top point of contention for many
>> months now.
>>
>>
>>
>>
>> > On Sep 28, 2026, at 10:25 AM, Martin Duke <[e-mail]>
>> wrote:
>> >
>> > The chairs are going to initiate a consensus call about the status of
>> various proposed MOQT features – should they be in a separate expansion
>> draft, or should they be in the core MOQT draft? We would like to avoid
>> using meeting time on this discussion, to the maximum extent possible.
>> >
>> > The features are top-N:
>> https://github.com/moq-wg/moq-transport/pull/1830
>> > and SSTS: https://github.com/wilaw/moqt-ssts
>> >
>> > We strongly encourage you to read the proposals before participating.
>> >
>> > There are multiple possibilities for the trajectory that these
>> proposals will take, so it is unlikely that any single trajectory is likely
>> to achieve rough consensus. However, the working group already has rough
>> consensus that it will complete the work in some form.
>> >
>> > Furthermore, we believe that everyone agrees that both features are, in
>> principle, optional to implement because they are controlled by a Setup
>> option that can be set to zero.
>> >
>> > For the first phase of the discussion, we would like to set aside
>> short-term document processing, issue management questions, and delivery
>> timelines, and think about these standards far into the future. Would this
>> be better as one RFC or as multiple RFCs? Here are some considerations that
>> the chairs believe you should consider:
>> >
>> >     • Does inclusion in the core draft increase the probability a
>> feature is implemented, and does that matter?
>> >     • Is the feature (and core MOQT) easier or harder to understand
>> with separate RFCs? Within the working group, people have asserted both
>> viewpoints.
>> >     • Will the IETF have to revise the feature in the future? If the
>> design relies on some assumptions that turn out to be false, it would be
>> easier to revise the feature if it’s specified in a smaller RFC, rather
>> than having to reopen the entire MOQT RFC.
>> >
>> > This email does not begin any consensus call, but you are invited to
>> read the proposals, file issues, and start thinking and debating these
>> concerns. It would be great if people read the proposals, thought about the
>> issues, and discussed their concerns on the list by the 13th of October
>> (Tuesday of the Seattle meeting). In fact, interop time would be a lovely
>> time to have high-bandwidth discussions. The chairs will initiate a
>> consensus call soon afterwards, assuming there is adequate discussion on
>> the list.
>> >
>> > Regards,
>> > Magnus and Martin
>> > _______________________________________________
>> > Moq mailing list -- [e-mail]
>> > To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
> Moq mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>