Session Date/Time: 20 Jul 2026 12:00
[00:00:11] Martin Duke: Okay. It's 02:00. Will someone in the back please close the door? Welcome to media real quick, everybody. This is session one of three. We get three times the fun this week. Welcome to Vienna, those of you who just arrived like me, and you see the mascot of a local American football team. This is the IETF Notewell. It describes some of the legal implications of you being here, particularly regarding intellectual property and our code of conduct. If you're unfamiliar with these documents, I suggest that you type IETF Note Well into a search engine and read up on them. Here's some resources for the meeting. You're probably familiar with them all. Okay. Obviously, we're using Meet Meetecho for this meeting. If you are attending here in person, please scan the QR code that you see on the mic stands. We don't have it anywhere else. So to record your attendance here and so that you can participate in joining the queue and other interactions. Is the is there a
[00:01:23] Magnus Westerlund: separate slide for the
[00:01:24] Martin Duke: the MoQ? Yeah. Yeah. Okay. Alright. If you are a remote participant, we strongly suggest to use a headset because the noise cancellation properties of Meetecho are not all that great. And if you wish to if you wish to ask a question or a comment on a presentation, use the Meetecho tool, presumably a like the like client if you're if you're here in person to raise your hand and so on. Okay. We have a fun little experiment. You can watch MoQ on MoQ. So you still need to use the light client to do any of the interactive stuff, but if you wish to watch the video of this meeting over MoQ, our friends at Meetecho who are MoQ enthusiasts have set something up there. So you see the URL and you can watch it that way. I'll give you guys just a minute to do that if you're gonna do that. Some of you might exit and come back.
[00:02:35] Magnus Westerlund: It's now in the shot. So, yeah, it can go on.
[00:02:38] Martin Duke: We can go on.
[00:02:39] Magnus Westerlund: Okay. It's on the shot.
[00:02:40] Martin Duke: Oh, thank you. Alright. A number of upcoming dates. As you know, we don't take a lot of time off in this working group between events. The deadline for our consensus calls on draft updates have fallen a little bit behind, so we have an open one for the draft 18 changes. That closes actually today, so your last chance to take a look at the diff between eighteen and sixteen. Did we do one on seventeen? Well, whatever. Do do do do the diff of 16 and 18, and if you have any issues with those, then please speak up today. We recently announced our virtual interim schedule between now and October, and you see those dates there. And there have been no comments about our general habit of doing it Monday Monday morning Pacific Time about 09:30. So we're gonna keep doing that, but we always do invite comments about those those norms. I will also note that September 8 is a Monday because of US Labor Day on September 1, so that is the one exception to our Monday rule. Also, we recently announced our next hybrid interim, which will be in downtown Seattle, Washington. It is a four day event. The first two days will be interop. People tend to filter in over those two days, and then we will do issue discussion on the Wednesday and Thursday of that week. Here's the agenda for today. There have been edits leading up to a few moments ago based on slides that we got and didn't get. You can read it as well as I can read it. So I'll just give you a second to look at it. Would anyone like to bash today's agenda? I will advance to the other session agendas in a moment.
[00:04:37] Cullen Jennings: Just confirming with Mike, you're mostly presenting. Right? Okay. Yep. Yep.
[00:04:46] Martin Duke: Here is Thursday's agenda and Friday's. Wouldn't like to bash any part of this week's agenda?
[00:05:06] Cullen Jennings: Cullen Jennings. I mean, I I the top end filter stuff is super important to us, way more important than many other things here. I'm sad to see it put as the last item on the last day.
[00:05:17] Martin Duke: Yeah. Well, we had a discussion about that. The the current the current status of our last consensus call on that is that it should be an independent a separate draft, and we've not seen that separate draft.
[00:05:28] Cullen Jennings: Can you put an email on the list that that is your consensus? Because I do not believe that's a valid consensual.
[00:05:32] Martin Duke: There's an email on the list about that.
[00:05:34] Cullen Jennings: Okay. I'm objecting to that consensus formally right now. How do we proceed with that objection?
[00:05:40] Martin Duke: I mean, the I guess
[00:05:44] Cullen Jennings: I I I don't I mean, please send me the information you're basing that on. I don't think I I I like, look. Just go through it and look at it. I'm willing to be convinced. But I think that it was fairly clear there was not consensus. And you choose to mean you can routinely take not consensus to mean, therefore, we're gonna do what I wanna do. And I don't think that that's really valid in this case.
[00:06:09] Martin Duke: We had a show of hands and a call on the list. Uh-huh. And the the combination of those two things led to a very strong consensus that we should work on it in some form and Unclear. Far less than rough consensus that we should bring it into the MoQ t draft.
[00:06:30] Cullen Jennings: Right. I 100% agree with what you just said. That is different than what you just said a minute ago. Yes.
[00:06:35] Magnus Westerlund: And from that, we have done a shares decision. I will state this is a shares decision as you might include that. We the reasonable thing to get progress on this is to make it as a separate draft, and that's now been request to you. And that also goes actually towards SSTS also, which we also so I think we're coming down to because looking at these two PRs for both of these things, it's getting very difficult to follow what's happening when you actually don't have an own repo with its own issue trackers to comment on the specific list. It gets way too confusing.
[00:07:18] Cullen Jennings: But on the other ones that were similar to that, a 10 page draft got reduced to, like, I don't know what, fifty, hundred lines in the actual document. Like, it's waste it's very, very difficult to understand how to insert this into the document. Right? And if we want to insert it in the document, then we need to put the things into the document that allow the extension points. And I don't mean IANA code points. I mean places in the algorithms where you say, this is a place where algorithms can be extensible, and here's what you can do in the algorithm. And that seems like a lot more work to me. And we've never had time in the working group where people could spend time discussing these two pros and cons. That's why we don't have consensus yet on what this should be.
[00:08:00] Martin Duke: I think there's been quite a bit of agenda time allotted to top end.
[00:08:03] Cullen Jennings: There's been agenda time allocated to discussing the top end algorithm. May I break discussing which of these documents it should be in. Mike?
[00:08:12] Zaheduzzaman Sarker: Hey. So I think this is a reasonable discussion to have. I'm not sure this is a discussion that needs our face to face time. I'm also going to point out, Colin, it is not the chair's job to convince you that there is consensus. It is the chair's job to call consensus. And if you disagree, you can file a complaint or an appeal, and then it would be their chair's job to convince me that there's consensus.
[00:08:40] Cullen Jennings: Okay. But but, I mean, I think I think Martin and I agree very strongly on it was about fifty fifty, roughly speaking, and that that's not consensus. Right? Either way. Yeah. Right? I think that that like, Martin, you and I are on the same page here. Right?
[00:08:57] Martin Duke: I would characterize it the same, but I I mean well, okay. I I I think I'm gonna listen to AD, we can take it offline. Yeah. Okay. You know, we I I I will say, like, we are we are still pretty far from working last last call. There's always a possibility that things could come in. I would suggest that we work those issues separately and then address it later.
[00:09:23] Cullen Jennings: But this is a core issue of the draft, which you are deciding to even though half the working group thinks it should be in, you are deciding to basically not allocate agenda time for repeatedly time meeting after meeting after meeting, right, for this topic?
[00:09:39] Martin Duke: Well, we it got substantial time in London.
[00:09:43] Mo Zanaty: Can I just clarify for the other thing? I think what's really what's really useful to move forward is at the last time the consensus was called on this, it was like a seven seven split about whether or not it should be adopted now into the merged into the MoQ t draft. And the the really important point now is to figure out where the where the seven that didn't favor merging it right now have objections because it wasn't ready. They weren't there were aspects of it that they wanted to understand better or there were changes they wanna make, or there's just never going to be a time where it's ready for MoQ t. That's the point that we need to figure out. Because if we address the issues that were opened and then people are still objecting, that's what we need to figure out. I
[00:10:24] Martin Duke: would love some to staff in asynchronously rather than all in agenda time because we have a lot of things to get through. I I I feel like well, Top End has received a fair amount of agenda time. I'm not saying it can't get in, but if you could do some op I mean, I think you know who the people are. And if you could maybe coordinate off, you know, asynchronously with them, that would really help us get through the other stuff. Okay. Well, obviously, not to full satisfaction of of the people that are concerned.
[00:10:56] Mike English: Yeah. Yeah.
[00:10:59] Martin Duke: Okay. I I Let's just Magnus and I will discuss maybe doing another one on the list if we feel there's been a lot of movement on that issue. Okay. Alright. Any other agenda bashes? Okay. I now it's up to our Alan Frindell to talk about what's changed with the MoQ t draft since IETF 118.
[00:11:31] Alan Frindell Frindell: Is there a way to make this? There we go. The world's biased against short people. Hey, everybody. Perfect. Thank you. Okay. So there's been two draft updates since IETF 118. Draft 18 was published on May 12. That is our current interop target. Draft 19 was published just a couple weeks ago. There are definitely some people who are very who've already started trying 19, which is great, but we're still targeting 18 for the broader group. This presentation covers them both together. If you wanna know which feature actually landed in which of those drafts, you can see there's a change log at the bottom of the document. And our next interrupt target is likely gonna be draft 20, and we will cut that in about eight weeks from now, which will be four weeks before our next hybrid interrupt. Okay. So what's happened? We've landed 72 PRs, which averaging 33.6 per week, so that's a lot. And there have been about a thousand new net lines in the draft, which are new features. There's been significant work done on to go take our security considerations to another level, a lot of clarifying text, and there's AINNA tables. And actually, I noticed that about 10% of the line total comes from the change log itself. So I think the headline thing that's been added from in terms of features and changing the sort of surface area of the API is range filters, which have been presented in both interims and full ITFs. So we'll go through it a little bit quickly. To give you a summary of what's there, it closes a very old feature request from a couple years ago. And now as a subscriber, you can filter your responses based on priority subgroup ID, object ID, and integer property values. You can express all the relevant spaceship operators. There is a set ID concept that you can use to create and and or combinations that are which should give you pretty much all the flexibility you need to filter stuff. For property filters in particular, there's two different modes, and this, I think, caused a little bit of confusion, but I think we understand what they mean, which is that for when you're when you're making a subscription and you add a property filter, that is matching against object properties, properties that accompany the objects in the data plane. If you include a property filter in a subscribe tracks control message in particular, that matches against track properties only in the data in the control plane. And if there's no match, there will be no subscription, and so you don't get a chance to do the other kind. And this has implications for how you do, like, GAP processing logic in a fetch response, for example, when there's filters, because you're not gonna get some stuff and you don't know if you if it got filtered or if it just never existed in the first place. We talked about our URL scheme, I think, in IETF 118 and Boulder. So this is has now landed in. So we now defined at least the basics of how MoQ t roles work. I think there's a couple outstanding issues yet about some of the some refinements, but, like, the core thing is there. So the basic idea is you open a quick connection, and you can include both the h three and MoQ t ALPNs in there. If the server picks h three, that means you you're not if you wanna get MoQed, you're gonna try web transport next and use WT protocol negotiation to get your version. There's similar logic for TCP and h two in there. Actually, is it? I'm not sure. Okay. We've also defined a media type for a MoQT session. This is the type of the MoQT session resource, the one you're connecting to. It is not the type of the actual media, like video and and and audio and etcetera. The reason we did this is we wanted to use the URL fragments to have specific meaning to MoQT clients, and you can't do that unless you have a media type. So we have defined a media type, and the fragment has the structure you see there where it starts with some a type identifier, which has a registry in our document. And then so MSF is the key example. They have, like, identified their type and then said after that colon what happens there and how MSF is supposed to inter interpret that. This fragment is always stripped out of the URL. It's never sent on the wire. It's handled by the client. I'm just gonna, like, pause a second. If anybody have any questions about this, this is the kind of crowd that's likely to have URL questions. Okay. Other things that have changed in the control plane relative to subscription. So you already heard me mention subscribe tracks. You might have been like, what subscribe tracks? So we just we had one message, namespace, which is how a subscriber can solicit, usually from a relay, information about who else is connected to that relay and what you can do. So that has been divided sort of into two different verbs. Now subscribe namespace is for discovery. It will tell you just about other namespaces that are available there versus subscribe tracks is what we've, long time ago, historically called wildcard subscribe. And that is just giving you, like, the actual tracks themselves. And subscribe tracks has also been updated. You automatically exclude your own published tracks. Let's see. A few other things. Group order came out of publish okay. It's either specified in subscribe tracks for all publishes that are under that subscribe tracks, Or The U if a publisher is initiating publish sort of, I don't call it a naked publish or an unsolicited publish, they just get to unilaterally decide what the group order is going to be because we don't let you update it. We now allow multiple subscriptions to the same track, which has been a restriction we had for a long time that we removed. The use case we are targeting for this is primarily cases where we can't necessarily if you're you're changing between one subscription and another and we couldn't guarantee the ordering, Therefore, we took the minimalist approach to deduplication, which is like, there's no deduplication. So it doesn't matter. The publisher can give both the subscriptions the same track alias, but the doc says, like, every one of they're treated like completely independent subscribers. So the same object is gonna come on the wire twice, even though the subscriber couldn't possibly use two copies of it. They'll look exactly the same for the most part. And subscribers, if they had filters on, like, subscription a had one set of filters and subscription b had a different set of filters, even though the publisher knew which one of those subscriptions it matched, the subscriber needs to refilter. Yeah. Request update now has concurrency limits, and you can you can coalesce the processing of, if you get multiple of them, you can condense that into one. Mo Zanaty?
[00:18:12] Mo Zanaty: Real quick, do we say anything about if there's a group order conflict between different subscribers? I'm sorry. Couldn't hear your question. Do we do we say anything about if there's a group order conflict between different subscribers? How would the Relay subscribe upstream?
[00:18:29] Alan Frindell Frindell: I this is a problem that's not new. We've had this problem. And I think it's similar in some ways to subscriber priority, which is that, like because group order on a subscription is just an important of the priority
[00:18:41] Mike English: on that.
[00:18:41] Alan Frindell Frindell: Relay's gonna do just to what Relay's Relay's gonna it. Relay's upstream. So if you get a conflict, then the re the relay gets to decide. But we usually say, like, these parameters are hop by hop.
[00:18:54] Mo Zanaty: So So just relay choice, basically. Same as priority.
[00:18:56] Mike English: Yes.
[00:19:02] Alan Frindell Frindell: Body control plane cleanup. So when we talked to you last, the brand new thing was that we just moved, I'll say, to a more HTTP like model where all every request has its own bidirectional control plane. We discovered when we sat down to implement that that it actually we were not as crisp about what it means for each side to send a FIN, to send a RESET, or send a stop sending. So we spent a fair amount of time figuring out how that is supposed to work and have written that down. We removed required request ideas and ordering constraint. So when we first went to BIDAI streams, we said, okay, we need the ability to reconstruct the ordering of the control stream, and we had this required request ID concept in there that lets you do that. However, we found that this caused a bunch of problems. It had sort of an unbounded state problem. And so we took a step back. We looked at some other mechanisms, and then we tried to analyze the use cases of when did people really care about the ordering. And at least in our London conversation, it seemed like everyone was pretty sure that the only time that it really matters when you're trying to really do some sort of a switch, where you're you you're you wanna pause one track and resume another. And so there is an open PR for a new parameter called switch from. We'll talk about it, I think, a few slides from now in more detail. But, essentially, we're using that as our that's our new target for we're we're, like, bringing in ordering constraint or coordination, cross track coordination. There's now a redirect error response and the ability to migrate an individual subscription, which is another feature that we have added. On instexability, there is now a code point range that can indicate that a track property is mandatory to understand. And so this is just to prevent a publisher from sending to some something to a subscriber that they know is not going to work. And so if you have such a property that so changes how a subscriber might interact with a track that you can't even deliver it to them, then you can reserve a code point in this range for your property. And there is we also took the very first tuple of track namespaces, and we have reserved some of them. So the first track tuple that is just a single dot is forever reserved, and no one is allowed to use it. If it is a dot and the word session, this is a very this is a special extensibility mechanism which is handled entirely within the MoQ T layer itself, and this never goes to an application. So use cases for this might be like you want to expose information about, like, the congestion control or something and have that delivered via a track. You can have it you're set you can use this as an extensibility point to register that track as, like, sort of a, you know, my session is owning this rather than the application. And then if you wanna start with a dot or anything else, we just said you need to register an IANA code point for that. But it gets passed to the application. So if and we come up with something clever like well known, in the future, we we won't, we know that people will have to check-in with us via an ANA registry. Okay. Data plane. What's going on there? We added a bit in the subgroup header to indicate if that subgroup starts with the first object ever published in that subgroup. And I think we added this for reasons where, like, you know, for caches or or other reasons. So it's just very useful to know. Like, we already had a bit that was like, this was this the last object in this group is the last one ever, but we didn't have a first, so it's sort of symmetric. We have taken delivery timeout and split it into two different types. There is an object delivery timeout, which is your favorite delivery timeout that we've had for a couple of years now. And now there is a subgroup delivery timeout, which is I believe they can be used together. The primary difference is that a subgroup timeout only applies once you have seen the end of the subgroup. So you've seen the fin or you have some other if you're the original publisher, you know that the subgroup is over, so you you just start the timer later versus the object one is really an object by object timeout. And people had different use cases, so we said, okay, we can just have both. And we've defined them both to be either track properties or object properties, meaning that this is useful for subgroups. You can have different subgroups have different timeouts. So your base layer may have a much longer timeout, an enhancement layer may have a shorter one to keep things fresh. There is a new parameter for fetch called fill timeout. This is for it's it represents like a budget that the publisher has to fill any gaps, really, for relays, to fill any gaps in its cache. So if it encounters a hole, it has to go upstream. Eventually, if this budget is exhausted, instead of trying to go figure out what is in the gap, it just returns this unknown status field we added sometime last year. And there are now also padding streams and padding datagrams, which can be used by a sender to probe available bandwidth. Okay. A few editorial highlights. Like as I mentioned before, there's been a lot of work on security considerations. I think there's a lot more. There's a couple PRs in flight, several issues that are open. Obviously, it's very important to to get the right level of detail in there. So but it it's it's a big step up. So thank you for who worked on it. There's some guidance about what you can do with zero RTT, which is good. We also renamed what were previously called message payloads to be called message body in control messages just because we thought maybe payload might confuse people with what's going on in the data plane. And the message called publish blocked is now called publish skipped, and that was hopefully gonna give people the clear like, more clarity that you're not going to get it later unless you ask for it. Okay. This was a slide that I presented at the last IATF, and we were very excited. We had just cracked the 100 issue level in the correct direction. All these numbers were green compared to the previous IATF, and we we said that our dream was that we were gonna get to issue zero sometime after this meeting. And I'm just gonna kinda go through. So we we were on our way. As of May 12, we had a we were down to 69 issues. Half of those were editorial issues, and several of the remainder had open PRs or needs PR labels. And we dedicated our virtual interims in that set of months to, like, these big rocks that we still had outgoing ongoing, and may I think we made some important decisions there. Filters made it in, for example. And then at the London interim, only a month ago, we, like, discussed and we made decisions on almost every outstanding issue that we still had. So, like, things were were going really great. It looks sort of like this. This is the issue count over time. And you can see, like, the the editors and the authors were this this didn't come for free. Like, there was a lot of effort going in to, like, drive this count down to where we were. And then people started implementing draft 18. We obviously knew that was gonna people are gonna find issues. Like, that's that's not unexpected. It's welcome. And then same deal. In the interim, we sit together, we talk, and people are like, hey. Did we think about this thing or that thing? So, like, that caused another little spike. We then had an extremely detailed review that really changed the landscape of what the work it was that we thought we had in front of us. And again, we do welcome extremely detailed reviews. I will say editors know that the editorial state overall of the document is not ideal, and we will plan to address it. So I we would prefer we already have 50 edit open editorial issues. If you wanna file an editorial PR for something that's bothering you, please do. But otherwise, just know we're gonna take care of that later. So we don't need I'm not saying all these issues were editorial, but a chunk of them were. So and then, you know, we took that as a reset and, you know, kinda picked up our cadence, and and we are where we are. But the graph is essentially flat. We're not going to get to issue zero shortly after this meeting. So this is how it really looks. There's now a bunch of issues that are all related to auth. We formed an auth design team. I'm super excited that we're gonna get recommendations, and they're gonna cover some of the work they've done so far, hopefully, on these issues. Almost every other category has had an increase in the number of issues. And the the total gap, at least compared to March, can almost exclusively be done captured in the editorial column. But I will say that if we're adding 13 issues every IETF cycle, we're not gonna finish. So that's a problem. So how are we gonna get there? And I thought about this, and I really think that it comes down to to to two things, focus and effort. So if you look at what this group has, like, our attention is very divided. There's many adopted drafts. They have LOAK, MSF, CMSF, cat, privacy pass, secure objects. I think that's everything that's adopted. Maybe I missed some. But we also have extensions, s c s SSTS, top end, tempo, which is something new. But then people I know are working always constantly on applications, demos, and there's, like, individual drafts. Like and we absolutely need so many of these pieces to have, like, a fully functional ecosystem. And in as much as they inform transport requirements, we need that work to happen. But, also, if MoQ transport never ships, none of those drafts mean anything. So we need to, like, find the right balance of, like, okay. We're we're giving the attention we need to these things, but I think the community needs MoQ transport to stabilize. And I think in order to stabilize, we need people to focus on it, and we need and we need the effort. Frankly, the like, reviews and updates for PRs is is too slow, and asynchronous engagement on issues in GitHub is poor. We only really get things done when we, like, grab ninety minutes of your synchronous time every two weeks, and that slows us down. So again, like, the ask from the editors is, like, let's take a breath and, like, try to, like, really, like, nail down as many things we have. I don't know how many people remember, but this is the birthplace of MoQ. The first MoQ buff was here four years ago. So let's not make it another four years. And so that that's something I plead to you. Does anybody have any questions about any of this? Rohan?
[00:29:37] Rowan Wheeler: Hi. During the agenda bash, I almost asked this question, but I've decided to wait for this slide. So we have three sessions. If this is actually important, then maybe we shouldn't talk about the stuff on Friday.
[00:29:54] Alan Frindell Frindell: That particular ask is slightly complicated because I am going to miss the meeting on Friday. And I but you're more than welcome to resolve all the issues in my absence.
[00:30:04] Martin Duke: So this working group is unusual in the extent of synchronous time we have outside of big ITF. We have hybrid interims that are about fifteen hours of discussion, and we have ninety minute virtual interims every two weeks. So our the chairs have made a conscious decision to make big ITF meetings be a little bit at a higher altitude to for some of us that are maybe not following things quite as carefully and getting really in the weeds and all this other synchronous time we have.
[00:30:37] Rowan Wheeler: Yep. I understand that. I Yeah. Appreciate that. But by by bringing these issues up, you make people think about it. You distract people who would be paying attention between even between the interims, potentially, from from spending more time on on transport or on, you know, local secure objects.
[00:31:00] Mike English: Okay.
[00:31:01] Martin Duke: Well, I think we're slotted for about ninety minutes on MoQ t issues this week, if I'm not mistaken, which is kind of a lot for a single draft.
[00:31:12] Alan Frindell Frindell: And if I can jump in, I don't necessarily think that it's a lack of the synchronous time that's slowing us down. It's more about someone if you file an issue, and then the editors are quick to engage on that issue. Like, if you don't have a response on your issue from an editor in two or three days, that's very unusual. You will usually get one the same day. Like, we see you and we want to help you, but you may have filed your issue and you disappear. And now we can't progress that issue anymore. We have to wait until a virtual interim to bring that up. Or if you file a PR and you will get a review from the editors on your PR, usually within a week at most, and we will provide you feedback. And but then if you don't update that PR for a while, then it's going to languish. Or, you know, we have people who are supposed to whose approval we need in order to merge, and we need those people to be reviewing things in a timely way. Like, that is much bigger. That's more an obstacle, I think, than the actual synchronous time. We bring the synchronous time, the big discussions, we can't resolve asynchronously.
[00:32:14] Martin Duke: If
[00:32:15] Alan Frindell Frindell: no one else has anything, I am all done.
[00:32:24] Mike English: Can you call the next one?
[00:32:27] Martin Duke: I can do it. Never mind. Yeah.
[00:32:32] Mike English: So,
[00:32:37] Martin Duke: Mo Zanaty? Is it locked? Right? Yeah. Clicker's there.
[00:32:49] Mike English: Okay. Set the timer again.
[00:32:52] Mo Zanaty: Okay. We're gonna give an update on the Low Overhead Container media format. So there were actually two revisions that were pushed three and four, mostly around the properties and the INA registries for them. To remind everyone, the properties were the metadata that we used to have as object headers in the MoQ object. And then we moved into the payload of of the of the MoQ object. And now we've actually gone in two different directions. We have the public properties, which are still in the MoQ object header, and then we have the private properties that are actually inside of the MoQ object payload. And so that was a change in in o two. But just to recap, that's what the properties are that we're referencing in the rest of the stack. And so in version three, we added a new property for the audio config. For video, there was already a video config because almost every video codec requires some kind of initialization data like that. A lot of audio codecs don't, like Opus, but some do, like AAC. And so now we added this audio config property for those codecs that need it. And similar to video, it maps directly to the web codecs audio decoder config. And the description property in the and that is the exact byte stream that you would put inside of your AAC raw. I think it's called the audio specific config. And so this is a new track or object property, and it's a link prefixed type zero f. And then we revised all of the properties because there were multiple collisions. And there were still some collisions even after that. So that's why we had to do a rev update again to do an o four. And so the ways the way things stand right now is we have the time scale and time stamp. Those were already in in MoQ t, but they had the wrong number. So we did a PR against MoQ t to fix that also. And then MoQ t didn't have the rest of these things, so we did a PR to MoQ t to add the rest of these things as well. And then there was also a conflict with secure objects. Secure objects did not appear in the MoQ t registry. And so people other drafts wouldn't know whether or not they're colliding with it. So we did a PR against that to add the secure objects extensions as well properties as well. So now this is the exhaustive list of all of the properties in in LOC, and they're also reflected in MOQT now. Issues that were closed, track properties, they're not gonna be there's no facility to authenticate them. Everybody seemed to be okay with that. The property collision we just talked about, we're not doing without MoQ. We don't have a facility to carry LOC over some other protocol. Framemarking was changed. Instead of using a variant, it was is now using explicit links. And audio config property we just talked about. And the INF feedback was also the registry collisions. Things that are left open. The
[00:36:25] Mike English: one
[00:36:25] Mo Zanaty: that probably merits some discussion is the first one, frame durations. So there's a request put in about identifying how long each video frame is. So having a frame duration property on each object. And there's, you know, ways to delta compress it and eliminate it if it's static or constant. But some people feel like there should be an expression of duration, at least for for video frames. Any anyone that feels whether we should or should not, happy to hear in the room or on the list.
[00:37:05] Martin Duke: There's a queue.
[00:37:10] Alan Frindell Frindell: Alan Frindell from Dell. My comment was actually a couple slides back on the the collisions. I think I left this comment before, which is that I mean, we'll end up renumbering everything in MOQT when we get to the end so that, like, everything that we reserve in that draft is, like, all numeric from zero, and I think that'll cause churn here too. So have we thought about just, like, saying that, like, secure objects, you're starting at I I don't know. Pick a number. 80 instead of 00. And then, Luke, you're starting at 90 or something similar. So that just granted, we should be now con keeping things organized in the MoQ transport as, like, placeholders won't keep step stepping on each other, but I can't promise that we won't anymore because as you've noted, it's flawed. So anyway, that was just my idea.
[00:37:56] Mo Zanaty: Yeah. I mean, we this is about the fourth time that this has happened. So, yeah, if we wanted to do a formal, you know, range allocation for each draft, we could do that.
[00:38:05] Ted Hardie Hardie: I know you don't need
[00:38:06] Alan Frindell Frindell: to be formal. Can you because I imagine you'll renumber as well when we get closer, but just just as an ongoing so not something I'd
[00:38:12] Mo Zanaty: say let's leave it as as is now. And any new registrations, let's say let's we'll give a number for a look, give a number for MSF, give a number for secure objects, and everybody use that as their starting point.
[00:38:23] Magnus Westerlund: Will?
[00:38:25] Will Law: Yeah. Will or Akamai, very similar question to what Alan Frindell did about about the properties. Right? If you look at the registration, I think MOQT reserves in a property space zero x seven a and and up for application usage. And I would think locks and applications. So for MSF, I didn't register in the property table in MOQT. I just allowed MSF to use the application defined space and registered them in MSF. Should should we do something similar for lock and not not even be in this table and therefore avoid all this collision problems that we're having?
[00:39:02] Mo Zanaty: I remember the I I forget the exact numeric ranges, but the the point about lock is we wanted to have the small one byte range.
[00:39:10] Will Law: Yeah. There's There is a one byte range.
[00:39:12] Magnus Westerlund: Yeah.
[00:39:13] Martin Duke: Well,
[00:39:16] Will Law: zero yeah. Okay. I guess it's it's slightly larger. Okay.
[00:39:19] Alan Frindell Frindell: I I think there are a few of these app applications specific. The the thing that can happen with those is that you can have 10 different applications hitting your Relay that all have assigned different meanings to those points. So if your Relay ever needs to do something with it, and there's no way to necessarily know which application has is going through a an object belongs to. We don't have like a content type type header. So these are they they can they they're nice in that there's this range of one byte codes. Anybody can use them, and they're never gonna collide. But it's not super useful in that relays can't really necessarily be like, oh, here's the local timestamp if you put the local timestamp there if they need it for some reason.
[00:39:57] Will Law: But, Alan Frindell, are are relays meant to be using audio level video config? Audio config, I don't think they are. Right?
[00:40:03] Ian Swett: I I don't know. Yeah.
[00:40:09] Will Law: So okay. So I would like some feedback on for MSF. Should we be doing what what Mo Zanaty's doing here and claiming a prop registering property types in MOQT, or should we continue to reuse? I'll I'll bring that up in the MSF section.
[00:40:25] Rowan Wheeler: Right. Rowan, may I to answer the Will's question, I mean, I think there are some properties here that you would need as a relay to, for example, do speaker selection. So even if the content was encrypted. Thanks.
[00:40:44] Mike English: I guess
[00:40:44] Mo Zanaty: there's a general open issue about numbering of the properties and whether we should use application or common property values for things. Think we're probably gonna follow-up on the list about this. I wanted to make sure that people give some comments and feedback about the open issues, which is, first and foremost, like I said, the frame durations. I really want an answer about whether or we should add that into low properties. Web codecs does have a duration. It's required by decoder, but there is a field in web codecs for frame durations for both audio and video objects. So
[00:41:20] Martin Duke: Colin, please be brief if you can.
[00:41:23] Colin Perkins: I will try to be brief. Colin Perkins, University of Glasgow. Just on the open issues and the parameter values, if you haven't done so already, and it's possible you have because I haven't been following this that closely, I would encourage you to look at the types of things we ended up adding when we were doing RTP to decide whether you want to include them, whether you want to possibly leave space to include them in future, or whether you are explicitly excluding them and make sure you have space in your parameter ranges and make sure you've you've taken these into account. So you so you don't end up with it in a horrible mess down the line if you realize you need to add them later.
[00:42:05] Mo Zanaty: Yep. Thanks. Good feedback. Yeah. We've heard some similar things about video orientation and all the things that are registered by WebRTC, by by RTP, by other specs. Alright. That's it.
[00:42:20] Martin Duke: Thanks, Mo Zanaty. Next up is Colin and secure objects.
[00:42:36] Mike English: Thanks.
[00:42:38] Cullen Jennings: Okay. So secure objects, if there's been very few change I'm gonna talk a little bit about some of the changes going since the previous ITF. But mostly, I'll just focus on the ones that have happened since our last interim meeting, which is pretty minimal. So there's not a lot changed in here. So the a bunch of work done on describing the threat model. We've talked about that that previously. This mostly came addressing many thanks to Magnus for a a great review on that And just tried to get clear on the type of things that we protect against and the type of things we don't protect against. Didn't change the protocol that much. One of the attacks that hadn't been described in there that's one of the ones that we think about a lot, that is a different attack in this type of environment from many other environments where we do security designs, is because you can cause a message to fan out to lots of subscribers, a relay that was a it was a bad relay might be able to send it might have, you know, a million downstream subscribers that it tries a different attack on each one of those millions. So it allows it to really multiply how fast it can try attacks quite rapidly. So there was some discussion about that and implications to the key length changes from it. Again, doesn't it didn't change fundamentally how this worked or any of the things on it. It was just part of the analysis of it. We moved to all fixed with integers to just make it very clear how they're canonic. You know? So basically 64 bit integers in the security places where we're canonicalizing them for security reasons. They're still all variable and short when they're sent over the wire. But in the place that we're going to take a bunch of numbers and we need to expand them to a common byte order before we compute a hash over of them to check some security property, we just move that all to 64 bit integers, basically. ...Mo brought up that this may not, this may be useless. So we moved the publisher priority to be recommended to was one of the not to be recommended, it's one of the things that's covered by the end to end authentication. So it's not encrypted. Obviously, the relays have to read it. But they this was a they can't change it because we're like, well, there's no reason for the relays to change this. Mo points out the relays can do whatever they want. I mean, even if they don't change it, they can still decide to prioritize or ignore it or do whatever they wanted. So this is a a very fake savings. It's like, you can't change this number, but you're welcome to ignore it. So may maybe this was a bad change. I I don't know. I'd welcome any comments one way or another towards this one way or another.
[00:45:18] Alan Frindell Frindell: Alan Frindell Frindell. So one question I have is we have we've been we're talking about the possibility of updating the default publisher priority and how that can end up being a little bit racy at times. And then it's like, well, you know, sort of the we haven't landed that in this spec yet, but it seems like we might. And if we do, then I want is that gonna impact this where, like, it's not that it even really is wrong, but it just got compressed or decompressed strangely. And when you do I don't know enough about the crypto here, but is it clear that, oh, the priority was the thing that was broken, or will it look like the whole object somebody touched something and we don't know what?
[00:45:54] Cullen Jennings: It it would look like the whole object was broken. You can't tell what part of that object was broken. So I I see your point on that. But I think the part that's racy in our whole changes of that was how the changes happen, which wouldn't change on this, is when when the data was encrypted, it would know what was the right priority was. That would be the priority represented in the data. And that part of delivering the priority publisher priority is not racy. So I don't think it's it's it's an issue. The part that's racy is getting it is is sort of how we deliver. But, again, that like, we could think about that more. And if it's an issue, that's a showstopper.
[00:46:29] Alan Frindell Frindell: Like Yeah.
[00:46:29] Cullen Jennings: I mean, I have to pull this out.
[00:46:31] Alan Frindell Frindell: Right? I would like, I don't think that prior maybe you can construct an application in which knowing that the nobody's screwed with the priority. Like, if someone's touched the priority, I don't wanna look at that object because I don't know anything about it. But, like, that seems a little overkill to me. And, like, if we just tell people, like, this is not authenticated, so don't put if your relay is super important dependent on some number, you can put it in you can protect that thing, but not this one.
[00:46:55] Cullen Jennings: Okay. I don't think this really helps anything by protecting it. So maybe I think I got a little bit overzealous, and I will take this out as as feedback on on this and and go with most suggested. Just remove publisher priority from being one of the authenticated fields. Is that thumbs up from people?
[00:47:10] Mike English: K. Sounds good. I was just gonna
[00:47:12] Rowan Wheeler: say that this the semantics like, you could have two different semantics. One is a thing that the publisher indicates what the what it would like the priority to be from the beginning. And the other is what is the actual priority that relays apply to it?
[00:47:33] Cullen Jennings: Okay. So that whoever's doing minutes got that in the minutes.
[00:47:36] Rowan Wheeler: So basically, I mean, it sounds like people do not see a value in having a publisher, publisher indicated.
[00:47:45] Cullen Jennings: Only people who read this are the relays. Right? Like Yeah. And they can do anything. And there's it gets overwritten by five other priorities in five other places. It's like, you know yeah. Okay. So the the object IDs are limited to 32 bits in this. We've sort of discussing on the side some ideas of maybe changing that. But right now, I don't think that those are a good idea. I'm not recommending that, Recommending we leave them the way they are for right now. So there may be a little bit of discussion in this one, but just to understand where it is. If you're using secure objects, you're basically limited to object IDs that fit in 32 bits. You're welcome to use group IDs that are for the full 64 bits. And the reason is so that we can fit this in a nice six bit nonces, which has some security perform or some performance increases for a bunch of the the common crypto we use. The We cleaned up a little bit this padding. So it has the ability to add padding to the packet that is in the encrypted portion of the packet so an attacker can't tell how much padding was added. And this just allows you if you are concerned about you're using a voice codec that perhaps by the variable size of the codec reveals something about the signal, about what the actual audio is or something like that, there is concerns about some of the audio codecs on that. But there's many other cases where the length of the data might reveal data to the attacker. This gives you a way to expand all your packets to be a common size or a common set of sizes or to otherwise obfuscate the information that might be left. And it's just it's it's exactly what you'd expect. Some padded you know, you add some padded data in the encrypted area. Let's see. We discussed previously the track properties are not secured by this. We fixed a bunch of just things that had gotten inconsistent in the draft over time. And we added a bunch of oops. I cannot this cannot seem to
[00:49:53] Ian Swett: there we are.
[00:49:54] Cullen Jennings: Okay. We have a the IANA registries don't match as previously discussed. We'll of course map those up. They don't match in multiple ways, the numbers, the names, etcetera. But we need to align all of those correctly as this stuff gets finalized. And I I maybe I'm missing a slide on here or skipped it, but we added a bunch of test vectors as well. So next steps on this, there's there's a couple implementations, Rust and TypeScript. We've been I've been playing with this in various various forms, a couple different groups. And at this point, I really don't I think that this draft is really ready for working group last call. And so that's that's sort of the state that I would like to see happen with it next. Now I believe in finishing things and wrapping them up and not having to discuss them more. It doesn't mean it would necessarily get published. It would be, you know, it it would probably be waiting for the MoQ transport draft to have its iAnna registry table set up first. Right? So it'd be blocked for a long period of time. But I would like to sort of just wrap this wrap up and and and call it done. Any thoughts on that from people of big big things they know they want done to this draft before we call it done?
[00:51:16] Zaheduzzaman Sarker: Yeah.
[00:51:17] Mo Zanaty: I think it is pretty much done. But the recent discussion about the object ID, I think it does merit considering Magnus's proposal to go back and look at the and see if if the 96 can really go to one twenty eight. I think the the the extra room there is for key IDs. Right? And so you wanna figure out how much of that is really necessary for the key IDs.
[00:51:38] Magnus Westerlund: Bet between posting the initial comment later, I found out that the actual it's fairly strict in in the ITF defined AIDs to be 12 bytes and 96 bits. So
[00:51:48] Mo Zanaty: Absolute hard number.
[00:51:50] Martin Duke: Yes.
[00:51:51] Mo Zanaty: That's because the carve out of the other four bytes is for key IDs?
[00:51:54] Magnus Westerlund: No. It's the nonce. Just for the nonce, it's 12 bytes. So that's the nine
[00:51:58] Mo Zanaty: But but the whole point of the nonce is the nonce is unique with a certain key. Right? So Yeah. Invoke your AES with with you're gonna invoke with a 128 bit thing, and the upper 32 is some key ID. Right?
[00:52:10] Magnus Westerlund: No. No. No. This is part it identifies the key. And then from the key, you use 12 bytes nonsense. Yeah.
[00:52:21] Cullen Jennings: I I can walk you through all this offline. And the other thing too is this is regularly misconceived at IETf. ASGCM does support numbers other than 96. It's just when you use anything other than 96, there's an extra hash that happens on every packet that's quite slow. So it's a pretty perform serious performance impact.
[00:52:41] Mo Zanaty: So there's that. So we're stuck with the 32 bit object IDs.
[00:52:47] Chris Lemons: Probably. That's unfortunate. Yeah. Exactly.
[00:52:52] Cullen Jennings: We talked about forty eight forty eight and everybody when they looked at their applications was like, actually, really it's the group ID things that we wanna be able to use the full group. And like, if it's really questionable why the object IDs even go to 64 bits in the use cases we have in the working group anyway inside of a single group. It was just we used a VAR int and it goes to 64. It wasn't really a driven requirement. So I think people had felt much stronger about using the bits towards the group than the other way around.
[00:53:26] Rowan Wheeler: Hey. Rowan again. So I'm like, I'm I kind of am a little uncomfortable with the idea. Like, I think the document is pretty close to damn done. But whether last call is appropriate before we really finish with with MoQ t, like, I just think we would need another working group last call. And that might be okay, but I don't know if there's a way that we can put it in a, like, a parking lot until then.
[00:53:55] Magnus Westerlund: Yeah. So I know other groups have done kind of a freeze call decided to say, okay. We we do a review now. If everyone agrees, we think it's ready, we put it on the parking lot until the relevant normative reference is ready so we can do the final review when they go through. I think that might be a model for this in this case.
[00:54:16] Cullen Jennings: I mean, I view most documents have more than one working group last call, and I did not say we should send it to the ISG. I said we should working group last call it, and then probably wait for the other things that it needs before it goes to the ISG. But it would make it easier to, like, get, like, the security area to review it and things like that.
[00:54:34] Martin Duke: Okay. So you would like to so your preferred state medium medium term state for this is a first working last call and maybe a sec early sec review? A sec review, broader review, and then probably,
[00:54:48] Cullen Jennings: you know, ask the AD if they want it before MoQ and that they sit on it or whether the working group sits on it. But, basically, either the AD or the working group sits on it.
[00:54:57] Mike English: Okay. Yep.
[00:54:58] Suhas Nandakumar: Yep. So, Suhas, I think plus one two having kind of do a first first working group last call because the last few edits mainly are on the editorial nature more than changing anything in design. And also the dependency on more core transport is, like, since we depend on the object model that's been stable for a while. So that's that's kind of proof that the object model for the more core transport is working. And I I would like to see if we can continue that way. Thanks.
[00:55:24] Mike English: Alan Frindell
[00:55:27] Alan Frindell Frindell: from Dell. I think I mean, what so that's just said about the object model. I mean, this 32 like, object IDs, like, should we be considering constraining object IDs in MoQ t more? Because the security properties of, like, oops, I accidentally wrapped my used the same nonce twice seems bad because I so, I mean, that's sort of concerning, and I don't know. Will the security area or somebody if if you have a you have a normative reference to MoQ t, and MoQ t is undergoing the level of churn that we know it is, are they gonna what are they gonna they do they need how much of MoQ t do they need to read, or are we saying we're freezing the components that this depends on?
[00:56:04] Cullen Jennings: No. They're gonna what they need to review even if we change them isn't gonna change their review. Right? Right. That we're not changed that much. And, like no. I don't I and to I don't I I just wanna be clear that we're the the current design of this is if you try and use secure object on something that's that's larger than 32 bits, you're going to get an error in the code. The code said you should not do that. Right? You just can't do it versus the the wrapping things. And so so there's there's not a foot gun there.
[00:56:29] Mike English: Okay.
[00:56:30] Cullen Jennings: We could add a foot gun, but, like, I think the more we talk about that, the more we decide not to. Yeah. So I I think that that stuff's fine. And, you know, the the parts of MoQ that we're changing are not the stuff that's going to change the security review of this.
[00:56:45] Alan Frindell Frindell: My my other concern about going to working last I mean, I think it's good to get more review. However, I I'll note that it looks like both implementations come from the same place. And so it would be really good to have at least one other completely clean room implementation that's came from some other set of people who looked at your spec and implemented it and said and we showed interoperability between those implementations. I don't know if that's blocking review or not. I mean, it's still reviewable, but that's will drive more things than we
[00:57:13] Cullen Jennings: can do. I certainly wouldn't be sad to see another implementation, of course. But, like, it's not a normal ITF step to require that. So yeah.
[00:57:20] Martin Duke: Mo Zanaty, please be brief.
[00:57:22] Mo Zanaty: My one concern is this is an encapsulation. And what we've learned from, like, things in RTP, like the SRTP encapsulation, you know, didn't anticipate other encapsulations like FEC or something else. Then we asked, oh, now when you when you do these things, which one comes first in the ordering and all that? And so when when you try to plus secure objects to something new in the in the future, is that new thing gonna have to specify all a bunch of stuff about secure objects like LOC to specify a bunch of stuff? Or can they use it generically? And if they use it generically, if there's some other wrapper that does something else not security related, then do we have to worry about the interplay of those? If we thought about the model for how that would work, that's that's my only concern about, as a draft by itself, it looks great. It's ready to go. But if we add something else later, does that does that something break?
[00:58:11] Cullen Jennings: I mean, I we've we've thought about that a bunch. And I I think that it supports like, it doesn't specify whether other containers go inside or out of it, but it works with both of them. It can go inside other containers. It could have other containers inside of it. And I think that that's the best we can do in a generic way.
[00:58:28] Martin Duke: I would like to ask a question as chair. If, say, we gave this another six to twelve months, would is anyone likely to is is there likely to be an additional implementation of this draft given that time frame? Just raise your hand if you're like, yeah. We'll probably implement that if you give me a little more time. Okay. So I don't see anyone in the room or online saying that. So it doesn't look like we'll get another implementation if we just wait. So maybe that's not a consideration. Okay. Fair enough. Thank you, Colin.
[00:59:00] Suhas Nandakumar: Thank you.
[00:59:03] Martin Duke: Okay. So next up is the off design team report, and the the lead of that team is Mike, and he's gonna come up and share happenings. Alright.
[00:59:38] Mike English: Thank you. So I'm Mike English from Cloudflare, and I was assigned this off design team. So I'm not You did volunteer. I did volunteer.
[00:59:51] Mo Zanaty: But you
[00:59:52] Martin Duke: didn't volunteer be leader. You you volunteered to be leader. Yes.
[00:59:55] Mike English: Am not an auth authentication or authorization expert, but I am going to do my best to summarize some of the things that we've discussed so far. There are a bunch of other wonderful people who have been contributing to this, including the people who volunteered on the list ahead of forming the design team and some others who have also contributed ideas. In particular, Thibault had an extensive conversation with him yesterday and got a lot of useful feedback on some of our discussions and ideas. So this is mostly an update. We're kind of exploring the design space but I wanna give people some context on what we're working through. These are kind of the topics that we were given to work on and we plan to come back to the working group by October with some answers on these things. We are also taking on ownership of the auth tagged issues on the draft. So those are also things that are part and parcel of all the other auth things that we're working on. Okay, so one big thing, and this was kind of the impetus of starting this focused design team, is the need for a mechanism in MoQ transport to communicate a challenge. So you can't just provide a bearer token if you want to do proof of possession, you need some way to have a challenge and response exchange that also occurs. So we've done some POCs with privacy pass in particular, where we have kind of used the error response as a way to smuggle this challenge through. But that's not super clean and it's not really what we should be doing. So at some point, we're gonna need some new messages on the wire as a way to communicate that. But in order to make sure that we're doing that correctly, we wanted to explore kind of the whole design space and say, okay, what does auth look like more generally? And we, there's a number of different configurations and use cases that have different requirements. This is maybe the key thing here. MoQ is a protocol that allows for fan out. So if you just have to do hop by hop authentication authorization, that's relatively simple. Questions arise when you hit this boundary where you are now aggregating subscriptions and you need to make decisions about trust boundaries and where things are being authenticated and authorized. So in this simple example, subscriber one auths to the relay. It wants to subscribe to a track that originates with P1, the original publisher. R1, you know, then can authenticate upstream. Exactly what that means, we'll get to. But the that session is then established and a track is pulled and, you know, a track flows to S1. Then a second subscriber arrives and also authenticates. And now we have questions. Can we reuse this data? Can we like share this with this other subscriber? It depends on the use case. So in a broadcast scenario, it's a little bit more straightforward what this might mean and and how how the trust boundaries might work. So for example, you may have multiple relays in a tiered configuration but all of the subscribers can have their authentication handled at the edge relay. So you can say there's a trust boundary here at the edge, and then the relay to relay auth could be a separate auth that happens due to whatever business relationships exist between these entities. And then also upstream to the original publisher, whether that's a client or a server whatever. So basically if you can delegate the responsibility of checking these things to the relays, your life gets a lot simpler. However, there are use cases where that may not be true. And this is where things get a little bit more complicated. If for example, you have an application where you have a requirement that the original publisher directly authenticate including proof of possession and subscribers, then you need to thread through the relay somehow the challenge response and a bunch of state needed for all of the subscribers. And if this could differ from one subscriber to another, you potentially lose some of the benefits of the efficiencies of aggregation. So there's this inherent tension in MoQ transport protocol. Like we want to be able to do efficient fan out, but that constrains other things that we're trying to do. So if we want to individually authenticate each subscriber with the original publisher, then the original publisher needs to individually authenticate each subscriber, which is, you know, placing that responsibility back on the original publisher, more load, etcetera. So one possible solution to this problem is to sample the subscribers that are coming in. And so you take only a subset of them based on some configuration and for that subset, you then relay things upstream and make the original publisher responsible for authentication. This is workable potentially, but very complicated and this is what Thibault and I spent a couple hours talking about yesterday. I think it's doable and I think that the use case, the requirements here may be real. But it gets awfully complicated to do kind of end to end things like this. So if it is at all possible, it is preferable to find ways to push the information needed to make authentication and authorization decisions down to the relays. Because if you can delegate that responsibility, then you can retain the fan out properties that you want. So a third potential model would be to communicate the policy that the original publisher may have and whatever ancillary information is required to make decisions in the session authentication. So in the token or whatever is used in setup exchange between the publisher and the relay. And then the relay can take that policy into account in making its decisions about end subscribers, which I didn't think is something that would appeal to me, but in some ways it's simpler than the second case. Yes, Ted Hardie?
[01:07:42] Ted Hardie Hardie: Ted Hardie Hardy, occasionally confused privacy enthusiast. In the case we were talking about before, you call proof of possession, and I would call challenge response, what the challenge response is meant to do is to take information that should be known only to the subscriber, and create a hash such that the original publisher can confirm that this hash is the hash that they would expect from one of its subscribers. And so, they can keep a table of what the hashes would be for the different subscribers, do a quick search against that. Hush matches, you're good to go. To pass all of that information down to the relay, so that the relay can do that, what you could do is provide that giant hash table. The difficulty with that is that actually then contains a lot of information about your subscriber base, its size, its characteristics, to the relay, which seems like a relationship we did not originally presume would be present between a publisher and a relay, who is meant principally just to fan this stuff out. It gets even worse if the situation is such that you can't create such a hash table, right? If it's something that the time of day or something else feeds into this, so that they actually have to have the equivalent keying material to p one in r one in order to make this decision. Again, you're really, really changing the relationship between r one and p one, or, and here's where the privacy bit comes in, forcing S3, in this case, to reveal things to R1 that they would not necessarily have revealed to a relay if the authentication were passed through to P1. So I think, as the design team works through this space, I really encourage you to think about the, not just the characteristics of this from the purposes of scaling, and there are very difficult scaling characteristics for this when you have large numbers of subscribers, certainly at the is this person in Denver level, where you're doing it by subscription rather than by geolocation, But also, the privacy characteristics of how it will actually work in the field. Because some of the ways you would get scale with this in a deployment would hurt the privacy of the subscribers quite substantially, because they'd basically have to reveal information to the relay that would otherwise be private. So I encourage you to think carefully about it as you guys go through the rest of the process. Thank you.
[01:10:34] Mike English: Thank you. We've got a decent queue. Jonathan.
[01:10:40] Jonathan Lennox: Jonathan, Linux. I mean, it seems like CDNs for HTTP must already solve this. What do they do?
[01:10:52] Mike English: That's yeah. Basically. Yeah. There's there's Yeah. And I mean, I honestly, I feel like And there's there's hop to hop.
[01:11:01] Jonathan Lennox: I mean, there's at some level, I feel like if, like, somebody you're doing either secure objects or the CMF equivalent thereof, I don't care that much if you get the encrypted data if you can't decrypt it.
[01:11:13] Mike English: Right. And yeah. And this is this is a very good point. Like, I forgot to mention this earlier, but I meant to tie directly to Colin's presentation that like you can assume that the payload itself can be encrypted, and so that's not necessarily a concern. Where it gets more complicated is if you want to key that in such a way as to efficiently fan out that encrypted material, but then restrict access on kind of an individual subscriber basis. That gets a lot more complicated. Ian?
[01:11:51] Ian Swett: Ian Sweat, Google. I am I think maybe partially to echo the past comment, but some of these things you're talking about are certainly interesting, but they seem quite complex. Is is the goal here to be better than HTTP and other comparable technologies, or is it to invent something new? Because this seems like something new, not just, like, we're gonna be a lot more efficient than HTTP. I I mean, in particular, in my experience, usually, I find auth somehow goes back to, like, a p one equivalent at the end of the day on a per playback basis. And maybe you can get by without that, but I think most use cases probably are gonna end up with a design that somehow involves that. So, obviously, you wanna be able to, like, validate that at r three. But are there really a lot of use cases that think they're not gonna have a I mean, there's more to a video playback than actually the video content. Right? Like, for example, like, there's the page or there's the app. There's a thing. Right? There's auth there. Like Mhmm. There's something scaffolding surrounding it. And so I feel like every application I know of, you have to do some auth at that layer, and then it's just a matter of, like, r three needs to know how to validate that it's okay. I don't know. Am I being silly? I'm not sure if I'm asking a useful question or not, but like
[01:13:14] Martin Duke: No.
[01:13:15] Ian Swett: All right. This seems very broad and difficult to solve, it seems interesting, but I wouldn't wanna solve it.
[01:13:20] Mike English: Well, yeah. So I think I think this is this is relatively straightforward. And my preference is that, you know, wherever possible, we do the simple thing. But there are requirements, and maybe Colin can speak more to this.
[01:13:37] Cullen Jennings: I'm in queue. I'm gonna jump just ahead in the queue slightly to to try and answer Ian's question a little bit, the previous one too or whatever, which is a little bit like what's what is different here though a little bit in classic HTTP. And in
[01:13:49] Ted Hardie Hardie: class
[01:13:49] Cullen Jennings: a classic HTTP CDN, when we had r one there, it doesn't ignore multiple relays. Just say there's only one relay. But r one going back to the original publisher, quite often in HTTP, that's authenticated with a TLS domain of the original publisher gives you who it is. And there's and it's often mutual TLS the other direction or some other way to know that that connection was was valid coming into r one. And so you're totally right. There's an application laying on top of this that did all kinds of things. But you end up with this token binding problem of you need to bind some authorization token to this incoming request to know that it's correlated with the session that you've negotiated at your application level. And that is easy to do in the HTTP CDN case. But in the case where the original publisher is a client on the webs somewhere that's not gonna have a domain name or any of these things, I think that I think that in the end, we have to just have some token binding scheme there at some we have to fill something there that that meets that gap. Yeah. And there's many ways to do it, but that's about what we need to grapple with at some level.
[01:14:58] Martin Duke: I think I have to sort of get
[01:15:00] Will Law: it. I
[01:15:04] Rowan Wheeler: you can if you want. Okay. Yeah. Hi, Rowan May. The so I I just wanted to kind of verify, like, what Ted Hardie asked about proof of possession. When I hear proof of possession, I think of a client has a private key, and they prove that they own that that they can they can demonstrate that they possess that private key. Mhmm. And this is not at all what you're doing. Right? Or it is.
[01:15:31] Mike English: I I think that some of the token schemes would do that. Yes.
[01:15:34] Rowan Wheeler: Okay. But they would be proving it for p, not for any real any relay, by definition, would not have position of those keys?
[01:15:44] Mike English: I I think it depends. I think that you could provide public keys to relays so that they could validate the signatures from subscribers, potentially. Like, that's The private keys. The relays would not have the end subscribers' private keys. The relays may have their own private keys. Okay. Right? Like, that's an option is that these up these upstream sessions could be separately hop by hop authenticated that
[01:16:07] Rowan Wheeler: way. Okay. Thanks. And then also, it wasn't clear in slide six, previous slide. Is so this is s two is blocked because the because the subscriber is not associated. You know, the subscriber's location is out of Cal is out of 5th within 50 miles of LA?
[01:16:36] Mike English: Yeah. So
[01:16:37] Rowan Wheeler: So you VPN in and change your VPN settings in the middle. Do you still get to access the content?
[01:16:43] Mike English: It it it depends on the claims that are being validated. But this is this is like an example of a a potential claim that you might have in a C4M token Okay. That is a restriction on, you know, certain geographic regions, and then that's checked against, you know, some other signal that the relay has access to, like IP geolocation or some other some other signal.
[01:17:04] Rowan Wheeler: I just found it. Like, these were some of the questions that ran through my head when I, like, admittedly quickly read through the draft. But I like, I've I had a lot of requirements quest level questions. So thanks.
[01:17:21] Alperen Temel: Hi. So this slide this tricked me off because you said, well, the relay within this radius cannot have this subscriber cannot have authentication. What if the relays are mobile? And I know that there is, the quick gives the underlying, handover, and you also do not have any wall clock time. But what if the relays are mobile? Then would you reauthorize When when you check that it is mobile, then you reauthorize every time or it is session level reauthorization?
[01:17:54] Mike English: If if the relay itself is mobile and may not have access. Sorry. I I missed where where the potential impact would be because the sessions might be ephemeral.
[01:18:12] Alperen Temel: Okay. So you're not going to reauthorize if the relays are moving around?
[01:18:18] Mike English: Yeah. To okay. So to to validate these claims. I think for C4M tokens where that's been discussed, the discussion so far has indicated that there may be like revalidation that occurs throughout the track. Like it may only the token may only be valid for some period of time and then the client is responsible for reauthenticating before that expires so that they can continue to access the track.
[01:18:49] Alperen Temel: Okay. So because see, it's confusing because the MoQ draft says that it is the relay's responsibility to do that, but you're saying it's a subscriber responsibility to keep track of reauthorizing. Right?
[01:19:02] Mike English: In in that scenario, it would be the subscriber's responsibility to reauthorize. The application would know what the timeout would be. Okay. Thanks. Okay. Okay. So these are kind of the the different topologies permutations that we've discussed so far. This is kind of what I think the protocol implications are. So again, as we have things written today, auth token is a hop by hop thing. Whether it's a setup option or whether it's a message parameter, that is hop by hop. Only properties are currently end to end. So if the original publisher does need to directly validate the end subscribers, it implies that there's some requirements here that we don't currently support and we need to devise some method of figuring out what the right rules are for forwarding things upstream in that way. Whether that can be done at some higher layer, like a streaming format that says, okay, you have to do this, I don't I don't know. I don't think that we can get through the relay. So we may have some transport requirements if we need the relays to reliably forward things upstream. Oh, we've got a queue.
[01:20:29] Cullen Jennings: Mike, I I I I just wanna provide a slightly different alter view on that, which is the reason we allow multiple auth tokens in the same message is because they were meant to be forwarded on to other things. That was the design property from the very beginning. So we have many other things that even though they are negotiated hop by hop, they are forwarded on. So, I mean, I I think that this is just all part of the design that was never nailed down.
[01:20:54] Mike English: Okay. Yes. I think that there may be a different interpretation of that.
[01:20:59] Cullen Jennings: So Totally. Totally. Totally buy that.
[01:21:00] Mike English: Yeah. That there my interpretation is that we want multiple tokens because the same client may want to present that bundle of tokens to different entities that it is directly communicating with. Right? So, like Yeah.
[01:21:14] Ian Swett: But I mean, I
[01:21:14] Mike English: connections only communicating with a single relay. So here, if for s s one may reach r two or depending on current load and, you know, whatever traffic shaping is happening, the CMS may direct them to r three because that's the cheaper CDN today. Right? And they want to be able to just present a token to, you know, whatever CDN they end up landing on and it should be interpretable by either of them. I don't think that's the same thing as this model where you're presenting multiple tokens that you haven't in in the draft, I don't think
[01:21:54] Martin Duke: I I agree.
[01:21:55] Cullen Jennings: This this is we need to figure all of this out is the only important point. Yeah. Yeah. But I don't think this was a design decision that was really made.
[01:22:01] Mike English: That was made. Yeah. Okay. As as written, I don't think that the spec supports that forwarding.
[01:22:12] Alan Frindell Frindell: Alan Frindell from Dell. The other thing that's end to end are tracks. And I wonder if there's a design where if the original publisher is really looking for information from and subscribers that it could use subscribe tracks in some clever way for the that to happen. I don't know if that's better or worse. I haven't thought about the properties. So throw that in the bucket when you think about other things. Okay. That's one thing. To the to the discussion that was happening, this idea we we have definitely gone through this, like, what you know, the auth is terminated at the first relay because it's hop by hop and you may be aggregating is absolutely something that I mean, I figured it out when I implemented my first relay. It was, like, three and a half years ago. I'm like, oh, look. We're this like, only the first guy gets his auth checked. And, like, well, what if like, that doesn't make any sense. And how does this work? I mean, if we need to talk about it now, we can, but I don't think it was like we put a pin in this. I I had really thought that we all agreed that that was how it was going to work, and I'm a little bit wary about adding lots more complexity. But I'll wait till you guys come with, like, a little bit more concrete proposals before I weigh in. But yeah. Alright. I guess that's all I'll say for now.
[01:23:34] Suhas Nandakumar: So, Suhas, it's it's nice that we are finally talking about auth, which has been pushed for a while. And hence, today's implementations are trying they're taking a simple demo kind of application and or terminating the auto to one relay. But real deployment does not fit in that model many times. And in in particular use cases, even when we run Webex, we leverage multiple CDNs. And in that case, the CDNs are also we do not a client would not talk to both the CDNs. It's the CDN to CDN policy that makes them talk. And in that case, your audience in the doc claim basically says, the first hop that, you know, if you're talking to CDN b, this is the token you should give to the other CDN. So what client does is that all it knows is that I have these two tokens. I need to hug you to my first hop, and that take care takes care of giving to other hops. And because the the entire CDN network would not be visible for a client as such other than providing the tokens provided by the issuer to pass it on. Again, this multiple token tokens is is kind of common practice in in many places. And also, it can be used, as you said, as a client can provide to two different relays. At the same time, it has also has the implication that, you know, based on audience, it can be passed on. It's not an end to end as such. It's like one CDN to another CDN. Or in some cases, it can be entered into the original publisher as well. My my point is that we are we are finally talking about these things. Let's kind of spend more time and figure out what we need to do.
[01:25:00] Mike English: Thanks. Chris?
[01:25:04] Chris Lemons: Yeah. Chris Lemons. So so you say the original publisher needs to validate in subscribers implies a requirement to relay off. So, typically, in in in to be clear, my way of thinking, which is not the only way of thinking about these things, the original publisher validates the insubscriber and then hands it a bearer token because the publisher trusts the relay to faithfully relay the the content. And if it doesn't, then it should be using a secure object and maybe even not then. But the the the relay is authorized to relay the content, and the way it knows to whom it may relay is because those people present a bearer token that was authorized by the publisher. Now I think there was a very good observation in that we're gonna need some sort of a token binding in order to identify publishers that don't come with publicly trusted TLS certificates. I think that's an excellent observation. We're gonna almost certainly need that. But that doesn't necessarily mean a requirement to relay authentication. Now I can't speak for every possible kind of token though because there are a couple of different tokens that are suitable for different purposes. I have opinions about the additional slides or elements on the page, but we'll wait until we get there.
[01:26:31] Alan Frindell Frindell: I remember one other thing I wanted to say because you mentioned off alias here, and I think that's probably not what Not what we That should only be used to compress tokens on a single hop. That's all it's designed for. Okay. And I don't think you can use that for anything here unless I'm misunderstanding something grossly.
[01:26:50] Mike English: Yeah. So context here is is not as a end to end reinterpretation of auth alias. It's so in the context where so for example here, yes, or here. So if we are going to sample some subset of these clients and we need a way to go upstream and we say that there's a new, there's sorry, I said it was not about like a new interpretation and now I'm describing. The way it would be used is still hop by hop. So it would be hop by hop between r one and p one. Because you have the subscribe already running. So if you need to do like authentication of additional tokens that you're somehow going to bind to, like, this shared aggregated track that is already authorized some other way. Right? You need some way to, like, out of band, you know, authenticate additional subscribers. Right?
[01:27:58] Cullen Jennings: I
[01:27:58] Alan Frindell Frindell: I understand what you're saying, but I don't think you want to use anything to do with our our token compression scheme at all to do that. I think you might you might want a message which is like, hey, s two showed up and this is their credential. Do I let them in or not? Like, that's a message that you might wanna send. If that's what you wanna do, that's okay. You don't wanna And that could be if we keep compression, you can compress that token, although you'll probably never reuse it there, so I don't really understand why.
[01:28:21] Mike English: Okay. So you're just gonna accumulate state in your token cache and that's no good. Yeah. That's fair. I think that the reason that we wanted to reach for it is because it was like separate, like in an identifier that you can just attach to subscriptions and keep that separate from, an ongoing subscription. So, yeah, so there is, you know, because of aggregation, if we do need to do some kind of additional authentication that is threaded through, you know, the relay boundary, then you need some way to like do that in parallel to the aggregated subscription or whatever the aggregated action is. And we do need some way to spell request challenge response things. I think that's a spelling issue. That part's relatively straightforward. It's more about these topologies where you might need end to end properties that is raising the biggest question right now. And we're looking for a kind of a generic pattern that's usable across all token types. We think that the request challenge response pattern is fairly flexible and should be reusable. Potential ordering issues. So in draft-eighteen, we have moved all our control messages onto their own streams which means that we're not guaranteed ordering. So if we're going to do authentication and separately have, you know, MoQ actions, you know, other control messages that are referencing that state, now we have, you know, ordering issues that we need to resolve that we didn't have before. I think those are all solvable. You know, we can define, you know, how things need to block and what kind of timeouts they should use, etcetera. But I did wanna call that out that when we had the monolithic control stream, part of it was simpler. Okay. So here's an example of, you know, spelling for the challenge response. You'd have some subscribe to a track with an authorization token that would have some token type. And if it's, you know, null, it doesn't have what it needs to do the proof of possession yet because it hasn't received the challenge to respond to, then whatever the upstream entity is would provide an auth challenge back, and then you would respond with some kind of auth response. And if that's valid, then you would get, you know, a subscribe okay, for example. Spelling questions are, you know, do we want this to be a new auth challenge message that can be elicited by a subscribe? Do we want to have
[01:31:23] Mo Zanaty: a
[01:31:23] Mike English: separate auth message instead of doing the subscribe, and then we reference that in the subscribe? Those are yeah. I think that's that's kinda what we're looking at here.
[01:31:38] Mo Zanaty: Mo Zanaty, do you expect these new messages to be in the subscribe bidirectional or on their own new streams?
[01:31:46] Mike English: That's one of the questions that I'm asking. It's like so if we if we instead say that we have, like, new auth message and you just say like auth, and that's that's the thing that carries this initial authorization token, and then you get back a challenge and response, and then you have some kind of identifier that you can then use in subscribe, that's one way of doing it. And then that happens on a separate stream, and then the subscribe stream, you know, can reference it. Another way of doing it is to keep closer to what we have right now, which is subscribe, which has an authorization token parameter. And then you get back either a specific type of request error, that is a a challenge, but then you can then send another message, this response, which gets, you know that that's a lot of back and forth on the subscribe. So I don't know if we wanna do that.
[01:32:39] Alan Frindell Frindell: Alan Frindell from Dell. I dropped this in the chat, but it seems like you could also do it as a parameter. Like, you send the subscribe okay in step two with the challenge in it, and then the subscriber sends a request update with the auth response, and then the last one's a request okay. It's just another spelling of the same thing. But that assumes that you all wanna do it on the same stream. I can't think what are the advantages of not doing it on the control stream?
[01:33:04] Mike English: So this. The fact is that a lot of applications, you're going to be subscribing to multiple tracks. And do you want to do that whole challenge response exchange on each message? We also still have authorization token as a setup option. So some of this could happen on a session wide basis, but depending on the application, you might need more granularity than that. And if we spell this in such a way that it's necessarily attached to each subscribe, then there's just a lot of back and forth that we have to do.
[01:33:39] Alan Frindell Frindell: Okay. Yeah. That makes sense. The request update trick does not apply to setup, but I see what you're doing. Okay.
[01:33:52] Chris Lemons: Chris? Yes. So so if you go back a slide, I think I'm observing that probably not by accident, this is shaped almost precisely the way DPoP nonce challenges are shaped. And so when we are looking at how we spell DPoP on the wire for cat that this this makes complete sense. Whether we spell it as an off challenge or as a, you know, as a setup okay or whatever whatever we do on that one, you provide a nonce and say, hey. Your authorization you know, your your proof of possession isn't good enough. Please come back with this signed properly. And looking to the the DPoP specification for exactly how that works and making sure that we have analogs, I think will help people get their brains around it. Cool. Thank you.
[01:34:52] Suhas Nandakumar: So how's Cisco? Plus one to what Chris said. Also, I like this design where we we we fall we started this design with namespace where you do subscribe namespace and subscribe namespace. By the time it ends, you can have multiple namespaces that comes, which is like a push of the namespaces that is coming in. This kind of falls out more or less. What it will support is that within a subscribed context between a request and an error or a request and an okay, you have all the odd happening between that one. And it also provides a model where in privacy pass where if you want to reevaluate your auth, a server can basically say, provide the new challenge. And those kind of things can be easily fit on this model. So this kind of we we approve this design works in subscribed namespace, and bringing something like this here makes total sense. Thanks.
[01:35:49] Mike English: So these are my proposals. This is like my take on trying to summarize what the working group or the design team has discussed so far. So if I'm misstating things, hopefully the other team members will forgive me. First question is, should we add a challenge response message? I think yes, it's just a question of exactly how to spell it. We got some good ideas on that and then the input is helpful. If people have more thoughts, I think there's already an open issue. I should have included the issue number here. But it's referenced on an earlier slide. Should we add a way for relays to statistically validate upstream tokens for aggregation? Maybe, like this is awfully complex as many others have noted. But what I've heard is that there's a requirement for that end to end validation. So I think that is gonna require further exploration. Should we specify types of scopes that need to be supported? I think that, as I'm interpreting this from notes, I think that this was talking about multi CDN sharing and being able to say in privacy pass and in cat, both those drafts should have some kind of field for claims that are like a scope ID, and that scope ID should be for a particular provider. So, like, if you have a C4M token that says scope IDs, and then it's like, you know, Cloudflare scope ID, you know, 57, you know, vastly Akamai scope IDs, whatever other numbers. They're gonna be unique to the provider. And it would be great if you could just put those all in the token. And should we specify authorization on data plane and control plane? Yes. I think Colin wrote that one. Maybe you can remind me exactly what Yeah. Don't know that is. That's my question.
[01:37:56] Magnus Westerlund: What do you mean?
[01:37:57] Cullen Jennings: What does that mean? Okay. So let's say we I I think the point I was trying to make here is if we have something the question came up earlier by Rowan of your IP address you you know, your your your said that your your IP has to be within GeoLOC to 50 miles of Victoria or whatever it was. Mhmm. And, you know, your IP changes to something that changes that value. How often do we do it? So we're authorizing the data objects here, I think that that's we need to come down. And so I think, unfortunately, to meet any of the video distribution requirements or to make the C4M token useful, what you're authenticating is not the subs well, you're not authenticating anything. What you're authorizing with this authorization token Mhmm. Is actually the delivery of the data, not that the subscribe got a subscribe okay. So if whatever caused that if the if if whatever properties were checked to decide that the data that this object was okay. If that changes on the next object, like it timed out, like the the token has now expired at that point in time, you have to you have to check that again. And so effectively, problem is is we are authorizing the data objects to be delivered here, and that's what people need to under you know, that that's what we're really getting at with with this point here, which I think is a surprise to many people. Right? They're like, oh, oh my god. That's a huge performance question. Yes. It is. But when you go and look at what do you think this C4M token means, I think you quickly come to the conclusion or you start looking at the requirements. You realize, oh, no. I do need to you know, I can't have a subscribe run for ten years on a token that was valid for five minutes. That makes no sense. So that's really what this is about. Chris?
[01:39:44] Alan Frindell Frindell: I I I just maybe I would only just maybe change with the that makes sense. The question here is not exactly like, do we need to have a way to say how often do things need to be revalidated? Yes. Like, very much.
[01:39:56] Mike English: That's it. Thank you.
[01:39:58] Chris Lemons: Hi, Chris. Briefly, question three, you were discussing scopes. The things you described were envisioned originally as audiences. I don't know that that's how people in here think
[01:40:12] Mike English: about them, but we should contemplate. Okay. Audiences. Sounds good. That's it. Thank you, everybody.
[01:40:23] Martin Duke: Thanks. That's a good start, Mike.
[01:40:28] Magnus Westerlund: Or is it Ian or both?
[01:40:31] Martin Duke: Which editor is gonna talk today?
[01:40:35] Alan Frindell Frindell: I don't even remember what I put in here. How many minutes I have? Twenty? Okay. Let's rock and roll. Okay. Blocked issues. In case you did not know this, it's been discussed before, but, like, when we look at an issue and we're like, we have a question and we need it answered in order to make progress on it, we mark it with this blocked tag, and we assign it to you, and we at mention you. Please provide and then so there's five issues that are stuck against three different people looking for your input. So your choice is you go to the issue, and you answer the question, remove the tag, or you close the issue, and we move on. So please take note and do that. Okay. Management consider considerations. So MoQ t definitely has management considerations, and we should write them down. And there are two related issues that got filed. One is about how should clients get diagnostic data from relays, and another one is about creating well defined metrics that people might wanna use for management. And my question for this group is where do we wanna write them down or how and who? So do we wanna try to address that in this document, or do we wanna have a separate applicability manageability document as some other groups have done for other work? In either case, we would need other volunteers, I think, to drive this work because the MoQ t authors and editors, as aforementioned, are already at maximum capacity. So it's, like, people who are passionate about the manageability and applicability, please stand up. Suhas, you are an author on too many drafts. Sit back down.
[01:42:15] Mike English: Oh, I
[01:42:16] Suhas Nandakumar: I clarification. It's a clarification question. When you say metrics, are are you talking something other than MLOG or something like MLOG? You'll have to
[01:42:24] Alan Frindell Frindell: ask the issue filer. Okay. I mean, I I assumed it was like, if you wanna if if you were in right manageability current considerations from OCTE, you might say something like, here are the things that you might wanna monitor to find out if you're being DOSed or something. Like, these are the these are important metrics to look at. I'm not sure.
[01:42:45] Ian Swett: I said it in a somewhat more oblique way on the issue, but this is a great candidate for an extension because, I mean, sometimes you own your whole system basically, and, like, you wanna manage it the way you want, and you have no interest whatsoever in a standard. Like When you
[01:43:00] Alan Frindell Frindell: say extension, do you mean a separate document?
[01:43:02] Cullen Jennings: Or do
[01:43:03] Ian Swett: you mean Yes. Absolutely. Like, definitely a separate document. Or maybe there's, like, data you need for one application and not for the other thing. I don't know.
[01:43:10] Alan Frindell Frindell: You mean for metrics and specific metrics specific? Yeah.
[01:43:12] Ian Swett: Yeah. Yeah. Okay. Like, it's important. I mean, but, like, put as little as possible in MOQT.
[01:43:18] Martin Duke: In the chat, is volunteering to coauthor the draft for diagnostic data from the relay.
[01:43:23] Alan Frindell Frindell: So who is?
[01:43:23] Martin Duke: Alperen Temel. Okay.
[01:43:27] Alan Frindell Frindell: I mean, I not a lot of people have weighed on this topic, but, like, is it okay I mean, and this is this came up briefly in the agenda bash, but is it okay? Can we start with much like we did with DOS, can we create a repo for this is the shell of applicability, manageability concerns, and we will iterate on it there. We will fight issues on it there. The volunteers will all muster and track their work there. And if the powers that be say that has to be or some subset of that has to be in MoQ transport, we will merge it in when that happens. But I would like to kinda clear this out of my deck, if that's okay. If you does anyone object to that course of action? No. Okay. Fantastic. We will do that. And if you and please, if you're
[01:44:08] Martin Duke: So, Alperen, you're volunteering a coauthor. Are you are you willing to start the zero zero in the repo?
[01:44:18] Alperen Temel: Sure. Yeah. I can do that. But I don't understand the entire process that was described. Where am I supposed to start? I I can start a draft, but
[01:44:26] Alan Frindell Frindell: We can coordinate offline. We'll we'll help you get started.
[01:44:29] Alperen Temel: Okay. Thanks.
[01:44:31] Alan Frindell Frindell: Okay. Fantastic. We've got some time. Let's let's talk about timeouts a little bit. Okay. So there's there's several different issues that talk about timeouts. And I think and and I've seen the same. I think this the quote here is representative of of of of a view, which is that, like, anytime something times out, the client really needs to know that a timeout happened and or either because there was, like, an error that said this thing timed out or because it knew what the timeout was, and it could check look at its watch and be like, oh, yeah. The relay said it was gonna be sixty seconds. And lo and behold, the stream closed, it's been sixty seconds. I guess I'm trying to understand, like, is it is this a principle we should be working for working around? And is is the solution space around that that we just need to make sure that every operation that can possibly terminate in a timeout? And here, I'm thinking of, like, things like delivery timeout are explicitly note negotiated, but there's so many other things. And there's another slide that you'll see where implementations are gonna have timeouts, and they may even be changing based on load. And, suddenly yeah. You normally, my idle timeout is sixty seconds, but right now, I'm under load, I'm gonna close your connection after five. But do do we need to have negotiation? I don't know. Maybe I'm asking too vague a question here. Martin Duke's gonna rescue me.
[01:45:58] Martin Duke: Yeah. Well, first of all, not client. I think you mean subscriber.
[01:46:03] Alan Frindell Frindell: Yeah. Maybe.
[01:46:05] Magnus Westerlund: Okay.
[01:46:07] Mike English: So,
[01:46:09] Martin Duke: I mean, aren't these all way I mean, don't don't timeouts either result in a reset or in the case of fetch, like a missing object marker?
[01:46:21] Alan Frindell Frindell: Is this slide helpful?
[01:46:23] Martin Duke: God.
[01:46:23] Alan Frindell Frindell: This was a list of things I thought about that you might time out for when you're dealing with MoQ. You might be timing
[01:46:28] Mike English: out with
[01:46:28] Martin Duke: I I'm not gonna give that real time. Alright. Thanks.
[01:46:30] Alan Frindell Frindell: Like, you might be timed out waiting for a setup message, for a control message after a stream opened, for, the end of a message after you saw the start of the message. I mean, there's a million different things, and I was trying to understand, like, okay. Some of these have predictable outcomes. Some of them do not. But I think the the higher level question is, like, some of these things, for example, might result in just me unsubscribing from you because you didn't provide something to me in in a timely way. And the other side may not never know that that's why because the other side might never know what my timeout was that I was waiting for. And is that something that we need to have explicit signaling around? Do we need to have 14 different timeouts that you advertise it set up so that the peer knows exactly what your internal timeouts are, or are there is there a little bit of, yeah, sometimes things happen is okay? Colin.
[01:47:24] Cullen Jennings: So, I mean, I I think this is just a a special case of the generalized error problem that we have, which is like, why did an error happen, and what should I do to recover from it? And timeouts are a very special case of that. Right? And we've seen other protocols like, DAV is very difficult to do high quality clients against random servers because it doesn't specify enough of this stuff. Right? And that's an HTTP example. And it's got a lot of problems. And I don't want I mean, I've worked a lot with that. And I don't want us to end up in that same case that we are there. And so the model would just do it like HTTP doesn't actually really work as soon as HTTP gets complicated even. So I think we need good errors. We need to understand these timeouts. Now on the question of each one of these, like, do we need to negotiate them or do we need to specify them? I don't really know. But like all of these seem great examples of you should be able to understand which one of those things happened and what you should do about it. I think should be the the underlying principle. Right? And and you're right. Some of the ones that you you can't negotiate things and set up that you're going to dynamically change on the fly. Right? I I agree with that. But you do need to understand that why something didn't happen and whether you should just try again or whether that would be the worst thing possible for the server right now if everybody tried again. Right? Those are you know, that and just throwing it out there as it broke, give up, is like, that's that doesn't really work for the type of applications we're trying to build here. Right?
[01:48:52] Alan Frindell Frindell: I mean, I hear a lot about what you say, but I also think that just this exercise of putting this slide together Yeah. And I'm sure it's not exhaustive. Right? And I'm I'm trying to think of, like, how am I gonna like, I don't wanna keep having this discussion every time somebody says, well, what about so I wanted to get, like, what is our principle that we can use to be very clear? I
[01:49:12] Cullen Jennings: I think we should go through the whole draft and everywhere an error can happen, including a timeout, we should figure out how the client knows what happened. Or in in some case, it might be a security thing. It might be like, no. The client should not know what happened. Like but the like, we should think about it logically and be able to do that. Right? And we should be able to communicate what that is. Right? Okay. Right now, we have way too many errors that all map to the same thing to understand.
[01:49:34] Alan Frindell Frindell: I mean okay. So there's a separate that's a separate that that we have too many errors that are all protocol violation with sort
[01:49:39] Martin Duke: of a place the same thing.
[01:49:41] Alan Frindell Frindell: Yeah. This is different. This is more about I'm trying to understand, like, that there's some operations for which, like, the result doesn't even have a way to say it. Like I said, like, unsubscribe. There's no I never tell you why I'm unsubscribing. I'm just unsubscribing from you. I don't want it anymore, but that could be because you didn't send me anything in the time that I expected you to.
[01:49:59] Cullen Jennings: But that's very important. Is it you unsubscribe because I just never did anything, you unsubscribe because you're overloaded? Those are two very different situations that I, a client, need to react to differently. And so I need to know that information. It's not just, sure. Whatever.
[01:50:13] Alan Frindell Frindell: So in fact, unsubscribe is not even a message. It is a quick reset stream, which carries no
[01:50:18] Cullen Jennings: I have said, when we move to reset stream, we're starting to lose information granularity of explaining what the error was and that that was one of the issues I raised with. So look. I I I guess I don't I mean, whatever. Yes. I think we should have all these separate, but I don't think these are really I I'm not seeing these as too much different than the other error cases is what I'm saying.
[01:50:38] Alan Frindell Frindell: Okay. I guess let me ask you, like, how well, let me let other people talk. Ted Hardie.
[01:50:43] Ted Hardie Hardie: Ted Hardie Hardy. You asked for a principle. And I think the base principle, which kind of falls out of what Colin was saying and you were responding, is you need to know which layer will take action, right? So just like you had the dot session thing to indicate that this never gets passed up to the application, this is entirely within the mechanics of MoQ T itself, you need to know which layer has to take the action in response to an error, and in particular, to a timeout error. So the first thing I would do is classify these things to say, how many of these are actually things that the application needs to know about, and therefore, the base action that the lower layer needs to do is to pass it to the application that this has happened? How many of them are taking place lower than MoQ T because their quick level shit happened, like a knack? And how many of these are at the MoQ layer, where it's all going to be done within MoQ T itself, and never passed up to the application before MoQ T has resolved it. And I think if you do that exercise of kind of, here are my buckets of things, you'll then kind of rapidly figure out whether it's tractable to tell the application what to do about it or not. Because there are going to be whole classes of things where you just tell the application what happened, and the application figures out whether it's going to do anything or something, and what that something is based on what type of application it is. But I think that, as a principle, might be a way that you start tackling this problem to get yourself at least past the point of where it's an undifferentiated mass of things, and we don't know what to do.
[01:52:20] Colin Perkins: Thanks. Hi. Colin Perkins. I basically agree with everything Ted Hardie just said. Explicit is good. You should not only know who has to take the next action, but what are the sets of possible next actions that should be that could be taken. And I think we need to specify that for everything in the protocol. The the less the less that is left undefined, the better.
[01:52:50] Alan Frindell Frindell: Okay. Thank you.
[01:52:57] Ian Swett: Ian Swett. I think everything they said was good. I think there's two different things, which is knowing that a timeout occurred versus, like, the I think something you originally asked, which is, like, do we need to communicate all the timeouts on the wire? And I would say, absolutely not. The only timeouts we should communicate on the wire are those for which not communicating them could cause an obvious disruption in application performance. Like like, I will unexpectedly kill your subscription because you didn't do a request update. So, like, as much Expires is another one. Yeah. Like, basically, like, you know, anything where, like, the application will not perform well from a user visible perspective. If you do not communicate it, then we gotta have it something explicitly communicated because otherwise, like, we're gonna be sad. Otherwise, don't. Like, less is more.
[01:53:50] Alan Frindell Frindell: Okay. Yeah. I mean, I think one specific example on here, is seventeen twenty, which talks about fill time out, which is the text currently says is like, well, the client says, like, well, my fill time out is a day. I'm willing to wait a day for you to fill these things. And they realize, yeah. That's so cute. Like, not gonna keep your subscription open that long waiting for things. And so it's going to reduce it, and then the subscriber doesn't like, I think that's the point here. It's like, well, how does the subscriber know that that happened? Or again, it could be dynamic. And so maybe the answer there, rather than trying to put all the timeouts in setup and try to broadcast everything, because we will inevitably miss something, is to try to make sure that it's clear, like, you get a different status in the fetch response, for example, when it's unknown because of time out or it's unknown because of something else. Maybe that's gonna satisfy and like seem like fit more in the principle. Just go ahead, Colin. I I mean, I think for
[01:54:47] Cullen Jennings: that type of design, I would have preferred more that when the initial request came up, it got an error right away that said, this number is too large for me. And that error included, here's my limit here's my current limit for you on what that number would be if you wanted to try again. Right? Like, that would allow you to do good clients and and good design. Not, I start to get some objects and then suddenly I get a timeout error. Right?
[01:55:15] Alan Frindell Frindell: I do hear what you're saying, but I I where it's not really extensible it it it's going to become intractable rapidly as we, like, think about every possible case that somebody may have asked for something that was unacceptable. I'm much if if if that needs to happen, I prefer the I will broadcast my limits and set up, and then you will know, like, what the limits were.
[01:55:35] Cullen Jennings: But I mean, I'd like like look. All of these types of designs we're just talking about, you know, like, hit my my solve my problem of, like, the client knows what happened and why or whatever. Right? And I I I agreed with what Ian said too. So but I just think we need to go through these. I don't there's a bunch. There's as I agree with you, there's probably more than you identified on your slide. But I don't think there's hundreds. I I think there's, you know, innumerable number we need to go through. And we've always identified this as one of the big chunks of work we needed to go do on the draft was errors. Like, my last review of it certainly didn't cover errors. Have a
[01:56:06] Alan Frindell Frindell: lot confidence. Yeah. There's our I mean, unfortunately, the PR has gone stale already. But to us to take a whack at, like Yeah. Redoing the granulated error codes, we definitely need to do that. We just need to the time when the draft's a little bit more quiescent so that we can get it done. Yep. I am gonna roll and while we're here, I do wanna get some on this question. So the current text and security section basically says, like, you should use timeouts because if you don't use timeouts, you might have problems with, like, people trying to send you stuff and not sending you that in a reasonable time, and you set your own timeouts. And there's you know? But how much, like, how much guidance do we give? Are we trying to enumerate all the scenarios? I think Colin just said yes. Try to enumerate them all. I I do worry that if we try to do that and we miss some, people will be lulled into a false sense of they don't need to think about anything we didn't think about for them rather than giving them a class of problems to think about. And the other question is, like, do we want the document to say specific recommended numbers or ranges for particular values of these timeouts? And I am inclined to say no. Maybe orders of magnitude at at at most, but, like, giving recommending specific values doesn't seem right to me. Does anybody wanna jump in?
[01:57:19] Mo Zanaty: Mo Zanaty? Mo Zanaty's an idiot. I I think it's less important to specify the small numbers all over the spec. I think what's more important is to identify the cases where it's unbounded, the cases where the time is unbounded and the implementation can't really set a useful timer because this really is unbounded. So it's your own application decision of what the time bound should be. I think those are the cases that need to be identified because because those are the ones where the application really has to make a decision about, okay. This is gonna be a long operation. It could be unbounded. I need to decide my own time out. That's what I think is more important.
[01:57:53] Alan Frindell Frindell: Alright. Thanks.
[01:57:55] Martin Duke: I think we've Martin Duke, Google. I think we've and as an individual, obviously, I think we have very very unique specific requirements around object delivery that are captured by delivery timeout and fill timeout, and delivery timeout is in fact negotiated today. I don't know if fill timeout is, but it could be quite easily. I don't do we have a huge problem with this in HTTP? Where I mean, they're they're they're hanging gets there, you know, you have you have you have half a request and there's just do we have to reinvent the wheel here, or can we just survive with just, like, the the publisher just erroring out when the it's a stupid delay?
[01:58:36] Alan Frindell Frindell: I I mean, I'm inclined for less is more, and, like, that I think resonates a bit with Mo Zanaty, which is what Mo Zanaty's statement was, which is, like, find the places where it's really like, instead of what we have here, which is a little bit like, yeah. Go find the timeouts in here and figure pick the important ones. And instead, we can say, like, these are some that are likely to be big resource problems for you if you don't put some sort of reasonable bound on it. Like, think about it in advance. But I don't know. I think the HTTP ecosystem, like, works. Sometimes things sign out. People debug it. That's why
[01:59:04] Martin Duke: we have jobs. So it's our employment program? Yeah. I mean, I like mean, this does not seem like a a unique MoQ. Like, these generic request timeouts do not seem like something that's unique to MoQ. The delivery and fill timeouts are unique to the MoQ use case. And so I I would I'm just really reluctant to take on these these problems that seem to exist where people seem to be fine with them in other contexts.
[01:59:33] Suhas Nandakumar: Okay.
[01:59:36] Cullen Jennings: I I just wanna give an example of one that was didn't go well where we went that approach. And that is the how long a NAT waits before it times out your connection. That went very, very poorly for us by, right? So this what's different in HTTP here is we this is a a magnification fan out type intermediary designed in by default type protocol, it might have some things that are a little bit different than than HTTP, which is basically client server.
[02:00:06] Alan Frindell Frindell: Okay. I think the I think the lesson there, which is valuable, is, like, that there may be specific ones we need to say more about and rather than so
[02:00:17] Cullen Jennings: 100% agree.
[02:00:18] Mo Zanaty: Okay. One more aspect is we should specify what is different for a relay versus a same subscriber or original publisher because I think there's plenty of cases where relays may need to have a lot more, you know, resilience and they're serving a million people. They're not gonna time out things, you know, quickly.
[02:00:39] Alan Frindell Frindell: Yeah. Okay. I think that's all we're gonna have time for today. But thank you for all all for your time.
[02:00:45] Martin Duke: Alright. That concludes the session. Thanks to all the presenters. Good job staying on time, and we will see you on Thursday.
[02:00:57] Magnus Westerlund: Okay. Now time will work. I I sent submitted that we had this issue. Alright.
[02:01:04] Martin Duke: I think I'm good on let me give you this charger back before I forget.
[02:01:13] Cullen Jennings: Yeah.
[02:01:17] Zaheduzzaman Sarker: Not the
Session Date/Time: 23 Jul 2026 14:30
[00:00:10] Chairperson: Okay. It's 04:30. Welcome to this exclusive by invitation only session of m o q. We apparently drove everyone away on on Monday. This session, as always, is being recorded. This is the ITF Notewell. It's Thursday. You've all seen it. This covers the implications of you being here, both in terms of what we expect for you in terms of conduct and legal and IP concerns. Read it if you haven't read it. By now, you all figured out how to use MeetEcho. But if you are here in the room, please scan the QR code on any of the mic stands or in the back of the room to register your your presence here at the meeting. If you have the full client on your laptop, make sure it is muted. If you are operating remotely and have any plans at all to speak at the mic, please use a headset if you can to avoid echo cancellation problems. Once again, it is possible to watch mock over mock. Here's the URL. Magnus is gonna put it in the Zulip chat in just a moment. And you will have to continue to use the MeetEco Lite client to do all the queue stuff, etcetera, and participate in the chat, but you can watch the actual video over mock, which is pretty cool. Thanks to our friends at MeetEco who are mock enthusiasts for allowing this to happen. Of course, if we can watch mock over mock, aren't aren't we done? Can't we just ship it? Alan says yes.
[00:01:54] Ian Swett: Oh, yeah. We're not done. People can watch
[00:01:57] Chairperson: video over the Internet now, so I guess we're done. This is the agenda for today. It is much shorter because we this is one of the focuses today is going to be to burn down some of the ever increasing MOQT issue stack. And we're also gonna talk about some other they're they're transport related. They're currently sitting as extension drafts. Doesn't mean they'll forever be extension drafts, but they're certainly in the transport, and so we wanna talk about those issues. Would anyone like to bash this agenda or tomorrow's, which is unchanged from Monday?
[00:02:41] Ian Swett: Okay.
[00:02:43] Will Law: That's the end of the presentation. So I have to go hand it to Will. Thank you. Let me just get a audio check. Is everything can you
[00:02:55] Magnus Westerlund: hear me? Yes. We can hear you well.
[00:02:58] Will Law: Okay. Great. Thank you very much. Good afternoon, everyone. I wish I was there, but I am here as we said. I'm going to present the section on Will Law from Akamai presenting the section on sender-side track switching. Next slide, please.
[00:03:14] Chairperson: You have slide control.
[00:03:16] Will Law: Oh, I do. Nice. Let me find it. Here I go. So just a reminder for those who've been following along, this is not new. We began it in February with a design team get together. We've had two implementations built, one by Cisco, one by Nokia. And at London, we we presented it and received a bunch of feedback. That feedback has been incorporated in the design. So I'm gonna go review what's been incorporated and present it for you today. You might wonder what happened to DTS. Well, we renamed it. Right? So SSTS stands for sender-side track switching. We felt this was a better name and descriptor of what the functionality is. It it can bring you server side ABR if you want to give it a media vernacular, but we try to keep it payload agnostic, so it's basically switching tracks on the sender or the publisher's side. The largest change we've made is to accommodate different algorithms for switching. So as soon as we posted the one algorithm, everyone came up and said, you know what? If we involve a client buffer levels or RTT or some measure of the history or a new exponentially weighted average scheme that they have, we would get a better result. And and everyone's right about this. And the point is there's many, many features that you might wanna add in the future, and if we bake all of these permutations into an RFC, it's going to be huge and I believe brittle. And it's not gonna be very extensible because someone will invent a new way of doing it that's better. So we decided to separate the design into a a base component which other algorithms can then extend. So we've taken our switching set assignment parameter, which is how you add a subscription to a switching set. It now has only two required fields. The switching set ID, which is the switching set you wanna put in, and then an algorithm identifier. And this allows us to support multiple algorithms, improved algorithms from the ones we have today or ones we can't even imagine today but want to implement in the future. And each of those algorithms can then define additional fields for the switching set assignment parameter. And to accommodate this field difference, we've added a new setup option called SSTS algorithms. So the server, during setup can can list the SSTS algorithms that it supports, and the client will then have knowledge of those algorithms and know that it can use it. And if the relay does not want to support SSTS, it can return an empty list that is perfectly valid. So you can turn it off if you want to. And we have an IANA registry where you can register these new algorithms. And what we've done is define algorithm zero. So we make the the core MOQT spec defines this baseline structure, and then it also defines algorithm zero, which is an an intentionally simple implementation. And it doesn't mean that it doesn't work well. I we have two implementations that show it working, but it can certainly be changed to improve on the conditions in the future. But we're going to come out the door with a working implementation. Alan, are you in queue for clarification?
[00:06:44] Alan Frindell: It is a clarifying question. Are you Go ahead. Intending that there can be multiple switching sets in the same session using different algorithms? Yes. Okay.
[00:06:57] Will Law: Then I see no reason not to support that. We might have one that is biased for extreme low latency switching. We might have another that's biased for six second switching and takes into account client buffers that don't really exist in a real time environment.
[00:07:12] Rowan May: So
[00:07:12] Alan Frindell: And in the same session. Like, between between the same two endpoints, you've got I've got one set of tracks. I've got my audio tracks with algorithm one and my video tracks with algorithm two? Yes. Okay. Perfect.
[00:07:27] Will Law: Okay. Continuing. So as I mentioned, we define a default algorithm zero, and this default algorithm immediately extends the switching set assignment parameter to add in the additional fields that we defined in the initial draft design and in the PR. So we've added throughput threshold, set throughput fraction that has since been renamed weight. This was a comment from Alan, so that change was made yesterday. Activate switching and set rank is actually no longer optional. It's required because of the serialization of this parameter. And these rules we presented in London, they have not changed. So the the weights and the ranking, you can set everything the same rank. You have a very simple scheme, but this allows you, for example, to have three sets of three switching sets in in operation simultaneously. It might be video, audio, and slides in a web conferencing scenario. And you can have under differing throughput availability, you can fail down. So you can always preserve this highest switching set here because it's got the the lowest rank. It's the most important. So it always gets allocated the bandwidth first and then the second one. And it can be that you run out of available bandwidth and you just don't deliver under certain scenarios on a good switching sets. This is again by design. Several comments were made about DDoS protection and to try to head this off, we originally had two setup options which limited the concurrent throughput and the concurrent tracks that you could use with DTS. And I think Gwendel has written extensively on this. And Gwendel is also right. This is a clear attack vector. However, setting up per session restrictions is trivial to bypass, and this was this was commented a lot in London. If we set up a limit per session, you just open up more sessions and you bypass all our limits. So really, we have to fall back on a relay protecting itself. It has to look at its resources and it it has to, irrespective of anything negotiated with the client, protect itself from abusive behavior. So we just the consensus in London was to remove these two set of options. And it it it is an attack vector and relays amongst all the other things they have to do need to make sure that under a scenario where the client's giving very little traffic but is causing a lot of traffic to move the network that they can recognize this and perhaps discontinue the session. Some other items we decided in London. So issue number one was do we need the ability to remove a subscription from a set without unsubscribing from that? In other words, I don't wanna switch it automatically, but I just wanna pull it out. No one could come up with an immediate use case for this. So for the simple algorithm number zero, you can't do that. But future algorithms can implement a more sophisticated removal mechanism if you like. The second decision we made here was repeating the switch ID. This is this is repeated with each subscription that you make each time you pass that switching set assignment parameter. Was it a good design? We decided yes because it avoids an extra RTT in defining the set and then waiting getting a confirmation that the set's been defined and then being able to use another subscription. So we've kept this design. And then there were also requests to add time out and stability measures. This came from the mocktail guys with their implementation experience. And we're not gonna add these to algorithm zero, but again, future algorithms can add the the more sophisticated algorithms. And you can quickly work yourself into corner cases with this. So I like the idea that we can have multiple algorithms and can experiment with different time out and stability damping functions. So I believe this work is now represented as p r sixteen thirty eight. We've resolved the major issues and the comments which are there, including Alan's exuberant 24 comments that he wrote in an external Google Doc. Those were all addressed yesterday and the day before, so that that is in there. We've implemented the decision and the changes in London, and they've also resolved the merge conflicts. So I'm I'm here. I believe the PR is ready to be merged, and I'm opening up for comment in the remaining time that we have on SSTS. Let me just see if there's a comment from Alan for q.
[00:12:29] Alan Frindell: I have a question about I I don't remember any of the comments I left in the doc. So and but I thought you just said I thought on the previous slide, you said you can't remove a track from a switching set in August That's
[00:12:44] Will Law: not true. You can't by unsubscribing it. You unsubscribe the track, and it
[00:12:49] Suhas Nandakumar: gets But
[00:12:49] Alan Frindell: then I no. But I thought that in the review, maybe I left a comment about the fact that you I thought you said you can remove okay. Maybe we need to go back and reread the text. So there should be no way to change the switching set ID of a subscription. Like, you put it in, and it's in. You can't remove it. You can cribe from it. That's it.
[00:13:10] Will Law: You can unsubscribe it. You can't change the ID that it's subscribed to. So you I thought I
[00:13:14] Alan Frindell: saw a text in the PR that said you could about explained how to change the ID. So maybe I maybe I'm misreading, or maybe it's been updated.
[00:13:22] Will Law: Yeah.
[00:13:25] Ian Swett: Ian's wet. I think from a design perspective, this looks good. Thank you for updating this. I have not reviewed the most recent PR, but I have reviewed previous ones. So I I think, I don't know. We can go back and forth on that. Actually, was unclear about where we've landed on this about, like, whether it's supposed to be a PR or a draft. I I realized I don't wanna go too far into process, but So we did editor, I wanna know.
[00:13:53] Chairperson: We did do a consensus call that it was supposed to be a draft. That is the current state of what is supposed to happen. Like, if you like this PR and you think it's ready and you guys have the four of you think it's great, then we could just do that. But or we could make it have it do it a draft. I don't we don't have the discussion right now. I think we do it offline with Will. Okay. Yeah. But yes. That is the correct state.
[00:14:17] Ian Swett: I I don't like to be put in this objective situation of rejecting or accepting things like this, which, like, the working group might have strong opinions on. Like, I'm happy to get it ready to merge into the draft, and, like, of course, we will do that. But, like, I would rather the call be made by the chairs, the working group, some larger group, because I don't wanna be on the hook for, like, saying either yes or no, honestly.
[00:14:43] Will Law: Can I remind the room that we had this exact discussion in London? And it was decided that because our charter requires us to implement some implementation of APR on the server side that we could this was originally written as an external draft, and then it was this it was the request was rewrite it as a PR, which was that was done. So if we look at the minutes for London, that was a decision taken in London. And I'm not arguing either way. I wrote the draft, and then I wrote the PR. If someone wants to take it out and make it a draft again, I'm okay with that.
[00:15:19] Chairperson: Okay. Yeah. I don't I don't wanna wrap around the axle about this. It's entirely possible I've forgotten something that happens all the time, unfortunately. If the editors would like us to do a consensus call to cover themselves on this and a person and they do feel it is ready, we are happy to do that. But we we could do that unless you don't do it here. Colin. Oh, no. I'm sorry. Mike is next in the queue.
[00:15:47] Colin Perkins: Thank you.
[00:15:49] Yanmei: Yeah. So I also had
[00:15:50] Mike: the draft question, but we can discuss more offline. So the other thing that I was thinking as you're presenting these slides is on the DBOS topic. It sounds like the intent is that we have recourse at the session level that we negotiate this in setup. And if you don't like the limits, the the session does. Is is has there been any thought about, something more granular than that, to communicate limits, you know, once things are kind of in in flight? You've got maybe multiple switching sets or something going on. I'm I'm just trying to think about this more in terms of the implications for actual applications when you hit these limits because I'm expecting that we will have limits in place that some applications may be running into.
[00:16:47] Will Law: Okay. That that's a good question, Mike. So currently, yes, it's up the discretion of the relay implementation if it wants to kill the whole session or maybe just terminate the subscriptions that are involved in that switching set. Oh. So my my vote would be that it terminates the the offending subscriptions for a switching set that it feels has an asymmetric ratio. It's there's too much data coming in and not enough data going out. And that's the ratio I would monitor if I were building a relay. And we're not gonna set that as a negotiated parameter because the client will just open up more and more sessions and and and do, you know, accumulated damage on the relay. But I think they exist the spec has existing mechanism for the publisher to terminate the subscription with with an appropriate message. So I I think that's what a relay could do in that situation.
[00:17:48] Suhas Nandakumar: So how's Cisco? Thanks, Will, for putting the PR. I reviewed the latest PR, and I like the fact that we are, going based on algorithm. That way, if someone wants to do something more advanced, they can still do. And we also have different default algorithm for someone to get started. And and and we approved with the two implementations that the default algorithm is pretty much useful in many of the cases that we tried under constrained networks. At least my test was with Wi Fi network constraint, some some with, like, full flow, some with, like, constraint flows, and it was reacting pretty well. So I I do feel that this is a useful addition to mock, and and whatever way we can support it, we should support it.
[00:18:37] Alan Frindell: So,
[00:18:40] Colin Perkins: Martin, this is just a question about the process here. Do you wanna clarify it all before I even start? Or what what is I mean, so I think I heard you say, maybe I understand correctly, that the chairs and the editor of this draft that, know, Will and the editors could decide whether they were gonna merge this into the document or not. Is that
[00:19:01] Chairperson: We have a process where the editors can choose to the editors and authors can can unanimously choose to bring things into the mock t draft. It is obviously subject to to we have these consensus calls on every draft diff where now it behooves them to, like, consult the working group to not revert things and create a mess. But that is the process. We do not do a consensus call on every PR that goes into the document.
[00:19:29] Colin Perkins: So my understanding of the process is that that is supposed to be bringing things in that the document is supposed to represent consensus, the working group document, and that we do our best not to bring things into that they often made decisions on things that are very obvious. Right? But that, no. This needs working group consensus to go in. And I think Ian's point was we don't have that. And I don't think that I think that the working group chairs determine consensus, but I don't think it's your choice. It's not what the chairs want here. It's not what the editors want. It's what the working group wants, whether there is consensus to put this in or not. Is I'm do we do we agree on the process here? Because it's what I just said is quite different than what you said a few minutes ago. Okay.
[00:20:15] Magnus Westerlund: I I think to to the same, four d d t s was actually held a consensus call to add the functionality, which there was strong consensus to do. That's and in that email also
[00:20:32] Colin Perkins: There was no consensus when measured at that point in time to merge it as it was.
[00:20:37] Magnus Westerlund: No. No. I agree with that. There's never been a consensus call on merging it, etcetera, that way. The share working group shares instructions to the DTS was to do a draft. The same as was given to top end.
[00:20:52] Colin Perkins: Which I believe they have. And now they have done the PR as well, which looks like an excellent PR, and I think it's ready to merge and should be merged. Yeah. And I I think that if we're gonna make a decision about that Yeah. We certainly should have some agenda time to discuss the pros and cons of Yeah. Of either side. Right? But I I I think that needs to be a working group decision is all I'm trying
[00:21:11] Will Law: to get to.
[00:21:12] Chairperson: Yeah. Okay. Thanks.
[00:21:16] Alan Frindell: Just seeing there's only six minute I think we have a lot of we need to kinda get our ducks in a row on on what our process is here, but I don't wanna take the six minutes and thirty eight seconds. If somebody has technical questions about this draft Yeah. I will yield my time. I guess I just wanna make it entirely clear. I said in the chat.
[00:21:33] Chairperson: Can can you quickly answer what you would like us to do to merge this?
[00:21:37] Alan Frindell: Okay. This is my my my read of the RFC that defines what an editor does is that we reflect the consensus of the working group into the document, and we have a process in place where we do we obviously do our best. We have this sort of check amongst ourselves that for anything that's designed, both of the editors and both the authors have to agree that that reflects the consensus of the working group. But I think for bigger issues like this, it does not hurt to have a consensus call as you have issued on the list. Is this ready to go into the document? And I'm totally fine with adding that for big things where we wanna make sure, like,
[00:22:12] Chairperson: that Okay.
[00:22:13] Alan Frindell: That we're doing it right and rather than putting it in and have to take it out.
[00:22:16] Chairperson: Alright. So I think that I I would like a clear I will initiate a call
[00:22:20] Will Law: on the list.
[00:22:21] Alan Frindell: Okay. My only ask is that one way or the other, I don't wanna keep iterating on this as a PR because I find that to be very hard to do. Either it needs to go in or it needs to it needs to be in a draft, but, like, I had to I had 30 comments, and I'm like, this will overwhelm GitHub. So I had to go do them in another tool. So, like, just from a purely practical point of view, it just needs to be a draft, not one PR. Thanks.
[00:22:47] Ian Swett: I actually Go ahead.
[00:22:52] Moezanati: Moza and Cisco, two two quick questions, Will. First, on the the default. I like the extensibility of the algorithms. The default zero one, is that something that can be removed or is it something that's gonna be, you know, ossified thing forever? If we determine It's ossified
[00:23:14] Will Law: forever because we're writing it into a document that we hope to publish as an RFC. So but is it it's ossified from the fact that it's reliable. Right? Algorithm zero will function that way. If you don't wanna use it, write algorithm two or three or four.
[00:23:28] Moezanati: Could it be negotiated the same way that the future ones will be negotiated so that it's so that if we decide it's a bad idea that we just just deprecate it and
[00:23:41] Will Law: Yeah. Could we deprecate it? One one option is to remove it completely. So, again, if we're gonna write this as an extension, then when your relay is negotiating, does it have SST support? It sends a list of algorithms that supports.
[00:23:57] Moezanati: Oh, so cannot include zero on the list? You cannot include zero on the list of supported algorithms?
[00:24:01] Will Law: It could not include zero.
[00:24:02] Alan Frindell: That is correct.
[00:24:03] Moezanati: Then I'm good.
[00:24:04] Will Law: We should probably, per your point, check the language because I think the language says it's a default algorithm and it it must be implemented by the relay. But there we could put an allowance in there to say the relay can choose not to implement this algorithm and to not advertise it in its list of supported algorithms.
[00:24:21] Moezanati: Got it. Okay. And the second the second thing is I know that Mock is only talking about the, you know, endpoint to Edge Relay, but it it seems like that this design is expecting that edge relay to pull all the tracks, pull the entire ladder down. And is there any guidance about limits on that? Because if the ladder is big and the endpoint, you know, only needs one track?
[00:24:49] Will Law: That that's exactly the DDoS question, which we've discussed, and there's a lot of comments on the thread for that. But we decided that all the restrictions we try to set up to protect it can be trivially bypassed. So it it is true. And the the spec as written says the relay should not should issue a subscribe forward equals one for all the tracks to keep them fresh so that when the client wants the track, it can switch quickly. We could introduce a second algorithm, which is the same as the first, but it does subscribe equals zero upstream. But now you will have a delay. Right? As soon as you wanna switch to a track, you have to go upstream and get the track down to you, and then you could switch to it.
[00:25:28] Moezanati: Okay. So that behavior is algorithm specific?
[00:25:31] Will Law: Yes.
[00:25:31] Moezanati: That forwarding behavior? Okay. That that's better.
[00:25:35] Jordi Cenzano: Okay.
[00:25:38] Ian Swett: Ian Sweat, is it possible to add an algorithm you can call it one or zero. I don't really care what it is, which is like server knows best. Like, the server can just say, like, I know what I'm doing. Yeah.
[00:25:48] Will Law: Because It's it's certainly possible. A lot of
[00:25:50] Ian Swett: use cases I have.
[00:25:53] Will Law: It's certainly possible. We can do that. I don't like that because I don't think the server really knows best most of the time. There's a lot more and servers get ossified far faster than clients do. So I I I'm scared of there's there's multiple server notes based algorithms built in a service from 2005, and they're no longer valid.
[00:26:14] Ian Swett: Okay. Fair point.
[00:26:15] Will Law: We can we do that? Yes. We can do that. So I would just like some clarity from the chairs then. Do you you when you say you want this as a draft, do you want it as a extension draft? In other words, it defines an extension to m o q t and it implements essentially what we have here.
[00:26:39] Magnus Westerlund: I think it's already today in some form is an extension because it's not mandatory to support, is it? Therefore, it's an extension, even if it would be within the context of MOQT specification. I think what we want to say now at this point is that we will run the consensus call to merge the PR in its current form. And in case that is not there's not rough consensus to do that, We expect the draft, just to be clear.
[00:27:17] Will Law: That draft does what? Defines a completely separate?
[00:27:22] Magnus Westerlund: It's it's the draft contains the specification for the functionality.
[00:27:28] Will Law: Via an extend how does it integrate it into MOQT? Does it define an extension? But it's
[00:27:34] Magnus Westerlund: As an extension, it's I was I don't see the difference here. What's your
[00:27:38] Will Law: Okay. Well, it's possible to write a draft that it doesn't define an extension here in Moq t and just defines an informational draft. I I just wanna be clear on what you're asking.
[00:27:51] Chairperson: Okay. So in about two weeks, we'll have a resolution to this. Colin?
[00:27:57] Colin Perkins: Okay. So one thing I just wanna say is that the current PR does define the text as the the list of supported algorithms can be empty, means you don't do SSD. Right?
[00:28:07] Chairperson: So Right. So, functionally, this is an algorithm. This whole discussion is about, like, the the ergonomics of, like, sorting this into different drafts. And so Which people feel strongly about it, I recognize, but it is that's what it is about. And it does have implications for managing the workload, but fundamentally does not change what gets deployed in the world, what draft these things are. Right. So before we have
[00:28:29] Colin Perkins: a consensus call on this, I'd like the opportunity to have some time to discuss the pros and cons of these two approaches. Yes. And I disagree with Magnus that if we don't put it if we don't have consensus to merge the PR, it automatically becomes a working group draft. We will also have to get consensus that the working group the draft will be adopted as a working group draft. That also needs consensus. Correct? Right? On the same page?
[00:28:54] Magnus Westerlund: So I yeah. Considering that we already had the consensus call on the functionality, I could see that we could actually could adopt it immediately as a working document because we have agreement in the working group to
[00:29:08] Colin Perkins: specify the functionality. Is gonna be that we already had that consensus call. Yeah. That's a So
[00:29:12] Chairperson: so so if we all if we
[00:29:14] Ian Swett: all agree the work should
[00:29:15] Chairperson: be done and we can disagree on how it is done and we neither adopt it nor put it in the draft, then we're not pursuing the work, which seems like a perverse outcome. So I
[00:29:24] Colin Perkins: think the third thing that that there's a third option is actually which is one the the alternative that I propose to not merging this PR if we don't wanna wanna move this PR, PR, which is you remove the algorithm zero definition out. My problem always with putting this in a separate draft, and I'd like more time to discuss this, is it's very hard to understand how it fit how it fits into the processing in the base draft, in the transport draft. And so if we left the part of this PR that doesn't define algorithm zero, just defines all the other parts of it and how it fits in where you process in the base transport, and you move the algorithm zero to a separate draft along with other drafts, that would actually meet that would resolve the problems that that I think are an issue. Now I'm not you know, we've had never had a chance to talk about those problems or anything. We can But there's a what I'm saying is there's a clear third option here as well.
[00:30:15] Chairperson: Okay. So I think what Colin is saying is we should delay the consensus call until we have virtual interim time to discuss the draft through of this, which That that
[00:30:22] Colin Perkins: would that would be my ask is, you know, to, like, get some
[00:30:25] Chairperson: time to talk about. I think I mean, we could take the time. It's slowing us down more, but that that's okay. We gotta get it right. Alright. Alan.
[00:30:33] Alan Frindell: Thanks, Colin, for offering that third option because I hadn't really considered that. But, like, if you just take the shell of SSTS, like, just like, oh, we added a parameter. It doesn't really do anything. Like, I have a hard time saying that that doesn't you know, that doesn't I have no objection to doing that. The thing I wanted to raise actually was Victor made a technical point in the chat. I don't wanna make sure that that got raised, which was if I understand correctly how we negotiate the algorithms right now, the server's offering a list and the sorry. The publisher's offering a list and the subscriber is choosing. And I think Victor's ask was, like, is there a way to say, like, I I would sort of like, do we wanna offer the publisher more control here, which is, like, the publisher came out with a new cool algorithm and really wants the subscriber to choose it. But, anyway, you do the best that you can. Or maybe, Victor, you can tell me make your own point, but I I thought it was a good point. We should think about it.
[00:31:27] Chairperson: Alright. Thanks, Will.
[00:31:28] Will Law: Yeah. Just to reply, I could certainly do that. The re the Relay can offer up its favorite algorithm as the only item in the list, and the client has no choice but to accept that algorithm if it wants to use SSTS. So it's a way for the server can choose by essentially not mentioning any other option.
[00:31:50] Michael Hosnas: Okay. Thanks. So
[00:31:58] Chairperson: this is Moe talking about location filters, which are in fact going into the base draft, and so it is a PR appropriately.
[00:32:09] Moezanati: Hi, This is a location filter. I worked with Victor on this PR 18 o nine, and it was earlier 14 o one. So to recap the current design in mock t, there is a location filter parameter already and then it compare and subscribe publish okay request updates. And it has a filter type enum inside of it and then some optional fields for start and end locations. The current filter types defined are one is the next group and this is relative to the largest object that that the that the publisher maintains. Then the next one is the next object too. It's technically called largest object in the draft right now, but that's wrong. It's actually the next object because it's largest object plus one. And then there's those are both relative to largest object. Then you can also specify absolute locations using filters three and four, absolute start where you just provide the start and the wind, and absolute range where you provide both the start and an end. And so there's rules about when those optional parameters appear for the different filter type enums. Then p r sixteen seventy three for fill fetch adds some more. It initially added many and now it reduced them and only adds one. The critical one is the relative start fill, you know, type five. And that adds another optional field called relative previous, which is how many groups back you wanna start. So a start group delta of n, again, relative to largest object. And there's there were also an earlier versions of that PR, absolute start fill and absolute range fill. And the latest version just makes those replace absolute start and range and absolute range, but I think that's probably an oversight and we're probably not gonna be able to completely replace those. We probably still need to have different fill variants of those. But anyway, so we have a bunch of enums, bunch of different ways you can subscribe. The new design that's being proposed, same location filter parameter, same messages that it goes in. The difference is we eliminate the enum. There's no more filter type enum and you just put in the start and end locations. And they're again optional. Those fields are optional and you can only omit from the end. So you can omit just the end object which means all objects in that end group. You can omit the end group and the end object which means no end to the subscription. You could omit the start object also and the rest of them which means that the start group is a relative start group or you you can include everything. And finally, if if you wanna remove the filter just like all the other filters, you can put length equals zero and that will remove the filter. So you can send a request update to remove filter. That's actually something you can't do today. You cannot remove the current the the current subscription location filters. As a hack, you can change the filter to an absolute start zero zero with no end. But that's a really hacky way of trying to remove the filter. This makes the length equals zero update look just like all the other filters. And again, if only the start group is there and all the other ones are eliminated, then that's a relative start group. I mean, it's relative to next group. So that lets you start at next group if you say zero, current group if you say one, and prior group if you say two. Now this doesn't say anything about if you if you're asking for prior groups whether that happens on a fill fetch stream or whether that's doing rewind kind of you know live subscribe streams or whether that just means your filter starts that that early but you're not gonna get any of those objects because they're already they're already gone. The those semantics are not part of this PR. This PR is only about the spelling of how you specify the locations that you're interested in. What happens about that interest, whether that triggers fill fetch streams or something else will be handled by sixteen seventy three. And we also have this special filter called largest object, which should actually be called next object. And if you put a start group end object of zero zero, that is the way to to invoke that next object filter. You always start at the next object, and there's no end for that. And then the absolutes should be, you know, pretty straightforward. Absolute group IDs, absolute object IDs. Alan.
[00:36:57] Alan Frindell: I you we're going kinda fast, and I apologize. I have not read the PR. But did you say that there's a way to spell relative previous with this?
[00:37:05] Moezanati: Yes. So start group
[00:37:06] Alan Frindell: Which is it on the slide somewhere?
[00:37:08] Moezanati: Am I missing Yeah. So it's the second bullet. If only start group is present see, if only if you would put only a start group, then that is a relative that is a relative start group. It's not an absolute start group.
[00:37:19] Alan Frindell: Only a start group is a relative start group, but it has to be in the past, not the future.
[00:37:24] Moezanati: So, yeah, if it It has
[00:37:25] Alan Frindell: to be subtracted from the largest instead of added.
[00:37:28] Colin Perkins: Okay.
[00:37:28] Ian Swett: Yes. So if it What
[00:37:29] Alan Frindell: you have is a little compact. I probably just need to read
[00:37:31] Ian Swett: it better.
[00:37:31] Moezanati: So so what we have today in the current drafts and in the current PRs is we have in in joining fetch, you have relative joining start, which is a number of groups to start. And in fill fetch in sixteen seventy three, we have this relative fill prior previous or something, you know, relative fill previous. And that's also a number of groups back from the the current group to to fetch. So to do that here, you only put in a start group and that start group becomes relative. If you put start group and start object, then that's absolute. It's no longer relative. And one other point that I forgot to put on the slide is this is not negotiated. The other filters that were talked about before are negotiated with setup options. This is not negotiated. This is this is baked in because it's core functionality that's required for subscribe and and fetch. So these are not negotiated filters at all. Okay. So a comparison between the old and the new. There's no change in functionality. You can think of it as a spelling change because all of the all of the ill the, you know, filter types that we had before map directly to a new way with this new location filter. So next group, you just put start group equals zero, and that will start you with the next group. Next object, which was called largest object in the draft today, you just put start group object to zero zero. And absolute start, you just put an absolute start and groups and object. Absolute range, you put start and end absolute group and object IDs.
[00:39:14] Alan Frindell: Okay. And then the way you start at zero zero is actually by not sending anything at all?
[00:39:20] Moezanati: Start what? Absolute start range zero zero. Yeah. You you that's unfiltered. That's unfiltered.
[00:39:26] Magnus Westerlund: So you
[00:39:26] Moezanati: That's unfiltered. Yeah.
[00:39:27] Alan Frindell: Don't send it?
[00:39:27] Moezanati: You don't send it. Yes.
[00:39:29] Alan Frindell: What about okay.
[00:39:30] Moezanati: And and the the draft kind of hints today to do that if you wanna remove a filter. Doesn't actually say this is how you remove a filter, but it hints that absolute start zero zero is equivalent to an unfiltered subscription.
[00:39:41] Alan Frindell: Should I only be doing clarifying questions right now?
[00:39:44] Moezanati: No. I'm assuming.
[00:39:46] Alan Frindell: Why is your proposal so bad? No. I'm just kidding. I know. Yeah. That work? My only it's it's I I like there's pieces of it that are easier to understand. Like, absolute is just very easy. It's like it's right there. But I feel like some of these other ones were, like, when we had an enum that defined what you're doing instead of special encoding, it was slightly more clear. But I'm also I don't care that much.
[00:40:10] Ian Swett: K. So people like
[00:40:11] Moezanati: Well, no. But I wanna I wanna make sure it's not confusing if I explain. So start group, a single number of start group, when would you ever want that to be something absolute? So No. Oh. That's that's the
[00:40:21] Alan Frindell: It makes now that, like, I've seen a slide with it and thought about it for, like, a while, I didn't I think and I I will go back and do the math to make sure that all the edge cases are covered, but I more or less trust that you've done that and that there isn't anything you can't specify. It's only so it's the only thing what you've done is wrong. It's just it's not quite as direct as, like, right now, if I want the next group, I just say next group, which I recognize is I know shouldn't con confuse API and why. No.
[00:40:49] Moezanati: But you don't just say next group.
[00:40:50] Jordi Cenzano: You have to say next group, and then
[00:40:51] Moezanati: you have to figure out whether or not you include some those those fields. Right?
[00:40:55] Alan Frindell: Yeah. Yeah. I'm anyway, I'm just saying that there's there's some pros and there's some trades trade offs here. I think this is fine. I'm not arguing against it.
[00:41:04] Moezanati: So in addition to the current draft, it also supports the exact features that the fill fetch 17 sixteen seventy three provides too. So the relative group start is, again, just putting a single start group, and the absolute start and ray and range is putting absolute numbers. Alright. So I've mentioned Phil a few times. The expectation is that this would land before Phil because it's it seems smaller and that we would update Phil to use this. And I'm I'm gonna do the update so you don't have more work on your plate, Alan. We'll update fill to to use this instead of the enums instead of extending the enums. So what this would look like in fill is two separate range, location ranges. One in the subscribe for the live portion and one in the fill parameter for the fill portion. Fill right now uses the enum to trigger the fill fetch stream and the fill parameter is optional. But this would make there's no enums anymore for for the filter types. So you add the fill parameter explicitly when you wanna fill and that's the trigger. If you add a fill fetch if you add a fill parameter, you're gonna get a fill fetch stream. You If don't add a fill parameter, you're not gonna get a fill fetch stream. So that's the that's interaction with fill. And the two separate ranges allow you to express different filters for the subscribe part versus the the fill part. So there was people argued about whether or not you could should allow a single range and and implicitly try to break up that single range into a live and a fill. But this way, with two separate explicit ranges, you know exact subscriber knows exactly I want this for my subscribe filter and I want this for my fill request. And I didn't dare put this on the slide, but if people that like to rewind wanna do something like that again or the original purpose of the fill fetch was including current object on live streams. This spelling would allow that without any more wire changes. It would just be a semantic change to say, if you get a subscription with these things in it, it means deliver even those old objects over live subscribed streams. So if people want that, they can revive that as purely a semantic change in the meaning of this filter without any wire changes. So here's an example of what you would put in subscribe. You put the location filter parameter and that is for the live subscription. So location filter parameter zero zero means start the next object. So that's basically, you know, start right now at the live head, but don't give me the old stuff. I don't want any replays because I'm gonna fetch old stuff. So the fill parameter is added to fetch the old stuff and you put a location filter of one, which means start at the current group. You're gonna fetch starting from the current group object zero to the live head in a fill fetch stream. And you're gonna have your live subscription filtered to start at that live edge. So you don't get the objects twice. If they're old, you don't get them on both the live subscription and the fill fetch stream. One new functionality that this also provides is that now the subscription itself can have a filter that even applies to the past. So when would you use this? This would be useful if you wanted to say, I have a tolerance for one group in the past. So the current group, even old objects in the current group, I want you to deliver them to me. If things come reordered in the current group, I want them. Today, the only way that you can start a filter on on the live edge is the largest object filter. So that means you have to ignore everything that came before the live head. This would allow you to say, no, I would also like the the objects that it may be reordered in the current group or in the current the past two groups but still filter out everything really old. So that's a new functionality that this would provide that some subscribers may have a use for. This is an example of how you do that. You just say location filter one and so that means I'm starting my filter at the current group. It doesn't mean I'm gonna go fetch things from the current group object zero. It just means that if those objects come late reordered, let them come through. Okay. Any hopefully that was all clear for the fetch stuff. Looking at you, Alan.
[00:45:41] Alan Frindell: Yeah.
[00:45:44] Moezanati: So this and now this is about fetch, the classic existing fetch that we have. Fetch today, there's two variants. There's the standalone fetch which has start and end fixed locations and then there's joining fetch which has adjoining start location which could be absolute or relative. So this location filter replaces all of those. So fetch now would require having the the location filter parameter. And actually the standalone fetch doesn't require it. It says it can be used but now if you omit the in standalone fetch, can request the entire track. You if it's a VOD track, you can just say fetch. And you if you don't know anything about the timeline or the groups, can just say fetch and you can get the entire track. And for joining start, again, you have the relative version where we just provide start group. And so you say that that's how many groups back I want my joining fetch to start. Or you can give an absolute joining fetch start group. And even though we made those updates to fetch, it's most likely that the joining fetch section will be completely removed by fill. And if we wanted to, we could even replace fetch itself one day with with fill, but people may have a harder time doing that, so they might not happen soon. So we just propose to go ahead and merge this. It seems like a straightforward spelling change in when. And then the following work would be update sixteen seventy three to describe how Phil uses these new new location ranges.
[00:47:22] Jordi: Victor.
[00:47:23] Will Law: Can you hear me?
[00:47:24] Chairperson: Yep. Yes.
[00:47:25] Victor Vasiliev: Yeah. I just wanted to maybe provide a little elaboration or, like, why why I saying is a useful thing is to unify the there are we we currently have free ways to specify how to specify allocation range in the draft and just unifies it. And it is convenient. It is very useful because there is like subscribe and fill and subscribe technically fill inherits parameters for subscribe. So it would make sense for them to share the syntax. And feel is basically a variety of fetch, so it would make sense for them to share syntax. So I I think that is yeah.
[00:48:09] Moezanati: And if we had anything else later that requires location ranges, it's, you know, a natural fit for those messages as well.
[00:48:18] Colin Perkins: Colin, I'm not arguing it should be one way or the other, but I was just sort of curious, like, wouldn't we use this to replace fetch as well?
[00:48:26] Moezanati: There there there's a lot of nuances there. So fetch is not well thought out. If you read it today, there's a lot of broken things in it that just don't make sense. Yeah. For example, you know, if the the track ends, you know, and it's ended and you get a publish done, it's not even clear you can fetch that that track anymore. And for and for sure, if you eliminate the fetch standalone parameter standalone message, you couldn't do it with fill fetch parameter because the subscription is is ended. Right? So things like that, we have to probably rethink about what publish done really means. Publish done should just mean that the live head is done and fetch okay signals whether the track is ended. We lose fetch okay when you do fill fetch because there's no eye to eye stream anymore to give the fetch okay on. But so you lose the indication that that that the track is actually ended and what the end location is. Fetch okay gives you the end location. The track ended well, that's another problem with fetch. The end location is ambiguous whether it means this is the end location of this current fetch or whether it's the end of the entire track.
[00:49:29] Colin Perkins: I mean, we added those signals to be able to I'll let Alan speak here but yeah.
[00:49:37] Alan Frindell: First of all, if you go file all your issues that you think there are with fetch, we'd love to make sure that they are addressed. This particular one, there is this you can we did differentiate the case where the end of the stream happened because your fetch range extended p s has the end of the track or not. But I think some of the things we're talking about with fill fetch may be real.
[00:49:57] Moezanati: So easier to remove it if people are okay with removing it instead of fixing those. So we
[00:50:01] Jordi Cenzano: could just remove fetch completely. The thing
[00:50:02] Moezanati: that has to be fixed is is publish done. The publish done interactions publish done specifies that you can't, you know, you you can't go back and and do a request update to the to the subscribe stream to get another, you know, fill location.
[00:50:17] Alan Frindell: Fill fetch says you can. Anyway, let's not talk about fill fetch. Let's talk about this. I I just wanna say one well, then I say that, and then the one thing I wanna point out about the way you have suggested it will go into 1673 is that there'll be two different location filters. And the only thing that gives me it's a little bit weird is that, like, I can have the the my subscribe and my fill be, like, have nothing to do with each other. Right? I can go say subscribe to, like, some group two hours ago and fetch some group from a minute ago, and, like, it's not exactly we were supposed to be doing joining fetch, and that's not a joining fetch anymore. But maybe that's fine. Maybe we just give every everyone all the Legos and they can build whatever castles they want.
[00:50:52] Moezanati: And I mean, nothing stops you today from putting nonsensical things in the current location parameters.
[00:50:58] Alan Frindell: In joining fetch? I I suppose that's true. Anyway, we were trying the goal of the original goal of 1642 and then 1673 was to, like, rationalize joining a track. And every change we've made to it has, like, stepped farther away until, like, you can do whatever you want. And, like, that's fine if that's what people wanna do.
[00:51:13] Moezanati: I just wanna point it But you you can you can join a track with a single with a single range if that's what you want and that and you add a fill parameter if you want to fill. If you if you intend to do joining fetch, you add the fill parameter. You don't have to put a location in that fill parameter if it's the same as the location Okay.
[00:51:32] Chairperson: Guys, we're we're running low on time, so let's not debate what Fest just today. Victor, I'm gonna close the queue very soon. Suhas.
[00:51:46] Suhas Nandakumar: Moe Moe, I think thanks for this presentation. I think Alan's point is correct in the in the sense that even though you you can have a two degree of control on on the field fetch location filter and and self subscribe location filter, I think it it would be helpful for joining fish to kind of say that that filter ends at the next object or whatever it called because that would give someone who's making it very clear, a smooth transition.
[00:52:11] Moezanati: Yeah. It and and it does say that. If you omit the end, it does say that that means the end is the largest object. So That's it. Victor Victor dropped off.
[00:52:26] Chairperson: Thank you. Thank you for staying on time. Alright.
[00:52:30] Moezanati: So do we are we are we good to merge or or you wanna wait for something? Or
[00:52:40] Chairperson: Which editor is going to grace us with those presents? Give him the clip. Give him the clip.
[00:52:58] Ian Swett: Yep. Was anyone did anyone not like that presentation? Because otherwise, we're gonna, like, editorialize and merge it whenever it's done.
[00:53:05] Magnus Westerlund: I I
[00:53:05] Colin Perkins: there's two PRs discussed. Only know which PR we're talking about. Like, yeah, it's really 18
[00:53:08] Ian Swett: o the one Moe primarily discussed, not 16
[00:53:12] Colin Perkins: o Not the Phil. Not the Phil one. Location. Yeah. Okay.
[00:53:15] Ian Swett: Yep. 180 nine. Right, Moe? Okay. Alright. Oh, thank you. Great. It's a very small screen. Yep. Okay. How can a publisher update a subscription? So we've talked about this in the context of SSTS a little bit and top end filters touches on it, switch from there's a number of cases where the publisher unilaterally changes the state of a subscription, and it would be nice to know that. In some cases, it's just nice to know. In other cases, it might actually be fairly critical to the functionality. For example, if you, like, stop a subscription in a given group, it would be good to know what group the, like, publisher stopped at. So, like, if you wanna subscribe somewhere else, you wanna do some like, just know what to expect, all of those things. It also might be useful, for example, like, when sending a go away, but we'll see on that. But the point is this is like a unilateral, I did this thing, I'm telling you, FYI. So there's a PR now for subscription state update, which kind of provides for that. Originally, we were thinking possibly request update could be used for this. However, request update can fail. And, really, request update is a request to update the subscription. It is not a statement about the state of the subscription. And so in this thing case, I think we think no response is required. The current proposal just has one field, which is parameters. You can't even update track properties because you can't update track properties as we discussed in the current previous interim. Yeah. Does this all seem sensible to folks? It I I think this probably is sensible. I mean, there's a few other ways of spelling it, but, like, we could put it in as nested params inside a message or something like that, but I think this is the easiest way. Okay.
[00:55:18] Suhas Nandakumar: Yeah. So how's Cisco? I I think most of the use cases that you'll study and have come repeatedly proven something like this is import is useful. And having it not an hacky version, but a clear clear state, would be nice. So I'm gonna support this.
[00:55:34] Ian Swett: Sure. Thanks.
[00:55:39] Will Law: Yeah. I'm just pointing out that this, message is very useful for SSTS, and this is give credit to Alan for pointing this out. Right now, when the server switches you, the client just has to observe a change in objects, but it doesn't get an explicit message that a switch has occurred. This would be an excellent conduit for conveying that information you've and and it could come back on your existing subscription state. So I think it's it's very nice utility for SSDs.
[00:56:08] Chairperson: Martin Duke is an individual. I was not worried about the use cases that you described. I haven't tried to implement SSTS yet or or or the switch from or anything. So maybe I will be worried about them. I would actually encourage you to go a little bigger. Like, I think we have other corner cases around, like, publish done where, like, we don't know when it is if if you have a subscription that ends at a particular group as a relay, but you have a subscription at the end of time upstream, you have, like, no way to send publish done. So I think there's things we could do with, like, group metadata that would solve a lot of these problems and maybe even allow us to get rid of other mechanisms. I don't wanna do that at the mic today, but if, like, people don't hate that idea, I would I'm happy to run into the PR and do something. Thanks.
[00:56:57] Ian Swett: Interesting point. I believe there's something awkward about publish done. It keeps coming up as weird. So Yeah. Happy to share that. We could also land this and then do a follow-up. But yeah. Colin. Oh, wait.
[00:57:10] Colin Perkins: Jim. I apologize, first of all, of that I didn't know this would be on the agenda, so I haven't read it. I'm just reading it for the first time right now. But at casual glance, it it seems like, yeah, reasonable. But I think I think it's just too vague to say. It's a state update. I think we need to explain what you can update when, what the constraints of that are, like, make it fairly specific. It's pretty it's pretty open. Do what I mean right now without really much specification of it. So I I think it I I like the idea, but I think it needs a bit more constraints and details on what state can be updated and what the relay needs to do of passing that at at what it you know, does it need to send those downstream or whatever it is? That type of information of how how you react when you get one of these, not just like, here's how to put the bits on the wire.
[00:57:57] Ian Swett: Yeah. Alan, is that response to Colin or is it
[00:58:01] Alan Frindell: More or less. I mean, one thing you said in the maybe it on the second slide, but it the message is unilateral, but all the use cases we have for it, for this for the most part, are informing the subscriber that something they asked for has now happened.
[00:58:14] Will Law: Yeah.
[00:58:14] Alan Frindell: So I was like, I told you to switch from, and then you get a message that's like, oh, I switched from now. Or I'm doing SSTS and, like, oh, you're I switched tracks for you. Or so it's not like I just randomly or the other one is top end. I switched I set your forward to zero because you fell out of the top end. Like, these are all use cases where it's not the publisher acting without the subscriber's intent. And we can I don't know? Remember the PR I wrote very quickly the other day, so I don't remember if it says that. But I I think that's relevant to be like Sure. We we're not giving a blank check for publishers to just, like, run roughshod over whatever the subscribers ask for.
[00:58:45] Ian Swett: Yeah. Yeah. The word unilateral might have a connotation that's slowly incorrect here. Sorry to jump in,
[00:58:51] Colin Perkins: just on the same thing. I mean, I I makes sense to hear what you're saying. And and but I think we should write down those and think some of those. Because if we have a situation where you've got a million tracks and you're and suddenly, you've changed the you know, you've turned a whole bunch of them. You've switched the state on them. Like, that doesn't work. This will just completely collapse the control channel. Right? So we have to be clear. I mean, we have to be able to think through this and make sure that this doesn't create a huge amplification of some sort.
[00:59:20] Alan Frindell: So it's it's not the switching itself that you're concerned about, but the control message that comes from the switch?
[00:59:25] Colin Perkins: If if I'm switching between a a very large number of tracks, they'll just happen and I get I only get the data for the tracks I'm actually receiving. But if suddenly I start getting notification messages about updates of what's going on, that might be great. I generally like that. As you know, I like to understand why something changed. I'm a
[00:59:43] Chairperson: big fan of that.
[00:59:44] Colin Perkins: But not if there's an opportunity for it suddenly to for me to get a million updates at once. That would be a bad bad scenario. And I don't I don't know that it's in that. I think we just need to define what what it is what type of what specific use cases we use it in, and I expect I agree with all of them. But we need to sort of talk about that and think through whether there's any problems with that type of problem.
[01:00:09] Gwendal: Yeah. So for switch from, this is very good. So we definitely for switch from, this is very good. So we it's it's something which is necessary. Just a clarification question. The new message, it is on the bidirectional stream of Yep. The subscriptions. Yep. Right? And so if it is a subscription which is with four one, it got zero, it it's still open. Right? The
[01:00:40] Alan Frindell: Like, can change forward from minus zero.
[01:00:44] Ian Swett: Or vice versa. Yeah. Vice versa. Okay.
[01:00:46] Alan Frindell: Okay. Yep.
[01:00:49] Moezanati: Moez Anati, Cisco. The, I think this functionality is is very useful. Probably something we overlooked early on. Really needed for the top end track filter switching because the unacknowledged messages are much much better for that. You wanted to avoid control message storms. So this reduces everything in half. That's great. Next slide. Just one little nit. Next slide. Yeah.
[01:01:15] Ian Swett: You want this one?
[01:01:15] Moezanati: Yeah. Oh, no. I'm sorry. Back. Okay. Maybe back back one slide.
[01:01:19] Alan Frindell: Yeah. Oh.
[01:01:20] Moezanati: That's the right thing. Publish notify is what it really is. Right? It's a publish notify. So what you said there in that first sentence is is exactly what what we need. It's a notify. There's no act. There's no it's only from the publisher. So I think that's a little bit clearer.
[01:01:35] Ian Swett: Yeah. Yeah. Notify is probably a better because update does imply action, which is not what is going on here. Yep.
[01:01:41] Moezanati: Yep.
[01:01:43] Ian Swett: Good point. Thank you for all the good commentary. Now let's go on to a slightly more subtle thing.
[01:01:51] Magnus Westerlund: All at the end, to be clear, to get good new new notes in minutes from this, summarize what happened with for issue 18 o three. Sir? What? Can you summarize the conclusions of the discussion we just held?
[01:02:08] Ian Swett: We are going to rename subscription state update to subscribe notify or something slightly more accurate. We are going to make sure that the PR text has it basically it's clear about what can and cannot be be notified and that you're not supposed to just, like, do this because you want to. It's supposed to be, like, as a result of a subscriber request. And I think Barton has an AI to ponder about whether this could make the published on case cleaner.
[01:02:45] Chairperson: Thank you.
[01:02:48] Ian Swett: Is that correct?
[01:02:48] Chairperson: I'll put something in the PR. So Okay. Yeah. Okay.
[01:02:56] Alan Frindell: Right now, when you receive a publish,
[01:02:59] Ian Swett: regardless of why it came, you don't know if it came from a subscribed tracks, and you don't know which subscribed tracks technically it came from, and you also don't know if it didn't come up from a subscribed tracks with the exception, weirdly, of forward and group order, which we make you include or I think we suggest you include. I can't remember. Which is sort of like so we basically take two parameters, but, you know, there's filters. There's a whole number of other things, priority, and so so so on and so forth that we don't have you include today in publish. This is sort of, like, an odd state of the world, but because it's difficult to know exactly what the state of the publish is. Even if you do subscribe tracks today, you might update subscribe tracks. And so, like, say you switch from forward equals zero to one or vice versa, and you get a publish, like, I wonder what state it's in. Wouldn't it be nice to know if you actually were gonna get data? Seems like a problem. Yeah. So maybe it's not important to know, and you can just figure it out from context. This seems a little scary to me. But is it important to know which subscribed tracks caused the publish, if any, is one question? And if so, do you need to know exactly, like, which version of the subscribed tracks and what the subscribed track state was? If it didn't come from subscribed tracks, so let's say, you know, video ingestion type publisher use case, do you need to know the parameters, or is the assumption that the original publisher is just gonna send you what they wanna send you and you don't really have any control over it anyway, and so it doesn't matter. So is it okay to specify the initial parameters in publish and just instead of saying today, say you can put forward and group order in publish, but you can't put anything else. We could say you can put any subscription parameters in publish, and then you would be able to communicate the full state of publish. For the most part, the and I think that's maybe for every case, but I can double check. The parameters are not ambiguous in in the sense that, like, you know, if it comes in a publish, it's clear that this is the state of the subscription is it doesn't conflict like subscriber or publisher. There's the issue, which I think maybe Moe brought up last time. We discussed this. What if you get parameters in whatever way they are conveyed that don't match the corresponding subscribe tracks? Do you have to check for it? Is that an error? Is that just annoying? Is that a bad relay? Like, how do we feel about that? And finally, should we just remove every all the parameters from publish? But if you wanna send a subscription state update, you can and reuse the message we just had, which is, like, an FYI of, like, here's the state of the world. There are some other solutions in this space, but kind of these are the questions slash solutions. What are people's thoughts? I think I think we should be able to, like, get to a solution to this problem, and it's just a matter of, like, there's a lot of spellings. I think a number of things might work. Colin, I believe, is first.
[01:06:12] Colin Perkins: I'm still pondering all of this. Very interesting. But I
[01:06:15] Ian Swett: was gonna just
[01:06:15] Colin Perkins: say, what's it's almost a trivial comment, but, we do get an indication of how to map it. You're you know the namespace that the subscribed's track was to. And assuming you weren't doing overlapping ones, that's what we've been using to understand what the publish maps do. I'm not saying that's my favorite way to correlate to to to do it is compare strings. I hate comparing things.
[01:06:36] Ian Swett: That's probably the least problematic question on yeah. I agree. Yep.
[01:06:40] Chairperson: Martin, do Google. Yeah. So the overlap solves a lot of problem, but it doesn't solve the request update problem except for group order because group order can't be updated, which is good because there's no group order. The there's a group order track property that comes in. It's all okay. Alright. Let me zoom out for a second and say that, like, we're in dire need of a table, all these parameters, because, like, some of them go in certain request types, some of them are only in certain response types, some of them can be updated, some of them can be update ok'd, And, like, we need, a chart, and I would prefer to just be able to ignore rather than error on, like, unnecessary parameters. We should also talk about that or decide on that one way or the other. So this is a mess, and, like, I and, like, this is just an indicate I think if if we actually write this down in a in a coherent way, it'll be easier to reason about because right now, there's just this thicket of of things.
[01:07:48] Ian Swett: I I agree it's a little confused right now. I don't think it's a complete mess, but but but, yeah, we're not in this optimal state. There's a few other things that I'll highlight later where we're not
[01:07:57] Chairperson: in an optimal state. But yeah.
[01:07:58] Alan Frindell: I think the right answer I mean, I don't love I think there's a there's no great answer, but I think just sticking the parameters in every publish is, like, the simplest, most straightforward thing that can't really go wrong, and we should just
[01:08:13] Ian Swett: do it. And just specify which ones can go and publish and then for
[01:08:16] Alan Frindell: I mean, we already and please don't anyone go file an issue about making a table because there's already an issue about making a table, which parameters go where. So we know. We'll fix it. Okay. After we get the wire image done, we'll make it easy to read.
[01:08:29] Ian Swett: Sure.
[01:08:30] Michael Hosnas: Sounds good. Mike Rosna, CDN 70 7. I would just like to point out with all the extensibility we are talking now about now about we probably shouldn't solve this with, like, writing down all the parameters we have now or tables or stuff like that because this need to work in, like, general case for any parameter we will have in any extension down the line.
[01:08:51] Ian Swett: Yeah. I I think we're going to end up with a list of parameters which are, quote, unquote, subscription parameters, which, like, modify the state of the subscription, and those will be, like, allowed on basically subscribe, publish, and request update is my expectation. But that's me. There might be an exception. Well, my asterisk, except when indicated otherwise kind of thing.
[01:09:18] Moezanati: So if you have if you have more limits on what can actually go in subscribed tracks, would that help? If we were tight about what parameters could appear on subscribed tracks, would that help? Or there's already enough that this is
[01:09:34] Ian Swett: No. I don't think so. Because filter, for example, can go unsubscribe tracks, and that's actually useful and, like, it'd be good to know that. I I don't think I think we're I think that cat has cat is out of the bag.
[01:09:45] Moezanati: Okay. Yeah. So I just it just seems it seems weird if we have to echo back everything in the publish because there could be a lot of stuff. Right?
[01:10:02] Ian Swett: I mean, these are parameters. They're not properties. Hopefully, people, when they're sending a subscription, are sending a moderate number of parameters. I can see properties getting pretty darn big because of auth hashes and crypto stuff.
[01:10:16] Moezanati: But So is the favorite direction not just to echo everything back in the publish that the current state of the publish? Is that the direction?
[01:10:22] Ian Swett: I think so. Yeah. Yeah. There's a separate PR for not echoing back properties in case you
[01:10:29] Chairperson: So we also echo the auth token?
[01:10:35] Ian Swett: That's a great example of a thing we wouldn't need text on, Martin. Thank you. Can you can you make sure that makes the notes? Yes. That's a great example of something that would be dumb.
[01:10:48] Suhas Nandakumar: So how's Cisco? I I think I I agree with Alan here. And and that that keeps the origin publisher puts in properties because it owns the tracks, and it knows what it wants to do. It puts the properties and sending it as it is makes more lot of sense. Another auth token itself, we need to think there is a read token which subscribers will be will use, and there's a write token that the publisher will use. So at some point in time, the relay would not, for example, echo the auth token if the from the port that came from the publisher. It basically is looking at this downstream and saying, like, is allowed to participate in that reading of the track. Yeah. So in that case, I I don't think so that that's that that's owned by publish. It's owned by the subscription that created it. Yep. So those kind of things kind of leans towards the point that what Alan was proposing is simple. For all, if we want to optimize later, we can do it, but it's easy to reason about.
[01:11:41] Jordi Cenzano: Thanks.
[01:11:42] Ian Swett: Okay. Thanks. I mean but, yeah, that great example of something that's not just echoed back.
[01:11:47] Alan Frindell: Yep. The I didn't get in the queue, Lorenzo made a comment in chat, which was about the subscribed tracks reference. Like, do is it at all useful to have how badly do people wanna know this thing came from the subscribed tracks?
[01:12:00] Ian Swett: Do we I can't remember. Do we allow multiple subscribe tracks in the same namespace? We don't.
[01:12:06] Alan Frindell: We can't have them overlapping.
[01:12:07] Ian Swett: You can't have them overlapping at all. No. That end doesn't matter. Okay. That would be my opinion. If we allow them to be overlapping, it starts becoming interesting. Alright. Thank you. I I think then based on that, we will probably I'll write up a new PR for allowing parameters that make sense in publish and make sure that ones that do not make sense are not included. And eventually, we will add a table. Or if someone else wants to make write a PR that adds a table now, then they can do so. Or I guess AI can.
[01:12:43] Moezanati: Oh, just on that final point, were you asking about overlapping namespaces or overlapping subscribe and a namespace?
[01:12:50] Ian Swett: I I was I was specifically asking, is there a case when you could receive where you could have two subscribed tracks and the same track could come to
[01:13:00] Moezanati: you No. That's as a result of and
[01:13:01] Ian Swett: and the answer is no.
[01:13:02] Moezanati: But for pinning, we do have a subscribed tracks of a namespace and then a subscribe in that namespace also.
[01:13:08] Ian Swett: Yes. That's fine. Okay. Yep. That should be fine. Wonderful. Thank you. Track aliases. When can you we reuse them or not? Okay. So currently, the text makes it very clear that for the same track, you can definitely reuse the same track alias. So, you know, you do a subscription, then it ends, then five seconds later, you do a new one. It's totally kosher to use the same track alias twice. In other cases, we also allow it, and we don't really say too much about it. Depending on raciiness and such, maybe it's a little bit tight. On the other hand, it does allow you to reuse one byte. Track aliases, which for some uses is, you know, maybe the extra bit or two, like, matters. There are three options in my opinion. One is status quo. Allow it. And, you know, if people wanna shoot themselves in the foot, then they could do that. Two, add some slightly more cautionary text. Like, you probably shouldn't do this unless you really know what you're doing. And, of course, that should not is one of those classic you can if you really know what you're doing, but, you know, we think it's a little dangerous. And so it's not in practice that different from option one as being cautionary. And then the third option is say, you must not, and we actually might enforce it if we detect it. Obviously, there would be no obligation to detect it. And that's it. And, Colin, go for it.
[01:14:43] Colin Perkins: I I I think for me, it's very important that we're allowed to use it in the case where it's the same track name.
[01:14:48] Ian Swett: Yes. We're not changing that.
[01:14:49] Will Law: Yeah. Okay.
[01:14:50] Ian Swett: That's not
[01:14:50] Chairperson: on the table. Okay. Thanks.
[01:14:52] Ian Swett: Not even nope. So it's this is only about if it's a different track, like, do are we just YOLO or which is status quo, basically. Or yeah.
[01:15:04] John: Java Linux, is there a way you can know that all previous things of the previous use of that track alias are done so you can safely reuse it, or could they be buffered indefinitely?
[01:15:15] Ian Swett: You can know that all you can know that all streams or datagrams have been closed and or sent for that track alias before using it. You can't guarantee that they're never delivered because, you know, the Internet delays. Mean, I there could be some middle box that stores out a hard drive and replace it a year later. I mean, I don't know.
[01:15:37] John: I mean, yeah, I mean,
[01:15:39] Ian Swett: if you know that everything with the quickest you know, all the quick streams are gonna be sent on are closed,
[01:15:43] John: then I guess it's couldn't I
[01:15:45] Ian Swett: don't know. It seems like
[01:15:49] John: yeah. If you can't know
[01:15:50] Ian Swett: that it's safe, then it's not safe. But the question is, do you care?
[01:15:56] Alan Frindell: Alan Frindell, I I think we should let peep there's probably somebody who's gonna want that one bite and Maybe even two bites. Yeah. And, like, I feel like handing them the foot gun is just fine. Go ahead. Okay. Like Okay.
[01:16:11] Ian Swett: Do we need any cautionary text about said foot gun or, like I can't remember. I don't think we have any right now.
[01:16:17] Alan Frindell: We can add something editorial if we really feel like it, but oh, and the other thing I wanna mention, you you can know that you received all the streams because publish done has a stream count in it. You can't we could put a datagram count in there too, but what do you do if it says, like, yeah, I sent you a million datagrams and you got 999,000 of the layout. Where are the other ones? Are they coming? Are they not? Could you get them later? Like, you'll never know. So it's just Yep.
[01:16:43] Colin Perkins: I can't get in the queue, but I I think we should at least have enough text that people who review the draft don't open a new bug to tell us they found an issue with it.
[01:16:54] Ian Swett: I think that's a good point because I think we thought we were done with this. Okay. Wonderful. Then we will add some editorial text to make sure that no one opens this issue ever again and caution about how it might be dangerous. Okay. Eight sixty nine, limiting resource consumption of a subscription, aka flow control. So revisiting this just briefly and deciding what to do about it. If anything, prevents one's subscription from starving others is the main goal, particularly using quick flow control. That's not really practical because it's not subscription or anything oriented. Also, it might limit buffering for unknown subscriptions. I filed the issue in the DDoS repo, but there are cases it's a little tricky to, like, know how much data to buffer for an unknown subscription. And, you know, you have to have heuristics anyway, but, like, if you could just say, like, I'm not gonna buffer more than two megs for an unknown subscription until I actually know what the track is associated with, it might make the logic a little bit more reasonable to implement. So the main negative of adding flow control is nested flow control stinks, and no one likes it. And managing it, it can be difficult. But you could also allow endpoint or an endpoint could set a fairly generous flow control at the quick layer and use MOQ flow control as the primary source of flow control, which I think some people have kind of indicated they thought they were going to have to be fairly relaxed about their quick stream limits and buffer limits to make MOQ actually function well anyway. There are other approaches discussed in the issue, but streams and bytes seem to be the things that are limited in quick. And so it's still my thinking that probably that's where it makes sense to start.
[01:18:48] Chairperson: Victor, go for it.
[01:18:52] Victor Vasiliev: Victor Vasili of Google. As usual, when describing slow control with subscriptions, my answer is you do not need slow control for subscriptions. And if you're doing it, you're doing something wrong. So let me explain why. Fundamentally, subscriptions is like, if you don't have enough bandwidth to consume something, you do not subscribe to that. Now the concern here is not just that, but also that there are some subscriptions that will starve to others. And I will point out that this is mostly an issue with priorities, which is to say, under most circumstances, you should have clear idea of what your priorities are. If and if the higher priority subscription starts off the lower priority subscriptions, that's not just side effects. It's the desired goal of the protocol. It is less clear to me whether this what this means on relays, but I guess publisher priority applies for publisher to relay flight, and we're technically held that relays to relays are out of scope.
[01:20:08] Ian Swett: Alright. Colin, did you wanna comment on that?
[01:20:14] Colin Perkins: I I can't believe why I'm gonna say this, but, like, you know, Relay is gonna do what Relays do. Like, I I I'm sort of poking around wondering how much this is a quality of implementation issue and how much this is something we do need to comment on. And I I I don't have a strong opinion, but I I'm I'm I I do feel like they're going to have they're gonna have all kinds of extra policy information about the different types of subscribers and different types of things, which might change how they prioritize their internal use of bandwidth. And this is gonna be hard to control from a client endpoint in a way that is acceptable. I don't know. I'm just trying to get my head around how I would implement that or, you
[01:20:56] Ian Swett: know Yeah.
[01:20:57] Colin Perkins: Not how I'd implement this, how I'd merge this with the other constraints.
[01:21:01] Ian Swett: Yeah. I mean, when I originally thought about this, I was mostly thinking about it from, like, a Relay's upstream perspective where, you know, you have n subscriptions on behalf of n different clients or you know? And so you wanna, like, ensure that none of them are starving any of the others. And, like, if one of them uses the last stream from the other one, then, like, we're really sad. But that might be a quality of implementation problem more than anything else.
[01:21:25] Chairperson: So. Martin Duke, when you say optional, optional for who?
[01:21:33] Ian Swett: Do the sorry. You don't have to set a limit. But if you do set a limit, yes, the sender has to respect it. Okay. Sorry. It's optional for the
[01:21:44] Chairperson: subscriber. Alright.
[01:21:47] Ian Swett: Because because limiting how much you send is not really very hard.
[01:21:52] Chairperson: Yeah. I this seems like a giant new mechanism, and, like, the reason I ask if it's optional is I'm tempted to, like, say, maybe there should be an extension. Yeah. Yeah. That's fine. No. It doesn't save any editor bandwidth, but it does mean that if, like, this is not baked, then we don't we can still ship mock tea without it. Sure. I can certainly without this. I I think other people can too. Sure. Yeah. Thanks.
[01:22:19] Moezanati: Mozzanati. I I wondered what, about what Victor said. Could we use priorities? If you close credit to somebody, is that equivalent to dropping their priority to the lowest? If I close your window, is that the same thing as I just I give you priority
[01:22:36] Ian Swett: two fifty five? No. Because if you say if I say if you you give me a 100 streams of credit and I have 10 subscriptions, I, you know, I can say, like, you know, each subscription only gets 10 streams max at once to make sure that, like, no one stomps on I mean, that's an extreme case, but, like or simplified case, but no one stomps on other people's, like, stream usage, things like that. Because, like, you can kind of run out of number of resources here. And so it's not purely prioritization in terms of bandwidth. It's partially just, like, you can run out of other resources. So it's a lot it is partially about buffering though, for sure, which is why, like, I tend to think of it as a issue that is more likely to hit relays than not relays.
[01:23:20] Moezanati: I guess the real concern would be if if if a particular track is opening many streams, that's the real concern. Because it seems like you can everything else you're gonna stop with priorities. I can stop your flow with priorities, but if you just would start going nuts opening streams on me, that that seems like the troublesome track.
[01:23:36] Ian Swett: That that is a particularly troublesome track.
[01:23:38] Moezanati: Yes. And there's no no way around that without having a per subscription stream limit?
[01:23:45] Ian Swett: Right. Yeah. Especially if you do, like, object per sub group for, like, enhancement layers or something, you can burn through streams in a real in a
[01:23:52] Will Law: real way.
[01:23:52] Moezanati: Can we make it only a stream limit, not a data limit?
[01:23:56] Ian Swett: Sure. We could.
[01:23:57] Moezanati: This seems like with priorities, could you could mitigate the data issues, but the stream issues are are hard to hard to stop. That's a fair point.
[01:24:05] Ian Swett: I mean, I think for a number of use cases, yeah, like, you're gonna burn through a lot of streams right now, which is fine. But yeah.
[01:24:13] Antonio: Antonio Cloudflare. Have not been following this one too much, but the situation of, like, someone setting flow control down to zero, subscribing to something, falling behind. Eventually, you have to actually terminate them in some way to actually prevent you from having problems. Is that really related to this something you should be making sure to actually, like, have somewhere in there encouraging people to actually get that right?
[01:24:39] Ian Swett: We we have a too far behind error code that you can give if, like, someone gets too far behind. So unlike HTTP where you're just stuck buffering it and, like, indefinitely, there is kind of an out. So okay. I think my takeaway is maybe an extension draft, although maybe people wanna see a PR for only streams. Is that would do people wanna see a PR for only stream limits? Let me ask that question.
[01:25:11] Alan Frindell: We I mean, there's already two different PRs for this. We can easily strip out the bytes. Sure. If somebody wants to see the PRs are there. I I I don't know. My read of the room is that nobody's enthused about doing this right now, but they kinda think maybe they might need it. So I feel like we should just maybe move to an extension. You know, let's just publish it our our idea as an extension.
[01:25:31] Chairperson: I am.
[01:25:32] Alan Frindell: Is anybody upset about that plan if we
[01:25:34] Ian Swett: Put in put in an extension. I have something else I wanna pair this with in an extension because it's fun. So, like, it'll be fine.
[01:25:40] Alan Frindell: Okay. Maybe you're sad.
[01:25:43] Colin Perkins: I mean, if you need this, you need this. I mean, it's been the base. It can't be an extension. Right? So I think we need to figure out what the case of this is. And I I'm again, I'm I'm reading it for the first time, so I'm sort of Sure. And I I my read of the room is no one read it. Right? Like, that's
[01:25:58] Ian Swett: that was kinda what happened previously, and I was hoping someone would read it before now.
[01:26:03] Alan Frindell: I will say we have this although Ian and I won't be here, but you guys are gonna be here tomorrow. So you you can spend all night reading these. They're not that long. Go read the PRs. Like, come back, talk about it tomorrow if you want.
[01:26:15] Will Law: Yeah. Okay.
[01:26:20] Ian Swett: One. Ah, one near and dear to my heart. Today, there are some things you can update with publish okay. It turns out only one of those things I think is safe in retrospect, and everything else is a little sketchy. And so my proposal is you have to use request update immediately publishing following a publish okay instead of being able to put the the updates in the publish okay. And at a high level, the explanation is every other time you do an update to a subscription and its date, it's like request response. And so one of the things you get back, for example, is largest object. And so for, like, setting forward equals zero, if you set forward equals zero today and publish okay, you don't actually know what the largest object is coming back to you is, which maybe for some cases, that's okay, but it's also really awkward. But it this is sort of just like an edge case that we allow this. So I think we currently allow location filters, forward, and priority. Location filters are also problematic for a similar reason that, like, you need to know where you know, what, like, next group or something are. So the simple there's a PR. The simple proposal is don't allow publish okay to update state. Just put it in a request update, which can be literally in the same packet as the publish okay. And that means you actually get a request okay in response, including location, our largest object, or any other things that need to come back with it. The goal here is just to simplify the state machine. So
[01:28:00] Suhas Nandakumar: So, Cisco, I I think that's a good good design to have. And I like the fact that because we are sending the request update right behind publish okay, it's not wasting RTT or anything there. Yep. Yep.
[01:28:13] Ian Swett: Alright. Thank you. Does anyone object to this? Okay. I'm gonna move on, and then ah, we're at Allen. See? I gave you plenty of time.
[01:28:31] Alan Frindell: We made it out of time. We have some, like, bonus slides from Will even. We might get to him. We'll see. Which token caused the error? So requests can carry more than one auth token. And request error, there's a request error code or two codes that talk about tokens. One that says it was malformed and another one that says it was expired. But the error does not tell you which of your tokens could have triggered that problem. If you imagine, like, the HTTP equivalent, you might that forexx, you know, would maybe could have theoretically used a response body or something, but our request error, like, doesn't have a way to carry that. So do we need a conditional field in request error that, like, if you got one of these two tokens, then we also include additional information about which which one? I don't know what the alternative is. We could do nothing. We could use I don't know. I have no idea. Colin, I thought you would have an opinion.
[01:29:29] Colin Perkins: I I and this is in the how we spell it category, which I generally don't care about. But, like, the tokens are big. You could put an integer that was, like, the third token got this error or whatever. It could be that we need to change the token message a little bit so the tokens are named and you get back the name of the token. There might be other reasons for doing that so that things could know which tokens they were looking for. I don't know. I think there's a few things we could I I I think we I think we need to solve this problem somehow. That's obviously, I filed the bug. But, I don't I think there's a couple of different ways we could spell this that were all pretty easy.
[01:30:04] Alan Frindell: I agree. I guess I'm a little bit just looking for some spelling grade. Like, do people say, like, yes. We this is a problem we've gotta solve, and we've got let's let's solve it by making request error. Have some field for it. Martin Duke.
[01:30:18] Chairperson: So if there are three tokens and one of them fails, is that a successful request?
[01:30:27] Alan Frindell: Not if you got a request here that said expired auth token. The I think the use case, Martin, is, like, some people might have tokens that are valid at different CDNs. And so I might have two tokens, which the other guy was like, I can't even use these. They're not for me, but the one that I care about is malformed. I think that's the I don't know. Maybe or maybe I can I can also just punt this to the off design team? I was trying to take out an easy issue,
[01:30:51] Jordi: but maybe a fail be not well, so,
[01:30:52] Chairperson: I mean, I I guess I imagine that if any of if I send you three tokens and one of them is good, I think that's successful request. And so, like, why would I or they're all bad, in which case they're all malformed off tokens. Right? So I I I feel like this is I'm not an auth expert. I'm not definitely not on the auth design team. This seems backwards, like this whole
[01:31:18] Magnus Westerlund: But they could contain different claims. That's, I think, is the point. So the the ones that contains the claim that you need to execute the operation is might be what's blocking. And or malicious or expired or whatever. It's it's it's like something is wrong with the the one which should give you the right to do it.
[01:31:38] Chairperson: So you need one of them, and you only wanna make the the requester replace that one rather than all of them. Yeah. Okay.
[01:31:51] Colin Perkins: I'm agreeing with Martin here of that, you know, we we have this design that I think that the auth team has talked about the this a little bit. I don't know. I'm not claiming there's any agreement on it, but I think at least some of us, myself included, think that as long as there's one token that is a valid token and covers the scope you want, then you allow the operation. It's an or of all the tokens, not an an and. Right? And one of the cases that's really important in these types of tokens is you're moving from version one tokens to version two tokens. Half your half your relays don't even know what a version two token is. It's an in it's an in it's a malformed off token as far as they're concerned or a token that they can't certainly can't parse. But you want your clients to be including both tokens so that you can have a migration process, right, from one type to another. This happens all the time. So we gotta make sure we don't break cases like like that and we have some way of dealing with it. And, I mean, I you know, after this discussion here, I I think that my filing my my issue is woefully inadequate and just needs more text.
[01:32:55] Chairperson: Yeah. I thought I thought about it. Like, it seems like a minor optimization to let just tell the client which one is doing, and I think this opens up whole range of questions, like, if multiple tokens fail? And I would I would do do nothing. Thanks.
[01:33:09] Alan Frindell: Oh, you said do nothing?
[01:33:10] Chairperson: Like, delete oh, okay. But Do not do not change it.
[01:33:15] Alan Frindell: Is that gonna work for you, Cullen? You filed the issue.
[01:33:18] Magnus Westerlund: Yeah. I know.
[01:33:18] Colin Perkins: That's nuts. I sent five up I sent I sent five tokens up, and then the request got back failed. What what do I do? Like, I what do I even even if I'm not gonna do anything, what do I log in my messages to explain and debug what's going on? Like, we've gotta get more information about back about what caused the failure. Right? Particularly I mean, even even even just the expired things. Right? Like, say my clock's a little bit time shifted with the other one. I you know, we need to understand these things. Like, we've gotta understand what went wrong. Okay.
[01:33:48] Alan Frindell: I I I think Mark,
[01:33:49] Colin Perkins: like thought you agree with me.
[01:33:50] Chairperson: So you so you know there's an off failure with one of your tokens, which is not so, like like, worst case, if there are five tokens, maybe you if you're completely ignorant about your tokens, you're renewing all five of them, which seems like a like, not optimal, but not disastrous. I I mean Look. Let's say
[01:34:11] Colin Perkins: the problem is is one of my tokens has a syntax error in them, and the only error I get back is is auth error. The only thing I can do is refresh all of them and try my request again, which will instantly fail again. And I will do this as fast as I can repeatedly slamming the relays. Like, that's that's not the right design.
[01:34:27] Alan Frindell: Well, there is a retry
[01:34:28] Colin Perkins: what I will do if that's the only error.
[01:34:29] Alan Frindell: Request error does have retry after. So if the relay doesn't want you to come back that fast, it'll tell you. But
[01:34:35] Chairperson: but how does knowing that token 4 is failed tell you that there's a syntax error and how to fix the syntax error?
[01:34:43] Colin Perkins: Well, knowing whether it was that the the token was expired token 4 was expired and I needed to refresh that and could try again is a very different thing from token four is malformed and you need to Well, we probably not retry. Right?
[01:34:56] Alan Frindell: That we do have. Right? We have the codes that tell you it wasn't malformed or it wasn't expired. That much
[01:35:00] Colin Perkins: you will learn. Well, I mean, even that's really unclear when you have different errors on two different tokens at the same time. And I'm fine when we could just take the first one, but, like, all like, I'm just getting this you know?
[01:35:10] Alan Frindell: I I'm happy to short circuit this discussion by adding an integer and moving on with my last.
[01:35:13] Chairperson: I've said enough. Do
[01:35:19] Gwendal: care, and I believe that we need to have an indication of which token failed.
[01:35:24] Chairperson: So
[01:35:25] Gwendal: And we could also notice that we only have two errors, but many of the claims can be wrong, like geolocation, typically. And so I don't know how it is indicated today. And so, potentially, we should also name the claim that fails the the tokens.
[01:35:50] Alan Frindell: Okay. If it if it I'm gonna give two two options here. Option one is we put in an integer. Option two is I punt the entire thing of the design team, and they come back and tell me that I need to have, like, 17 fields that, like, tell me all the different things that could possibly be wrong.
[01:36:09] Gwendal: Well, if it is with, the cat token, we have the CTI to transport the indicators of the token which has failed, and we could have the the claims key.
[01:36:21] Alan Frindell: I mean, the thing is, the MACT supports two to the 64 token types. So I don't know what's gonna be in any of those.
[01:36:27] Gwendal: But what is very good that I am not in the design team, so I'm very happy to give them the one.
[01:36:32] Alan Frindell: Okay. I think this may already be in the list. But, anyway, Mike and Colin, you have inherited this one. I'm I'm not gonna touch it. Have fun. Prefer my structured mock t query space. Okay. So back to our mock t URL. So we the mock t URL follows the HTTPS URL, which does not define any structure of the query beyond what thirty nine eighty six syntax and the percent encoding rules, which means, like, you know, people are very con used to seeing query strings that have, like, name equals value and name equals value. Well, that is application x w to reform URL encoded, and it's really just a convention. Even HTTP does not require that be the only thing that you do. It's just what people do. So we do have a requirement that a mock t URL be convertible into an HTTPS URL because you don't when you send your client hello and you say, well, I'm willing
[01:37:30] Ian Swett: to do web transport or
[01:37:33] Alan Frindell: raw mock, then you if it comes back, it says, great. We're doing we're we I picked h three. Like, you need to be able to send this URL over HTTP. So that's data. And then so do we wanna put any requirements here, and should any part of the key namespace be registered in some sort of first come, first served table? So I'll also note that HTTP does not do this. So, basically, the query space is owned by the resource. Like, whatever the host name and path is, it gets to define whatever the query string means to it. And so that is not something that HTTP does. So opine away. Colin?
[01:38:15] Colin Perkins: I'd be happy to I would have been happy to present this bug. Oh. But the You're welcome. If you
[01:38:20] Alan Frindell: have more or do you wanna say?
[01:38:21] Colin Perkins: So, please. I mean, I think the the the the thing that HTTP obviously doesn't do this. And I think that we've learned in HTTP that that's sort of depressing at times because it means you don't have a common way of knowing you might be able to merge two different things together. So if a given resource wants to implement some, some way of using the this space, right, and one wants to do it one you know, one one wants to do it one way and one wants to do it the other way, there's no really common way clear way to merge them together. You you could have conflicts. Now we have come up with a convention that many things use, which makes it easier to converge those things back together. But since we're defining a new spec and a new thing here, we could just say, you know, you must use this convention, the the normal sort of convention you often see on HTTP. Right? And that doesn't caught the fact that we say in a mock URL, it has to sort of fit this syntax, that would give us a lot of flexibility in future things and that we can have more than one application or usage thing that's trying to put things here instead of only having one that can define what goes there, which is what happens in HTTP. So I think this gives us a bunch of flexibility for something that we wish we had in HTTP and we didn't because we didn't define it the beginning. I don't think it causes any problems in mapping it, to HTTP URLs because what we're proposing is totally valid for HTTP. And it just it it's just sort of saying, instead of having this de facto convention that you can't count on working, in HTTP, we it's not a de facto. You can count on it working in in mock. And it doesn't it's not like it's gonna limit what people can do in any way. They can still do you know? I mean, everyone could restructure their data to be in that form. So it seems like super low cost to us, and it gives us a bunch of flexibility down the road is what what I'm thinking. And that's that's sort of where of where I where I think it's this is valuable for extensibility. And the fact that HTTP doesn't do it was you know, because it couldn't, it didn't define it early enough.
[01:40:33] Alan Frindell: Would anybody else like to comment on this issue?
[01:40:37] Magnus Westerlund: I I run this past Ted for the URI aspect, and maybe ask the HTP director from the if they have any feedback from the HTP's perspective. But
[01:40:50] Alan Frindell: yeah. For whatever reason, I cannot understand what the chairs are saying, so I have to look at the transcript.
[01:40:56] Moezanati: It comes out quick.
[01:40:57] Colin Perkins: I mean, totally fair to do that, but I don't think that they will have any they're just like, well, this is a further constraint on some bytes we were already fine with. Yeah. So it seems unlikely. I mean, definitely worth doing, but I
[01:41:09] Alan Frindell: I see an HTTP technical expert at the mic Yes.
[01:41:12] Mike Bishop: As well. So this is something Mike Bishop, this is something that we have seen in a couple other instances. Core has their compact CRI thing that defined a an optimization if your URI happens to have key equals value pairs. And constraining the space here should be fine. And, I mean, particularly if the equals is optional, if you have something that isn't key equals value, you just have a very long key and no value. So and defining that it gets interpreted that way, sure. That should be fine.
[01:41:54] Alan Frindell: Are are you saying this is okay or yes, you should you should grab the bull by the horns
[01:41:59] Mike Bishop: and do this? I think this is fine and it's probably useful. Okay. So long as your requirement is that mock t URIs be convertible to HTTPS and not the other way around.
[01:42:14] Alan Frindell: I know less about if there's if that's a requirement.
[01:42:16] Mike Bishop: But Because, like, if if you require this, there are potential h t p URIs that then would not be valid mock t unless you unless the equals is optional. And I don't know the encoding specifics to know whether it is. Mhmm.
[01:42:33] Alan Frindell: Alright. Thank you.
[01:42:38] Magnus Westerlund: Go ahead.
[01:42:39] Michael Hosnas: Michael Hosnas, c d n seventy seven. Would we expect the clients and servers to now must understand this and parse it?
[01:42:52] Alan Frindell: I mean, none any more than an HTTP server already. I mean, if if it's an HTTPS, you're an HTTP server.
[01:42:57] Colin Perkins: It it wouldn't change that in any way. But if you were writing an application that required you to look at this in some extension or some other thing, then, like, yeah, you have to be able to parse whatever you define. But no.
[01:43:08] Michael Hosnas: Then I have questions about scope.
[01:43:11] Alan Frindell: Oh, yes. It's all part of the scope.
[01:43:15] Chairperson: Especially
[01:43:17] Michael Hosnas: about the case if I have, like, two same key value pairs but in different order, should they be the same scope?
[01:43:24] Alan Frindell: That's such a spicy question. Reminder that a mock t scope is defined by its connection URL, and that includes the path or which includes the query. So
[01:43:40] Colin Perkins: Sorry. Just a minute. Maybe we're talking about different things here, but that's
[01:43:49] Alan Frindell: Are you talking about aft what's after the fragment? Because I'm
[01:43:52] Colin Perkins: talking about what's after the fragment. You're talking about the the fragment. No. No.
[01:43:55] Alan Frindell: We're we're gonna I'm I'm thinking Sorry. We made progress on an issue that was not the one you filed.
[01:44:05] Magnus Westerlund: This is clear.
[01:44:06] Alan Frindell: Yeah. I think I should probably just punt on this. I think we got some feedback. We'll have to revisit this, and maybe, Colin, we can get a little bit more info in the bug about what you're hoping to accomplish. Okay. There is this text in the draft about the relationship between mock t versions and extensions. It's there's two sentences. One says, new versions of mock t have to say what existing extensions can be used with that version, and which I think is around, like, I don't know if we mean this sort of reads literally. Like, I have to go find every extension in the universe and enumerate whether it's gonna work or not. Or perhaps we could maybe mean something more general, like, because mock t version two has the same is more or less wire compatible, anything that worked with v one will work with v two. Or if we change something about, I don't know, the object model, we might say, okay. Any extension that conformed to this constraint would work. I think that's what we're trying. The other sentence is new extensions must specify what versions of MACD they can be used with. So if I come up with cool extension one, and I can say this works with MACT v one or anything that is wire compatible with MACT v one. And then, I don't know, or say we we've already published four versions of MACT and then some I come out with an extension, but I only work with the latest version. My you have to be on mock t four because we redid the object model to be something else or something. So, several questions. One, do we like, how do we feel about all this text? I'm pretty sure the second sentence seems good. I think the motivation is, like, just think about when you're writing extensions and future us writing updating the draft, like, think about your compatibility matrix. The issue also discusses something different, which is about what if we have a future version of mock t, which we think is going to we want it to require some extension we have also defined between now and that time. And and and what role does Ayanna play in any of this? I I think in that case, my my thought is, like, if there's, let's say, you know, cool extension one we want mock t v two to be like mock t v one plus cool extension two, then we should we will do one of two things. We will either say in mock t v two that you must send the setup parameter that enables that thing to some non zero value, or we will just take the content of that extension, and we will include it in Mach d v two. And so I'm not sure that we need this other thing.
[01:46:37] Rowan May: Hi. Rowan May. I consider myself a bit of a negotiation and feature version nut. Like, in that, I I like working on these things. I think those two sentences, I think, are good. I don't think Aianna should really play much of a part in saying this is for this version or whatever. I think that should be in the text of the extensions. It should be in the text of a new future version of the mock transport. And I wanna point out one very nice feature of the text that you have there, which is it is really, really useful to be able to deprecate either a, you know, an extension or just a property. Like, it you may wanna be like, this property was a terrible idea. I never wanna use it again. You wanna be able
[01:47:35] Chairperson: do same thing.
[01:47:38] Alan Frindell: It should be too priority. Thank you, Ron.
[01:47:41] Moezanati: Mosinetti, if by extension here, we mean setup option? Yes. Okay. So I think we should be explicit to say setup option because that's the thing that's actually gonna get INR registered. Right? The INA registry is set up options. Right?
[01:47:52] Alan Frindell: Well, okay. I'm sorry. The text where the text uses the word extension, I believe it's in the context of a broader like, an extension draft that may have a set up option of
[01:48:02] Moezanati: That that that's my problem is that we're not gonna register anything called extension anywhere. Right? If it if it uses five setup options, we register five setup options and that's what goes in INR. Right? We don't have an INR registry called extensions. That is correct. Right? So we're only talking about setup options Yes. A table of those. So that registry is just gonna have a column for v one, v two, you know, or something like that.
[01:48:26] Alan Frindell: Can we get it out of it that way? I think I see what you're saying. When in that the setup when you when you register a new setup option, you list the versions of mock t that you think it is legal to send them in. But then when we ship a new version of mock t, we have to go update that table to include all the ones we think are valid and Well,
[01:48:45] Moezanati: the INA table itself would have a column for each mock version. It would have a column that says versions or something.
[01:48:51] Alan Frindell: I mean, I'm I'm also trying I'm trying to avoid us having some future administrative headache, if possible.
[01:49:02] Moezanati: But I think I think the the mapping in this table should be the the mock setup options registry, and that you just have a column for mock version inside of that. And then it's up to the mock, you know, editors when v two gets published to go back at that table and add v you know, version two to all the extension to all the setup options that that are allowed in v two. A new setup option register, you know, registrars would add their row and figure out what versions they work with and have the right data
[01:49:33] Alan Frindell: in that column. That would work for me to solve this issue. I'm not sure if it works for everyone. I can't see who's next.
[01:49:40] Magnus Westerlund: Ian.
[01:49:41] Ian Swett: Ian. I was gonna comment. I I think in general, less is more, but in particular, like I mean, if we make a new version, we're gonna do whatever we want. Like, I don't understand, like, what the first sentence means. Like, I mean, us now is gonna constrain us from five years ago. Like, whatever. We're gonna publish the RFC we want. Like, I I don't know. It just seems kind of, like, bizarre to say that. But but the second sound seems sensible. Okay.
[01:50:09] John: So what is the registration policy for these things? Can I have a private one? And if so, does the new version have to tell have to specify whether you can still use my private extension?
[01:50:20] Alan Frindell: Not I mean, I think the I don't remember what the policy is. I'm sorry.
[01:50:24] John: That that sounds like a terrible idea. I think
[01:50:26] Magnus Westerlund: I've yeah. I agree.
[01:50:27] John: Version should specify which, you know, IETf defined things, but it shouldn't have to specify every extension that everybody ever thought of, whether they told you about them or not. So that first must seems like a bad must.
[01:50:39] Alan Frindell: I I agree. I think I'd like to change that first sentence to be something along the lines of, like, more generic, not trying to enumerate specific extensions.
[01:50:49] Magnus Westerlund: Okay. Individual comment here. From my perspective, I do think it's enough that the future version main specification tells you if they have any requirements on versions extensions, features, so to say. I think the setup is global across all versions, if I remember correctly. So these names are uniform across all versions of Mach T, as long as you call it mock T, because I think that's what's defining it. So but, yeah, I don't think there's any point of having an IANA table or something for a version which extensions I think the extension themselves should maybe specify versions, but and you have the table of versions that's been defined just so you can find them for the main specifications. So
[01:51:45] Jordi Cenzano: but Okay.
[01:51:49] Colin Perkins: Try and trudge way back in memory here of why well, this is when we're like, I think we were in Stockholm or something. We're trying to sort through how this worked is where it came up. So remind me so if an extension so let's say version one of mock t comes out, and after that, there's a new extension made, but this is long before version two of mock t's done or whatever. What's how is that signaled in the setup? I mean, if you want to speak the extension,
[01:52:20] Alan Frindell: you send like, you you negotiate mock t v one, and in your setup message, you have the setup option or options associated with your extension that say, I support this. It's not a new there's no mock t version that's specified. Like, for example, quick v one works with datagrams.
[01:52:36] Colin Perkins: So, look, I I I I I went looking in the draft right now. I I'm not sure I could find text on that's that's workable. I think maybe we should just update some text that says that I I can I can put some an issue for that? I should probably check more carefully whether that text is already there or not.
[01:52:52] Alan Frindell: Don't Sorry. What is the text you're suggesting?
[01:52:54] Colin Perkins: What you just said.
[01:52:55] Alan Frindell: There is a I would go read the section on extensions, and they're actually someone did file someone a non regular who's filed an issue, which I've interacted a bit, which is like, I wanna write an extension, but your text is I'm not understanding what you want me to do, but I've gone through the text and tried to make some updates there, but I think it tells you what you're supposed to do, which is like, step one, setup option is how you tell people that you have an extension or and then Right. You know, then once you do that, you can change as long as the peer also sends it, you can say what you know, you can change the rules of everything. You can make subscribe, go backwards, or whatever. Okay.
[01:53:29] Chairperson: Okay. Thanks, Alan. I know you wanted to bring in the other slides. In our judgment, that is too spicy for now. Will slide. So please take a look at issue fourteen fifty three. We'll discuss that in in a a future interim, probably. Issue fourteen fifty three, and then we're gonna switch to something completely different, which is Yanmei, our our, as time allows, presenters. So please go ahead.
[01:53:55] Yanmei: Okay. Seven minutes, that's enough. Hi. I'm from Alibaba. Today, I will introduce a new scenario for Media over QUIC and also for for the discussion to discuss these requirements for feedback. So first part, I will quickly introduce is how to use this media real quick for the live agent streaming about the scenario and also the performance metrics comparing to the WebRTC. And the part two, we will go back to the feedback mechanism. And also, we will discuss about how to support this in relay architectures. So first, we will go quickly through this scenario. It's kinda like we have this application, and people could use it it to have a video video call with the mount with the video call with this omnimodal. And the users can use this application to identify the real world objects through these video frames. And, also, these agents could understand their purpose and also could give them some recommendations and also this shopping assistance. And also these agents could help the users complete related tasks. And all these low latency communication are all over Media over QUIC. And we we have two AB tests about this transportation layer. And the first first one is about using the Media over QUIC, and then the second one is using the WebRTC. And we find out that we the the video quick, they they really has a much more faster session setup. And the key point to that is that we can use these zero-RTT connection built through the Media over QUIC. And, also, we are able to get a better QoS through this multistream priority, and even we could get some better TTFT. And now we're back to the feedback. First, we focus on the problem it solves. Actually, we have already have many feedback inside the transport layer, like the easy key and also the timestamp of easy key and easy and and RTT. But that's not enough for the original publisher to notice whether the service quality tackings has already met or not at the receiver side. So we need to brought these MOQT layer feedback. It's kinda like you can use this this feedback like objects complete time and also how many objects has missed a deadline and also the receiver side receiver side rate. And, also, we need to add more QoE feedback for the application layer. It's kinda like whether the players has suffering some rebuffering and also whether it's the stores so you can get better QoE through this feedback. I believe in last, the IETf people has asked a question how to use this feedbacks through this relay architecture. Now we brought the solution here. We have designed two kind of different feedbacks. The first kind is the last mile feedback is consumed by the l one relay. The second kind is the original feedback. And the L1 relay could choose to forward it to the original publisher. And the original publisher could use a feedback to decide the target period. And we have two target use case scenarios. The first one is a live streaming. For this kind of scenario, the original publishers typically has already transcode coded this content into a different ABR letter. So there are different levels of ABRs, and the feedback is yearly consumed at the last mile. And the second and the second scenario is for the audio and the video conferencing. The original publisher may need to collect all these feedbacks from all these sessions, attend this meeting. So to avoid there are too many feedbacks, the l one could aggregate these reports through a short period like five seconds, and it it can decide a better QoE for this kind of situation. Now we're back to end to end feedback passes. Last time, we have introduced this scenario, and it can work for live agents and also for things like cloud rendering and also cloud gaming. And people might wondering, how does this feedback signals make the QoE better? There are two ways. The first way is to consume the by the congestion controller like GCC, and it could control the sending rate and also the pacing rate. And the second way is to consume by the original publisher. The original publisher could use a feedback to decide a better target bit rate and also decide the proper frame rate. So we have some experience for these experiments through with with q with this feedback or with all these feedback. Now we get the lower rebuffering rate, and, also, there are less objects which miss the deadline. And, also, we have a lower store duration through these experiments. About the next step, we are going to update the feedback draft to the next version, including all these mechanism we have discussed today. And, also, we are going to collect more experimental data. And in the next version, we're trying to find out how to use this feedback with web transport. And, also, we really need more feedback from the and from you. Thanks,
[02:00:28] Chairperson: Any questions, comments? Jordi?
[02:00:34] Jordi Cenzano: Hi, Geordi from Meta. Thanks a lot for the presentations. I'm really interested in the in all of this. Just one question. Could you tell us order of magnitude how big your experiment was?
[02:00:45] Yanmei: Excuse me?
[02:00:46] Jordi Cenzano: How big the experiment was? I mean, millions of connections, hundreds, thousands, just order of magnitude.
[02:00:53] Yanmei: Ten ten hundred thousand. 1,000,000
[02:00:57] Jordi Cenzano: Yeah. Of connections? Yeah. Okay. So okay. Thank you very much.
[02:01:03] Moezanati: Moez, Cisco. I think this is interesting to consider the feedback direction. And one thing that you may wanna look at is tomorrow, we're gonna talk about the the track top tracks filter. One of the use cases of that is to optimize the fan in of many feedback tracks back to an original publisher. So that wouldn't give you details from every single subscriber, but if you wanted to aggregate that feedback and get the top of some of those, that would help the fan in scenario be manageable for by a smaller original publisher.
[02:01:30] Chairperson: Yeah. That's The queue is closing very soon. Thank you.
[02:01:37] Jordi: Okay. Joey from Nokia. Just I think this is very also interesting, but I just want to to to know that there is your plan to how to negotiate at the house sounds can be reported.
[02:01:50] Yanmei: Yeah. The this parameter is negotiate at the setup period, and we could send you a link of the this draft after this meeting. Yeah. Thanks.
[02:02:03] Chairperson: Thank you very much, everyone. We'll see you tomorrow for most of you, to talk about some of the many, many other drafts that we have for the working group. Have a nice evening. Thank you.
Session Date/Time: 24 Jul 2026 14:00
[00:00:08] Jared Jennings: Okay. It's 04:00. Thank you for joining us, those of you hardcore enough to be here at 4PM on Friday. We're four hours in. We got ninety minutes to go. Almost almost home, guys. Alright. This is the IETF note well. It covers a lot of the considerations for you being an IETF participant. If you're not familiar with it, type the IETF note well into your favorite search engine and read up on it. If you are remote and plan to talk or think you might talk, please use your headset so we don't have echo cancellation problems. If you are present and you've not done so already, and you are not on the full session in your laptop, scan the QR code that is at the back of the room and on the mic stands on your device to register your presence here and also enable you to participate in any of the audience participation functions that we have. Once again, we are happy to offer the opportunity to watch MoQ over MoQ. Once again, Magnus is going to put this in the chat, this URL. You can get the media feeds delivered via the MoQ protocol, thanks to our MoQ enthusiast friends at MeetEco. If you do that, you will need to use the Lite client to connect for all the chat and hand raising functions that come with me at echo because this is just a a media feed. But that is cool and, like, hey. We can watch video of a mock now. So I think the the mock the editor decided to go home because the mission is accomplished. Well, they did go home, but I I think they're trying to dial in. This is the agenda for today. We are covering most of the drafts. The other adopted drafts, we haven't covered yet in addition to some new work. If we have time available, we we had to cut most short on his top and track filters time. So he I I believe he will be able to use any additional time that we have. It should that should we should that happen to occur. Would anyone like to bash this agenda? Alright. Hearing nothing. Mike English, are you out there? There is. There is. Just in time. Mike, are you gonna share your screen, or do you have slides somewhere?
[00:02:52] Ben Bockshear: He's still joining.
[00:02:56] Jared Jennings: He's cutting it close. Alright. We're gonna give this just a little bit longer, and then we'll just rearrange things.
[00:03:30] Will Law: Let's
[00:03:36] Magnus Westerlund: it's Will. Is it
[00:03:37] Jared Jennings: Okay. Will, are you there?
[00:03:43] Will Law: Yes. I am here. Do you want me to go first to give Mike some time in case he's having problems?
[00:03:48] Jared Jennings: Yeah. Go go right ahead. I'm gonna hand you slide control once I find the button. Where's the button? Oh, there he is.
[00:04:02] Will Law: Okay. Just let Mike know he doesn't have to panic, and he's got another twenty five minutes. So good afternoon. I'm Will Law from Akamai, and we're going to start now with the what was the second item on the agenda, which is updates on MSF and CMSF. There's some important updates as well as some decisions we should consider. So one of the PRs we just merged following London was a new ability to update track fields via a delta update mechanism. So previously, prior to this, if you wanted to for example, we have a a track called video here with a bit rate 1.5 megabits per second, and we wanted to change the bit rate. Our spec said you had to delete that track and replace it replace it with a completely new track with a different name. So now we have a delta update mechanism. The operation is called update, and you can replace any of the independent fields. So it's basically an override process. You override the the new value, overrides the older value. It's a small package. It'll easily fit inside one MTU, so we don't even really need compression for it. It's not gonna buy us much, and then we get an updated model on the client. So it's the ability to change things on the fly. I think this this will be very useful and it's in place as as of the last release. We also merged an ability for tracking object properties to carry in net data. So we had a mechanism. We have an in net data list, and we basically have an inline attribute, which says, I'm gonna exclusively list the in net data as a base 64 encoded string. But sometimes you want to change your in that data midway through a track without stopping the track. And to do that, you can use the object property type. So we define that both the track property. This is where the initialization data is immutable over the life of the track because you only send it at the start of the track. And you signal in the in net data list that the in net data for a given track is carried in the track property sorry, in in the track property. And then if it might change at any time, you can use an object property. We recommend that you should attach this to the first object in each group. In other words, at the group boundaries, you don't don't have to do that. You can obviously add it wherever you want to change it. Because it might change at any time, a consequence of using the object property is you must keep repeating it. This is because you don't know when people are going to join a track. But we have what I think is a flexible enough system now. We got inline data. We got track properties, and we got object properties.
[00:06:48] Jared Jennings: Moe's in the queue. Yep.
[00:06:50] Will Law: Moe, sorry. I wasn't watching. Thanks, Moe, for question.
[00:06:53] Moe Zanaty: Yeah. Moe Zanaty, Cisco. So LOC already defines and registers track and object property for audio config and video config. It's not JSON. It's the binary blob. So it just omits the ID and and and type. And data is just the binary, not not bin 64 or anything. So those are already available if and I even though LOC registers them, there's no reason for them to not be usable by by anything else. They're just they're just literally the in its segments of of audio or video payloads.
[00:07:32] Will Law: So that's a very interesting question because they're basically identical to what we defined here. My next slide coming up is a question for the group of whether we should be reserving these or using them in the application space. So, Moe, let me when I get to the next slide, let's readdress that. But I'm all for reusing them. So if we can reuse them as is, yes, we will. Think that's a good idea.
[00:07:54] Moe Zanaty: And I I don't mind moving them out of LOC and putting them into MSF if you think it's a higher level spec that would be packaging agnostic.
[00:08:02] Will Law: Well, the question is, should there be any there? Right? Each is an application format, and there's a reserved space for for these which doesn't require registration. So you'll notice I didn't register them. I have a slide coming up asking the group whether this is the right approach.
[00:08:17] Moe Zanaty: No. I I I I personally believe that this is so frequently and commonly used that it needs to be registered. Doesn't make sense to require every app to do it in a different way. I think it this is a perfect example of the right code point allocation for something critical that every video app is gonna need.
[00:08:34] Will Law: Sounds good. Jordy?
[00:08:37] Jordi Cenzano: Yeah. Jordy. Yeah. I think it should be so sorry to not wait to the next slide. I didn't know you have. But I think it needs to be in the track because then you allow you allow dynamic changing. Not, you need to refresh the manifest. So, basically, you have a split brain there, and you cannot change dynamically from a codec to another codec or from one resolution to another resolution. And, also, just to more to most point, LOC defines this, metadata, but does not define the codec string. So, basically, it's not usable in WebCodecs yet. I will create a PR.
[00:09:13] Will Law: Yep. Create a PR. I'm happy to reuse locks. And we don't in in MSF, we don't need to send the codec string over in it over properties because we define it in the catalog. So let me get to my next question is so should MSF use tracking object properties in the reserved application space, or should we register them in the MOQT table? So if you look at the latest version of MOQT section five dot eight, it it basically says this is reserved for standards action, but we're in this this this range. Right? Zero x seven nine is what I what I selected. This is application specific use in the one byte encoding range. That's where I I put these. We're here now. Should we move to the standards registration? And this is really a architectural philosophy question for the group. I can see this space filling up. Right? So does is it just first in is lucky or what's or does MSF get because we're an adopted spec, we get to write into the space. And what if it's not generic? What if it only applies to MSF? Then should it be in the application specific space? Cullen?
[00:10:29] Cullen Jennings: Sorry. Cullen James. I didn't realize how far I had to go by the mic. So I think that we should register these for sure. And we should use a shared one across the multiple things that use it. That that makes way more sense because I think this will end up in lots of places. And I think that I mean, remember that a standard is also a specification. So we can choose about like, we should think about how we wanna use this space. And I don't know that size matters on these. These are so large that I'm not sure you'd want them I'm not sure this is you worth using a one byte code on. But if it if it if it if it does make sense to have a one byte code, then let's do it for sure. But I think we can pick whether we wanna put it in the one byte space or the two byte space. Does that make sense?
[00:11:17] Will Law: Yeah. In in this case, if it's application specific and the application's not gonna run out in this range, it can just use one byte because it's convenient. I think the one byte is much more applicable in the standards action space. So It just Are you basically saying that it's applications
[00:11:35] Cullen Jennings: I I'm I'm I'm arguing strongly against application specific. I think we should reuse it to be generic across multiple things.
[00:11:43] Jared Jennings: But Okay. Either way, we can
[00:11:45] Cullen Jennings: put it in one byte or two byte. Mhmm. And it has this table is really misleading by the way it's written. Right? Like like, I think we probably need to rethink about how we write this table. That's the minimum you need to get in there. So we can put it even though this will be a standard, it's defined in a standard. We can still be used to the specification required two byte encodings if we want. I think the question is is, is this used in a way where saving a byte matters? Or is this used in a way where saving the byte doesn't matter? We should figure out the answer to that question and then choose which space to put it in based on that.
[00:12:20] Will Law: Okay. So I need to talk to Moe who's right behind you then because Moe, I think, registered in this one byte space. Right? So the argument is that in that segment, there's already lots more bytes. We we could happily go with the two byte space perhaps.
[00:12:35] Moe Zanaty: Yep. Moe Zanaty, I I agree that it's not necessary to to occupy the the one byte code points. And these segments are usually on the order of tens of bytes. So they're not huge, but they're they're not one byte or or three bytes. But what what I was mainly wanting to say is that I I I don't think any IATF spec should ever reference the application specific range. I considered appless application specific use to mean implementer use. The implementer can choose this value, but no ITF spec would ever choose this value. I think the ITF specs should all use the reserved range because they're intended to be interoperable. Application specific is like, you don't care about interoperability, so you throw whatever you want in that number space. And you don't intend anybody to copy you, and you don't intend to ever collide with anybody because your own application. You're not interoperating with anyone. So I don't think we should ever reference the the ones that say app app use in any of the IATF specs. And I I agree that we could probably move the LOC can reregister in the two byte space for the for the config segments. And and I'm sympathetic to Jordi's request for having a different track property for the codec string. Right now, we assume that the the codec string is negotiated some other way, like through catalog or just known upfront. But, yeah, that that's an essential part of of initializing a decoder too in addition to the to the net data.
[00:14:03] Rohan Mahy: Good. Hi. Will and may. So it's sort of similar to what Mo just said, but basically, no no other application at IETf that
[00:14:15] Moe Zanaty: I know
[00:14:15] Rohan Mahy: of has a reserved range that they call application specific use that doesn't mean private use. It means every application comes up with whatever number they want. It so, like, I I think, really, the the wording is actually probably wrong there, and you probably mean private use. Not that it's being used by an application of mock, but that it's being used for a private application. And if you maybe wanna make that range slightly smaller, you could do that. But I I I don't care about that. But private use is what that usually means when somebody says reserved for application specific use. Thanks. Okay.
[00:15:03] Jordi Cenzano: So, Hass, I I I
[00:15:04] Suhas Nandakumar: agree with Rohan that we probably should call it private. And the idea behind that is that you do not need an applications to you need applications to know that you can get on either side to be able to use it. That's the reason why it's in the private or application specific. It's not standard. And on the track property, I think we should use the other space that we have, which is reserved for the mandatory track properties. Properties. Object properties can probably go in the two byte, but the track properties should go in the other one because we divided the space between object and track properties. Might not be the right design, but at least that's what it's right now.
[00:15:43] Magnus Westerlund: Yes, to one comment. I think we need to look into the definitions here about applications, private use, etcetera, and especially consider what is the limiting scope for these so we don't get collision between on a marketing relay, for example, is it within a you need to be consistent within a particular domain scope or what is it? Just to clarify those things. Go ahead, Will.
[00:16:13] Will Law: Okay. So I just for action items for the notes, we've got an item to revise the language for this section and introduce the word private to make it really clear that these are not IATF standards. MSF would fall under the standards action, then I'm gonna collaborate with Moe. We will share both the tracking object properties for a net data. We'll figure out where to put them, and I'm also gonna add current properties that are in private registration for MSF. We've got a few other ones not referenced on this slide. I will all those also move those over and register them in the MOQT managed property table. Next slide. We have an open PR that I'm looking for feedback on and also implementation action. Actually, Ali and his team have done some early work on this, and I don't know if Ali has data to share on that. But it's basically the ability to switch across tracks that have different group or GOP lengths, which is practically what the groups are mapped to. So we have three tracks. The first one has the orange blocks or your eye frames, and each one has twice the eye frame distance of the others. So we communicate a single key frame spacing attribute, which is the number of objects between your key frames. And based on that, we define a formula and that allows a client to robustly switch from any point in a track to another point. The advantage being that you get faster startup and you get faster switching because you don't have to wait for the your bit efficient longer track. You could jump down to a smaller one for a short period of time and then jump back up at your next boundary. So this is defined. It's in a PR. It's not merged yet, but we're looking for challenges to the algorithm or the edge cases where it's not working, or is there, more importantly, other information we need to provide in order to make this scheme robust? Yeah.
[00:18:17] Ben Bockshear: This is wrong.
[00:18:17] Will Law: And I see a comment from Ali. We demoed this last month that MWS will be available online pretty soon at mocktail.dev. So it's already a working version of it, but I'm looking to get this into MSF as an available option as soon as possible because I think if we just do the same as DASH and HLS, we're where it's a challenge. But if we can improve upon them to to some degree with schemes like this, then it's to our advantage. Okay. Gwendel?
[00:18:47] Gwendal Simon: Yeah. So it's a great idea, like a HPSP. Know? Yep. So for the for for the switch from parameter, especially in the soft mode or aligned mode, we need to have the same group ID. And so here, as you can see, the group ID is not aligned, like, four, two, and one. So we would need to have some indicator of how to rebuild the group ID alignments to make sure that we can have a smooth transition from one track to another.
[00:19:26] Will Law: But don't we we have the ability to specify an absolute group ID, and in this case, you would know what it is. It doesn't matter that it's not the the group ID here is one, whereas here it's two. You would just specify this as the absolute group ID in your switch from.
[00:19:42] Gwendal Simon: You you specify I mean, in in into switch from unless I you know, there are still some conversation with this.
[00:19:50] Will Law: But
[00:19:50] Gwendal Simon: the if you said, want to switch to group ID number four here because you want to switch to a, we will and if you are on the on the track b, you will continue until three dot nine of the track b.
[00:20:05] Will Law: Okay. We need an explicit attribute to say this is this group ID I'm giving you is for the target destination, and there's a different switch from for the track that I'm playing.
[00:20:17] Gwendal Simon: Unless we can use double filters that Alan mentioned based on more specification where we said one track filter for the field fetch and one track filter for the for the subscription, but it's a bit complex.
[00:20:36] Will Law: Okay. But the I think your the action item for the notes is we need to look at the switch from capability to see if it actually enables this type of dissimilar group group length switching or non non synchronized group length switching and see if there's another parameter we should provide.
[00:20:53] Gwendal Simon: Or we restrict to the hard mode of the switch from parameters and the hard mode of switch from, you switch immediately, which couldn't be the case here, but you
[00:21:06] Will Law: Yeah. Which is yeah.
[00:21:09] Rohan Mahy: Okay. Thank you.
[00:21:13] Will Law: Okay. Moving on. So here's an issue, which is proposal, and I would like to debate it. It's replacing catalog with nothing. So I will explain what I mean by that. MOQT allows empty track names. It also allows empty namespace as well. But if we define a catalog to be the null or empty track name by default, then we don't need to keep communicating its name. So our URL syntax, which currently looks like this line because we have to explicitly put catalog in as the name of the track, would collapse to just communicating the namespace. And as long as you're using MSF, we would have the convention that you can subscribe to the null track of this namespace, and you will get yourself a catalog. And if we do that, then you open ourselves up to be able to have many different kinds of catalogs. So you could have the default one, which is the null one, and then you could have a free or a paid or a one for Germany, one for France, etcetera. That's the argument for doing it. The argument against this is people will, in a year or two, forget that there's a name here, and we it can get murky. So there's a nice there's a cleanliness the cleanliness to having an explicit name when we're asking for a track. So I'm just looking for input on this issue, and we can certainly debate it here, but also online.
[00:22:44] Moe Zanaty: I've long argued for having the null name as as the catalog. I don't like reserving a code point that is likely to crash clash with the application use in catalog. You know, many things could be called catalog by the application. So but it's unlikely something's gonna be null by the application. One minor nit is I would put the dash dash. Mean, the the the the canonical text string of of the namespace and name is dash dash name. So you still need to think of the dash dash after the namespace to indicate there's there's no name.
[00:23:18] Magnus Westerlund: And That's good point.
[00:23:20] Moe Zanaty: Yeah. And originally, I was gravitating towards dot as the directory for the for the catalog. But since we reserved dot, we reserved dot in the namespace as the first tuple. I wouldn't wanna start using dot somewhere else even if it's just the name and not the not in a tuple because I think it just causes confusion about whether or not dot is reserved.
[00:23:40] Will Law: Just one one point, Moe, on that question. Yes. So you're arguing and I think Victor's saying the same, that dash dash dash to me is a little dirty. It's like that I'm gonna every URL I send out is gonna end with dash dash. Can we not just revise the definition of the namespace name topple to or the string to say that if we don't if we don't if the null namespace doesn't need to be communicated with a hanging dash dash, that would be
[00:24:07] Moe Zanaty: We could. I mean, we we could wrap the the canonicalization of the namespace name full track name. We could we could change it if we wanted to. It's just, you know, another if check or something. It's a you know, right now, just says, this is the way it always is. You have to say, oh, if it's null, then you omit the dash dash. Okay. I don't think it's a big deal.
[00:24:25] Ali C. Begen: I think we
[00:24:26] Moe Zanaty: could do that.
[00:24:26] Will Law: Okay.
[00:24:29] Suhas Nandakumar: Suhas, I think having a no catalog is fine, but I still think we we need to have dash dash because you do not know if you're finishing your up your namespace stuples entirely or not because I can have app and nothing. Or or how do we know that this is the last namespace tuple before there's a catalog or not if you're cutting earlier?
[00:24:53] Will Law: Because it's a defined it's this is defined by MQT, how to construct this. And certainly with an MSF, the next one would be an ampersand if we're adding key value pairs. So it you would you would cleanly know that this is a namespace because namespaces are separated by dashes. If there's no dash dash, then you're not communicating a name, and you would use the default name defined by MSF, which would be the null null name.
[00:25:22] Suhas Nandakumar: Okay. But I think if I understand correctly what you're saying is that if I have five tuples and if I use only three tuples in the namespace, that means that those three tuples and by implicit catalog is the track name, even though there are other two tuples. So I cannot do prefix of tuples there. There because if I if if there was if I had used all the five, I would use all the five tuples and dash dash nothing, that would have been very clear saying that there's no prefix here. So all the tuples that are supposed to be used has been used. There's still you create an ambiguity if you're not using all the tuples under user prefix of Okay. Whenever you encode. So
[00:26:01] Cullen Jennings: I apologize. I I just worry that, you know, everywhere else, we try and make it really hard for implementers to not implement things. Right? And right here, this you know, where we put the default on this one is going to cause
[00:26:26] Jared Jennings: Yeah. Are
[00:26:33] Cullen Jennings: we back?
[00:26:34] Will Law: You are back.
[00:26:36] Cullen Jennings: So the it it it just seems like it I really don't care. I I we can discuss this anywhere, but I feel like having dash dash catalog, given no human ever types in these URLs, right, That it's really no big to have deal to have dash dash catalog there, and it makes it clear. And it makes it if we want to add different things, we don't suddenly have this confusing default that's or this default that's hard to sit other things on top of. You know? So I I I sort of lean slightly the other direction, but I obviously don't really care what what we do on that that part. But
[00:27:12] Will Law: Okay. Thank you. So I hear arguments on both sides of this. We'll add comments to the issue, and we'll continue discussing it before we move towards PR. Another PR that's open that I'm just looking for review and support on is
[00:27:30] Jared Jennings: Hey, Will. We got about two minutes left, so we probably focus on whichever you think is the most important.
[00:27:36] Will Law: So this one's quick. I think it's useful. We have an event timeline, which is basically rows of identical data. But in this example, a lot of these examples, we want some type ahead of data. So this is a crop inspection service with the these are drone coordinates, but it's useful to add the stuff in blue so you can correctly interpret the rate of the data. To do this, we can find a track property. It's in that same application space. I will remap it to a MOQT managed one, but the idea is this allows you to add additional information. I think it's very useful. If you don't wanna add it, you don't have to add it, but it'll enable event timeline to be flexible in its usage. So please check that out. We have a PR open right now to change the language of mapping, and, basically, it says, irrespective of the packaging type in place, each mock object must be placed on mock subgroup zero. This came from Luke, who I don't know if he's on to to motivate the request here. Question is, is this correct? What about future temporal scalability? Because this was the the scheme under which we wanted to have half our frames on one subgroup and hop on another. But if we have normative text saying every object must be placed on subgroup zero, then we remove ourselves from that option. So we do we relax it to assured or do we modify it to say must if you're not doing temporal scalability?
[00:29:10] Moe Zanaty: Most of the night, I do not think it definitely should not be a must. I mean, it doesn't make any sense to prohibit multiple subgroups in in one of the core specifications. That doesn't make any sense to me. I don't understand the motivation of even why you'd wanna want this.
[00:29:26] Will Law: Okay. I'd appreciate a comment on PR169 if that's the case. Thank you. K. Queue's closed. Gwendel's out of the queue, but he's running. Okay.
[00:29:38] Magnus Westerlund: Yeah. I have five seconds. Quickly.
[00:29:40] Gwendal Simon: Go ahead. We need to have a specific meeting to discuss this because there are too many people conflicting on this.
[00:29:48] Will Law: Okay.
[00:29:48] Jared Jennings: Okay. That's gonna be the last word. Thank you, Will.
[00:29:50] Will Law: I had more stuff, but thank you for your time.
[00:30:01] Jared Jennings: Mike is next. If I can find the interrupt thing.
[00:30:11] Magnus Westerlund: It's at the bottom. There it is.
[00:30:14] Jared Jennings: Thank you.
[00:30:19] Mike English: Cool. Thanks. So I'm Mike English from Cloudflare, and I am reporting on the state of MoQ interop at IETF 126. At a high level, this is what we have in the automated interop test runner. I realized that the text on a lot of these images is going to be quite small and hard to read, but there are links. So if you want to download a copy of the slide deck, you can, view the pages directly and zoom however you like. On the whole, we saw some new additions, to the Interop Runner, kind of a mixed bag in terms of, tests, passing and failing, but I think we have forward progress and good momentum. This is what the, you know, full matrix looks like, looking at the, pairings of different implementations, against each other. This view, some have taken issue with, the information density here. So we are looking into I I have another slide in a minute. We're looking into some alternative representations of this information. But the basic idea is there's a little tiny superscript that tells you which draft version was negotiated, and then the pills are kind of of the available tests, how many were run, how many passed, and the color is determined by, you know, whether they all passed or all failed or somewhere in between. And then in some cases, the tests are skipped usually because there's some kind of a a build issue with that particular implementations, entry. So, that's what's going on there. Yeah. Thank you for putting that in the chat too. So supplementing the automated interrupt runner, and backing up, I guess, a little bit. The history here is we had started with kind of ad hoc testing, and then we moved to a spreadsheet. The spreadsheet was useful, but I think gave kind of a false sense of precision, and there was a lot of ambiguity about, you know, which version of which code was run when, when a a cell got filled in. So the automated interrupt runner gives us, a lot more concrete information about which tests were run against which code bases at what time. But there's still value in kind of, often application level higher, interrupt testing that people are doing in kind of an ad hoc fashion. So we are now collecting that in a data as well, and this is in the in the wiki. So you can see some of these reports. Giovanni's is quite thorough, and very helpful. You can see his Python implementation was able to interop with, Moxygen, Nokia's implementation, I'm quick, what else, moq-x, moqtel, and then there were some issues between Giovanni's implementation and Cloudflare's. The control messages work, but there were some subtle issues in the in the data plane. And I see Alan's in the chat talking about data plane tests. I will get to that. So here's examples of more reports. I put them all in the slide deck, they're kind of captured for posterity, but they're also available in the wiki if you want to go look. As I mentioned, we are also looking into a better presentation of the information available from the automated interrupt runner. Giovanni has put fair bit of effort into one particular approach that I think shows some promise, and that looks like this. So here, you would have kind of the view that we had from the spreadsheet before where you look at one draft version at a time. There's a drop down at the top. The results here are dated, so don't take that as as anything. This is, about the presentation of the information. But then you can kind of see, you know, running over QUIC, running running over web transport, you know, how does each implementation pairing fair. One of the questions that we're exploring right now is, how do we collapse, multiple implementations that run multiple version numbers? And I think this gives us a way to do that. So if we kind of group together, you know, all the different branches of mock r s, for example, that have single version support for different draft versions into, like, a family, and then we can present it here as just, you know, moq-rs on each draft version. There's also, we're doing some work to thread through a way to constrain, the set of versions that, can be negotiated. Up till now, the interop runner has assumed that the highest, mutually supported version is what would be negotiated between any two implementations, and that turns out not to be always the case. Sometimes implementations have a preferred version that is not the latest, and so it will negotiate differently than the framework expects. So, for that reason and because we want to have the ability to get, better test coverage on older draft versions in some cases, we're going to set things up so we can kind of thread through an environment variable and say, okay. Target this draft version and and then try interrupting writing these tests. Okay. And, here's everybody at the at the hackathon. I say everybody. This is not everybody. There are multiple groups of people at different times, but it was a pretty lively, bunch on Saturday and on on Sunday. So we had a good time. So coming back to the question of, data plane, I do have an open PR, with a couple more tests that I would like to add. And my intent is to kind of go through Alan's conformance test suite and pick kind of high value targets there and start migrating those tests over into the InteropRunner. The InteropRunner is designed not as a, you know, as a monolithic conformance testing tool, but as true Interop. So we always have a test specification and then multiple implementations implement to that test specification so that we can get multiple test clients testing different relays. And so part of the work of of porting over those tests is kind of working backwards, turning that into a specification, and then implementing it in, in different implementations. Alright. So open things up to discussion. And I'm happy to go back to, kind of cover some of the the detailed reports if if people want to speak to those individually. I intentionally left time for
[00:37:59] Ben Bockshear: that.
[00:38:05] Mike English: Altani?
[00:38:07] Altoni: I was waiting for the chairs to call my name. Okay. Altani, Cisco Meraki. So I see a lot of yellows, and the yellows you said are the interesting cases where the control plane, data plane doesn't doesn't, work together. Right? Either the data plane phase, that's what you said. Right? And I see a lot of yellows. So I'm just wondering, can you speak a little bit more on why there may be a mismatch between control plane and data plane in these cases? Because every protocol stack has this problem where the control plane is relatively easier to establish because just set of handshakes, but the data plane is where the actual juices, you know, all those caching and the packets and everything. So what is your takeaway from the yellows?
[00:38:49] Mike English: Yeah. So to be clear, the yellows here are denoting any circumstance when a portion, but not all of the tests pass. So that's a signal that, you know, there's something happening. You know, we were able to negotiate setup and some kind of session is occurring, most likely. And then, but some some of the tests are also failing. So most of the tests that we have right now are control plane only, but we do intend to add a data point to that. So even some of these greens are, you know, maybe all of the, you know, messages are are going back and forth appropriately, and the state of the tracks is properly being communicated, but the actual objects are are not flowing, as you saw in some of the anecdotal reports. So, yeah, we do still have issues. We have, you know, work to do to to get everything properly represented in the automated runner, but that's happening. Thank you. Jordi?
[00:39:49] Jordi Cenzano: Yep. Jordi, Mehta. So just let me start by saying that I'm a fan of simplicity. And I realized that over time, the the interrupt is becoming more and more and more complex. So at the very beginning, there were bugs in the implementations and we were fixing them. But now I realized that the biggest bucket of problems is different ways of doing the same. So, oh, I do publish namespace. Oh, no. I only do publish. Oh, I do moq-me. Oh, no. I do log log three. I require subscribed names namespace. Oh, no. I don't I don't need that. I just do live. So I have two ideas that I wanted to surface in so for the sake of simplicity, to surface to this working group. First of all, is take the advantage of doing breaking changes. So we are doing breaking changes at every version. So if we ever everybody agrees that published namespace is the way to go, I'm totally okay with that, or publish. Just deprecate the other way. And then it's a simple way to say, if you are compliant with b 18, this is the way to publish, period. There is no confusion. This is one. And the second and and the second idea is about define interrupt levels. So if I just want to send small data messages okay. Level one. I just need these two messages. Subscribe, live, no fetch. No. This is level one. Level two. Oh, I want to go back. Then same. Level one plus fetch. Level three, level four, up up to media catalog and all the full sync. So just wanted to just share these ideas in the working group.
[00:41:16] Moe Zanaty: Thank
[00:41:16] Jared Jennings: you. I'm gonna close the queue quite soon.
[00:41:20] Suhas Nandakumar: So, Hass I think you're
[00:41:20] Magnus Westerlund: ready. No.
[00:41:22] Suhas Nandakumar: Sorry, Suhas. No.
[00:41:24] Magnus Westerlund: No. So I'm relaying Alan here that one thing his test and stop bugs in. So this is for the data play test, I think, or test is multiple imputation is that it sends published down and requires receiving it in order to pass. It also exercise prefix matching in the relay. And in general, Moq-twenty 18 interrupt is not as solid as twenty sixteen was seen with Jensen. So now you can go ahead.
[00:41:54] Suhas Nandakumar: I just I think in Madrid or something, Jordi and I had media interop to some to to some level between two different implementations, two different clients and one relay. I think at some point, we should, get back to doing the media interop, which is like we haven't I think Jordi's moq-me also kind of moved to LOC. We have and we need to kind of define a a way to do the media interop, at some point. That would be really helpful.
[00:42:19] Jared Jennings: I enter the queue to ask the question I always ask. Mike, at the next interop in Seattle, do you think we should stay on 18, or do you think we're ready to move forward?
[00:42:29] Mike English: I think it's hard to say. I think, I my take is similar to Alan's that, the interop that we have here is not quite as solid as, what we had on draft 16. However, I am seeing more activity happening outside of just the hackathon, so I could see us being able to move forward.
[00:42:56] Jared Jennings: Okay. Other people are feel free to share your impressions in the chat. Kota.
[00:43:01] Kota: Oh, Kota, just one thing. The one problem I I've run into while interrupting is that the that the, basic control messages and object flow or or a datagram and subgroup works. But once I send a request update for flipping forward, for example, any crashes, so we we might need another session level interop to test, like, request okay, request update for if not every parameter, but main parameters.
[00:43:37] Moe Zanaty: Moe Zanaty, Cisco. I think I like Jordi's idea of maybe having more structure around the interop. I know that, you know, you currently can define any test in any scenario, but I think maybe work with the editors to figure out what is the core, you know, stepwise features of mock. And And that may even inform if the editors eventually wanna trim down the spec. We keep hearing about shipping it soon and, you know, cut the craft. So if you ever really wanna figure out what are the basics of mock versus what are the, you know, layered follow ons, may be a good thing for the work group to figure out and and embed that as a structure in the interop tests.
[00:44:15] Mike English: Yep. I I also really like that idea of having different levels of interop. And I think so there's only a small number of control plane, focused tests that we have right now in the runner. And the reason for that is because we were trying to, you know, ease into, okay, what what are the simplest things that, like, should be widely supported? But, you know, now there are questions. Okay. How do we validate data plane? And then there's a lot of, you know, complexity that starts to rise as you get into the different permutations. There's a lot like, you you might support, publish namespace and subscribe flows just fine, but not be able to support, subscribe namespace and publish yet. And so I think it would be helpful to kind of discuss as a group, you know, how we see those, things batching together.
[00:45:01] Jared Jennings: Thanks. Thank you, Mike. Alan just asked that Mike would say that he was just at virtual interrupt day on draft eighteen maybe in early September and then go to twenty for Seattle. Again, let's go ahead and have that chat on the list and in the chat. You're up next. Yeah.
[00:45:25] Suhas Nandakumar: I'll present right now. Yeah.
[00:45:27] Jared Jennings: Bring it over here, please.
[00:45:28] Ben Bockshear: Okay. I think you should yeah. I'm working with Okay.
[00:45:39] Suhas Nandakumar: Okay. One, three. So I'll be talking about what is called tempo. This is basically a draft. Yep. This is a draft that Cullen and I authored about how do we use mock for a synchronized layout. So the the dream or the the ideal dream here is that, like, let's say you have a live a FIFA soccer event happening, and we have subscribers coming across different paths in the network. Someone is in the living room, someone is in the bar, or someone driving by, and a goal happens. What we want to do is that, the moment should be shared live, and it should be felt simultaneously by every viewer. I do not want more to see it before I see even though he's right next next to me or something like that. So how do we kind of use mock to enable something like this happen? And the one of the main reasons why we would see the issue with this is because each of the subscribers might be on different paths, and there's different arrival rates or different variable network delay. The because of this and also because there is no coordination between the subscribers, that means that everyone is on their own. Every viewer is on their own and the and we and that causes the the the differences in who gets what and when. So the more more four major categories of use cases where something like a synchronous player might be helpful is in live sports as the one as though just one that we we discussed, where we do not want someone to see earlier than his neighbor. And and what we need is a a spoiler free shared experience. And in so second use case is the multi room audio where you have multiple audio speakers, and I I play out a music or something, I would like to be played out around the same time without having echoes or bad audio. The third thing is, like, Twitch use case where you have a pulling done by an inter streamer, and we we would want the response to come in a way in a in a way that it's meaningful to the content or the poll that's being done, not delayed. And and obvious use case would be emergency alerts where when you make an alert, it would be nice if those alerts kind of play gets better at the same time. If not, they'll well, the echoes and other things might cause not to understand what the alert is about. So solution, at least what we have come up with and try to implement is called Tempo, which is like a timing extension for media player orchestration. At very high level, what it is is every version publisher will publish three pieces of information along with every object. There's some optimizations which we we'll talk about it later. But the idea here is that there are three properties. One is the capture time stamp, second is the playout delay, and third is the hop time. The capture time stamp capture time stamp is that when an object is captured, that's the time stamp of that. And playout delay is that when the original publisher expects the playout to happen based on this application. And hop time is every relay trying to fire up a stamp when when it's forwarding the object. Of these three, the the first two are immutable properties, which we do not expect relay to change. And the last one is, like, relay has to change it. And how this this kind of shows, you know, from the original publisher all the way to the subscriber, the capture timestamp and delay goes as it is. But hop hop time basically changes on every relay based on what it finds when it forwards the objects. And why does it matter to have the hop time changed by the relay and how the last hop basically helps here is that because in a in in a network path between the relays within a data center, most of the time, the the delay is kind of stable or it's not as variable as in the last hop or the edge. Having relay having the subscribers or the viewers get the most recent version of the time stamped by the relay would also mean that they would be able to cap calculate the right offset and and and just and just adjust the play out delay. That's the reason why relate to update the hop time would become very important. So when we talk about clocks and timestamps, there are things that might happen. We have three scenarios where we can happen is that if your original publisher, your relay, and end subscribers, they're all NTP synced, then probably there's no problem because you have all you need to do or the or the server is take the capture time stamp, take the player delay, and at it, you'll get the actual player time. That's not not it's not as complicated. There might be small differences, but not in a in a way that have a bad user experience across the viewers. Our second use case or second scenario is there when you have the publisher has the timestamp sorry, NTP sync clock and the relay has NTP sync clock, the formula has to be kind of take take into consideration the variability at the last hop, the one way delay that would happen to calculate the offset of the clocks, and then adjust this its payout time. And the third scenario where you have the origin publisher and end subscribers do not have NTP sync but a relaxed NTP sync, this is the one of the worst cases because you do not really know. So having some kind of metadata track that you have, you can have or with the Relay, that could give you periodically the timestamp sync would help to calculate a better player time. So as we talked about, if if everyone is in the PC, you do not have to even carry the hop time because that's not needed because all the clocks are in the PC. In that case, when the version publisher publishes such such a object, it it can totally skip the hop time. This is one of the optimizations there. In a way, how the tempo organizes the thing how it works is that there are two parts. One, the origin publisher publishes that their data with the times that with stamping the various times, and relay distributes it to the subscribers. And subscribers calculate the hop time, they calculate the final payout time, and and they provide a feedback to what we what we call as the sync server that basically says that I'm am I doing good or bad in terms of the expected play out? And the sync server provides a feedback to the original player player publisher to readjust its time if if subscribers are falling behind. So we have data flowing from the original publisher all the way down to subscriber, and the feedback going from subscribers back to the playoff the player placing server, which press the origin original publisher. This is the feedback loop I was talking about. The original publisher apply we've talked from the blue at the bottom. The subscriber reports, hey. I'm I'm doing, like, fifty milliseconds behind every time you ask me to do something. Let's say many subscribers report their up updates to the PlaySync server. The PlaySync servers figures out, okay. Close to 8080% of subscribers are experiencing delays. So let me adjust the delay and tell the version publisher to slow down or, you know, other your player play out so that, you know, every viewer can adjust accordingly. So it's more of a graceful degradation, but also not having to be not have not avoid a history where needed. This kind of shows an example where at the if the audio packet was being played every twenty milliseconds, at some point, 80% or 90% of subscribers basically reported saying that we are hundred milliseconds behind every time we try to play out. And the sync server has told the original publisher to delay everything by hundred milliseconds. And then from then onwards, the every object that gets sent will be adjusted to the new player delay. That way, all viewers are at the the end goal is that all the viewers now do see things a hundred milliseconds delay, but they're all seeing at the same time. We talked about three things that, in worst case, we have to send per object, and that might be too heavy, you know, given the audio packets are really small. So some of the optimizations is that we might not use the full fidelity of the timestamp. It might be only six we can use just 14 bytes. It has its limitations, but it's useful for most of the common use cases. Other optimization is that we don't have to send every object. We can send periodically based on some registered frequency, and viewers can basically inter interpolate and and calculate the actual time they need to do. Or we can create our group IDs to be time aligned group IDs in the sense that using the group ID is good enough for every subscriber to kinda figure out what's the play out time. So if you are using the time aligned groups, then you do not have to send any of the three time time time properties that we talked about. And and we we talked about the case where every subscriber kind of sends their feedback to the PlayXync server and PlayXync server tells the pop publisher to update player delay. There's another way we can also deliver that information from the origin publisher all the way back to the subscriber if we had a catalog track. And a catalog track could be one way to kind of communicate that information. That way, you do not have to stamp every object, but it should send an update of the new play out delay in a catalog as a catalog update, and one publish will basically let every subscriber know. This is kind of another optimization if we if we do not want to kind of stamp every object there. So what does Tempo basically do? Right? Tempo provides a way for a synchronous play out in in a graceful degradation degradation way so that if something goes wrong, subscribers will let the publisher know and and publisher can react to that one. And because we have the placing server constantly monitoring what's happening, we can have adaptive buffer. And with if if you follow the optimizations that we talked about, if if you know it's already NTP synced, and if you know that we can use a single catalog track to update the delay, then probably there's minimal of zero overhead. And this also kind of works in the case where there's no clock sync across any of the three entities, like the relays of the original publishers or the subscribers. And the it this uses mock native distribution to the core to make it happen. I think that should be all.
[00:56:01] Magnus Westerlund: I will in queue.
[00:56:03] Suhas Nandakumar: I will go ahead.
[00:56:07] Ben Bockshear: Can
[00:56:09] Will Law: you hear me? My video is yes. So I'm very much in favor of the synchronization mechanism. I do have some strong concerns with this design for highly scalable sports events, which is really the use cases you cited where we do want people synchronized. Because if I have a million subscribers and I'm gonna I'm gonna route data from all of them back to a coordinating system, I think that's an awful lot of centralized data that we don't actually need. We we a timing system in which each player is essentially stateless would be more scalable. And I think the important thing for players, you can tell all players to have a two second buffer, and you give them a timestamp of when the media was made. But the players further away from the origin, they suffer because the data's taken too long to get to them. So instead of that per hop being rewritten with every hop, if in fact the hop was added, so you got the sum total by the time it arrived at the subscriber, now the subscriber could take that initial target delay for people with zero distance, add on the total hop distance, and as you move away, all the localized subscribers would have similar playback delay. And I think you can build a system where the publisher takes a conservative value for latents for synchronized latency to accommodate the 80% users and try to get rid of the need to make the dynamic feedback back to the system.
[00:57:37] Suhas Nandakumar: Thanks, Will. I I totally agree. When when we're doing this one, this this was the first version where we thought, having a play out sync server might be easier. I agree with and the more and more, subscribers out there having more dynamic at some point, we also thought about, using mock mechanisms to send the feedback back feedback to the original publisher, which we have today. And I I agree with your things. And I think if you can I'll send you the link to the issues. If you can the repo, if you can add these comments, that would be great.
[00:58:10] Altoni: Hi. I was trying ask to come back. Interesting idea. Amazing. But isn't this artificial induced Archibike.
[00:58:17] Ben Bockshear: That's
[00:58:17] Altoni: Isn't sorry. Isn't this artificially induced latency pulling everybody down the same point as well? That was one. And the second thing is
[00:58:28] Ben Bockshear: wait a
[00:58:29] Altoni: second. I'm so sorry. Wait. Yes. Isn't this a isn't this, like, a creeping up on the logic that should reside on the application layer instead?
[00:58:39] Suhas Nandakumar: Yes. It it does pull it it does penalize some of the subscriber some of the viewers. But the whole point here is that we do not want some viewers to go ahead, especially when you know that you want the player to be synchronous. And the cost of their synchronicity is that you you will delay some some viewers.
[00:59:01] Altoni: Okay. But how about having some bounce on this this artificial delay? Like, you cannot delay beyond this point because you don't want to a bad target should not pull all the good targets down.
[00:59:14] Suhas Nandakumar: Yeah. Yeah. Definitely. I think at at the application layer, which is using you'll have some some restrictions on how much you can delay because you do not want to have a bad subscriber. And, again, there's a there in in one of the slides we talked about, there was a way to prevent this hysteresis and also not blindly react to someone saying that you're delayed by one second. So the placing server or the original publisher who is reacting is is not blindly reacting to the that come in, but it is it's more reacting in the context of the application and why how it needs to be delivered. Yes. The answer is yes. But it's out it's on the on the on the application that's using will we'll need to take care of that. This this provides a mechanism to distribute it.
[00:59:55] Altoni: Okay. Application layer will still take control of it. Gotcha. Thanks.
[00:59:58] Magnus Westerlund: Yeah.
[01:00:00] Jared Jennings: You. Hello.
[01:00:04] Patrick: Hello. Hello. Okay. Yeah. We got you, Patrick. Okay. I have to say sorry. I haven't read your draft. So but I just want to to to say that we do have some use cases where we want some object from different tracks to be processed or in a logical manner. So I think I'm not I don't know if this timing you are talking about, Tony, is the the only solution, but now we we like to maybe check with your use cases and maybe contribute and join this work later.
[01:00:39] Suhas Nandakumar: Yeah. That would be really helpful.
[01:00:40] Mike English: Thanks, you.
[01:00:42] Ali C. Begen: Yes, This is Ali. We implemented the same thing actually a couple of years ago using a different mechanism, not just the monarchy as a mock extension. So I I I have two feedback, two comments to share with you. If this is a large event, as Will mentioned, this really shouldn't go back to the publisher. There shouldn't be really another server where, you know, you know, all this information is collected because, I mean, there will always be some really bad clients who are suffering. Right? So the the the the the publisher is gonna say, this is a suggested play out delay. And then all the clients, some of them will be in a good condition, some of them will be in a bad condition, but they will try to stay within plus minus delta of that value. Right? So by speeding up the playback or slowing down the playback, they can adjust accordingly. If you are really out of that window, you will have to make a jump if you have to. Right? Skip some frames and so on. But then you also, as a bad client, if you are one of the bad clients, you have the option, I'm gonna be out of sync. Yeah. Because, you know, I cannot just keep skipping frames for the sake of others. Right? Yeah. So I think avoiding the feedback going back to the publisher is one thing. And second, we'll look doing some local adjustment through the playback speed changes is the other. So that will that will certainly help.
[01:02:02] Suhas Nandakumar: The both both are I like of all the people, I'm sure you would have tried this, and thanks, Ali. I agree. Both are valuable inputs.
[01:02:09] Jared Jennings: I will close the queue soon.
[01:02:11] Jordi Cenzano: Hi, So just following what what Will said. So I think I think that you mentioned the then it's quite obvious that if everything is perfectly synchronized, everything is very easy. Yeah. So now what we can trust is that the relays are synchronized.
[01:02:29] Ben Bockshear: Mhmm.
[01:02:30] Jordi Cenzano: So then you have the poll the problem in the publisher clock and in the subscriber clock. But you also have a live stream going allegedly live stream going between those and those elements. So wouldn't be much easier just make a decentralized system and leveraging the connection, the live connection that you already have with approved bandwidth because if not, nothing works. And adjust the not adjust the clock, but keep track of the delay of those clocks, then everything is synchronized and the problem disappears. But I
[01:03:02] Suhas Nandakumar: think that's valid input. Yes. We should consider that.
[01:03:05] Rohan Mahy: Thanks.
[01:03:08] Participant: Hi, I think we'll describe this, but I just wanted to make sure I I got it as well. I think this problem of the live event and synchronizing is, like, more applicable to, like, in in a local setting. You don't necessarily want, like, all 100 like, 100% of the global population that's viewing an event to all be necessarily synchronized. So figuring out, like like, maybe as see as the users associated with a single relay server, which need to be synchronized rather than trying to synchronize all of them might be a better experience. So you're not, like, pulling pulling down other users.
[01:03:45] Suhas Nandakumar: I I I I do totally agree. Like, especially when you're you you can have this segmented by geographies too, various Yeah. Of release under which you want to adjust versus something else you do not want to. I I I think so. Yes. I think at the higher level when the end to end application is using this one, that's where some of those decisions might might happen. But I
[01:04:04] Ben Bockshear: agree. Just
[01:04:08] Cullen Jennings: quickly comment on two things. We do see that often clients that are basically in the same room might be going through very different relays because one of them was on a cellular connection and one of them was on a, you know, Wi Fi connection. And so it's hard to tell what group of things you might wanna have the same delay quite often. Location's hard. Right? And the only other thing I was gonna say is we didn't really talk about in the draft, we we have been talking about on whiteboards or whatever is is if you want to have feedback that goes back about what the latencies are experiencing so you can adjust the delay, obviously, sending it back on a track with a top end filter that only statistically gave you some of the largest delay things allows you to take a million subscribers but only get data back from a statistical sample of the ones you care about, which are the ones that are larger than a certain number or below a certain number to to help you adjust adjust your things. So that was that's not on the draft anymore. We've just been thinking about that if people wanna bounce ideas around that somewhat. Thanks.
[01:05:10] Suhas Nandakumar: Yeah. I think I'll just answer to that one. Yes. The the point about having two different network paths in this within the same room is very important. And also, like, as multiple people have commented that not having that sync server is a big benefit to the solution. And if you can leverage anything on mock tracks itself, that's much faster and a bit better solution. I think that's probably for the next version, we'll try to experiment with top end and see how things work.
[01:05:37] Magnus Westerlund: Thanks. So and I understand this is that I mean, this is an extended capability for mock systems, and it's nothing that needs to happen that now. So you have to continue to evolve this, and thanks for the feedback, I guess, for you appreciate it.
[01:05:53] Ben Bockshear: K. Yep. Yeah.
[01:05:58] Jared Jennings: They're already up. Okay. Next
[01:06:04] Cullen Jennings: slide. So
[01:06:06] Jared Jennings: You got the clicker.
[01:06:07] Cullen Jennings: Super. So there's been a lot of discussions around people not understanding why various things were were used or what the use cases were and stuff. And so Suhas and I did a bunch of work to try and write up and do a little bit of demos I'm gonna show here in a second of some ways that we're using mock in the video conferencing style the the the non sort of streaming video type cases. Sort of one of the video conferencing type video cases to try and help people understand where these features were coming from, how we're using them, and and understand better what we need to do in the base transport. So I'm gonna talk about those a little bit today. It's a strange presentation for me. I'm not this these mocha drafts are about a usage of mock. I'm not sure they would ever be proposed to be done in this working group. But they're there to help drive the requirements and understand what we're doing. So
[01:07:07] Rohan Mahy: Check the slide share here.
[01:07:18] Ben Bockshear: Screen. You're seeing your screen.
[01:07:30] Magnus Westerlund: It's coming. I think it's just behind.
[01:07:34] Ben Bockshear: I guess it's Okay.
[01:07:37] Cullen Jennings: So this is this is an example here where we're we're we're we're doing standard logins. We're getting some affinity tokens, then we get access tokens. We log on on two different clients here that Suas has logged on to. They're both web clients that are doing a chat application. You could see the
[01:07:54] Jared Jennings: chat. There
[01:07:56] Cullen Jennings: we go. You know, there's chat back and forth. You can get an idea of what the feel of the latency between these two are. There's reactions on this. And I'm gonna talk about the features of mock in couple slides later that we use on this. You can escalate it up to a video call here. So we're not sharing audio or anything, which will be a little bit confusing on the next demo, but you can see the fairly low latency on all of those types of things. So that sort of some sort of key features that we're we're driving on those types of things, including also sort of, you know, reactions and live texts and stuff that we'll show here in a second.
[01:08:35] Moe Zanaty: So
[01:08:38] Cullen Jennings: if people wanna play with this stuff, it's all open. Okay. Let me get to the other one that I wanna talk about here for a minute. Okay. So the this video what we're this is an active speaker thing. And so as Moe started speaking there, he switched in. And if we're playing the audio along with this as well as as most folk as Vanessa said, you'd get you'd get the top two speakers. So it's an active speaker switching thing. It's very common, these types of video conferences we use every day. The the selecting of a speaker and switching them in is quite rapid and flips between the various speaker. So I'm gonna talk about this sort of use case too of how it works in a few later slides. So I can stop sharing now.
[01:09:28] Jared Jennings: K. Back to the slides? Yep. Now we'll go on slide. I have to give you control again. Okay. You're back.
[01:09:40] Cullen Jennings: Okay. So what I'm gonna do here is all of those actually didn't involve any SFU or media servers. Those all used only the relays for all the communications back and forth with them. Yes. There's some stuff to set up the cookies and the tokens and understand the namespaces and the catalogs. They're outside of the mock. But everything that was going on in those cases was purely flowing over the medium relays with no additional application servers or other devices that were in it.
[01:10:12] Ben Bockshear: We split it up into a a bunch
[01:10:13] Cullen Jennings: of different layers of how we've set up the drafts and thinking about this with, you know, the identity and the authorization. And that drives the keying, which drives our messages, and then that all sits on top of mock. The the the we split the specs up into some different functionality here for chat. I'll talk about what it needs, about meetings, what it needs, and some of these other ones. So the chat one here, this one, what was happening is the different users, Alice and Bob in this case, they all have their own track inside a namespace for the channel or whatever you wanna call the the group room they're they're doing. And they are publishing their messages on their own track, but the messages have a reference to the messages the message that came before them or the messages that if there's multiple messages that came before them in a glare case so that they can form a directed graph and that all the clients can render these in the correct order even though they're on different tracks. Now we also put the the the the groups we tend to put based on intervals of time, which allows a a client that's joining to be like, give me all the messages that happened in the past five minutes. And then once it's got those, it can go and get all the messages that happened in the past month. And once it's got those, it can go back to So you can go from an absolute time to a group number on the track that you're trying to fetch. This does, however, result in cases where the group numbers are not sequential on the tracks. The next one we're sort of talking about here is the real time conferencing with actually, it's not I missed my points on there. Yeah. So this used publish. It used subscribe namespace to discover all the tracks. And it used subscribe to get the message off them obviously, and fetches to go back in time and get older messages. The real time conferencing used the top end filtering. But it uses subscribe namespaces to discover the participants in it. Each participant was publishing their own audio and video tracks. And we're we're using track filters plus top end to select the top two speakers in that case into it. The synchronization of the group switching. So obviously, a new person starts talking and we don't necessarily have a new group or a new iframe there. If the group we're switching to is very close to, if its group number is is very close, we'll actually use fetch in some cases. Just go back and get if we're missing, you know, three frames at the beginning of the group. If we're not near the beginning of the group, then we use the new group request to get the other side to generate a new group and start going from there. Now the the type of things that we were talking about with with switch and other mechanisms to to go to another group, they're probably not as applicable here because when a new person starts speaking in a conference, you generally want to switch to them pretty quick. And but it's possible that, like, Ali's scheme where you have multiple tracks with iframes at different sort of intervals would allow a rapid switch. We haven't played with that type of approach yet, but that's a that's a possible approach too. It would still need the top end in all of these issues. I think that those are really the the identity and authorization, we're using cat tokens with depop so that they're not bearer tokens. We have things with we tend to have scopes, of course, for the namespace like the channel or the meeting or conference you're in, but also for sort of roles. Role and scope may be very wrong words to use so they're so overloaded when we're talking about these tokens. But we have an idea of, you you would have a token that might make you a moderator for a space or only allow you to be a participant. Or maybe if you were something that was like a a bot that was just trying to do a transcription of the service, you'd get an observer level token. So those are sort of the the level ones we're working on that one. And very much an idea that we could use cross federation with multiple relays networks being involved with this. Stop me if there's a queue showing up too. End to end encryption, m MLS based on the group of the channel sort of set the keys. Lots of more work is needed in that space. And then using that to drive symmetric keys that are used for the secure object to encrypt things end to end. And one of the things with the security stuff is pretty quickly get yourself into the space where, I mean, you need to authorize human names at some level is what people wanna work with, but you need a way of mapping a human name of, you know, what I think the person's called. You know, my people might think I'm fluffier. They might think I'm Cullen, but how you map that to the sort of cryptographic keys and things. So we have a personal address book that will synchronize between your devices if you have more than one device, that helps deal with some of those issues.
[01:15:10] Magnus Westerlund: So You have a question from Alan. Is this a proof of concept, see what one could do when you put it all together? Or are you thinking this could be the basis of an interoperable messagingconferencing system?
[01:15:23] Cullen Jennings: So the intention of this is to move it towards the later, to move it to an interoperable system. And this I would not propose that the exact things as they're currently written would meet there. There's definitely some work. We'd like to collaborate with people on moving the system. But it was not meant as the usual, just a quick demo. So that's why we have proper drafts on it. Does that answer Alan's question?
[01:15:47] Magnus Westerlund: Yep. Yep.
[01:15:48] Ben Bockshear: Okay. I
[01:15:52] Cullen Jennings: think that that's really about the main things that I wanted to talk about on that. These slides were that's that's the draft names if you're looking for them. And I think with that, I will answer any other questions people have about what we're thinking about, what we're doing. We're also really happy to work with people on trying to think about some ideas of how to how to make this work. And one of the things that's very interesting on this is ways of mapping it to existing messaging systems, Matrix, XMPP, other various ones, is is one of the sort of Cure features on the on the chat portion of it, for sure, that would be very interesting to have feedback on. I've talked to some of the Mimi people, some of the XMP people, a few others. Other questions on this? No. Queue. Perfect.
[01:16:45] Ben Bockshear: Mike? You have a mic on this. Q.
[01:16:48] Jared Jennings: Go ahead, Mike.
[01:16:53] Mike English: Thanks. Yeah. So I just wanted to ask about these drafts. I think it's extremely helpful to have this level of detail in terms of use cases when we're talking about some of the features that we may or may not need in the base mock transport protocol and, you know, other features in the ecosystem to support these types of applications. I'm wondering if you see these drafts as something that you we could discuss and say, okay. There's maybe an alternative spelling of, you know, the the mocha approach to doing this that would change its relationship to requirements on the base draft? Or if that's, you know, if this is kind of like a fixed, you know, here's here we did this like and now we're, you know, moving on.
[01:17:42] Cullen Jennings: Nope. Nope. Mike, it's it's very much it's we're really happy to make changes on this and discuss other ways of doing it because we think the key thing for driving forward people to understand the requirements is to have some agreement around the requirements. Right? So if people look at the way we're doing some particularly functionality in here and be like, you know, there's a different way of doing this that would be better and align, would make the base transport draft simpler and still do everything you need. We're very open to putting the changing the drafts, putting those in, talking about the pros and cons of those, even enumerating multiple ways of doing it in the drafts with so people could think about them well and then pick which one was an appropriate one. You know, that's that's the type of conversation we wanna drive here.
[01:18:23] Mike English: Excellent. Thank you for this then. This is this is very helpful.
[01:18:27] Jared Jennings: Yeah. Colin, this is Jared. I'd also like to thank you for doing this. I think one of our obstacles has been a lack of understanding between the live streaming and VTC communities, and this is a huge, a very productive effort to try to bridge that gap.
[01:18:42] Cullen Jennings: Thank you. This has taken time away from other things that would have been also productive for getting the draft done. So
[01:18:50] Jared Jennings: Okay. I I actually think this will help clear some roadblock. Not having read the draft, I still think it'll probably likely clear some roadblocks. Thanks.
[01:18:57] Cullen Jennings: Yeah. Okay. Thanks.
[01:18:58] Jared Jennings: Okay. Moe, you're up. You get
[01:19:00] Participant: the rest of the you you you take us the rest
[01:19:02] Jared Jennings: of the way.
[01:19:06] Rohan Mahy: I was just gonna say that
[01:19:09] Jared Jennings: Oh. You know Alright.
[01:19:10] Rohan Mahy: I read all these, and I had a question about sender sidetrack switching. What you want to ask offline?
[01:19:16] Jared Jennings: Oh, thank you, Ron. Sorry to sorry to miss you there. I was busy ranting. I'm gonna give you slide control, Moe, and take this home.
[01:19:25] Moe Zanaty: Yeah. Moe Zanaty here to talk about is this working? Oh, there we go. Moe Zanaty here to talk about the top tracks filter. We've called it in the past. It was called the max tracks selected filter, and and people usually just call it top in. So we're calling it top tracks filter now. It's in the PR fifteen eighteen, and it was in originally PR 14 o one. And we may wanna clean it up this weekend and put it in a totally different PR to avoid all of the old stuff that was in '14 o one had three different filters, location filters, range filters, and track filter. Fifteen eighteen has range filters and and track filter. So maybe we'll just have
[01:20:10] Ben Bockshear: a clean separation, put track filter, top tracks filter all by itself.
[01:20:16] Moe Zanaty: So to make sure people understand what the use cases are, this is allowing a subscriber to basically do a fan in kind of application. It wants to grab data from a lot of publishers. So mock traditionally is the fan out. Right? One single publisher to many subscribers. This is the opposite. This is a a subscriber wanting to monitor a large pool of publishers and only sample a select group of those publishers, only n of those publishers in that large pool of publishers. And what are the use cases for that? Well, in in conferencing, it's essential. It's absolutely required for all conferencing systems. So you wanna select the top active speakers and only show their video streams. So you may have, you know, four active speakers on on screen at once. Same thing for, like, a security cameras. If you had a site canvas with hundreds of cameras, but your monitor only shows, you know, 16 at a time, you wanna select the ones with the top suspicious activity. People watching esports, you wanna see the top two highest scoring players and watch their gameplay battling it out. You could think of applications where a publisher's video feed can get feedback tracks that are like upvotes. And so you can select the top upvoted tracks. And so you're dynamically seeing what are the most viral you know, 16 most viral videos at once. And these are all media applications, but you could also consider non media applications like, you know, in in financial markets, bids are, you know, very common. So you could just say, give me the one highest bid out of this entire pool of bidders. So you can imagine all kinds of applications like that. One thing I didn't mention that I just heard brought up is feedback tracks. If a publisher is fanning out to lots of subscribers and it wants some feedback from those subscribers, but it doesn't wanna be overwhelmed with millions of tracks of feedback. It can have those feedback tracks on the top end filter so it can say, I only want the top three highest latency feedback. And so you only get the highest latency from the three highest latency subscribers coming back to you. So it's gonna be used for fan in of feedback tracks. And those are the client benefits. We'll put together a slide for what are the relay network benefits. Now the relay network is typically out of scope for mock. We don't talk about the inner relay connections. We only talk about the subscriber or original publisher connections to its edge relay. But within the relay network, top end has a huge benefit because if you look on the left without top end, subscriber on the bottom that wants to monitor 400 tracks has to subscribe to those 400 tracks. It'll subscribe namespace to the entire namespace and get
[01:23:01] Jared Jennings: 400 publishers. Moe, We've got eight minutes. Do you think we could maybe just move to the open issues?
[01:23:06] Moe Zanaty: There are no we've closed all the open issues. I wanna make sure people understand the use cases and the benefits so they can make an educated decision about whether this should be in the core draft. Does it address enough core use cases, or should it be an extension draft? So if you see on the left, each one of those relay nodes is handling all the publishers directly connected to it. A 100 at the top level, and then it aggregates the 200 at the mid level, and then it aggregates even more down to 400 at the bottom level. So you have large volumes of traffic across all hierarchies of that network and worse as you get to the edge. Whereas with top end, the subscribers allowed to say, I only want the four highest tracks. And each of those relays can propagate that filter upstream. And so it's only getting four on every one of its upstream links to its directly connected relays. And those relays can request four all the way up the tree. And And so you end up with pruning at all levels of your relay network. Realistically, you would never do this. The application would never accept that bandwidth. And so what ends up happening is you don't use mock. You cannot use the mock relay network at all. You have to put your own app servers in those places where the mock network nodes were and do your top end filtering on your app servers. That's what everybody does today. That's what every single video distributor does today that needs to select a subset of tracks. So mock is useless for those people if it can't do this function. You have to deploy your app server anyway. Just run the mock relay on your app server. You don't need mock at all at that point. This is the design. Fits on a single page. It's not complex. There's a single setup option, so it's already negotiated as an extension. It's a setup option, max top tracks, that tells you that that tells the the relay is telling the client how many maximum tracks you can select. So 1,000. One of the things we just did recently is we reduced that down to two fifty five. It's only a single byte now, so you can't you can't request thousands of of tracks. That simplifies the data structures that you need to implement this. So you don't need very big complicated, you know, multilevel tries to to make this efficient for scale. And then inside of subscribe tracks or request update for it, you have this top tracks filter parameter, and it just specifies the property type that you're watching so you can see what the highest values of it are and how many how many tracks you want, the top in that you want out of that track. Simplifications we've made, you can see those. Simplifies the data structures, allows the the relays to pick when they wanna reserve or out or release their resources. And now we reduce the number of parameters down to just two, property type and max top tracks. This is the state machine for how you transition from an unknown track, which is unselected. You don't the the subscriber doesn't even know the track alias. And then when it becomes selected, the relay will forward a publish so that the subscriber understands the track alias and then starts receiving those objects. When it falls out of the top end, it can get a request update forward zero to tell the client you're not gonna get data from this track anymore. Another track will come in and replace it. Eventually, when the relay wants to reallocate those resources to something else, it can reclaim those tracks by sending publish done to go from deselected back to unknown. Pretty simple state machine. The concerns heard were maturity. We've we've been iterating on this for a long time, almost a year now. We have real world implementation experience. We've implemented in in in in three different relays. The complexity was an original concern. We've reduced the the parameter counts. We've changed the limits on those parameters so that simpler data structures could be used. The spec text has been drastically reduced down to only about a 150 lines or less. The design time complexity is much simpler now because you have many open source implementations, so developers can already pull from those to see how others did it. The runtime complexity, which is was a big concern for some people, we've demonstrated it in all the current applications that have deployed this. It's less than 1%. It's trivial compared to the QuickStacks basic processing. There were concerns about amplification and asymmetric attacks. We added sections describing how relays could protect themselves in those cases. And there's ongoing DDoS, you know, work. So we'll work with Mike to figure out, you know, what other what other avenues are there to close there. These are the implementations that are out there. Mocktail has it. Quikr has it. Cloudflare, moq-rs has it, and OpenMock, moq-x has it. So we've demonstrated in all of these different products. Go ahead, Magnus.
[01:27:50] Magnus Westerlund: Yeah. I'm just relaying Alan. If subscription state updates, publisher notify lands, would you bring back deselect select notification?
[01:28:04] Moe Zanaty: The deselect to select notification is a request update with a forward equals one. Is that what you asked?
[01:28:10] Magnus Westerlund: Yeah. I think Alan Anders, if you if you get back publishing notify all the state updates, would you bring back them to these rates?
[01:28:19] Moe Zanaty: Oh, no. Yeah. No. We would we would definitely prefer the publish notifies. Yes. That's better. That's a better mechanism than the request updates. Cuts the traffic in half. Cuts the control traffic in half. And this is just a slide to show that the runtime complexity is is, like, you know, one percent or single digit percent in in running relays. Yeah. So the next step is we we would like to see if people are willing to get this merged into MOQT.
[01:28:45] Magnus Westerlund: Yes. So we already have consensus to work on this functionality. So and I think I saw some in the chat, at least, cleared for a new PR, a new clean PR. Can you do that? Yes. Yes. So the proposal, I think, from here for shares is that you clean up the PR. We will start question on the mailing list first to see if there's some is it here only two options? Is it merging directly? Is it ready for that? And do basic consensus call on the mailing list so people are chance of reading this and determine if it's ready or not? And if someone has other options for how to work with it, they can propose it. But from if we will do at least one clear if it's ready to merge. So we'll do that on the mailing list so people have some time too. And then we know we've got going into some vacation times for at least for the Europeans, etcetera.
[01:29:51] Jared Jennings: Rohan, please be brief.
[01:29:53] Rohan Mahy: Yep. I need this. I'm using you know, I'm doing something with WebRTC right now. It's killing us. Like, I was looking at what features I needed, and this is like, this would solve this would solve, like, 98% of my problems.
[01:30:12] Jared Jennings: Thank you. Ben?
[01:30:16] Ben Bockshear: Real quick. Who decides which streams get selected? Ben Bockshear. Who decides which streams get selected on which place?
[01:30:26] Moe Zanaty: Recycled streams?
[01:30:28] Ben Bockshear: Which which which who selects which stream is the top track?
[01:30:31] Moe Zanaty: The relay. So the relay is is is monitoring the objects' properties, and the objects that have the largest values of those properties go into its into its selection list. So the Relay maintains a ordered list of the top 10 tracks. And as objects come in, it decides whether that object gets forwarded or not, whether it goes into the top 10 Lint or not.
[01:30:50] Ben Bockshear: And and who decides this value, what is the top, what is the highest value? The
[01:30:54] Moe Zanaty: real really, a lot of it is the publisher publishes the value.
[01:30:58] Ben Bockshear: The publisher itself. Gotcha. That's what I wanted to know. Thank you. Alright.
[01:31:04] Jared Jennings: Thank you all for hanging out to the bitter end. Enjoy. Please have a good trip to wherever it is you came from, and we will see some of you in Seattle. The rest of will see in San Francisco.
[01:31:34] Ben Bockshear: You're asking me at the start about why I was interested, and I didn't want to just