Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add delivery timeouts #449

Closed
wants to merge 5 commits into from
Closed

Add delivery timeouts #449

Changes from 4 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
6c125ae
Add delivery timeouts
vasilvv May 20, 2024
0d41dcd
Merge branch 'main' into timeout
ianswett May 27, 2024
6b2afb1
Convert delivery timeout to a track request parameter
vasilvv May 28, 2024
ecda081
Make "streams" singular
vasilvv May 29, 2024
72f0b97
Merge branch 'main' into timeout
ianswett May 30, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 26 additions & 0 deletions draft-ietf-moq-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like what this actually is a stream reset time


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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

semantics of this field depend on the forwarding preference
({{object-message-formats}}) used by the objects on the track in question:

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

- 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

- If the Object Forwarding Preference is `Object`, once the specified number of
milliseconds has passed since the object was fully received, the relay SHOULD
NOT open a new stream for the object in question, and SHOULD reset the
existing stream if it has 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
received, the relay SHOULD NOT open a new stream for the group in question,
and SHOULD reset the existing stream if it has been already opened.
- If the Object Forwarding Preference is `Track`, this parameter MUST NOT be
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

present.

If the parameter is absent, no timeout is requested by the subscriber. If
there are other timeouts that apply to a specific object or group, the earliest
one is used.

## CLIENT_SETUP and SERVER_SETUP {#message-setup}

The `CLIENT_SETUP` and `SERVER_SETUP` messages are the first messages exchanged
Expand Down
Loading