[Moq] Re: Consensus call on Object filters

["Mo Zanaty (mzanaty)" <[e-mail]>]

Many things can already cause cache holes. But I agree filters can significantly add to that.

PR#1518 says relays SHOULD aggregate and propagate filters upstream to conserve resources. This was added mostly for concerns of amp attacks in large namespaces rather than single subscriptions. We can alter this guidance to add something like "unless the relay favors a more complete cache for potential future requests". Would that help?

Thanks,
Mo

________________________________
From: Luke Curley <[e-mail]>
Sent: Thursday, May 14, 2026 11:23 AM
To: Lorenzo Miniero <[e-mail]>
Cc: Magnus Westerlund <magnus.westerlund=[e-mail]>; MOQ Mailing List <[e-mail]>
Subject: [Moq] Re: Consensus call on Object filters

Hey Lorenzo, that's exactly my view too.

In an ideal world, a relay would only ingress what it egresses. But I don't think that's possible with object/track filters; the edge cases become extraordinarily difficult.

And Victor, I strongly think SVC should use separate tracks instead of object filters. It fixes a bunch of problems (including HoLB) as you can selectively SUBSCRIBE and prioritize each layer.



On Thu, May 14, 2026, 6:46 AM Lorenzo Miniero <[e-mail]<mailto:[e-mail]>> wrote:
On Wed, 13 May 2026 14:30:20 -0700
Luke Curley <[e-mail]<mailto:[e-mail]>> wrote:

> I chatted a bit with Mo on the phone, thanks for reaching out!
>
> I'm warming up to top-K track filters because they do improve the user
> experience. There's a naive but expensive implementation, which is
> probably good enough most of the time, and most of my concerns focus
> on the complex but cheap implementation.
>
> Heh but I got more spooked by object filters. A FETCH with an object
> filter no longer provides implicit gap notifications.
>
> ex.
> -> FETCH filter=sub-group=0
> <- OBJECT id=0 sub-group=0
> <- OBJECT id=2 sub-group=0
> <- OBJECT id=3 sub-group=0
>
> If another FETCH arrives, I can't serve it from the cache until I go
> upstream to verify whether id=1 exists, or was just filtered out.
>


Why not always FETCH everything (in the requested range) and only filter
on the way out? That's probably how I'd do it, especially in case cache
consistency is important.

Lorenzo


> On Tue, May 12, 2026 at 9:50 AM Luke Curley <[e-mail]<mailto:[e-mail]>>
> wrote:
>
> > I'm okay with object filters provided the working group actually
> > treats them as optional. But the group has already discussed
> > multiple ways we could use filters to fix issues with the draft,
> > ex. JOINING FETCH.
> >
> > I think there are three options:
> > 1. Promise to fix core issues with the draft without using filters.
> > 2. Make filters mandatory to implement.
> > 3. Make filters an extension.
> >
> > Otherwise this is a trojan horse, an optional yet mandatory feature.
> >
> >
> > And I would strongly discourage any relay from forwarding filters
> > upstream. A fragmented cache *is the reason* why MoQ won't scale.
> > Publishers can already do this via arbitrary object ID gaps, and
> > subscribers can now do it via arbitrary filters. I'm quite worried.
> >
> >
> > And yeah I definitely oppose top-N track filters.
> >
> > On Tue, May 12, 2026 at 4:42 AM Magnus Westerlund
> > <magnus.westerlund= [e-mail]<mailto:[e-mail]>> wrote:
> >
> >> WG,
> >>
> >> In yesterday’s meeting we did two polls related to the filters
> >> proposal ( https://github.com/moq-wg/moq-transport/pull/1518) The
> >> chairs take away from that is that we had a good indication of
> >> there being a rough consensus for including the Object Filters
> >> part. The signal from the top-n track filters was showing clear
> >> interest but equally strong no. So this part needs further
> >> discussion, I will start a separate thread on that part.
> >>
> >> This functionality would be optional to support and will have an
> >> option to indicate the maximum number of filters.
> >>
> >> This is a two-week (until the end of the 26th of May) consensus
> >> call on including object filters as described in PR #1518 into the
> >> MOQT specification. I encourage all, also those that participated
> >> in the poll, to state a position. State if you are supporting
> >> including Object filters in the MOQT specification.
> >>
> >> Supporting / Not Supporting
> >>
> >> Comments:
> >>
> >>
> >> Magnus Westerlund
> >> MOQ Chair
> >> --
> >> Moq mailing list -- [e-mail]<mailto:[e-mail]>
> >> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
> >>
> >



--
I'm getting older but, unlike whisky, I'm not getting any better
https://lminiero.it