IETF MOQ WG: Filters on SUBSCRIBE_TRACKS

Message Snapshot

• List: moq@ietf.org
• Thread subject: Filters on SUBSCRIBE_TRACKS
• Message subject: [Moq] Re: Filters on SUBSCRIBE_TRACKS
• Author: Mo Zanaty (mzanaty)
• Published: 2026-06-15T23:15:33.000Z
• Source tag: ietf-mailing-list
• Message URL: Open in IETF Mail Archive

Summary

Mo Zanaty (mzanaty) posted to the MOQ working group mailing list on June 15, 2026. Hi Ian, Track Properties should be static / immutable, iirc from the interim discussion. Like your codec example. But something dynamic…

Why It Matters

This message came from the public MOQ working group archive and captures active discussion, meeting coordination, or implementation feedback around Media over QUIC.

Message Excerpt

Hi Ian, Track Properties should be static / immutable, iirc from the interim discussion. Like your codec example. But something dynamic like motion would be an Object not Track Property. A property filter on a codec Track Property would filter publish, while a property filter on a motion Object Property would only fil…

Plain-Text Body

Hi Ian,

Track Properties should be static / immutable, iirc from the interim discussion. Like your codec example. But something dynamic like motion would be an Object not Track Property. A property filter on a codec Track Property would filter publish, while a property filter on a motion Object Property would only filter objects not publish.

When filters are aggregated and propagated upstream, they suppress unwanted traffic as far upstream as the propagation, typically the edge relay of the original publisher or the OP itself (self suppression) if it supports receiving filters.

In your motion example, say 0-4 are too low to alert, so the app sets a motion>=5 properly filter to suppress the noise floor, all the way to the OP or its edge relay.

This is all just the property filter, not the top N tracks filter. All range filters work with absolute values. If the app knows the absolute values it wants, it uses range filters. The top N tracks filter is used when the app wants relative comparisons of tracks to forward only the highest values rather than a known absolute value range. You can combine both to get relative and absolute filters, like top 9 highest motion>=5. If all have motion=0-4 you will get nothing. If only 3 tracks pass motion>=5 you will get 3 not 9. If 20 tracks pass motion>=5 you will get 9.

Is this clear? Do you think we need more text to clarify this?

Thanks, Mo

---

From: Ian Swett ianswett=40google.com@dmarc.ietf.org Sent: Tuesday, 16 June 2026 00:08:31 To: MOQ Mailing List moq@ietf.org Subject: [Moq] Filters on SUBSCRIBE_TRACKS

In the context of Top-N, at the interim I asked a question about filtering out Tracks known to be of no interest (e.g., tracks with no movement when looking for tracks with the most movement, etc). I asked whether the proposed Track filters (PR #1518https://github.com/moq-wg/moq-transport/pull/1518) solved this problem by allowing you to perform Top-N only across Tracks with a parameter above a certain threshold. In the room, it seemed like everyone thought it did. After thinking about it more, I'm not sure how it could, but let me walk through an example and let me know if I'm thinking about it wrong.

Example: I would like to do Top-10 for a Property (e.g., motion) like the scenario described during the interim, where the cameras are immediately connected to relays with <10 publishers each. Naively, that means a central relay would have to subscribe to every camera to construct a Top-10.

If one could filter out Tracks with no motion, that could dramatically reduce the amount of data, but if I put a property filter in SUBSCRIBE_TRACKS and it filters on Track Properties, then the Track property value for all camera Tracks might be no motion. If there was no value, I'm unsure what would happen, but let's ignore that for now. If motion occurs, I suddenly become interested in the Track, but if the Track was filtered out, I will never receive a PUBLISH and thus…