[Moq] Re: Request Synchronization Use Case

[Alan Frindell <[e-mail]>]

The slides I uploaded yesterday cover the use cases discussed here, the
range of options as I see them, and the new SWITCH_FROM proposal:

https://datatracker.ietf.org/meeting/interim-2026-moq-08/materials/slides-interim-2026-moq-08-sessa-request-ordering-switch-from-00

This is for the Request Blocking topic tomorrow at 12:30 local time.

Thanks

-Alan

On Tue, Jun 9, 2026 at 3:20 PM Ali C. Begen <ali.begen=
[e-mail]> wrote:

> Thanks, Alan. This PR #18 (and #1642) looks good to me. It does pretty
> much everything I wanted from the original SWITCH PR and is closer to our
> current implementation in MOQtail. I hope to show some live ABR demos
> (subscriber-side and relay
> 
> Thanks, Alan. This PR #18 (and #1642) looks good to me. It does pretty
> much everything I wanted from the original SWITCH PR and is closer to our
> current implementation in MOQtail.
>
> I hope to show some live ABR demos (subscriber-side and relay side) on Thu.
>
> -acbegen
>
> On Tue, Jun 9, 2026 at 11:43 AM Alan Frindell <afrind=
> [e-mail]> wrote:
>
>> Thanks for the detail Cullen.
>>
>> > is there a possible unification with a slightly simpler SWITCH
>>
>> I drafted a PR <https://github.com/afrind/moq-transport/pull/18>
>> (currently in my repo) for a new "SWITCH_FROM" *parameter* that can be
>> included in SUBSCRIBE and REQUEST_UPDATE.  This PR builds on #1642
>> fill-fetch streams, and offers a subset of SWITCH functionality from #1378,
>> while also adapting to the unrelated track scenario.  The essential bits
>> are:
>>
>> SWITCH_FROM {
>>   Switch From Request ID (vi64),
>>   Mode (1),  // Hard or Soft
>>   Publish Done (1),
>>   Reserved (6),
>> }
>>
>> The publisher determines the Start Group of the resume subscription as
>> normal
>> 1. Set Forward=1 and Apply the Subscription Filter (this ensures new
>> objects in future groups aren't missed)
>> 2. Continue delivery on the suspend subscription until there’s an object
>> to publish in the resume's Start Group
>> 3. Make the Switch
>>   Mode = Hard --> Set Forward=0 on the suspend subscription
>>   Mode = Soft --> Set End Group = Start Group - 1 on the suspend
>> subscription
>> Cancel delivery of any Groups >= Start Group
>> Send PUBLISH_DONE if requested
>> 4. Send SUBSCRIBE/REQUEST_OK
>>
>> Having spent time writing this PR, I have a much deeper appreciation for
>> the work Gwendal and co have been doing.  There are many cases to consider,
>> and I don't think I've worked through them all exhaustively.  There is room
>> to expand the functionality.  Thanks Zafer and Gwendal for some early
>> reviews and feedback.
>>
>> I plan to cover this in more detail during Thursday's discussion on
>> Request Ordering - I'm open to feedback or a different direction entirely.
>>
>> Thanks
>>
>> -Alan
>>
>>
>> On Sat, Jun 6, 2026 at 10:13 PM Cullen Fluffy Jennings <[e-mail]>
>> wrote:
>>
>>>
>>>
>>>
>>>
>>> > On Jun 3, 2026, at 12:14 PM, Alan Frindell <[e-mail]> wrote:
>>> >
>>> > Circling back to the use cases here -- I copied them into issue #1519
>>> last month and there has been some discussion there, but I'd like
>>> additional input ahead of next week in case folks have missed it.
>>> >
>>> > > 3) a stream being paused and unpaused in rapid succession and
>>> requests reorders on the wire resulting in the opposite of the desired
>>> state.
>>> >
>>> > Since REQUEST_UPDATEs are serialized on the subscription stream, I
>>> believe this use case is already met.  Please correct me if I'm missing
>>> something?
>>>
>>> Agree
>>>
>>> >
>>> > > 1) Swap tracks. In a video conference, a subscriber is subscribe to
>>> track for Alice and Bob’s video and is watching Alice with Bob paused, but
>>> wants to pause Alice and unpause the track with Bob. It’s pretty common to
>>> want to ensure to pause the current one before unpausing the new track to
>>> not have congestion.
>>> >
>>> > I just want to clarify -- is this scoped to a single pair of tracks or
>>> many pairs (eg Alice's Audio + Video and Bob's Audio + Video), or something
>>> that's not even pairwise (Swap Alice's Video for Bob *and* Cindy's)?
>>>
>>> Both cases happen but when switching from Alice to Bob & Cindy, if you
>>> switch to Bob then put in a separate subscribe update to change Cindy
>>> forward to true, it does result with Cindy delayed an bit but this all gets
>>> masked a bit as the windows change size. I think we could live with having
>>> a bit of delay in that case.
>>>
>>> I’m mostly concerned with the Alice to Bob case.
>>>
>>>
>>> >
>>> > > 2) client side ABR
>>> >
>>> > Ian added some questions in the issue, but i think it reduces to
>>> essentially the same problem as above, except it's Alice's low-quality for
>>> Alice's high-quality video.
>>>
>>> Agree this is same as Alice to Bob case above.
>>>
>>> >
>>> > I guess the direction I'm heading in -- is there a possible
>>> unification with a slightly simpler SWITCH.  If we reduce SWITCH to only
>>> swapping the forward state on two tracks with existing subscriptions (no
>>> more SWITCH->PUBLISH), and make "min group" an option, would this meet all
>>> our ordering requirements?  This presumes some way to effect a join, which
>>> #1642 offers.
>>> >
>>>
>>> I’ll send a review of the PR - I agree something in that direction could
>>> work -  thanks.
>>>
>>> > Thanks
>>> >
>>> > -Alan
>>>
>>> --
>> Moq mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>