Session Date/Time: 11 May 2026 16:30
This is a verbatim transcript of the Media over QUIC (MoQ) Virtual Interim meeting held on May 11, 2026.
Magnus Westerlund: Okay. I wonder where my co-chair is.
Magnus Westerlund: Okay. Apparently my co-chair has connection problems. So let's get started here and see, hopefully he joined by the time we get to the more main parts. Let me turn on my camera. So, welcome everyone to this Media over QUIC virtual interim on the 11th of May. And this session is being recorded.
Magnus Westerlund: The Note Well applies to this meeting as we haven't- if you don't know it, you have to read up on it because it does impact what- if you say or do, contribute, etc. in this meeting, there's certain things that applies to that.
Magnus Westerlund: So, as usual we use the Meetecho queue to join if you want to state something, open the mic. Reminder of the short lag between. You can speak without. ECHO and headset are recommended.
Magnus Westerlund: So, we do have one more virtual interim between we go to the London meeting in beginning of June. And this is on a Tuesday, the next interim meeting. So the 26th is a Tuesday. This is to get around Memorial Day and also a French holiday I guess it is. So. Alan?
Alan Frindell: I see Switch on the list there. Are we also going to talk about the DTS draft at that time or do you need- did you mean in separate time?
Magnus Westerlund: I think so we will take both, yes.
Magnus Westerlund: So, yeah. And for the- we will send out an email asking for agenda items for the London meeting also, so expect that soon.
Cullen Jennings: Um, are there any- are there any more updated logistics details on the timing of London meeting or how- or is it two days, three days? Just sort of like more details on that?
Magnus Westerlund: So we have- if I remember correctly, the interop is in the beginning Monday-Tuesday, and then the- it's Thursday-Friday which do the standards discussions.
Cullen Jennings: Thanks.
Magnus Westerlund: Yeah. And the standards discussion slots are in the Datatracker.
Magnus Westerlund: But yes, we will try to get a reminder about the details about that also out on the mailing list.
Magnus Westerlund: So, let's go on to give the word to Mo.
Magnus Westerlund: Let's see. Stop slides. I think you can share.
Mo Zanaty: Yeah, let me share my slides. Um, you already have the new revision up, right? So I could just select it. Can anyone hear me?
Magnus Westerlund: Yes, I hear you.
Mo Zanaty: Okay.
Mo Zanaty: Um, okay so this is the new PR for filters, which was a reduction in scope from the previous PR 1401. The new one is 1518. Filters.
Mo Zanaty: So first let me broadly say what motivated this work. Um, the main original proposals that came from Will were around video keyframe scrubbing, and that would be an object ID filter to say object ID zero for keyframes. Um, to extract the video base layer, that would typically be subgroup zero. Um, so that would be another use case for extracting a specific layer of a video. If you wanted to turn a fetch into multi-stream, um, you could do multiple fetches, each with a subgroup. So this is assuming we don't have rewind or any of the other things that talking about subscription semantics in the past. For fetch in the past, you could still have it stream-based delivery by mimicking the live stream-based delivery by having each subgroup as a separate fetch. So a subgroup filter with subgroup I would accomplish that. If you had a specific codec or encoding, um, you know you wanted H.264 or you wanted, you know a 1080p or something like that, there's a general property type filter. So you could say property type codec equals value H.264. Um, you have a priority filter, so if you wanted to have only the critical alerts in a log- this is a non-media use case- um, you could say the priority zero filter, and that will only give you the critical alerts. Those are all what we call range filters.
Mo Zanaty: Um, so object ID, subgroup, property, and priority, those are fields in the MoQ object headers and you can specify ranges of values that you want to filter on. The other broad set of use cases are like asking for the top active speakers in a meeting, for example the four most active. That's common in conferencing. Um, for a security application, you could have the top most suspicious activity among your security cameras, and if the human viewer is only able to see a 4x4 grid of 16, you can ask for N equals 16. Um, if you have players in an eSports tournament, you can request the top- top two scoring players and watch their player video side-by-side, so track filter with N equals 2. If you have non-media use cases, like a top bid in auctions or online markets, just ask for the N equals 1 top value. And server-side ABR, you could ask for the top quality within your current congestion controller's bandwidth limit estimate, you can just ask for N equals 1 track. So those are all track filter examples. And this is not exhaustive, just saying what the top ten things that the group has said before is useful.
Mo Zanaty: The design, like I mentioned, is a reduced scope in 1518. We removed the location filter from 1401 and we removed the group filter from 1401. We also removed some of the setup options and the ability to specify how many tracks can be deselected. Um, and we redefined how the ranges work for the range filters. Um, for the track filter we also removed the parameters max-deselect, max tracks deselected, and max time selected, I'll mention that later. And some improvements to the wire encoding and the interactions. So those are the high-level changes in the current PR.
Mo Zanaty: Next I just want to go through what the current design looks like as it is now. So at a high level, there are two setup options to enable these filters. By default they're both zero, so they're disabled. So if a relay does nothing, both these filters are- are disabled and subscribers can't request them. Max filter ranges is the total number of ranges that you can have in all filters for one given subscription or one given fetch. Um, so that includes all the subgroup, object, priority, property filters. All those combined can only be up to this limit. So this is supposed to limit the computational complexity that a relay has to do per object if it wants to limit that. Max tracks selected is for the track filter. It's basically the limit to top N. Um, the practical limit, you know should be in the dozens or hundreds. Um, it's a varint and I'll talk later about whether or not that can be simplified, um, if people are worried about large-scale complexity. And again, if it's omitted it's disabled.
Mo Zanaty: The range filters- there's four of them. Um, they can appear in SUBSCRIBE, SUBSCRIBE_NAMESPACE. You can update them with FETCH_UPDATE. Um, they're also available in PUBLISH_OK for opposite direction subscriptions. And they're available in FETCH. Um, they all look the same. They all have this set of ranges um, that you can have. And what was new that- that was added recently is we also have a set now, and that was to be able to allow relays to aggregate downstream filters and have a single upstream filter that was an aggregate of the downstream filters that it received. So this set concept allows being able to have filters that AND within the same set value. So if you say set one, all the- all the ranges in set one are all ANDed together. And then you OR all of the different resulting sets. So you have an AND-OR combination that um, you can use to aggregate your downstream requests to a single upstream request. You can remove a filter with a length of zero in a FETCH_UPDATE while leaving the other filters intact. And you can leave the end off at the very final range to say there's no end.
Mo Zanaty: Here's some examples. I already mentioned the use cases before, but here's the- those use cases, how you would actually implement them with the current filters. Um, pretty easy syntax, very common. Um, on the right-hand side just to show that all the, you know normal operations that you can do with equality, less than or equal to, between- all of those things, not equal to. All those operations you can still do using ranges. Um, so some people were confused about "Well, you're only allowing ranges, how do I say, you know not equal to something?" You know, you just have a disjoint range, the bottom example. So all of the stuff that you can do with ranges can turn into all the typical comparisons.
Mo Zanaty: The track filter is a different type of filter that selects the top N tracks within a namespace and it ranks them by the highest values that you specify in a property type. Um, so you watch a certain property, um, and you say for example, voice activity, and you use that on the video tracks as a tag to be able to select videos of the most active speakers. Um, the track selection filter can be combined with all of the other filters, with the range filters. Um, and the current text also mentions that forward and um- and one other thing I forget. Oh, and the subscription location filters, those are also basically filters. You can combine all of those filters together and you get an AND of all of those combinations. And the track selection filter runs first before those. And here's why- this was a change to accommodate a request for scalability to be able to allow the track selection filter to run once for the entire namespace on ingress, um, and then you run all of the other filters that may be subscriber specific on the egress legs per subscriber.
Mo Zanaty: Um, this is the actual parameter for the track filter. It can only appear in SUBSCRIBE_NAMESPACE and FETCH_UPDATE for SUBSCRIBE_NAMESPACE. Um, you see we've removed a lot of the parameters. We removed the max tracks deselected. Um, now it's up to the relay whenever it wants it can PUBLISH_DONE to purge its old state. Um, or it can keep a large list of deselected tracks internally if it wants, as like a hot cache for avoiding extra PUBLISHes and PUBLISH_DONEs. We also removed the max time selected. Um, it's now a track property, so publishers can specify that and it's uniform across all the subscribers.
Mo Zanaty: Um, we added a diagram of what the state machine looks like as a track cycles through its states. It starts off unknown, meaning that the name and the- track name and the track alias are not known to the subscriber. Once it's selected, then it's published to those subscribers with a Forward equals 1 flag, and then it's considered in the selected top N tracks. After that promotion, it can be demoted either based on a timeout or based on getting evicted by another track. Um, in which case it becomes deselected. Um, and when it's deselected it can sit in this cache of deselected tracks um, so that you don't have to specify the alias and the track in a publish again. Um, and then finally when you want to evict it out of that deselected list you can PUBLISH_DONE it. When you PUBLISH_DONE it, then it goes back up to the unknown state, the alias and name are- are no longer in scope. So only in the selected state do the objects pass the filter. In the unknown and deselected states, the objects fail the filter and so they'll be blocked.
Mo Zanaty: Um, some other changes that were made: we did delta encoding to match a lot of the other delta encoding happening in the rest of the spec um, to tighten up some things. Um, the property filter was moved to have a- a different filter parameter per property type instead of enumerating all the property types in one parameter. Um, there were clarifications on how you identify subgroup gaps when you have filters in place. And we added this selection-deselection diagram and process, and we also now explicitly signal whenever you select or deselect with a Forward equals zero or 1 flag in a PUBLISH or a FETCH_UPDATE.
Mo Zanaty: Um, also we added text about how a relay could protect itself if the namespace is large. There were a lot of concerns that- this is really more of a concern of SUBSCRIBE_NAMESPACE itself, but SUBSCRIBE_NAMESPACE now if it allows you to do a single command that triggers a lot of work by the relay if the namespace is large. Um, and so the guidance that we gave is that the relays should be able to aggregate and propagate these filters upstream to avoid doing a lot of extra work. Um, and they may impose limits at any time, either fail the SUBSCRIBE_NAMESPACE or any time during the subscription it can fail individual subscriptions. Um, and you can give an error "namespace too large" or "conflicting filters" or "prefix overlap" for the various cases that the relay thinks may be either too complex for it, constraining its resources, or maybe an attack vector.
Mo Zanaty: Um, I'm sorry, I'm seeing some questions. I hope they're answered. If not, um, just bring them up in the- in the discussion. And sorry I'm trying to fly through this as fast as we can so we can get to the discussion because hopefully that will be more fruitful. There are implementations of this um, that are tested and even demoed. Um, all the implementations are on the same order of magnitude size, you know about 1 to 2K lines. Um, and that's just the core code, not tests. Uh, there's- these are all GitHub links, so on GitHub these are all open source projects. On GitHub you can go to Quicker Laps. Um, we did a live demo of that at the National Association of Broadcasters in Las Vegas. Um, there's a link there to the- to the video. Obviously the video's not live but it's a recording of that. Um, there's also an implementation of Open- Open MoQ MockX relay. Alan did this implementation and from that experience um, he has some concerns about the ranking code complexity that was involved. Um, and then finally there's Cloudflare, the MockRS relay. Suhas took that codebase and although it- it predated- that codebase still hasn't added things like SUBSCRIBE_NAMESPACE because it's on its- pre-draft 16. It's in the process of moving to the newer drafts, um, but he was able to still add the bits and pieces needed to make that work in that- in that codebase as an experiment to see, compare all three approaches.
Mo Zanaty: Um, and then the finally the next steps, that's what I want to spend most of the discussion on is, so the- you know one option is as currently written, it's a PR against the draft-ietf-moq-transport draft. Um, so we could just merge the PR. Um, there's also been discussions about whether this should be moved to an extension draft that's on separate draft outside of core draft-ietf-moq-transport. Um, and then thirdly there's an option of okay we're not sure yet whether it's part of- you know, ready for draft-ietf-moq-transport or should go as definitely as a- as a separate draft. What if we simplified it? Would it then, you know be better- be better to simplify it first and then add it to draft-ietf-moq-transport? And the only simplification things that have come up in the past, if you look through the issues in the backup slides, um, Alan at one point asked for having a single property per namespace that could be on the- in the track filter. Uh, and even before that we had a concept where it was not only a single property but it's actually a well-defined property called a selector, so you can't even specify the property type, it's a single uniform property type across all track filters. So that- that's a possible simplification if people want. Um, I don't think it simplifies things that much but it's possible. Top N could also be simplified to be less than a byte. Uh, right now it's a varint. Um, we don't- we don't have practical use cases for requesting more than 256 in a namespace. So if people don't see a need for more than 255 tracks, we can impose a hard limit of top N and make it a byte instead of a varint. And by the way, relays can already limit that today in the setup. In the setup you can say- relay could say max tracks selected is 255 if it wanted to limit because its internal implementation was limited to 256. Um, but so those are the some possible simplifications if we thought that complexity was a concern.
Mo Zanaty: And uh, that's the last slide and I- I would just note that I think the main issue to discuss- we haven't heard too many discussions about, we haven't heard too many voices about "I'd like to see this design differently, this design differently." There hasn't been much churn about the design recently. There was a lot of churn months ago, but now I think people are pretty much on board with the design is correct and- and meets the right use cases and is the right level of complexity. These little two simplifications are possible things that people could- could think about to simplify design, but broadly nothing else is being considered to iterate on the design. The core thing I think we need to discuss is whether the complexity-utility trade-off is- is good. Um, so Alan has concerns about complexity. I think Ian had some concerns about whether the utility is enough- general enough for most applications to warrant being in the core spec. Um, and if it's just the niche only for a few applications then it should be an extension, not in the core spec. So I think the core question for the next steps is whether or not the complexity-utility balance is right. You know, did the- did it tip the scales? Is it too complex and too niche and it should be an extension, or the complexity is bearable with all these implementations, you know working, and the utility is seen across a broad swath of applications, not just the niche. Um, so I think that's the- I think that's what would decide the next steps. That's the end of the presentation. There's backup slides if you want to see more of the issues, but I don't think we need to go there.
Mo Zanaty: So chairs, I'll leave it up to you how you want to handle.
Magnus Westerlund: We have Victor in queue here, probably wants to ask questions, so let's go ahead Victor.
Victor Vasiliev: Uh, are we at the clarifying questions stage or just opinion stage?
Magnus Westerlund: I think we're at the general discussion stage. We're done.
Mo Zanaty: Yeah, we're done.
Magnus Westerlund: Go ahead and join the queue if you want to have.
Victor Vasiliev: Oh, okay. Uh, yeah, so uh I have two comments, one on the track selection. I think so thinking of track selection in SUBSCRIBE_NAMESPACE and like whether it should be in an extension draft or in the main thing, uh I understand the appeal of pulling it into extension draft, but now that I think about it, if I were to design SUBSCRIBE_NAMESPACE I and I would rather start by designing SUBSCRIBE_NAMESPACE with top N support than first designing SUBSCRIBE_NAMESPACE and then putting in top N support later because I suspect when building distributed systems at scale the fact that at some point you would want to support top N would be meaningful consideration, which kind of makes me lean it towards the core draft. Uh, I think single selector is probably like- I'm a huge fan of single selector as- as I said back in Toronto and I think it covers most of our use cases and I kind of see how it could help us optimizing things. Uh, now regarding the- the in-track filter, the object filters. Uh, so one thing I've been thinking about recently, so uh could you go back to the slide with use case for object filters?
Mo Zanaty: Use case?
Victor Vasiliev: Yes, use cases for we have for track and for object filters.
Mo Zanaty: Yes.
Victor Vasiliev: Uh, so there's like the thing where we switch layers. Uh, but one thing we need to think more is that like when you switch layers you kind of have this uh kind of the same problem like with joining, so imagine that you are- so switching off layers is easy. But in our current design, do I understand correctly that if we switch a layer back on it will start that layer immediately and not at the group boundary?
Mo Zanaty: Are- are you done? Is that a question you want to stop or you want to finish all your point?
Victor Vasiliev: That- that's a question I have. Do I understand correctly that they're switched immediately?
Mo Zanaty: If- if you apply a range filter it's- it's evaluated per object, yes. So if the object comes in with that- with that.
Victor Vasiliev: Yes. So one thing we might want to want to figure out is uh that like let us change filters at the group boundary because I if I like decide in the middle of the group that hey, my bandwidth is good, I should switch on extra layers of SVC, I don't want to get those truncated layers in some cases.
Mo Zanaty: Yeah, so I think what you're pointing out is- is a race condition between- and this is not specific to filters, although filters brings it out the best. There's a race condition between a FETCH_UPDATE and what the object plane, what the data plane is giving you in- in return. And we don't have anything in the object- you know, in the data plane that says "this is now in response to your new request," right?
Victor Vasiliev: Yeah. Now my example is actually not very good because I just realized that with temporal SVC you can join in the middle of subgroup, but.
Mo Zanaty: Yeah, but there's- there's GOP structures that- knowing your dependencies is not easy in SVC.
Victor Vasiliev: Yeah, there are GOP structures in there like with spatial- with dimension SVC it's different, so.
Mo Zanaty: But- but for example, if we had something like Switch, Switch is where you want to have the- the sender, the publisher determine when your group, you know switches. You could switch to the same group with a- with a filter attached, right? I mean same track, you could switch to the same track with a filter um, you know with a filter applied. Um.
Victor Vasiliev: Okay. That- that's all I wanted to say. Thank you.
Mo Zanaty: Alan.
Alan Frindell: Uh, okay. Um, are you still on use cases slide? Uh, I had one quick question because uh one of these stood out to me which was four, um, because you gave codec as an example and that is most likely a track property and not an object property. And so my- I- it's been a while since I've reread the PR but I know top N works this way, but for range filters, is it every ob- like, basically like the track property is the default for every object in that track, and a track and an individual object can override it. But there's no such thing as an object without the property?
Mo Zanaty: W- yeah that- that's true, with the exception of there's also text that says if you used a track filter- if you used a track property in the range filter, that the property filter would also filter out the publish itself. So if you hadn't received the publish yet, you wouldn't receive any objects from that track. If you had already received the publish and you later applied the filter, then only the objects would be filtered out and if you had a, you know an object that- that differed, that overrode its- its track property, then you would get that object. But if you never got the track in the first place and you- if you specified this on the subscribe itself, you would not get the track at all. You wouldn't get a SUBSCRIBE_OK because it would be filtered out and you wouldn't get a publish from it either because it's.
Alan Frindell: What- what error do I get? If I say sub- oh this is if I say subscribe and I have a filter which says codec equals something. I get track not found or?
Mo Zanaty: The real use case for this would be in SUBSCRIBE_NAMESPACE. You had a namespace with 10, you know qualities, a ladder, you know. You subscribe to YouTube video title, and in that it's the 20 property- the 20 different encodings that YouTube provides. If that was all in a namespace, you would say a property filter on encoding, a YouTube, you know custom property encoding equals this. So you would never get the publish for that. That's the core use case.
Alan Frindell: Okay. I- I get what you're saying and I get the utility of it. It's I think that- that's in there is quite subtle and I think we maybe- it may need like either more explicit test or something. Anyway, like I'll move on. I have some other things I want to mention. So one of them is you didn't talk about self-exclusion, but in the implementation like this is one of the things that causes the, you know probably double the complexity of the implementation is to be able to- I say top N, I don't really want the top three, I want the top three that are not being published by me. And that means that potentially every subscriber in the namespace has a different set of tracks they're getting if they're all publishing something that's in.
Mo Zanaty: Yes, that's right. So you have to have a top N plus one or plus number of publishes that a subscriber.
Alan Frindell: If- in the way we have implemented it in MockX is you we track the top N plus K where K is the number of tracks you have published that are in the top 10 or the top N. So it is- it- there's meaningful complexity there, but I mean you and I had many discussions about it and like I understand the utility of like that's what you want. Like you don't want your own track back, but it's like if people go and think about it it- it- I mean there's a performance complexity trade-off and I think one of the implementations kind of went with the- the simple but more expensive way to do it and we implemented it in a way that's like we think is performant and scalable but it is also meaningfully complex. So people should just think about it.
Mo Zanaty: That's right. I- I agree with you. That's why I brought up the N less than 256 limit, because I believe that if you had prompted your AIs uh with the scale of- of the problem, it may have picked different things. Like for example, you know Redis, you know for a couple hundred things is not going to create ordered sets and, you know and all those things and node-based structures. It'll give you a flat vector. So if we had a limit of less than 255, I think the data structures chosen may end up being different than a very highly scalable data structure that is intended for the millions or- or larger. Um, and I think that's where the core difference is, you know. The- some of the implementations picked things knowing that we're not going to ever ask for more than a hundred or so. And uh, and you're right, if you- if you asked for a million, you know that implementation would suck. Um, so that's where maybe we consider.
Alan Frindell: It's- it's less about N and more about the number of viewers because if like and so if you think about the case that we tried to optimize for was webinar where you have 10 speakers, I want the top three of the 10 speakers and I have a thousand viewers. So I don't want to be recomputing the top N a thousand times every time the property changes. I only want to be computing it when like because for 99 for everyone who's not publishing that list is the same. Anyway I don't want to rat hole here, I just want to let people know self-exclusion is like part of this and it's meaningful complexity or performance trade-off. You have to pick where you sit there.
Mo Zanaty: No, I- I agree. I- I don't want to discount the complexity thing. Uh, you know everyone that- that has implemented this, you know has had a- to do, you know weeks' worth of work to- to get it. It's not going to be something you code up in- five code in a day, um, you know well. Uh, but you the rough complexity, the rough size of what you'd get out of that couple weeks is going to be around 1 to 2,000 lines. Um, and uh relatively, you know reasonable performance for- for moderate sizes of, you know top 100 publishers and subscribers in the thousands. Maybe not millions, but seems kind of impractical that you'd have a- a single relay node uh with millions of publisher-subscribers directly on it. Um, that seems like there's already way too many other performance things that'll- that'll crash before this.
Alan Frindell: I- like I can talk more about it, but there's a long queue. So I just want to like quickly run through my other things. One, the way you're using forward to signal things, I think it's important to have that signal but it's a little bit awkward. Right now forward is only defined by the subscriber but you're using it on the publisher side, so we should probably just like take note of that. Um, the deselected list which was there but isn't there but is shown in your diagram that there is this like state of things that are deselected, I just assume that that is like entirely implementation dependent how you manage that. Um, and I mean I think one of the concerns I have about a number of the dimensions here is that like essentially we've given implementations an out in a bunch of different ways. It's like "Yeah, if this gets too complex for you just error," and I think that might lead to interoperability problems. So instead of saying you must be able to support this or that. So, I mean this is to say just like I'll answer the top-level question should be any surprise. I mean I think this is a totally useful feature and I think people will implement it and I hear what Victor's saying about having people plan for it will be better than retrofitting it. But I also think that the- this should be an extension and not part of the core draft.
Mo Zanaty: And just to re-emphasize Victor's point, I think Victor's point was that- they- they should phase share with- with SUBSCRIBE_NAMESPACE. Like if- if we think we need to pull the track filter out to an extension, I think Victor's saying maybe we should pull SUBSCRIBE_NAMESPACE out to the same extension because it seems like not having them together is kind of- is kind of weird and maybe even more problems uh if they're separated than if they're together.
Cullen Jennings: Um, sorry I was a lost slides here. So, I mean I was going to when people started talking about the complexity issues, the complexity issue that everybody raised was were we going to have performance problems, um, not that it was going to be a thousand lines of code. Like I think the thousand lines of code is no big deal, I think that's fine, I mean this is like, you know this is a major part. Um, so everything I've seen performance-wise seems to suggest this did not impact in performance in a meaningful way, that the performance issues remained as always the sort of crypto and the- the quick- the QUICK stuff. Um, so I think that makes me really in the fact that we have this across multiple uh of the relays, you know is a strong suggestion. One thing to sort of Alan's point about the- I do think obviously talking about exclusion is something implementers have to or self- self-exclusion is something implementers have to think about. And this was the reason why I thought that originally the design should be doing the top N like you should filter first and then do the top N selection instead of the other way around. I don't really care about which way we do that, but that would actually solve the complexity problem, right? Um, or the difficulty in that, I think would make it much easier to- to implement. Uh, and I think it's also it's much easier to implement if you think about this as what packet do I forward next, not how do I connect up these incoming tracks to these outgoing tracks? Uh, so I- you know when I looked at the code across the different implementations it was pretty, you know it's like the- the the- the how difficult it was depended on this sort of underlying metaphor that was in the- the relay. So I think there's lots of things on this. On the topic of putting it in a later and pulling it out in extension, I mean I think this is core to our fundamental use cases, so I think it should be in. But what I really hear is like what's the advantages of pulling it out? And I think the advantages people think of pulling it out is we can not work on it. We can leave it till later. Um, but that's exactly one of the reason- I like that's not a good reason to me. I think we need to like work on this now, people want to work on it, we're having in terms, we have it pretty much done. I'd rather not just reopen every one of these arguments every nine months and never finish them. I'd rather finish them. And if we're going to finish them and they're done, I think it should be in the base draft. So that's- that's where I feel still very strongly that this should just go in the base draft and that we have it pretty much worked out as it is right now. Module in and not- of course there's a bunch of issues raised of things that we should, you know flag to implementers.
Mo Zanaty: Yeah, and just to reiterate- reiterate Victor's point, I think the most likely thing if we defer it and do work on it later or separately is if we end up discovering things that need to change in SUBSCRIBE_NAMESPACE, that would be unfortunate. We discover things that oh this is wrong in SUBSCRIBE_NAMESPACE or this needs to be clarified or specified in SUBSCRIBE_NAMESPACE for things to work right. That- that's where I think separating them could cause some- some churn and problems especially if we miss the problem even before, you know we go to workgroup last call or before even RFC. That would be bad.
Will Law: Yeah, it's working. Um, so firstly there seem to be quite a few use cases here, especially the media ones where we clearly want to filter or track select at group boundaries. So it would seem simple just to add a bit flag to your message or your parameter to say "Hey, only evaluate this what I'm asking for here at group boundaries." The use case where we were switching subgroups was one that Victor raised. Another would simply be the security camera one. I can't decode the video if it switches in the middle of a group. I want it to come at my i-frame, which would be a group boundary. So that seems a small extension that would not be complex and would lower the complexity, the effort, because you wouldn't have to evaluate every single object. And just as a second call in support of it, I- I believe this- this has broad utility not just in media, but in moving non-media, in moving data. The ability to filter we can think of as- as distributed reduced, right? Take a large amount of data and my network is actually reducing it for me, and that makes MoQ particularly attractive in the marketplace for implementers. And I want MoQ to come out of the gates having advantages over existing solutions, especially something like network reduction. So I would also vote for it to be in the core spec. I think the majority of the work is done. There's no good reasons to push it out at this point.
Mo Zanaty: That's why I tried to highlight at least one non-media use case for both the range filters and the track filter, um, that there could be broad utility beyond- beyond media.
Tim Evens: Okay, is it working now? Hopefully. Okay, sorry about that. Um, okay few- few items. One on multiple properties, I would say do I need to do top N on multiple properties? No, I don't think so. But do I need to have track filters on multiple properties? Yes, I think so. And an example of that is classic tags. If I want to label tracks with metadata and tags, that would be done through a property- track extensions or properties or whatever, and I may want to select based on that. And I definitely think in- in Will's statement about non-media cases, definitely in data cases we're going to definitely want to do that. I'm going to want to filter by region, I'm going to filter by sovereignty, or I'm going to filter by different various attributes. So I want that ability and I may also want top N at the same time, so I think limiting to just one property is a mistake. So I don't think we should do that. I think we should definitely not put that limit in the core draft.
Tim Evens: Um, I think there needs to be more clarification on explicit SUBSCRIBE. So I still am unclear exactly how to handle when I get subscriptions for the same track that is already been matched and what I'm supposed to do with closing out one that came before the other. So if I had a PUBLISH that was sent because of SUBSCRIBE_NAMESPACE and I sent it already, but then the client decided to do an explicit SUBSCRIBE, how do I transition that to a permanent SUBSCRIBE? Do I need to like close out it with a PUBLISH_DONE and then follow the SUBSCRIBE handling or- I mean how do I handle that scenario? So I feel like that scenario is not really articulated. I know what we have done, but I don't think what we have done is going to be what everybody else is doing. So I think we need to have better verbiage about how to handle explicit SUBSCRIBEs, specifically when it comes in in different orders, like the scenario of when does it come in and not.
Tim Evens: I want to mirror also self-exclusion. I will say that self-exclusion initially was a little complicated and it was obviously we had to do it. It was ridiculous if we didn't do it. But the way we implemented it, it really wasn't that complicated and we were able to do it. And that is because we do a second-level filter in a per SUBSCRIBE_NAMESPACE. So we do on every subscriber of a namespace, we can easily filter out your own tracks. So for us it was actually quite easy, low-hanging fruit, very easy to filter it- filter that out. But it was required, I have to say, you definitely want to do that. Um, performance measurements. We have done a lot of performance measurements. I also was on the fence- fence, you know Alan and I have talked about this before. I was like "Oh my god, we're doing so much work in state management and blah blah blah." But at the end of the day it has shown with a small number of tracks that are being matched for a given SUBSCRIBE_NAMESPACE, um, it really isn't that big of a performance hit. So we're seeing less than a 1% overall hit with performance. In fact, in most of the flame graphs when we do all these performance measurements of like number of connections and SUBSCRIBE_NAMESPACEs meetings and all these multiple participants, um, the top N is actually not that big of a deal. It actually is pretty low. So I would say that has not really- has not materialized in such a big thing. It's more of a pain on I had to refactor my code and that was annoying and I was quite annoyed with it, but- but now that that's done it's- it's not on performance.
Tim Evens: Um, I would say that one of the big challenges that we do have and I think everybody's going to run into this problem is having to deal with the top N maintaining PUBLISHes and PUBLISH_DONE state on per SUBSCRIBE_NAMESPACE. So even if you have a consistent, you know map of- of all of the top tracks, you're still having to maintain which PUBLISHes were accepted by the subscriber because the subscriber can still say SUBSCRIBE_ERROR- PUBLISH_ERROR, it can still air out that PUBLISH and say "I don't want that PUBLISH" or it could do a Forward state zero or whatever, it could do all kinds of different things and we're maintaining that on a per SUBSCRIBE_NAMESPACE. So I would say that's where the complexity really for me was maintaining on a- I almost want to do like an umbrella like this, as I have a SUBSCRIBE_NAMESPACE with all these PUBLISHes happening there, to a per subscriber of that namespace. I have to maintain the PUBLISHes and the state of whatever that subscriber has decided to do. And that's where my complexity was and- and I do acknowledge that there's complexity there. Um, so as far as like the- where we do the, you know advertisement of the property track, you know value that we're going to watch, be it a numeric value or maybe in the future a name- a string value or some type of tag or metadata or whatever. Um, I personally don't care about per group, I know that group is a sequence of like i-frame and things like that, but we have FETCH and other things that kind of fill that gap in some cases. But what I do care about is I don't really want to inspect per object. I think per object is difficult and right now in Laps we actually do it as a more of a post-inspection, we actually do it as part of caching, so caching is inspecting it and then we still do pipeline forwarding so we don't delay the forwarding of the data, which means it's slightly delayed. But I think there's a lot of value in saying that we do inspection on subgroup because subgroup is start of stream and start of stream I have no choice but to inspect the stream, I have to inspect the stream because I have to know what track alias this belongs to. So I have a requirement anyways to inspect the start of stream. If you add in track properties, that's really not a big deal if you add in track properties on that. So I would- I would say it would be really nice to do it on a per subgroup basis or somehow negotiate that, somehow say that the inspection is going to be on subgroup, which is basically start of stream.
Mo Zanaty: Just- just a clarification. I- I think that's not filter specific either. I think what you're describing is a relay to be able to ignore everything but the subgroup header, um, and that- that would strike at the core of properties, not just filters, not just properties you're filtering on but the core of properties themselves, you want to be able to ignore by a relay other than just the start of stream header. So I think that's a bigger thing than- that should be a separate optimization outside of filters and not just construct- constrained to um, the track filter or even the range filters.
Tim Evens: Yeah, so if we could certainly- because I have to inspect the start of stream or the stream header anyways, I think it's very little for us to add extra stuff to inspect at that point. But I love pipelining. Pipelining is extremely important especially with large messages when you're sending like, you know 10 megs or 100 megs of data through one subgroup. If I can just forward that subgroup with no delay by saying I don't have to inspect anything, that's going to be far more efficient and far lower latency than if I have to stop every object and have to inspect every object. That's just, you know really not ideal in that particular case. Okay, that's all I had.
Suhas Nandakumar: Yeah, uh thanks Mo for driving this. Um, I think I'll try to address in two layers here. One is the utility. Uh, we need to drive a feature by utility. And over period of last seven months or something we have shown there is utility in using object filters where every implementation needs to do per object evaluation to see if that filter passes- if that object passes the filter or not. So either you do it at one point or a different point of the stack. We- we basically need to look at some parts of the object header. If- if there's a filter negotiated or something. So I- I think there is, for the reasons that Will pointed out, they are really good use cases. Especially when not just media when you're going to do cybersecurity events over MoQ and other things where people already considering some of these things. How do you kind of reduce the data so that you can get to the aggregators and react on top of that in real time, which none of the systems provide today? And- and MoQ has a sweet spot to kind of provide something like that with filtering mechanism. I- I am a big supporter of having filtering mechanism. Like how the subscription location filters work and does its job, having the similar filtering mechanisms like what you have decided as core transport is important. Uh, and it also over period of simulations and other things I've done it clearly shown across multiple relays when you aggregate these filters, if- if the filter was not there the amount of data that you download versus when filter is there and- and get- take it upstream the amount of data that gets reduced, it also saves bandwidth. If there's utility and also there's cost saving as well. So given that I think this should be in the core transport. On the implementation and the complexity wise, I've been intimately involved in three implementations. One is Laps, I've been- I've not implemented but reviewed quite a bit of the design and everything. And on the MockX, me and Alan have gone through overnight, like a couple of weekends and- and days to kind of get it implemented. And I also implemented this feature in- in uh, MockRS as a PR, it's not landed but it's on a PR. One thing what I realized is that it's not the- the- the PR text is unclear, it's more like- more, I think you highlighted very clearly that uh what is the thing that you are kind of trying to optimize it at this point in time? And- and I see the two things, right? One is that many of the top N has quite a bit of updates. When the updates happen, what is the data structure you need to consider versus when- when all the updates are done, now I want to kind of pick the top N, what is the data structure I need to consider? And I think your suggestion of having a single selector and a top N limit would kind of moot all those arguments to basically to- to do something that's pretty scalable because uh the one in the Cloudflare kind of amortizes your search by being linear but not bounded linear but- but at the same time kind of provide large scale on- on faster updates. On the other hand on the- on the MockX it kind of tries to optimize your query to be O(1) but huge cost on updates which is n times M kind of a cost. I think this is- this is something I personally feel that on interop day or something we can- we- we- as implementation designers we can talk about it, but I don't think so that has an- that has to do with the PR text for what the filter is and how- what's utility of this for the MoQ working group because- just- just to kind of finalize that point, interactive world will- will try to move to MoQ and this is one of the core features for many of those use cases to kind of work along with other data kind of use cases that Will and you mentioned. Um, I think this should be a core part of the MoQ transport. Thank you.
Ian Swett: Um, I'm not in a position I think at the moment to say whether it should or should not be core part of MoQ but uh, I just want to bring up all the things I think that I am either concerned about or like want the group to understand. Um, so I'm going to talk about a bunch of stuff that no one else has talked about. Uh, my first one is DDoS. Like that is absolutely my number one thing here, which is like I can require the relay to do like an unbounded amount of work and like "Oh, I'm going to make you filter through like, you know a billion objects to find like the one object I want," which I mean is useful in some sense like but it's also like an enormous, you know amplification factor or- like however you want to say- so like I mean we can put that in security considerations but I think filters definitely like amplifies the ability of one to do that and like we shouldn't take it lightly. Um.
Mo Zanaty: We tried to add this text, but I agree that this text is sort of still kind of hand-wavy and doesn't give an implementer enough concrete tools to protect themselves.
Ian Swett: Right.
Mo Zanaty: These are- these things are- are fundamentally asymmetric. So there's- you know the utility of them is not asymmetric.
Ian Swett: It's a feature and a bug. Like I'm on the same page. But it's terrifying from a- yeah from a deployer's perspective. I mean already have things where, you know someone can be like "Oh, I'm going to request like a 2 terabyte file" and, you know then I have to be sure my flow control is working well and everything, you know. So, um so I think the DDoS concerns are very real and I'm still a little bit concerned that like it's going to take us a while to like sort those out if we do put them in the core draft. That being said, I think we probably should make sure like we have ways of addressing them in the core draft regardless of if we put this in the core draft is my belief. Is like we should make sure if a thing like this happens we can address the DDoS concerns in the core draft as much as humanly possible. Um.
Mo Zanaty: I think Victor's point about SUBSCRIBE_NAMESPACE fate sharing would also apply because I think the DDoS vectors also apply to SUBSCRIBE_NAMESPACE so if you're not comfortable with those I think pulling those out, putting them together in something else would make sense, they should fate share together.
Ian Swett: Now called SUBSCRIBE_TRACKS by the way. So, let's go. Um.
Cullen Jennings: Actually, before we move on to that, let me just interrupt for a second and maybe you can say a little more on this. I mean like it seems to me that the DDoS attack is largely happens to do with how many publishers are there, not subscribers, and like we already have this problem with you could have a million subscribers that all put Forward equals No and one publisher. I'm not sure it's that much different than this. I mean any thoughts on that?
Ian Swett: I- I kind of assumed that like people would use the Forward equals 1, 0 thing like in a kind of optimistic manner and like most of the time they wouldn't actually subscribe to it but they would maintain a subscription in Forward equals zero mode in some cases and in other cases they would actually subscribe so- but yes, I think it's extraordinarily similar to the Forward zero-one conversation, um, for sure. Uh, I think the idea that two people could- one people- set of people could ask for like only the highest temperatures and only the lowest temperatures and those two things being disjoint and as a subscriber today you, you know have to kind of subscribe to everything and then filter is unfortunate but there's slides, if we get to them later, about allowing multiple subscriptions to the same track, which I think like we've discussed many times like would completely mitigate that issue. Um, so I think that's a fixable problem. I do think ABR combined with top N is really complicated. I mean I've spent a fair amount of time thinking about it and I don't think I have a clear answer. And so I think thinking about top N as a way to solve ABR is probably the wrong way of thinking about it and I think the interactions of ABR switch or otherwise with top N is extraordinarily complex and I don't know, I don't think it's a solved problem, I guess is my comment. Um, and subgroup filtering is okay, but I think when people put it forward as a way to solve the like, you know joining fetch sort of problems like I think it's kind of a bit of a janky solution to that and so like I don't- I'd rather focus on the more positive use cases of like what you pointed out Mo rather than kind of like papering over existing problems with the draft. So.
Mo Zanaty: I agree, yeah. I don't expect the subgroup filter to obviate the need for something like a reasonable rewind or a reasonable fetch.
Ian Swett: Yeah and to Victor's comment I think the- the group boundary issue is still relevant here and like I think maybe filters makes it a little more relevant because you can say like "Oh I do want to go up a quality" or like something like that. And uh, it makes it even more important that that works but um.
Mo Zanaty: Yeah, it's- and I think that maybe that's something we should consider generically. A FETCH_UPDATE may need a parameter that says "do this update on a group boundary" or something, uh, yep.
Ian Swett: No, I agree. Um, okay. That's all I had. I think the big thing I want to emphasize for the group is like we should really be careful about DDoS concerns and like there's a draft about it but I think we need to take them seriously because that's where the risk for the wider community comes, right? Like if it's just about a few thousand lines of code as much as I don't write- like writing it, like as Cullen said that's not the end of the world, um, but I think we've found that the DDoS sort of concerns can be subtle and like difficult to mitigate.
Mo Zanaty: Yeah, so if people want to drill down into the issues, the issues are in the- if you go to the PR, the patch for the PR has that repo will have all the issues um, that are talking about that PR and so you'll see the stuff about relay amplification and um and other amplification concerns. So you can review in detail and add your comments there about if you think we're missing anything, if we have a better solution to protect against things in the current text.
Cullen Jennings: Sorry, that was- I interrupted Ian. It was that same comment. I'm out of queue.
Mo Zanaty: Oh, okay. Tim.
Tim Evens: Sorry, just takes a second to switch the video and audio. Um, so I just kind of posted it as well but I would say on DDoS, I think there's a couple of key things that have changed in the spec that I think really helps with DDoS. While I'm not a huge fan of doing bi-dir streams for requests, I think it actually adds a lot of churn to have to do a lot of development changes and whatnot and refactors, but it directly does help with DDoS. And I think if we do broker out you through task threads or whatever we want to do, we have a lot of mitigation capabilities to handle observe requests. So if there's a bunch of requests coming in we can actually handle those far better than a single thread in a linear fashion handling- or in a sequential fashion handling control messages. So I think that actually by itself is a very good improvement for MoQ, so I think we are going to address it there. I do think that with top N filter, track filters, whatever, we- we should have some upper limit on how many properties we're going to monitor. But I think monitoring properties, especially start of stream is not really significant and I don't think it's going to cause a DDoS issue of any kind unless we are expected to monitor every object and unless we're expected to monitor some gigantic list of- of extensions and that is obviously ridiculous, so nobody wants to do that. So I think we have to put some limits and draw the line in the sand somewhere saying we're going to give you like 10 properties and of those 10 properties ingress, specifically ingress because that's where we're monitoring these properties, not on per subscriber. So I think it's kind of important to call out: it's not per subscriber that we're monitoring them, we're monitoring them ingress. And those subscribers influence the ingress monitoring and- and when we fill up the maximum number that we're going to monitor, we're going to have to tell the other subscribers of namespace that we can't monitor those properties anymore because we're already monitoring 10. You know whatever, and it's because of other subscribers, so that needs to be brokered and handled. But yeah. Sorry. Okay.
Mo Zanaty: Alan.
Magnus Westerlund: I want to close up the current queue and then we will ask some questions on- on where we are etc., where people's view are so.
Alan Frindell: Um, yeah just on the issues and I thank you for like we worked through a lot of these like a month or two ago. I haven't gone back and checked on what the latest status is. I don't even remember if they're all still open. It looks like clearly some have been addressed or you have like a proposed resolution so um, of maybe the question is like of these, I mean I would hope we're not bringing 17 open issues into a draft that currently has 49 non-editorial issues open.
Mo Zanaty: No, just mostly to understand the history and the discussion and the arguments. Uh, so some of them are still open like, you know your- your number 17, "do we want to have one property or not?" That's why I added it to the slide, as "do people would think it's a useful simplification or not?" So that's yeah, it's still open. Um, it's not a problem in the text, it's just a, you know "would you want this simplification or not?" Um, all the other ones should be, you know uh should pretty much be closed but, you know what I was hoping was that the- that the opener would close them based on the current PR. That- that they think that the current text actually does address their point, you know like the relay amp stuff that Ian was talking about, we added that one blurb that you know that I put up on the other slide. Is that really sufficient to close out these or there's still, you know aspects of those issues that need other text. Uh, so I'd prefer that the opener actually reviewed and closed them. I- I can rescrub through them and say, you know @ the owner and say, you know "I think this is done, do you want to close it?"
Alan Frindell: Yeah, absolutely. Like I think some almost certainly are closed although it's possible that other people in the working group who haven't been following that repo may want to go be aware of these issues. So people who are interested in this feature should go maybe scan this list and see what you think but the issues could be closed if- if the opener thinks it's- it's resolved. The other, I think we don't- I don't think we talked about it, but another potential simplification is like whether or not this is recursive. Um, so if I subscribe in namespace top N A/B, is that only things in AB or is it things in ABC, ABE? Um, and there's a difference in current implementations out there about who is actually handling the recursion and who isn't. Um, so I mean it's probably high- more high utility to have that recursion based on how MoQ works but it's just another like hinge point that.
Mo Zanaty: And by recursion you don't mean multiple SUBSCRIBE_TRACKS. You mean a single SUBSCRIBE_TRACKS but the publishers have different levels within that namespace.
Alan Frindell: Yeah, I mean when I just said that I'm referring to the second thing you said. Yes, that like there's one SUBSCRIBE_TRACKS but everyone's publishing in down a couple levels from there but they're applied to one top N. But also nested top Ns is another difference in implementations. Some support nested top Ns and some don't.
Mo Zanaty: We don't allow nested SUBSCRIBE_TRACKS anymore, right? SUBSCRIBE_TRACKS is disallowed from-
Alan Frindell: From one subscriber. But you can have two subscribers that have somebody's top N in A and somebody's top N in A/B.
Mo Zanaty: Oh, that- that's why we added that error specifically conflicting filters. If- if you look at the issue that-
Alan Frindell: Okay. See also my earlier point that like we gave people error codes, we're just going to create interoperability problems, yes.
Suhas Nandkumar: Yeah. I just wanted to bring one point that I remembered about the DDoS that while Mo- Ian and I kind of had some discussions about how we can improve the DDoS even with the current SUBSCRIBE_TRACKS filters too because they have a similar kind of DDoS. But I think the object and range filters kind of make it more obvious. Uh, and and I think at some point like how we have Magnus' PR that is taking a security considerations new view and writing that section, in the same way we need to kind of write a DDoS section that kind of talks about these things. And it'd be good- good point to kind of to gather all these things that are proper DDoS vectors and start writing things that are important.
Mo Zanaty: Yeah. I agree it should be looked at holistically. But I think Ian is right that SUBSCRIBE_TRACKS itself certainly broadens the- the attack space.
Magnus Westerlund: Yes. So let's actually see if we can get a little bit of signal into this to round what we should do with this. Um, I'm going to ask two questions because I think the main line of discussion actually been around "should we support both range filters and track filters?" It's still the kind of main dividing line.
Ian Swett: Uh, Magnus. Can I ask for one thing? Um, I think Mike English might have an implementation of this or someone on his team does and I don't think we've heard from him. Is might that be relevant? I don't know.
Magnus Westerlund: Sure. If Mike wants to contribute so. Go ahead Mike.
Ian Swett: Okay. I just want to make sure like all people who actually really knew what was going on here like got to have their input.
Mike English: Yeah no. Um, so Suhas has contributed um a- a POC on a branch. I have not evaluated that. My- my main concerns are similar to Alan's in terms of what this looks like across, you know multiple relays and across an entire network. Um, so I'm following all this, um but I don't- I don't have much to- to share back yet in terms of experience reports.
Magnus Westerlund: Thank you. So, yeah. But I do want to ask these so saying: I first want to ask the question: who would support adding range filters into the main- to the MoQ transport draft, merge it in for range filters? And then I'm going to ask the question on track filters. And then we will see how the results looks. Um as an indication of what to do going forward. Um, of course you have the question of single selector property etc. I didn't get this clear indication that that would be very decisive in these questions so.
Mo Zanaty: Just to clarify, this poll is not about the track filter. This poll is about the object range filters.
Magnus Westerlund: Um, and Suhas did you have a further comment?
Ian Swett: I- I had a question for Tim which is like: I am less familiar with all those other subsystems but I am very curious about how what we're doing relates to them and I don't know if Mike-
Tim Evens: So, yeah. I mean I know this is not related to the range but- so I come from a background of course working on a lot of message buses. I've been doing it for like over a decade, but anyhow um, it's- it's non-media related. So media is very like specific, very small set of use cases and need. But when we look at other data objects, there's a lot of variability of doing filters. And right now if you look at like Kafka as an example they have like record headers. They call them record headers. Which is pretty much the same very- very similar to object filters or object properties and track filters. It's very similar. Um, but they have those and everybody that I know of like if you ever go to KubeCon and things like that if you talk about platforms and how everybody else is doing automation and message bus and forwarding and everything else, they're all using those record headers as a way to sub-filter topics. They call them topics or- or names or subject names whatever, but they filter those because applications like metrics as an example emits to this monolithic topic. You have this gigantic topic that covers a global footprint but then you need to sub-filter those that data set. And they're using record headers for this. That's exactly how they do it. And they do it by region- they encode region information, they encode um, you know customer information to some extent like which customer is it? Should I even be looking at this data or not looking at this data? That's at that filter level. I see the SUBSCRIBE_TRACKS no different than doing a topic subscribe and if I do a topic subscribe I'm going to want to filter that. And it's not just on the name. It's going to be based off of attributes. So hopefully that clarifies it a little bit but- but I think if MoQ is ever going to go to non-media you're going to have to deal with this. Or- or we're going to have to support it. And yeah.
Magnus Westerlund: So, thank you. Um, let's close this poll and do the other. Uh as still want to do especially around top N which I think is what- even if I understand your- I think I understand what you're going for there Tim. Uh, I think the crux here is the top N part but- so I start the new poll now. People indicate how they feel about the top N compared to the previous one. Uh I will go back to the results afterwards when we try to-
Magnus Westerlund: Okay. I will give people a few more seconds to put in their positions. Hand-show hand. Still changing. Okay. Five more seconds and then I will close it.
Magnus Westerlund: So, yeah. So the result was that for the object filters there was seven yes, three nos and one no opinion. Uh which I at least could interpret as some- from this group as a kind of rough consensus to include it. Um however on the top N track filters it's seven yes, seven nos and two no opinions. Which to me indicates that yes, there's- this is not clear field yet at all so. Um. So I think what we want to do actually round this through the mailing list but I- I think what we- we might have room here to include object filters to start with and see if- and if you proponents can continue to say "Okay, can we figure out and improve the kind of proposal surround this fears or maybe the kind of worries around top N here" to see what that makes to people's opinions.
Cullen Jennings: Um so look I- I heard the- I'd like to understand from the people who don't think that we should do this. I'd just like to better understand the issues cause I don't- I don't think I fully got them in school. I got the DDoS ones and I- I think those are easily addressed though I agree not addressed yet. But I- but beyond the DDoS ones, would people speak to what specific issues they're- they're concerned about with it because I think that would make it easier to drive to conclusion on this and I'm not quite following it. If anyone wants to speak to that. Thanks.
Ian Swett: I put my hands up for something else so-
Magnus Westerlund: Okay. Yeah. So anyone who would want to comment on Cullen's question can just step in and I think it's Alan. Go ahead.
Alan Frindell: Uh I- I mean I feel like I've been relatively vocal and consistent throughout so I didn't think I needed to jump in and say again what I think. It's that um, I agree there is utility in this feature. I think it's cool. I think you can do cool stuff with it. Um, I think because of that people will implement it. Um, I think it needs probably a little bit more soak time. I think it's quite complicated and I don't want to put it in the core draft because the core draft is already quite long, difficult to understand and this is a little bit like it- the burden of understanding is like high enough that I think it will live better in its own draft. And I just want to say like it being its own draft in no way takes away from its utility or the degree to which people will implement it because there's already implementations of it. It's not even in any draft. And uh, there's also- I mean we already this group already has like seven adopted drafts. So like I don't know why we think moving it to another document is necessarily a bad thing. Um, so anyway that- that's my feeling on it.
Mo Zanaty: Just- just one clarification Alan. Do- do you think that any simplifications would make it better to merge into the core draft or do you think even with any possible simplifications you would still like to see it as an extension regardless of all the simplifications?
Alan Frindell: I- I think I would- I guess I would maybe need to see like if we reduced it to its simplest possible form I'd need to think about it. It might get me closer to yes. But like I mean in one of my worries about this feature is that we over-simplify it to get people to buy- I mean to get implementers to say "Okay, but then application developers feel too limited by what we've built and we end up with something that nobody will use." So I don't want to over-rotate on the simplification. I think we should put the features in it that it needs.
Ian Swett: Um I definitely agree with that last point. I mean that's definitely a valid a concern on my part as is like that things are like going in a good direction but like maybe not quite done-done. Um, I don't have a strong opinion either way on whether it's an extension but I guess I will say like um, for QUICK, connection migration is fairly complicated. It ended up in the core draft. It's not really clear that that was the right call but by the time we really realized probably it should have been punted, it's far too late. Um, datagrams were the opposite story. At this moment I think like every single QUICK implementation on earth implements datagrams, right? It's like of course you do. Like I don't even understand why you would not. Um, and so I don't think it living in an extension like kind of puts it in some kind of like side world at all um but I- I think my biggest concern is around like getting it well-baked and making sure it really fits the core use cases and, you know I think Tim alluded to the fact that like I don't think I fully understand the kind of what the status quo and what the best practices are in the like um kind of pub-sub filtering world uh and yeah that- that gives me a little bit of caution to putting in the core draft partially just because it's like obviously we want to do like the best thing, um but I would like to be more experienced. So.
Magnus Westerlund: We are running out of time so and now we building up the queue again. So I'll try to be short on your comment. Suhas.
Suhas Nandkumar: Yep. Uh, I think the implementation complexity has been raised multiple times. I think other than clarifying the text, the only- only issue I've heard so far is an implementation complexity and there are two implementations of this, probably three. And out of those other two implementations are more simple and easy to understand. Uh, I do not- it's not about criticizing one's implementation versus the other but just saying, you know, a implementation did something that sounded more complicated versus other did not do that. That doesn't mean one is complete and another is incomplete. I think that's the wrong way to kind of go to decide a feature. Um, and to- to be very frank even with many of the opens stacks that are out there today with MoQ, caching does not work, which is required for fetch. Uh, and and we- we do support it and we're trying to fix it for almost two years, fetch has been landed, we are fixing it because we know there's a real utility behind that. Uh, this focus on it- it's too complicated to implement for me hence we should not implement the feature seems like-
Magnus Westerlund: Suhas, now you getting bit- please wrap up.
Cullen Jennings: Um, one of the things about if we try and put this in a separate draft is we are going to spend substantial time making the base draft so it's extendable in this type of way because it's really complicated to write these types of specs where they're highly mixed in with what- how all the existing stuff is working without having them completely contradict or have to rewrite large parts of the base spec. So this is one of my concerns about splitting it apart is, you know, we will have to work through through that. It's not- it will not be trivial to split this apart. Now, that said, I don't think anyone has ever asked that this is mandatory that all relays implement. I mean everyone's always been you can set your max number of track filters to zero and not implement any of this in your relay, it's still a valid relay. Um, that's it- so, you know keep in mind that whether your relay actually supports this or not is not equivalent to is it in the base spec or not, right? Those are two separate things.
Mo Zanaty: My- my main worry if we move to another draft which, you know I honestly don't mind which- which draft it's in, but my main worry is that the reason we move it to another draft is so we can hurry up and get the core done and out. And my worry is that this is probably going to surface some things. I don't think we're done with this. Um, you know, I think this is probably going to surface some things especially in SUBSCRIBE_TRACKS. I- I think there's a good chance that it's going to surface some things, you know along with the DDoS stuff and- and general, you know subgroup gaps and all the- all the kinds of nitty-gritty things that we haven't gotten to the details of yet. I worry that it's going to surface those things and and if we do it as a separate spec that's later and then we accelerate the- the core spec and get it out as soon as we can, we're going to miss some important things in the core spec. That's my only concern about having it separately. Logically I don't see a problem with having it as a separate thing. It's, you know it- they are separate. And for the two questions, they are separable. We can easily separate the two things out of the PR into object filters only and track filters separately.
Tim Evens: So, just to kind of reiterate um, and my experience of implementing this, um I had to go through a little bit of a refactor to support the concept of track filters, not the actual track filter code itself is different. Breaking that out as a separate draft is a different thing than having the relay have a hook, a latching point to where I can implement something like this concept. So I feel like if we don't have something in the MoQ transport draft or spec that specifically says that the relay needs to support this type of filtering and- and then describe the type of filtering but don't actually describe exactly how you'd, you know what you're doing, but say that you have to have this type filtering- or track level filtering. If you don't put that in there then people are going to do what- what we did. We didn't have support of filtering per track initially and that was a refactor that I had to go through which was a lot of pain. Now that it's done it's great, but I hope everybody Greenfield who's going to develop a brand new relay is not going to have to go through that same thing as soon as a new draft comes out and says "Oh, you need to do track filters" and then it's like "What? I didn't do that with my fanout. My fanout does not have that capability" and- and I think the draft needs to somehow articulate that the fanout needs to have that capability.
Magnus Westerlund: Noted. Ian.
Ian Swett: Okay. So this is not about technical at all anymore. This is about like what are the expectations of the working group and timeline. Um and reason I ask this is like I think Alan is hoping to get all substantive issues down to zero-ish in London. I think accepting this makes that massively less likely, probably implausible, just to be realistic. Um and I want to understand how-
Magnus Westerlund: Do you mean the range filters which the working group just had rough consensus for or top N or both?
Ian Swett: I guess I was thinking both but I'm- I guess I'm not really sure where we're sitting on the top N range filters and track. I mean actually I would preferred a separate vote on the top N versus the track filter cause I think they're actually slightly separate things but that's pedantic. Um and so if we are going to punt out the end of MoQ transport because we think this is really important, are we going to have like a message as a community about like "we think draft 18 is like a good thing to implement for a while and then we're going to go work on a bunch of other like improvements that we think are material and we expect you to update you later but we think like," I don't know, it doesn't have to be draft 18, but like "is there going to be an interop message of like this is a deployable draft for like some period of time or" cause it's pretty clear the outside world sort of is getting impatient. Like I'll be honest. Um I infer that, I'm sure others infer it more than I do.
Magnus Westerlund: Yeah. I don't think we have really time to discuss that aspect today. I- I would recommend it to actually take this list. I think when I actually sent out something to the list after this meeting we will try to take this into respect about also. But uh, yeah. Thank you for the discussion here around this. We will come out with some working group mailing list request for feedback additionally and then let's see what we can take away. But yeah. Thank you for the signal we have gotten here. Alan, you wanted-
Alan Frindell: Oh wait. I did screen share instead of slides. Slides. Thank you Mo.
Alan Frindell: Okay. Um we only have four minutes to talk about joining fetch which is exactly the number of minutes I wanted. This is just trying to figure out get some input to know where we're going to go from here. Um so to my knowledge there's something like six proposals that are floating around to like fix what people complaining about joining fetch. It's getting hard to track all of them. I think this is less of a technical problem. We can do lots of things but like I don't know what if anything can achieve consensus. So this is kind of a survey. It's not a consensus call. Um we're just trying to plan what our next move is or like what PRs should we try to put in front of people. And I'm going to put these survey questions on the list, um especially since you may not have time to think deeply about them and there's only three minutes left.
Alan Frindell: Okay. So um this- the slides are going to have questions. If you have time- if you feel you have time, answer them in the chat. There's no clarifying questions, there's no discussion, there's no queue. Just do the best you can. Um if you need to go consult like you have until like next Wednesday to answer these on the list.
Alan Frindell: Okay. Question 1: Is your use case satisfied? So please answer one of the following: "I do not need joining fetch to meet my use case," "Joining fetch meets my use case in functionality and performance and is not an undue implementation hassle," "Joining fetch meets my use case in functionality and performance but is an implementation hassle," "Joining fetch meets my use case in functionality but has poor performance," "Joining fetch does not meet my use case in functionality and performance." So feel free to like start typing your answers in chat. I'm going to leave it up for like 10 more seconds and then roll to the next.
Alan Frindell: Sorry Cullen. There's no way we're not doing this.
Cullen Jennings: No I'm just going to insert this comment. I just- as I've said forever like reopening these types of discussions is what is going to cause us not to be done in 12 months from now, not- not anything else.
Alan Frindell: I couldn't agree more Cullen. The issues have been open since joining fetch came in, so we have to address them. It's not like new objections. There also actually are- okay I've got it. I'm rolling to the next slide.
Alan Frindell: Question 2, so please preface your answer with the question number from now on so we can see the difference. Are you laying in the road? Like: "One, you can live with the shape which is two control messages and past and future have different data planes and you can make any small fixes you need to ship this thing," "Two is that you cannot live with the two control messages but you can live with separate data plane," "Three: I cannot live with two control messages but you only need the unified data plane for current group and it's okay if groups before the current group have separate data plane," or "I you cannot live with two control messages and you cannot live with two different data planes."
Mo Zanaty: You expect us to grok and answer that and think about it in one minute?
Alan Frindell: No, you have until next Wednesday to reply on the list. Okay. I'm going to move to the next slide so we don't run out of time.
Alan Frindell: Okay. Uh question 3: augment or replace? Um if we make a change it "must replace joining fetch," "should replace joining fetch," "may replace joining fetch," or "must not replace joining fetch." You can- I guess you can just say augment or replace or try to make it clear like what you want to do.
Victor Vasiliev: Victor the question is- sorry I said no clarifying questions but like: is it okay if we do something to address your problem but leave joining fetch in the spec or we have if we do anything we better get rid of joining fetch completely.
Alan Frindell: Okay. Discussion of use case is going to be the same. And we're out of time so I'm just going to try to go fast. You probably can't answer this question quickly enough so maybe we'll have to take it to the list but if-