Code change:
This error code can be sent by a publisher to a subscriber that is not consuming data fast enough, causing a queue to form at the publisher that exceeds the publisher's limits.
I added text here on when to send Too Far Behind that attempts to clarify the fidelity of subscribe. It ended up in the delivery timeout section, which may not be where it belongs, but we don't have a generic section that explains how subscriptions work, it's spread amongst the relay section, SUBSCRIBE message and Delivery Timeout.
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 , which opt-in. The only other issue to address is - 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 such as , 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.
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.
Individual Comment: Here's a clip from the minutes: 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?
Individual Comment: If a publisher doesn't have enough MAXSTREAMDATA, MAXDATA or MAXSTREAM_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?
If the relay is sending data to a subscriber, and the link between the subscriber and the relay cannot sustain the bitrate of the track, eventually the relay will have to buffer more and more data. At some point, the relay would have to drop the data; we should specify how that happens (lowest priority stream gets dropped first?).
Individual Comment: +1 We need to specify what happens in this case. I think there's two parts: 1) selecting what gets dropped (this is a priority question) 2) the mechanism for dropping (stream resets, etc).
+1 Expanding Alan's list, I think we should determine: (1a?) valid boundaries for dropping data (group? object? byte? bit?) (2a?) under what circumstances the subscriber needs to be informed of the dropped data (do we need different verbs with different semantics in this case, e.g. fetch/subscribe? is dropping data always permitted and something all subscribers must be able to tolerate?) (2b?) the means of informing subscribers of dropped data (implied or explicit)
The AI is to add an error code for SUBSCRIBE_DONE to indicate a subscription was cancelled because the subscription was too far behind.

Related discussion:
text: as that of the next later Object, with the assumption that the Object's data was reordered. <del> If neither the subscriber or publisher specify DELIVERY TIMEOUT, Objects are delivered as indicated by their Group Order and Priority. </del> <ins> If neither the subscriber or publisher specify DELIVERY TIMEOUT, all Objects in the track matching the subscription filter are delivered as indicated by their Group Order and Priority.  If a subscriber exceeds the publisher's resource limits by failing to consume objects at a sufficient rate, the publisher MAY terminate the subscription with error 'Too Far Behind'. If an object in a subgroup exceeds the delivery timeout, the publisher MUST reset the underlying transport stream (see closing- subgroup-streams). </ins> When sent by a subscriber, this parameter is intended to be specific to a subscription, so it SHOULD NOT be forwarded upstream by a relay