**Session Date/Time:** 10 Aug 2026 16:30

[00:00:10] **Martin Duke**: Good day, everyone. This is the first MoQ virtual interim meeting after IETF one twenty six. Good to see all of you after our little break. As always, this session is being recorded. My cochair, Magnus, is on vacation this week, so I will be running the meeting solo. This is the IETF Note Well. If for some reason you're unfamiliar with it, please, type Notewell into your favorite search engine or scan the QR code there to find out about a lot of policies associated with your participation at IETF. You're here so you've already figured out how to join a meeting in Meetecho. There's a raise hand button at the bottom of your screen that enables you to join the queue to comment. There's a separate tool for shows of hands, which, will become evident. Should we happen to do that today, we probably will not. In general, you should have your audio and video off. If you are planning to speak, give yourself about a second of latency to press unmute before you plan to speak because there is a bit of a lag. And I strongly recommend that you use a headset. If you were participating in a conversation and you are not using a headset, there's likely to be a lot of echo, and we'll have to mute you, and that is generally fairly unpleasant. So if you have one, please get it. We don't have a lot of outstanding consensus calls with each other for once. We have three more virtual interims prior to our hybrid interim, which would be in Seattle. The the details about that meeting are on the list. At some point in the next few weeks, I'm going to ask for a list of attendees, and I hope we see many of you there. This is the agenda that, Alan so hopefully put out, last week on the list. I've compressed it into just PR numbers just to make it a little easier to read, I suppose. Will is driving one of these conversations, but, basically, Alan's gonna run the meeting once I stop talking,

[00:02:32] **Cullen Jennings**: to work his to try to

[00:02:34] **Martin Duke**: resolve a bunch of mock issues. Would anyone like to bash this agenda?

[00:02:43] **Alan Frindell**: I did just notice, Cullen said he can only come for the first part. So, Cullen, if there's one of those that you think is more important or several you'd like to push to the front, we can do it that way.

[00:02:55] **Cullen Jennings**: No. Thank you for that. Whatever you think, Alan. And this this doesn't see this doesn't match the agenda that was put on the list, right, because I was trying to work through all of those. This seems different, or is this the same?

[00:03:05] **Alan Frindell**: No. Pretty sure it's the same.

[00:03:07] **Cullen Jennings**: Okay. Perfect.

[00:03:07] **Alan Frindell**: Okay. The numbers, you know, which I keep in my head readily, obviously.

[00:03:11] **Cullen Jennings**: Yeah. Yeah. I know you have those. Look. Alan, what whatever you think is the order that's to do these in. Alright. I will be here for the first half hour, and I apologize. I can't be here for the second part, and

[00:03:23] **Martin Duke**: we'll go from there. So whatever you

[00:03:24] **Cullen Jennings**: think is important to have. If

[00:03:26] **Martin Duke**: this is different from Alan's email, it's merely because of my clerical error. So with that, Alan, I'm going to hand it off to you.

[00:03:33] **Will Law**: K.

[00:03:43] **Alan Frindell**: There we go. Slides. And I didn't think about where to insert Will's issue, so I might just try to run through my deck. And if I see us running out of time, we'll pivot over to your deck, Will. Otherwise, hopefully, we'll get to it at the end. Okay. So the way that we see it, like, through these sort of four kind of, like, more, like, larger structural things and, of course, I'm setting aside auth because I'm waiting for the auth design team to come back with with design proposals there. So there's this ordering of things we need to do. So one of them is this respelling of location filters that Mo talked about in Vienna. It it's it it seems ready to go. I think it's still missing one author editor stamp. There was one open question that was asked there, which I thought I would run by folks here, which is if a subscriber asks for n groups before largest, but there is no largest because no objects have been published yet, what is the resulting filter? Is it unfiltered? Is it the next group, meaning it'll start from whatever the first object is that you get, or you defer the resolution of the filter until the first object derives and then you go and back from whatever you get.

[00:05:05] **Mo Zanaty**: Mo? Yeah. Sorry. I I updated I updated a comment here this morning. I think unfiltered is the right answer. I think none of the other answers make any sense. Deferring resolution, I think, is especially problematic and gives the wrong result to the application most of the times. So I think if we go with unfiltered, it's it's clear, it's cleaner. And I think it's really the only logical only logical choice. After this, I would I would like to mention there's two other things in the that PR that that I'd like to get closure on. But let's do it after this.

[00:05:44] **Cullen Jennings**: Yeah.

[00:05:45] **Alan Frindell**: Let let's go does anybody else have any I I tend to agree that I defer is my least favorite. Unfiltered or next group both seem fine, but I'm I'm yeah. Martin?

[00:05:56] **Martin Duke**: Not about this question. I thought I put this in my review, but maybe I didn't. Did we consciously decide to get rid of the idea that you could start a subscription at some arbitrary group in the future?

[00:06:08] **Alan Frindell**: I think Moe replied to your comment, and it's still possible. You can still

[00:06:12] **Martin Duke**: Because you would just do five zero or something.

[00:06:14] **Alan Frindell**: You just give an absolute start location in the

[00:06:16] **Martin Duke**: future. Okay.

[00:06:17] **Cullen Jennings**: Yeah. Alright. There was Sorry.

[00:06:18] **Alan Frindell**: We've never or I I don't if never is quite right, but, like, certainly since, like, draft two or something, there's not been a way to say relative n in the future. Like, start with three groups in the future. We've not had that for a very long time, and we still do not. I'll just say one thing that I I think everyone who worked on this PR had the same vibe, which is the spelling of is it largest what is currently called largest object is a little weird. You specify zero start group zero, start object zero, and that is, like, the special encoding that means whatever largest object is. Nobody can think of anything better because it seems confusing. And if you really wanted to start at zero zero, you're just that's the same as unfiltered. So you that's just a everyone will probably hit that gotcha. Moe?

[00:07:07] **Mo Zanaty**: Yeah. I agree. I hate that too. And I I think I have a plan to remove it, but it'll it'll depend on how people feel about is joining fetch really the only reason we ever had that largest object filter. And if people can come up with concrete use cases for it outside of joining fetch, I'd like to hear them. If not, then I think we have a good a good solution to get rid of it completely.

[00:07:32] **Alan Frindell**: You mean, like, as part of fill fetch?

[00:07:35] **Mo Zanaty**: Yes.

[00:07:36] **Alan Frindell**: Okay. Yes. Martin?

[00:07:39] **Martin Duke**: Two comments. One that was again, I don't have a use case, as I say, like, every meeting, basically. But my understanding was that was for audio that you might have groups that are aligned with the video rather than any sort of actual dependency. And so you but the audio objects are actually independent, so you might as well get audio from the first object

[00:08:03] **Cullen Jennings**: regardless.

[00:08:08] **Martin Duke**: The other thing I

[00:08:09] **Mo Zanaty**: wanna largest object does. Largest object would prevent you getting things, from the from the past. Prevent you getting out of order things. That's what Largest Object does. It prevents out of order Yeah.

[00:08:24] **Martin Duke**: That's transcription.

[00:08:26] **Alan Frindell**: So maybe what you want in that case for the B-frame case is just unfiltered. Like, anything that shows up is fine with

[00:08:31] **Suhas Nandakumar**: Yeah.

[00:08:31] **Martin Duke**: I mean, that might work. It's probably fine. The other thing I'll say is just that I mean, I agree that it's this PR is just kinda clever about encoding. It kinda compresses everything so you don't have weird edge cases and all that, but it's, like, sort of clever in a bad way, and it is very, like, nonintuitive that adding object ID just makes it a complete that completely changes the semantics of this. But I think it's like, the the way to not do that is to have, like, different filters that mean different things, but then you have all these weird overlap cases. So I I'm kind of happy with this bizarre encoding we have, even though it's, like I said, intent like, intensely nonintuitive.

[00:09:14] **Alan Frindell**: It's not like HTTP one one where you're gonna be typing it into a terminal. Like, you're gonna be interacting with this wire protocol through some library that serializes it for you, and, hopefully, said library gives you an API that is simple to express what you want, and it handles the compression for you. So I'm I'm I don't love it, but I'm okay with it. Cullen?

[00:09:38] **Cullen Jennings**: I mean, I this is not on a place where we worry about compression in the slightest. Like, I mean, we should just make something that's clear and easy for implementers to understand. Like, it's not, like

[00:09:47] **Alan Frindell**: I I think the vibe is that everyone who's looked at it feels like it's, you know, it's, like, four steps forward and this one step back, and everyone's just sort of willing to take that trade off.

[00:09:56] **Cullen Jennings**: I can definitely live with this as it is, so let me leave it at that. Okay. Yeah. I I I I do wanna

[00:10:01] **Martin Duke**: say it's not mostly about compression. It's mostly about the fact that they're, like the the the semantically clear thing is you just have separate filter types, then you have all sorts of weird error cases with overlaps and, like, things doing different things. So, like, I think that is, like, the compelling reason to do it this way. Compression is is a nice, like, secondary reason.

[00:10:19] **Alan Frindell**: Yeah.

[00:10:21] **Cullen Jennings**: Yeah. I find Martin's comment compelling.

[00:10:23] **Alan Frindell**: Okay. I'm gonna go ahead and so I I I see only comments were unfiltered. So we'll answer that question unfiltered. Moe, you wanna bring up your other two comments here?

[00:10:31] **Mo Zanaty**: Yeah. So first of all, Martin, there were some things that were overly clever that I think need to be spelled out more clearly. The unfiltered case, I don't I don't believe people when was this was written, that wasn't a conscious thought about what happens in unfiltered cases. But the comments have have led us to the point where unfiltered is allowed on fetch, and that means fetch from the very first object all the way to largest object. And and now Ian is also suggesting that even in a joining fetch, you can leave no parameter and that would also be unfiltered, which would mean the same thing. Start from the very beginning of the track and go up the largest object. So that's kind of where

[00:11:11] **Cullen Jennings**: we are right now. I'm gonna

[00:11:12] **Mo Zanaty**: make sure everybody's on the same page with that. I haven't made the clarifications to say that. The the the description already does this, but there needs to be some clarifications to say, in this unfolded case, this is what you get for both fetch and joining fetch.

[00:11:29] **Alan Frindell**: My we I think we talked about that in the editors meeting, and so I think Ian and I and Suhas, I think I mean, it all seemed like a fine res like, it's at least consistent, which is, like, if you happen to joining fetch and you don't specify a filter, it meant you wanted to joining fetch from the beginning. And that's, like, that's if that's how we're spelling fetch, that's how we should spell joining fetch.

[00:11:51] **Mo Zanaty**: Okay. That's that's the only substantive open issue. The only only one that's a and minor editorial thing that I can close off with Suhas, the, you know, n greater than zero thing. That's just editorial. It shouldn't it doesn't impact anything.

[00:12:03] **Alan Frindell**: Yeah. Okay. I'll move on. So the publish notify message, again, we talked about it in Vienna. This is it doesn't have a use in the current draft, but there's the things that are coming after it want to use it, so we sort of need to to sequence it here. And it makes it's a little odd because when you read it in the PR, you're like, what why would I send this? And there's not a reason yet, but that will get clarified as we merge it into the following two PRs. I know Cullen had a comment about what do what do relays do when they get this, and I just added a sentence to the PR, which is like, this is an informative message and no reaction is required. It is purely designed to inform the subscriber that something that they asked to happen has happened. So it shouldn't ever be a surprise to the receiver that they get it, and hopefully, the PR is now clear on that point.

[00:12:55] **Cullen Jennings**: That works for me. Thanks.

[00:12:57] **Alan Frindell**: Okay. So once those two land, we do need to make updates to fill fetch and switch from to, like, use both of these new semantics or the these new structures. I do have some open questions on fill fetch that aren't related that I'll go through on the next slide. Mo?

[00:13:16] **Mo Zanaty**: Just to mention, Track Flows also intends to switch to using this instead of the request updates.

[00:13:23] **Alan Frindell**: Publish and notify. Yeah. I figured. Yeah. Cool. Martin?

[00:13:32] **Martin Duke**: So I maybe I'm not thinking about this. I haven't thought about this enough, but, like, presumably, there's some action which was to take on this informative message.

[00:13:45] **Alan Frindell**: Not in this like, not as a at the MoQT layer, no. Right? If there was an action that we wanted the MoQT layer to take, we would send request update, and you could send an okay or an error. But this is just like for example, if you think about switch from, this message is gonna be used to tell you when the like, when the old track is done or when the or something like that where it's just like, hey. You asked me to switch from this thing, and I just set forward forward zero. Like, you're not gonna get anymore now.

[00:14:22] **Martin Duke**: Okay. So I guess that up so how would be internally, like, updating state that

[00:14:33] **Alan Frindell**: It might be useful to surface it to the application. Right? Like or it's possible that you could update. I don't know what state you have in your receiver. I haven't thought deeply about it. I think it'll shake out an implementation a little bit, like, if we need to add more text around here for for what you need to do, but I think it's I think it's more likely an an application signal.

[00:14:59] **Martin Duke**: I don't know. Like, I I it seems a little it's not clear to me that, like, the criteria that make us decide that this doesn't need a request update. Like, I think of published namespace, for instance, where we allow a a which is, to me, purely informative, but doesn't but we have this, like, request okay thing. But I don't know. May maybe

[00:15:31] **Alan Frindell**: not You would okay. If you okay. I I think there's a diff like, I think published namespace is something where, like, your auth could be bad, and I wanna reject that and be like, no. You you didn't do it

[00:15:41] **Suhas Nandakumar**: right now.

[00:15:42] **Alan Frindell**: This is strictly for things where, like, these are normally in your control. You deferred control to me, the publisher, to make a change. I'm telling you that I did it.

[00:15:53] **Martin Duke**: Okay. Alright. Thanks. Okay.

[00:15:56] **Alan Frindell**: Okay. Okay. Things that are open in the fill fetch PR. I tried to go through what the comments were there. There's some threads which have petered out, but there's still important discussion going. So I tried to poke the people who started those conversations to reengage there so we can get closure. So one of them is that it seems like where we're gonna go once location filters merges in is we're gonna completely separate. There'll be, like, a totally different location filter for subscribe and for the fill part. I think the fill will probably inherit the one from subscribe if you don't override it or something. It will have to sort of wait. But by letting them be totally independent, you can now they'll be they could be disjoint and totally nonsensical. Like, the original intention of fill fetch was, like, I wanna make join simple so you only get to specify one filter, but then everyone has sort of said, no. They want it to be separate. So that's the way it's going. If anybody wants to object to that, you can say, like, no. No. No. You should only allow one filter that covers both subscribe and fill. Okay. Did not is there a use case for disjoint filters? No. I don't think so. Well, no. That's not true. Somebody had a somebody I forget what the thread was in the PR that stated it. Someone wanted to do a particular thing that wasn't exactly possible. I think it had to do with preventing an object coming in both the fetch stream and the subscribe stream, a late object. So now you can best you can say the fill ends at largest object and the filter starts before it. Ian says, don't like the complexity, so it might be worth going through the use cases. Martin?

[00:17:53] **Cullen Jennings**: Yeah. I mean, like, the

[00:17:53] **Martin Duke**: whole thing with the nesting filters and all that is it is it is really pretty baroque. And there's always there's so many ways to do things already in this protocol. I would love to close off some avenues if there's really nothing compelling here. I get maybe I didn't follow the thing you did propose. It seems like pretty clearly anything before largest object goes in the fetch and, like, anything after largest object goes in the subscribe, at least to me. But I I I guess other people opinions, maybe they have use cases.

[00:18:29] **Alan Frindell**: I can try to explain it real like, the way the the way the seventeen sixty three is currently written, sixteen seventy three, it says you give one filter, one range. It splits on largest object, but it also sets the subscribe filter. So if an old object comes, it matches the subscribe filter, but it may also if you didn't if you had a nonzero fill timeout, you might also get that on your fetch stream as well. So and people do not like that. And that was a sort of regression relative to what joining fetch provided. And I think if you look at if we make this one change, I think what we have done is we have taken joining fetch and exactly replicated it as a parameter on the subscription, which seems to be what the feedback of the working group has massaged this idea over time, and that's where it has landed. And I think there's trade offs there, but I'm you know, if people think it's a win better than what we currently have, then we should do it. Cullen?

[00:19:33] **Cullen Jennings**: I I do think that it's important to just keep that use case where you there's this rare this rare edge case where you can get the objects objects twice. I can go into more details why, but I don't think it really matters. You just you end up with delaying things if you don't do that. But I think the use case for having two different filters that would that I remember being brought up is if you want to do if subscribing forward, you wanna subscribe to the high resolution stream or or yeah. But that's like in a similar in sorry. In in a scalable video codec, you know, you wanna have the base stream plus the high stream. But in the fill on the back, because you're unlikely to go back and you're just trying to fill a low quality buffer on on the possibility, you might need to go back. On that one, you might be willing to accept a fill with only the base stream or the low resolution stream, where going on the subscribe, you want the high resolution stream. Right? So that's a case where you you need separate filters for the two.

[00:20:24] **Martin Duke**: Right? My

[00:20:25] **Alan Frindell**: Sorry. I'm using the word filter here, and I mean location filters.

[00:20:28] **Suhas Nandakumar**: You just mean

[00:20:29] **Alan Frindell**: the location range filters, and I think that we need to also update this PR now that range filters have landed, but I would imagine that you could specify different range filters on the subscribe and fill always. Like, that seems like because you're exactly your Okay. I I I think if people have more thoughts about reasons why we you want you'd I guess Ian's maybe comment is one, but I know he can't really really comment because he's driving. I think we're gonna once the other PRs merge, we're gonna at least write a version of this PR that has two filters and the two location filters and see how we feel about it. Second one is, do we need the invalid range error code anymore? Now that and this intersects some with one, as the PR is currently spelled, there are no there's no way to say the current reason we send invalid range is if you subs if you send a subscription and it's everything in your subscribed filter is entirely before largest object, we currently say you return valid range. So but now we basically say that the ranges are now everything you send and subscribe is valid. There's no invalid range. So the PR removed this code. And so there was also this very vague text in there that said you could also the publisher can send it if it cannot satisfy the requested filter, which is quite vague. The question is, do we do we need to keep this code so that we don't remove this this vague requirement? I'm inclined to remove it and just say, like, there's invalid ranges in what you want. There may be some other reason why you wanna fail a request, but this is not it. See plus one from Martin. Cullen says if live location is two and I ask to go back five, it's not an error you get from start. That's correct. That's in Moe's PR actually, which basically says if it clamps to zero if you try to go back too far. Moe?

[00:22:40] **Mo Zanaty**: Yeah. So I I agree with this. Let let's remove the possibility of invalidity. And the the approach we took with location filters was what is the logical thing the app is trying to do? What things are broken? That the app is doing something broken, and that's when we should signal an error. But what things are legitimate things the app could do? And asking to start five back when you don't know the head at all is a legitimate thing to do. There's no reason why the app is broken doing that. So we just clamp down when when the when the publisher resolves that, says, well, no, sorry, you know, there's I can't go back five. You're gonna start at, you know, at the very beginning at two. So I think that makes sense to do wherever an intent from the app is not broken. Let's not have errors for it. Let's just do the right thing and specify what the behavior is. And if that removes invalid range, I'm all for it.

[00:23:30] **Suhas Nandakumar**: Okay. And just clarification question. So when you said for Cullen's question, it it gets from the start start of group two or group five?

[00:23:40] **Alan Frindell**: If you ask for two if you say if you if you say current minus five and current is less than five, you're gonna get start from zero zero.

[00:23:50] **Suhas Nandakumar**: Okay. Yeah. Got it. Thanks.

[00:23:53] **Alan Frindell**: I think to Moe's point, that's clearly what the app would've wanted rather than an error. Okay. For the AI minute taker, we're going to remove invalid range. Okay. If ins if subscribe end is entirely before largest, the subscription stays open. I'm very I'm I'm pretty sure that we discussed this in London, and that was our outcome, but people reviewing the PRs had mixed feelings about it. So I'm bringing you up here again. So the reason for this is if you send a subscription and it happens to be with with an end and that's before largest, you can still there's two reasons why it might be valid. One is you can send a request update and change your filter. The other one is groups and objects can be out of order. The publisher could be publishing backwards, and largest object is descending from the publisher's view, and you would miss that. So I still think the right behavior is, like, the subscription stays open until the subscriber either the track even it says when the track ends, the publisher is allowed to keep it open for a while in case the subscriber says that's an that's sort of a should, not a must. But it also says that, like, if it there's a way to end a subscription is to unsubscribe. Moe?

[00:25:07] **Mo Zanaty**: There's a related PR to remove the error from publish done about subscription ended. So I guess at some point, somebody thought it was a good idea to when your filter location range ended, do a publish done. And we decided, no, that's that's not our that's not the right behavior. Only the subscriber should be able to to end things if it's filter based. So no location filter ever impacts a publish done. Publish done is only if the publisher actually ends the entire track.

[00:25:41] **Alan Frindell**: Right. Okay. Which means if I if I send a subscribe for, like, ten ten to twenty twenty and largest object is 30, you'll just get a subscribe okay, largest object 30, and nothing is flowing probably. And you can decide what to do. You can unsubscribe. You can update your filter. You can do whatever you want. Okay. Does anybody object? I see a plus one in the chat. Okay. For the AI minute taker, we are going to keep the subscription open. Okay. There's some text in there about what happens when forward state is zero. It says, if you specify a fill filter when forward state is zero, you get no fill fetch stream. And if you transition your forward state to one and you don't specify a fill filter, that also does not open a fill fetch stream. I think this intersects with one. And so I think since if we have if the filters are totally independent, it means that the first sentence is wrong and needs to be removed. You could because you can subscribe with forward state zero and attach a fill fetch with a specific range, and that is a valid thing to say. It also means that the second sentence is true. I can change the forward state on my subscription, but that would never open a fill fetch unless I included a fill fetch, like, parameter block and a filter for it, which is like, I would also like you to go get this as a fill fetch. Cullen?

[00:27:11] **Cullen Jennings**: What you're saying there makes makes total sense of this, but I'm just wondering. If we end up with things like the switch tracking stuff where so so, like, my knee jerk reaction is sort of what you said. Like, you know, if the client didn't want, you know, didn't wanna get the fill fetch, it shouldn't have asked for the fill fetch. Right? But if we're using, if it's not the client or the subscriber that's going to cause the the forward equals zero to get thing, it's some sort of, you know, switching mechanism that's gonna caught catch it. What the client might be trying to express here is if you ever start forwarding me this track, at that point in time, you need to figure out what the start point is, and you need to do an appropriate fill fetch for me, like minus one on that. So it wouldn't even be the time this was accepted. It would need to be based on the time that the switch happened. I look. I'm not arguing that one way or another, but there's two very different designs we could have here. And I think we need to think about what use cases we want to to to solve with this.

[00:28:13] **Alan Frindell**: Does that can both of those make sense? What you're saying makes a lot of sense. And I think when I went through this the first time, I realized that subscribed tracks where it you know, in top end in particular where it's the publisher suddenly sees like, oh, this thing matches you. I'm gonna start sending it to you is not useful if it's in the middle of a group often, and so you might wanna have a way and subscribe tracks or top end to say, when you start forwarding me a track, I need you to fill fetch it from the beginning, or I think same with Switch. And so but I

[00:28:45] **Cullen Jennings**: That's that's what I'm proposing here.

[00:28:48] **Alan Frindell**: I think we still want that to be somehow I don't think we need to address that in this PR because it doesn't define that. Right? We can define that in those PRs when they say like, they express what the fill fetch semantics are when you get one and when you don't, but I don't think it's tied to the forward state. And Ian raised a point that there's a PR open that removes the whole concept of forward and just replaces it with a filter, which you should go read and see if you like it, and there's a slide later. So that may make this somewhat moot.

[00:29:19] **Cullen Jennings**: Well, I I do think I mean, we could leave this as undefined in this PR. Let's say, like, it doesn't cover what's happened. A later PR is going to cover this or something. But I think that putting in something that's, like, the wrong answer for what we intend to put on, like and then fix it in something else just seems like sort of the

[00:29:36] **Alan Frindell**: wrong We definitely shouldn't write anything wrong in this PR. Agree. Yeah. I think maybe removing both sentences does no harm.

[00:29:42] **Cullen Jennings**: Like I mean, you could even just list as an open issue that's expected to be resolved later or whatever, like, just so implementers aren't confused. Right? That this

[00:29:48] **Suhas Nandakumar**: is Yeah.

[00:29:49] **Alan Frindell**: I I think if we if we remove the first sentence and keep the last, I think it's basically the same as not saying anything, which is, like, you'll get one when you ask for one, which is sort of what you would expect. Okay. Okay. So AI minute taker, think about how this intersects with later PRs and potentially remove both sentences and replace with a to do. Okay. Fill failure. At the seven six meeting, we talked about this, but it was raised again on the PR. So we agreed in so on in the seven six meeting that reset stream is an okay mechanism to signal that a a failure that that that a fill has failed. Are we still okay with that? I think there might have been some concerns about is that as as expressive as what you can. And I think we can just if there's there was a question about, like, what are the reasons a fill can fail? I sort of said people who have implemented relays that implement fetch can tell you why it can fail because they can go look at their if conditions. So if somebody finds one and wants to express something we can't draft, we can add that reset code to make sure that it's as expressive as we need it to be. So just checking in here that it's okay to to move forward with this as it's written in the PR.

[00:31:20] **Cullen Jennings**: I know what you're saying makes sense. It does just leave me a very uneasy that, like, why don't we just go look at all the things Fetch can do and make sure that we've got them covered as a starting point anyway?

[00:31:28] **Alan Frindell**: Well, I think it comes down to, like, what we can write looking at the draft and what you can write when you look at the an implementation. Like, the implementation is gonna be much richer because you're gonna hit all the things. You're like, oh, I couldn't get an upstream connection. Oh, the guy timed out. Like, whatever it is. Like, there's only so much we can do building sandcastles in the air here. Yeah.

[00:31:49] **Cullen Jennings**: But we have some that we know that are in the spec from fetch today. So we can I mean, I like, I I agree with you that when we implement it, we'll there'll be more? But it does seem to me like like time out, off credentials, all of those things are well known ones. Right? So

[00:32:03] **Alan Frindell**: And they all exist today. Like, those those are all expressible in the reset codes we have today. Suhas?

[00:32:11] **Suhas Nandakumar**: Just to be clear, the reason why we are depending on the research stream is because we cannot signal the fail fill fetch error separately.

[00:32:19] **Alan Frindell**: There's no separate request, okay, for a fill fetch. That's in the current

[00:32:23] **Cullen Jennings**: Okay.

[00:32:24] **Suhas Nandakumar**: And I and and and do do we not consider if a a subscriber is asking with the fill fetch, if the fetch fails, does even subscriber should subscription should also fail? Like, why would now like, I'm just trying to think, why would an app application want to specify that you it want to fill and be okay if everything fails?

[00:32:46] **Alan Frindell**: So today, joining fetch, they're totally separate. Right? Like, you're joining fetch can fail, your and subs that does not affect your subscribe in any way. And so in a way, like, because the the high level thesis that has emerged here is, like, just keep it like joining fetches and let things fail independently. We could tie them together if people wanna but I have a feeling someone else is gonna say the exact opposite, which is, like, let them be independent.

[00:33:12] **Suhas Nandakumar**: Right. I'm I'm I'm I'm just trying to say because at least in joining fetch, you knew 100 reasons why it failed because we had a fetch error for joining fetch. We are losing that degree of clarity or granularity of why things fail with because research stream just says I'm risk it's in the stream. Right? It's not

[00:33:28] **Alan Frindell**: Well, research stream has an error code, and those error codes are as rich as can be as rich as request okay request error is and should be already, I think.

[00:33:36] **Suhas Nandakumar**: Then are are we mapping the fetch errors to those those research stream codes is is the question.

[00:33:41] **Will Law**: Are we are

[00:33:41] **Alan Frindell**: we missing something? We can double check that none are lost. I think I did at one point. I don't think any are. And and like I said, we can add more. If somebody finds a reason that we don't have, let's just add it.

[00:33:50] **Suhas Nandakumar**: And, yeah, and also map the existing error codes to that as well.

[00:33:55] **Alan Frindell**: You you do lose a couple of things that are in request error that are more expressive. One of them is retry after. One of them is the ability to redirect. But I think those are also more likely like, if that's really what you wanted to say, you can say it on the subscribe.

[00:34:16] **Suhas Nandakumar**: Right. I'm just thinking, like, should we use something like the publish notify mechanism in here too?

[00:34:26] **Alan Frindell**: I don't know how exactly that

[00:34:27] **Cullen Jennings**: would work, but we can talk about it.

[00:34:29] **Suhas Nandakumar**: Yeah. Yeah. Sure. Yeah. Makes sense.

[00:34:32] **Alan Frindell**: Okay. Ian? Ian, you're you're muted if you're trying to talk. Okay. Ian left the queue. Okay. I I'm gonna persist. So AI minute taker, like, I'm gonna double check that we didn't lose any there's no fetch there's no codes you can reply to a fetch with that aren't also expressible as a reset stream error code in the current PR. Okay. The last one that's open is changing a subscriber priority changes the sub priority for all fill fetch streams I mean, or none of them. It's not expressed in this was a question Ian raised. So this is something we lose. And when you have joining fetch, you can for a long time, we didn't even say you could reprioritize a fetch, but we sort of got it for free when we did something. I forget what. Request update maybe. So you now you can reprioritize fetches independently, but your fill fetches, you cannot change the subscriber priority of them after you start them without because you can't request update a fill fetch. So I guess the question is we could we could say if you request update to subscribe, it's priority, it changes all the fill fetch priorities, or it changes none of them. Maybe none of them is better since you could have expressed a subscription priority at that time that was different?

[00:36:23] **Mo Zanaty**: Moe? Can you remind me what what parameters are allowed to be overridden and fill parameters? It a subscriber priority is obviously not one of them. It is. It is one of them.

[00:36:37] **Alan Frindell**: Yes. So when you subscribe and or request update and attach a fill fetch, you can give it a different subscribe priority. But if later you wanna change it, you there's no mechanism to do it.

[00:36:47] **Mo Zanaty**: Right. Yeah. I I think that's the right I think that's don't see how it I don't see how implicitly changing it by the subscribe priority is any better.

[00:36:57] **Alan Frindell**: I agree.

[00:36:58] **Mo Zanaty**: I don't think that's a good change at all. And the second thing is, do we allow auth to be different? Can the auth be different on the parameter? Okay.

[00:37:06] **Alan Frindell**: Yes. I don't know that people are expecting fetches to last so long that you need to request update your fetch auth token. Like, I mean, HTTP doesn't work like that. Like, you ask for, like, a giant object that takes you an hour to download, nobody reevaluates your auth token halfway through to make sure it's still valid.

[00:37:26] **Mo Zanaty**: Yeah. Anyway, I don't I don't think this matters because you can always cancel. If you don't like something about the fetch that's ongoing, you can always cancel that fetch into a new fetch with the new parameters that you want. Right? So I don't think I don't think we should bend over backwards trying to modify a fetch that can easily be canceled.

[00:37:41] **Alan Frindell**: Okay. Yes. I I I think I agree. Okay. So AI minute taker, if the subscribe priority changes, it only changes the subscription. It does not change the priority for any ongoing fill fetch. Okay. That's does anybody else have other things that they had on there that I didn't bring here that they wanna talk to us?

[00:38:00] **Suhas Nandakumar**: Just one one question on what Mo said, and we concluded. Mo said that we can cancel the fill fetch independently. How can we do that today?

[00:38:08] **Alan Frindell**: Send to stop sending.

[00:38:10] **Suhas Nandakumar**: Oh, okay. You got it. We're not doing the fetch cancel or anything. Just just stop sending. Okay.

[00:38:16] **Alan Frindell**: There there is no fetch cancel in the draft anymore. Yeah.

[00:38:18] **Suhas Nandakumar**: Yeah. Makes sense.

[00:38:19] **Alan Frindell**: Thanks. Okay. Okay. Fun times. Let's see. Publish contains subscription params. We talked about this in Vienna. The publisher now includes subscription parameters in publish. It's either copied from what was in this relevant subscribe tracks, or if it was an unsolicited publish, say, like, a client publisher, it just puts in whatever defaults it's using. I think I forget who's hasn't stamped it. It's probably Suhas or Victor. Otherwise, I think this one's ready to go. I don't know if anybody wants to comment on it. K. How are doing on time? I wanna make sure we leave time for Will. I might run through this one and then hand it to Will. Publisher default priority update. So we've been talking about this for a while. Michal was kind enough to write a PR. I'm trying to summarize it here. So, Michal, if I get it wrong, let me know. So the proposal is this. We take the default publisher priority property, and we change it back to a parameter, which it was up through draft 15, I think. And then you allow the publisher to send a request update that changes this parameter, and it will receive an okay. What and you can use that as an ACK to know when the other side has received it. An object that has an explicit priority in the data plane always overrides this default. So you would always use that explicit. An object that does not have ex explicit priority, which is relying on the default for the receiver to interpret its priority, it uses the one that was in effect when the object is received. So and there's an example on the next slide. So if the same object happens to be received twice and it has two different priorities, the PR has changed it. So this is no longer a malformed condition. It just can happen, and it's not the end of the world. It just says, use the higher priority, e g the lower number of the two that you got and move on with your life. The PR doesn't say anything about how this should be used through a relay, And so that's an open question. Like, if a, like, if a relay gets a publish and then it sends a publish down, we we could say may or should or must use the same default. Should seems like I mean, it seems like you probably ought to, but if there's some really good reason you don't want to, I guess, it it it's not the end of the world if you don't. Different hops can use different defaults. It's just this is only a compression feature. It doesn't it's not changing semantics. So let me pause on that question. Did anybody have thoughts on and that goes for both when it's in a publish and when it's in a request update. Does anybody have any thoughts? Martin?

[00:41:10] **Martin Duke**: This seems really racy. Like, how Well,

[00:41:12] **Alan Frindell**: it's totally racy. I'll get to it on the next slide.

[00:41:15] **Cullen Jennings**: Okay.

[00:41:21] **Alan Frindell**: Maybe that was Suhas's question too. Alright. Maybe go let me go through the the next slide, and then we can come back to that question. Okay. So here's an example. So a publisher sends a publish with a default priority of a 100, then it sends an object with no priority. So it's implicitly a 100 from the publisher's perspective. Then the publisher sends a request update to send change the default priority to 200. So if those two messages get reordered at the receiver, the receiver's gonna get the priority wrong from the publisher's perspective. But the publisher knows now at least that it's got a request update in flight, so it should be ex including explicit priorities until it gets the ACK, until it gets the okay. Then it knows that the receiver has the new default, and so then it can start omitting them again. So the the racy bit is on the ones that you sent before you knew you wanted without a priority before you knew you wanted to change it. I did think of a way that we could get rid of this ambiguity, which is that when you change it, you include largest object. And then the sender knows if they are sending an object smaller than largest object. But after they sent the request update, then it has to explicitly encode the priority. And then the receiver knows that any object that it gets that's smaller than largest and it doesn't have a priority should be done with the old one. There's two things I don't love about it. One is that it's a little odd to put largest objects in request update, but I can live with it. The other one is that it requires the sender and receiver to maintain potentially unlimited history because you need to know, like, if I say if I change the priority many times, you need to know where this object fit in the history of these things in order to know whether you have to include it as priority or not. Or maybe you always do. Martin?

[00:43:11] **Martin Duke**: Two things. So, like, I don't think the sender has to maintain history because you can always have a cutoff where you always explicitly send the priority. Sure. If you if you don't wanna if you wanna clear out state. I think the I think you're right. The receiver's kinda stuck. The other thing is I don't understand why this is a request update instead of a publish notify.

[00:43:31] **Alan Frindell**: The okay. So it's published the only reason is because the ACK is useful in this case.

[00:43:35] **Martin Duke**: How?

[00:43:37] **Alan Frindell**: The publisher knows the receiver has the update, and it's okay. It's safe to start omitting the priority again. Although if we switch the largest object scheme, it's possible that we could make it a publish notify?

[00:43:56] **Martin Duke**: Oh, no. Because then you get the stuff before, and it's and it's

[00:44:01] **Alan Frindell**: mean, the other the other option is we just it's a little racy, and it's just priority, which is kinda best effort and only does anything if there happens to be congestion and, like, la la la. Like

[00:44:11] **Martin Duke**: Well, I mean, I I

[00:44:12] **Cullen Jennings**: think the concern is this

[00:44:13] **Martin Duke**: is supposed to be well, I guess maybe it's not an immutable thing anymore. This seems like a lot. I I don't know. I don't I don't like it. I don't

[00:44:28] **Alan Frindell**: but You'd be more specific about what you you think we should leave it as is, which is this is a compression feature and you can never change the default is what you wanna keep?

[00:44:39] **Martin Duke**: I think that's a lot cleaner. Like, I I I don't know that saving the bit the the byte is, per object for a edge case where we have a change in the default priority is, compelling to introduce all of this stuff. But, I mean, it's a personal opinion as individuals and implementer who has to deal with it and doesn't really care about this case. Thanks.

[00:45:03] **Alan Frindell**: Yeah. Suhas?

[00:45:05] **Suhas Nandakumar**: Yep. I I I think, any sender who is trying to change the priority of a track for for any valid reason, they they know for for a bit there will be, some changes. And and that that's true even if you're trying to do end to end encryption keys. Say someone leaves the group, then you need to rekey. And for a while, you encrypt with old, and then you start encrypting with a new key. Given that, you know, it it it any any mechanism we try to put on the signaling or or end to end system, it's always becomes more complicated towards the end to make sure that everyone got the thing at the right time. So rather than the the typical things we do is that we repeat some of those things. For for a while, we remove the compression, you know, properties that we get, but but we include the priorities multiple times, say, for for one full group. And then after that point, we can once you got a okay, we'll show that even if even if not okay is not there. Right? If one group, we can keep doing that. It kind of shows that the information is spread across in the system so that people the receivers can act as expected. Anything more we try to put will make the implementation more complicated as Martin was talking about.

[00:46:19] **Alan Frindell**: Okay. Thanks. Michael?

[00:46:22] **Michal Hošna**: I think all of those solutions that Suhas proposes doesn't solve the problem that, like, the request update can can be so much faster than, like, the any any queue you have on the data plane. So you cannot, like, guarantee that the priorities will be the one you want. I think the main question for the group is, like, is the raciness okay? I kinda think it is, but I don't have, like, concrete use case for this feature. But I would kind of want to, like, hear if we want to, like, do synchronization because I agree, like, any synchronization is, like, very painful.

[00:46:58] **Suhas Nandakumar**: Suhas? Just respond to Michael. I'm I'm totally, with you on saying raisiness is okay in this case, and then we should not add more complexity on top of it there. And I'm just trying to say the say the point I was trying to say is that we can, reduce the amount of raisiness by repeating some information for a while to to see the system eventually settles down, but it's not full proportion as I said. And we are we should be okay to deal with some kind of raisiness here.

[00:47:29] **Alan Frindell**: Oh, Michael, are you still in the queue? Okay. I I think that I I there's sort of three ways we can go. One is we do nothing. You cannot change this, and it costs a byte. But there's zero ambiguity, and there's no new code you have to write. Two, we do something like seven seventeen seventy, which is you can do this to save the byte, but it's racy, and it causes, like, some head like, it's work for us to nail down on the loose ends of the spec, and you have to go write code for it. And then there's, like, seventeen seventy plus, like, not that we remove the racy, but I I'm not hearing really anybody saying that's worth it. So maybe let's start there. Does anybody really want this feature and want to remove all raciness? Okay. Don't hear anybody asking for that. So it really comes down to do we do we want this do we want $17.70 sort of more or less as is, or do we not? Like so people who use it are gambling on raciness in exchange for a one byte compression savings. How many people are here? Do we wanna, like would a show of hands be useful? I I don't really know. Another option is, like, we could take this we could not land this in transport, or we could we could do a middle ground to make it a parameter instead of a property and but we don't define update semantics, and then someone can define update semantics in an extension. Suhas?

[00:49:30] **Suhas Nandakumar**: I I I don't think so. This can be an extension extension to just update the priority. But but I do I do feel like there there are real use cases where you would want to change the priority of the track that you're sending. And and if that happens, going to repeat that priority in in the object is is totally fine. Do we need to update the why a pub request update? Maybe maybe not. But but the the very fact that if you are including that ob that priority in every object that overrides whatever we have set it in the original publish, always already gives you the kinda the thing that, you know, the the new priority will be what the object shows up with.

[00:50:15] **Alan Frindell**: Chairs, how should I resolve this? I don't like, think what I'm hearing is that at least, like, from, like, Suhas, I don't know if Cullen's around, but, you know, he's been an an advocate for this one in the past. They kinda want this. They feel like the bite's gonna be meaningful. We should have a way to change it. I hear a lot of people also saying, like, it's just a bite in complexity. We don't want it. So I'd I'd what's the do we just put it in the spec? And I don't know. What do you think? I'm looking for what to do.

[00:50:45] **Martin Duke**: I'm sorry. Who's arguing for this to go in the spec?

[00:50:50] **Alan Frindell**: I I I think I've heard Cullen advocate for it strongly in the past. I don't know if he's still on and then Suhas as well. Okay.

[00:50:56] **Mo Zanaty**: Is there

[00:50:57] **Alan Frindell**: anybody else who really is excited about saving this byte that wants to put their hand up?

[00:51:04] **Suhas Nandakumar**: Just to be clear, I'm not I'm not saying that we I I I'm just saying that whenever someone wants to change a priority, they can change it in a word, right, and not worry about the completion.

[00:51:16] **Alan Frindell**: I'm not wait. Are you saying that you don't wanna you don't mind about saving the bite, you do? I don't understand.

[00:51:21] **Suhas Nandakumar**: I I don't mind saving I don't mind about adding an extra byte if I if I'm from now from the point t u two onwards, if I want to change the priority, I'll I'll just include that in the byte, then doing the signaling channel to say I'm going to change the default priority.

[00:51:36] **Alan Frindell**: I so I think you're saying you still want the ability to change it, and you're willing to live with the raci ness.

[00:51:42] **Suhas Nandakumar**: Yes. I I I would yes. Changing yes, but I I don't think so that we need to have a request update to do that. Just change on the object with

[00:51:50] **Cullen Jennings**: the Oh,

[00:51:51] **Alan Frindell**: you're saying you don't care about the compression at all?

[00:51:53] **Suhas Nandakumar**: Yeah. I I I don't I'm not sure about what Cullen thinks, but I I I I think as long as on the data plane, its signal is is good enough.

[00:52:04] **Martin Duke**: Okay. So I I don't know who's fighting for this at this point.

[00:52:14] **Suhas Nandakumar**: Like, I I can check with Cullen and see what he thinks and and get back by tomorrow if that helps. Not sure.

[00:52:22] **Alan Frindell**: Why don't we I can you just start a thread on this? I don't know if you wanna call it a consensus call or not, but, like, I'm tempted to say no if

[00:52:32] **Martin Duke**: there's Yeah. The sentiment seems to be not to do this. I can send an email if you want.

[00:52:39] **Alan Frindell**: Yeah. And just say, hey. The vibe in the meeting was this. Is if anybody's gonna have, like, severe heartburn and wants to try to change it. I mean, I guess, conversely, I mean, I do hear I see some people in the chat saying no. I think, Martin, it seems like you don't really like it at all. I think Luke is not does not like it. So

[00:52:59] **Martin Duke**: I mean, I I think this side of tinkering with the object model at this stage of the game is pretty dangerous, and you are ending up with you certainly end up in a case where Relay can get to get the object same object twice from two upstreams with different publisher priorities. That doesn't sound that seems like a lot of seems difficult to reconcile.

[00:53:24] **Suhas Nandakumar**: Martin, that can happen even without this today. Like, two publishers because you can put in object the the publisher priority. Right? So if two publishers are redundant publishers are sending, each can send with different priority of the same Well,

[00:53:36] **Martin Duke**: that that's a malformed track.

[00:53:39] **Alan Frindell**: Okay. I I wanna cut this off so because I know Will has like, took time to write slides in back in Vienna and hasn't got a chance to present them. So I I made can we just, like, wrap this up quickly and we can just continue it on the list? Yeah. Moe, do you have something super quick?

[00:53:53] **Mo Zanaty**: Yes. The last point that Martin made, the malform track, I think, needs to go. That need that needs to be removed. Regardless of disposition of this, I think it's a problem to malform a track because it came in with two different priorities.

[00:54:05] **Alan Frindell**: Can you open an issue about that, Moe? Sure. Thank you. Okay. I'm gonna stop sharing my slides. I'm sure that the other ones I made were super interesting, and you guys should go go read them, and we can talk about them on list or on the issues. And, Will, why don't you do what you can?

[00:54:25] **Will Law**: Thanks. Does this meeting run till a half hour or the end of the hour?

[00:54:30] **Alan Frindell**: Oh, you're right. I forgot.

[00:54:32] **Martin Duke**: End of the hour.

[00:54:34] **Suhas Nandakumar**: Oh, the end of the hour.

[00:54:35] **Will Law**: But thank you, Alan. I'm gonna keep my spot here. But

[00:54:40] **Martin Duke**: so I would just threw away a half hour of time.

[00:54:43] **Will Law**: We can go back for sure. Changing changing subjects here. This is fetch pacing for MoQT. Next slide. Or do I have control? I have control. This is issue 1453. It's over a year old. It's an old one, and the chairs asked for a proposal to actually make this work. So I've written one, and these are the slides describing that. The the very quick background here is that standard congestion control is gonna attempt to download data as as quickly as it can send it. Most servers will try to send data as fast as they can. And for fetch responses, this is going to lead to bursty traffic, which then leads to buffer bloat and packet loss on the intermediate networks between your edge relay and your end client. Studies have shown that delivering it as fast as needed is better than as fast as possible. That's a semantic word game. You can say, well, how fast is needed? And the answer is let the subscriber tell you. Let the media player. For example, a media player knows it's subscribing to a three megabits per second encoded video track. The relay is gonna try to send it at a 100 megabits per second if that's the only thing you're downloading because it's in it's either in cache or it gets it very quickly from upstream. But the the client can say, you know what? Send me that three meg track at 10 megs. I'm perfectly happy. I really don't need it any faster than that. And this makes sense for fetch only because subscriptions are naturally paced at their own encoding rate. And I realized after listening to the discussion we just had, this actually works for fill fetch as well. So when you see fetch here, it would make sense for the the filling part of a fetch. So I I have a draft here that proposes a solution as an extension to MoQT. So we have a boolean setup option which is called fetch pacing supported. If both sides say they support it, we're off. And it's very simple. There's a single new pacing rate message parameter that you can add to a fetch request. It's a bar end and it carries the rate signal. Rate signal I copied from SCONE at the suggestion of Lucas Pardue, and it's a logarithmic scale. So it's got a fast rate. You can specify from, I think, a 100 kilobits because that's the the the initial value here up to gigabits. And I just show some useful values here. There are more intermediate values than these. So I think it covers a range of values we might wanna pace at. And this parameter accompanies the fetch request when the publisher sees it, they then deliver at approximately the rate requested. Some FAQs before you ask for questions. So can you modify the pacing rate after issuing the fetch? No. Because I don't think we have an update mechanism for fetch. You can cancel the fetch. You can issue a new one, the different pacing rate. Is the pacing intended to be precise? No. It's not. You must pace at approximately the indicated rate. It might be slightly higher or lower. The time base should be the group duration of of the track being paced. It's been pointed out that a server doesn't know what that group duration is. It can it can estimate it by observation, by looking at walk time between groups, so it might adjust its pacing and go with a lower value. Clients should not depend on preciseness. The whole point of this is that a general limitation is practical and useful. And the study I quote in this comes from Netflix who did the SAT scale across millions of clients and and were able to show utility in it and QOE increase. Does the draft define the mechanism by which we pace? No. It doesn't. There's many different ways to do it. We just again say that you should do it at approximately the indicated rate. Security considerations, you can lie to the relay. You can have a, say, a file that's encoded at 20 megs per second, and you can ask for it to be pasted 10 kilobits per second. Functionally, this is no similar to doing subscribe with forward zero. So I think the mitigations we have in place or warnings for that should also cover that case for fetch. And that was it. I will any questions on this? Sure.

[00:59:09] **Mo Zanaty**: Yeah. Just just thinking out loud. I put in chat what I was thinking. But, instead of server side, if the client is the one specifying the rate, so the client already knows what it wants, can it already do this today just using QUIC itself, just using the, you know, stream credit? I I know it's not part of our official MoQ API to say that on the stream, you know, on the stretch stream, you know, don't allow, you know, credit automatically, you know, give the credit

[00:59:39] **Will Law**: to the at Luke's request then. It is per request, not per connection. So wouldn't sending a QUIC stream data affect your whole connection and not not this individual request? You might have five parallel requests for a page paste paste each of them separately.

[00:59:57] **Mo Zanaty**: But but that that that's what I mean. Each each stream in QUIC is flow controlled individually. Right? So fetches, right now, only one stream. If you had three multiple you know, three concurrent fetches, you could set three different rates on each of those three different streams. Is that what you mean?

[01:00:14] **Will Law**: The the goal is to set a different be able to set a different rate on each stream. Correct?

[01:00:19] **Mo Zanaty**: Right. So I think we already have some mechanism to do that. MoQ obviously doesn't surface that mechanism at all. In any of our specs, we don't say that you can apply a QUIC stream limit. And I don't think any of the MoQ libraries do anything like this, but it seems like a pretty easy change. And it would avoid the the nose that you said earlier. You could update it. The client could update it, and it's precise. The client provides exact number of bytes.

[01:00:43] **Will Law**: Not all clients have access to the QUIC stack. For example, web based clients using web transport and a browser API. There there's no API That's good point. Yeah. Correct.

[01:00:52] **Mo Zanaty**: Yeah. You you'd want some something that specifies this API directly, and you'd one of our transport feature that corresponds to whatever mock library features we we had. Alright. Just wanna throw it out

[01:01:05] **Cullen Jennings**: there. Okay.

[01:01:09] **Alan Frindell**: Thanks, Will, for doing this. I think it's very useful. We actually very soon, we're gonna put out a draft for something similar in HTTP, and we have done experiments at scale doing HTTP, including this kind of rate parameter. And if if I think it's very useful to to tell the sender, I think flow control is the wrong way to do this for two reasons. One, what you just mentioned about web transport in particular. But generally speaking, a lot of QUIC libraries don't necessarily give applications the gran the granularity of control over setting the rate at which you want flow control credit to be released. And the other one is that, like, flow control is like, we we have learned the hard like, before we had good priority controls at Meta, we used flow control as, like, poor man's priority and rate signaling. And what you're really supposed to be using flow control for is is for resource control. I only have this much memory, and you can't exceed it or you'll overflow my buffer. And trying to tune your priority stack by tuning that flow control number is, like, will lead to bad outcomes. And I don't think we should recommend people to do it. I guess I do have an open I mean, I'm sort of neutral as to whether the way you'd find it here as an extension seems fine. I I guess if people are, like, clamoring for it to be just a native mock t parameter, like,

[01:02:27] **Suhas Nandakumar**: it

[01:02:27] **Alan Frindell**: I'm I'm I'm neutral on on that outcome.

[01:02:30] **Cullen Jennings**: I'd certainly like it to be

[01:02:32] **Will Law**: a MoQT parameter. I'm a little bruised and scarred from trying to get things into MoQT anymore. Everyone says it be written as a external draft and as extension. So if you're happy to have it as MoQT, I will rewrite this. But I just did that round trip with with another draft. So I'm starting off with an extension here, but clearly, if it's simple and practical, this would be that could be a very natural part of the mock team. Martin?

[01:03:00] **Martin Duke**: I disagree with this. We don't have an API thing. The API is to consume the data slowly. Like, whether you're up in JavaScript or you're down, you know, in the QUIC implementation, if you just don't read from the stream, like, the buffer's gonna fill, and it's gonna put back pressure on the sender. Like, the whole point we have fetch is to allow this kind of flow control. Like, that was the entire the entire reason was because it was hard to flow control subs like, when stuff came in the past, we needed some way to quickly do flow control and, like, you know, we have this quick function to do flow control.

[01:03:32] **Will Law**: But what if we start timing out then unintentionally? Like, you start reading a lot slower. The say say the relay is getting it upstream at a 100 megabits per second, and you're you're reading it at five megs per second, it's a three meg per second stream. What's your relay gonna do? Is it gonna start timing you up? When it's got an explicit pacing parameter, it could set protections to say, this user wants it. I don't wanna ever send it at this rate even if the user's not giving any break pressure.

[01:04:03] **Martin Duke**: Well, so so the so the problem is the relay is serving multiple fetchers and, like, this one is falling behind.

[01:04:09] **Will Law**: So you might want it at three meg. Somebody else wants it at 20. Somebody else wants it at 80.

[01:04:14] **Martin Duke**: Isn't that a like, isn't that I mean, I think that's a problem regardless. Right? I mean, I don't think I don't think that having this explicit parameter makes it is functionally different. Like, there's still a DOS attack where I say, give me 100 bits per second. It's the same as just not consuming the data and not granting credit. Right?

[01:04:36] **Will Law**: True. It's not a DOS attack. It's no different to, like, slow reads or or a DOS attack. This is a signal that it's

[01:04:47] **Cullen Jennings**: Yeah. Oh, you know,

[01:04:48] **Martin Duke**: does. But

[01:04:50] **Suhas Nandakumar**: Yep. And I also don't like the

[01:04:51] **Will Law**: transport API. It's tricky there when you subscribe to a stream to it's nice when it you can pipe what's coming out the stream directly to your decode engine. But to implement what you said, you would have to grab small bites of it, grab them slowly, and implement it. Whereas if we had this mechanism on the relay side, you could simply park the output and would come at approximately the rate that you'd requested for simpler clients that are with

[01:05:18] **Cullen Jennings**: Well, what our fetch application does is provide sort

[01:05:21] **Martin Duke**: of an API to the application to just, like, pull grab one object at a time. So it only consumes at the rate that it's able consume, and that naturally fills up the buffer and causes, you know, flow control, back pressure. That said, we don't have a super sophisticated fetch relay implementation. I was dead set against this. I'm like, gives me pause that Alan has this HTP experience. It makes him think that this is valuable, and I'll have to think about that, maybe talk to him. But my modulo that, my gut instinct is to say this is, like, duplicative of mechanisms we already have that work pretty well without I mean, maybe not optimally, but work pretty well with no, like, special machinery. Thanks.

[01:06:04] **Suhas Nandakumar**: Good.

[01:06:07] **Michal Hošna**: Michael? I actually think we kinda need this and that, like, doing back back pressure for this doesn't work that well. Maybe my question would be, why is this only for fetch? Don't we want this for subscription in general?

[01:06:28] **Will Law**: Well, subscription, you don't tip subscription is for content that's naturally paced by its encoding rate. You can't get you can't get encoded content faster than the rate at which we it's being produced.

[01:06:40] **Michal Hošna**: But I think the the question is, if we look at non low latency stuff, you I could see use cases, especially when we do, like, trying to map existing HTTP adaptive streams to MoQ where, like, you get the whole group at once, which which is something like the the problem you have with HTTP is, like, requesting file that is already existing or, like, you are seconds or, like, tens of seconds behind behind the live edge, you may get the whole group.

[01:07:12] **Will Law**: And this also It's a it's a fetch. Right? You can't you can't be subscribing to something

[01:07:18] **Alan Frindell**: that's Like like, the the

[01:07:19] **Michal Hošna**: the publisher may be giving you, like, the whole group at once.

[01:07:22] **Will Law**: So the publisher sends nothing, and then it bursts the whole group is what you're saying. But that's to me sounds like a publisher problem. The publishers intentionally causing the burstiness there. Okay.

[01:07:36] **Michal Hošna**: That's yeah. And maybe I think the motivating use case for others is one of the problems we have with live streaming and and not pacing is not necessarily, buffer bloating. But that if you if you are doing a big fan out, and you synchronize all the clients, like, you are bursting all the clients at once. That's, like, the problem that you are trying to solve with with, pacing often. Okay.

[01:08:06] **Mo Zanaty**: No. And just to clarify, this is only on, downstream for each fetch, so it doesn't imply any kind of operation at the relay for its upstream fetches. Right?

[01:08:17] **Will Law**: Mean, you can you can obviously imagine a relay that's smart and trying to juggle an upstream pace that's greater than the highest downstream pace. Right? I think it would be foolish for relays to try to do that. They could they could run into a timing problem where it suddenly changes and now they want unpaced content and they wouldn't have it. So I I I think I wrote in the draft that this should this should not this pacing should not be propagated. Got it. But nothing stops the relay from doing that. Right? They can if they want to.

[01:08:52] **Mo Zanaty**: Got it.

[01:08:54] **Will Law**: And for people saying, like, I see in the thread fetch from zero to infinity, I I I don't anticipate people using they they would do a sawtooth buffer fill. So you'll fetch ten seconds of content and you'll pace it so that it, you know, it takes comes to maybe eight seconds instead of a quarter of a second. I think that's the type of usage you might want to deploy it with. Okay. So it's up there. Please file issues. Okay. Alan?

[01:09:25] **Alan Frindell**: Yeah. I guess I was also just gonna reach for a conclusion here, which which might be that, like, for now, we just continue this work as the extension, and, I mean, it's written as such. And I I hear some people like it, and I hear some people don't right now. So I think don't do any additional work.

[01:09:42] **Will Law**: Okay. Especially a quick and dirty implementation would be nice in a relay that that and just to test it out, see if it works or explore some corner cases. I think that would be nice. Okay. Suhas?

[01:09:56] **Suhas Nandakumar**: Yeah. We will this this is useful functionality. One one thing I wanted to ask you is that have you sent about this to the mailing list just so that everyone is aware of this work? I did. Yep. Okay. Cool. Thank you very much.

[01:10:08] **Will Law**: Okay. Thanks. Bye.

[01:10:11] **Alan Frindell**: Okay. I will resume with the last twenty minutes, but I'm glad we had that nice interlude so you don't have to listen to me talk the whole time. Oh, Will, you might need to stop slides. I think we're on seven. Yeah. Okay. Okay. So this issue, thirteen fifty two, subscribe doesn't need a forward parameter if we have filters. People said, why don't we see a PR and see what it looks like and see if we like it? So thank you, Suhas. You wrote the PR. People go read it and see if they like it. I know some people have. I think the initial response has been kinda positive. So but it's of a big departure. We've had the forward prem for a year or two, and people are used to having it. So I don't know if, Suhas, if you wanna jump in and just kind of explain the the semantic that you have here.

[01:11:13] **Suhas Nandakumar**: I I I I did change that based on the location filter. So I I would I would rather say if people are reviewing it, review review it after the location filters get landed because I based it on the location filters branch so you have the duplication of location filter. And what the main idea here is that if you do start range greater than the end range, that's pause. That that's that's the one line summary for what it is. Let me know if it makes sense. There are other ways to encode it as well. For example, we can have zero like, start a start object start group, start object, end group, and end end object all being zeros to mean to not, like, basically pause the subscription. But what it what we lose if we do that is that we'll not be able to get absolute object zero from the group zero. So and since I thought about it, I mean, most of the ranges when we write even the loops, the way you basically inward, you what you do not want is to flip the something like, make make make make the range empty by making the start smaller than the end so so greater than the end. So give it a read and let me know maybe after the location filter PR lands. That way, you'll have only 10 to 50 lines of changes to see rather than a big, big change right now.

[01:12:37] **Alan Frindell**: Okay. Thanks, Suhas. Yeah. I just kinda put this up for to let people know that it was available. I don't think it's ready for action immediately. Oh, Martin?

[01:12:47] **Martin Duke**: Yeah. I don't understand how this works with the, publish notify stuff.

[01:12:52] **Alan Frindell**: I think it's just a different way to spell forward. So if the subscribe if the publisher should if the subscriber said pause this thing when you're ready and the publisher does, then it would send a publish notify with whatever encoding means you're not getting anything right now. If that means a location filter with start equal end or whatever it is, like, that's what you'll get.

[01:13:12] **Martin Duke**: Okay. That so the idea is that a publisher can send subscription location filters in general to the subscriber, or is there special carve out for, like, the null filter, whatever that is.

[01:13:27] **Alan Frindell**: And then be able to send location filters, for example, switch from use cases where the or even potentially top end might be where, like, you when you move off of something, you update its range to be like, I'm gonna give you the rest. I'm ending your subscription at this group or something like that. So I think location can come in.

[01:13:46] **Martin Duke**: I mean, I think this can work, but I I I don't wanna have, like, this thing where there's you can you can only send a specific type of subscription filter in publish notify. That sounds like way too many, like, layers of of permissions, if that makes sense. But there's specific parameters you can send and publish notify, which is fine.

[01:14:09] **Alan Frindell**: Right. But I think location filter is gonna be one of them.

[01:14:12] **Martin Duke**: Yeah. That's fine. As long as it's all location filters, and we're okay with that.

[01:14:16] **Alan Frindell**: Some of them would be very weird, but okay.

[01:14:19] **Martin Duke**: Yeah. Moe?

[01:14:23] **Mo Zanaty**: I think the high level bit of this is right. The forward perimeter already has confusing interaction with with the even before the location filters, the existing subscription filters, you know, the forward already had weird interaction with those. And I think it is right to eliminate forward and do everything based on locations. I think the particular spelling that I would like is what Ian suggested, is, you know where you wanna end? Say it. You know? So you you wanna end right now and you know the object that you got? Put that as the end, and that's the way you stop. You stop something. So I think an explicit end when you know, you know, the the current location, that's the easiest way. If you don't know the location, that's the challenge. You don't know head. You don't know anything about the track. How do you express no location and then so then maybe sauce is hack of, start before, start bigger than end is viable. But I think we should avoid going back to forward because I think there's so many holes that we don't even realize are there. And when we move to a single way to do this with just locations, I think it'll be a lot clearer.

[01:15:32] **Alan Frindell**: There is a difference between forward and setting the end, which is that if old objects come that are smaller than your end, you're gonna get them. With forward, you don't.

[01:15:41] **Mo Zanaty**: But but that's what largest object could also do that. Right? That's what out of order stuff is

[01:15:47] **Alan Frindell**: Right. But if I set forward zero, it doesn't matter what my filter was. I'm not getting anything. If I set my end location, I'll still get stuff smaller than end if it happens to show up. So that's just I mean, maybe that's a difference people are okay with, but it's just a difference.

[01:16:01] **Mo Zanaty**: Yep.

[01:16:02] **Alan Frindell**: Okay. I'm gonna move on from this. It sounds like there's some more work ongoing. Is Victor here? This was Victor's issue. He said he wasn't gonna be able to make it.

[01:16:14] **Suhas Nandakumar**: Yeah. He's not making

[01:16:16] **Alan Frindell**: it. I I we might put a pin in this. Victor did not

[01:16:19] **Suhas Nandakumar**: like

[01:16:19] **Alan Frindell**: or for reasons mentioned on the slide. I think I I did highlight one key difference. If you subscribe if you make two subscriptions with different filters versus making one subscription with OR'd filters, one of those is gonna deduplicate objects and one of those is not. So that's pretty I think that may be an important enough difference to that justifies keeping both mechanisms. But I'm gonna I'm gonna we'll we'll come back to this at time when Victor can speak for himself. Well or yeah. Let's just do that. Not much time. Okay. These are some new issues. Timeout overrides for subgroups cannot be propagated if a relay joins in the middle, and I've expanded the concept of this. So we allow you to change the subgroup, like, the delivery timeout for a subgroup or a datagram by including in a subgroup, you include that in the first object in the subgroup. But if you subscribe in the middle of the subgroup, you're gonna miss that override because it's in the first object, not in all the objects. And so, essentially, like, including these overrides in objects in the data plane makes them unreliable. One of them is datagrams. So if I have a datagram with a timeout and I don't get it, I get although, I guess that's per datagram. I can also filter. So I filter out objects that are red, and it turned out that object zero was red. And then they had the over they had the timeout override in it, and I'd miss it. Or this may be subgroup join case. But carrying the timeout overrides in the data plane is also a feature. So if you move that timeout override to the to the control plane in some way, it might be on a different stream, which means it could be reordered and you wouldn't even receive it before you got the you know, before the subgroup came in and out. So do people have thoughts on what we should do about this? Nobody has an opinion. Everyone's bad coding right now. No one's listening to me. Okay. I'm gonna move to I'm gonna move to another issue because I'm getting no signal here. I I am somewhat inclined to close this issue with no action, but I don't know that I can do so without at least one other person giving me a plus one there. Interaction of include property zeros and mandatory track properties. So we added this new option for a subscriber to say include property zero. And the idea is that if I already have all the properties and they may be large, I don't want to get them again. But there's also language about, like that says, like, if the subscriber gets a property that is mandatory to implement and it doesn't understand it, it's supposed to take specific action. And it can't do that if we include property zero and it doesn't receive those at all. Now it's sort of not the use case. Like, you're not supposed to send zero unless you already have them, and they're not supposed to change. And there's also logic in there that says the publisher is not even you're this publisher is supposed to error if the subscriber doesn't support feature foo and the publisher wants to include that extension. It's supposed to error the subscriber fetch anyway, but that's a should. It also publish is not well handled in this case because if, like, the subscriber did a subscribe tracks and this track has a mandatory to implement property that the subscriber doesn't understand, am I supposed to send it to them and let them choke on it, or am I supposed to publish, skip it? I don't know. Another but maybe the right option is, like, when you include property zero, we just the only all the mandatory implement ones, like, come anyway. You could and that that sort of side steps the issue. So people have thoughts on this? Martin?

[01:20:42] **Martin Duke**: I mean, this is all people violating the spec by either tweaking their properties x post or just putting include properties in. They'll actually have the properties.

[01:20:54] **Alan Frindell**: I think it's the latter of the two. Well, assume it's the latter of the two.

[01:21:00] **Martin Duke**: Well, I mean, like, if you violate the spec, then shouldn't you be punished by having things work very badly?

[01:21:05] **Alan Frindell**: I mean, I'm okay with that disposition as

[01:21:07] **Martin Duke**: well. Okay.

[01:21:11] **Mo Zanaty**: Mo? Yeah. I'm I'm also okay with that, but do we actually say that you can't put this parameter in unless you already have the properties? I don't know. We say that this is this is not allowed when you're blind of properties?

[01:21:27] **Alan Frindell**: I mean, we can say that all we want. Doesn't I mean, there's no protocol, please. Somebody can. But Right. They they can get what they deserve. But but I guess But

[01:21:37] **Mo Zanaty**: it's sort of Like Martin said, I mean, if if it's clear that they're violating something, then then they know that things will blow up potentially. But if we don't say that this is bad, then they don't know that they don't know that bad things could happen.

[01:21:49] **Alan Frindell**: So if we so I think for everyone who's talked so far, I think what I'm hearing is, like, it's fine that you might miss this as long as we tell people not to do it, and and that's okay. I I I I can write a PR to that effect. Okay. So after that, it is we're going to oh, Martin?

[01:22:10] **Martin Duke**: Yeah. I'll just say, like, I I put in the comments, like, unless there's some sort of DOS that I can't see right here where, like, sending us by pretending other properties that I don't, like, I can do something bad to the publisher, but someone else is gonna think about that.

[01:22:24] **Alan Frindell**: You can get a track that the publisher really didn't wanna send you, but maybe the publisher ought to know the publisher should not send it to you anyway because if it knows you don't support the thing.

[01:22:34] **Martin Duke**: Yeah. Like I said, I don't know. But, like, the only that's the only hazard here is if the must is also protecting some sort of DOS or security problem. I don't think so, but, know, the spec better

[01:22:48] **Suhas Nandakumar**: than me.

[01:22:48] **Alan Frindell**: It's sort of unclear. Yeah. I'll put up the PR and maybe in review if somebody has a problem. They can maybe we can get through this quickly. Is the query in the URI part of the MoQT scope? So the path parameter conveys the u the thirty nine eighty six path and query. And I think the language about MoQT scope's a little bit ambiguous. It just says path. But is that are we talking about the thirty nine eighty six path without the query, or are we talking about the path setup option which has both? I think everyone who waited on the issue was like, the query shouldn't be part of the scope explicitly. Does anyone wanna weigh in? Victor is one of our scope experts, and he's not here. Mo?

[01:23:57] **Mo Zanaty**: If our setup option path is different than the thirty nine eighty six, think, where should we just rename our option that make it clear?

[01:24:07] **Alan Frindell**: I I mean, we mirror what HTTP does. There's a colon path pseudo header that carries both. So, I mean, we could split it into two. I mean, I I think it's fine. As long as we make it explicit what defines the scope, I don't think we need to rename the parameter. But I think the bigger option are we are we all agreed that we don't want query to be part of the scope? That let's start there. I know Will and Michael both had opinions. I don't know if you wanna share them here. I see oh, Will gave a plus one, Michael.

[01:24:43] **Michal Hošna**: My opinion is mostly I think we have plenty of things in that are scoping already. Like, we have already already end path, which is, like, more than we have with HTTP. So leaving query for something else and skipping all this query prob all the, like, which queries are equal problem it's a good thing to do. And I Okay. Agree with Moe that, like, path is kind of bad name, but, like, that's on HTTP.

[01:25:12] **Alan Frindell**: Okay. Unless somebody objects, I'm going to make it clear that query is not part of scope. Okay. There's two new issues that have been filed. I wanna make sure the off design team is aware of them because I've tagged them as off, and I don't feel like I have the scope to resolve them. One of them is about what are the semantics when multiple authorization token parameters are included in the message. There's a bunch of use cases here about including the same, like, type of parameter that belongs to multiple CDNs, and I don't even wanna like, if you're I just wanna make people aware this issue is there, and I hope they it's in the the off design team has their eye on it. The other one I can explain more directly, 1843, someone was asking, like, how am I supposed to tell the subscriber or the client that their token they need to refresh their token? I tried to reply, I was like, we we we solved this with the expires parameters. So if I subscribe to you with a token, when I validate it, I can find out when it expires, and I tell you in the okay. Like, if you take no action, I'm killing the subscription, whatever, in ten seconds. So that's how we handle it. However, there's no vehicle to convey that when you send your send your token and setup. Setup is now unidirectional, and the server can send it first. So there's no way to like, if the client setup is like, here's my token, and it'd be like, oh, well, great. It expires in ten seconds. I can't tell you that. So I don't know. And, like, I I didn't I don't know the right answer to, like, solve this problem, but maybe also that can be on the off design team. Is there an off person here? Looking at the list of people. Okay. Well, hopefully, they read the deck. Or see I've cc'd people on issues also. One thing I wanna float and let people know. So the the authors and editors are gonna get together for a face to face in three weeks or four, and we're gonna try to tackle some of our 50 editorial issues. I was contemplating that we should cut draft 20, like, immediately before that, and then we will do our editorial magic, and then we'll cut draft 21. So, like, twenty and twenty ones would be sort of no ops. And then the next draft that we cut, that would be interrupt target, would be 22. Does anybody have heartburn about that possible plan? I haven't talked to Ian about it. In draft 20, I have app alphabetical listing of messages. If we're gonna do stuff like shuffle the deck chairs, that is definitely a thing to do in a draft that is only editorial change. So that's what the idea here is that, like, if we're gonna reorder messages, we would do that in a draft that has no functional change so that we don't bury a functional change in a section move. So we would just, like, cut 20. And so anyone wants to know the difference between eighteen and twenty, they can look at that. And anyone wants to know the difference between that point and 22, they just differ from 21. And, like, we just isolate all the editorial changes. Anyway, just view unless somebody has, like, hard coded their plans for draft 20. That's just a heads up that the next actual implementation target might be 22, and we might burn a couple draft numbers just for sanity of comparison. Okay. That's all I got. Martin?

[01:28:56] **Martin Duke**: Thanks, Alan. I will say just as a chair announcement that I've I've been sort of sitting on the draft 19 diff consensus consensus call because I think people are still implementing 18. Magnus does owe us a interim virtual interop date, which I believe is supposed to be eighteen so that in Seattle, we can do whatever Alan's up to after he does all this editorial stuff at 2021, whatever it is. So, I'm deliberately sitting on that one because I think when people implement, that's when the issues come. Other than that, I will see you on the twenty fourth. Alan will not be there on the twenty fourth, unfortunately, thanks to chair incompetence. And so, it might be a good time to bring up some non transport issues if people need time for that. Just email Magnus and me if that is something you are interested in. But Ian will be taking the lead on that, and we'll run through issues, and I'm sure we'll do fine with the time we have. So, great. We'll see you all in two weeks. Alan, we'll see you in four weeks.