How does a relay/publisher know what to prioritize or drop?

[ianswett]

It's unclear to me what objects a relay should prioritize or drop when congestion limited. This is discussed in a few places, but I want to only focus on the question of what to send first and when to give up on sending an Object entirely.

Specific examples:

1. Is there a point at which Objects from a subscription should no longer be transmitted? If so, what determines that time?
2. How does a relay decide whether to send the newest object or oldest? Does it depend upon group boundaries?
3. Can a relay infer that some Objects are droppable if they have lower priority than other Objects in the same group?

My strawman proposal is that subscriptions should have numerical priorities, so a relay knows whether it should send Objects from one subscription or another given limited bandwidth. Additionally, subscriptions should have a TTL so relays know at what point they should stop retransmitting Objects.

[kixelated]

It depends on why we're dropping an OBJECT.

• Viewer has skipped past OR
• Relay is out storage.

In the first scenario, the receiver should be in charge since it's knows the jitter buffer size and whether it wants to block. Prioritization gets us most of the way here but maybe we add an explicit "I don't want GROUP X" message to save bandwidth.

In the second scenario, the sender must be in charge since. I would drop based on TTL with an explicit "I won't send GROUP X" message. In theory you could drop based on send order, but it's not time bounded so you end up catching way too much.

It does feel weird that they are two different units. Maybe the receiver could signal its TTL as well, but that feels wrong without advanced knowledge of the inbound content.

[wilaw]

Is there a point at which Objects from a subscription should no longer be transmitted? If so, what determines that time?

The publisher may add an explicit "expiration" absolute timestamp T to Objects. Any relay forwarding an object for which now() > T may drop that object or remove it from a pending send queue if there is congestion.

How does a relay decide whether to send the newest object or oldest? Does it depend upon group boundaries?

Objects can carry relative priorities, set by the publisher. These may correspond to newest or oldest, or they may not. The relay always sends highest priority items first when under congestion.

Can a relay infer that some Objects are droppable if they have lower priority than other Objects in the same group?

No, a relay should NEVER arbitrarily drop objects, it should just delay their sending, until either they expire or the relay runs out of queue memory. In both these latter cases, to should report this condition to the subscriber.

[ianswett]

@kixelated I do think the subscriber needs a way to indicate what objects/groups they no longer need. The idea of a 'Stop Sending' message to indicate Objects before some point are useless is one possible mechanism. Maybe there could be a corresponding 'Subscription truncated' message from the server to indicate all Objects before some point will no longer be sent? This could be due to memory pressure or something else (ie: Will's timestamp).

Thanks @wilaw for the explanation.

I'm not a big fan of absolute expiry times, because of clock skew issues, though maybe part of being a relay is having a fairly well synchronized system clock? It's certainly not something I'd want to rely on for a client, but servers tend to be a lot better. Also, I'm not sure you'd want the same timestamp value for a subscriber near the original publication vs around the world?

Are you thinking the expiration timestamp T only applies to the live edge? For VoD, presumably this time would be ignored, since otherwise features like rewinding 15 minutes wouldn't work.

For delivery order, I think you're saying:

• Deliver highest priority first
• Within a priority, deliver oldest non-expired first.

[wilaw]

though maybe part of being a relay is having a fairly well synchronized system clock

Given the ubiquity of NTP solutions, this is a reasonable requirement for a relay provider.

I'm not sure you'd want the same timestamp value for a subscriber near the original publication vs around the world?

Propagation time around the world is in the order of 100s of milliseconds. I'd just put a conservative expiration timestamp for all users, versus the complexity of trying to adjust for distance-from-origin. It would mean that close relays would expire content 100s of milliseconds after they could have, but that's not a problem. I expect relays to purge caches in the order of seconds (at fastest) anyhow.

Are you thinking the expiration timestamp T only applies to the live edge? For VoD, presumably this time would be ignored, since otherwise features like rewinding 15 minutes wouldn't work.

No, expiration notification must take DVR (rewinding) in to account. See my comment and examples here.

For delivery order, I think you're saying:

• Deliver highest priority first
• Within a priority, deliver oldest non-expired first.

Yes, although our nomenclature does not address "oldest" or "newest" so it might beter be expressed in terms of "within a priority, deliver smallest non-expired group numbers first"

[fluffy]

I'd rather talk about this on a call when we can.

[ianswett]

I'd like to discuss this on the call tomorrow if we have time, but one simple idea came up today which was that SUBSCRIBE_UPDATE could include the ability to update the 'start' of the subscription to a group which is after the start of the subscription.

This would be a simple way to say "I've started playing group X, so I don't need any groups <X"

[kixelated]

I'd like to discuss this on the call tomorrow if we have time, but one simple idea came up today which was that SUBSCRIBE_UPDATE could include the ability to update the 'start' of the subscription to a group which is after the start of the subscription.

This would be a simple way to say "I've started playing group X, so I don't need any groups <X"

Dope idea.

[wilaw]

Why are the semantics of SUBSCRIBE_UPDATE necessary? For the use case cited above, if you don't need groups <X, then UNSUBSCRIBE and SUBSCRIBE with STARTGROUP=X. Keeping subscriptions clean (single entry point, single exit, immutable after establishment) leads to more stable systems at scale.

[fluffy]

We discussed this for many months. I would rather get a bit of the other stuff nailed down before we open up all the prioritization stuff.