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.