Add delivery timeouts #449

vasilvv · 2024-05-20T15:06:37Z

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

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 moq-wg#440

suhasHere · 2024-05-20T17:04:19Z

draft-ietf-moq-transport.md

+  a relay should attempt forwarding objects, or zero to indicate that no such
+  time limit is provided.  The specific semantics of this field depend on the
+  forwarding preference ({{object-message-formats}}) used by the objects on the
+  track in question:


clarification question:
Since the Delivery Timeout is in the SubscribeOK, how does the relay expected to know it's value ?

Assuming the objects the relay has to serve were delivered to it via moq subscriptions, it can cache and use the value it received when it performed the upstream subscription. This will work if the value is immutable per track.

There's a corner case here, where the relay receives an object from upstream before the upstream Subscribe OK. There's no way to know if the object has passed its delivery timeout. It's probably ok to assume the object is valid to deliver in this case.

@afrind thanks ..

I am trying to wrap my head around the right set of requirements :

what is a object property VS

what is per subscription property

DeliveryTimeout seems to be object property as defined by the publisher. It doesn't change per subscription ? OR do we expect these to change per subscription ? If not, CacheDuration PR seems to be heading the right direction

afrind

Individual Comment

afrind · 2024-05-20T23:52:17Z

draft-ietf-moq-transport.md

+  a relay should attempt forwarding objects, or zero to indicate that no such
+  time limit is provided.  The specific semantics of this field depend on the
+  forwarding preference ({{object-message-formats}}) used by the objects on the
+  track in question:


Assuming the objects the relay has to serve were delivered to it via moq subscriptions, it can cache and use the value it received when it performed the upstream subscription. This will work if the value is immutable per track.

There's a corner case here, where the relay receives an object from upstream before the upstream Subscribe OK. There's no way to know if the object has passed its delivery timeout. It's probably ok to assume the object is valid to deliver in this case.

suhasHere · 2024-05-21T17:51:37Z

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 · 2024-05-21T18:32:49Z

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?

fluffy

I don't think this will work for a bunch of the use cases for a few reason:

some use cases the times outs are not the same for all objects in the subscriptions

I need to think about if that is important or not

suhasHere · 2024-05-22T05:28:55Z

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 · 2024-05-22T09:02:03Z

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 · 2024-05-22T15:22:26Z

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

I think this is the best approach by a mile. I'd also love the ability for the subscriber to indicate the delivery timeout too, so it could indicate the maximum jitter buffer size and let the publisher deal with dropping old content.

kixelated · 2024-05-22T15:33:36Z

draft-ietf-moq-transport.md

+      in question, and SHOULD reset all existing streams if those have been
+      already opened.
+    - If the Object Forwarding Preference is `Group`, once the specified number
+      of milliseconds has passed since the final object of the group was fully


Interesting that this is based on the final object; I really like it.

kixelated · 2024-05-22T15:43:30Z

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.

ianswett

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

Takes an opinionated approach to adding 'Fetch' style functionality within the existing mechanisms. Can be improved once various TTL/etc PRs land. For example, we can add a 3rd mode where In Order is preferred within a client specified Delivery Timeout. (#449). Pulls in concepts from #428 Fixes #269 Fixes #326 Fixes #350 Closes #421

vasilvv · 2024-05-28T08:00:09Z

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).

afrind

Individual Review

draft-ietf-moq-transport.md

afrind · 2024-05-28T16:21:34Z

draft-ietf-moq-transport.md

+  milliseconds has passed since the final object of the group was fully
+  received, the relay SHOULD NOT open new streams for the group in question,
+  and SHOULD reset all existing streams if those have been already opened.
+- If the Object Forwarding Preference is `Track`, this parameter MUST NOT be


In the current design, this means the forwarding preference of the track must be known by the subscriber. Perhaps it's better to a) ignore it or b) reset the stream after the timeout.

Should we necessarily design around the requirement of it being not known in advance, or a mismatch? I feel like if the subscriber expects something like stream-per-track, and it gets datagrams instead, it's going to have a bad time.

That's why I made Stream per track only used by the 'Strict In Order' mode in: #452

If we did this, I think track could be handled the same way of group and simply reset the stream and end the track if time has been exceeded.

Due to the DOS stuff discussed in Seattle, I think we should update this so that in all cases the time starts at when start receiving the first bytes

fluffy

For this to make sense as a way to not get things that are outside the jitter buffer, I don't think this works to use the end of the steam. For the jitter buffer use case, it seems like we want this to work with datagrams and perhaps the other stream modes.

This would be better if it was limited to only be meaningful for final subscriber to relay. But if that relay is downstream of constrained link, then this does not solve the problem.

fluffy · 2024-05-29T16:45:34Z

draft-ietf-moq-transport.md

@@ -862,6 +862,32 @@ information in a SUBSCRIBE or ANNOUNCE message. This parameter is populated for
 cases where the authorization is required at the track level. The value is an
 ASCII string.

+#### DELIVERY TIMEOUT Parameter {#delivery-timeout}


It seems like what this actually is a stream reset time

suhasHere · 2024-05-29T17:03:16Z

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 · 2024-05-30T17:35:16Z

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?

fluffy

Overall I think this changes what gets delivered next and would make more sense to discuss at Seattle interim.

fluffy · 2024-06-05T13:18:27Z

draft-ietf-moq-transport.md

+
+- If the Object Forwarding Preference is `Datagram`, once the specified number
+  of milliseconds has passed since the datagram was received via this
+  subscription, the relay SHOULD NOT forward that datagram.


"received via this subscription" does not make sense to me.

fluffy · 2024-06-05T13:20:41Z

draft-ietf-moq-transport.md

+  milliseconds has passed since the final object of the group was fully
+  received, the relay SHOULD NOT open new streams for the group in question,
+  and SHOULD reset all existing streams if those have been already opened.
+- If the Object Forwarding Preference is `Track`, this parameter MUST NOT be


If we did this, I think track could be handled the same way of group and simply reset the stream and end the track if time has been exceeded.

fluffy · 2024-06-05T13:22:23Z

draft-ietf-moq-transport.md

+duration for which the relay should attempt forwarding objects. The specific
+semantics of this field depend on the forwarding preference
+({{object-message-formats}}) used by the objects on the track in question:
+


I think all these case could be exactly the same which is if the time is exceeded, the stream in use (if any) gets reset and for stream per track that implies no more of the track will be sent, for stream per group that imples no more of the group will be sent.

fluffy · 2024-06-05T13:23:24Z

draft-ietf-moq-transport.md

+
+DELIVERY TIMEOUT parameter (key 0x03) MAY appear in a SUBSCRIBE or a
+SUBSCRIBE_UDPATE message.  It is a number of milliseconds indicating the
+duration for which the relay should attempt forwarding objects. The specific


Give this does not somehow propagate to upstream relays, I don't think this will meet work for the use cases where the last relay is downstream of the congested link.

fluffy

Need to sort out when time for expiry starts

Pulls in some text from #449 and attempts to convey the conclusions of the Seattle interim. Closes #449

ianswett · 2024-07-25T18:00:30Z

Closing this in favor of #486

Pulls in some text from #449 and attempts to convey the conclusions of the Seattle interim. Adds Subscribe Parameters to SUBSCRIBE_OK to allow this parameter to be optional in SUBSCRIBE_OK. Closes #449

vasilvv requested review from fluffy, suhasHere, wilaw, afrind and ianswett May 20, 2024 15:06

suhasHere reviewed May 20, 2024

View reviewed changes

afrind reviewed May 20, 2024

View reviewed changes

fluffy requested changes May 21, 2024

View reviewed changes

kixelated reviewed May 22, 2024

View reviewed changes

ianswett reviewed May 23, 2024

View reviewed changes

Merge branch 'main' into timeout

0d41dcd

ianswett mentioned this pull request May 27, 2024

Delivery Order (aka Fetch lives) #452

Closed

ianswett added a commit that referenced this pull request May 27, 2024

Pull in 'Delivery Timeout' from #449

d6ba4d6

Convert delivery timeout to a track request parameter

6b2afb1

afrind reviewed May 28, 2024

View reviewed changes

Make "streams" singular

ecda081

fluffy requested changes May 29, 2024

View reviewed changes

fluffy reviewed May 29, 2024

View reviewed changes

afrind mentioned this pull request May 29, 2024

Add a Max Cache Duration (aka ttl) field to Objects #446

Closed

Merge branch 'main' into timeout

72f0b97

fluffy requested changes Jun 5, 2024

View reviewed changes

fluffy requested changes Jul 4, 2024

View reviewed changes

vasilvv mentioned this pull request Jul 8, 2024

Error codes for streams being reset #481

Open

ianswett added a commit that referenced this pull request Jul 12, 2024

Add a DELIVERY_TIMEOUT param

a1ad316

Pulls in some text from #449 and attempts to convey the conclusions of the Seattle interim. Closes #449

ianswett mentioned this pull request Jul 12, 2024

Add a DELIVERY_TIMEOUT param to subscriptions #486

Merged

ianswett closed this Jul 25, 2024

afrind mentioned this pull request Aug 5, 2024

Controlling encoding parameters on the receive side #42

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add delivery timeouts #449

Add delivery timeouts #449

vasilvv commented May 20, 2024

suhasHere May 20, 2024

afrind May 20, 2024

suhasHere May 21, 2024

afrind left a comment

afrind May 20, 2024

suhasHere commented May 21, 2024

afrind commented May 21, 2024

fluffy left a comment •

edited

Loading

suhasHere commented May 22, 2024

VMatrix1900 commented May 22, 2024

suhasHere commented May 22, 2024

kixelated left a comment

kixelated May 22, 2024

kixelated commented May 22, 2024 •

edited

Loading

ianswett left a comment

vasilvv commented May 28, 2024

afrind left a comment

afrind May 28, 2024

vasilvv May 29, 2024

ianswett May 29, 2024

fluffy Jun 5, 2024

fluffy Jul 4, 2024

fluffy left a comment

fluffy May 29, 2024

suhasHere commented May 29, 2024

ianswett commented May 30, 2024

fluffy left a comment

fluffy Jun 5, 2024

fluffy Jun 5, 2024

fluffy Jun 5, 2024

fluffy Jun 5, 2024

fluffy left a comment

ianswett commented Jul 25, 2024

Add delivery timeouts #449

Add delivery timeouts #449

Conversation

vasilvv commented May 20, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

afrind left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

suhasHere commented May 21, 2024

afrind commented May 21, 2024

fluffy left a comment • edited Loading

Choose a reason for hiding this comment

suhasHere commented May 22, 2024

VMatrix1900 commented May 22, 2024

suhasHere commented May 22, 2024

kixelated left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kixelated commented May 22, 2024 • edited Loading

ianswett left a comment

Choose a reason for hiding this comment

vasilvv commented May 28, 2024

afrind left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fluffy left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

suhasHere commented May 29, 2024

ianswett commented May 30, 2024

fluffy left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fluffy left a comment

Choose a reason for hiding this comment

ianswett commented Jul 25, 2024

fluffy left a comment •

edited

Loading

kixelated commented May 22, 2024 •

edited

Loading