**Session Date/Time:** 13 Apr 2026 16:30

**Aman Sharma:** Yes, you notice we're still very few that joined. So we will give people a little bit more time. I think some might have a problem joining.

**Martin Duke:** The problem was on my end. I'm in now.

**Aman Sharma:** Should we run through the trivia slides?

**Martin Duke:** I guess we could get started on that. Okay, let's do it. Okay, as usual, sure. The Note Well applies to this meeting. If you have any questions... Hello Cullen. Did you... No, okay. Um, it's, if you have any questions or you should be aware of these, by participating and know that by actually speaking or contributing in any form to this meeting, you have certain things apply to you. So, and we also have Code of Conduct etc. that applies. So, use Meetecho and use the queue tool to raise your hand to join the queue. And also if you have show hands, we will use the tool. So, do notice there is a bit of lag if you try to speak when you're opening up the mic. And headsets are recommended. So, upcoming dates. We have additional virtual interims. We have 27th of April, 11th of May, and 26th of May. And then we have meeting in London, the week of, starting with interop on the 9th and it's 11th and 12th for the actual technical meetings. It starts the 10th, yeah. It's that week. So, and today's agenda is that we first go with REWIND, and then we have the rest of the time is for MoQ editors issues that they can discuss. So, Martin, you're first.

**Martin Duke:** Good day everybody. Alan asked me to... Alan asked all the owners of the Big Rocks to present over these interims leading up to London and hopefully we can sort of resolve them. The last time the group talked about REWIND, it was at the Boulder interim and what this is basically is a way to get a few recent groups via SUBSCRIBE, getting SUBSCRIBE semantics and the key thing that's happening here is that it's done best effort by the publisher. The publisher could just say no, I have nothing in cache, you are not getting anything. And the idea here is to avoid the head-of-line blocking that's inherent to JOINING FETCH and to just have the SUBSCRIBE semantics be used for those, which is good for some use cases. All right, I don't want to go through the whole presentation about what this is again, but some of you probably don't remember or weren't there. So just very briefly, there is a setup option called... This is written as an extension because that's how we were doing things. So there is a option called max_rewind_groups that tells you kind of the maximum number you can request. There's a new subscription... if you support that... if both ends support that option, then subscribers can use a new subscription filter called rewind which has some integer in it, which basically says I want to go n groups before largest object and have those delivered with SUBSCRIBE semantics if possible. And that can't be larger than max_rewind_groups. And then in SUBSCRIBE_OK there's a parameter called rewind_groups where the publisher tells you, this is, you know, I... you asked for this many, you may have asked for this many but this is the number of groups I'm actually going to give you based on what I have locally in cache. A value of zero means I'm going to give you the current group from its beginning. And it's like a good way... people have nitpicked the details of this, but essentially you can view it as essentially imagine the SUBSCRIBE started at the beginning of whatever group you start at. So you get a very similar experience as if you have subscribed, you know, at the point where that group started rather than at the point you're actually beginning. If there is a JOINING FETCH done concurrently with that... or I'm sorry, if that... if the SUBSCRIBE has a rewind parameter also has a JOINING FETCH attached to it, the JOINING FETCH will omit whatever groups are included in the rewind. But you might want to do the JOINING FETCH just to make sure you get the objects, although you may get them later with a JOINING FETCH than you would get with a rewind. And like the important thing to understand it is best effort. The publisher can just not include the rewind_groups parameter in which case, you know, it reverts to NEXT_GROUP behavior or it can have whatever number you requested, it could provide zero, it could provide a number less than the number you requested, or it could provide up to the number you requested. Does anyone have any questions about this? And again, this is from the long JOINING FETCH discussion we had in Boulder where it kind of came up what bothered people about JOINING FETCH was the, like, the head-of-line blocking issue. So this is mainly addressing that. Go ahead, Luke.

**Luke Curley:** Um, is zero mean you don't... does it mean you don't support this at all? Because I see a less than or equal to sign.

**Martin Duke:** No, so if you sent... no, so if the option is missing, you don't support this at all.

**Luke Curley:** Zero means latest group?

**Martin Duke:** That's correct.

**Luke Curley:** Okay. I mean we could spell that differently if people have issues. Okay, are there other questions? Mo, question.

**Mo Zanaty:** Yeah, I had a similar question. So the spec says current group for zero. Does that mean the beginning of the current group or does that mean...

**Martin Duke:** Yes.

**Mo Zanaty:** Okay, so you can go back to zero of the current, whatever the current group number is.

**Martin Duke:** If the SUBSCRIBE_OK parameter rewind_groups has the value zero, that means I'm going to go back to the beginning of the current group and deliver that to you as SUBSCRIBE semantics.

**Mo Zanaty:** Okay, so that's what we originally had a long time ago as our subscription filter for PREVIOUS_GROUP, right? Or...

**Martin Duke:** I think so. Like some sort of, like, current group beginning of current group filter I think we had at some point, but I don't remember.

**Mo Zanaty:** That's the intent of zero now. Got it.

**Martin Duke:** Yes. Gwendal.

**Gwendal Simon:** The max_rewind_groups, is it the horizon, the max group in the past that you can send, or is it the number of groups that you can send?

**Martin Duke:** It is the... Okay, well then there's an issue about this that I'll get to in a minute. But what it says is, don't even bother to ask for... don't even bother to send a number larger than this because my cache doesn't go back that far as a session-wide parameter. So let's say I store three groups in the past in my cache for whatever reason, I might send a value of three. Right? It's kind of an advice... it's kind of a... there is a MUST in there, but basically just sort of a hint on like how big of a number to ask for. It doesn't guarantee that you will provide that many groups because if you don't have SUBSCRIBE, you know, if you don't have that much back in your cache for whatever reason, it's not going to do you any good. Okay, I think that's all the questions, so I'm going to move on. All right, so just a lot about publisher strategies. Alan asked a lot of questions about this that were generally good questions. The draft does not say you must do things this way, although there are a number of restrictions. The biggest one is if for some reason there are discontinuities in a particular subgroup, you cannot deliver that second part of that subgroup because you have to preserve SUBSCRIBE semantics with the dependencies associated with streams. You can do something very complicated here. There's nothing really in the spec to prevent you from, like, cheating a little bit by going and fetching the objects you're missing, although that kind of defeats the spirit of it. But like mainly proposed just like a simple strategy that a publisher might use. If I don't have an upstream subscription active for that track, I would probably just take the rewind filter and put it in my upstream subscription so I can attempt to duplicate the... I can attempt to provide what the subscriber is asking for. Luke is saying cache filling isn't cheating. Um, it kind of is because the point is you're trying to avoid the head-of-line blocking and um, well, I mean you might be avoiding head-of-line blocking depending, but okay, fair enough. All right, and if there is an upstream subscription, basically I would go as far back as the first complete group I have for that existing subscription. So for instance, if my upstream subscription started in group four and it's asking for group three and later, basically... obviously these are all expressed as DIFFs, but bear with me. So if it's asking for group three and I have... if my subscription started in the group four, I would probably offer to start at group five because I can deliver... that's the first whole group that I can deliver. I have to emphasize it's okay if objects are missing because these SUBSCRIBE semantics, if I did not get a subgroup at all, I'm not even going to deliver that subgroup. If a subgroup gets reset, I'm not going to deliver the whole subgroup. It's just as if there was a SUBSCRIBE... just as if the SUBSCRIBE was happening at an earlier point. Alan.

**Alan Frindell:** Yeah, I think the way to be... I think your rule is right. I think the easy way to think about it is that, like, the first available rewind group is largest object... exactly what you have written there, largest object group plus one. If you don't allow rewinding past that point, it should be safe.

**Martin Duke:** That is how I would implement it. If you want to have, like, really complicated cache logic that, like, checks the, you know, checks if you have the whole group or if you're missing gaps in subgroups and all that, like, you know, knock yourself out. But I like easy and simple and I don't think the spec has to really specify as long as it sets rules about what you need to do.

**Alan Frindell:** Right, but I think that's why we... if we can add rewind, which is nice, but you can't get rid of JOINING FETCH because if you need, if you want to start in the current group, for example, and it's not there, if the current group was, like, incomplete in some way, you would still need to FETCH it in order to fix that problem. Does that sound right?

**Martin Duke:** It is not the intent of this to replace JOINING FETCH. It is to... there's a gap in JOINING FETCH in that you have this head-of-line blocking problem and it's meant to solve that.

**Alan Frindell:** Okay, gotcha. Suhas.

**Suhas Nandakumar:** A bit more of a clarification question. The... I'm seeing the contradictory view here. One is that yes, we have a head-of-line blocking with JOINING FETCH and we want to solve it. But at the same time we are saying we are solving it with rewind which can have gaps in it. They are not solving the problem, they're not solving the problem which you're supposed to solve which is FETCH should give you the answers or give a complete answer if something is missing. But with having I'll do SUBSCRIBE semantics and it's okay to have gaps, we are not actually solving the original problem which we intended to solve with rewind. So I'm a bit confused on actual problem we're trying to solve.

**Martin Duke:** So the problem is you want the group now, it's okay if it's not perfect, but you would prefer the low latency of not having head-of-line blocking rather than waiting...

**Suhas Nandakumar:** Right, but then it does... just to be clear that it's not solving the FETCH problem though. FETCH guarantees there will be things in here. This is not guaranteeing that one.

**Martin Duke:** That's correct. Yes.

**Suhas Nandakumar:** Okay. because it's been formulated as such, so I just want to be sure that that's not the case.

**Martin Duke:** Well, so I mean today the only way to get a few groups in the past is to do a JOINING FETCH or I guess if you happen to have more information an absolute FETCH. And that has head-of-line blocking issues. There might be other reasons you want earlier groups that don't require 100% object fidelity, and this is what that's for. Luke.

**Luke Curley:** Just a... this is like a clarifying question. SUBSCRIBE today is a relay allowed to serve what it has of a subgroup? If it knows it's got, like, zero through four and then it doesn't... and then it has a gap, is it allowed to just reset the stream? Like it doesn't kill the subscription if you don't serve all subgroup?

**Martin Duke:** That's correct. Yes.

**Luke Curley:** Okay. I mean, the relay may not even know it's missing a subgroup, right? It may never have been initiated by the upstream. Yeah, so in theory like you don't need to check if you have all the subgroup. You could just always say like, yeah, this rewind is successful, you just might give it only some of subgroup that you happen to have in there.

**Martin Duke:** The way the draft is written right now is you must be able to initiate a subgroup in one in like in every group that you're promising. So in theory I could just have object zero for every group and serve this.

**Luke Curley:** But what if you never received it? Like you never received the previous one?

**Martin Duke:** Then you shouldn't... well, the spec says you should not offer that.

**Luke Curley:** Okay. I mean, it just feels like you could be able to offer it and then just never deliver it, but we can spell it out.

**Martin Duke:** Yeah, okay. Will.

**Will Law:** Yep. Hey Martin. Just a question. You say you're solving the head-of-line blocking. So you would... you don't want to... if you want to start three segments behind live but the relay only has one behind live, then you say I'll just take the one right now. But that means your player is suddenly okay with starting with, say, two seconds in its buffer instead of the six seconds that it wanted. Is that an actual scenario? Most OTT players I know want a fixed amount of data in their buffer and therefore the head-of-line blocking, even if it delays the start, is a feature because their alternative is to wait that period of wall-clock time for the other segments to arrive to fill their buffer. So the use case in which this becomes useful is only when that wall-clock time is less than the time it takes to go back and do the FETCH, which I don't think is a very broad...

**Martin Duke:** Okay. Well... all right, fair... well, okay, so Will, you know way more about these use cases... you've forgotten more about this than I'll ever know. But like there are three ways to build a buffer, right? One is I can just SUBSCRIBE and wait for three groups until I've accumulated stuff. Another thing I can do is do a JOINING FETCH and get three, you know, however long that takes to get the whole thing. Another thing I can do is go is is do a... well, okay, another thing you can do is do a rewind and let's say I get only one group, then I wait for two to get a full buffer. A fourth thing I can do is do a rewind and a JOINING FETCH and in the best case I get SUBSCRIBE semantics instantly as far back as I want to go. In a second best case, I get it via JOINING FETCH which is going to take longer, but still I'll still get it.

**Will Law:** But in all three of those cases, you had to do a JOINING FETCH. So how is a rewind parameter plus the subscription better than the subscription plus the JOINING FETCH?

**Martin Duke:** Because the JOINING FETCH is obviated if I get all the groups I want from rewind.

**Will Law:** But that would... if... and that occurs if they're all in cache. But if they're all in cache, your JOINING FETCH will be instantly fulfilled...

**Martin Duke:** No, because the cache may not be complete.

**Will Law:** Right. But your point was if the cache is incomplete, you still need to do JOINING FETCH and that the benefit of the rewind parameter...

**Martin Duke:** No, because if I have any objects... if I have any objects in the cache I can... I can deliver them via rewind, whereas they have to be complete to deliver by via JOINING FETCH.

**Will Law:** Right. That's the difference. Okay.

**Martin Duke:** Like I may not even know if the group is complete, but like so I may have to do a FETCH just sort of speculatively in case there's missing objects.

**Will Law:** Yeah, which I think you do. You do need to do it speculatively because the player requires those segments to start and it can't... it has no a priori knowledge of what your cache state is, so it has to do the JOINING FETCH. So it's always... the OTT player is always going to have to do the JOINING FETCH.

**Martin Duke:** Again, this is not an attempt to eliminate JOINING FETCH. This is an attempt to get early group... early groups faster by relaxing fidelity requirements.

**Will Law:** Well, I think you could entirely eliminate JOINING FETCH, but we maybe will get to the issues later because there is a proposal for that.

**Martin Duke:** Yeah. Gwendal.

**Gwendal Simon:** Yeah, I was about to say that it's a bit disappointing to not try to replace JOINING FETCH because JOINING FETCH is generating a lot of negative comments despite its features and this is an opportunity to to do this. And well, I mean I was just following what what Gwendal was saying that anyway we need to do JOINING FETCH on this.

**Martin Duke:** Well, we have our... I mean, we had a long discussion about this and we decided the only problem we had was was head-of-line blocking. So this solves that problem. And there are people who really want to keep JOINING FETCH for whatever reason. So, like I mean, like I don't really care if we keep JOINING FETCH but I'm trying to respond to what the group decided in Boulder. Cullen.

**Cullen Jennings:** Um, this is going to be... this isn't for or against this, it's just trying to understand the pros and cons relative to JOINING FETCH. So my understanding of the head-of-line blocking problem with JOINING FETCH was very much that this happened in the cases where you might have a layered codec and like, you know, other layers were blocking base layer information type thing. Now it always seemed like if your JOINING FETCH could be applied to you only want the FETCH on the base layer and you could use multiple FETCHes to get the other layers, that that really allowed you to use all the prioritization mechanisms and timeout mechanisms to get the right thing that's happening and I just like when I read all this I don't really... this seems like for practical use cases it's going to really take away my ability to make sure that the priorities happen in the right way to get the right layers at the right time in the use cases where this might matter. So I'm having a hard time just sort of figuring out what are the use cases exactly where there's a head-of-line blocking problem and then does this improve them or is there an easier way to improve them some other way? That's... that's what I'm trying to get my head around. So could we... I mean what... can you... can you explain more the use case where this really... but which is targeted at? And let's just assume that all the right groups have been that the relay's cached everything it received in the relevant time zone. That's a whole separate issue of if the cache is incomplete, I don't think this works at all. But let's... let's ignore that issue assuming the cache is complete.

**Martin Duke:** Well, if the cache is complete, then there's no benefit relative to JOINING FETCH. because... I'm going to mute you because it's echoing, Cullen. Um... if the cache is complete, if I have every object in all the groups that the subscriber wants there, I mean you might as well do JOINING FETCH, it doesn't matter. Um... except that you might want SUBSCRIBE semantics instead of FETCH semantics for reasons. Like, I mean even if the cache is complete, if your bandwidth is limited, you might want to just start tossing stuff, right? Um... let's see. If the cache is... if the cache is not complete, like there are some objects in the group but not all of them, like you're missing certain layers, you don't know what you're missing etc. then it would enable but all the groups are present, it would enable you to just deliver what you got rather than go all the way upstream to get the objects.

**Cullen Jennings:** I still think that we've got to get really straight about what our use case is. of like if... if this only works... like this is completely unspecified for how it works when the cache is incomplete. In a way it... and works by I mean the end device knows it got all the information so it can process it. Um, so we'd need to define what the relays do when it's incomplete in a really clear way or we need to hit the um... or but I mean I think that the realistic use case is the cache usually is complete. So I don't know. I... I feel like we we sort of need to get our our use case a little bit straightened out here.

**Martin Duke:** Okay. Mike.

**Mike English:** Yeah, uh, I just wanted to speak to kind of the meta issue here and express a concern that people are asking to revisit the JOINING FETCH discussion that I thought was pretty well settled. Um, I was happy to let go of JOINING FETCH, um and we talked about it for a long time and everybody decided no, we don't need to get rid of that, like we've got, you know, this little gap and I feel like this is a... an answer for that little gap and we should just figure out those details and be done with it. Otherwise we're going to like just go back in circles again and again. I would like to move forward and ship a spec.

**Martin Duke:** Thanks Mike. And just now I've like I think processed Cullen's thing. Um, if nobody wants this, if nobody wants to use this, like let's throw this away. I'm not here to create work, I'm here to try to solve a problem that I thought the group expressed. If everyone's like no, we actually don't have this problem, great. Let's not do rewind. I have... this is not a baby that I cherish. Victor.

**Victor Vasiliev:** Uh, are we... are we currently at discussion or clarifying questions just in case?

**Martin Duke:** Uh, I believe my next slide is... actually what is my next slide... wait I got the controls now, never mind. Uh, I was just going to talk briefly on implementation then run into issues and just kind of summarize coding efforts. So like if nobody wants to do this, that's a signal to save us a lot of presentation time. So why don't we... let's not get into the details right now because the details will come. But uh, yeah. This is as good time as any to say like I hate this or please do this.

**Victor Vasiliev:** Okay, so here my thoughts on this. So uh, like this is something I think I pitched like two years ago when it was called backfill. Uh, when it was like we were discussing SUBSCRIBE and FETCH and I remember people really hated the fact that it like does not really work consistently because of dependence on the cache state. And I can understand this is like if I want the latest three groups usually I just want latest three groups and like the really wonky cache thing doesn't really do me any favors especially given that as far as I understand this doesn't really immediately tell you the state of the cache. Uh, so you don't even know if you should do JOINING FETCH or not. Now there is a generalized version of this proposal that actually kind of solves this problem. So there is an idea which I don't remember it's like SUBSCRIBE_FETCH or whatever it's called where you are doing a FETCH but the relay serves you data as a SUBSCRIBE and you if it's a large range you can tell it how many objects per second you want so you can get a video playback. And this is like not novel, this is basically how protocols like RTMP work which is like where you just uh, and that like this proposal is basically the special case of that with fill timeout equals zero. Uh, I do wonder if... so this prop... the SUBSCRIBE_FETCH thing I mentioned is mostly more interesting for applications like VOD and it doesn't really solve fully the problems that people have with JOINING FETCH because you still need to like two separate subscriptions. And this kind of has an interesting aspect that this all objects arrive on the same subscription. Uh, but again like the fact that they cannot rely on this is kind of weird and leaves it in the weird state.

**Martin Duke:** Okay. All right. So uh it is true that you can probably even if you have to go do upstream FETCH you probably still can avoid head-of-line blocking if you're using SUBSCRIBE semantics. If someone wants to write that draft or PR and people like it better, that's fine. Mo.

**Mo Zanaty:** Yeah, um I didn't see anything about um the message so I assume you're still piggybacking on whatever subscription filters can already appear in which is including REQUEST_UPDATE. So while you know it's presented as a pretty narrow, you know gap to fill in in FETCH JOINING FETCH handling, I think more broadly people are going to interpret this and try to use this in general for trick play and especially if you can do it in in REQUEST_UPDATE, I can do an update and you know and grab an arbitrary number of groups back and change my subscription filter locations to to get what I want. So I think we need to be open-minded about what this would really end up being used for the way it's currently spelled. I don't think it'd be limited to that gap.

**Martin Duke:** Well it's... well it's defined from some largest object, so uh in principle you could do that but I don't know that it allows for a lot of trickiness. Like largest object doesn't change, the initial largest object sent in the SUBSCRIBE_OK doesn't change. So that's... that's the point it's going to be from. And if if you're asking for something too early, the publisher could just say no because this is a best effort mechanism.

**Mo Zanaty:** But a REQUEST_UPDATE will have a new largest object and you can you can calculate whatever rewind groups you want from that to do whatever you want, right? So...

**Martin Duke:** Largest object is comes from... well no because largest object comes from the publisher and the like REQUEST_OK does not have REQUEST_UPDATE leads to REQUEST_OK and REQUEST_OK does... I mean maybe it has a largest object parameter. It was not my understanding of how the protocol worked, but it keeps changing so I don't know.

**Mo Zanaty:** We used to call it largest object. I think we're now calling it the joining location, right? And we are saying that updates do update the joining location, right?

**Martin Duke:** Okay, well then then you know then we'll have to fix the draft again. I don't... like stuff keeps changing so I can't keep track.

**Mo Zanaty:** Just back to the higher-level question. Do you expect people to use this for trick play? Because I know we had some open issues around wanting SUBSCRIBE semantics for VOD. Do you expect people to use this for trick play, VOD?

**Martin Duke:** I don't know what trick play is.

**Mo Zanaty:** Uh, just play a VOD, you know, with random seeks and stuff like that. Do you expect people to to use this for stored playback with, you know, non-sequential...

**Martin Duke:** Um, I have not thought about that at all. I don't know.

**Mo Zanaty:** So this is not intended at all to address that. And it's an accident if it's used for that.

**Martin Duke:** I mean, right now, yeah. But like I say, I mean, people expressed a desire for for some of these properties. So um I'm providing the properties and and the group can tell me if they find it useful or not.

**Mo Zanaty:** Okay. Suhas.

**Suhas Nandakumar:** Uh, I do... just to go a bit in history, right? Like my... my first proposal of subscription filters had going back plus or minus n, uh, either forward or backward when I presented this in Denver or Boulder, like two and a half years ago. And and as part... one thing that came out of the discussion is that I was very clear why we should not mix the past semantics and the and the current or future semantics into one API because of all the edge cases it would open up. And and hence uh going to... we dropped the something like equal to equivalent to rewind back then and adopted FETCH so that it's very clearly defined semantics where FETCH requires uh an application that's using to find all the answers about the range it requested for, either it's available or not available, and it's okay to wait. And and a... a player that's built to kind of buffer a couple of seconds or six seconds would want that answer to be known before it can smoothly play or not or give up or do something about it. And in that given given that's the use case that JOINING FETCH or FETCH is solving, rewind definitely would not solve that that use case. On the other hand, if at all we we are thinking about head-of-line blocking with uh FETCH or FETCH mechanisms and we want to make it more parallel, there are two options today that we can do. One, we can definitely use multiple FETCHes, that way an again the player is the one who has who has to make the final decision on how it wants to stream these things together to play out. It can make that multiple FETCHes, which is no changes in the draft required. Or you would uh enable FETCH to do multiple uh streams, which would give you something like what we have in the rewind, but but again that requires more complexity on the player, which it would do in the case if it divide divides its request into multiple FETCH requests. So I kind of feel that, you know, either we can go go that path, and I agree with Mo's point about, you know, if we are... I'm really getting hard to figure out, you know, what's the use case where I would start using it, which is not SUBSCRIBE, which is not FETCH, which is not JOINING FETCH. Um, and that's where I'm a bit struggling. As far as the proposal what you have, I'm I'm not saying it's it's bad. I see what it's solving as tech from technical perspective. I'm not able to figure out how it solves the the use case that we intended to solve.

**Martin Duke:** Okay. Well all right, let's see, a bunch of things. Um I think the best effort nature of this like handles a lot of use cases because the publisher can always say no if it gets too hairy, like sort of that's a very high level response to that issue. Um clearly... so I mean I think clearly to me this avoids head-of-line blocking for reasons that are... I mean I think are evident and that was the stated thing. Um I I'm very happy for a bunch of people to say this does not solve any use case they have. I would be interested to hear if somebody say this solves my use case. And if nobody says this solves my use case, I think we should abandon it. Luke.

**Luke Curley:** So I think this is close. I think the main thing that really worries me is actually the um... I the the fact that it's unreliable and based on cache state. Um, so in an ideal world, for example, like you want to start three groups behind. I really just want to start a subscription minus three groups and if, for example, the most recent group is in cache, start delivering that to me immediately while um we go and backfill the previous stuff. So like on this slide like can't prevent cheating by fetching objects. I think you actually want the cheating. You want the case where the relay if it doesn't have something in cache to start go getting it, but it can still deliver things that it has in cache to you. Um, so is that like a modification of FETCH that doesn't have head-of-line blocking? Like that could be one way of doing it. I think subgroups just need to be delivered in parallel is really like... and and you should get them. I don't want to have to deal with a case where like just because I hit an edge node that didn't have something in cache I have to change my behavior. Um, I really just want to say give me the latest three groups' worth of subgroups.

**Martin Duke:** Okay. So... so like Victor you would like this to not be best effort. Um, fair enough.

**Luke Curley:** Yeah, I would like it to... I mean, if obviously if a subgroup no longer exists, like the relay can't get it, it fell out of cache, the original publisher doesn't have it, then yeah, like reset it, you know, drop it explicitly the same way SUBSCRIBE works. Um, but you should should go back and try to get it.

**Martin Duke:** Okay. Well, I mean, like I'm happy to solve whatever use case people have. That said, like we did just have Suhas saying we tried that and there were all these bad edge cases. So I'm a little leery of just saying yeah that's fine. But... fair enough. Ian.

**Ian Swett:** Sure. Um, yeah. I mean, I kind of think I agree with um what was just said. Um, in the case of if you want to go four groups in the past, you know, if you only have one group in cache, you could start serving that one group immediately and then go upstream to rewind for, you know, the four groups to minus one like the range you're missing basically. Right? And I think that that would actually provide like a more reliable behavior of like I mean the whole point here is to like as the subscriber you are saying this is the thing I want and the publisher's job is to like do their best effort to like give the subscriber the thing they are asking for. Right? Like so like this is why it's nice to have a semantic like this, which is like I am expressing the thing I would like. Like go do it. I don't care how. Um and systems like that tend to be a little bit more robust because you can optimize them or not. I mean, worst case scenario you're like, I don't know what the state of my cache is, I'm just going to go upstream for everything and like proxy it through. I don't know. So...

**Martin Duke:** Okay. Gwendal.

**Gwendal Simon:** Uh, you are solving my use case. This is the magic sentence we wanted to hear, right? Um for... for switch, um for you are solving one use case which is that JOINING FETCH and SUBSCRIBE requires two bidirectional um connections and uh you would like SUBSCRIBE to not start before the JOINING FETCH to finish so that you have a smooth continuity between the FETCH and the SUBSCRIBE. You can technically do some stuff like this with priorities, but it can become a nightmare if you never catch up the live feed. And so you you have something which corresponds to one use case which is uh you want to serve with only one bidirectional um stuff that you have in orders. So this is... this is good. This is something which which would be required and uh this is something which is an improvement of JOINING FETCH. Um so it's something that could be useful for in just for this case, except that we don't want the relay or the publisher to send to omit gaps. We would like to have um the rewind to start only with consecutive objects in the cache. Meaning that you don't want gaps. You you if you if you ask for five in the past and if you have 1 3 4 5, you would start from three and not from one because two is a gap.

**Martin Duke:** That is what rewind does.

**Gwendal Simon:** Okay, so in that case, that would solve my use case for this.

**Martin Duke:** I'm sorry, were those groups 1 3 4 5 or objects?

**Gwendal Simon:** Groups.

**Martin Duke:** Okay, yes, then that's that's what it does. Alan.

**Alan Frindell:** Yeah, so I had... like I did write a draft that was sort of like a rewind++ that added the subscription like added the logic to FETCH behind it so that it was always reliable, right? If you said rewind three, then it was going to start serving what it did from cache but send a FETCH upstream. Now if you think through the publisher logic of how that actually works, it's a really complicated implementation and I would not expect most people writing relays to be, like, super eager to make it work with all the use cases. Um, probably people who think it's easy are only thinking about subsets of what MoQ allows and not everything in terms of, like, different subgroups and large gap, like random object IDs and subgroup IDs and all kinds of things that can make it very hairy. But it is possible. Um, so I mean if what people are saying is that they want this, but they only want it if it has the option to to sort of act like JOINING FETCH or like more like JOINING FETCH where it's like I said go back three and like gosh darn it, you better go try and at least give me three. Like I think it can be done. Um, but I'm... so I think Mike dropped in the chat, like, oh I'd rather I don't want to require it but I want to allow it and that's sort of where I ended up as well, which was like, okay, like if people just want to write the simple thing rewind is there and if you want to be like a really cool relay that can rewind even farther, it doesn't cause JOI... it doesn't cause head-of-line blocking, might cause your groups to get delivered in a funny order. Um I think I think the draft, you know, can be written to allow relays to do it without it being problematic.

**Martin Duke:** Okay, thanks Alan. So uh if I can attempt to summarize what I've heard. I've heard a bunch of people saying I don't have a use case for this, which is fine. I've heard a handful of people saying this is exactly what I need, uh Gwendal certainly and and maybe one other person. Uh and I've heard a few people that want um no optionality. That like dang it, you're going to get those those groups. Um and I think the two things I would say to that number one, there are other proposals that Suhas apparently had one and Victor had one and if that's the way the group wants to go, we should resurrect those. Um and I hear people also concerned that that's just a really complicated solution. I think Suhas said that and uh and Alan certainly just said that. So um um does it make sense for me to go through kind of the more the detailed stuff about this draft or I don't know what do you think Magnus and and actually I'll ask the editors too, what are you taking away from like if this is a use case that we want to solve around these is this the right proposal to move forward or should we resurrect something from the past? Should we rewind to uh Victor's proposal or Suhas's proposal?

**Alan Frindell:** So my... I'm sort of where I am almost where we were when we wrote JOINING FETCH, which is like maybe this doesn't solve everybody's use case, but it's it's not that much text and it's not that hard to implement. So I don't object to going forward... I mean, it's more like a mental load, which I think already exists on people using MoQ is like well, what do I do? Do I want SUBSCRIBE? Do I want FETCH? Do I want rewind? Do I need all three? Like um that might be the downside. But like from a can we... so like I if if there's enough people who are like no, we really need this, and this shape is fine, like um I I don't see reason to lie on the road and say we shouldn't have it. Or we could always do it as... like as it's written as an extension too, so people who want it can implement it in the marketplace will decide who implements the extension.

**Mo Zanaty:** I think there's a higher level question of whether or not some functionality like this is is what the group wants and the second question is the spelling of it. Um, the easier thing is the spelling. I I kind of disagree with the spelling because having worked on the filters, we originally had we originally added that location filter and uh we removed that because it was a lot of text. But most of the text was actually removing all of the subscription filter and replacing it with a generic mechanism which just you just specify the location. You just specify a location filter, start and end group and and done. So the rewind would come, you know, like automatically with with that if we just let the the start location be many groups back. Um, so the spelling of it I think would be simpler if we went to the the location generic location filter that we had in the now-deprecated DP PR for uh for filters. That's to me the easiest spelling. The question is whether or not the core functionality is is required. I think for the for the niche use case that's being presented as, you know, a gap in FETCH, I don't think it's use... I don't think that justifies the complexity for that. But I think in general, people want SUBSCRIBE semantics in the past. That's a more general thing that people want regardless of JOINING FETCH, regardless of any gaps of that. Um, so I think addressing that and seeing if the group wants to deliver SUBSCRIBE semantics in general for things in the past, uh is the way to go. If it is, I would suggest we we think more deeply about the spelling and resurrect a generic location filter instead of patching on another few extra code points for for another yet another type of filter in addition to NEXT_GROUP, LAST_GROUP, you know absolute group, all that junk.

**Cullen Jennings:** Uh, I mean I I think our problem here is is we're very unclear on what it is we want and that's why there this discussion's going round and round. And there's a couple possibilities from what I hear that we could want is we want to do a let's say SUBSCRIBE, you know, three in the past. And the answer of you might get it, you might not, we don't know and it depends on the relay implementation is not going to work for anyone. It's going to need to either be you get it or you get an error or you don't get it if the cache doesn't have it or something but we have to get specific about the row... how this works, right? And that's right now it's really only the spelling and it's not how it works or what it does. And I think that that's that's why there's so many questions about the sort of use cases and and other parts of this. So if we're going to say that yes, you always get the data if it's possible to get the data and if it's not possible to get the data you get an error, that'd be one solution. Or you could be like this is an optimistic thing that you'll get if the cache is complete, you'll get that and if the cache isn't complete, you won't get it. Those are two very different things and we could do either one of those but right now it's not clear which one of these there are and I think we'd have to get specific on the use case and the requirements and then we could easily write this.

**Martin Duke:** I I think it's more the later thing, although um cache complete is a...

**Cullen Jennings:** But I don't think what Gwendal wants is the later thing is what I heard him describing his use. I So I agree, this is sort of the later thing. Fair enough. But I don't think that's what Gwendal wants. So, uh I don't know. Gwendal, if you want to comment on what you want? I shouldn't speak for you, but...

**Gwendal Simon:** Well, what I want is to have one unique bidirectional stream and to be able to serve from this stream groups in the past.

**Cullen Jennings:** Sure, and if there's one object not possible in that, you just want it closed, error, or...

**Gwendal Simon:** No, if it is... I mean the the uh if all the groups are consecutive groups, meaning no gaps, uh we serve them and we don't serve anything before the gap.

**Cullen Jennings:** And would you expect that if the cache didn't have that, would you be expected to go upstream and do it? Like let's say you're the first subscriber to this relay, there's nothing in the cache.

**Gwendal Simon:** Well this is one of the proposals that we discussed in the draft issue is to say just one flag in the rewind to say if I really want to have something... yeah, this is optimistic or not, right? But if I really want to to fill the the gap then it's it's a JOINING FETCH. So I don't want to do the rewind. But if I can serve directly from the cache, then it's good, you know. You can go with one flag we could reconcile rewind and FETCH. I don't understand why we want to not uh reconsider FETCH... JOINING FETCH for this.

**Ian Swett:** Uh, yeah. I think I think everyone would like a faster way to join and like the ability to join. I'm sorry. I'm sorry, Cullen. Um, can you respond? I mean, if you want to respond, that's fine. I have to mute you because of the echo that... No, no. Sorry, my apologies for the muting. I it's fine, you muted me. I did not want to respond. Thank you.

**Ian Swett:** Okay. Yep. Um, like everyone wants to be able to join faster. Um, we we've sort of actually created a problem for ourselves in the existing design, uh which is like the default filter is basically like largest object and that inherently creates a situation where you end up with like half a group which is basically useless. Like no one really wants that. Like that's like what I if I start halfway through a subgroup, like that that is not a thing I can do anything with as a... um as a client. for example. So, like I think we should kind of recognize that and as such, you know, especially for the current group option there's two states of the world. Either the relay has a cache and it probably starts the at a group boundary, the current group or prior, or it has nothing and it can send the current group thing upstream. Um, which is why I honestly think just like undoing whatever we did in draft eight or whatever to like get rid of current group would possibly be fine for now, which is like, you know, those are your two options. Like someone's got to be able to serve the current group. If no one can serve the current group, no one can join and that's like a self-solving problem of itself. Like so like what you're going to do? Um, I'm not saying that's the optimal way forward in the long term and like SUBSCRIBE delivery for things in the past would be very interesting. But um, and I think arguments have been made that like starting n groups back has similar complexity to starting at the current group, but I think there are ways in which starting at the current group is special because really like if you can't start at the current group like you can't join until the next group group starts. Logically, there's just no way to start. So anyway.

**Suhas Nandakumar:** Um, just to say that yes, uh I did present something like this in past and I I strongly recommend we don't go revisit unless it's it's solves a real use case. Um, the... the thing that convinced at least me back back then when we had the discussion was going multiple groups in the past and having SUBSCRIBE semantics was not useful for two reasons. One, because you're going in the past you have that means that you already have a time budget that you can fill. That's no longer live, you're not on the edge. And since you're going in the past that means that you want to fill your buffers in exactly the things you need and you do not want gaps. That was the reason why moving into the FETCH direction was sounded right back back to me. On the case of should we allow to join to the beginning of the current group? Yes, that was also one of the filters that we had in the original proposal. Uh and I'm not against that uh option. Uh but also we need to keep in mind that that would work really well if you have a static GOP size of say two seconds or five seconds, but it would not work for 30 seconds GOPs or like the GOPs which are... they you don't you don't want to kind of keep sending keyframes unless it's needed. But but that's... that's both are valid valid scenarios and we have solutions for both, sorry for the latter. And for the case where we would want to start from the beginning of the group to Ian's point, if I think adding that would would still still be fine. Um and I'm I'm still not very confident that we should go back add a new semantic that goes back with gaps. Uh because that's one of those problems I'm not a solution for which I'm not able to convince a use case for it.

**Alan Frindell:** Um, so I'm... like for sure like joining at the current group is like a main use case and there's absolutely friction out there and um it's still I mean to Ian's point I still think there's I mean there's this one weird edge case where like you don't have an upstream subscription in the current group but you have stuff in your cache and like if you're willing to discard all of it and go upstream again or just like it that could work I guess. But anyway it just gets it gets messy. What I liked about the rewind thing was like it sort of defined when that was safe, which is like oh well I already had an upstream subscription that started before the current group, which means anything it's there is I'm going to get it anyway. Um, so but like solving for the current group mostly like I if that's what we want to do it's maybe scope down, it remu... it sort of removes the need to say like oh we should flow control this, although Suhas's point about dynamic GOPs is also potentially valid that the current group could be arbitrarily long. Um, yeah, I don't know.

**Luke Curley:** So my goal at least with groups has always been that they're delta encoded. Like that's always been... at least subgroups. We'll just at least say subgroups are always meant to be delta encoded. Like receiving the end of a subgroup is not useful because there's something previous it depends on. And that's always one of the principles I think that really works. You can drop the tail of a subgroup, but you can't drop the start of it. Like you can't just arbitrarily drop stuff in the in inside. Um and I think the problem with latest object is it implicitly does that. It's exactly what Ian said is it it drops everything from the start of a group based on the state of the cache or like whenever you joined and you have to go back and FETCH it. Um, I really just want some way of of making it so that you deliver from the start of a subgroup. Um, you don't give me the tail of it and then make me go and repair it myself. Um, and uh that's and I think latest group solves that in some way like just always start at the beginning of a group. I I don't think you should ever start at the some random object based on the cache.

**Alan Frindell:** Uh hi, my audio working? I just got an overconstrained error here, whatever. Can you hear me? Yes, I can hear you. Okay, thank you. Sorry, firstly I I agree with uh Luke on what he just said about always always starting at a group boundary. That seems reasonable. Intermediate groups are very special cases and certainly not the majority. I wanted to address the discussion around the notion that if we engineer something that if we could just get current group then we're good. I would argue that current group is not magic. My current group might have started 10 seconds ago... I mean, sorry, 10 milliseconds ago. And with a live stream when you start, you you have only one chance to build the buffer and that's when you start your live stream, right? Once you're playing a live stream, unless you change the playback rate, you can't adjust your buffer size. So getting just saying I can I can reliably get the current group is very arbitrary because it it may not solve my buffer. What I need for an OTT player is a certain amount of buffer time, one, two, three seconds, whatever it is, and therefore I want to express that in multiples of my groups. So I think saying that we can get current group only is not a solution. Saying that we can get n groups behind live reliably where n is some reasonable number, I think that is the more general solution.

**Victor Vasiliev:** Uh, so like I feel like the root cause is here that there is a bit of magical thinking around what group does. Like as I pointed out before in MOQT groups don't actually do that much. They're like a naming thing. But really MOQT is about like objects on subgroups and group like there is no difference between object in current group and an object that is like far away in the past group. So joining joining does not make it simpler if you only limit yourself to current group even though that is what application wants to do. So like the key problem why we split SUBSCRIBE and FETCH is like imagine you have a subscription and like let's say there are already like let's say your group is five... like you really subscribes to your upstream and the upstream is already generating media and you're in the middle of the group, so SUBSCRIBE gives you the objects in the group at the at the rate that they are generated and FETCH then lets you catch up to the front. But you can't really requi... like essentially if you require joining the current group you require really to buffer like you would have to like at the point you have subscribed you'd have to buffer all of that in memory and then you'd have to wait until the head is fetched and then you have to buffer that head and then you have to concatenate these together and that is entirely plausible but the current design is you have to do this application at the end subscriber because uh otherwise you're just forcing relays to do arbitrary amounts of buffering for you. Uh and I think that was I think that I think that that was the design tradeoff with SUBSCRIBE_FETCH and I think that was the correct design tradeoff.

**Luke Curley:** I have a question. Um, has anyone... can anyone express a time you would actually want current object?

**Victor Vasiliev:** Uh, it is if you want to do JOINING FETCH.

**Luke Curley:** That's... that's a byproduct of current object. That's not my...

**Victor Vasiliev:** It's the filter.

**Luke Curley:** That's a sideways way of answering my question. Um, but you don't actually... like you don't actually want current object, you want the beginning of the subgroup, like that's my point.

**Victor Vasiliev:** That is the case. Sorry so JOINING FETCH is a mechanism, it is not the thing you want. Uh it is... like large... it is very rare that you would want largest object because otherwise you would just use like group per object or something.

**Luke Curley:** Yeah, yeah exactly. Yeah, for audio you use object for audio.

**Cullen Jennings:** Uh I mean I I'll just add I think I said this in chat, but I think there is one case that we've talked about in the past where you don't really want the middle of the group in the slightest. You want the beginning of the next group. But in the meantime, you would like all of your rate control and buffers to be filled up and running correctly by the time the object that's important to you, which is the next I-frame, arrives. Um, and I'm not saying this is a strong use case, but I'm saying this certainly is a use case that's used sometimes in um in interactive like in real-time conferencing like this particularly where you're using new group request. You're basically subscribing now in the middle of stuff. It's throwaway data until you get the next group and you're sending a new group request at the same time so you get that pretty soon. Um, that's where it's a model that I think is useful.

**Mo Zanaty:** Yeah and Ian to clarify we are actually using current object all the time because what we found is that a JOINING FETCH is a blind guess that that you can handle that, you know, that that rewind. That's could be a very large rewind. So instead, we just SUBSCRIBE directly current object and you look to see what that current object is. If it's, you know, two or three or four, you can JOINING... you can FETCH, not JOINING FETCH. Now you have an absolute FETCH. You can FETCH to to catch up because it's a reasonable catch-up. If you're at object 90 and you know the GOP is 90, you know, 3, then you don't FETCH, you just wait naturally for the next group to start. And if you're halfway in the middle you say, okay, I don't want to wait three seconds for my for my next GOP to start. I don't want to catch up to two and a half seconds of download. So I request new group right now from the sender assuming they support that. So we do actually join at current and we make a decision at that point whether you want to rewind or go forward or NGR to demand a new group instantly.

**Martin Duke:** All right. I I feel like we're getting away from the presentation here.

**Ian Swett:** Sure. I want to validate that, Mo, I agree. Your use case is completely valid. I'm not... I don't love the way it's currently solved in the draft, but but it's totally valid. So like that's clearly a use case we should target and but I think maybe we can even do better than we do today. Uh and I actually got in cue... Martin to to say that I think a mechanism like this I was first very opposed to a mechanism like this because I thought like Suhas said the distinction we made between SUBSCRIBE and FETCH, you know, was sound, but the more I think about it... what worried me about is that I thought the distinction was sound because when a relay is processing things, it's getting ingress objects and it has to decide whether or not to egress them on certain connections. That coming in and going out we want it to be SUBSCRIBE all the time, right? And so you make an instant decision and you forward. So I worried that if some subscribers are, you know, asking for groups in the past and the relay now has to merge that private that past FETCH with the incoming objects that that was ugly. But then when I thought about implementation-wise, all you have to do is just flush a giant assuming your QUIC stack can support a buffer that deep, just flush all the giant, you know, FETCH directly into the into the QUIC buffer immediately and then the forwarding will still happen naturally. The ingress to egress forwarding will happen naturally, but it'll just be at the end of a big queue. So I think the reservations that I had about it before are gone because I've realized that for relay processing it's not a big deal. Uh the merge operation between the prior FETCH and the ongoing live subscriptions is not a big deal assuming your QUIC stack can handle those large queues.

**Martin Duke:** Okay. So I think one of the fault lines that I'm hearing here is like are we like guaranteeing delivery of all the groups that are requested or not? And there there are, as we've said a couple times, there are old proposals to do the former and one thing that motivated this and that I think Alan also brought up was that one of the questions here is where are we putting the complexity? That rewind really kind of punts it to the subscriber to if you really want it all, you got to do JOINING FETCH and all the other stuff because the relay is just going to do the best it can with rewind, whereas um if we like impose a bunch of requirements on what the relay has to do, the relay has to do it and therefore it has to be a little more complex in a way that might be a little more tricky than people think as I think Suhas also alluded to some edge cases. So I'm not... like I hear like a few people interested in a... well actually I'd want to ask one question to Gwendal. Gwendal, you said this solves your use case. Does a guaranteed measure also solve your use case?

**Gwendal Simon:** No, I don't think so. It just simplify every switching. Okay, so it's it's a I think it is a good use case but you know I'm like you, huh, I don't care if if nobody wants to have this...

**Luke Curley:** All right, okay. Gwendal, can you can you clarify what the minimum functionality here would be necessary to simplify your use case? Just to like understand like what's the smallest thing out of this proposal that like would help that particular use case just so everyone knows.

**Gwendal Simon:** Well, you know it is this one bidirectional with subgroup continuous streaming of data, you know. If I mean the the relay has sometimes the group object and subgroup in cache and it can just not deliver it by SUBSCRIBE just because we say no although it's obviously it's super easy to to do so. So it's and we go into this crazy priority JOINING FETCH two bidirectional and changing the priority in the fly if we want to maintain a continuous streaming just because although we could just because we decided that it's not possible. So this this idea of implementing a quite simple SUBSCRIBE with some data that you have and if you don't you say no and if you have you say you deliver it, it looked like a simple semantic but but okay, I mean...

**Alan Frindell:** Yeah, so I had... like I I did write a draft that was sort of like a rewind++ that added the subscription like added the logic to FETCH behind it so that it was always reliable, right? If you said rewind three, then it was going to start serving what it did from cache but send a FETCH upstream. Now if you think through the publisher logic of how that actually works, it's a really complicated implementation and I would not expect most people writing relays to be, like, super eager to make it work with all the use cases. Um, probably people who think it's easy are only thinking about subsets of what MoQ allows and not everything in terms of, like, different subgroups and large gap, like random object IDs and subgroup IDs and all kinds of things that can make it very hairy. But it is possible. Um, so I mean if what people are saying is that they want this, but they only want it if it has the option to to sort of act like JOINING FETCH or like more like JOINING FETCH where it's like I said go back three and like gosh darn it, you better go try and at least give me three. Like I think it can be done. Um, but I'm so I think Mike dropped in the chat, like, oh I'd rather I don't want to require it but I want to allow it and that's sort of where I ended up as well, which was like, okay, like if people just want to write the simple thing rewind is there and if you want to be like a really cool relay that can rewind even farther, it doesn't cause JOI... it doesn't cause head-of-line blocking, might cause your groups to get delivered in a funny order. Um I think I think the draft, you know, can be written to allow relays to do it without it being problematic.

**Martin Duke:** Okay, thanks Alan. So uh if I can attempt to summarize what I've heard. I've heard a bunch of people saying I don't have a use case for this, which is fine. I've heard a handful of people saying this is exactly what I need, uh Gwendal certainly and and maybe one other person. And I've heard a few people that want um no optionality. That like dang it, you're going to get those those groups. Um and I think the two things I would say to them number one, there are other proposals that Suhas apparently had one and Victor had one and if that's the way the group wants to go, we should resurrect those. Um and I I hear people also concerned that that's just a really complicated solution. I think Suhas said that and uh and Alan certainly just said that. So um um does it make sense for me to go through kind of the more the detailed stuff about this draft or I don't know what do you think Magnus and and actually I'll ask the editors too, what are you taking away from like if this is a use case that we want to solve around these is this the right proposal to move forward or should we resurrect something from the past? Should we rewind to uh Victor's proposal or Suhas's proposal?

**Alan Frindell:** So my... I'm sort of where I am almost where we were when we wrote JOINING FETCH, which is like maybe this doesn't solve everybody's use case, but it's it's not that much text and it's not that hard to implement. So I don't object to going forward... I mean, it's more like a mental load, which I think already exists on people using MoQ is like well, what do I do? Do I want SUBSCRIBE? Do I want FETCH? Do I want rewind? Do I need all three? Like um that might be the downside. But like from a can we... so like I if if there's enough people who are like no, we really need this, and this shape is fine, like um I I don't see reason to lie on the road and say we shouldn't have it. Or we could always do it as... like as it's written as an extension too, so people who want it can implement it in the marketplace will decide who implements the extension.

**Mo Zanaty:** I think there's a higher level question of whether or not some functionality like this is is what the group wants and the second question is the spelling of it. Um, the easier thing is the spelling. I I kind of disagree with the spelling because having worked on the filters, we originally had we originally added that location filter and uh we removed that because it was a lot of text. But most of the text was actually removing all of the subscription filter and replacing it with a generic mechanism which just you just specify the location. You just specify a location filter, start and end group and and done. So the rewind would come, you know, like automatically with with that if we just let the the start location be many groups back. Um, so the spelling of it I think would be simpler if we went to the the location generic location filter that we had in the now-deprecated DP PR for uh for filters. That's to me the easiest spelling. The question is whether or not the core functionality is is required. I think for the for the niche use case that's being presented as, you know, a gap in FETCH, I don't think it's use... I don't think that justifies the complexity for that. But I think in general, people want SUBSCRIBE semantics in the past. That's a more general thing that people want regardless of JOINING FETCH, regardless of any gaps of that. Um, so I think addressing that and seeing if the group wants to deliver SUBSCRIBE semantics in general for things in the past, uh is the way to go. If it is, I would suggest we we think more deeply about the spelling and resurrect a generic location filter instead of patching on another few extra code points for for another yet another type of filter in addition to NEXT_GROUP, LAST_GROUP, you know absolute group, all that junk.

**Martin Duke:** Mo don't location filters only apply to future objects?

**Mo Zanaty:** Well subscription filters in general, yes, they they do but you could... the syntax doesn't say anything about that. It's just a implied meaning that if you say something in the past, the relay can automatically jump to the head and ignore that you said 10 groups back. Um...

**Martin Duke:** All right. I mean, that's the spelling issue. I mean, we can... okay. Cullen.

**Cullen Jennings:** Um, so the most important thing I heard today on all of this was actually what Victor said and it reminded me that on our previous discussions of this we were like look, this is the API people want, but people are confusing the API they want in their clients and the simplicity of that API from what happens over the wire. And the real question is do we cash... do we force the relays to do all the complexity in the caching of this or do we force the clients to do the caching of this? And I think that the right design decision is to push this particularly early join complexity where the where there's you have to do different things depending on whether the cache is filled or not on the relay that we push that complexity into the client library and that the memory for it into the client library is probably where we want that. So I think that that's really should help drive our architectural design no matter whether how we ever do this rewind or stuff, but that combined with what's our crisp requirements I think we... we should get to this easily. So that... that's the thing that popped out as helpful for me today.

**Martin Duke:** So Cullen, you may or may not agree with this, but I think this might be a vote for something like rewind because it's it's potentially quite simple at the relay.

**Cullen Jennings:** Uh, I do not think you have written down in the slightest what it needs to do in the relay. If if the implementation for the relay is if it's not in the cache it ignores it, that's fine, but that won't meet any of the use cases that people have because then they'll have to write the code to deal with all of it on the simplicity side just like FETCH. They'll have to do the JOINING FETCH at that point. But if it is no, the relay will do everything it can to satisfy the rewind request, then it's a very different thing. And like we're unclear of which of those two things it is yet, right? So that's...

**Martin Duke:** Well I mean you you just wanted to push that to the client, right? That's that's what you just said and that's what this is doing.

**Cullen Jennings:** No this is pushing it to the relay is my read of it, but... okay. but but that's okay. So but like either way I guess I I want to push that to the client and if that's a vote for relay that's a vote for... I mean for rewind that's a vote for rewind right. Um but I think we need to get crisp on that. I'm not I'm not for or against rewind.

**Martin Duke:** Thank you. Suhas.

**Suhas Nandakumar:** This is more of a observation on current group plus cache fill if the current group is not there or the largest group is not there. I I think that kind of breaks the whole point. If I'm subscribing to the current group and I can still I can wait, then probably I can do JOINING FETCH. Or if I do not want to wait, then probably I should subscribe to the next group. I I this this in-between I I want current group but I also want to wait for current group to fill, then I would rather say why can't we just do the next group, which we already have the filter for that today? So I kind of want to really understand why waiting with current group would not work with JOINING FETCH or just going to the next group would just work because anyways you're ready to wait.

**Martin Duke:** I feel like we're there's a lot of entrepreneurial design activity here rather than just kind of like we're just increasing the number of options to address this rather than decreasing them. But okay, Victor.

**Victor Vasiliev:** Yeah I'm never mind.

**Martin Duke:** Okay. Will.

**Will Law:** Yeah, I just a counterpoint to Cullen's position that we can keep things very simple on the relay and just magically move this complexity to the client. I don't think we can. The client does not know the relay's cache state. It can ask the relay for that cache state but it's always going to be an RTT behind the relay in knowing that. It has to ask for it, has to get a response. So that can lead to a race condition where it's perpetually behind. Plus it's a performance issue that we'd much better off just making this decision on the server and implementing...

**Martin Duke:** Well, no, so the... so I think the the client complexity is that I am sending like if I want everything and I want it as fast as possible, then I am sending SUBSCRIBE plus JOINING FETCH plus rewind and um depending on the cache state I'm going to get it's going to come in different streams basically.

**Will Law:** That's fine. Clients can deal with... can realign content, but the argument is is rewind giving you any better performance than just SUBSCRIBE plus JOINING FETCH? You have to do a JOINING FETCH and in the case where your rewind is fast because the objects are in the cache, then your JOINING FETCH is going to be fast too because it's going to pull the objects from the same cache and return them to you.

**Martin Duke:** Well no the if if they're both there the JOINING FETCH is only going to deliver things that are not in cache, in groups before the ones that are not in cache.

**Will Law:** Yeah I was the hypothesis I was saying is a SUBSCRIBE as we have it today plus a JOINING FETCH compared to your draft plus a JOINING FETCH. And I would argue that in the cases where your draft is fast, so would the current implementation with the JOINING FETCH be fast as well because the objects are in the cache. It's just the JOINING FETCH guarantees how many objects come and rewind doesn't.

**Martin Duke:** Fair enough. Ian.

**Ian Swett:** Um, sure. Uh, two things. One is um I agree that, you know, the API surface is an important aspect to parrot what Victor and Cullen said, uh but I also think sending the intent upstream allows relays and the network to like make optimizations that like the client just fundamentally can't by itself whether it's cache state or otherwise, right? Like I mean, maybe the client sends something to a relay that doesn't actually have the objects in cache but it's like, oh, I'm in a data center where like it's right over there and so it can go grab it. Um and so I think I really like systems that try to provide intent. Um, but I agree that like lack of predictability of the response is is annoying. Um, I guess the other thing is like to go back to why would JOINING FETCH not be as fast? Like um I mean there are ways to to kind of work around it but uh like one of the example situations that we have discussed is, you know, I have uh every other frame is like a dependent frame and so you know I have 15 frames per second and 30 frames per second in another enhancement layer and you know they're like even-odd for example. Uh in such a circumstance with a JOINING FETCH, I could only deliver the first object in the group if for some reason um I hadn't gotten that second object. And so it end up in this weird spot where I can give you the last half of the group by SUBSCRIBE and I can give you the first object via JOINING FETCH and then I get stuck. And the solution to that is the fill timeout thing of saying like, oh, only give me things in the cache. But then you don't get the enhancement layer at all. Like it just it gets complicated and weird. Like the text about how to optimally join starts getting like more and more complicated about like well you can do this combination with this timeout and this param instead of just being like I want to join the track, give me what, you know, you think I should have to join the track. Right? Like I think joining tracks is like an important thing that we're doing here and that's part of the reason why we've discussed it so much, but I also realize it's not trivial. So...

**Luke Curley:** So I was going to uh answer what Cullen's points earlier. Uh there's an idea that latest object is easier for a relay than latest group. Um but they would be implemented the same way. Basically if a relay has an active subscription, it serves a new person via that subscription. And if it doesn't, it sends the subscription upstream. Uh the only reason why latest object might be easier is if you have a fragmented cache, but you kind of only get that today because of latest object, if that makes sense. Like it causes its own problem. Uh in either way you're going to need the relay is going to have to support JOINING FETCH. Like it's basically JOINING FETCH is a requirement. Um 99% of subscribers are going to do it, the relay is going to have to have a way to backfill if it had a fragmented cache. Um so I I don't really see a reason why you shouldn't have latest group. It's not more complicated for the relay, they have to do it anyway and largest latest object is what's causing this fragmented cache in the first place.

**Alan Frindell:** Sorry my Mac took the wrong moment to put my screen bar over the bottom. Um I just the more we talk about this, the more I'm convinced both that there's probably a better solution than what we have written down right now and it will take us a very long time to find it. It's already we're already four years in and we haven't found it and there's a bunch of smart people working really hard on it. So I think that my best proposal is we don't do any of this, we make the minimum changes we can to draft 17 to ship it which I put in the chat and I presented in Boulder but it's like there's already a PR for one basically both pieces that are like relatively close. So if people really want to solve the head-of-line blocking problem, which is the problem we said we wanted to solve, there's short solutions and we can be done with this for now and then after V1 ships, we can make MoQ V2 with the best freaking subscribe verb and it can ship whenever it needs to. Um but if we try to fix this, it will take another year to get agreement on anything. Um, so that's my two cents.

**Victor Vasiliev:** Regarding on whether complexity of like assembling head and tail of the subgroup makes more sense on the player versus the relay, uh if you're most case if you're doing a player with any amount of buffer you already have groups that you arrive out of order and you have to stitch them together. So like you already have to have logic in the player which puts things in order when they arrive out of order. So you if you're doing that on per object basis instead of per group basis that will happen automatically and JOINING FETCH does not actually affect you in slightest. Uh...

**Mo Zanaty:** Am I up? I guess so. Um can someone clarify I thought we did already uh merge or at least agree to uh the uh the FETCH timeout. Is that still in flight or we don't have consensus yet?

**Alan Frindell:** I think was waiting for Victor's stamp. Is that right? It's the PR's been up forever. We talked about it two weeks ago and made the changes that we talked about there. Most of the editors approved it. So it's close. I can't remember exactly what the last blocker was. Um...

**Mo Zanaty:** Assuming we had that in the head-of-line stuff people keep talking about is moot, right? And it's only about whether or not you want multiple subgroups delivered or a what single stream. Isn't that what we'd end up with?

**Alan Frindell:** Right and if you there's one piece of the filters PR which would give you control over that potentially. which is like, you know, I'd say I want to subscribe but I know that I want to join this thing, but I don't want to head-of-line block on anything but subgroup zero because the other ones are enhancements I don't need to join and I can go FETCH those later if I want to if I had time etc. So anyway I think it works.

**Mo Zanaty:** So Martin as the author of this, do you agree that if we had the JOINING FETCH timeout, FETCH in general timeout, that and the ability to FETCH different subgroups if if you wanted subgroup delivery, that that would do the same thing as the this rewind or do you think there's some other missing or timing problem?

**Martin Duke:** Uh I mean it's slightly different in that subgroup filtering like implies you have to sort of like pre-give up on subgroups rather than uh like giving as many subgroups as you can handle, but I'm not going to lie down on the road over that.

**Mo Zanaty:** And it requiring subscriber knowledge of the subgroups rather than publisher publishing whatever it wants for subgroups. Yeah, that too.

**Suhas Nandakumar:** I the... just trying to respond to Ian or probably a question to Ian more than a response. thinking a little bit more about the JOIN kind of message if we had a join message that would just automatically know like for me to join the track at the right point. My only kind of thing that I'm concerned about that is like how would relay know should it should it join you from the beginning of the current group or should it join you from the uh next group because relay has no idea of is a static GOPs, how long the GOPs are, or dynamic GOPs. Um at some point it becomes more of a client decision to even influence that JOIN. And and more I think in the if I go in that that direction it feels like oh I can I can achieve that with SUBSCRIBE and JOINING FETCH for example. So that's something I I see something like that might be useful, but I'm I still think that if we start thinking more deeper into it you might have some some of these questions needs to be answered. But but I'm not thought through to say it's a good or a bad thing. But just thought that came through.

**Ian Swett:** Yeah so I think that's a good question and I think that's actually important because I mean we added new group request but um it I'm not sure if it ever gelled ideally with like the design we actually have because there's a number of cases where new group request um as Mo said allows causes you to do like suboptimal things. Um like subscribe to something and then be like, oh actually I don't want that, I'm just going to kill it and like then like actually go in the future. Um but I I mean I think um Alan at some point suggested like basically a max object ID param as one potential option which is basically say like, you know, if if you're beyond this object ID then like send a new group request upstream and don't like satisfy this um don't start at the current group. I mean, if we had time we could do timestamp, something like that. Like I don't think those I think the the idea would be to just forward that intent to the relay and let the relay like um make a good decision on on behalf of the subscriber.

**Alan Frindell:** I don't think it's orthogonal, Alan. It's totally like this is all about joining really. Anyway. Um, I I mean I view that just to be clear, my idea was in SUBSCRIBE you send two object IDs which could be the same. If it's less than the first one, it implicitly does a JOINING FETCH. If it's between the first one and the second one, it sends an NGR upstream. And if it's after the last one, it sets you to next group. So it's like join me in the optimal way and the subscriber's providing the bounds of like am I at the beginning, middle, or end of the group. But I don't know. It's it's just a latency optimization over what Mo's doing right now which is like they get the information back to the subscriber and then they issue it. So like it's it's just a 1 RTT savings. I mean a lot of these things are latency optimizations. I can always do a track status and then like decide what to do.

**Martin Duke:** Okay. Um I close the queue. I I'm not sure we're going to get anywhere else in five minutes. I would summarize this as follows: Gwendal has said this would be useful to him, but he can live without it. Uh there are a bunch of other people who want something sort of in this space but something that isn't really rewind that's got a lot more relay complexity on it. Um Alan and there's like a dozen proposals, some of which are old and pretty well developed and some of which were just sort of engineered in real time here today. Um and I have to agree with Alan's conclusion that we are pretty far from any sort of agreement on this and I think we can live without it. So uh the draft exists, people have filed issues. Um you're welcome to file issues if you like. I'm not going to spend a ton of time on it. I did actually implement this although hasn't been committed to our codebase yet. I know that Cloudflare was working on it. Uh Mike and I might talk about whether we still want to just do an interop for for fun. Um but uh I don't doesn't sound like this is ready to move forward which is fine. I'm happy to not work on it and I think the editors have a plan to to band-aid this these problems with other PRs. So uh Alan.

**Alan Frindell:** I mean I guess that's my question and we maybe the right way to do it is have the chairs issue a consensus call so there's no ambiguity in terms of where we are because some of the issues with JOINING FETCH have been filed since before those consensus calls so I don't want to stomp on the authors of those by saying it's too late and we can't design the the fix here. Um but I would like to understand like can we live with the band-aid like we'll put in we'll put in fill timeout in one shape or another, we'll probably land subgroup filters of some shape or another and that that plus, you know, we can sort of paper over the problems and the working group can live with that or I mean, you know, my job is just to reflect the consensus of the working group so but I need you guys to tell me what that is.

**Martin Duke:** I I um at this point I'm a little less okay putting on my chair hat. I'm a little less inclined to like agree we have a problem than like agree on a solution because if we just say yes, nobody really loves the status quo but everybody has a bespoke solution to this, we're we're going to faceplant. I mean we faceplanted today on this, right? Because some people want well everyone wants something slightly different here um and I I don't think we're going to get there. And it sounds like everyone can survive with with the band-aids. Which to my understanding means that we are pushing this to if if someone wants to try to solve this problem this will go into an extension. You will have to develop an extension for it most likely.

**Aman Sharma:** I mean currently it is an extension. Like it's a draft. Yeah yeah yeah. Your proposal is kind of extension but yes, it's we not expecting to it it's unlikely that we will even if you develop an extension we'll merge it to core but that's unless you use it yeah. I'm I'm happy to send the list a three-way like a a consensus call that says like do nothing, adopt the draft as an extension, or like incorporate it into the MoQ transport. Um and just see where the numbers come out, but I I have my doubts that it's going to come out well. But that's a good way to dispose of this once and for all or at least, yeah, once and for all.

**Luke Curley:** I have a question about when it comes out as don't do anything to the current draft. Are we do do we have enough solutions to be done with the current draft or do we need to keep working until we find better solutions to the issues that are open?

**Martin Duke:** I think at this point somebody needs to build a consensus around some solution to to move forward. I don't think we can just reach a consensus that we hate the current draft and just leave it open-ended. Because that that I think most the band-aids we've developed especially with fill timeout Alan are like I hate the subgroup filter thing ew. Um but like wow you just recreated subscribe by issuing like 15 FETCHes. That's not innovation but um like uh but but I think I think those band-aids are probably as good as we can reasonably do. But I did want to go back to the question of like I mean we talked about adding back largest group like do people really hate that? Like would that not just be like the right thing to do? I mean why would we not want that I guess?

**Alan Frindell:** Can you clarify do you mean setting the filter back to largest group? Like adding a largest group filter option? Okay we're out of time. Yeah, I think if there's a proposal for that we can we can bring it up later. um...

**Luke Curley:** Well it got brought up today that's why I was asking for like feedback from the group.

**Martin Duke:** Okay well we don't have time to take it to the list take it to the list. We don't have time for a queue. All right have a good week everybody.