Clarify the fidelity of SUBSCRIBE

[afrind]

During the interim last week, there seemed to be consensus that SUBSCRIBE's default behavior is a high-fidelity mode (eg all new objects will get to all subscribers, with the exception of DATAGRAM tracks). Based on the FETCH discussion - the status of a cache on any relay in the chain has no impact on new object fidelity. The only parameter that can affect this is the subscriber's DELIVERY_TIMEOUT, which opt-in.

The only other issue to address is #462 - a subscriber falls too far behind live head to sustain the subscription based on sender resource constraints. I recommend we add an error code to SUBSCRIBE_DONE such as TOO_FAR_BEHIND, include the final queued object ID, and remove the subscriber from the forwarding table so no new data is queued for them. When those objects are delivered, the subscriber can FETCH later objects and/or resubscribe as needed.

[fluffy]

I do not think this was the consensus. It has been very clear that one of the main use case for sub groups was temporal scaled video where there was enough bandwidth for one sub group but not enough bandwidth for all the subgroups.

[afrind]

Individual Comment:

I do not think this was the consensus

Here's a clip from the minutes:

Conclusion on allowing fetches to future objects:
Responses before live edge have fetch semantics, and after live edge
have subscribe semantics, provided:

Transition from past to live needs to be handled cleanly
Subscribe must be high fidelity

It has been very clear that one of the main use case for sub groups was temporal scaled video where there was enough bandwidth for one sub group but not enough bandwidth for all the subgroups.

My understanding of that scenario is that prioritization can deprioritize some subgroups but they are queued indefinitely unless the objects within pass the DELIVERY_TIMEOUT. If the delivery timeout is infinity, how does a relay know which subgroups can be skipped over (or when) and which are critical? Do you have a different mechanism in mind?

[afrind]

Individual Comment:

If a publisher doesn't have enough MAX_STREAM_DATA, MAX_DATA or MAX_STREAM_ID to send objects, it seems to me that it needs to queue until the peer grants these credits, up to the delivery timeout, right?