[Moq] Re: Request Synchronization Use Case

[Gwendal Simon <[e-mail]>]

Thanks Alan,

I'm happy with this direction. SWITCH_FROM param on top of #1642 covers the large majority of the use cases. And it does not introduce zombies fwd=0 subscriptions.

Indeed, I still see a few corner cases, mainly where the relay has to source the resume content upstream. Relay with no cache and/or a bounded/high-RTT upstream link. Not a blocker for me. I am OK to let it go.

Note that this PR depends entirely on #1642, so it makes the #1642 discussion in London considerably more significant.

Looking forward to Thursday.
Gwendal
________________________________
From: Alan Frindell <[e-mail]>
Sent: Tuesday, June 9, 2026 11:43 AM
To: Cullen Fluffy Jennings <[e-mail]>
Cc: Gwendal Simon <[e-mail]>; MOQ Mailing List <[e-mail]>
Subject: Re: [Moq] Request Synchronization Use Case

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]<mailto:[e-mail]>> wrote:




> On Jun 3, 2026, at 12:14 PM, Alan Frindell <[e-mail]<mailto:[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