[Moq] Re: Request Synchronization Use Case

["Ali C. Begen" <[e-mail]>]

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]
>