Session Date/Time: 11 Jun 2026 08:30
[00:02:01] Alan Frindell: Is there anyone online that will introduce themselves? I I haven't been able to scrub who's online, and if not, feel free to just turn on your audio if you want to.
[00:02:14] Mo Zanaty: Paramount?
[00:02:24] Alan Frindell: Okay. Is that it? Anyone else? Alright. Moving on. This is the idea of Note Well. It looks you've seen it before, but it actually, some of us are new, so maybe not. This describes sort of the the the ultimate property implications for you attending this IETF meeting as well as outlined to put contact consideration. So if you're not familiar with it, you can do IETF or consider another. I encourage you to search for some of those terms. I can get you where you need to go search wise, and you can meet on some of those some of those considerations. I'm meeting logistics. For the first time, thanks to the efforts of the Meetecho team and the Cloudflare team, we have you know, I just worked for this hybrid interim meeting. So many of you are familiar with Meetecho, I'm assuming. So by simply logging in, you you sign Blue Sheets by to indicate your attendance here. If if you are here so we are gonna use Meetecho for shows of hands for for the technical chat, etcetera. In terms of the queue, we're gonna try to allow conversation to be more more naturalistic in the room when that is happening. And if you are on both look at it and enter the queue by pressing the raise hand button there on your on your screen, and we, as chairs, will monitor that and and and slide you in a conversation where it seems appropriate. When the queue gets long, in the past, we've had a whiteboard, I'm, like, start writing things on on the board. That is when we'll we'll be at the queue when that happens. So at some point, we'll just call it to do that. And, again, this is new. We haven't done this before, so forgive our growing pains, but our our plan is then Meetecho with you. So for that reason and and if for no other reason, you should you should join, then you should log in to Meetecho for those for that purpose. You can do that on your MoQ topic or data tracker page that has there's an upcoming meetings page, which has a link for this as well as the the MoQ in the MoQ working group meetings page, or you can simply use your your device to scan that QR code, and you'll get a live version of the client that that has the key functionality that won't give you the video and and stuff you don't need because you're here. Those of you who are remote, this is exactly like attending a regular IETF meeting with that small exception that remotely, with this small exception that we're gonna have this this different, like, this different queue dynamic at least at first. If you are logged in here, please mute your speaker. If you are remote, if you do if you do decide to speak in this meeting, first, be aware that there's a bit of latency in unmuting your device, so give yourself a second or so before you start talking. Secondly, the echo cancellation properties are not great. So if you are going to speak, it would be great if you have some sort of headset so that it can just echo back the channel. If you do not do that, we have to meet you pretty aggressively to to make anything legible. Any questions about all this? Alright. Let's move on. This is the agenda for today. We received many, many agenda requests. Not all of them were satisfied. We certainly, today, the focus is absolutely on MoQ Transport issues. We have an aspiration to have the last call in Vienna. We'll see if we get there, but part of that is just burning down the issues that the editors have on our plate right now, and almost all of these items are relevant to that. As as mentioned a few minutes ago, there's a fire drill at 10:15, and we're gonna use our opportunity to take a break. Do we
[00:06:10] Magnus Westerlund: have to leave the building right now? No.
[00:06:12] Alan Frindell: We just have to just it's wild. It's it takes a short amount of time,
[00:06:16] Magnus Westerlund: but there is there's an alarm on different parts of the building, and there are times that we do not know how to do
[00:06:23] Alan Frindell: it. Okay. Seems like a, like, a not conducive time to have a meeting and a very conducive time to go get coffee So you don't have to go outside or anything, but this is a great time to break. You can have a sidebar conversation, get some caffeine, do whatever you need to do. Let's see. I'm not gonna read this entire thing to you, but at 11:45, allegedly, we have a catered lunch. If it turns out to be late, we're going
[00:06:44] Magnus Westerlund: to move
[00:06:45] Alan Frindell: things up, but that should be straightforward. And during that catered lunch, Tongyu Dai is here. He has the demo of a of a diagnostic tool he developed. Everything is optional. Your adults can even tell you want, but I I I just wanna say it's sort of, like, super optional. If you wanted a bunch of awesome opportunity to do sidebar conversations, stuff you're interested in presentation, you're very welcome to sit here and and listen to this talk, but I don't wanna discourage the other things that happen at lunch that are productive. Okay. We are gonna take a a bit of a break at 02:30, not to have fun, but to relax and to talk about our next hybrid interim, would be in September, early October. Try to nail that at least a week to have it, but I think you can put the everyone's calendars, and then maybe talk a little bit about potential venues. We're on another break, and then we'll close it out with some more issues. I do wanna call out call out Mike English's presentation towards the end of the end of the day. You may recall that a number of months ago, we started a a DOS design team to kind of keep thinking of these issues. This is the first I don't know if
[00:07:54] Ian Swett: it was
[00:07:55] Alan Frindell: last, but certainly the first readout from them. It was kinda to put it in draft, and we'll talk and this may need to call your attention to that and maybe talk a little bit about prepare you for further discussions about the submission of that document if you've had a chance to read it. Okay. Would anyone like to batch today's agenda?
[00:08:13] Ian Swett: Yes. I see the first item is for the my co editor. And I have not seen his slides. Although, I have slides on
[00:08:22] Alan Frindell: this topic, which I can present. Think he wants
[00:08:24] Ian Swett: to do that.
[00:08:25] Alan Frindell: Maybe he's in France. He could be in France.
[00:08:27] Ian Swett: It does happen. Random issues. And then just shuffle things around. I don't know.
[00:08:47] Alan Frindell: That's what we have to do well, why don't we
[00:08:51] Ian Swett: Or I can just do thirty minutes of issues, and we can do all the subscriptions.
[00:08:55] Alan Frindell: This is a rookie mistake. We can schedule Ian first. Okay. Let's Rookie mistake. Yeah. Let's have Moe oh, let's have Moe go first, and then if if he and, like, we'll just we'll break in the middle of whatever comes next. So that will I'll be Multiple Subscriptions or The new Joining FETCH depending on on whether I'm here.
[00:09:20] Magnus Westerlund: Okay. These slides are shared for me. Those.
[00:09:22] Mo Zanaty: So Okay. Can you guys just do it? Yes.
[00:09:25] Alan Frindell: So, actually so there there's there's another presentation option here. This desk was actually somewhere else a moment ago or yesterday when we were talking about this. If you want to come up here, and you don't have to
[00:09:42] Cullen Jennings: I'm sorry. That's the lack of my I wouldn't oh,
[00:09:45] Alan Frindell: it's not the problem. Yeah.
[00:09:47] Magnus Westerlund: Oh, we can put something on. Yeah. I
[00:09:50] Victor Vasiliev: can solve that problem.
[00:09:55] Alan Frindell: Okay.
[00:09:58] Mo Zanaty: You want presenters to go in a circle?
[00:10:00] Alan Frindell: I'm not gonna want is a strong word, but the idea here is that if you're sitting here, you can you can view the chat pretty effectively if you want. You can look at the slides. You'll your face will be facing both many of us and the camera. So this is something you can choose to do. If you wanna do it from your seat, I'm not gonna control how you do your
[00:10:20] Mo Zanaty: So can can you can I flip with this or no? So can I can can it?
[00:10:25] Alan Frindell: I don't know. That's probably not gonna be that
[00:10:28] Mo Zanaty: I'll just ask I'll
[00:10:29] Ian Swett: just ask you We we can do it
[00:10:30] Victor Vasiliev: for you.
[00:10:30] Magnus Westerlund: We can We are up.
[00:10:31] Alan Frindell: Yeah. But I guess Okay. Alright. Well, that's that's we'll see how that goes. Alright. Okay. This is this is tomorrow's agenda. It's a little more eclectic. There will be some MoQ discussion. Can do anything apart from from the was discussed overnight. We are spending a little bit of time talking about the top end thing, which we I don't wanna see if it resolved, but we had the
[00:11:11] Cullen Jennings: the interim resolution on a
[00:11:13] Alan Frindell: couple couple meetings ago. And then we're for a number of reasons, we're gonna talk about some of the other drafts on Friday afternoon. One of those reasons that some of our editors are early tomorrow our MoQ editors rather. Nevertheless, that is the agenda for for Friday. Does anyone have to when you like to batch that agenda now, or should we just wait until we get we get to tomorrow when maybe things will change then?
[00:11:41] Mo Zanaty: Will be
[00:11:41] Ian Swett: batching tomorrow.
[00:11:42] Alan Frindell: Yeah. We will re batch it tomorrow because god knows what's gonna happen today. And, you know, I I think that as I mentioned, I think our priority really is to get through MoQ Transport issues today this this meeting. And so if if we if the task tends to fill the time allotted, so I I think Magnus and I need to be alert to when we're kinda spinning our wheels and not getting anywhere. But if we feel like things are progressing well and productively, some of these other items might drop off, and if and the and the idea of going getting to issue zero on on on. Okay. Here in the here in the ask time, these are some of the presentations that we that we were not able to allocate time to. Well, they overflow. It's just because we didn't give Mo quite as much time as he thought he needed. Nevertheless, those those are those are they're a thing to run extremely quickly. And then lastly, here are the upcoming dates. We've got a couple virtual interims. Did we already watch this do a lot of it? Like, those still promos. I can't remember. Is that is that since the call's still open?
[00:12:55] Magnus Westerlund: Well, any locked the
[00:12:59] Alan Frindell: Anyway, sir certainly, there's been an email proposing these dates. I'm not a 100% sure what the I can't remember what the status is of the consensus call. Nevertheless, our plan is to do that at 09:30 Pacific, which is, what, sixteen thirty UTC on those days. They're both Mondays. As I've said many times, as Jerry's group, we are we are wide open to hear any sort of feedback about those meetings. We kinda settle on that title, the time that works for for the group. But if Mondays are, like, horrible or sixty thirty UPC is horrible or there's some other problem where we're running virtual in terms of the now, we are very open to feedback. We get very little of it.
[00:13:41] Magnus Westerlund: Yeah. But so far,
[00:13:42] Alan Frindell: we haven't seen any feedback, and the date we're set
[00:13:44] Magnus Westerlund: to comment on this was '8 to June. So we I think these days are set.
[00:13:50] Alan Frindell: So And we request three sessions at the end. I'll just see how that goes. I would anticipate one of them being Friday afternoon because that's usually how the ISG publishes somebody who asks for three sessions. I've asked for not Monday morning because I have a personal matter that's gonna cause them to arrive on Monday morning. So use that do what you want with that information. We'll see if that's honored or not. Yeah.
[00:14:13] Magnus Westerlund: I mean, the AI the first agenda will come out probably in two weeks, and then we'll lock down, like, two weeks down or three
[00:14:23] Victor Vasiliev: weeks before the meeting.
[00:14:24] Ian Swett: So Can I I believe centralized also draft deadline, I imagine?
[00:14:29] Alan Frindell: Yes. Yes.
[00:14:30] Ian Swett: So and just from at least from my perspective, we do plan to kind of draft on that day, which will be an outnumber, which will be not in the future, should have many resolutions on
[00:14:42] Alan Frindell: So you may have noted that there's interim report in tomorrow morning's agenda. I think we use that time to maybe get a sense of if people wanna move to nineteen because people are just so done with eighteen. I it's it's not the case, but we'll find out tomorrow. Maybe we'll be in eventually. Okay. Enough to move. Is Ian in the room? No. Okay. Moe, you're up. I guess we're gonna have to this here.
[00:15:38] Mo Zanaty: So this is the recently adopted filter. It's in PR 1518, and there was an earlier PR 1401 on this. Next slide. Recap the motivation. There's video key frame scrubbing for, you know, trick play. Object ID zero is a natural thing for that. Video base layer extraction, subgroup zero is a simple thing for that. Let's get the most stream files because they could be better solutions. Specific encodings, if you wanna filter on a property, like, you know, codec is, you know, H.264 or something. And then nonmedia examples, you know, clear critical alerts and log in to use a priority filter for that. So that's the use cases. Next slide. This is the one pager of the entire design, everything you need to know about the object range filters. There's a setup option that controls it. Max filter ranges, the default is zero. So it's off by default unless you negotiate this. And that limits the total number of ranges that you can have in all the filter types for any given subscription or fetch. These are parameters that can, appear in subscribe, subscribe tracks, request update, publish okay, and fetch. And there's four of them, and we'll talk about maybe striking one and adding another in a minute. And I wanted to stress because I thought the previous talk was gonna touch on this. The need to do multiple subscriptions on a single track was originally motivated by filters causing two different subscribers having disjoint filters. And the publisher that the relay publisher that's receiving that has to say, wow. How do I reconcile these two disjoint filters? I have to subscribe to the entire track of stream. So to avoid that, we thought about having multiple subscriptions. Instead, we added what's in bold there, the set concept to basically allow a relay to aggregate all the filters from different subscribers into multiple sets, and then they're poured together. So it really does not have to be multiple subscriptions even if they're different from the underlying subscribers downstream. So I wanted to stress that aspect. Set is basically pouring everything in in all those different sets. Within a set, you end all the filters.
[00:18:09] Magnus Westerlund: It it No. It doesn't have much percent switching if it wants.
[00:18:12] Mo Zanaty: Right? And then individual subscribers could could use this too if you wanted to, you know, have a certain combination or this other combination endpoint to do that too. Okay. I'm not sure
[00:18:23] Ian Swett: I understand. So that's your sets use these sets on one or remove all the filters,
[00:18:58] Magnus Westerlund: receive all the objects from any of the filtering will be gone.
[00:19:00] Mo Zanaty: The the the p r p r says should relays should aggregate and propagate filters upstream. So Okay. Okay. But for other reasons, that's before we had this if if the multiple subscriptions has maybe relaxed that wording.
[00:19:17] Ian Swett: I guess my whole question is if we do multiple subscriptions, would we remove set?
[00:19:20] Mo Zanaty: No. No. This I think this is a very valuable concept without without any any relation to multiple subscriptions. Because this this one only allows the subscriber to express a richer thing. You could say, you know, you know, this temperature or this pressure, you know, this product or if it's just a, you know, a small a small frame. So Okay. It's fundamentally new capability. You want
[00:19:47] Ian Swett: this regardless of that. Okay.
[00:19:50] Mo Zanaty: Okay. And they all just follow the same the same pattern. You specify the set and the and the range. Except for the property filter, you also have to specify the property type that you're filtering on. Application question.
[00:20:04] Victor Vasiliev: What you said, can't I can't
[00:20:06] Ian Swett: do a set where it's like a set of loop filter or a other type of filter. It has to be
[00:20:11] Alan Frindell: a set of a given type
[00:20:13] Mo Zanaty: of filter. No. No. But a set set is a number. Everything with that number is is is all ended together. Should all Everything with different numbers are all or
[00:20:24] Ian Swett: together. Alright.
[00:20:25] Cullen Jennings: So Okay. Okay.
[00:20:26] Alan Frindell: So a set is not just, like, a sequence of ranges or something. Okay.
[00:20:29] Cullen Jennings: It's it's
[00:20:30] Ian Swett: like set ID. Yeah.
[00:20:35] Mo Zanaty: Okay? Any that that's the entire design on one pager. Is everybody clear or anything that alright. Next
[00:20:44] Alan Frindell: slide. There's a little timer running in the left window there in case that you're
[00:20:48] Mo Zanaty: interested. Next slide. These are just some examples. We ran through this in the virtual interim, but, you know, basically, you can do all the things use cases before. This is just showing how you would actually encode those use cases. And the strike throughs are because we're doing health encoding. So that's the original number and then the delta encoded number after it. And on the right, it just shows that even though we're only doing, you know, inclusive ranges, you can still do all the relational operations just by using inclusive ranges. So you can do, you know, equal, less than or equal to, greater than, in between, inclusive, exclusive, all those, not equal to, all those combinations with with sets. Okay? Thanks. Next slide. Alright. Three issues that I wanted to bring up. I wanna make sure I understood. First one is that the property filter, this is where you have a a an object property equal to some value. The property filter can also filter published messages in the current PR. This is something that Alan brought up because he he missed it. So I wanna make sure everybody understood this and didn't miss it and agrees with it. This is what the exact text says in the PR that the property filter can work on both track and object properties. It has no way of knowing. Right? You don't know if something is a track or object property by the number. So if it's a track property, that that added a new capability to this build because now it can filter the published message itself. So that means if you put this in subscribed tracks you put a property filter in subscribed tracks, you can filter the published messages that come back for for that namespace and only get the property type that you wanted. So for example, if you wanna only wanna get a namespace with all of the encodings for a ladder of of of a title. So, yeah, you know, all the different bit rates, codecs, everything, you know, like a YouTube folder that all those encodings could be properties, and you could filter track properties. You could filter on one specific track property. So coding is a v one, for example. And that would actually filter out the published message. In addition to all the objects, it wouldn't you obviously wouldn't get any objects because we didn't get the published. So I just wanna make sure that the text is clear and that the that the concept itself is also agreed. Alan came back and said the text is clear, but he he missed it the first step. So it's
[00:23:20] Ian Swett: a I have a question about how the the interaction so let's say I want I subscribe tracks,
[00:23:27] Alan Frindell: and I
[00:23:28] Ian Swett: have a filter for a property, and a publisher comes to the publisher that doesn't have that set
[00:23:33] Magnus Westerlund: of track record. Some properties are both in
[00:23:35] Ian Swett: the can be in the track or overwritten in an object.
[00:23:38] Mo Zanaty: So in
[00:23:38] Ian Swett: this case, it's not in the track
[00:23:40] Mo Zanaty: Okay.
[00:23:40] Ian Swett: But was in a later object. We will be trying to never see it.
[00:23:44] Mo Zanaty: So first, you'll need the published message to do The published
[00:23:47] Ian Swett: didn't pass the filter.
[00:23:48] Mo Zanaty: Oh, the published did not pass
[00:23:49] Magnus Westerlund: the filter. But maybe a subsequent
[00:23:50] Ian Swett: object would have.
[00:23:51] Mo Zanaty: Yeah. So now that that that's what this is clarifying is that the published message itself would get filtered out. And if the track property does not pass the filter, no objects
[00:24:00] Ian Swett: in the task will be filtered And you're okay with that because there's other places where the behavior says, well, it wasn't in the track. Like, if I just did a subscribe, that's only filtering on the object properties and not on the published track properties.
[00:24:15] Mo Zanaty: That's right. Because it's too late, and you've already subscribed.
[00:24:18] Alan Frindell: I guess. Yeah.
[00:24:25] Mo Zanaty: It's just not okay.
[00:24:25] Ian Swett: It's I'm just saying there's a subtle behavior difference. Because sometimes people think about the parameters in subscribed tracks as pretend that I subscribe with these parameters. But this is not like that because this is this is the difference between subscribing with this and subscribing tracks that produce two different results. That's all I wanna make sure everyone understands.
[00:24:47] Mo Zanaty: Yes. Okay. Alright. So everybody's good on this. This is not unexpected functionality. This is not controversial functionality. Nobody likes this.
[00:24:56] Ian Swett: I think this is reasonable, but I agree with Alan that it is
[00:24:59] Alan Frindell: it is suddenly different in a way that, like,
[00:25:01] Ian Swett: I think is utterly incremental.
[00:25:03] Mo Zanaty: And unimplementable? No. Totally. It's utterly and completely It's incremental.
[00:25:07] Ian Swett: It's not not a technical problem. It's not a technical concern. Concern. I think it works fine, but it's it's kinda similar but different. Yes. Like, I I think we could have
[00:25:16] Victor Vasiliev: the drop problems if we don't quite spell it really, really,
[00:25:19] Mo Zanaty: for sure. And the the this this filter PR predated the track properties. So this was just like an accident that, you know, something all of a sudden, it could filter published messages because we had to track properties later. So it was we we either could not support track properties at all, which made no sense. It's the core utility of the filters to do something like that. So it matches the filter. So I think we're settled on this one.
[00:25:45] Alan Frindell: Yeah. It seems like a logical way to structure this. Like, I don't want random objects that that didn't get published for.
[00:25:50] Cullen Jennings: Yeah. That won't work. Yeah. So the track alias is gonna be a problem.
[00:25:54] Mo Zanaty: Yes. The next one is whether or not we should remove the object ID filter. The main purpose of it is for scrubbing key frames so you can quickly get iframes from a track by using object ID zero. Now that's often true, but that's not always true. So you have to know that the encoding is actually supporting that it's guaranteeing key frames in object zero. Sometimes we have leading pictures. We can have temporal scale of load structures that don't put the first first frame as the iframe. So that was not an ironclad thing to to always be guaranteed to work anyway. An alternative to using object ID zero, if you don't have the object ID filter at all, is to put them on a separate subgroup, put the keyframe on a subgroup. The advantage of that is now you can have different priorities with different subgroups. Now the iframe can have its own higher priority than everything else. Another alternative would be just to mark mark the frames themselves, mark mark key frames with the property. So you can say, you know, you know, property frame type equals key frame. And some some apps may choose to do that using something like frame marking or some other custom markings. So there are other ways that that key frame scrubbing could be implemented, and it's not clear that the original vision of object ID zero was ironclad to work anyway. So my recommendation is to actually go ahead and remove the object ID filter and use the other alternatives that exist unless we'll have a really good use case for the object ID filter for something else.
[00:27:30] Magnus Westerlund: What if the
[00:27:30] Ian Swett: application provide? This is
[00:27:32] Magnus Westerlund: So is this is this something an extra figure is more work? Or if if if not the case, I don't think so. Removing it it If
[00:27:58] Mo Zanaty: if people need the filter object IDs, then we should keep it. If they don't, then Victor originally raised this and made me think, yeah, but, otherwise, you keep keep it straight. Straight.
[00:28:08] Alan Frindell: More people raise their hands. Anyone else who's gonna raise their hand just use the use the tool, but you four don't need to. Okay. I I think she can be just all simultaneously hands, I'm calling, I guess. I don't know. I don't know really I I think I agree with Dale. It it made me think
[00:28:24] Cullen Jennings: in audio, all of those things might increase the size of the audio a little bit to use them. So it may be if we're doing scalable audio stuff, and maybe there's an argument they wanna keep this. But it seems like such an easy thing to do that I I don't don't see any harm to it one way or another, but I don't have a solid use case. So just just, like, random input, like,
[00:28:41] Mo Zanaty: sort of
[00:28:41] Cullen Jennings: lean lean towards the end. But
[00:28:44] Mo Zanaty: Yeah.
[00:28:47] Magnus Westerlund: Yeah. I I have a strong objection to removing object filters. Oh, your your stated use case that it's not always true that object ID zero carries a key frame. True. But 98% of the time, it is true. It is that way for draft-ietf-moq-msf, which is our adopted streaming format. So I don't the grounds for that 2% of the time, I don't need it. Therefore, I'm gonna remove it. To me, it's not a strong argument. My second objection is objects are our atomic unit of transmission. That's what moves of a model. And we're building filters, but then we're not gonna build a filter that actually allows us to filter this object. So I from Suhas's point of view, I can attach properties to every object, and you're gonna filter those. So the level of effort inspecting every object is the same there. Yep. So I I think inspecting object ID or a property header is equivalent that we've been I'd like to keep
[00:29:36] Mo Zanaty: Can you flip one slide forward? Go go to the next slide real quick. One moment. One yeah. One more. I just wanna show people. Ignore the content of the slide, but at the very bottom, you see the original p r 14 o one, the table on the bottom. The original p r 14 o one had basically almost everything in the object header. It had a location filter. It had the group ID, the subgroup ID, the object ID, priorities, properties. Almost everything from the object header to payload link, you could filter on. And we eliminated some of them because people thought it was, you know, unless you could have a really strong use case for it, don't include it. And there was some overlap between the location filter and the group and object filters because locations are group and object IDs. So that's why we removed the group ID, and we're gonna remove the object ID as well. But then
[00:30:24] Ian Swett: we realized that we need
[00:30:25] Mo Zanaty: it for keyframe scrubbing. So that's that's the rationale for removing it and for why it was kept.
[00:30:34] Alan Frindell: Yes. Sir. I was
[00:30:35] Magnus Westerlund: just curious about the the the sort of set idea in in these filters. I wondered whether it either makes sense to have set any other other sort of location filters as well or whether to remove it because you there's a section in in the draft that sort of explains about combining all
[00:30:54] Mo Zanaty: the different
[00:30:54] Magnus Westerlund: kinds of filters, whether whether that'd be a useful thing to include. I don't know you thought thought about that.
[00:31:00] Mo Zanaty: You talked about location filter or the other?
[00:31:02] Magnus Westerlund: Well, the with the range filter, you've got this new set concept. But then the other ones, there's no sort of set concept. So in that way so it felt like maybe that could be useful across the whole lot or or not across
[00:31:14] Ian Swett: any Yeah.
[00:31:15] Mo Zanaty: I think you're talking about the the location filter. The location, but not the object ID filter. Right?
[00:31:20] Magnus Westerlund: The yeah. Well, you're you're right. You're new proposed filters.
[00:31:23] Mo Zanaty: Yes. The next one. The next slide. Okay. So, I mean, there's no harm in keeping it. I mean, we it's already in the PR, so it's no work to to to keep it. It's a simplification that but if it's useful people. Let's keep it.
[00:32:45] Alan Frindell: I Yeah. I didn't think you just say it as an individual, obviously. I don't I don't like alternative one. I think, like, having subgroups. I think someone we have to express dependencies and just, like, make it impossible to express dependencies keyframe is a real bummer, but I guess this is a dead issue anyway. Also, as chair, I'd like to say that Magnus and I talked about this very productive. Gonna immediately fall behind schedule and run through your slides and discuss these issues to the question. Okay? Alright. So and the conclusion here is Okay.
[00:33:15] Magnus Westerlund: Do not remove it.
[00:33:16] Ian Swett: Yep. Yeah.
[00:33:17] Magnus Westerlund: Keep it. And it's yeah. No one
[00:33:19] Alan Frindell: because it's sinking in recent. So
[00:33:21] Mo Zanaty: And the last point is the next slide. The last point is the location filters. So like I mentioned, we had the location filter in the original PR. It replaced the subscription filters, the enum of, you know, all the different four types and now maybe extended to eight types. It replaced all of those with a location filter that looks just like the other filters. It was removed because we wanted to make the the PR simpler. It's just less text. Most of the text of the original PR was the location filter because it removed a ton of stuff about the subscription filters. So it's the largest part of the diff. So that's what was written from 1518, not really from for a technical reason. So recommendation now is in light of other things that are happening, which we'll talk about now in section, it makes a lot of sense to go back to that location filter because we see that this email of ugly subscription filters just keeps growing, and then they can be replaced by what the app really wants, just the range of objects, range of locations. So that's the that that's the recommendation is to go back to the location filter that was in '1401, and looks like all the other filters has length and the one difference is it doesn't have a set. It has a start and an end, and it doesn't have a set, and it doesn't have multiple ranges. That can be relaxed if you wanted multiple ranges. There's another issue somewhere else that says, can we have multiple ranges for fetch? So if you wanted that, you can make it like the other filters that have multiple ranges. Or we could keep it simple and just have a single range. And it works for both relative and absolute. So if you only put start group and nothing else, that's a relative that's a relative location filter. And it's relative to the next group, so you can you can say next group or current group or in groups back. So the same thing that's happening with fill fetch or, you know, replacement for joining fetch. You can do all those same things with this much simpler syntax, and it aligns all the other filters. So that's that's the final third point. And for cleanness, we can do it as another PR instead of putting it in the filter PR. But it it's in line with all the other filters. It would look exactly like all the filters. It would just remove a lot more text, just like 1401 removed a ton of text about subscription filters. It would make the bit diff much bigger again.
[00:35:50] Cullen Jennings: Well, just to be clear, I say, it can do absolute start and ends as
[00:35:53] Mo Zanaty: well. Right? Yeah. Yeah. Yeah. Because, I mean, if you just put the start and end location. So if you just put real you know, all four real numbers in there, then you're gonna get an absolute range. If you want relative, then you only put a start group. Relative will will will give you anything from the next group to the current group to previous groups.
[00:36:12] Magnus Westerlund: This is you. I don't so I I think when we started all these filters, we started with integration because that was simple, and we had
[00:36:21] Ian Swett: we started to experiment that
[00:36:22] Magnus Westerlund: more and more use cases came in more intimidation. It's been very clear
[00:36:27] Alan Frindell: that we we decided to add
[00:36:29] Magnus Westerlund: more generation to achieve all those things. Like, I I'm I'm not sure which way we go, but I'm I'm expecting one way to do that would be my recommendation if that means you do filtering and define all these kind of filters on top of what you have as an admin properties, that's that's simple, and we can go to that one. Or if we decide to go add more integration, I think we should be working that. I what I'm not be kind of supporting very much is that, right, having two ways to do same things.
[00:36:57] Mo Zanaty: Oh, no. They have know, if we had the location filter, you would have to replace the subscription filters. You cannot add the location filter on top of the subscription filters. It has to replace all the
[00:37:05] Magnus Westerlund: subscription filters. Right. Like, if someone wants to be filtering, there's one way
[00:37:09] Alan Frindell: to go, but that would
[00:37:09] Magnus Westerlund: be good. Either way, which the major design you make. Yep.
[00:37:13] Mo Zanaty: We could talk about this more in in in the Alan's section
[00:37:16] Ian Swett: if you
[00:37:17] Mo Zanaty: want, because it's related to The new Joining FETCH and and what the app is we're trying to do.
[00:37:24] Alan Frindell: Will? Yeah.
[00:37:25] Magnus Westerlund: I I support re adding it for the same argument as prior. It's our object model, the core number the core IDs on group ID and object ID. This gives us the authority to filter on that. In respect of the use cases we know today, future use cases using this transfer transport, I think, would find this really useful. How?
[00:37:48] Ian Swett: I so I think it's applicable. So and I think it's somewhat tied with other things. So I I'm open to the idea. I just wanna give it maybe a little bit more time thinking about how that intersects with what we're are we doing with joining fetch that's different? How can it interacts with fetch? And, anyways, I think there's a lot of complex combinations in the as well. So, like, I'm just
[00:38:11] Mo Zanaty: I think this needs a little
[00:38:12] Ian Swett: bit this might need a little bit more thought before we turn it in here.
[00:38:15] Mo Zanaty: Alright. Next slide. This is summary.
[00:38:17] Alan Frindell: Oh, well, not. Are you trying to draw the cues? No, Victor.
[00:38:21] Ian Swett: Oh, I wanted to shout out to Victor who's had this idea last year.
[00:38:24] Alan Frindell: Okay. So this I'm sorry. This is applied to fetch as well as subscribe. Yes. Okay. Yes. Alright. I would need to think about this more. So a long time ago, we decided to have subscribed and only our group boundaries for, like, stream termination reasons, and this seems to be sort of flattening that. I I know we need it for fetch. I
[00:40:40] Cullen Jennings: the back of those comment. And but just to add on what Martin, Martin, I think when we've had problems with this before, we didn't have, like, the ways of marking that an object was the end of the group and things like that. And so I think the reasons that caused us to not want to do that in the past, we've solved other ways now. So, agree, it needs some more thought. But, like, let's say you take a let's say you have a
[00:41:01] Mo Zanaty: filter that doesn't give you the whole group
[00:41:02] Cullen Jennings: but only gives you half the group here, and you receive it. Nowadays, when you got the last object in that the filter gave you, you wouldn't know whether it was the end of the group and you have the whole group
[00:41:12] Alan Frindell: or not, which you didn't before. Right? So it's it's it's the end of the subgroup. Sorry. End of the subgroup. Yeah. So right so right now, I think the only secret we have is bin.
[00:41:21] Ian Swett: So you have you have to rely on reset at.
[00:41:25] Alan Frindell: Right. Okay. So well, I so this so this is what we have to work out. So, like, as we stand today in the subscribe, if you get a fit, you realize that the previous offers at the end of the sub group. So the two ways to do this are either acquire a reliable reset at, or if you were if your filter ends in the middle of a group, you have to, like, know that you don't know what the end of
[00:41:44] Victor Vasiliev: the sub group is.
[00:41:45] Mo Zanaty: That's people. But you're what you're you're doing that filter on the.
[00:41:50] Alan Frindell: No. No. So you know that you can you know what you're doing. It's just, like, you have to like I said, I mean, this is not gonna break the protocol, but okay. But we are now saying so, like, there's this whole game of, like, when do I know when the subgroup is over? And Finn solves that under most cases, but now there's this edge case where when subscribed when it's subscribed when a filter ends mid group,
[00:42:12] Mo Zanaty: like, you do
[00:42:13] Alan Frindell: not know. You have to, like, flag that somehow. Right. And and that's okay. Like, we could it's I'm sure it's fine. It's just it's just something we're using that is and it it's probably less gross than having, like, a different filter for fetch versus subscribe. So I think especially now that we have, like, combined doing fetch or subscribe fetch filters, basically. Right? So I'm amazed well, we'll put this in this vacation because, like, we're getting think we should do this, but but there is there is a subtle change in these in what you can learn as subscriber because of this change.
[00:42:49] Ian Swett: I I I think that edge might be kind of sharp, and then it's a very subtle distinction Yeah. Both for a publisher to do it correctly and for a subscriber to know how to do it incorrectly.
[00:42:59] Alan Frindell: Well, we could do rely when we said at, which has
[00:43:01] Ian Swett: Well, has to a lot of depth on it, and I understand that. Yeah. I'm like
[00:43:04] Alan Frindell: But But the thing is you have to deal with
[00:43:05] Cullen Jennings: that case anyway. Right? Like, even if you don't do this, you have cases where a stream is, and if you were a stream for some reason or another dot ended in the middle of the group.
[00:43:12] Ian Swett: And then the receiver has
[00:43:13] Cullen Jennings: to deal with that correctly, but the correct
[00:43:15] Alan Frindell: Why the receiver has a reset and Today,
[00:43:17] Ian Swett: the the the slide is very clear. It's a thin, then the last thing before the thin was the last, and that's separate from you.
[00:43:23] Cullen Jennings: Got it. So problem solved.
[00:43:35] Alan Frindell: You you have to treat a fit as a reset in terms of this thing, which is like, it's not hard to code. It means you have no way of knowing what the. So you use the filter. We use the filter, which you can you like, don't don't it hurts when I do that. Don't do that. So, like, maybe you just do that. But that is that is what we've done to ourselves here, and it's fine. I like it. I still think it's the right choice. Okay. I'm the last one in so let's move on. And we got, like, two minutes.
[00:44:02] Magnus Westerlund: Let's conclude then on the page one.
[00:44:04] Alan Frindell: Just This is a couple of me just give you a conclusion. Right. Yeah.
[00:44:07] Mo Zanaty: This is a this is a conclusion on everything. So I think we have agreement on the first one. If everybody's okay with the property filter as is, the way it publishes way filters publish messages. No problem. But we decided not to remove the object ID. We're gonna keep it. That's the utility. I think I hear we would like to see a PR on re adding the location filter.
[00:44:28] Cullen Jennings: But then, of course,
[00:44:28] Alan Frindell: a separate PR. And then
[00:44:30] Magnus Westerlund: it will there were support for it, but both of Boris
[00:44:34] Ian Swett: and yeah. Okay.
[00:44:36] Magnus Westerlund: So PR and then people can review that and comment on that.
[00:44:39] Mo Zanaty: And and then the final point is 1518, it still has the track the top end filter in there as well. So, hopefully, pending the end of this week's discussions, we can figure out if there's still no consensus on keeping that or not. If there's not, then we have to remove it for 1518 and put it into a separate PR or draft for both.
[00:45:00] Alan Frindell: So in the, like, the minute we have for break, my computer decided to hit a minute ago a couple minutes ago, and so I missed the consensus call. We decided what was was the result this was your consensus call that you that you made, Magnus. Was the was the consensus that track filters were in, but the top end particular thing was not in MoQ Transport?
[00:45:23] Mo Zanaty: I'm confused about that consensus call question. The the current PR, the track filter is the top end filter. The word track filter itself is used for the top end filter. So there's there's no track track filter is
[00:45:34] Alan Frindell: not top end. I think the confusion is what
[00:45:36] Ian Swett: the the first thing on this slide, the property filter in filter published is what some people are calling the track Okay. Now that's authentic. Okay. That's not what's in
[00:45:44] Alan Frindell: the PR. Gotcha. Okay. So property filters are in. Filters are not yet in. Okay.
[00:45:48] Mo Zanaty: But I'm I'm, you know, I'm skeptical that's what people thought because that subtle nuance, I don't think anybody in this room
[00:45:55] Ian Swett: I I agree. I agree. You even missed it. Yes. I think the people are but now we're now we're gonna redo it. We want updated filters, and we want the property filter unpublished.
[00:46:04] Mo Zanaty: The the people said it at at the at the virtual interim that had the consult. People said that they wanted the concept of track filtering period. Whether or not it was top end specific, they wanted eventually to have a general, you know, filtering of a bunch of tracks. Maybe not in the top tracks of the the just in general. That's I think people were saying track filter was. That's not written up anywhere. There's no there's no PR that mentions anything
[00:46:32] Alan Frindell: like that. Okay. So I I think the current alright. I I don't know if you wanna do another consensus call. I'll just go to list to make sure we got this nailed down. But we'll talk about it over the break. Yeah. I think the current another business call. I think it's clear that
[00:46:45] Victor Vasiliev: the previous consensus call is
[00:46:47] Cullen Jennings: very unclear to everyone what it meant. Meant. We We shouldn't shouldn't do do too too much much with for it. That. Right? Right? But I but I
[00:46:51] Mo Zanaty: also like to get more information after the end of this inter after the end of this Friday because we hope to show more data and and Yeah. Understand what the what the problems are. Is it, you know, herd from alimony, maturity, I I hear complexity. So what I'm I understand and address Right. So the
[00:47:07] Alan Frindell: the the current state, as I understand it, is all the filters, including property filters, but not top end, are in short order going to MoQ Transport, which is why there is a PR for it. The top end's current status is extension. But, like, all like, all extensions, it's great time. Like, all extensions, like, you know, if if if can satisfy, make sure we can drop it. That's the current state. I would be rooting for you to try.
[01:02:49] Victor Vasiliev: It should be a word for some.
[01:02:50] Alan Frindell: Did you
[01:02:52] Ian Swett: okay. Well, the the was the latest deck approved? I have
[01:02:56] Alan Frindell: no idea. I don't know. Probably, I didn't approve it. Did you approve it? What? The latest deck? How late?
[01:03:04] Ian Swett: I don't know. Sometime today.
[01:03:06] Magnus Westerlund: I approved it when I arrived in the morning at the wrong line.
[01:03:09] Ian Swett: Okay. Yep. That's fine. I didn't change it. Okay. This talks about 1642 PR and unfortunately. So as you recall, we, like we tried to we talked to bunch of boulder, and we had the interim rewind. It didn't go very well. Ian and I tried to, like, try to understand, like, what does this group want? And so we sent out a survey to take care of who responded. So this just I put these results on the list, but the general consensus or I wanna use that word. The results of the survey was that, like, nobody said joining fetches failed functionally, and, like, six out of nine people said that they're can deliver the current design, including two that said they don't even use joining fetch in their new sense. But there's but if look you at it the other way, there's a majority of people who are unhappy. Four says
[01:04:11] Cullen Jennings: is this
[01:04:11] Alan Frindell: how you
[01:04:11] Magnus Westerlund: object to my slides? No. Attention, please.
[01:04:42] Ian Swett: Yeah. Okay. Okay. Alright. So it does work, but eight out of 12 people either says they really don't like it or it's not working for them. People said they wanted to spend more time to get this right. So you average the number of months, people would I would rather expect take this much longer. People wanna spend some time to to get to to get it right. The there was a strong majority that said, if we change anything, it has to we have to rip joint and patching out. Like, they want and it's like, the must not was you have to keep the functionality, but everyone was like, don't add more and have joint and patch in there. If you do anything Is
[01:05:21] Alan Frindell: a strong majority?
[01:05:23] Ian Swett: Okay. Maybe not. Nine to 15. What is 60%? I don't know. Barely. Okay. Barely. Not even consensus. Okay. And then I apologize. I just
[01:05:34] Mo Zanaty: used that it wasn't.
[01:05:35] Ian Swett: Okay. And then the but nobody was saying, like, we have to completely remove, like, the fetch data claim for everything. So what am I talking about? So we looked at all this feedback, and we wrote a PR that has two different separable pieces of functionality in it. One of them is delivery changes for the current group, and the other one is expanding the capabilities of subscribe so that you can subscribe and things in the that will trigger things in the past to be delivered to you, which is not something we do. There's sub bullets there, which is
[01:06:15] Alan Frindell: The fire alarm test is now complete. Please respond to all future fire alarms.
[01:06:24] Ian Swett: Got it. Okay. So one of them is, like and it ties in with, like, what I was talking about, like, how many filter types do we need and how do we spell them on wire? There's a few different options. And if we allow subscribers
[01:06:39] Alan Frindell: I don't think you've heard
[01:06:40] Ian Swett: nothing off the wall.
[01:06:40] Alan Frindell: But but
[01:06:46] Ian Swett: There's a possibility like, there's an option that we could remove fetch, which might be a spicy topic. So we're gonna talk about these things separately. Okay. So since we introduced fetch, like, you have groups, somewhere you have largest objects, almost certainly in the middle of a group somewhere, that group in which it is in the middle of is what you would call the group. Everything after the large objects can be returned to via subscribe, actually things before that be subscribed to if you set the filter right. But everything if you really want stuff back there, you gotta send the fetch. So what what sixteen forty two proposes is that, like, you can get everything in the current group via subscribe. But anything before the current group is still delivered fetchishly. This is not completely true. Right?
[01:07:36] Magnus Westerlund: This is true for the data. Right? Meaning that
[01:07:39] Ian Swett: the blue one is sent with subscribe. You need a resource train. But what is in green will be sent with the filled FETCH, but you can get what is in green from subscribe. If it's like a later item object? Yeah. Yes. You can. I realized. Oh, this is so it's confusing. Okay. Ignore the pictures if they're confusing. I can't I can't undo that. Okay. So why do we want current group delivery? So one of them is, like, we like, when you subscribe when you're trying to get the current group, it's coming via two different data planes, where your subscribe plane and your touch plane, and that's sort of, like, weird. There's headline blocking issues with like there could be low priority subgroups in your current group, which fetching them is going to block the higher priority ones. And also, like, if there's missing datagrams or something that like will cause your fetch implementation to be slower. There's a priority version issue that we filed, which I can't exactly remember the details of, but I remember that it seems like it had some real cases that couldn't be presently expressed. And another thing we've heard is this is, like, joining the current group is, like, the most common operation, and it's annoying that you have to do it with two different firms.
[01:08:58] Alan Frindell: I would like to scooch about six inches forward so you're on camera.
[01:09:01] Victor Vasiliev: Oh, you better? Thank you. Yes. Okay.
[01:09:03] Ian Swett: I don't like the the most common operation. I was gonna say, let's not do any clarifying questions because I'm gonna go through, like, four or five slides, and I'm definitely not taking don't like your proposal until we get to discussion.
[01:09:20] Cullen Jennings: I do wanna ask a clarifying question. You just said though, because you said something there that sounds
[01:09:24] Magnus Westerlund: the opposite. You said the the the can you
[01:09:26] Cullen Jennings: say can you explain which one of the solutions has say more about the headline blocking problem here. Okay. Number one. If you Is what you said sounded the opposite of what I prefer.
[01:09:33] Ian Swett: In the current thing, let's say I have two subgroups, high priority and low priority. And for whatever reason, the high pry the low priority one has delivery time outed from Hub to to redo. So my cache has a bunch of pools. I have I have an entire high priority subgroup, but they come every other object, and so I have, you know, just as many pools in my cache.
[01:09:51] Magnus Westerlund: If I join fetch if I join
[01:09:52] Ian Swett: fetch that group, it'll give me the first object and say, oh, this is missing. I need to go ask upstream to give me this little priority thing. Even though The fetch part
[01:10:00] Mo Zanaty: of The fetch part of it is the box.
[01:10:02] Alan Frindell: Yeah? Yeah.
[01:10:02] Ian Swett: Thanks. Mhmm. Okay. So how does it work? Current group delivery. So it's objects in the current group can be delivered via subgroups and datagrams. The publisher has to serve from
[01:10:14] Cullen Jennings: the beginning the beginning group from
[01:10:16] Ian Swett: from from its cache or via an upstream subscription or VFX. The pub the publisher needs to respond. It's gotta know that it's starting subgroups with the actual first object that was published by the OOP. Once it's caught up to live, then the live objects just keep coming on the same streams. So in order to implement this, like wait. You have to you have to have some caching. I don't think it requires parallel subscriptions. You can filled FETCH. But, anyway, there's it it moves some complexity to the publisher or relay to, like, give you what's in the current group over subscribe. And there's no flow control for the current group. It's gonna catch up as fast as possible. That might be fine in a lot of cases, and it might be really bad in others. But that's, like fetch is flow controlled and subscribe is not. So that's what happens if you do this. So for some happy paths, things work great. If you have no upstream subscription, the relay can just issue an upstream subscription with the current group, and it will be delivered to you in exactly the right way so you can just relay it. Another happy path is everything in the current group is already in cache, so you can just search directly. And there are cases where if your cache is incomplete between object zero and the largest object in the current group, as long as your upstream subscription started before the current group, that means the objects that you're missing are still in flight to you. So it's okay to start deliberating the ones that are missing are gonna show up, and you can relay them. So, like, this is what I think people are like, but it just works. It's fine. There are unhappy paths. So if for somehow you if you relay me an upstream subscription and it started mid group, like,
[01:11:59] Magnus Westerlund: with a location
[01:11:59] Ian Swett: filter, then it's gonna have a hard time if someone asks for current group. So a Relay can avoid this by only subscribing on group boundaries. So not sure that that is, like, this is an avoidable hazard. The group is too large to fit in the cache, so you can like, it's just not gonna fit. You the current group is days long. If somebody asks for current group, like, you just can't serve it that way, and so you have to have more code to react to that. Or somehow you, like, did some eviction or something, and you have, like, Swiss cheese your current group. So there's what the PR does is it, like, it it recognizes that, like, this operation can fail. Like, if you wanna subscribe to the current group, it's there are cases where they really just cannot give it to you. And the proposal is, like, you just move on. In mock t, there is not really a guarantee that you're ever gonna get anything via subscriber. So if you asked for current group and I told you largest objects is in group 10, and then you didn't see any of group 10, you just got group 11, like, can you just deal. The PR adds a reset stream code so that if you started serving your group and then you realize that you ran into one of the hard cases, you just reset it and say, like, this is not available. And there could also be a similar signal in Request Ordering (SWITCH_FROM),
[01:13:22] Victor Vasiliev: which is just like, you asked
[01:13:23] Ian Swett: for a group, but, like, it's not it's not available at any price.
[01:13:28] Mo Zanaty: Pause for discussion. Do what do people think? Do you move
[01:13:34] Ian Swett: on current group? Do move on current group? Group? Well, I'm sorry.
[01:13:38] Mo Zanaty: Had to
[01:13:38] Alan Frindell: Let's use the keynote. If if your sense is you need to raise your hand, just raise your hand at the tool, please. I think that's the way to proceed. Okay. Well So you said do a current group? Yes.
[01:13:50] Magnus Westerlund: I also want the group maybe just prior to current. Right? And the mechanics of delivering that that prior bit of the current group can also deliver the
[01:14:00] Mo Zanaty: the group in front of it.
[01:14:01] Magnus Westerlund: So to me, the current group is is a boundary, but it's a relatively arbitrary boundary. And I realized we can't have unlimited groups behind live, but is there a could we could we dictate how many groups behind live we want to make it a reasonable number that could accommodate a lot of use cases that don't actually wanna start with current group because it's not enough of it.
[01:14:25] Ian Swett: I mean, what you're describing is green and rewind stuff. So this is I had
[01:14:30] Magnus Westerlund: to propose something different than what is to me. What can you answer why we can only Why? Sort of a little bit of the past,
[01:14:38] Mo Zanaty: but not a bit more of
[01:14:39] Magnus Westerlund: the past? Think You see the same cement.
[01:14:41] Mo Zanaty: So I
[01:14:41] Ian Swett: think one is that the current group is special because it's the only group that spans the large spans the lifetime. So, like, it seems reasonable to have some special treatment for this group that makes it somewhat different than the group immediately before it, which is entirely behind life. So that's one reason why we think this is not just an arbitrary distinction, but, like, a reasonable distinction. And the other one is, like, it's already a little bit dodgy that we you you're giving up flow control when you subscribe current group. And so going back indefinitely makes the relays job harder. It has to, like, go, like, figure out ways to serve things. Rewind was sort of like, you get what you get, and people didn't like that either because it was like, well, I wanna go back 10, and the relays only has three. It's cash, and it's like, well, you're only getting three. Then that's not what I wanted. So at least with this, like, it's predictable what you're going to get.
[01:15:32] Magnus Westerlund: The group can be two hours long. You know, we we tend to think of groups as small things Right. In terms of seconds,
[01:15:38] Ian Swett: and therefore, we're limiting the flow control damage to the smaller area, but it it could No. That's a caveat with this. Like, the the current group is super long, then and it if it's in one stream, then it's flow controlled. But if it's datagrams or if it's over a stream per object, then, like, that can blow out your connection. And that's just a consequence. We'll.
[01:16:03] Alan Frindell: Yeah.
[01:16:06] Magnus Westerlund: I'm in the same page.
[01:16:07] Ian Swett: I mean, this is all come from your sentence. This is the most common Let me ask them more. What's that? About I mean, the is this is is only about the data plan. The second half of the presentation
[01:17:04] Magnus Westerlund: is about the control plan. Yeah.
[01:17:05] Ian Swett: So if you it's not that you can't ask for groups behind the current group and subscribe because that's what the second half of the presentation is about. It's that the way the data gets delivered to you is different and that the where that differentiator happens is between the current group and the one before it. Does that make sense? So it's not that you can't subscribe to group minus three. It's that groups minus one and minus two and minus three are gonna come a different kind of stream and the ones that are from the current report are coming via subscribe streams.
[01:17:31] Magnus Westerlund: Yeah. Okay. So, I mean, I know this is a fetch.
[01:17:33] Ian Swett: I know this is stuff. So, I mean,
[01:17:35] Magnus Westerlund: I think it's good, but
[01:17:51] Ian Swett: Yeah. So
[01:17:53] Victor Vasiliev: first of all, like, the the current purpose special because this is the only place where we we break, like, guarantees that your groups are, like, currently, the brain's history. Like, as I said, it's like that states that, like, worst thing about joining FETCH is that, like, it splits group into two groups is unusable as in you're just getting bunch of these frames in the. And the reason, like, the reason why this is hard is you always whenever you've talked about groups since the past, you always run into this issue with flow control, which is, like, what happens if you even if you ask current group, you're inherently at a race because you're you're trying to send some re most recent objects on sort of such re on a Riotfile subscription, but you're also at some risk. Obviously, it happens to it's a table of the group, but, you know, also, it's a risk that they have to the group. We'll get it back to the for cash. So that's just and, like, as you raise the number of things you try to backfatch, that's the probability of this happening is approaching one. And I I'd say the current group the reason current group set up as a nice plus FETCH is a nice compromise is that it solves the issue of you splitting a subgroup, but also it also deals with back pressure the way we originally tried to deal with it, like, to. So it kind of tries to combine the best aspects of the personal perspective.
[01:19:37] Alan Frindell: Cullen, can you flip back
[01:19:38] Cullen Jennings: to your page with the little the
[01:19:40] Alan Frindell: boxes, the colored
[01:19:42] Ian Swett: The one that okay. Some people don't like those.
[01:19:45] Alan Frindell: Yeah. Okay. Okay. That that that one.
[01:19:48] Magnus Westerlund: So so I think we need
[01:19:49] Cullen Jennings: to do like, I wanna go back to the use cases that drove this, which is people want it. The reason they're getting the first half of 11 there at all was so that they could start playing it. Right? And but on the other hand, if they got the beginning of twelve before they spot the before they got enough of eleven to start playing it in live, that, you know, if if time had moved on while they were getting all of this backfill of eleven, they wanted to just move start of playing twelve right away. And this drives a priority issue of you need to be getting 12 needs to be coming at a higher subscriber priority than the backfill of eleven. And so that causes you to need to be able to split the priorities between the blue half and the green half of 11. And I think that, like like, we're forgetting like, we need to go back to these are the use cases, and this is why we looked at this design before and decided it didn't work.
[01:20:48] Ian Swett: Can I ask you so of the three things there, call it 11 a, 11 b, and 12
[01:20:52] Cullen Jennings: Right? How would you word the priority in the use case you're talking about? You you put 11 b's, the second half of eleven and twelve, a higher priority.
[01:21:02] Ian Swett: And what's what do put 11 a as a lower priority? But you want you want 11 b before 12 before 12?
[01:21:09] Cullen Jennings: The problem is there's not a good way. I mean, you could put you could put 11 b at even a lower priority than 11 a. But the problem is is we don't have a good way to express a different priority for 11 b and twelve.
[01:21:20] Ian Swett: Now That's is dead. Okay. Nothing Sure. So it's like we can design
[01:21:24] Cullen Jennings: like, we design things to sort of deal with this. But I think
[01:21:27] Magnus Westerlund: that what we have to look at
[01:21:28] Cullen Jennings: to figure this that, really, this problem is not about whether you need to send one verb or two verbs up. Okay? Everybody gets wrapped up on that. That is the most irrelevant part of the discussion. The part of the discussion that's super relevant is what's this doing to the congestion control, and how does the application have the right level of control to make sure it gets what it wants? And this is one of the problems with trying to use subscribe to backfill let's say we got 10 groups back.
[01:21:50] Ian Swett: And by the way, I agree with everyone.
[01:21:51] Cullen Jennings: As soon as you're going back in time at all, it doesn't matter how many groups you're going back because there's no one size limit. All the problems happen, whether it's just a small group or
[01:21:58] Ian Swett: a big group. So I think that we
[01:22:01] Cullen Jennings: need to to talk about the the what happens to all those things. And when you're trying to do multiple streams, multiple tracks, different tracks at the same time, and you're trying to say which one of these are more important than others. Like, as you start putting all of these onto the same streams for the subscribes, that's where we got ourselves in trouble. We couldn't figure out how to make that all work. And part of it was we wanted to be able to do things like, say, if let's say I'm backfilling object 10, k, across three tracks. But you wanna say, I want most of my bandwidth on this track first and then then these other two tracks second. Right? We can easily see how to do that with fetch, but it's a little bit less clear when it's all merged in with this. So I think we need to talk about what data you want to arrive in what order, and how do you get that to happen no matter what set of verbs you use to describe this is the important thing.
[01:22:49] Alan Frindell: Okay. And everybody's trying
[01:22:50] Cullen Jennings: to simplify the verbs. I get that. I don't care about that. I care about what order
[01:22:53] Alan Frindell: the data lands on the wire.
[01:22:54] Ian Swett: Okay. I I hear what you're saying. I even your premise that, like, I think some people would want 12. I think there's different if if you count those 11 a, 11 b, and 12, I think different use cases would give you different answers for what is what order they want those things in. Like Sure. Gwendal probably wants 11 a, 11 b, 12. I think like, five seconds back
[01:23:12] Magnus Westerlund: or fifteen
[01:23:12] Ian Swett: seconds back. Right? But then I'm hearing what you're saying is like, well, maybe I want 12. Maybe they want 11. I definitely don't want 11. I mean, the bot. Like And so But Yeah. So I think I think I think there's multiple cases. I do agree. We should write them down and make sure that they but I don't think that we even have the richness today to express everything that you think we do.
[01:23:30] Mo Zanaty: And so that I don't
[01:23:30] Ian Swett: think this is, like, causing that many more problems than we are right now.
[01:23:34] Cullen Jennings: Sure. But I think what I'm trying to say is, like, this won't work. This will cause real this won't get the way you want without tapping something in the priorities. As is I'm not saying you can't fix this or. Just saying that as this stands,
[01:23:46] Ian Swett: I I I don't think this
[01:23:47] Cullen Jennings: will work. This will cause you to not be able to meet the use case applying twelve early. You'll this will result as
[01:23:52] Ian Swett: You get twelve before eleven.
[01:23:53] Cullen Jennings: When when you don't backfill eleven, twelve will be significantly delayed in this case from what it would be in the current situation.
[01:23:59] Ian Swett: Okay. And so the way that you have tends to deal with this Yep. Is that it says if you want to do that, you want I mean, I think the way the mock team is is, like, if you want twelve before eleven, then you want descending work. And I think you messaged me privately and said descending won't work, but that's how you would do it. Right? Just like, oh, I'll give you eleven until I have twelve, and then I will start giving you twelve and eleven to deprioritize.
[01:24:19] Cullen Jennings: Yeah. But you that that won't work because when you go from 12 to 13 descending order will. Like, look. I'm not gonna give a tutorial on why every commercial product that does real time video in the world
[01:24:28] Victor Vasiliev: doesn't use a descending order.
[01:24:30] Ian Swett: Okay. Okay. I'm just saying That's the only one that doesn't. We have the only four to give you twelve
[01:24:35] Mo Zanaty: to 04:11. Right.
[01:24:35] Cullen Jennings: And that one's not usable here because when you go from twelve to thirteen,
[01:24:38] Alan Frindell: it will fit. Right?
[01:24:40] Ian Swett: Alright. There's four. Okay. Very long queue. Okay.
[01:25:47] Mo Zanaty: I get to my turn Okay. I'll I'll I'll mention what I I'll mention the point.
[01:25:51] Alan Frindell: Alright. I'm next. Okay. I'll do two things. Oops. So I think Is it? Thank you. So if the desired order is 1211A11B, I think this poll actually allows you to get that quite naturally. Because if 11 a is available, then you're just gonna start with with 11 a and, like, everything's great. Right? I mean, you you get all I got 11 and then 12 in sequence, assuming you're sending order. If 11 a is not available, then 11 b is blocked because you don't have the front of the subgroups. You cannot send anything from eleven b. You don't even have the information of whether those are starting symptoms or not. So if twelve if twelve zero arrives before eleven zero on, like, some sort of backfill or whatever, like, twelve is gonna go first. Now when eleven a comes later, like, you'll get that that, you know, then that'll that'll start secreting twelve, which is I mean, it is what it is. But I think the I think this case addresses what you want maybe a little bit better than the current thing. You get eleven b first, like, instantly. Right? Then then you'll get the backfill for, like, 10 or group you want. Okay. Second second my second point was a question, which was when the when the relay says, tough luck. I don't have it, and I'm not gonna give it to you. Does that so it's not gonna be delivered on a subscribed screen. Is the is the fallback that he did is delivered to you on a fetch stream, or does it just go into the ether?
[01:27:25] Mo Zanaty: In
[01:27:29] Magnus Westerlund: help me. My market's
[01:27:30] Ian Swett: lost. Okay. Is it it it I think the the scenario is, let's say, the current group is too large to get in cash, and you send it subscribed for current group. And they realize, like, I don't have that anymore, and I send a fetch up stream and the original publisher time out or something. Like, what what are you going to get? Maybe it was a little maybe the PR is vague, and there's rooms that have different. I'm not sure that I can
[01:27:57] Alan Frindell: it is the same for the PR to do. I don't have a strong opinion about that, but I think we need to figure it out. Right? And and figure you know, should it should it be delivered on this on attached or not?
[01:28:06] Magnus Westerlund: But it is in the one of the comments that we can the PR, but
[01:28:25] Victor Vasiliev: motivating issues for so this is the the delivery order. So if you have delivery ordering ascending, you want ten, eleven a, 11 b, 12.
[01:28:41] Alan Frindell: If you
[01:28:41] Victor Vasiliev: have descending, you want twelve, eleven a, 11 b, 10. And I think that is actually not currently expressible. And so so the reason that's as important is, like, there is no circumstance under what you want to let them be before.
[01:28:57] Magnus Westerlund: Yes. That's true.
[01:28:59] Alan Frindell: Yep. That has to be true.
[01:29:01] Mo Zanaty: Oh. Yeah. So I'm gonna talk in detail with Victor and Aman, I think, about this. And, clearly, what I said to this wasn't clear to him. But I think you guys need to try this, implement it, and then see what happens. What's gonna happen is if that 11 a is is any sizable chunk, suppose that you're halfway through the group and the group is two seconds, one second of of eight megabit video, that's already gonna put VBR into congestion avoidance. You you're gonna you're gonna already pull out the scene when so the problem is subgroups are designed for the natural real media rate. It makes sense to have the subgroups fall out and be prioritized when there's a natural media rate, and real congestion causes them to be reordered and dropped. This introduces fake congestion by bursting 11 a at line not even line rate, instantaneously. You burst 11 a to the quick stack. The quick stack says, oh, this is not media. This is I'm, you know, I'm doing a file transfer. I'm bursting out as best as I can, but you've exceeded the pacing rate. You've exceeded the c win. So now you're basically into this into this mode where you have to start queuing things, either at the level or if you have a type integration with your QuickStack, somewhere between. When you start doing that queuing, that's when the subgroups start taking priorities. So the priority kicks in then in real real world scenario, the subgroup probably works well for real congestion. In this scenario, it works horribly because you're not you're not under real congestion. You don't want the subgroups rewarded. You want them you want the objects in order. Decoders have to receive all the objects in order to decode them. You can't get them on order. Player The has to have a playout buffer that's stitching together all the subgroup streams and putting them in object ID order. If you force the subgroups all of a sudden now start coming in subgroup order, not object ID order, Now you've delayed the playout offer into for the entire graph because you're gonna get all of subgroup zero first. Then you're gonna get all subgroup one first. This next. Then you're gonna get all subgroup two. You're gonna get all subgroups in order, and all the objects are gonna be mishmeshed. And so now you're gonna have to go all the way back to get object one. You're gonna have to get all sub groups zero first to get object one and sub group one. So that's why if you actually implement this, I think there's gonna be an obvious problem with multiple sub groups. With a single subgroup, it works fine. It's it it's but then it's identical to flat fetch anyway. So, you know, maybe not maybe not anything materially different. With multiple subgroups, you're gonna see object reordering. The app is gonna get object reordering. And the whole purpose of this is fast play out. Now you have to wait the entire GOP to play out because unless you're a plat only the base layer and not any enhancement layers. But then you shouldn't get them. Why are you occupying the wire if you're gonna drop them anyway at the playout? Just do a separate filter and only get your base layer. That's true.
[01:32:08] Magnus Westerlund: Okay. Thanks, man. So I I think on the question is, so should we have a large scale? I think that's really great for the question. Think that's really great. I think They they they have they they have effect positive effect if they work together, not So I will not answer that question at this point in time. But one thing I've heard is that, especially when you do have the the missing of subgroup, like, for 11 a, let's say, you have, like, two subgroups and one is missing. If I understand correctly,
[01:32:38] Alan Frindell: what will happen is that if
[01:32:39] Magnus Westerlund: you you do not have the odd subgroup, then you'll get even subgroup and order will never get out because subscribe semantics does not go and fetch the old ones. In in that case, the is that is expected that when someone does this, they'll have a degree of experience for half of the l m a because there's no way to get the full experience. And if this if that's that's what what we want. But I think I I understand that John and Fitch asked this I I need to watch him to fill those gaps, but it gives you know, this delay, but it gives in everything so that you you you can have the right sub groups being there for rendering time and hence have the good quality. But I think we we missed that. We we'll end up having whether we have this kind scenario back end, but even if it's been something that point. And second thing is that there's no way for me to say, my player is waiting too long. I won't cancel that. Maybe can do the first update and probably do it. I'll I'll give different priority for filling in. That's something I think I I think we discussed about the there might be ways to do it, but that's one of the things.
[01:33:47] Ian Swett: And I just realized
[01:33:48] Magnus Westerlund: of what what Moe was talking about when, you know, ugly Wi Fi network conditions where which is which happens when you're in any Wi Fi that there there's this part once where the Wi Fi network does start scanning. At that point, you will not be able to send or receive anything. So the Wi Fi X point, basically, buffers over data.
[01:34:06] Alan Frindell: And
[01:34:06] Magnus Westerlund: whenever that happens, some something very similar to what is. It it will buffer and burst the data to the client, and that's when we get most crazy. And maybe I think for this immediately, Until now, the my data, it was so low. Now I see huge huge data coming in. So I have a lot of bandwidth, and it starts thinking because the segment grow 10 times bigger, it starts thinking everything is fine. We start expecting something. And next you see the data going normal, and immediately, you think, oh, I have lost now. It'll go back again. And this keeps happening every time. And I just kinda want to see, like, we need to kind of think a little bit about these things. But on on on the general semantics about can we join these two things in such a way that it can be simpler API? I think in general direction, I I like it. But I think there's some of these constraints in that report.
[01:34:50] Ian Swett: Mhmm. Cullen?
[01:34:53] Victor Vasiliev: Can you
[01:34:53] Cullen Jennings: see the slide of how we handle the sort
[01:34:55] Ian Swett: of upstream, like, the the
[01:34:56] Cullen Jennings: the rainy day case one or
[01:34:57] Ian Swett: something? Or something? Yeah.
[01:35:00] Cullen Jennings: So yeah. Okay. So the I want the most number one here seems like, you know, obvious at some level. Okay. But I wanna point out that this is sort of a a turtles all the way down. We have to figure this out. So this will send it
[01:35:15] Alan Frindell: to the upstream relay, which will
[01:35:17] Cullen Jennings: you know, initially, it's gonna go through some one or more relays, and it's going to the same thing is going to go to the original publisher. And in the case where the original publisher is, like, a large something streaming off the disk, yeah, that's sure fine. Problem. This works fine. But in the case where the upstream publisher is on congested end of a land link because usually on our lands, it's the upload that is, you know, on average upload slower than download. So that's where we see more congestion than anywhere else The you know, or more limited bandwidth.
[01:35:49] Alan Frindell: I I think that we
[01:35:50] Cullen Jennings: need to work through how this is is really gonna
[01:35:52] Victor Vasiliev: work because I think it it's
[01:35:53] Cullen Jennings: going to run into problems there, particularly if some of the relays in the path can't cache as many GOPs as we allow or as many groups as
[01:36:03] Alan Frindell: we allow you to go back. Right?
[01:36:04] Cullen Jennings: So let let's just say
[01:36:05] Ian Swett: Well, let's this is only for the current group. Yeah. Sure.
[01:36:08] Alan Frindell: Okay. But if
[01:36:09] Cullen Jennings: there's a relay that doesn't allow you to cache a full group, which is very realistic when we're talking about the end memory.
[01:36:15] Ian Swett: Or it'll fall to number two, which is
[01:36:16] Cullen Jennings: Yeah. Equally the Yeah. Yeah.
[01:36:18] Mo Zanaty: The group is so I think
[01:36:19] Cullen Jennings: that this will just result in a lot of places where we get current group unavailable, and I think that that's a much worse outcome than where we are today. And I don't I I don't actually agree with the statement that MoQ never guarantees anything. It's like, no. I actually think that mock within the limits of
[01:36:38] Alan Frindell: the bandwidth being available, if
[01:36:40] Cullen Jennings: you're doing subscribe on reliable transports guarantees delivery at at at some level.
[01:36:44] Alan Frindell: Right? You you know, I think
[01:36:46] Cullen Jennings: that that's that the applications are relying on that to work. So I I guess what I would say what I'm saying on that is that there might be some applications that are totally acceptable for sure to add that, but I don't
[01:36:57] Alan Frindell: think that I think you
[01:36:58] Cullen Jennings: wanna think very carefully about whether you were removing the functionality we have today, which seems much more reliable than this in in its But you can gonna work.
[01:37:07] Ian Swett: But take what you just said and apply it to subscribe this join fetch because it's kind of the same, isn't it?
[01:37:15] Magnus Westerlund: The the join fetch
[01:37:16] Ian Swett: the subscriber link was to the DVD Edge relay, but the join fetch will keep going backwards to the Origin Publisher or through relays that may not have a cache. Right.
[01:37:23] Cullen Jennings: Right. But its ability to put the to serve that data at a lower priority that doesn't impact over that congested link is much higher when it puts them on a separate stream than it when it does on things. I mean, this is just like, I think if you have a thousand clients all joining at the same time, all causing this to go back. So so let's say you have a thousand. A 100 people joining the meeting at roughly the same time. Okay. So in the first, you know, fifteen seconds of the meeting, there's a lot of these things happening that are going past in those stop sequences. And I know, how does this work when you have a bunch of these things all going back to the original subscriber around the same time, and it needs to trickle that data out, yet it's on the same stream as what it's trying to publish its real
[01:38:08] Alan Frindell: mainstream data on.
[01:38:09] Ian Swett: The relays should all be. Well, there should only ever be one subscribed to the current version.
[01:38:13] Cullen Jennings: But look, it works fine if sure. As long as all the relays can keep the whole box even
[01:38:18] Ian Swett: with, like, cache. Even if you don't, it doesn't have like Right. You should only ever have one. Just like you think you can have a big fetch it till you last for the same object. You don't have to fetch redo a few files.
[01:38:28] Cullen Jennings: Okay. So I've I've gotten some dubs from that, and I'm started feeding it out to
[01:38:31] Alan Frindell: the clients that requested it. And now the next client comes along.
[01:38:36] Cullen Jennings: I don't have to redo it.
[01:38:37] Mo Zanaty: But isn't that a general problem today regardless of this? Right? Wouldn't wouldn't join fetch more of the same thing?
[01:38:43] Ian Swett: I I no. I think that's okay. I'm saying The new Joining FETCH is in the front of me. No.
[01:38:46] Cullen Jennings: Think that does have to
[01:38:47] Alan Frindell: be involved. It's just that
[01:38:48] Ian Swett: fetch has a way to manage
[01:38:49] Cullen Jennings: that data separately than the mainstream video that you're providing to all the clients that are already
[01:38:53] Ian Swett: joined. I see that you is, like, we are almost at the end, and it's regrowing. I let me I think everybody's had a chance to speak at least once. So let me just maybe say, what I'm hearing is some interest, some skepticism, some desire to work through scenarios on paper in more detail before we say yes or no on this idea. And, also, like, we should look at the second half of the presentation because they sort of
[01:39:18] Mo Zanaty: work they they work together. So And can you clarify if this made that impact was the mirror?
[01:39:24] Ian Swett: Right. I mean, I think these I think the the idea of whether there's current group is separable from the second half
[01:39:29] Magnus Westerlund: of this
[01:39:29] Ian Swett: presentation, which is you can send a subscribe. Is that what that includes passively. So anyway, Victor, Ian, you want another word on
[01:39:37] Mo Zanaty: for before you move on?
[01:39:38] Victor Vasiliev: Yeah. I posted a quick comment on Mo's. It just bizarre to certain extent true that in some cases, with joining with subgroups, you do want to filter out some parts of the subgroups, like, that's already in the beginning exams.
[01:40:04] Mo Zanaty: Yes. I agree.
[01:40:05] Victor Vasiliev: It's it's it's just but it is also.
[01:40:09] Mo Zanaty: You don't want them all green 11. You want the base layer green 11. Yeah.
[01:40:14] Alan Frindell: Well, okay.
[01:40:15] Mo Zanaty: You want lemonade
[01:40:16] Alan Frindell: prime. Okay. So first of thought was great about maybe you just get base layer after that's audio actually displayed. But if you wanna say that the other subgroups are not completely useless because they allow you to display 11 the higher subgroups in 11 b because they they allow you to encode that. So they're not completely useless, although they are public pair of utility.
[01:40:39] Ian Swett: I think what I heard from Moe is, like, getting if if, say, two subgroups enhancement or base enhancement. Yes. The decoder really wants some a b a b Yes.
[01:40:50] Mo Zanaty: Not once. It has to it cannot deal with it out of order. Was not worth it order.
[01:40:54] Ian Swett: Yeah. Okay. I mean, if I don't love the most if it doesn't get a b a b a b, like, if it gets a a a a and then b b b b b, then it it even if it gets, like, b's called b zero late, can it not catch up if it's gone ahead and a?
[01:41:10] Mo Zanaty: The a stream is fine. The b's are droppable, so you just drop the b. You would never render it. Right? You can't you have to do a b a b a b a b. And if you're a player, you're buffering up so that you can get that experience. You want a 60 hertz stream. You're playing you request that 60 hertz stream. You wanna play it. So your buffer has to has to be able to see what the jitter is between those two streams and buffer to handle that jitter. So that's what the player's doing. It's delaying those two sub Well, no.
[01:41:39] Alan Frindell: But so I I read that up to the live edge, b will not displayed unless unless the player is really buffering. I don't know if it's buffering in use cases or not. But my point is that after the live edge, there are further objects of b that are dependent on the objects in subgroup A. So once you hit the live edge, the player will be able to start will be able to add that against the player because you're delivering these previous objects that you would have actually displayed.
[01:42:03] Magnus Westerlund: So so one that was my point. Like, until, like, you hit that point
[01:42:07] Victor Vasiliev: Yes. You have. Correct. Okay.
[01:42:10] Mo Zanaty: That would be fine. I think we're just trying to say. Yes. What Victor's saying is is that you need a subgroup filter on 11 a. Otherwise, all those subgroup objects that you're throwing away are clogging your bandwidth and forcing you to wait in the player.
[01:42:24] Alan Frindell: But this is what I'm saying. You're not throwing it away because you can use them No.
[01:42:27] Mo Zanaty: No. No. The enhancement layer.
[01:42:28] Alan Frindell: No. You're not throwing them away because once you get to the live edge, you will get objects from the enhancement layer that are dependent on the earlier objects.
[01:42:37] Mo Zanaty: That that completely depends on your video encoding strategy, and most most don't do that.
[01:42:40] Alan Frindell: If they're if they're on the same stream, then they're Alright.
[01:42:45] Mo Zanaty: Victor's are independent subgroups. They're not dependent on each other. Okay. Alright. Is that okay? So I'm gonna
[01:42:50] Ian Swett: I'm gonna move on to the second half
[01:42:51] Alan Frindell: of the presentation. Do you want a of hands? I the only
[01:42:55] Ian Swett: I might want is not, like, a formal show of hands, but maybe, like, a temperature check of, like, how many people are like, yes. Like, I really wanna kinda wanna do this, and how many people are like, no.
[01:43:05] Alan Frindell: This is a really bad idea.
[01:43:06] Ian Swett: Stop it now. Because that if everyone was like, stop it now, I would save myself some work.
[01:43:12] Magnus Westerlund: I mean, may I say something? Like, because has some value that I have to the
[01:43:16] Ian Swett: the first question that you have. So I'll I'll see if you go.
[01:43:19] Alan Frindell: So alright. So you don't mind?
[01:43:20] Ian Swett: Not right now. Maybe tomorrow or something will come back and see if people have formed an enough of opinion on it or gone through things. Okay. Okay. So the second half of what's in 1642 is expanding the capabilities in subscribe. So this allows subscribe to deliver groups that are earlier than current via a what a a fetch formatted stream, and in the PR, It is called a filled FETCH stream. And so it it's it's not it's like the same data stream you would have gotten if you had sent a join and fetch for it, but there is no join and fetch. You said subscribe three groups ago, and it will open a fetch stream from and give you the past data, and it will open subscribe streams and give
[01:44:02] Alan Frindell: you the live data.
[01:44:04] Ian Swett: But it just comes in one message, and you express the range in in a single message. You can do that also via Request Ordering (SWITCH_FROM), which has some you can if you Request Ordering (SWITCH_FROM) later, like, say, you're pause the track and then you rejoin, you can Request Ordering (SWITCH_FROM), and that will open another when you when you change the filter, it will open another fetch stream to give you what you need to join after resume. So anyway. So this and the PR takes the joining fetch text is all gone, but the data plane for fetch is obviously the hardest part of fetch in that case. This is what I just said. So every Request Ordering (SWITCH_FROM) that changes the requested fill range will spawn another filled FETCH stream. The PR does not limit the concurrency, so, like, you can theoretically send many request updates and have many filled FETCH streams in flight servicing the same subscription. We could theoretically cap that at once. So if I issue a new one, cancels the old one. I don't know what's right. I meant to change this word problem here. This is something that fell out of this PR. It was not a design intention. But if you say subscribe and I give a a fill range, which is entirely in the past, and then I send a Request Ordering (SWITCH_FROM) and I give another range, which is entirely in the past, and I do that repeatedly, you end up having a subscription to VOD, which is something that you haven't really been able to do in MoQ prior like,
[01:45:31] Mo Zanaty: you just can't do it. You don't mean deliver on the servers. You mean
[01:45:37] Ian Swett: Everything's coming on. But there's a slight improvement over, say, having a a naive fetch. Right? So today, do this by, you know, just using fetch just like you would with HTTP get. There's literally no difference between
[01:45:51] Magnus Westerlund: mock HTTP get.
[01:45:52] Ian Swett: This is slightly nicer because you don't have to retransmit the track track name every time instead of staying in a relay so you don't have to Oh,
[01:46:00] Alan Frindell: that's a gate. Yeah.
[01:46:01] Ian Swett: Yeah. There there's a there's a few it makes it slightly nicer.
[01:46:04] Alan Frindell: I don't think it's
[01:46:04] Mo Zanaty: a part of this because we conceptually need to realize that is a subscription. It should have the subscription state just like subscribe does. It needs everything that subscription needs, and it's it's horrible inefficiency to have to do both. There's a VOD FETCH.
[01:46:21] Ian Swett: There's another issue. Like, for example, every FETCH OK will have all of your track properties, which should be alert. So, like, if I'm fetching you know? But if I but this wouldn't. And so it's again, it's it's a it's a slightly
[01:46:40] Mo Zanaty: I
[01:46:42] Victor Vasiliev: don't think this can 100% replace that because you don't always you can't always subscribe to some things that you can manage, like, a process.
[01:46:53] Ian Swett: I think that's an open issue. It does not I think that we need to talk about how to handle subscribing to a draft- or whether you need whether we need to signal, you know, subscribe or, hey. Like, hey. You subscribed to this thing, but I know that it's done. I've seen you in the track marker. That sort of open. Joining a publish is a little bit trickier. So if you think about draft 18, when you publish with a forward one, that I think that implicitly means you it has to start with the largest object. It doesn't say that in the draft, but I I don't understand what else it could be because there's no way for the publish to go back and start you with past, like, past objects.
[01:47:34] Mo Zanaty: Why would it be unfiltered?
[01:47:35] Ian Swett: Or unfiltered is another way to large topic drawing filtered, I guess. Rather than filtered is more correct. Thank you. So, anyway, so the PR states this explicitly. I'll then you get to change that filter. We could theoretically follow-up and say that when you use track tracks, that the default is actually current group because that's probably what you really want. Like, we don't want, like, to start in the middle of a group. When you are joining a publish that started in forward one, you don't need any of this machinery because it tells you what largest object is, and you can just do a fetch for it. And that will give you a a seamless transition. The problem is that when you publish forward zero, you're not receiving objects and the relay's largest object is moving forward as new things are coming. So we if you sent a PUBLISH_OK and a fill, you don't really know where the end of that fill is going to be. So what you need to do is immediately send a Request Ordering (SWITCH_FROM) for the fill because the request okay for that will tell you where the split happened. And you need that in your fetch stream so that you can apply the rules that fetch has, which is like, if I'm fetching up to 10 and the stream ended at eight, then I know nine doesn't exist. So there's shared parameters and shared fate in this world. So there's most of the parameters you can only express once. So subscriber priority, the authentication token, all of those are applying both to the subscription and the filled FETCH. Group order is, like, logically separate, but the way I spelled it is there's, like, a three mode in them. If you think about it, there's four different possibilities. Both ascending, both descending, and then the two opposite orders. But one of those opposite orders does not make any sense where we were filling the fetch from ascending mode and the subscribe and descending mode, like, going back towards the join point. So I didn't let you spell it that way, but you absolutely could just make these two different ascending, descending flags and just don't send the nonsensical one. In any case, the the way it's spelled, there's ascending is both ascending, descending is both descending, and then FETCH ascending sub ascending is called FETCH ascending. And those group orders also have an implicit prioritization between the filled FETCH and the live. So when you're ascending, the fill has higher priority. When you're descending, the live has higher priority in in both the descending ones. Mo?
[01:50:05] Mo Zanaty: Yeah. One of points I, you know, the list about twenty days is that the other filters this one may complicate this because we can't follow this pattern of overloading the filters with, you know, new enums to to me.
[01:50:21] Ian Swett: I think
[01:50:22] Mo Zanaty: want this one first. About this one again. So I think I I think we realized that some parameters will not be shared. Some some parameters will be unique for the fetch side versus the subscribe side. Okay. Like, we just talked about you probably want a subgroup filter on the fetch side, only get the base layer. Yeah.
[01:50:43] Magnus Westerlund: It was about the the shared parameters. Mean, the priority for transcription
[01:50:51] Ian Swett: The numeric priority will be the same. So we give you a eight bit priority number, and so if the subscribe priority is 10, then the fill fetch is priority 10, and subscribe part of it is also priority 10, And the tiebreaker is defined by this group order. You know?
[01:51:08] Magnus Westerlund: Oh, if if if I want feedback stream come first, should I give the give them a different subscriber priority?
[01:51:17] Ian Swett: In this VR, you cannot. You would instead just say ascending, which means the.
[01:51:22] Magnus Westerlund: Yeah. Yeah. The the actually this.
[01:51:25] Ian Swett: Yeah. The proof of the eyes are the way.
[01:51:27] Magnus Westerlund: But I'm sure we prefer the
[01:51:29] Victor Vasiliev: we have a fast conference. Yeah.
[01:51:31] Alan Frindell: This is
[01:51:32] Ian Swett: I mean, it sort of depends on your use case, I guess. Yeah, that can make sense. If you send forward zero, that implicitly cancels all fills. If you cancel the subscribe stream if you cancel the subscription, that buy dye stream, that will cancel all your filled FETCH streams. But you can individually cancel the filled FETCH just by stop sending that batch, and that does not cancel your subscription. The filled FETCH timeout only affects filled FETCH groups, and the delivery timeout only affects future current and future groups. Things you can no longer do. So things that drafting team will let you do that you wouldn't be able to do if you land. So one, we just talked about. You can't set a different numeric subscriber priority on subscribe versus the fetch. You get the same number and the relative prioritization as group order. If you guys need it, we can do.
[01:53:41] Magnus Westerlund: So I have a more quantification question. Should I add them the three combination of parts you'll be sending? Can we should have three different types of projects? Yes. Then because I think I'm listening.
[01:53:53] Ian Swett: We'll we'll get it. Yeah. Let me just okay. So that's, like, the point number two, I, like, removed this, like, what I thought was a nonsensical order, but if people want it, we can specify it in that way. Today, you can cancel the subscription to keep your filled FETCH, but I'd remove that if you do it this way. Like, if you cancel the subscription, the fills also get canceled implicitly. You also can't trivially aggregate downstream subscriptions. Gwendal Simon did an amazing job of, like, analyzing this PR and, like, into a whole flow chart, which is disturbingly long, which I linked here if you wanna go read it. It's it's beautiful, and will help you definitely help you to punch your thing through it. And I highlighted some cases where the PR has not yet covered yet. So but there are cases where, like, if you have a particular kind of upstream subscription and then new subscription comes with a slightly different kind of filter, like, you need to do some relay processing before you just, like, like, today's subscriber counts. You're like, great. I'm attaching you to this one. That's all I need to do. Now it's like, I have to look at the filter. I have to figure out what your filter patch is. I need to decide which is the upstream inside of.
[01:54:58] Mo Zanaty: No? If you forward equals zero, the subscription, does that affect the filled FETCH?
[01:55:03] Ian Swett: Or Yes. It does? Yeah. If you forward zero, the subscription cancels your full
[01:55:07] Alan Frindell: fetch. Does
[01:55:10] Mo Zanaty: that does that seem a little weird that that like, conceptually, I thought it would mirror subscribe tracks. Subscribe tracks is like a factory for subscribes. It it it all the brands you put subscribe tracks apply to the subscribes, but then if you keep messing with subscribe tracks, it doesn't do anything to these established subscriptions. It's a factory for new subscriptions. But then you then you manipulate the subscription directly. You don't manipulate subtracts. I thought it the same thing that this is a factory for catches. We could
[01:55:39] Ian Swett: do that. Like, I I again, I thought it, like, made sense to couple this the fates together, but if people think that independence is super important Right. We can say when you've if what you really want is to cancel everything, like, I'm pausing this track. I don't want anything, Then you will just have to cancel the subscription and stop sending the filled FETCH
[01:55:58] Magnus Westerlund: fetch streams when they come.
[01:55:59] Mo Zanaty: Yeah. I I think it's good to have a general approach regardless of this forward question. A general approach. Is this a factory for fetch streams, or is it it's it's constantly updating those fetches? Is opinionated in that, like, the filled FETCH is part
[01:56:14] Ian Swett: of this they're coupled with the subscript. So you cancel that subscription, your fill fetches are gone. If you forward zero the subscription, your fill fetches
[01:56:20] Mo Zanaty: are For example, you update the the range. Your filled FETCH is still there. Right? If you have another filled FETCH You'll get a
[01:56:26] Ian Swett: new fill if you update the range of the fill type, you'll get a new fill fetch.
[01:56:29] Mo Zanaty: But but the old one is not canceled or gone. Not in PR. It's so it it's like a factory for that for that one parameter, but the other parameters, it strictly modify them. It could be good to figure out if we could do one cleanly one way or the other.
[01:56:44] Ian Swett: I mean, I I I think this is, like,
[01:56:46] Magnus Westerlund: doable. So I mean, like,
[01:56:48] Alan Frindell: we have a the other now to just reset the the fetch stream, filled FETCH stream Yeah. Or or even, like, stop reading to the
[01:56:54] Ian Swett: full stream. No buy filled FETCH stream to control that fetch.
[01:56:57] Alan Frindell: Right. But you always have the option
[01:57:00] Ian Swett: of Subset.
[01:57:00] Alan Frindell: Yeah. So it's an important use case if you can just use that knob instead of providing
[01:57:04] Mo Zanaty: the knobs.
[01:57:04] Alan Frindell: Yes. Yes.
[01:57:20] Ian Swett: Oh, but sorry. If
[01:57:29] Alan Frindell: this does not if you
[01:57:29] Ian Swett: if you subscribe forward zero, it doesn't even create with your initial subscribe as zero. It doesn't even you said filled FETCH forward zero. It's like, no.
[01:57:37] Magnus Westerlund: You don't get anything. Yeah. But the relay is getting a
[01:57:42] Ian Swett: lot of data for you, and so there's a There's a different issue, which is, like, what
[01:57:46] Mo Zanaty: does the relay do with this which we'll
[01:57:48] Alan Frindell: talk about in the issue section,
[01:57:50] Ian Swett: not for this like, right now, our doc our draft says, when you get forward zero from the subscriber, a relay should send over one upstream, but that might get you strong when you talk about it.
[01:58:00] Alan Frindell: Yeah. I think I think I'm sorry. I think what Gwendal was saying is today, we're set you up for zero. So you cannot go get a zillion objects and make them really go get a zillion objects and not take any of them. Whereas, at least in theory, limited by the migrate. Right? So by
[01:58:19] Ian Swett: They got there's no version of that in this either. If you subscribe if you if you do a filled FETCH patch and forward to zero, it's it's like, I'm not gonna open any filled FETCH patch
[01:58:27] Magnus Westerlund: for them. Yeah.
[01:58:28] Alan Frindell: I I think it's still the case, but I'm a bit concerned.
[01:58:31] Magnus Westerlund: We we have a general notion I'd see on several frames of when you do forward zero, should the relay keep getting stuff, or should it be like a hard or soft filled FETCH? Right? We could invent that, and then that would there's cases where you want it for for liveliness to keep constantly retrieving, but there's other cases where you don't.
[01:58:52] Ian Swett: I mean, you should so I was trying I think I tried to simplify a number of things. What I hear from people is that they like having lots of degrees of freedom, which shouldn't surprise me after four years. So, like, I think maybe that can you guys can have them, like, if that's what you want. There's a few more slides here, and I see my timer ticking down the tunnel. I I mean, I I
[01:59:09] Cullen Jennings: guess that's I'm wondering about on the build streams is, like, we have lots of conditions where the errors can be different on different objects you can get in some traffic. Like, you might be able get some
[01:59:18] Alan Frindell: of the objects in traffic,
[01:59:19] Cullen Jennings: not others, just based on the time they were published and the time and the token
[01:59:22] Alan Frindell: off, example. Right?
[01:59:23] Cullen Jennings: That's one of our off use cases is time based stuff. So I'm sort of wondering, like, can this report error? Like, how do errors happen? How do you report errors for the filled FETCHes effectively? That's what I'm trying to get at.
[01:59:35] Ian Swett: There's not a separate control message for the fill. So whatever you your SUBSCRIBE_OK or SUBSCRIBE_ERROR is like or REQUEST_ERROR is like one path to report problems, like, it starts. Once you get going, you have the option of using the unknown range to be like, well, I tried to set I tried to make this piece of the upstream, but the upstream is not available right now, so I'm just gonna redo an unknown marker, continue serving me some cache. And you can reset that stream and be like, I time now talking to the upstream or whatever you wanna do. That's sort of it. Right? There's not a control pointing to say,
[02:00:11] Mo Zanaty: fill stream one guy. Unless you use Request Ordering (SWITCH_FROM) only, you can do REQUEST_ERROR. There didn't look for the first drive.
[02:00:19] Ian Swett: I think the logic is if any of your Request Ordering (SWITCH_FROM)s ever fail, it kills your whole subscription.
[02:00:24] Mo Zanaty: Request Yeah. Error will REQUEST_ERROR to a Request Ordering (SWITCH_FROM) will kill the subscription? Yeah.
[02:00:32] Alan Frindell: Yeah. And
[02:00:32] Cullen Jennings: that one was good. Kinda just like a factory model. Yeah. That's right. Like like, it's not a factory.
[02:01:08] Ian Swett: I mean yeah. It makes sense. So one question that came up was like, could you kill fetch completely, like standalone fetch? Because if you already killed joining the fetch, could kill the control message fetch? So I think the answer is you could. I'm not sure if we should. So if you do a fetch and your range is entirely in the past, that's like a one and done operation. If you do a subscribe and your range is entirely in the past, the PR, I think, has that you do, but I think I've settled mentally on through these, we talked about the VOD case, that subscription stays open. Like, as long as your VOD stream is open, you know the filled FETCH is done, you could send another Request Ordering (SWITCH_FROM), ask for something else. Right? So I think the most the complicated piece about fetch is describing what the data stream does and describing joining fetch, which we removed. I don't think having a simple standalone fetch, which is like, just give me these objects in one shot. I know what I want. I don't want a subscription. Kinda makes sense, but I'm gonna don't wait on this yet. I'm just gonna get me out of my presentation. Which
[02:02:10] Victor Vasiliev: might be close.
[02:02:11] Magnus Westerlund: Oh, good. Good.
[02:02:13] Ian Swett: So alright. Do people have other, like, thoughts on filled FETCH? I heard a lot of maybe it's too coupled. I mean, it would be better if we decoupled more. Do people like it better than doing the drawers? Where was it?
[02:02:31] Victor Vasiliev: Where was that? Don't know it's like.
[02:02:33] Ian Swett: Do people wanna okay. Then there's they're after this. So there's different if this is, like, a general like, do you think the concept of issuing a subscribe that could contain past objects and getting them over a fetch light screen is a good thing? Or would you rather have it today where you send a subscriber to live things and fetch the past things?
[02:02:51] Alan Frindell: I can say, like, I I think that this I'm mostly just a respelling and joining fetch. The the two things are different or some of the shared state, which I think I'm fine with. I I can I I don't really mind if we had we have a little more? But what what I like about this is this solves one of the cross screen dependency problems we have right now, and that's what's really appealing to me about this. Gwendal?
[02:03:14] Magnus Westerlund: So I support it. I I like it. And I just wanted to add that it's it's today is the best way to support the client side API in a clean way to Request Ordering (SWITCH_FROM) our data. So the use case is
[02:03:56] Ian Swett: Well, if you haven't seen
[02:03:57] Mo Zanaty: it, there's a PR
[02:03:58] Ian Swett: there's a built on this.
[02:04:00] Mo Zanaty: I I I saw it. I didn't it's still on. So if you have this parameter switched from, why does it need this other parameter?
[02:04:08] Ian Swett: The location like, you can basically Request Ordering (SWITCH_FROM) and include in the same thing, a fill, which is, like tells, like, I'm switching I'm subscribing. I'm switching from this other track. I don't remember pressing the and I get a filter, which could be, like, minus three from head, and then that will open the filter stream when it's red. Anyway, let's not bad into it too much, but just to say so the flow chart I've grown, that's it works. I mean, there is no it's important.
[02:04:51] Victor Vasiliev: Mike? Mike English. Just wanted to say, on the sharing, I think that this is maybe not so much of
[02:05:00] Magnus Westerlund: an issue because if you keep
[02:05:03] Victor Vasiliev: this particularly, if you keep the standalone fetch, then you always have the option of sending that for anything else that you need to back up rather. But just as a reminder, training fetch was an optimization to be able to pipeline things within the wrong trip time. So the idea is always that, like, once the client knows where the live edge is and what the state of the world is, they can always go back and fetch this to to back over there. So I think this is is great.
[02:05:34] Ian Swett: Okay. Cullen?
[02:05:37] Cullen Jennings: I think all the hard parts of this aren't figured out yet. I need to get more details on those. We need to go back to the use cases and make sure we nail down, like and I like, look. A bunch of these things, like, do we need to
[02:05:47] Alan Frindell: look hard or not?
[02:05:48] Cullen Jennings: Like, we need to, you know, concrete and figure those out. I see how we can extend this to do them. Right? But I think there's, like, a bunch of those around priorities, errors, what what has to be you know, being really clear about what flows over which stream when and what type of data it is.
[02:06:03] Victor Vasiliev: But, I mean, like,
[02:06:04] Cullen Jennings: conceptually, don't don't really care. I mean, I
[02:06:06] Victor Vasiliev: think we're just we're doing the same
[02:06:07] Cullen Jennings: thing as joining patch. And, know, at
[02:06:09] Alan Frindell: some level, joining touch gave us
[02:06:10] Cullen Jennings: a lot of flexibility in how things was delivered. And, you know, maybe Ian would argue we don't need that flexibility or whatever, but I
[02:06:19] Alan Frindell: think we need to go
[02:06:19] Cullen Jennings: back and figure that out and and then figure out if we're okay with this reducing that flexibility or whether we need to put into this mechanism adding in flexibility to to do those those types of things. And we definitely have to deal
[02:06:32] Alan Frindell: with all the issues about how this goes back
[02:06:34] Cullen Jennings: through a chain of relays to an original publisher.
[02:06:37] Ian Swett: I guess this I mean, as you point out, this is in many ways, like, a slight of hand that doesn't change the status quo that much. Right? Like, it's it should flow through realize it's very similar
[02:06:48] Victor Vasiliev: to what a joint venture does.
[02:06:52] Cullen Jennings: I think it could be made to do that perhaps, and then we'd have to write that down, but it can't be written down. That's not true when the how does that the whole hard part of this, like, what happens on a rainy day is like, oh, we got a bunch of options. We'll figure that out later. Right? Like, that has to get very specific before
[02:07:06] Alan Frindell: we can really actually address how this works.
[02:07:09] Cullen Jennings: Right? Okay. It can't just be, like, relays do whatever they want. Maybe this will work, and we move from a situation where we know exactly what will happen and
[02:07:17] Mo Zanaty: what can
[02:07:17] Cullen Jennings: form a relay do to we move to a situation as far
[02:07:20] Alan Frindell: as, like, might work,
[02:07:21] Cullen Jennings: might not. Who knows? Right? Like, we gotta be I mean, I Yeah. I know that's not your intention.
[02:07:25] Ian Swett: I'm not No. No. I but I would I would just ask them that for you because you, I think, clearly have some in mind and maybe others do as as well. Like, it's much easier if you guys can write down the specific cases that are important to you and that we can run that through the PR and
[02:07:39] Alan Frindell: find out where the polls are.
[02:07:40] Mo Zanaty: Sure.
[02:07:40] Ian Swett: Because it's hard for me to generate those since I'm more of, like, a bits and bytes and less on the users. Will?
[02:07:47] Magnus Westerlund: Yeah. I I support this. You know, even if it looks and behaves a little bit like joining fetch, I like the the shape of the API. I also the switch from, as Renan Dincer has mentioned, I think it's an elegant way to do the client side of the art, and that's certainly important to my use cases. I also think the vault fetching is particularly elegant, and I like that as well. I think that'll be efficient for those reasons, basically.
[02:08:12] Mo Zanaty: Well, I like it as well. I think we should remove fetch and running fetch. This is a much better mechanism. I think we need to work out the shared versus unique parameters. I know there's a spelling that has missed the parameter block, and maybe, you know, we can look at that or have some other ideas. If you can solve the the unique versus shared parameters part, I think it's clear that that fetch by itself is is it got a lot of holes in it. Got lot of inefficiencies. Was inefficiencies. This will help a lot.
[02:08:49] Magnus Westerlund: And, Victor?
[02:08:51] Victor Vasiliev: I think the biggest problems that I realized yesterday is that there is a big problem of joining fetch right now, which is because where to join fetch, it joins with respect to some point largest object in the group. And, traditionally, we have, like, very specific rules about how you attach to that state and how you update the state. And if you guess it wrong, you get, like, a race division where you have a gap between the timing process of scribe and timing process Drifting Edge. And this completely gets rid of the biggest assets to our process just moments ago. So I it removes quite a bit of state tracking on
[02:09:33] Alan Frindell: the account. Okay.
[02:09:38] Victor Vasiliev: Yeah. Yeah. So you did all you did all it is the same state. Like, it's just a request.
[02:09:43] Mo Zanaty: I mean, can you do a Request Ordering (SWITCH_FROM) with a full fetch request in it? Yeah. The browser, really,
[02:09:48] Ian Swett: you can, but you no longer like, the whole thing, the draft pattern on joining location, that's removed. Because if I do if I
[02:09:56] Mo Zanaty: do Request Ordering (SWITCH_FROM) for filled FETCH free prior,
[02:09:59] Ian Swett: what's that? It'll be evaluated against the current the the location that's
[02:10:05] Alan Frindell: Are you done, Victor?
[02:10:06] Victor Vasiliev: Yeah. So the current rules are, like, you have a joint location, and you report it when you already subscribed, and you update it in some cases of Request Ordering (SWITCH_FROM).
[02:10:16] Ian Swett: Yes. And this gets you a bad one.
[02:10:20] Victor Vasiliev: I argue that Request Ordering (SWITCH_FROM) should always update the same, and that that's effective in that sense. What
[02:10:29] Magnus Westerlund: I've realized is that a problem discussion. This this definitely requires a focused design team. Not not to say not to kind of talk about spelling, but also, like, the the four issues I could send you in and and thanks for adding those things. We need kind of add a clarifying expression of how each
[02:10:50] Ian Swett: of those things should be done.
[02:10:51] Magnus Westerlund: I I do feel like having one word where subscribe can go past part of the
[02:10:56] Alan Frindell: future is
[02:10:56] Magnus Westerlund: a good thing. It's not a not a talking thing. Same time, but without answering those things, I'm seeing
[02:11:31] Victor Vasiliev: I
[02:11:42] Ian Swett: think the only two things this
[02:11:45] Alan Frindell: this PR removes from this joining batch functionality is is value instead of two, which,
[02:11:53] Victor Vasiliev: you
[02:11:53] Ian Swett: know, was my opinion is that that's better, obviously. Maybe there's a use case where it could be different, but that's the spelling. You could fix that.
[02:12:01] Alan Frindell: And then the other one is you can't go this. You can't go outside in when you do report.
[02:12:08] Ian Swett: Those are the only two things that were removed.
[02:12:10] Alan Frindell: I don't I don't outside in was not something
[02:12:15] Ian Swett: I think one was gonna comment we've highlighted is that you you we also lost the controls to read from the fetch, which means there were some cases where you get a fetch error, which gave you a little bit richer detail, including a reason for this.
[02:12:31] Alan Frindell: Okay. I I I I put myself in the queue with chair. I think we're getting great. I'm I'm hearing a lot of positive sentiment about the direction of this PR, and obviously, a lot of detailed discussion to happen. I would like to open this floor to anyone who, like, thinks this is a a bad path to go down before we move on. I I will note that I mean, you know, this is doesn't block us from doing anything, but Lars Eggert is not here. He's a big joining
[02:13:02] Ian Swett: fetch I I did run this by Lars Eggert. And he I mean, I think he for the whole proposal, his biggest thing was he was current group. Yeah. If I can paraphrase, he really liked the current group thing. He was sad that I didn't go back further than the current group because he wants it forever, but he was also sort
[02:13:18] Victor Vasiliev: of building a little bit of compromise.
[02:13:20] Alan Frindell: Okay. Great. Thank you. Thank you for taking that step. So, again, opening this floor, but anyone like this back again. So
[02:13:28] Cullen Jennings: so I I I don't wanna comment on being a bad. I definitely I wanna be a comment on
[02:13:32] Alan Frindell: I don't think it's all in use cases we
[02:13:34] Cullen Jennings: wanna solve today, so I don't think it's our most important idea. Like, our our dedication of time, this and this is you know, I I I feel like this would be a great thing to work on at some point,
[02:13:45] Alan Frindell: but I would rather get
[02:13:46] Mo Zanaty: the stuff that we have
[02:13:46] Cullen Jennings: to get done before we publish our draft done ahead of this, which is I see as a nice to have.
[02:13:52] Alan Frindell: That that's fair. I'm going to work on this. I I think it might do think partially solves the the request problem, which
[02:14:13] Mo Zanaty: I think. Right? I don't know
[02:14:14] Ian Swett: if trivial is the way I would do it. I mean, let me back and say, like, if I see there are two paths forward to work, one of them is we band aid joined Fetch up to the ISG, and we just keep going. Like, we we're
[02:14:26] Magnus Westerlund: on joining Fetch. We've gotten this happen
[02:14:27] Ian Swett: two years ago. We just keep there's there's little problems with it. We keep guessing this is the problem. That'll probably and we I think we can get there. Call them. Like, I think we can and I think there's another one which is we we switch tracks and go in this direction. And, like, at the end of the day, the total number of use cases we can score, I agree, doesn't really change. Maybe the vibe one, like, that being slightly better than it used to be. It's but it's not,
[02:14:48] Alan Frindell: you know, our core So so the extent this is spelling changing, people are fine with spelling change. I'll I'll make that statement. There's concern about there's some concern about the noms you're removing. So I think the I think the action item is to work with as you described, maybe work with and some other people that are concerned about the noms taking away. I I think that you could resolve over over a period of see Yeah. Yeah. Right. Okay. We're just gonna if that if that does not, like if that takes too long to converge, just, like, open up all open up all the not you're not sure about so we can land something, and then we can follow the issues if you wanna take away knobs later.
[02:15:26] Mo Zanaty: Okay. I'd like to understand more about the the largest object control location.
[02:15:30] Victor Vasiliev: Gotcha. Okay.
[02:15:31] Mo Zanaty: I'm all for that, but I okay. Yeah.
[02:15:34] Cullen Jennings: I mean, speaking of the largest object filter?
[02:15:36] Mo Zanaty: No. No. The the the partial filter requires loading the trouble location.
[02:15:41] Ian Swett: That's how it works? Right. No. The the the issue that was there is that today, your Request Ordering (SWITCH_FROM) and enjoying the fetch that matches that Request Ordering (SWITCH_FROM) are two separate messages. So when you get a Request Ordering (SWITCH_FROM) that changes forward state from zero to one, the relay has to record large object at that time in case a join comes later. Yes. That edge is now removed because the Request Ordering (SWITCH_FROM) itself is the join, and so it doesn't need to have this, like Can you
[02:16:05] Mo Zanaty: do a Request Ordering (SWITCH_FROM) with two largest object? Can you or your Request Ordering (SWITCH_FROM) two largest object? J or to largest object. Can't you do it? Yes. And that will force you to change your join location. Right? So the real estate has to remember is join location until we can eliminate largest object.
[02:16:20] Alan Frindell: I'm all for eliminating the largest object filter. You know, because there's no more joining. This removes your invention. Request update is you don't have to say anything because you just look at what it is when you get the request. No. You just put largest object filter on a Request Ordering (SWITCH_FROM) or on a banner subscribe. That forces the
[02:16:36] Mo Zanaty: Relay relay to still record join location. Right? What? It doesn't either
[02:16:40] Ian Swett: There's no more joining. There's no more there's no more joining location anymore because there's no more join.
[02:16:44] Mo Zanaty: That's how largest object filter works. When you say Okay. Would be useful.
[02:17:12] Alan Frindell: So I I think we we I hope we can kinda discuss on this.
[02:17:16] Ian Swett: Okay. There's I I wanna so both Victor and Mo didn't like the spelling and wanna talk about different ways to spell it. We're we've been out for seventy five minutes.
[02:17:24] Alan Frindell: I think can can we do that off? Can we change spelling offline?
[02:17:29] Ian Swett: Can I give can we do, like, five minutes and just to highlight, and then people can we'll
[02:17:32] Magnus Westerlund: have some I just have one more thing? We have you have the first question that you asked about should we add that just a group, sort of beginning of the current group thing. I think we have it resolved that either.
[02:17:40] Ian Swett: I kind of agree. I don't know. Now that people have seen the whole let me go through the styling and hold up. Think about it
[02:17:46] Mo Zanaty: in the back of mind.
[02:17:46] Ian Swett: As the second half of the presentation,
[02:17:48] Mo Zanaty: This this does this does not require that first part. That's true. Against the current group, we have to be against this. This is not required for the first group change. Okay. They're separate. Current separate.
[02:18:00] Magnus Westerlund: Or probably they are separate, especially if you do filled FETCH stream to the latest software. Then this current group comes Yeah.
[02:18:05] Mo Zanaty: They they tell tell you something. They said with previous groups. So whether it comes as flat or whether it comes as subscribed is the first is
[02:18:13] Ian Swett: the first. Let let me let me just go through the last few things to keep in mind, and we'll give you guys a break. So one question is the way I spell this so today, there is absolute start and absolute range filters. They don't change anything in the past. They just say if anything comes in this range, I want it. The question is if we add the ability to filled FETCH those ranges, when I say, I wanna start from whatever, this absolute start point, If we add that capability, do we still want the capability where it only sets the filter and doesn't filled FETCH? So my PR leaves both options. You can either subscribe with the filter or subscribe to the filled FETCH. And I think Moe was like, we should only support one of those. We should only support the filled FETCH option. Yeah. And I don't know if there's if you give a
[02:19:01] Mo Zanaty: like, just wanna respect. I'm interested in this range of objects. Why would you not give it to them?
[02:19:06] Ian Swett: I don't know. That's I that's why I'm asking the question. Absolute range
[02:19:10] Mo Zanaty: of objects at once, and you say no.
[02:19:14] Ian Swett: Does anybody feel strongly about retaining the filter versus fill option?
[02:19:19] Cullen Jennings: So and is there a case where you're, like, you you're saying, I want this range of objects, but I don't want the even ones because I'm
[02:19:26] Ian Swett: doing No. It's like, I want this range of objects, but not if they've already arrived.
[02:19:29] Mo Zanaty: The purpose of actual range of objects is for future stuff.
[02:19:47] Ian Swett: Maybe the maybe that does make it simpler. At least we don't have to add, you know, so we can just No. I understand why it doesn't
[02:19:52] Alan Frindell: understand it.
[02:19:53] Ian Swett: Okay. Anyway, so this is this is just how it's spelled in the PR that there's the four filter types we already have, and it adds these four new ones. But I just for the previous slide, we can just merge the
[02:20:07] Alan Frindell: two
[02:20:07] Ian Swett: absolute together. So it could only add two. Current group, again, is completely optional. So maybe the only one that's adding is it's either current group and relative previous or just relative previous. Moe, do you wanna talk real quick to the slide, or you want me to
[02:20:23] Mo Zanaty: run through it? Or This is what I presented this morning. It's a location filter proposal. Again, resurfacing it. And it just I think more simply expresses what the what the app really wants, a range of objects. Just give me a range of objects, and whether it's absolute or relative, both are supported by just giving you a range. It's it's that simple. So you don't need an enum. You don't need all these variants. Just give a single language.
[02:20:52] Ian Swett: Kill kill the enum. I mean, it's I think it's a different way
[02:20:55] Victor Vasiliev: to spell it. Yeah.
[02:20:56] Ian Swett: Okay. Makes sense. And then, Victor, wanna Can I ask you one question
[02:21:00] Magnus Westerlund: about how does this work on the join fetches case?
[02:21:05] Mo Zanaty: You you you put this on this well, join fetch would be gone, and you do the the other also legit.
[02:21:39] Victor Vasiliev: Okay. Victor? Yeah. Oh, my my proposal is basically instead of adding new subscription filter types, you can take existing subscription filter types or you can take some location filters, and you can have just a separate parameters. It's just like, here is a parameter to support the. And this last few gives you some flexibility of, like, specifying whatever parameters you want.
[02:22:02] Ian Swett: The only thing about that that I have a question about is, like, kinda goes back to what you just said, which is, like, that means I can say subscribe relative minus 10, but fill relative minus five or vice versa.
[02:22:16] Victor Vasiliev: Is that just true? I I mean yeah. Is that well, I I mean, to subscribe to the parameters that you would feel subscribe with all that, like,
[02:22:26] Ian Swett: new layer on subjects. Right?
[02:22:27] Victor Vasiliev: Yes. That's the difference. And the other thing is I'm not a 100% sure, but I think if if we make location filter, can we make that location filter just inherits
[02:22:52] Mo Zanaty: final spelling that combines I think the key part of this, to get it to you, is this message parameters embedded within that that concept needs to somehow or something equivalent to that needs to found. Parameters. Because because because the parameters between subscribes and fetches, some of them are shared, some of them need to be unique. We need be able to express those unique ones somehow. I don't really like I don't love the nested, you know, put wrapped up parameters inside of parameters. You know, but we need to figure out some way to to do that. Okay. That's all the slides I have on this topic.
[02:23:29] Alan Frindell: I don't think he does the parameters.
[02:23:31] Victor Vasiliev: I think that sounds horrible.
[02:23:32] Alan Frindell: Let's just have two different primary types of one which only applies to fetch one, Okay. So okay.
[02:23:52] Ian Swett: Do you wanna how do you wanna Suhas's point about the the current group five? Like so I I feel like sentiment towards 1642 is the right direction for removing to any eventual ladies direction. Yes. Current group seemed more ambiguous. I think What's our plan to resolve that?
[02:24:13] Alan Frindell: I think people need to digest it. That's what I heard. Okay.
[02:24:17] Ian Swett: Do we wanna, like, read, like, save ten or fifteen minutes tomorrow to I I just come back and see
[02:24:23] Alan Frindell: if you're right. So if you wanted people that needed to digest the current group thing, please your whole set of mistake look at it. Right? We have a parking lot for a monthly London tomorrow morning, And we could revisit that and see where people what let's take people's temperature again tomorrow morning on whether we wanna proceed or kill the fire.
[02:24:44] Magnus Westerlund: I mean, I think one
[02:24:45] Ian Swett: other question too is that are there people for whom if we don't do we don't add a current group, the whole thing is a no go? Like, we move that might be in this category. But, like, is there anybody else who's, like, noted you?
[02:24:55] Mo Zanaty: I think we need to understand who thinks they really need current group, and the people that see problems with it need to talk to those people show them the problems with it
[02:25:02] Ian Swett: when they apply their use case. Can we get, like, a quick, like, who here is in the camp of, like, I really need current group? So
[02:25:13] Mo Zanaty: let's have a beer and show you why it breaks YouTube's cases.
[02:25:17] Ian Swett: And I think we've seen some Okay. Okay. That's all I have for this one. I know we're kinda fully behind schedule and
[02:25:27] Alan Frindell: Yep. That's fine. I mean, like, I I think if you got some feedback that
[02:25:29] Victor Vasiliev: they can use as long as she runs,
[02:25:31] Alan Frindell: you know, butter on everything. So, you know, we're gonna talk with some people. If
[02:25:36] Mo Zanaty: you're a strong
[02:25:37] Alan Frindell: so we have we're dealing with a bunch of adopted drafts on Friday afternoon. I was actually gonna talk to Will about this a bunch and what what, like, how to prioritize those. If you have strong feelings about which adopted drafts
[02:25:49] Mo Zanaty: need to
[02:25:49] Alan Frindell: be discussed this week, come see me at lunch. Lunch is not here yet, but it will be here in the next fifteen to twenty minutes. So rather than trying to launch into the on the Multiple Subscriptions talk, we just do issue with log for
[02:26:04] Victor Vasiliev: until lunch arrives. Can I stand
[02:26:06] Ian Swett: up in the background? I've been talking about that.
[02:26:09] Victor Vasiliev: Like, I mean, you're gonna mess it.
[02:26:25] Alan Frindell: If you wanna stop talking, you can list you can be one of the ones.
[02:26:28] Mo Zanaty: Can I throw up one one wild thought on the previous topic? Instead of debating the current group thing, you know, ad nauseam, can we consider at the end of the day, the data streams are are are delivering either subgroups or flat fetch streams? Why not just give that as an explicit option in in in the in the subscriber or there's no filled FETCH with it. You just say a range, and you say whether you want that range flat or as some and you're the app, so you're making the decision. If you break something, you you're you know what you're breaking.
[02:27:05] Alan Frindell: But you wanna flatten something. Easy to insens the song really quick.
[02:27:08] Mo Zanaty: You you want it you want it sub grouped? You get it sub grouped. And it's up to you to decide which way you want it. And so that could be more provocative.
[02:27:16] Alan Frindell: Or I I I think that's isn't it?
[02:27:20] Ian Swett: No. No. I think those those same, like Explicit Well, I mean, intention. Actually, I think, Mo, to some degree, it's just this dumb thing. Right? Which is, like, if you don't want the current the past objects of the current group, if you want them to be a field test, you can do that. Subscribe. And I think we can make that option. And if somebody's like, no. I really want the objects in the current group in my subscriber streams, then we can make that a toggle.
[02:27:49] Alan Frindell: So the current group, we deliver either by not at all or by that stream or by subscribe stream.
[02:27:54] Mo Zanaty: I'm not saying the current group. I'm saying in general. You can I'm
[02:27:58] Ian Swett: actually I'm saying any group. Like Any range you want.
[02:28:01] Mo Zanaty: Any range you want, you can say, I want this flat or I want it You feel that's really important. I think it's a way out of this mess to figure out who really wants the current grid flat, who who wants the old stuff. Martin opens the next door.
[02:28:15] Alan Frindell: I I I mean, that I think the
[02:28:17] Mo Zanaty: fight is getting everybody on the same page about what they want, how you know? I agree. Our goal is Maybe harder than just saying, this is not even the trust.
[02:28:26] Cullen Jennings: Because I'm sure how to implement this
[02:28:28] Alan Frindell: in less time than we've been discussing it. I I don't know if expanding the knobs to point you know, what's actually advocating for is is move this along or not. I I think having the having the current group, all objects of the current group being delivered either not at all or by touch screen or by a subscribe screen is a pretty simple tweak to both we have that maybe makes everyone happy unless somebody thinks that
[02:29:59] Mo Zanaty: Why we digest it over lunch?
[02:30:01] Alan Frindell: Yeah. Why don't we digest it over lunch? Okay. So do you have some issue with
[02:30:04] Ian Swett: I I would I I've hit request for slides before.
[02:30:06] Alan Frindell: Oh, there you go. Yeah. Probably. Okay. And
[02:30:12] Cullen Jennings: just what come on that that's sort of meta comment on previous thing. It's like, look. I I'm I'm in favor right now of things that don't dramatically complicate the protocol of the implementations
[02:30:21] Alan Frindell: Yep. And remove
[02:30:23] Cullen Jennings: months of arguments from the table of getting us that I prefer to add it. But I'm not it doesn't matter if this one or other one's similar. Like, it's like, we should be at that state of, like, how how we get to something that meets everybody's needs even if some people have crazy needs? Yeah. I'm saying he is crazy, but I'm like, hey.
[02:30:39] Alan Frindell: We'll we'll figure that out of our prepared.
[02:30:41] Ian Swett: Martin, you want this one? Go on.
[02:30:44] Alan Frindell: Okay. I can talk about this. So I thought this issue when I tried to implement things and noticed that we had published blocked. Okay. So now that our request streams are that each request has some body stream, like, the the the request flow control thing is the number of body streams in your lab open. So there's a number of verbs, the ones that listed there, where clearly, like, the the request should retry it. Right? Because the there's no way for the publisher to push that thing those things. Okay. So now we have quick streams blocked. There's a question that I think some people probably credibly said is an API question, which is, like, does does not have a contract to, like, queue pending requests that are rejected by by screen flow control and then retry, or is that gonna get passed to the application? That is that's fine as far as it goes. I can accept that. One response I got over HTTP, we just open another session when we get when we get block. I don't think that's a satisfactory way to do things. Well, first of all, like, I think we've been trying to as in, like as an ITF, we've been trying to discourage opening more connections to the same target, the same that made ever since HTTP one one. We have all these we have set we have requests that have dependencies on other requests that does not work across sessions. And then lastly, servers more or less cannot. Servers can be requesters, and they cannot open new sessions in general. So that I don't know that really works. So and a and a minimum for that, I would like that submit it to you, and that was, I don't think, not obvious to people. So I think it'd be nice to have an editorial tech say, this is not a good way to solve this problem. Okay. The other the other part of it for these first, we talked about, the other thing that we use the other thing that's the other question, what is the expected relay behavior? So if I'm a a client and I said they subscribe to a relay that ports upstream and it is looking for blocked, Like, is is the relay expected to retry that or will it send an error and maybe, like, say, try again in a little bit, although it really is no way knowing when the screen credit is gonna open. Like, I don't really have an opinion about this, but I think you should write down what we what we do in this for in our public reasons. I'll open the board discussion
[02:33:08] Victor Vasiliev: about it. Or you can just just talk. Mean, I know what
[02:33:14] Alan Frindell: a load balancer does, which is, oh, it's another dimension.
[02:33:17] Ian Swett: Right. But in this case, relays don't open connections. Clients relays can't find Nope. I think and then upstream.
[02:33:26] Alan Frindell: Yeah. I think upstream question.
[02:33:27] Ian Swett: But the but the
[02:33:39] Alan Frindell: is behind the behind the net or a firewall. I can't open a pinch. Okay.
[02:33:50] Ian Swett: I think we should write down what we think is going to happen because there's gonna be some cases where it will never succeed. Right? If the client has a maximum of 10 subscriptions and the relay needs so it gave 10 credit. Yep. And then the relay now has another subscriber who wants to subscribe to an eleventh one, but the the client is never gonna grant that credit because there's already a town going. Like, that will always that's just
[02:34:15] Cullen Jennings: gonna fit. And I think
[02:34:16] Ian Swett: so there has to be some revision for the relay So to to give up and be like, I'm sorry, subscriber.
[02:34:21] Mo Zanaty: That's that's one advantage of of not having fetches in the data plane.
[02:34:26] Ian Swett: Well, those are at least theoretically.
[02:34:28] Mo Zanaty: Your fetch will end They're all undersubscribed. Well, I
[02:34:32] Ian Swett: know that that means some streams are
[02:34:33] Mo Zanaty: all better.
[02:34:34] Alan Frindell: So So one one notion is so a couple considerations here. One is that there's always a situation where the reader's gonna have to give up. Like, it's it's gonna queue a fine number of pending requests. So we we eventually will have to fall back on the on the on the on the client doing something here. But, I mean, I'm not excited. I don't want a strong opinion about this. We wanna have their what, you know, have to what the relation do. I mean, the the the the the that I think we're trading off here is, like, try to be easy on the relay and not make it do stuff versus the fact that the client has no idea when that credit will be granted, and so retrying is going to be, like, a very strong trial and error ish process.
[02:35:20] Mo Zanaty: Do you have any sub creditors for max traction or anything like that?
[02:35:24] Ian Swett: I mean, just to buy a credit. That's it.
[02:35:27] Mo Zanaty: But for me, there's a credit card credit?
[02:35:29] Ian Swett: In with transport brand. No.
[02:35:31] Mo Zanaty: No. But I mean, at the app at the app level, do we say anything about so we said that that Relay allows 10 subscriptions. There's no way to know that?
[02:35:39] Alan Frindell: No. It's it's not the Relay. You're doing it for
[02:35:41] Ian Swett: this client for another client to know that the Relay is blocked on Relay is blocked on client a because client subscribed to Relay.
[02:36:04] Cullen Jennings: Because we can't service,
[02:36:06] Alan Frindell: like, request anymore. But if you it depends on which peer you're, like, going to be writing a subscription to. And, like, for some, say, namespaces, like, you know,
[02:36:19] Ian Swett: over here, I can send subscriptions for this namespace, but I can't put that one, then you're in
[02:36:23] Alan Frindell: a tough spot because you don't know when when the client's connecting or you're going to be able to service the request they have.
[02:36:31] Mo Zanaty: Don't most quick stacks just give credit automatically when you get near the watermark?
[02:36:37] Ian Swett: Mhmm. Usually, there's a hard limit on concurrency. So I would say, like, I'm willing to service 10 requests at the same time or a 100 requests at the same time. And as streams close, I would grant more credit. But if the if you're at if you have a 100 open, I don't give you more.
[02:36:53] Cullen Jennings: I think this is what I mean,
[02:36:55] Alan Frindell: I think when get
[02:36:55] Cullen Jennings: we the general DDoS thing, we're trying to use streams as the mechanism to limit all of our DDoS things, which work well in the HTTP case.
[02:37:04] Ian Swett: I don't
[02:37:04] Cullen Jennings: think it's gonna work here. I think if we make streams the limit, we're going to run into unsolvable problems like this.
[02:37:10] Alan Frindell: I don't if this is unsolvable. I think we should write down the the
[02:37:13] Ian Swett: I so first of
[02:37:14] Cullen Jennings: 100% agree, it has
[02:37:15] Alan Frindell: to be definitive. We need to understand this
[02:37:17] Cullen Jennings: and preferably the client needs to understand what happened that went wrong.
[02:37:20] Alan Frindell: Right? I mean, there's two options. REQUEST_ERROR, no stream credit. Right? Or, like, or maybe the hangings or maybe there's a new, like, pause message that says, like, I'm trying. Give it a time.
[02:37:31] Ian Swett: Or the subscribers send the time out. Yeah. Right. Keeps I'm willing to wait this long for Brett to There's
[02:37:38] Alan Frindell: many ways to spell. So I don't I'm so, like, I I I guess I'm not hearing, like, really strong opinions about, like, how we resolve this problem because it needs to be solved. So maybe, like, you or I, friend, you are, that solves it in some way, and we can just, like, see if it makes any money.
[02:37:55] Ian Swett: You simplest thing to do is to say, if there's no credit Request. You know, you can't open it, then you just then you you give the request there, and the client is responsible for retrying. That is, like, the least amount. Okay. I think the second one would be, like, a client we we create a new time out parameter. We use real time out. I don't know if that's a good use of time out or not. No. But the the time out is, if you I'm willing to wait this long for my subscription to be established, and that covers including if there's no credit, I would like to do the queue for credit. And my time out expires before I meet at the end.
[02:38:32] Alan Frindell: I think that we need to break from talking.
[02:38:36] Magnus Westerlund: So talk mostly.
[02:38:38] Alan Frindell: Okay. So alright. So I I guess, actually actually, then so I what I'm hearing is, yes, we should break this down. Like, as far as nobody has any stronger opinions about how should we solve once we just have something that we can all agree to do. And so I think some either Alan or I or a PR that poses, I think, probably REQUEST_ERROR because it's easy, and we'll see people screaming about it.
[02:39:00] Cullen Jennings: So just a quick question on that.
[02:39:01] Mo Zanaty: It sounded like what I was hearing
[02:39:29] Ian Swett: client is already having time out on the subscribe. Right? When it says subscribe, it's gonna be like, I'll get to my subscriber page for 30 seconds. And if I don't have one, I don't care why it doesn't come back. I'm gonna I'm gonna cancel it.
[02:39:41] Cullen Jennings: So that
[02:39:41] Ian Swett: mean I don't think we need to send it forever.
[02:39:43] Alan Frindell: But I I think we need to REQUEST_ERROR anyway because you can always run out of the, like, max pending requests. And so let's just have REQUEST_ERROR as, like, simplest thing to do because
[02:39:52] Mo Zanaty: it has
[02:39:53] Alan Frindell: to do this anyway.
[02:39:54] Cullen Jennings: And and,
[02:39:55] Alan Frindell: like, if people later, if people someone really wants to relay a queues of vendor request, we can add that as
[02:40:01] Ian Swett: well. Well,
[02:40:27] Alan Frindell: That that that's the problem here.
[02:40:29] Mo Zanaty: That means
[02:40:30] Alan Frindell: Because the request comes upstream. So, like, by definition, the requester had the
[02:40:35] Victor Vasiliev: for certain of these verbs,
[02:40:36] Alan Frindell: the requester had the stream credits that make the request in the first question, I think it's happened. Right? So the the relay now needs to pass that request upstream and cannot because the upstream does not have credit. It cannot open another session in general because of firewalls and stuff. The relay could have the relay could well, I mean, problem with stream credit the way stream credit works is it quick. It's max stream ID. And so by closing streams, you don't actually get more stream
[02:41:28] Cullen Jennings: credit automatically. Okay.
[02:41:30] Ian Swett: But it might enable them.
[02:41:32] Alan Frindell: It might enable something to happen. That's I think that's internal relay logic that we wanna get into.
[02:41:36] Ian Swett: Right. Let's just write a request here.
[02:41:37] Alan Frindell: Yeah. Okay. I think that's where we're at. Alright. Sweet. Next slide, please, because there's the other okay. So there's two other verbs. Subscribe and publish are weird because well, I there there's, like, all these flavors in there. So there's subscribing play them on subscribe and publish, and then there's also publishers that covers all of those subscribed tracks. Like, if I can zoom out a little bit, there's there's some duality here, and then, like, if for some reason I can't subscribe to you, like, because there's no credit, like, you could publish to me if I give you credit, right, and and vice versa. What currently exists in the editor's cop editor's draft is there's a message called PUBLISH_BLOCKED, which occurs only for publishers that are in subscribed tracks. And so it's like, hey. You asked for all these you asked for all these tracks, but you didn't give me extreme credit. Dummy. So, like, I can't actually publish this to you, so you should well, okay. So we need to do something about that. That that seems like a sensible subset of subscribe and publish that actually have a specific message for them because they you asked for us, and I can't give it to you because of your mistake. What I do think we need to do is, a number of reasons, is say, what happens when when you get PUBLISH_BLOCKED? What is the expectation? Is the expectation that the peer is going to give you screen credit or that the peer is going to send subscribe or or something else. In principle, subscribe might be blocked, so that's like, oh, that's like another crap. Well, that's kinda dumb, but, like, maybe that happened. I mean, if I was setting college block, I'd probably add
[02:43:23] Magnus Westerlund: some stream credit at
[02:43:24] Alan Frindell: the same time. But I guess you don't have to. You can say, like, I'm not sending this to you. This this particular track to you, and by the way, you can't really ask for it because I'm not giving you extreme credit. That might be useful information, I suppose. And it's possible to expand this for, like, all subscribe and publish.
[02:43:41] Victor Vasiliev: You know? I I don't
[02:43:42] Alan Frindell: think we wanna go there, but that's something we could do to allow this duality to to to come in. But yeah?
[02:43:49] Magnus Westerlund: I think, Colin,
[02:43:49] Mo Zanaty: that's is kind a of.
[02:43:52] Ian Swett: Think I think in retrospect, maybe this naming, I think this message will
[02:43:58] Alan Frindell: because I think maybe PUBLISH_BLOCKED would almost be a better name.
[02:44:04] Ian Swett: Okay. And because I actually think there
[02:44:08] Alan Frindell: might be use cases for which you actually do have stream credit,
[02:44:12] Cullen Jennings: and you just don't wanna use
[02:44:15] Alan Frindell: But you're like, I have like, I I can open a bidirectional stream, but, like, I want to keep selling reserve, and I don't
[02:44:22] Cullen Jennings: wanna blow through all of
[02:44:23] Victor Vasiliev: my buy die streams on this subscribe tracks. And so I'm going to,
[02:44:28] Ian Swett: like, intentionally like like, I'm
[02:44:30] Alan Frindell: gonna limit how many Vidyo streams I
[02:44:31] Victor Vasiliev: use for getting subscribed.
[02:44:33] Magnus Westerlund: So so
[02:44:33] Alan Frindell: I guess what case that is is subscribed tracks had a had a if the subscribed tracks involved had a low priority and there were higher priority subscribed tracks. Yeah. Okay.
[02:44:42] Ian Swett: Yeah. Exactly. Stuff like that. So, basically, like
[02:44:45] Alan Frindell: or if you just needed like,
[02:44:46] Ian Swett: I I may wanna make do a subscribed namespace to
[02:44:50] Alan Frindell: that person in the future. Okay. If I use up my body streams, like, I can't or I can't do that. So, like,
[02:44:56] Ian Swett: I I think probably redoing it to PUBLISH_BLOCKED. And because the intent here is
[02:45:01] Alan Frindell: to say to give the publisher a way to say it quickly.
[02:45:04] Ian Swett: I'm not gonna give you this publish because I can't slash
[02:45:09] Cullen Jennings: don't wanna. Okay. And here's the track name. If you want it, the last
[02:45:14] Alan Frindell: one. Yeah. So it's decoupled from the flow controls. It's clearly not the thing we're trying to point. Probably should have been more decoupled.
[02:45:21] Mo Zanaty: Originally, the the motivation wasn't.
[02:45:24] Alan Frindell: Yes. Motivation was that. I
[02:45:26] Ian Swett: the more I thought about it,
[02:45:27] Alan Frindell: I mean, resources just
[02:45:28] Victor Vasiliev: it's complicated. And, like, I think there are cases when
[02:45:31] Alan Frindell: everybody just to
[02:45:33] Cullen Jennings: be honest.
[02:45:33] Mo Zanaty: Because the
[02:45:34] Alan Frindell: question so then yeah. So the recommendation, do you rename it, and then I think you still need text texting. Like, if this if the subscriber wants it, they should send it you. Right. Okay. It's your. I
[02:45:44] Cullen Jennings: think that makes sense. So I and I was I just like, I don't wanna have
[02:45:48] Alan Frindell: to implement these things if
[02:45:49] Cullen Jennings: they're blocked and then later unblock them all. Don't wanna do that. That. I need some proposal to solve
[02:45:53] Alan Frindell: that for me. So I I
[02:45:54] Cullen Jennings: like that. And make it clear it's not an error. Right? Let's see. There's possibilities to figure out. But I think this also raises
[02:45:59] Mo Zanaty: the thing you said
[02:46:00] Cullen Jennings: that the relay might want to not, you know, reserve some streams.
[02:46:03] Magnus Westerlund: I think it's something like that.
[02:46:04] Cullen Jennings: The client has to understand and has to understand what the limits are. So I think if we're going to have the Relay not use all of its streams, then we need to provide and subscribe tracks, a parameter that's the maximum number of tracks you wanna use or whatever. Right? It's gotta it's gotta be controllable by the client, not just the Relay does random shit. The client trusts and guess what happened.
[02:46:21] Ian Swett: I'm kinda inclined
[02:46:22] Mo Zanaty: to recall in there.
[02:46:23] Ian Swett: Like, just maybe it goes in these scrap tracks okay or something.
[02:46:28] Cullen Jennings: Something. But it's
[02:46:29] Ian Swett: like, I'll give you 10 or something.
[02:46:31] Magnus Westerlund: Yeah. Like
[02:46:32] Mo Zanaty: well, why don't why don't use the next space too large here?
[02:46:37] Alan Frindell: Oh, oh, it's somewhere else.
[02:46:39] Ian Swett: It's the food is here.
[02:46:40] Alan Frindell: It's on there. Excellent. Okay. Alright. So I think it sounds like Ian knows what to do for for this part of this particular Yes. Yeah. Okay. So Alan or I will fight over who writes the request here at least to the other slide. And Ian will take care of this slide. Okay. Issue resolved. Let's go eat. Okay. Before everyone stands up, so we have forty five minutes for lunch at at it's 12:15 right now. 12:30, Tongyu Dai, if that's okay. He will present about his is it accurate to call it, like, Wireshark for MoQ? Basically. Ten minutes. What's that? Okay. Well, he will start at 12:30. If you're interested in that, just eat here so you can hear that talk. If I don't wanna discourage you from going on your sidebar conversations. If there was, we'd have our sidebar conversations as well.
[02:47:33] Mo Zanaty: Okay. Chris is here.
[02:47:35] Alan Frindell: Yeah. It might be good to do that. Well, we got a whole conference room right there, which is great, and, you know, it's it's a big it's a big city. Try to miss the pod. Alright. Let's go eat. And those of you who are remote, we'll resume at thirteen PM London time. Those of you here, please be back by thirteen hundred London time. And and we'll see you then. Here, it's different. Meet echo set. Yeah. Yeah. No. Okay. There there there's a different session for the afternoon because data tracker. So I'm gonna leave the for archival purposes, I'm gonna leave I'm gonna conclude at the I'm gonna
[02:48:19] Victor Vasiliev: include at the end
[02:48:20] Alan Frindell: of lunch, and then at
[02:48:23] Magnus Westerlund: the beginning of lunch, we'll start a new session
[02:48:25] Alan Frindell: because you have to log in again, but this will be stored on the on the YouTube recording for the morning session, this lunch thing. Okay. So those of you who are out out there in the moment, join the new Meet echo at thirteen hundred. Can you I cannot delete that. It is. Yeah. Yes.
[02:53:14] Ian Swett: Would you like would you like to go later?
[02:53:17] Alan Frindell: I wanna know if it's an option.
[02:53:21] Magnus Westerlund: What do you know what the
[02:53:22] Victor Vasiliev: firewall rule thing is? Like, this
[02:53:24] Alan Frindell: How long are you thinking? I don't know. See? Like an hour or two hours? Two hours might be stretching it. An hour is fine. Probably. An hour is fine. Hour is fine.
[02:57:01] Ian Swett: Yeah. But we don't wanna change it yet.
[02:57:03] Victor Vasiliev: We wanna change it after the next year.
[03:09:56] Alan Frindell: Yes. I will approve it for you. Okay.
[03:14:55] Ian Swett: I will not
[03:15:02] Alan Frindell: Yeah. That's that's the problem.
[03:19:25] Victor Vasiliev: Okay.
Session Date/Time: 11 Jun 2026 12:30
Will Law: So, Al, which I think is a, like, all use cases larger than, involved in, in all of the, what? It's just easier to like, do one. Like, of all the things that I started to walk through about like, well, you have to like, iterate through your subscriptions and learn more.
Alan Frindell: I mean, it's, it's only, it's almost like as one subscription, and like, the primary union of the, some sort of, union of the two primers, right? Like, the most, right?
Will Law: That is what 1B is trying to express. Max. So, it changes the publisher processing. 1B is like a, smushed together of subscription. Especially when you combine it. But, there is another potential future. It's like, you can't, you actually can't read in the abstract, all possible extensions that could come in the future, and whether they are compatible with 1B. I think it's the problem. Like, I think I, I can guarantee that I can make an extension that makes 1B, impossible to work. Okay, so not impossible.
Alan Frindell: Okay. Okay, so if there's, if, if, if there's a subgroup that completely matches both subscriptions, I will just open two separate screens, same track with ab- with identical contents, and that's... Okay, I mean, that's, that's like, seems, that's bandwidth wasteful, but I can, but I see that it makes it easier on the, on the publisher, and like, the subscriber. Like, screw you for doing this, so like, you should suffer, you should suffer. So that's fine. You're done. Okay.
Will Law: Okay, I think the text we should say in this case is just like, the reason we allow this is specifically for subscribe after unsubscribe racing, and which means the subscriber should have already thrown away state.
Suas Nandakumar: Yeah.
Will Law: With unsubscribe, which means when it gets the new one, it'll match the new one. So it might get objects that it doesn't expect. Because they are on the, they have the alias, yes, it's possible. There could be datagrams floated on the network from the old subscription that show up.
Piers O'Hanlon: Yeah, yeah. I could imagine some odd legitimate use cases for deduplication scenario. Like, if you subscribe to a fuller track of low test, you know, or something like that. You know, you don't want to have thousands of iterations of it. There's one, both. Okay, I, I, I can live with 1A as an individual, and the only one that really cares is the input parameter.
Will Law: Okay, 1A but with striking the last bit.
Will Law: That's correct. We're saying that the publisher chooses the alias, and the publisher can choose the same alias, or are we saying, publisher always chooses the same alias?
Suas Nandakumar: No, no, we say we're just not saving, they can't. We're not adding any new restrictions. We're saying like, if it's like today, but you can add the tool, and if you choose the same alias, then...
Will Law: Then bad things can happen?
Suas Nandakumar: I mean, yeah.
Will Law: The subscriber can suffer if they choose the same alias. Okay, so it's not that you must, but you will. We'll call, you must deal with the consequences.
Suas Nandakumar: We'll call it the fact that that's a risk. Yeah. And...
Will Law: Suggestive, suggestive that that is yet another reason why you might not want to have overlapping subscriptions. In other words, that those use cases are rare.
Suas Nandakumar: Understood. Okay, like...
Will Law: I think it'd be well worth some text, some warning signs at, in the draft about that.
Suas Nandakumar: All right. Yeah. All right.
Will Law: That one was faster than I think we thought it would be. Cool. Thank you.
Will Law: Oh, are we done? Oh, okay. Um, all right. So, we've now, I believe, finished the morning. All right. So, now, uh, now next up is track blocking, and then we've got draft. All right. And so... 1 and a half. Okay. Uh, okay, so when we defragment, we, we froze, uh, with the request. So, the current constraints and problems are, blocked messages, how much invite, ice creams, can be received and processed out of order. Also, unsubscribe is no longer a block message. It's a quick control message, and so nothing can be ordered with, like, unsubscribe cannot be ordered with respect to any other block messages. It's no longer... Uh, so as for use cases, uh, this is all that came down. Um, one is swap tracks. So, you're in a video conference and you want to, um, replace Alice with Bob. So, the idea of like, wanting to make sure we pause Alice's track, uh, before we resume Bob's, so that we don't have congestion. We want those associated with... Uh, second one mentioned was client-side ABR. Um, there wasn't a lot of detail in the use cases, but I assume that's like, I have partition A, and suddenly I want to move to partition B, without overlapping tracks. That sounds very familiar. We talked about... Um, the third one was, um, update, repeated updates to the same track, like, uh, pause, resume, pause, resume. We want to make sure you end up in the same state. Um, that needs to be ordered, um, but that's already covered in Draft 18, because request updates to a given track are already in order on that track's stream. So, we're just on 1 and 2. I guess the first question, I mean, the whole presentation is built on that that's all the use cases, but are there, did you see any other, any other ordering use cases? We, so this seems like request update is really the thing, like, updating to, updating two different tracks, is not necessarily ordered, so updating forward state, yes, we do have a way of updating forward state, which changes different tracks. But like, if I'm updating the priority of different tracks, or I'm updating delivery timeouts on different tracks, it seems like those cases don't really need to be synchronized. Um, kind of, and then the filters is the other one, like, I'm changing the filter set on the one versus another. Does that need to be, is that ordering? Or is it okay that that is like, you know, that's up in terms of solar?
Cullen Jennings: Well, the, the, the problem with filters today is not, uh, not specifying what it depends on is, knowing in the data plane when it took effect. Knowing that the filter was, was actually applied, right? Like, what I'm getting, what I wanted or what I wanted a minute ago. That has always existed, and back then, no, back then, offers no solutions.
Suas Nandakumar: So... No, no, I'm not, I'm not picking this issue, I'm just saying, one, is there a use case with filter-ness in the, in the range of, you know, you have something that was, you have one stream that was tracking at that speaker, or was basically filtering on some field. Like, for a track or speaker or something like that, and now you're going to pin it in the application and you're going to unpin another one at the same time. Like, and, and, so you're updating the filters on two different streams at the same time. Honestly, I'm, I'm, every case I can think of of this sounds like, eh, okay. You could do one, then the next one, in close succession and it would work out close enough. So, like... Okay, yeah. That, that, that's like the one that's, All right, yeah. I'm going to, I'm going to roll forward with, it's just the switching or the swapping of things. So, uh, the like, range of solutions that we can think of, like, we do nothing and sort of defer to the quick implementation, like, most of these control messages are small, they are all high priority, the network's always going to go in one packet and like, in the very rare cases that doesn't happen, we live with the consequences. Um, we can try to reconstruct the ordering on other, on with, with the control streams. So, you have a required request ID in Draft 18, so try to do that. People didn't like it. It require, required additional changes that were, uh, in order to balance the receiver state. Otherwise, as, as the Draft 18 is written, we don't have to keep receiver state for that. There was an alternative proposal that Victor had in PR 4, which was a similar in its like, attempt to reconstruct the order of the control stream, but still had some of the, some of the same state map problems and was somewhat complex. Neither of these approaches really guaranteed that the ordering was atomic if the application wanted it. It only guaranteed that the messages were received in order. Uh, so, then it's like, how about an atomic message that can handle swapping tracks, or again, I don't know, is there any other... If only someone had told us we needed that. Okay, so this is, this is what I came up with. Real quick before, uh, I think, I think we also mentioned, um, at one point, uh, I don't know if atomic, but like, request update and boundary. Request update at some specific boundary, request update after, or something? Yeah. Like, you know, like, like you were saying, you know, you want the sub-filter to kick in at the enhancement layer, only on the sub-boundary. You don't want it all. Or forward equals one out of group boundary seems to make a lot of sense for this. But you can also just change your filter at start of boundary. You can do that. Yes, that's true, well. If we have the current group filter, you could just change your group filter to currently right, okay, so you could... But, well no, because if, if you set, if you set the filter, If I send a request update says, forward equals one, filter is next group, you know, to whatever, yeah, then you're going to start then I will lose the rest of the group. All right. Oh, but it's, yeah, I'm not getting it anyway, right. Yeah, okay, that works. Never mind. What about, what about going the other way, pausing at the end of the group? Pause it at the end of the group, you set the filter to the next group, yeah, right, got it. Yep, all right. This is, this is... Okay, so this might give us, well, it took a couple iterations to, some of that back, so um... I added a, the proposal is to add a parameter called switch_from, uh, the key bit of it is, is, so you send this in subscribe or request update and it has a request ID that refers to the track that you are switching from. And there's a couple of bits that toggle behavior. One of them is a mode called hard or soft, and we'll see, we'll see that in the next slide, what those, uh, the publish done bit is like, whether you want that track to be, whether you're just pausing that track or if you want that track to end. So, this removes, um, like, if you think about the original switch proposal, like, or, or various other constraints, like, there's no race condition here. The subscription you're switching to has to exist because you're putting the switch_from in the subscribe flow. So, uh, and the one you're switching from has to exist also because you're, that's what you're switching from, has to already be there. Um, and the location filter that's active either in the same parameter set or previously is the one that governs the behavior of going ahead when you switch. Oh, wait, what if, maybe you'll answer this later, but what if the request ID hasn't been received yet? Why would you be switching from something that you haven't, that the receiver hasn't received? Uh... The switch_from you kind of have to have it established. That's a reasonable rule. Okay. All right. So, you must have al- you must have al- you must have already received either from the publisher or subscriber, okay, publisher or subscriber. Okay, that, that's a reasonable restriction. It's fine. Nothing then you can't, this would cancel subscribe on any of, of the active subscribe, how to switch, the alias is different, yeah. So, this is what you do when you get a switch_from. So, uh, look at the filter that's in that message and you can draw up what the start group is, so if it's, start a current group, start a next group, start, we have an absolute group, whatever it is, you you pick what start group is. You step forward one and apply this subscription, the new subscription filter on the new resume track. So, the reason you do that is to make sure you don't lose any future objects by performing the switch, so it's, normally the switch happens fast, and the same thing will happen, but you have to do it, uh, you keep delivery on the suspended track until you have an object ready to publish in the start group of the new track. So like, if I said like, I want to switch at group 10, but I don't have group 10, I just keep nothing happens at all, except until I have something for group 10 to send. Once you do, that's when you make the switch. So, if you're in hard mode, you set forward zero immediately on the suspended subscription, so that will like, stop all the delivery of any things on the suspend. If you're in soft, you set the end group of the old one to whatever the start group on the new one was minus one, which means if there's still objects coming, they'll drain to the end of that group. And you cancel any, if you happen to have any queued but not sent groups on the bigger, or equal to the start group on suspend, you cancel those. And then, you send publish done, the message asking you to send publish done, uh, and then you can send the subscribe okay or the request okay on the new one. So, that's one proposal on the soft, uh... Like, this works great if the groups are aligned between the two, swap on the, really works well. Yeah. But, you know, if you change soft mode, so that instead of saying it's, it sends till the end of the group, like, if you have, if you replace start group with, basically, the group that's currently sending. So in soft mode, it sends to the end of the group that was sending at the time the switch happened. Okay. I think uh, then, then you'd have this working on unaligned ones, which, it solves a race condition where this lands very near the time, the group transition. Okay. I think there are times where by the time you have an object ready to go in the start group, that the suspended track has gotten ahead. And so you don't even want to finish that group. Now that you're ready to send on the start, you want to cancel it. But I don't disagree that you might want the behavior you're asking for as well. There are six unused bits. So we can make another mode, though, I don't know what it's, the distinction with soft. Yeah, so if there's, Yeah. So if, if the, if, if the subscriber, if the old subscriber's behind the live edge because of congestion, then there could be multiple groups between the start group for the new subscribe and what's being delivered. All right. So this is why start group should be in the past. This is why 1642 should land, otherwise, your stuff is. Okay, got it, yeah. All right. I at some point I tried to make a bunch of slow cool slides like Will, Will always do, and I got so lost. So, I was like, It's a bad sign. Okay. Just make, not because of the, the algorithm is simple, I hope people understand like, everybody can realize, feels like they can write this algorithm well, it's like not that complicated to do. But like, trying to map out all the possibilities: where is the subscriber? Where is the suspended subscription? Where is the resumed subscription? And all the different combinations there are, made my head spin, so I'm not. Yeah, so, once you do, so... Could we, in mind, continue delivery of suspended until there is publications of the, of the subscriber of publications of the start group. Start group on resume. Okay, start group on resume, which is the, the next, usually is the next group on the resume. I mean, there's different ways to do it, right? I think there's different cases. So, there's a case where, and this is what, is that? Oh, I think I had to go through some of these examples, maybe it'll be easier, walk through of these on the, on the actual session. Um, is, is the question is like, as observation I have, is that, um, effectively, I was thinking about like, effectively, you can perform entirety of the switch once you have, um, subscribe okay, uh, on the new, because since you, Yeah. On the new, you may not even get a subscribe, you are already subscribed to the streams. Yeah. Oh, uh, so, the point I'm trying to make is like, if I'm switching, and group of Alice, I know that I've usually developed my state, and I at the moment I receive switch_from, I would be able to set appropriate filter on both old and new subscription. I think that is starting to move more towards, what Victor has in, in, for visual, which is PR, um... Is there, is there a PR for this? He, it's in my repo. It's, uh, iframe mark transport or 18, Draft 18. Um, I was, uh, the problem, the reason why I didn't put it in the main repo is that, depends on 1642, and it's very difficult to make the PR without duplicating 1642. Yeah, it's just, that is a queue. Oh, oh, my goodness, there's a queue. Do you guys, can I just run through like, the last couple slides, and then we just, okay. Um, okay, I think, you, you all understand how, um, that either you're going to publish done or not. In soft mode, publish done is a little trickier. Like, you don't actually know when you can send it, if, if publishers has the end of group buffer indicated, it's clear. If they don't, then you basically have to have a timeout, which like, I haven't seen any objects in this group for a while, so like, you can send the publish done. Um, so, that's one edge. Um, I think this is kind of what we already talked about, like, um, if you're switching Alice to Bob, like, they may not be, those, you probably want hard in that case, because the tracks are like, not in group aligned, and so soft mode might do the very, very wrong thing. Um, and the groups might be really long anyway, so you may not want to like, go till the end of the group. Uh, so, that's why, what or the case for hard. Um, so I tried to map this out a little bit, like, and I'm not an ABR guy, but like, it seems like if you're going to up-switch, like, there's common, two ideas, like, there's a conservative, like, it's more important for me to minimize the overlap, than it is, um, to, like, up-grade sooner, and so, you, like, try to compute some unreceived objects in the future, and use soft mode. If you're trying to be aggressive, um, you might use, uh, a hard mode on some previously group that's already received. Uh, and then on the down-switch side, um, if you're being, like, same thing, like, you might be doing this conservatively, like, I, I know I need to go down, but I don't need to go down right this second, versus, if you, if you want to be aggressive in your down-switch, I don't think you want switch_from, I think you want to just unsubscribe right now, and like, you don't want any of this coordination, because it's like, action. Um, this is kind of what I related to before, like, did we discover all the cases? Like, do we need to work this out? Yes, I think so. Um, I, I kind of, I feel like the core mechanism of it, like, both building on 1642 and using a parameter, like, that kind of feels right. I think there's room to add functionality with other bits. Um, my, my inclination would be keep this as simple as possible, and, and let data drive the, the additions that we need. Uh, okay, that's all, that's all the slides. Queue. Oh, oh, my goodness.
Gwendal Simon: Yeah, so first, I mean, I like the idea of Cullen that the, kindly hard, which is like, finishing the group and then stop, basically.
Suas Nandakumar: Current group.
Gwendal Simon: Finish the group that the largest object is in. Which is in between soft mode and hard mode.
Suas Nandakumar: And do the alignment.
Gwendal Simon: Correct. But, uh, yeah, so it does not cover all the use cases, but, but most. So, I think we can survive with this complex of switching, complex of, of, of tracking. Uh, which is doing what, what, what, uh, Victor was saying. In-switch, the relay has the ability to choose where to, to do the soft, uh, switch, or if it is imposed by the clients. Most of the cases works, so I think it's fine, but we need to be able to contact with the thin fetch.
Cullen Jennings: Yeah. Absolutely.
Gwendal Simon: Because any kind of network congestion will make you lagging behind, and so you will need to, and that addresses the point from Piers of command from TLS, and the client is going to, yeah, triggering the switch, which is a good point for this.
Cullen Jennings: I will say that the subscriber, maybe some of you thought of this as well, and for a minute, the PR had, um, an auto mode, where the relay would compare between the largest object of suspend and resume, and then make a decision based on that comparison, but it was still a simple thing, but then, I think I convinced us both that we don't need to, that got confused, so we took it out. Anyway, I think it might be better to hand this off to the experts. Um... That's good. Okay.
Will Law: Cullen.
Cullen Jennings: I, I, I was going to say, I, I think it is good, so like Victor said, I, I think the hard mode alone is worth doing. Yeah. And, the, you know, whether we need, you know, an old way of doing, you know, that...
Will Law: Coach.
Cullen Jennings: Oh, it's gross. Just, just, just draft it. It's gross. Yeah, the relay has to figure that out, but I, I think it is, we should move forward with at least hard, and then figure out, I think we will add these two other things, too, and maybe it's what you had there.
Will Law: Are we saying that we don't need soft at all right now, or are you saying that you might want soft? No, I actually think soft might just be fine, if we sit down and reason through the whole thing, like exactly what we need.
Cullen Jennings: Okay. Well, I mean, I'm, I'm open to soft. There are three modes or four, but... Yeah. I, I think it's just going to be, I think it's, I think it's with, we'll need to reason through the exact cases, make sure there's an optimization. Yeah.
Will Law: Okay, yeah. Where this matters is all the cases where there's an edge case that happens, clear, right? If the, the happy day cases, are easy. It's, it's the weird cases, and maybe we only need one mode, maybe it's exactly what we have, maybe it's something slightly different. It seems like that needs more work.
Cullen Jennings: I agree, yeah.
Will Law: Ian.
Ian Swett: Um, yeah, no, I agree. It seems good. Um, I, I was going to just say that I thought the hard mode, active, would work pretty well for all of these cases, but anyway, you just said that, so.
Will Law: All right, hard. Hard is more of a brainer. We always do that. Do we need more modes? Maybe.
Cullen Jennings: I don't, I, I think it's worth writing it.
Will Law: Like, what does that do? Why are you doing that? Why do you need publish, why, why is the publish? It's like, do you want to subscribe and unsubscribe, or did you want to subscribe and pause, or did you want to, like, or did you want to resume and pause, like, all the combinations are possible on it.
Cullen Jennings: Exactly. But, if you paused it for them, then you can't just use it after. You don't get a signal that it's paused. Wait, what? It did. No, just so like, when the switch happens, you'll start getting data on the new track. Well, well, what's the new stream? It's in forward zero. And you're not going to tell me? You'll know when you get an object from the new track. I think you should tell me. I think you should tell me. I don't like not being told. So, you, you need switch_from okay.
Cullen Jennings: Or you need some other...
Suas Nandakumar: Oh, is it? Sorry, I, I, I lied. We just send request. Request okay comes at the end. Yeah, you'll get, you'll get request okay.
Cullen Jennings: But not necessarily, that's, that doesn't mean that the suspend track got to the end of group minus one.
Suas Nandakumar: That just means the switch has happened.
Cullen Jennings: That's right. And update the filter. No, no, that's, that's fine. It's as long as you tell me that it has happened. And on, on the other track, when its forward state goes from one to zero, at whatever point in time that happens. In hard mode you'll get, that's when you get the subscribe okay. Sure. So but, just ignoring all that, in that other track, when do you get some notification? No. There's not today. So, we're... Well, today, only when... Sorry. Today, only when you send request update, so your request okay tells you that that's done, right? So, this adds a sort of a, "I want to do this in the future, and it'll tell you on, in does, it tells you on the switch_from, on the, on the new track." That is correct. Yeah, so, I... Subscribe okay does it send the, the largest object? Yes, it does. Okay, so you receive some thing which is like, oh, the largest object is 19.2, and then you receive 18.0 because, switch_from is minus one. Yeah. Well, um, yeah, a number of points. Uh, firstly, at a high level, I agree. I, I like the design of this. Number one, can you clarify, are you only toggling forward state? Yeah, okay. No, in soft mode it toggles the end group of the old one, which will essentially terminate that subscription.
Suas Nandakumar: Yes. Well, it'll, the subscription will, if, if you terminate and have the publish done, then that track's, that's, that's the end of it. It will go away. If you set publish done to zero, it just sets the end filter and then leaves it. It's, it's a weird state where it'll technically, it's in forward one, but the filter is blocking everything. And then if, if, and it does, if that object arrives, then then subscription, the old, all the upstream management of old, we don't have traffic coming to an end. Because that's one of the arguments against DTS, right? It consumes a lot of bandwidth for stuff you are not watching. And this in my relay, this is a case where if all the subscribers are forward zero, I send forward zero up- upstream. If all of the subscribers have filters that end in the past, I do not send that forward zero upstream, but I probably should. Because it's the same effect. It's a signal zero on your relay, and they switched from A to B. Does the A subscription going up get cancelled? It doesn't say one way or the other, but a smart relay should, uh, I mean we would, we would want that as one of the, of the requirements. Well, I mean we can get it if there's a, if there's like, if there's an issue about forward, because currently forward state says even if all your subscribers are paused, the draft says you are supposed to subscribe upstream unpaused. Well, I want to stop this, I want to cut, I only want one subscription going upstream, so you'll only have one. Well, no, you'd have more than one. No, you would have two. Yeah, you're saying, oh, I want one, and I've got the one I'm switching from. I want the old one to go away. Are we switching away from it? Even if the subscriber is still keeps theirs open, with the new group? The subscriber is, just, it's a single subscription. It switches from one to another to another, so you don't want any of the legacy, all of these moving tracks behind. It wants to close them. As soon as the switch is complete, it, it, I want a mode where it closes. It cleans up, and closes them. I, I hear what you want and I think you're right. I just, it might need, I think that change might be broader than just switch_from. Okay, I can see, but I think that's important for ABR switching, where we have these ghost tracks hanging around, and we switched away from... Are you also adding publish done? Yep, queue. Yeah. Okay. Okay, sorry, I had, I, I had to stop the three-part question. You have a four-go. Um, to handle perpetually unaligned groups, so switching from track A to track B, but track A's are arriving three milliseconds always after the group boundary ahead of the other track. Or aligned in time but not in delivery order, and you're, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one, so there can be an overlap there at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yeah, you can't touch. You have to wait. Yeah, I, I do. If you land this, then this is probably something DTS would take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, um, what's the one I had on, on the, on the, on the client-side of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, of the, "resource protection" issues, and some other considerations. Kind of an extension to what we already had. I think we discussed this, so back in Boulder we talked about this and we decided that it might be useful to capture this information in some kind of document. Rather than adding it directly to the transport spec. So, we did that. We created a draft. So, it's an informational document, it's not normative, right? It has a cover of, a protocol, subscribers, and publishers. It separates things into data plane, which concerns transport, and then control plane. So, there's some aspects of this that are kind of a compilation of things we've talked about already. And we made some recent updates so we have some more definitions and we're looking at a number of PRs to address those. We're aiming to have a 01, soon, at least for Geneva. And then, questions? Is it worth publishing a document like this? Is this mostly useful as a place that we can land? You know, wait, this could be a problem, you should keep this in the back of your mind as you work on the base spec. Or is it useful to kind of capture that and publish it as an RFC that's just informational? That's one question. Is there an appetite to adopt this as a working group document? And a related question, should this remain a standalone document or should it be merged into some other document? That's the questions that I have.
Will Law: Can I get a quick, physical show of hands, people who have even sort of, sort of read of the document? Actually, quite a few. Okay. That's more than I expected. Great, okay. Continue.
Ian Swett: That's it. That's all my slides.
Will Law: Okay, I guess we can go to the queue. Wendell.
Gwendal Simon: Yeah, so first, I mean, I like the idea of Cullen that the, kindly hard, which is like, finishing the group and then stop, basically.
Suas Nandakumar: Current.
Gwendal Simon: Finish the group that the largest object is in. Which is in between soft and...
Cullen Jennings: Hard.
Gwendal Simon: And, you know, do the alignment. Correct. But, uh, yeah, so it does not cover all the use cases, but, but most. So, I think we can survive with this complex of switching, complex of, of, of tracking. Uh, which is doing what, what, what, uh, Victor was saying. In-switch, the relay has the ability to choose where to, to do the soft, uh, switch, or if it is imposed by the clients. Most of the cases works, so I think it's fine, but we need to be able to contact with the thin fetch. Because any kind of network congestion will make you lagging behind, and so you will need to, and that addresses the point from Piers of command from TLS, and the client is going to, yeah, triggering the switch, which is a good point for this.
Suas Nandakumar: I will say, the subscriber, maybe some of you thought of this as well, and for a minute, the PR had, um, an auto mode, where the relay would compare between the largest object of suspend and resume, and then make a decision based on that comparison, but it was still a simple thing, but then, I think I convinced us both that we don't need to, that got confused, so we took it out. Anyway, I think it might be better to hand this off to the experts.
Suas Nandakumar: That's good.
Will Law: Alan.
Alan Frindell: I, I was going to say, I, I think it is good, so like Victor said, I, I think the hard mode alone is worth doing. Yeah. And, the, you know, whether we need, you know, an old way of doing, you know, that...
Will Law: Coach.
Alan Frindell: It's gross. Just, just, just draft it. It's gross. Yeah, the relay has to figure that out, but I, I think it is, we should move forward with at least hard, and then figure out, I think we will add these two other things, too, and maybe it's what you had there.
Will Law: Are we saying that we don't need soft at all right now, or are you saying that you might want soft? No, I actually think soft might just be fine, if we sit down and reason through the whole thing, like exactly what we need. Okay. Well, I mean, I'm, I'm open to soft. There are three modes or four, but... Yeah. I, I think it's just going to be, I think it's, I think it's with, we'll need to reason through the exact cases, make sure there's an optimization.
Will Law: Where this matters is all the cases where there's an edge case that happened, clear, right? If the, the happy day cases, are easy. It's, it's the weird cases, and maybe we only need one mode, maybe it's exactly what we have, maybe it's something slightly different. It seems like that needs more work.
Alan Frindell: I agree, yeah.
Will Law: Ian.
Ian Swett: Um, yeah, no, I agree. It seems good. Um, I, I was going to just say that I thought the hard mode, active, would work pretty well for all of these cases, but anyway, you just said that, so.
Will Law: All right, hard. Hard is more of a brainer. We always do that. Do we need more modes? Maybe.
Alan Frindell: I don't, I, I think it's worth writing it.
Will Law: Like, what does that do? Why are you doing that? Why do you need publish, why, why is the publish? It's like, do you want to subscribe and unsubscribe, or did you want to subscribe and pause, or did you want to, like, or did you want to resume and pause, like, all the combinations are possible on it.
Alan Frindell: Exactly. But, if you paused it for them, then you can't just use it after. You don't get a signal that it's paused. Wait, what? It did. No, just so like, when the switch happens, you'll start getting data on the new track. Well, well, what's the new stream? It's in forward zero. And you're not going to tell me? You'll know when you get an object from the new track. I think you should tell me. I think you should tell me. I don't like not being told. So, you, you need switch_from okay.
Cullen Jennings: Or you need some other...
Suas Nandakumar: Oh, is it? Sorry, I, I, I lied. We just send request. Request okay comes at the end. Yeah, you'll get, you'll get request okay.
Cullen Jennings: But not necessarily, that's, that doesn't mean that the suspend track got to the end of group minus one.
Suas Nandakumar: That just means the switch has happened.
Cullen Jennings: That's right. And update the filter. No, no, that's, that fine. It's as long as you tell me that it has happened. And on, on the other track, when its forward state goes from one to zero, at whatever point in time that happens. In hard mode you'll get, that's when you get the subscribe okay. Sure. So but, just ignoring all that, in that other track, when do you get some notification? No. There's not today. So, we're... Well, today, only when... Sorry. Today, only when you send request update, so your request okay tells you that that's done, right? So, this adds a sort of a, "I want to do this in the future, and it'll tell you on, in does, it tells you on the switch_from, on the, on the new track." That is correct. Yeah, so, I... Subscribe okay does it send the, the largest object? Yes, it does. Okay, so you receive some thing which is like, oh, the largest object is 19.2, and then you receive 18.0 because, switch_from is minus one. Yeah. Well, um, yeah, a number of points. Uh, firstly, at a high level, I agree. I, I like the design of this. Number one, can you clarify, are you only toggling forward state? Yeah, okay. No, in soft mode it toggles the end group of the old one, which will essentially terminate that subscription.
Suas Nandakumar: Yes. Well, it'll, the subscription will, if, if you terminate and have the publish done, then that track's, that's, that's the end of it. It will go away. If you set publish done to zero, it just sets the end filter and then leaves it. It's, it's a weird state where it'll technically, it's in forward one, but the filter is blocking everything. And then if, if, and it does, if that object arrives, then then subscription, the old, all the upstream management of old, we don't have traffic coming to an end. Because that's one of the arguments against DTS, right? It consumes a lot of bandwidth for stuff you are not watching. And this in my relay, this is a case where if all the subscribers are forward zero, I send forward zero up- upstream. If all of the subscribers have filters that end in the past, I do not send that forward zero upstream, but I probably should. Because it's the same effect. It's a signal zero on your relay, and they switched from A to B. Does the A subscription going up get cancelled? It doesn't say one way or the other, but a smart relay should, uh, I mean we would, we would want that as one of the, of the requirements. Well, I mean we can get it if there's a, if there's like, if there's an issue about forward, because currently forward state says even if all your subscribers are paused, the draft says you are supposed to subscribe upstream unpaused. Well, I want to stop this, I want to cut, I only want one subscription going upstream, so you'll only have one. Well, no, you'd have more than one. No, you would have two. Yeah, you're saying, oh, I want one, and I've got the one I'm switching from. I want the old one to go away. Are we switching away from it? Even if the subscriber is still keeps theirs open, with the new group? The subscriber is, just, it's a single subscription. It switches from one to another to another, so you don't want any of the legacy, all of these moving tracks behind. It wants to close them. As soon as the switch is complete, it, it, I want a mode where it closes. It cleans up, and closes them. I, I hear what you want and I think you're right. I just, it might need, I think that change might be broader than just switch_from. Okay, I can see, but I think that's important for ABR switching, where we have these ghost tracks hanging around, and we switched away from... Are you also adding publish done? Yep, queue. Yeah. Okay. Okay, sorry, I had, I, I had to stop the three-part question. You have a four-go. Um, to handle perpetually unaligned groups, so switching from track A to track B, but track A's are arriving three milliseconds always after the group boundary ahead of the other track. Or aligned in time but not in delivery order, and you're, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one, so there can be an overlap there at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yeah, you can't touch. You have to wait. Yeah, I, I do. If you land this, then this is probably something DTS would take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, um, what's the one I had on, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, "resource protection" issues, and some other considerations. Kind of an extension to what we already had. I think we discussed this, so back in Boulder we talked about this and we decided that it might be useful to capture this information in some kind of document. Rather than adding it directly to the transport spec. So, we did that. We created a draft. So, it's an informational document, it's not normative, right? It has a cover of, a protocol, subscribers, and publishers. It separates things into data plane, which concerns transport, and then control plane. So, there's some aspects of this that are kind of a compilation of things we've talked about already. And we made some recent updates so we have some more definitions and we're looking at a number of PRs to address those. We're aiming to have a 01, soon, at least for Geneva. And then, questions? Is it worth publishing a document like this? Is this mostly useful as a place that we can land? You know, wait, this could be a problem, you should keep this in the back of your mind as you work on the base spec. Or is it useful to kind of capture that and publish it as an RFC that's just informational? That's one question. Is there an appetite to adopt this as a working group document? And a related question, should this remain a standalone document or should it be merged into some other document? That's the questions that I have.
Will Law: Can I get a quick, physical show of hands, people who have even sort of, sort of read of the document? Actually, quite a few. Okay. That's more than I expected. Great, okay. Continue.
Ian Swett: That's it. That's all my slides. Oh, okay. Um, so first, I mean, I, I, I would think we can go with that draft.
Piers O'Hanlon: Yeah, yeah.
Ian Swett: Okay, so we'll, we'll try this. Uh, why does it matter what order we get the request okays back? Like...
Zafer Gürel: Uh, you missed the morning thing about 1642, but, it'll have a, the largest object in it and that matters for how you process those.
Ian Swett: Yeah, I, I, I mostly just don't want like a branching fork of like five different request updates that all depend on some, each other, and, I, I don't know, I feel like this is just a single subscription, head-of-line blocking's okay.
Will Law: That's...
Zafer Gürel: Yeah.
Suas Nandakumar: Uh, no other, um, so, this, this is, uh, basically, follow up, um, what's, what, what the, um, what's the one I had on, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably something DTS would take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, um, what's the one I had on, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably something DTS would take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues, and some other considerations. Kind of an extension to what we already had. I think we discussed this, so back in Boulder we talked about this and we decided that it might be useful to capture this information in some kind of document. Rather than adding it directly to the transport spec. So, we did that. We created a draft. So, it's an informational document, it's not normative, right? It has a cover of, a protocol, subscribers, and publishers. It separates things into data plane, which concerns transport, and then control plane. So, there's some aspects of this that are kind of a compilation of things we've talked about already. And we made some recent updates so we have some more definitions and we're looking at a number of PRs to address those. We're aiming to have a 01, soon, at least for Geneva. And then, questions? Is it worth publishing a document like this? Is this mostly useful as a place that we can land? You know, wait, this could be a problem, you should keep this in the back of your mind as you work on the base spec. Or is it useful to kind of capture that and publish it as an RFC that's just informational? That's one question. Is there an appetite to adopt this as a working group document? And a related question, should this remain a standalone document or should it be merged into some other document? That's the questions that I have.
Will Law: Can I get a quick, physical show of hands, people who have even sort of, sort of read of the document? Actually, quite a few. Okay. That's more than I expected. Great, okay. Continue.
Ian Swett: That's it. That's all my slides. Oh, okay. Um, so first, I mean, I, I, I would think we can go with that draft.
Piers O'Hanlon: Yeah, yeah.
Ian Swett: Okay, so we'll, we'll try this. Uh, why does it matter what order we get the request okays back? Like...
Zafer Gürel: Uh, you missed the morning thing about 1642, but, it'll have a, the largest object in it and that matters for how you process those.
Ian Swett: Yeah, I, I, I mostly just don't want like a branching fork of like five different request updates that all depend on some, each other, and, I, I don't know, I feel like this is just a single subscription, head-of-line blocking's okay.
Will Law: That's...
Zafer Gürel: Yeah.
Suas Nandakumar: Uh, no other, um, so, this, this is, uh, basically, follow up, um, what's, what, what the, um, what's the one I had on, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably something DTS would take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues, and some other considerations. Kind of an extension to what we already had. I think we discussed this, so back in Boulder we talked about this and we decided that it might be useful to capture this information in some kind of document. Rather than adding it directly to the transport spec. So, we did that. We created a draft. So, it's an informational document, it's not normative, right? It has a cover of, a protocol, subscribers, and publishers. It separates things into data plane, which concerns transport, and then control plane. So, there's some aspects of this that are kind of a compilation of things we've talked about already. And we made some recent updates so we have some more definitions and we're looking at a number of PRs to address those. We're aiming to have a 01, soon, at least for Geneva. And then, questions? Is it worth publishing a document like this? Is this mostly useful as a place that we can land? You know, wait, this could be a problem, you should keep this in the back of your mind as you work on the base spec. Or is it useful to kind of capture that and publish it as an RFC that's just informational? That's one question. Is there an appetite to adopt this as a working group document? And a related question, should this remain a standalone document or should it be merged into some other document? That's the questions that I have.
Will Law: Can I get a quick, physical show of hands, people who have even sort of, sort of read of the document? Actually, quite a few. Okay. That's more than I expected. Great, okay. Continue.
Ian Swett: That's it. That's all my slides. Oh, okay. Um, so first, I mean, I, I, I would think we can go with that draft.
Piers O'Hanlon: Yeah, yeah.
Ian Swett: Okay, so we'll, we'll try this. Uh, why does it matter what order we get the request okays back? Like...
Zafer Gürel: Uh, you missed the morning thing about 1642, but, it'll have a, the largest object in it and that matters for how you process those.
Ian Swett: Yeah, I, I, I mostly just don't want like a branching fork of like five different request updates that all depend on some, each other, and, I, I don't know, I feel like this is just a single subscription, head-of-line blocking's okay.
Will Law: That's...
Zafer Gürel: Yeah.
Suas Nandakumar: Uh, no other, um, so, this, this is, uh, basically, follow up, um, what's, what, what the, um, what's the one I had on, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably something DTS would take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues, and some other considerations. Kind of an extension to what we already had. I think we discussed this, so back in Boulder we talked about this and we decided that it might be useful to capture this information in some kind of document. Rather than adding it directly to the transport spec. So, we did that. We created a draft. So, it's an informational document, it's not normative, right? It has a cover of, a protocol, subscribers, and publishers. It separates things into data plane, which concerns transport, and then control plane. So, there's some aspects of this that are kind of a compilation of things we've talked about already. And we made some recent updates so we have some more definitions and we're looking at a number of PRs to address those. We're aiming to have a 01, soon, at least for Geneva. And then, questions? Is it worth publishing a document like this? Is this mostly useful as a place that we can land? You know, wait, this could be a problem, you should keep this in the back of your mind as you work on the base spec. Or is it useful to kind of capture that and publish it as an RFC that's just informational? That's one question. Is there an appetite to adopt this as a working group document? And a related question, should this remain a standalone document or should it be merged into some other document? That's the questions that I have.
Will Law: Can I get a quick, physical show of hands, people who have even sort of, sort of read of the document? Actually, quite a few. Okay. That's more than I expected. Great, okay. Continue.
Ian Swett: That's it. That's all my slides. Oh, okay. Um, so first, I mean, I, I, I would think we can go with that draft.
Piers O'Hanlon: Yeah, yeah.
Ian Swett: Okay, so we'll, we'll try this. Uh, why does it matter what order we get the request okays back? Like...
Zafer Gürel: Uh, you missed the morning thing about 1642, but, it'll have a, the largest object in it and that matters for how you process those.
Ian Swett: Yeah, I, I, I mostly just don't want like a branching fork of like five different request updates that all depend on some, each other, and, I, I don't know, I feel like this is just a single subscription, head-of-line blocking's okay.
Will Law: That's...
Zafer Gürel: Yeah.
Suas Nandakumar: Uh, no other, um, so, this, this is, uh, basically, follow up, um, what's, what, what the, um, what's the one I had on, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues, and some other considerations. Kind of an extension to what we already had. I think we discussed this, so back in Boulder we talked about this and we decided that it might be useful to capture this information in some kind of document. Rather than adding it directly to the transport spec. So, we did that. We created a draft. So, it's an informational document, it's not normative, right? It has a cover of, a protocol, subscribers, and publishers. It separates things into data plane, which concerns transport, and then control plane. So, there's some aspects of this that are kind of a compilation of things we've talked about already. And we made some recent updates so we have some more definitions and we're looking at a number of PRs to address those. We're aiming to have a 01, soon, at least for Geneva. And then, questions? Is it worth publishing a document like this? Is this mostly useful as a place that we can land? You know, wait, this could be a problem, you should keep this in the back of your mind as you work on the base spec. Or is it useful to kind of capture that and publish it as an RFC that's just informational? That's one question. Is there an appetite to adopt this as a working group document? And a related question, should this remain a standalone document or should it be merged into some other document? That's the questions that I have.
Will Law: Can I get a quick, physical show of hands, people who have even sort of, sort of read of the document? Actually, quite a few. Okay. That's more than I expected. Great, okay. Continue.
Ian Swett: That's it. That's all my slides. Oh, okay. Um, so first, I mean, I, I, I would think we can go with that draft.
Piers O'Hanlon: Yeah, yeah.
Ian Swett: Okay, so we'll, we'll try this. Uh, why does it matter what order we get the request okays back? Like...
Zafer Gürel: Uh, you missed the morning thing about 1642, but, it'll have a, the largest object in it and that matters for how you process those.
Ian Swett: Yeah, I, I, I mostly just don't want like a branching fork of like five different request updates that all depend on some, each other, and, I, I don't know, I feel like this is just a single subscription, head-of-line blocking's okay.
Will Law: That's...
Zafer Gürel: Yeah.
Suas Nandakumar: Uh, no other, um, so, this, this is, uh, basically, follow up, um, what's, what, what the, um, what's the one I had on, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, on the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as wellSuas Nandakumar: Okay.
Will Law: Okay, so I...
Ian Swett: Okay, sorry, I had I, I had to stop the three-part question.
Will Law: You have a four-go.
Ian Swett: Um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always at the group boundary ahead of the other track. They're aligned in time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yeah, you can't touch.
Ian Swett: Yeah, but...
Ian Swett: Yeah, I do. If you land this, then this is probably something DTS would take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch...
Will Law: You mean relay to the upstream.
Ian Swett: Relay to upstream would handle, would do a switch from. That makes my brain hurt, but... It's already, you've written the code, so... No, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active.
Will Law: Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or...
Will Law: Yeah, okay.
Ian Swett: I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So, my, my, uh, another thing I'll say is, I, I'm going to, I started paying my like share in your PR, so we'll look at that there. Okay. Um, next. Us. Oh, oh, I, I hope this is the, the last point. Um, one question I had is, is the three, and then wait. Next is, basically, follow-up, um, what's, what, what the, "resource protection" issues. The last point, um, we have to have a fairly clear architecture. So, our, like, larger, just, consistent, as a single... Okay. Um, okay, so, first, I had, I, I had to talk about this, so, um, to handle perpetually unaligned groups. So, switching from track A to track B, but track A is arriving three milliseconds always after the group boundary ahead of the other track. And aligning the time but not in delivery order. And you are, are you waiting like, "Oh, I need to send the next group." No, you just, hard stop at the next boundary. This, what will happen in this case is, if the, the track you're switching from, so always getting the relay first, it will start delivering objects in the start, in the group's aligned, it'll start publishing the first bit in the start group, then you'll get an object in the resume track's start group and you'll be like, "Ah, this is what I want." And then it will effect either a hard or soft switch on the old one. So, there can be an overlap there, at the, but what I found with, I think 1378 had a little bit of this tail chasing problem, which is like, I want to get to a group where I haven't started the old one yet, but that may never happen. Right, if the, if the smaller track is always getting there first. Yep. You can't touch. You have third party? Yeah, I, I do. If you land this, then this is probably some things that we can take advantage of. If, if the prior thing I mentioned, which you can clean up cleanly, so instead of DTS keeping six open subscriptions and just totally forward state between them, it could actually automatically execute switch, you mean relay to the upstream. Relay to upstream would handle, would do a switch from. That makes my brain hurt, I, it's hard. You've written the code. Just call, call the thing, but now we could have a mode on DTS, which is bandwidth efficient, and only keeps one upstream active. Oh, the me, oh, uh... Oh, first of all, I had one note, so, um, Ollie's going to present some experimental results, uh, tomorrow, that deal with the old switch proposal, but I think are probably germane to this as well, so whatever that's worth. My question is, uh, so to be clear, the request ID must be a subscriber or publish, right? This can't use this with the subscriber track, or... Yeah, okay. I think, I think the PR says so. It, it can't be your own one. Okay. Maybe there's use cases with subscriber self, but... Okay, well, right. So,Will Law: what did you say? I'm sorry, I missed that.
Suas Nandakumar: My question is, is this like, uh, "I want to have a way of saying, I want to have this and that, so that we don't have to worry about this." That's, that's what, that's what I was thinking.
Will Law: Okay.
Suas Nandakumar: Okay, I can see that.
Will Law: If we, if we are to, if we are to proceed with that, then we will have to, we will have to have a more general way of saying, "I want to have this and that." Yes.
Suas Nandakumar: Okay.
Will Law: Okay, I'm, I'm okay with that.
Will Law: Yeah, but then we would have to have, we would have to have a more general way of saying, "I want to have this and that." Yes.
Suas Nandakumar: Yes, that is correct.
Will Law: If we do that, then that's, that's fine. We can, we can, we can write a PR for that.
Suas Nandakumar: Okay.
Will Law: So we can proceed with that.
Will Law: I think that's a good way to proceed.
Suas Nandakumar: Okay. I, I, I would agree.
Will Law: Okay, so I will, I will take the action item to write that PR.
Suas Nandakumar: Okay.
Will Law: And then we will, we'll try to, we'll try to have that ready for Geneva.
Suas Nandakumar: Okay, sounds good.
Will Law: Okay, thank you.
Will Law: Oh, is there any other, is there any other, is there any other business? Okay.
Will Law: Okay, so I think we are, we are done for today. Thank you all for coming. We'll see you tomorrow.
Suas Nandakumar: Thank you.
Will Law: Thank you, bye.
Piers O'Hanlon: Bye.