Add delivery timeouts

[vasilvv]

The timeouts in this PR are defined to to ensure that the invariant properties implied by the object delivery preference are maintained, e.g. if stream-per-group is used, it is impossible to accidentally timeout an object in the middle of the group.

Fixes #440

[suhasHere]

if stream-per-group is used, it is impossible to accidentally timeout an object in the middle of the group.

I am not sure what would be issue .. isn't its application's choice rather than transport requirement ? Just trying to understand the constraint better

[afrind]

Individual Comment:

what is a object property VS what is per subscription property

I agree this should be more clear in this PR. I'm assuming this is an immutable track property reported in Subscribe OK. @vasilvv can you clarify?

if stream-per-group is used, it is impossible to accidentally timeout an object in the middle of the group.

I am not sure what would be issue .. isn't its application's choice rather than transport requirement ? Just trying to understand the constraint better

I think this highlights something that may require additional discussion; I get the sense different wg members have different assumptions about how streams move through relays.

My view is that when a publisher chooses to deliver objects in stream-per-group or stream-per-track modes, it is doing so because it wants the reliability and ordering guarantees QUIC provides to streams. Therefore, a relay can't remove an object from the middle of such a stream, since this changes the reliability properties my app depends on. The current draft has language reflecting this:

A relay MUST not reorder or drop objects received on a multi-object stream when forwarding to subscribers, unless it has application specific information.

With this in mind, I'm inclined to agree with the stream-per-group restrictions in this PR - if a relay is delivering a group on a stream, and encounters an object that has exceeded the delivery timeout and won't deliver it, the only option is to close the stream and move on. I'm also in favor of some kind of restriction on dropping objects using stream-per-track (either disallowing it entirely, or closing the stream).

If reordering or dropping objects at relays is important to application behavior, I would think the publisher would choose datagram or stream-per-object forwarding preferences.

Is there a use case for using stream-per-group/track, but allowing the relay to drop or reorder objects?

If so, how is it better than using a stream-per-object or datagram mapping?

[suhasHere]

Therefore, a relay can't remove an object from the middle of such a stream, since this changes the reliability properties my app depends on.

This is not entirely true. If the application wants no objects to be dropped end to end across relats, it will set the duration to reflect its slowest subscriber ( in the case where there is a mix of different subscriber types ???) . This is done regardless of delivery mechanisms (stream mapping) being used .

[VMatrix1900]

Therefore, a relay can't remove an object from the middle of such a stream, since this changes the reliability properties my app depends on.

This is not entirely true. If the application wants no objects to be dropped end to end across relats, it will set the duration to reflect its slowest subscriber ( in the case where there is a mix of different subscriber types ???) . This is done regardless of delivery mechanisms (stream mapping) being used .

Delivery timeout only applies for real-time transmission, prioritizing data freshness over reliability. For DVR usecase(relays don't send this object more than 30 minutes after it was produced), 100% reliability is desired. This is more related to content policy: #448

[suhasHere]

Therefore, a relay can't remove an object from the middle of such a stream, since this changes the reliability properties my app depends on.

This is not entirely true. If the application wants no objects to be dropped end to end across relats, it will set the duration to reflect its slowest subscriber ( in the case where there is a mix of different subscriber types ???) . This is done regardless of delivery mechanisms (stream mapping) being used .

Delivery timeout only applies for real-time transmission, prioritizing data freshness over reliability. For DVR usecase(relays don't send this object more than 30 minutes after it was produced), 100% reliability is desired. This is more related to content policy: #448

From what i read, a delivery timeout of 0 means , no restrictions . yes , i do agree the some of the concerns is auth/policy related , as in, until when origin thinks the content is valid.

[kixelated]

Is there a use case for using stream-per-group/track, but allowing the relay to drop or reorder objects?

@suhasHere

Absolutely not. Never attempt to reorder or introduce a gap in a QUIC stream. Use multiple streams at drop/reorder boundaries instead.

The application chooses these boundaries via the stream mapping. If you're using a stream per group, then you've forfeited the ability to drop/reorder individual objects which is entirely the point. Now the decoder doesn't need to deal with that possibility.

[vasilvv]

Based on conversation Wednesday, @vasilvv is going to change this PR to be subscriber controlled.

Did that (also since it's a parameter now, zero is no longer a special value).

[suhasHere]

From the interim discussions:

• it will help to elaborate a bit on the use-case (even informatively) and when the timeout is triggered esp for stream per group mapping and the expected behavior
  • Are we allowing for new group to trigger reset of the stream for the older group(s)
  • Does this span across multiple groups ?

[ianswett]

From an individual perspective, I think this functionality is interesting, though I realize there are more edge cases than I first thought.

For example, we're doing Object per stream, and there are 5 Objects in a group and they arrive in reverse order (for whatever reason), is the real intent that the last Object expires first? Similar question for any single Object that arrives late due to loss/etc. Differences on the order of an RTT or two will occur fairly regularly I expect, so it'd be good to clarify the expected behavior.

The other observation is that if one is willing to send frequent SUBSCRIBE_UPDATE messages that increase the Start, you can achieve very similar behavior without any direct reliance upon time and dealing with the question I just posed. Besides the annoyance of sending and processing SUBSCRIBE_UPDATE messages, is there a reason SUBSCRIBE_UPDATE can't solve the same problems?