[Moq] Re: Joining FETCH Survey

[Suhas Nandakumar <[e-mail]>]

Please see inline.

On Mon, May 11, 2026 at 11:15 AM Alan Frindell <afrind=
[e-mail]> wrote:

> Hi, we got cut off at the end of the interim, and we planned to put this
> survey on list anyways, so here goes.
>
> Please reply on list before 5/20.  If you want to give color to your
> answers that's fine but please choose an answer from the provided options.
>
>
> *Question 1: Are your use cases satisfied?*====
> Answer 1-5: Which best describes your situation wrt to the currently
> specified version of joining FETCH?
> Please exclude any problems related to required-request ID/ordering.
>
> 1. I do not need Joining FETCH to meet my use case(s)
>

[Suhas] Meeting use-cases typically don't soley rely on joining fetch as
the end applications (players) will pick the right choice based on GOP
duration, location in the GOP and so. So I do feel it does meet our
use-cases.

>
> 2. Joining FETCH meets my use cases(s) in both functionality and
> performance, and is not an undue implementation hassle
>

[Suhas] For the benefit it offers ( so no RTT), some implementation
complexity seems fine

>
> 4. Joining FETCH meets my use cases(s) in functionality but has poor
> performance
>

[Suhas] Not sure what we mean by "performance" here ? Can you please
clarify ?

>
> 5. Joining FETCH does not meet my use case(s) in functionality and
> performance
>
>
> *Question 2: Are you laying in the road?*===
>
> Answer 1-4 which best describes your situation
>
> 1. I can live with the shape of joining FETCH (two control messages, past
> and future have separate data planes). Make any small fixes needed and ship.
>

[Suhas]. 2 control messages are fine as long as they are semantically
different. To answer this question appropriately, I am not clear of what we
mean by  "small fixes needed".

>
> 2. I cannot live with two control messages, but I can live with separate
> data planes.
>

> 3. I cannot live with two control messages, but can live with a unified
> data plane for current group only (groups entirely in the past can have
> separate data plane).
>
> 4. I cannot live with two control messages nor separate data planes for
> past and future.
>

[Suhas]. I am finding it a bit hard to answer these questions
without knowing the actual issues here:  Is it implementation complexity or
is it purely aesthetic or has it to do with blocking vs non-blocking
responses or something else ?

>
>
> *Question 3: Augment or Replace*===
>
> If we make a change, it ____ replace Joining FETCH in MOQT
> (MUST, SHOULD, MAY, MUST NOT)
>

[Suhas] It depends on the change that is being proposed.

>
> *Question 4: Tolerable Scope of change for past*
> ===
>
> 4.1 Past data must be flow controlled in all cases (Y/N)
> 4.2 Past data must be flow controlled only if before the current group
> (Y/N)
>

> 4.3 Relays ____ use “Fill” semantics to retrieve all requested objects not
> in cache, when no existing operation will deliver them (e.g. upstream
> subscription).
> (MAY, MUST, MUST NOT)
>
> *Question 5: Delay Tolerance*
> ===
>
> I am willing to delay WGLC and RFC by ___ months to achieve a more
> preferable Joining FETCH outcome:
> 0
> 1
> 2
> 3
> 4+
>
-- 
> Moq mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>