Skip to content

Clarify Latest Object Filter #853

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

Closed
wants to merge 7 commits into from
Closed

Clarify Latest Object Filter #853

Changes from 5 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
a15ceff
Clarify Latest Object
martinduke Mar 24, 2025
2fea33f
typos
martinduke Mar 24, 2025
93b1ecc
alan comments
martinduke Mar 24, 2025
c31f2f6
typo
martinduke Mar 24, 2025
bfd0911
Alan comments
martinduke Mar 24, 2025
46f777a
Eliminated hints on use
martinduke Mar 27, 2025
d626e11
Merge branch 'main' into sub-filter
martinduke Mar 27, 2025
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
30 changes: 18 additions & 12 deletions draft-ietf-moq-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -879,7 +879,7 @@ allows relays to make only a single upstream subscription for the
track. The published content received from the upstream subscription
request is cached and shared among the pending subscribers.
Because SUBSCRIBE_UPDATE only allows narrowing a subscription, relays that
aggregate upstream subscriptions can subscribe using the Latest Object
aggregate upstream subscriptions can subscribe using the Higher Objects
filter to avoid churn as downstream subscribers with disparate filters
subscribe and unsubscribe from a track.

Expand Down Expand Up @@ -1343,14 +1343,10 @@ the publisher to identify which objects need to be delivered.

There are 3 types of filters:

Latest Object (0x2): Specifies an open-ended subscription beginning from
the current object of the current group. If no content has been delivered yet,
the subscription starts with the first published or received group.

AbsoluteStart (0x3): Specifies an open-ended subscription beginning
from the object identified in the StartGroup and StartObject fields. If the
StartGroup is prior to the current group, the subscription starts at the
beginning of the current object like the 'Latest Object' filter.
beginning of the current object like the 'Higher Objects' filter.

AbsoluteRange (0x4): Specifies a closed subscription starting at StartObject
in StartGroup and ending at the largest object in EndGroup. The start and
Expand All @@ -1359,13 +1355,23 @@ group than StartGroup. If the StartGroup is prior to the current group, the
subscription starts at the beginning of the current object like the 'Latest
Object' filter.

Higher Objects (0x5): Specifies an open-ended subscription. All objects with
a Location greater than the Largest Group ID and Latest Object ID fields in the
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think this is the wrong definition and will result in really hard to resolve race conditions. I think you should take it off the highest group / object the relay has received, not what was in the Subscribe OK. I'm speaking from implementation experience here. Think hard about the case of a non cacheing relay that got the object refereed to the the subscribe OK multiple object before it got the OK

Copy link
Collaborator

Choose a reason for hiding this comment

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

Would that actually work, given that joining FETCH relies on the SUBSCRIBE_OK-provided values?

SUBSCRIBE_OK will be delivered by the publisher. This is most useful where the
Group ID implies a temporal relationship.
Copy link
Collaborator

Choose a reason for hiding this comment

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

I am not comfortable of adding group relationship in these filters.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it's useful to provide a hint to the reader on why you'd want to use each of these, but I won't lie down in the road over that sentence.


All Objects (0x6): All objects that arrive via upstream SUBSCRIBE at, or are
created by, the publisher after processing the SUBSCRIBE, whether or not the
Location is higher than the highest observed when the SUBSCRIBE is processed.
This is most useful for tracks where the Group ID does not imply a temporal
relationship.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Subscription filters should be agnostic of group structure. This seems to be adding application semantics and feels fragile to me.

I am bit unsure on how this filter is addressing the original linked issue

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The original issue is that people read the LatestObject definition and had two different interpretations. Both interpretations serve valid use cases. So now there are two precise filter definitions, one for each use case.


A filter type other than the above MUST be treated as error.

If a subscriber wants to subscribe to Objects both before and after
the Latest Object, it can send a SUBSCRIBE for the Latest Object
followed by a FETCH. Depending upon the application, one might want to send
both messages at the same time or wait for the first to return before sending
the second.
If a subscriber wants to subscribe to Objects that precede the Higher Objects
filter, it can send a SUBSCRIBE for Higher Objects followed by a FETCH.
Depending upon the application, one might want to send both messages at the same
time or wait for the first to return before sending the second.

The format of SUBSCRIBE is as follows:

Expand Down Expand Up @@ -1772,7 +1778,7 @@ A Subscriber can use a Joining Fetch to, for example, fill a playback buffer wit
certain number of groups prior to the live edge of a track.

A Joining Fetch is only permitted when the associated Subscribe has the Filter
Type Latest Object.
Type Higher Objects.

A Fetch Type other than 0x1, 0x2 or 0x3 MUST be treated as an error.

Expand Down