[Moq] Re: Request for "FETCH" Proposals

[Cullen Fluffy Jennings <[e-mail]>]

> On Sep 24, 2024, at 9:48 AM, Luke Curley <[e-mail]> wrote:
> 
> Forgot to reply to Cullen, inline:
> 
> On Mon, Sep 16, 2024, 5:01 PM Cullen Jennings <[e-mail]> wrote:
> 
> Look forward to seeing the proposal but I suspect we end up with something along lines of what Luke is proposing. I like it. 
> 
>> On Sep 16, 2024, at 2:14 PM, Luke Curley <[e-mail]> wrote:
>> 
>> 
>> My proposal for FETCH mirrors HTTP. The consumer opens a bidirectional stream and the publisher replies on the same stream.
>> 
>> -> FETCH track=video group=64 object_start=4 priority=N
>> <- OBJECT id=4 ... OBJECT id=5 ... OBJECT id=6
>> 
> 
> I think we would also need the namespace in the FETCH or some way the FETCH had the full track name.  I’m assuming it would have start group and object as well as end group and object. 
> 
> Yeah it would have the namespace too. I omitted it in the example for simplicity.
> 
> But I should have elaborated, my proposal is that you can only FETCH a single stream (aka sub-group aka peep) at a time. I don't think a relay should merge N upstream streams into 1 downstream stream. It's a lot of complexity and HoLB that the viewer can accomplish with multiple FETCH requests instead (just like HTTP).
> 
> So that means the FETCH would identify a single subgroup. No start/end group ID, just a single group ID. A start/end object offset into the sub-group makes sense though.
> 
> It would make sense to add group direction flag of ascending or descending to the FETCH. 
> 
> A stream per FETCH means the subscriber could manually "order" them by increasing /decreasing the priority field only. Although given the single byte priority, an explicit order to break ties would be wise too.
> 
> I’m assuming a relay would send an upstream FETCH for any ranges of objects that it did not have or did not know if they existed or not and forward the objects in order to the downstream. This makes a latency hit for applications that have gaps but still works fine and applications that used FETCH would probably set up the groups / objects to not have any gaps in the sequences. 
> 
> The relay needs some way to know if a fragmented cache represents a full sub-group that can be served immediately. Skipping object IDs guarantees ambiguity.
> 
> IMO this is why object IDs should start at 0 and increase by 1. If you do want a gap (ex. dropped frame), explicitly signal it with an empty payload or the null object status.

I like the simplicity of this.