IETF MOQ WG: Consensus call on Object filters
Luke Curley posted to the MOQ working group mailing list on May 13, 2026. 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.…
Message Snapshot
- List:
moq@ietf.org - Thread subject: Consensus call on Object filters
- Message subject: [Moq] Re: Consensus call on Object filters
- Author: Luke Curley
- Published: 2026-05-13T21:30:20.000Z
- Source tag:
ietf-mailing-list - Message URL: Open in IETF Mail Archive
Summary
Luke Curley posted to the MOQ working group mailing list on May 13, 2026. 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.…
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
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
Plain-Text Body
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.