Is Forwarding Preference Independent of Use Case?

[martinduke]

In his review of #426, @kixelated indicated that some of the forwarding preferences seemed illogical for some use case. Indeed, the PR makes no judgments about what forwarding preferences make sense with different drop policies; it seeks a way to express missing objects and groups in any forwarding pref.

My reading of the current draft is that forwarding preference is an immutable track property. If you want to distribute a track for a use case that requires a different forwarding pref, you need a duplicate track. Maybe that's not explicit or what was intended; it could, in principle, be a per-subscription property based on the sender's understanding of the use case embodied by that subscription (or fetch, if we have those).

Or maybe we want to say that certain forwarding preferences imply certain behaviors. Maybe a track stream simply does not allow omitting objects, so no missing object marker is necessary for that format.

I don't have any preferred approach here, but we should agree about what is implied by a forwarding preference.

[suhasHere]

@martinduke I did skim through #426 but I seem to be missing the above implication in the reviews.

Also on the forwarding preference , we had extensive discussion on this topic and the group agreed to what is reflected in the draft. I am missing to understand what use-cases are we referring to here ?

[martinduke]

An example question: Can a track stream omit objects?

[kixelated]

My reading of the current draft is that forwarding preference is an immutable track property. If you want to distribute a track for a use case that requires a different forwarding pref, you need a duplicate track.

While nobody is advocating for a separate track, that's a pretty good interpretation yeah. The stream mapping and priority is baked into the objects themselves.

But a VOD should be able to use the same objects as the original live stream. This is especially true for blurred "live" use-cases like DVR, instant relay, and of course reliable live.

That brings us to my PR and Ian's FETCH: a mechanism to ignore the priority of the original object and deliver in creation order instead. I think it makes perfect sense to decouple the delivery order of first mile from last mile depending on the desired user experience. I want to go a step further and remove priority from objects altogether provided there's a default that relays can use.

But this is very different from forwarding preference, which in the draft really should call "stream mapping". I definitely don't want that to be a subscriber preference because then a relay will have to combine streams. There's a number of things wrong with that (ex. converting from stream per object to stream per track) which is why we ruled it out.

So yeah, the stream mapping is an immutable property of the track. A decoder can depend on objects being delivered according to the stream mapping avoiding the need for a fully reassembly buffer with potential gaps. This wasn't the case in previous drafts and was a massive pain.