Session Date/Time: 26 May 2026 16:30
Here is the complete verbatim transcript of the meeting:
Martin Duke: All right. It's 9:30. We'll begin. Welcome to the Media over QUIC virtual interim, our last one before the London meeting. This is the IETF Note Well. It talks about the intellectual property implications of you being here, as well as the scribing, the code of conduct. If you're unfamiliar with these documents, please, you can scan the QR code or you can type IETF Note Well into your favorite search engine and find out more about these topics. You've already figured out how to get into Meetecho because you're here. Please turn your audio and video off unless you're planning to speak. There is a roughly one-second latency when you turn on your sound, when you unmute yourself. So, please anticipate that and press unmute a little early. I strongly recommend you use headphones. The echo cancellation properties of this tool are not great. If you are participating in conversation and you do not use headphones and your echoing is wrecking everyone else's audio, we will mute you aggressively, which will make it very hard to talk constructively. So, I strongly recommend you go get yourself some headphones, as I'm wearing right here. For any technical chat, actually any chat, use the Zulip button, which is the quote bubbles at the top left of your chat tool, of your toolbar. You can also enter the queue by raising your hand using the hand symbol that is in the bottom center of your screen.
Okay. Upcoming days, we have all kinds of stuff happening. Last interim meeting, two weeks ago, we had a filters consensus call initiated from that. Today is the last day to comment on that. We had some shows of hands to supplement that consensus call. If you did not participate in the show of hands and you would like to comment on the status of those changes, please send something to the list today, or the chairs if you prefer, if you wish to be private. I strongly recommend that you watch on YouTube that meeting if you did not attend, or at the very least read the minutes. But, the much richer discussion of course is in the recording than in the minutes. We are also having, we've already opened a consensus call for what we're going to discuss today, so that we can get it concluded before the London meeting. I mean, you're here so you're going to listen to this discussion. We're going to have a show of hands at the end of the discussion. If for some reason you don't feel equipped to do the show of hands until you go read the document, that's actually great. Go read the document, send the comment by June 4th, and we will hopefully have this all resolved by London.
In London, the agenda is dependent on the outcome of that consensus call. So, I've published an agenda for the hybrid interim in London, and it has two branches depending on how this switch consensus call goes, and of course it also includes the DTS consensus call. Okay. June 8th, there is the deadline for comment on interim dates. I don't have them written on here, but I've announced two potential interim dates. I believe it's the 22nd of June and the 6th of July between London and Vienna. If you have any concerns about those dates or the way we're doing virtual interims, please share that with the group. And, I will finalize those dates on the 8th of June because that is the two-week deadline to schedule a 22nd June interim. So, oh there you have the potential dates, the 22nd and the 6th. Yeah, it's actually on the slide if you keep reading. I forgot I put it on there. And then finally, that runs us into IETF 126, from the 20th to 24th. We don't know, we've requested two sessions. I don't know when.
Magnus Westerlund: Actually, we have requested three.
Martin Duke: Oh, we've requested three? Yes, Magnus.
Magnus Westerlund: Yes. I went all the way to the top. All the six six hours of potential blocks, if we get it. But, for information, that might mean that we get the last session on Friday, things like that, because to get spread out or using the whole getting in the time, we will probably end up in the least preferred slots for at least one session. So, yeah.
Martin Duke: Yeah, I might have missed the Monday morning, but I will know in a couple of days and I'll edit our session request if that is a concern. Okay. Moving on, any questions about this? This is the typo-ridden agenda slide. We are in admin trivia right now. We're going to give out 35 minutes to Gwendal for SWITCH, so that'll run till 17:10 UTC, and then we're going to give 35 minutes to Will, and the reason the slide is supposed to say is the last 15 minutes we're going to use for a show of hands for both, for both improvements, features, I guess you could call it. So that of course can run 17:45 to 18:00. So, I see Gwendal is on, so I am going to stop talking, stop sharing slides, and Gwendal, take it away.
Gwendal Simon: So, should I request slides or screen share? Slides, I guess.
Martin Duke: Yeah, slides.
Gwendal Simon: And where, how do I—oh, okay. Uh. So, SWITCH proposal. Okay, I hope it's the latest version I uploaded. Okay. Um, so, um, it's about SWITCH. Issues, I mean, or PR 1378. So, I mean, now we are greater than 1600, right? So, it's a, it's an old PR. Uh, so, the, what we are talking about, we are talking about some switching capabilities, which come from use cases coming from the live TV streaming industry at large, I would say. So, OTT are also concerned by this. Um, in, in this world, in this live TV streaming or live streaming industry, a subscriber usually decides ABR switching based on some, I mean, ABR like adaptive bitrate, based on a multitude of, of parameters, of incoming parameters. And, there are like many algorithms that have been designed for years. And, some of them take into account actual throughput of the connection between the servers and the clients, and the edge servers and the clients. But, most of them take buffer level depletion risk, playback rate, hysteresis is something which is very important because we don't want to switch constantly between low and high quality tracks.
Um, the player mode is something which can drive some decision as well. And, in the end, observation of the throughput, but history-based prediction of what will be the next point. So, it's something which is much more sophisticated than just saying, "Hey, we are under a threshold and we want to move." It's something which is more like, okay, based on what I have, I know that this can be temporary or not, or something like this. And, it's, ABR is just one aspect of the use cases we have for switching from one track to another track. Uh, we can have changing camera in multi-view events. So, if you tested the Formula One app, you can see what's, what's happening. You can switch from one driver to another and you absolutely want to have continuity in the actions. Uh, you can have changing settings in, in to your audio, into, I mean, typically audio. You can have something which is just the client saying, "Hey, I don't want to have 4K anymore because I have some plans issues," or something like this. VR headset is something which is always referenced as well, and sometimes the rendering capabilities of the device itself, the hardware processing, the decoder, can be a reason to move. All of this to say that actually here, the subscriber is the one who triggers the switch, and he or she is the only one being able to do this. Because, this is information coming from the, from the subscriber. So, we want to have something where we expect the, I put my camera on, by the way, where we expect the subscriber to be triggering switch.
Okay. Any question so far? No, okay. Uh, so, yeah, it's not the latest version. I tried to upload the latest version of the slides, but in fact, it has not been, there has not been approved. So, can I stop the slide share here and share my screen instead? Let me, yeah. I want to confirm closing the deck, and I will request screen share. Can you give me screen share? Yes. And so, how does it work in that case? Yeah, this one will be good. Okay, so, you see my screen, right?
Magnus Westerlund: Yes.
Gwendal Simon: Good. I can, I can see it as well. Good. So, well, here, I mean, there is a important concept to understand, or concept or use case to understand. It is that we have often scenarios where we have a subscriber who lags behind life. So, here, we have a publisher generating, so, here, I put numbers, these are groups. So, instead, I mean, I didn't put all the objects of the group, I just put groups. Group number 29 with objects 0, 1, 2 until the end, 30, 31, 32. And so, every let's say every second, we have a new group, let's say, for simplification. Relays send this to the subscriber. And, what you can see, that the subscriber is lagging behind life because, here, at the time, let's say, it receives 29, but what it is, but what the player is actually playing is 25. And, this is not a bug, this is, this is a reality of how OTT is working today. We, the recommendation is to have three, four groups in the, in the buffer so that we can have, you know, we can absorb whatever is happening. So, it's good or not, I don't know, but at least, this is something which is, which is the reality of what we have.
And, here, in this scenario, after the group number 20, 31, we have the group number 32, which, and there is a congestion. There is something which is congested. And, at this point, the congestion occurs, but the player still has three groups in the buffer. So, it is not in, I mean, big danger. And, this player, this subscriber, decides to stick to this, to this track. But, the condition deteriorates and 33 takes forever to come. And, when the 33 is finishing the action, the, I mean, the delivery, then, the, the subscriber, the player is in jeopardy. And so, here, we have a buffer depletion, client is playing 32 while receiving 33, and this is, this is not good. It must move.
Martin Duke: Gwendal?
Gwendal Simon: Yeah.
Martin Duke: Uh, we've been talking about SWITCH for a long time. Um, and you're spending an awful lot of time running through like the basic motivation. Um, I-I've asked on the chat if anyone needs this. No one has spoken up. Maybe they don't. Maybe we could just move to what the tension points are that are preventing this from being adopted, uh, and just have more time to discuss those.
Gwendal Simon: I, I think this slide is important, uh, as, and—
Martin Duke: Okay. I mean, you can use your time as you want, but it's my recommendation. Okay.
Gwendal Simon: It is, it is the last motivation slide I have. So, it's, it's, I just want to make sure that people understand that, uh, it's not, you know, temporary network congestion that, uh, is the reason to, to switch. It's a multitude of, of opportunities. And, here, what we have is that the, at the time the subscriber receives, uh, yeah, it is order ascending, order. At the time the receiver receives 33, the relay receives something which is 36-ish, 37. And so, if the subscriber sends the, subscribe at that point, it will receive something which is 37, which means that this, this guy is actually three, four groups behind the, the relay. And, it doesn't exactly know where it is, meaning that it, it knows that it is lagging behind live, behind live, obviously, but it doesn't really know where, and it doesn't really know if the relay has the, low-level quality track, and it doesn't have any information about what it can expect to have, uh, as soon as possible to change this. And, this is where we need to have some specific actions for the SWITCH. Um, I see Victor in the queue. No, no longer in the queue. Uh, so, this is the main point of the, of the, of the system. And, this is where the combination of subscribe and unsubscribe, and all the priority management, when we discuss this in previous meetings, it took a long time, but we agreed at some point that, yeah, it's a gymnastic which is very complicated to do, to do. Luke, for queue.
Luke Curley: This is probably on the next slide. But, for this use case, do you want 33 next for the subscriber? Or do you want 37?
Gwendal Simon: I want to have continuity of the, of the, of the—so, you want, you want 33. Okay. I want to have 34, but 34 from the track with low quality.
Luke Curley: Okay.
Gwendal Simon: Because I want to switch ASAP. In fact, I would like to switch before 33. And, I mean, while I was receiving 33, probably the, the subscriber should have taken the decision earlier to, to move. And, in that case, one action possible is to come back to the 33, because I do prefer, I mean, sometimes the subscriber prefers getting rid of what it has received and getting the 33 from the, from the better quality, I mean, from the lower quality track, because it knows that it will not deplete the buffer too much. And, this is one of the options we, we propose in the, in the system.
Suhas Nandakumar: Gwendal, just a clarification question. So, when you say you wanted to receive 33 from the lower quality track, that was, does that mean that that track also has lower priority compared to the current track?
Gwendal Simon: Well, I mean, if I, if, I mean, here, at the time we propose, the, the decision is taken in this specific slides, since I receive 33 already, I'm good with this. But, I want to have 34 ASAP. If I took the decision earlier, and I started asking for 33 for the lower quality, then I should stop 33 at high quality, I should have, uh, high priority for the 33 of the low quality, uh, track. The problem is that I don't know if the relay had 33, and I don't know how long it will takes for, for the, for the relay to, to have it, so, it's a risk which can be hard to take.
Suhas Nandakumar: Thank you.
Gwendal Simon: So, what, what we say in that case, uh, what we need to do to, to have is a very simple message to say, "Well, uh, I'm, I want to to, uh, move from the, I mean, I have a current subscription, track A, let's say, and I want to go to the new track. So, I will need to just send track name, namespace name and name. And, this minimum switching group ID, it is the earliest group ID at which the subscriber permits the transition. So, at, when I was, uh, if I come back to the previous slide, here, it would be minimum group transition would be 34. Okay. I want to go for 34. But, if ever the, the player had taken the decision before, while it was receiving 33, it could say, "I want to move to 33." And, if the relay has 33, then it would stop track A 33, and it would go to 33 track B. So, we address the use cases that Luke, uh, raised during the Boulder interim like this. I can stop the delivery of the current group and I want to replace this delivery with the, with the new group. And, this parameter, minimum, uh, minimum switching group ID is the one carrying the information. Yes, Victor.
Victor Vasiliev: I am really confused. So, like you say is that your buffer runs out in the middle of you receiving 33. But, you're saying that you want to start with the new, new track with 34. So, what happens to the rest of group 33?
Gwendal Simon: Here, I just received 33, right? So, that's why I want to switch to 34.
Victor Vasiliev: When you say you received 33, do you mean like completely received 33?
Gwendal Simon: In, in this example, yeah. The, the dotted line shows that we received the entire group 33. The subscriber received it, can put it in the buffer immediately. The player is playing 32, so, technically, the information is just on time. And so, we can prevent re-buffering at, at this, at this point. But, if it looks like the congestion is serious, and so, we don't want to continue with this track, we need to move to the new track as soon as possible. And, we need to move to the new track with the, for, the next group, and the next group is 34. So, I want to move to the new track with the group number 34. Oh, we can see it. Yeah, um, no, you said an interesting thing there, "as soon as possible." Um, because to me, SWITCH is not as soon as possible. SWITCH is depending on what's in the cache of the relay.
Luke Curley: Correct.
Gwendal Simon: So, we have a buffer empty and we're saying like, "Hey, we're on 1080p, I really don't want the next group, but it's up to you, relay, if we switch down, or if we wait on a fill." Um, I just want to verify that's the behavior you want, like, your buffer empty and you're downloading 1080p, and you want the relay to decide like, now you don't need, you know, 360p for this next group because they don't have it yet. And, and you just committing to downloading like 6 megabits for the next 2 seconds because of that relay decision, or if you want to wait for a fill from the publisher. So, uh, well, here, we, we let the relay decides what's the best option, and when is the next possible, I mean, the earliest possible, uh, switching point. So, the earliest possible switching point, it is in the algorithms later. So, here, you can have relay which are more aggressive than others because this decision of, uh, what is the earliest possible, uh, group boundary at which you can switch while preserving the continuity of the, of the flow, depends on if it fetches, if it has this in the cache, and what are the other, uh, information it gets.
Luke Curley: I, I mean, I'm getting, I guess I'm getting at what, what do you as an application want? Because, there's a lot of vagueness about what the relay is supposed to do if it gets a switch message. What, what do you actually want to happen?
Gwendal Simon: So, I mean, this, this use case is a bit extreme because the subscriber waits a long, long time before, before moving. But, what we want is to have the earliest possible switching capabilities, which is in the past for the, for the relay. And so, this is why you, the relay is the best one to, to take the decision, because the relay knows what it has in the cache. This is what we feel, but so, it's, we let the relay decide what is the best for my situation, I would say. Suhas.
Suhas Nandakumar: So, I'm just trying to clarify requirements here. So, assuming that the relay was subscribed to both the high and low-quality stream and it fully had like all the groups in its cache that we're talking about here, so, at like, the relay has everything right now. If I sent a SWITCH with the earliest, so, at the time point you described there, but I sent my, I set the earliest group to, let's say 30, so, I've already received, received 31, 32, and maybe part of 33, and I set to 30. What happens in that case? What, what does the relay send to me?
Gwendal Simon: So, if I send, if, I mean, if the subscriber sends SWITCH now, the, and with the minimum, uh, group being 30, 34, if it has everything in cache, it will—
Suhas Nandakumar: Not 34. Send it with a minimum group of 30. Says SWITCH now with 30.
Gwendal Simon: It, it will, it will send back from, from 30 if it has everything. And, it, it means that the relay understand that if the minimum switching group is 30, that this guy is just like playing something way in the past, and it can remove everything in the buffer, it is his responsibilities, but it will send 30, 31, 32, 33.
Suhas Nandakumar: So, would it clear things out of, so, on the like, let's say I'm switching from the high track to the low track.
Gwendal Simon: Yeah. Yeah.
Suhas Nandakumar: At the point I switch, does it clear things out of the high track as well? That was, that was queued to send.
Gwendal Simon: Yeah, yeah, it stops the, the delivery of the high track, and it will deliver the, the low track exactly as you—
Suhas Nandakumar: Okay. I think I'm still trying to get my head around all of that. Thanks.
Gwendal Simon: Yeah. We kind of need to move quickly if you want to finish on time.
Aman Sharma: Uh, oh, okay. Um, quick question, is the assumption that the two tracks are group-aligned?
Gwendal Simon: Yeah, so, I mean—
Aman Sharma: That's fine, I'm just, I-I just want to clarify, state that out loud. That's fine.
Gwendal Simon: Yeah, correct. Um, but it doesn't mean that, that the two tracks have all the groups aligned. It's that they have some alignment in some, in, in, in, in, in some time. In fact, the decision of which is the group boundary that the two tracks have approximately at the same time, the, not approximately, the relay has in the buffer of the cache two tracks with the same group number.
Suhas Nandakumar: I didn't understand that answer. Can you say more just about the times when only some of the groups are aligned?
Gwendal Simon: Yeah, so, this, it's, it's, comes at, at the next one. So, the—unless Mo wants to, to, so, what, just, just to, to, the selection of the smallest common group boundary, so, the switching point, the switching group, here, it's G switch. It is, the group G switch exists for both track A and track B at the relay, meaning buffering cache or information the relay has. And, what is in the spec is that we say that the two, the group exists when at least the header of the first object of the group has been received. So, if I received group 34 object 0, just the beginning for track A, and the same for track B, I say, "Hey, this is a group boundary because there is a request for switching from track A and track B, and both tracks have the same group number as, as far as I can see." And so, I consider this is a, this is a group alignment. There is no timeout for this. Sorry, Mo.
Mo Zanaty: Yeah, um, just, uh, to clarify. SWITCH, uh, the base SWITCH is for a single other track, right? And it's still purely a client-side ABR decision. So, the bandwidth estimate is coming from the client, and the target SWITCH track is only one of them, and that's coming also from the client, right? So, I just want to make sure that before we get to DTS that this SWITCH is a single client-side ABR fully driven by local bandwidth decisions, nothing to do with the relays.
Gwendal Simon: It, it, it is driven by whatever, as I put in the first slides, which is the decision of the player, which is based on any kind of information it has.
Mo Zanaty: Okay.
Gwendal Simon: Which can be application level.
Mo Zanaty: Got it. That's it.
Gwendal Simon: Yeah, can we move quickly, uh, because I have couple of other information we need to, Ian for queue?
Ian Swett: Yeah, sorry, Meetecho booted me for a sec. Uh, can you go forward one slide? I had one more clarification question. Um, the, is the SWITCH only for groups that are in the past? Like, oh, two more slides, sorry. One forward. Uh, two more. Oh, this one? Okay.
Ian Swett: I think slide 5. Yeah, the transition group. I was trying to read through the transition group logic. Do the, does the transition group have to be a, it says, "the group G switch exists for both A and B at the relay." So, it must be in the past in some sense.
Gwendal Simon: No, no, the minimum switching group can be in the past or it can be in the future. It is just one indication. So, the, the, the choice of this smallest group boundary G switch, it is G switch exists for both A and B at the relay. G switch is greater than or equal to the minimum switching group. And so, if you put switch, "Hey, I want to switch at group number 40," which is, I mean, which would come later, you can. If you said, "I want to go back in the past and I want to receive groups from, from the past because my buffer is, I don't know," then, it's good as well. For the, for the relay, it's just something which is completely transparent. And, the other information, which is close to what we had in rewind, is that for every group in the G switch life edge, if the group is available for A, the group, the same group should be available for B, meaning that we have continuity for the group between the two tracks. And, at some time, it can happen that the timeout, we didn't, I mean, the relay does not find any common group boundary, and so, it just fails. So, there is a kind of, we, the relay says, "Well, I can, I can guarantee continuity between the time I decided, the G switch I decided and any event in the future." So, this is, I mean, this transition group algorithms is basically checking the buffer, checking the cache and seeing if it can do anything for this. The point is that, because we introduced some, some point of, lagging in the past.
It is, if G switch is earlier in the past than live edge, in that case, you need to fetch, right? Because you need to send objects which are in the past. In the example, it means that the relay is receiving 37 from the original publisher, but suddenly, it has to create a new track, I mean, create a new publish for the, for the, I mean, to do the, the, the switch, and this publish should start in the past, it should start at 34, although it is receiving 37. So, between 34 and 37, you need to fetch, right? And so, for this, what is suggested in, uh, 1378, uh, PR, that the publish carries a SWITCH transition parameter. This is the, last slide, I mean, footnote, which is, that says, "Hey, G switch is 34, live edge is 37, I will distribute a new publish for this, and so, at that point, it just opens a uni-stream starting with fetch header, and it sends all the objects which are between G switch and live edge." Okay. And then, it finished at this point. And then, it continues with the live track B delivery on the sub-group streams, exactly as a regular publish. So, it means here that we have, I mean, I want to clarify this. It means here that we, we start a publish with objects that are fetched, and so, we maintain the, the fetch semantics here, by this fetch header parameters, when we have to send object in, in groups in the past. Mo.
Mo Zanaty: Um, to clarify, you mean the relay actually sends a publish message? The SWITCH message did not establish subscription to B? The relay has to send publish to establish subscription to B?
Gwendal Simon: Yeah. The relay, when it receives the SWITCH message, okay, there is a current subscription request, ID, and when it receives this, this, so, this is the current one that it will stop at the time of the group boundary, and then, it will create a publish, and the publish, it opens a publish for track B.
Mo Zanaty: Publish on B? Or is the publish after the SWITCH requirements are fulfilled that it has both groups?
Gwendal Simon: Sorry, I didn't—
Mo Zanaty: Is, is the publish immediately in response to the SWITCH, or is the publish only after you've fulfilled the, both groups of, of the same, of the two tracks being available, and they both, they both are greater than the minimum?
Gwendal Simon: Yeah, it, it, it reply by a publish when it finds a common group boundary G switch. Meaning, it opens a publish for track B when it has, I mean, no, it opens always the publish when it receives the SWITCH, but it can be a publish which is immediately published done if it fails. And, if it finds a common group boundary, then it indicates the SWITCH transition parameter with G switch live edge, and, and it sends with the fetch.
Mo Zanaty: Okay. I was just trying to, I was just trying to understand the timing of the publish. The publish is not instant after the SWITCH, the publish is after you're actually going to start getting the real data.
Gwendal Simon: Yeah, when, when you, when you identify the G switch group boundary. Correct, thank you. Luke.
Luke Curley: Yeah, I was just going to piggyback. Uh, it feels like this is kind of like subscribe update, or like request update. The publish seems a little weird, because you need some way of like associating that this publish was caused by the SWITCH, but this is just nitpicking.
Gwendal Simon: Well, we discussed this multiple times. I thought—
Luke Curley: I think it's fine. I don't think it's critical to talk about, so, ignore me.
Gwendal Simon: If, if we wanted to have a subscribe update and player subscribe update, we needed to, to have the subscriber sending two request ID and so, that play with this. Here, the, the relay can send, can decide the, the request ID and it's, it's, it can of clarifies. And, the uni-stream that carries the fetch, uh, information is, is sent on the uni-stream. I have a slide for just this because this is something which is, which is a bit new I want to say in this debates. Uh, so, the SWITCH creates one target track request context at the relay. And, publish seems to me as a natural downstream semantic for this because we want to have something which is close to subscribe. Okay. But, if G switch is in the past, we need to send catch up, I mean, we need to catch up data, okay? Um, and so, the relay opens the dedicated unidirectional stream for catch up, start with fetch header, delivers group, and then, the live objects following on the sub-group. And so, we don't need extra request ID, we don't need any cross-stream correlation for this. And, while the catch up is in flight, live objects accumulate in the relay queue, and are delivered in order. So, this is something which doesn't require any subscriber, subscriber coordination with the priority, uh, management for this.
So, we do, I mean, I don't have production-level stuff, but we have an implementation. So, we have, so, we have three actually, I kind of discovered the, the Nokia's one, and I could not get, uh, more details about it. But, we have a Moxigen fork and a Moqex relay draft, uh, which is 287, uh, which doesn't have all the, I mean, it's, I mean, I, I did not test all the parts because it's complicated to test, because you need to create congestion, the relay, and you need to create all the, uh, actions. But, at least, we know that we can clean switch, uh, with flag, without lag, and we can switch under lag. And, the first bullet I should have put it in, below because inline catch up path verification works, error path works as well. Congestion simulation and concurrent switch and subscriber race, I have not. But, it's something which is, so, I, I do have the two first bullet of next test, which are now in the, in the system. And so, there is a kind of implementation, for it. I don't have anything in production, for this. Uh, but, this is because well, uh, it's not adopted, right? And, what, what else do I have? I think it's over, well, no, I mean, this was the discussion on this. But, so, I, I think this, this point of, putting the fetch, uh, information in the publish is something which is, um, interesting, because it's explain, a very simple way to, just survive from lags. But, if you don't have any more question, I can give the floor to Will with 2 minutes, ahead. Well, so, I'm in the queue as an individual. Can you go back to slide 2?
Gwendal Simon: Slide 2?
Martin Duke: Whichever one has the, the packet diagram. There, great. Okay. So, now, go, go where you just were. Okay. So, uh, you said, okay, so, you wait, so, you want, ideally you want to start at 33 with a low, with a lower bandwidth track, right? Whichever number, 33, 34. Okay. Say it's 34.
Gwendal Simon: 34, yeah.
Martin Duke: Okay. So, the way we would do this with the spec today is I would send join, uh, I would, I would send a request update on the old subscribe to end the thing on 33, the end the old track on 33, and I would send a standalone joining fetch, absolute joining fetch, on 34, right? So, I might, I might get some fetch stuff, I might get some subscribe stuff, I will get some subscribe stuff depending on the state of the relay, or the relay's live edge. So, do you agree that if the relay has everything, like with that assumption, that this is fundamentally like the behavior exactly the same from a subscriber perspective?
Gwendal Simon: Uh, it's not exactly the same because first, you would receive the joining fetch plus the subscribe at the same time. So, you will receive, uh, the low track 34, 35 due to the fetch, and 37, 38, 39 due to the subscribe. And so, you would have, exactly at the time where you are short in network, uh, a double tracks, uh, delivery of—
Martin Duke: No, because I'm sending a request update to terminate the subscribe at, at 30. No, but you, but you need to have the subscribe for the, for the new track before you are going to the joining fetch. So, so, what I'm—
Gwendal Simon: So, you will—
Martin Duke: What I'm arguing is that you will simultaneously send a request update, a subscribe and a joining fetch.
Gwendal Simon: Well, it's mandatory, right? If you want to use, uh, joining fetch, absolute joining fetch, track B, it's because you sent a subscribe track B before.
Martin Duke: No, these can happen in the same flight.
Gwendal Simon: Yeah, it can happen in the same, yeah, sure, but the data which is delivered from the relay will be both the fetch and the subscribe, which is not what you want, because you want to, suddenly you have double—
Martin Duke: I want to comment on I just want to comment on that a little bit. It depends on priority. You're not going to receive both, if the priorities are set, you can get the fetch first, or if the priorities are set the other way, you can get the subscribe data first. So, it's not you're going to get those both at the same time. That's not true, what you're saying.
Gwendal Simon: Yeah, correct. It is, it is the subscriber—
Martin Duke: All right. Well, all right, well, we're out, if you can finish the point, we're out of time. Uh, so, we're, I mean—
Gwendal Simon: No, yeah, yeah, sure, sure.
Martin Duke: We don't have time. Okay. So, uh, I'm sorry, Colin, did you have something else you wanted to say in the queue? Okay, great. Will, you're up.
Will Law: Okay, I also want to, uh, request, I want to do a screen share. I, I'm trying, you're sending me slides, but I want to do a screen share. Now, we should, yeah, okay. Now, I see it, Will.
Will Law: Okay, it's working. Thank you. Uh, I need to turn my camera on. You can see me, act surprised. So, uh, this is DTS, Dynamic Track Switching for Mock Relays. This was first, uh, a design team that got together at the end of Boulder. We then made a presentation at IETF 125, there was feedback from the group. So, this is the second presentation that is showing you that feedback and showing you the revised implementation, uh, that has been developed. So, we call it DTS because it's switching between two tracks. This is server-side switching. So, to separate it from what Gwendal was showing, which is a new API, the client is still dictating what the server switches, but the server executes the switch, and in this case, does it based on a bandwidth decision. I'm not going to revise the use cases that we developed for this. Uh, they are presented here on the slide.
So, the general approach has been simplified. Number one, we have a single new parameter, which we call switching set assignment. And, the way it works is you decide what tracks you want to switch between. You can do this either by reading a catalog, if you have one, or if you don't know the tracks ahead of time, you can do a subscribe namespace with a track filter, assuming that gets, um, in, and then the client will notify you with a publish message and then you can use that in the publish. Okay, you can also use that switching set assignment parameter. So, you've got two different vectors for figuring out the set of tracks you want to switch between. Uh, our assumption is that the tracks are group-aligned in terms of content. That group N of one track is a substitute for group N of another. So, you subscribe to each of the tracks. You add this parameter along with your request, in the very last one that you're adding, you, you set a flag in, in the parameter to say, "Okay, go ahead with the switching now," because you don't want it to activate in the middle of you setting it up. And then, the relay from that point on selects the preferred track at each boundary by monitoring a number of, uh, properties, and it's basically toggling forward equals 1 and forward equals 0. So, all your tracks stay subscribed, but only one of them is sent to you at a time from within the set.
Here's the structure of this, uh, assignment parameter. It's, it's an object, so, it's odd, it's not just a number. We have a switching set ID, that's just a name you give to it, call it number one. We got the throughput threshold for this track, which is probably a little bit above the actual bitrate of the track, you don't want to switch right at the bitrate. A throughput fraction, this is the relative weight of, uh, this switching set, uh, compared to other switching sets that might be active at the same time. And, you've got a range of 10, right? You can do it in, in fractions of, of 10. Uh, and it allows us not to have to, if we can add and remove sets, they're all relative fractions, right? So, they just adjust their relative weight. When you want the switching to start, you just set this flag to 1, otherwise it's 0, and you can optionally rank the switching set as well to compare it, its importance against other sets, and I have a slide to explain this. So, these are new items that were added from the original design, and I think they're quite useful and not too complex. Um, so, just as a reminder, you got two ways to set it up. If you know it, you, you send your parameter on the subscribe message. If you use subscribe namespace, you're going to add this parameter to a publish OK message, and then your tracks are discovered dynamically.
Right, here's a simple example. So, I've got three, I'm subscribed to 1, 2, 3, 4, 5, 6, 7, 8, uh, tracks all together. They, this is say, video, it's, it's, I've ranked, uh, put it in a switching set, the blue switching set, and given it a rank of 1. Lower numbers are, are more important. The green set is rank 2, the pink set is rank 3. So, if we have 30 megabits of throughput, the relay is going to go to the highest-ranked item, that's its algorithm, and then based on 30 meg, it's going to make a decision which of these can I play? It's going to play 4 meg. That gives it 26 meg left over. It goes down to the next set, picks 8, goes down to the next set, picks 8, because it's everything's good when I have 30. Uh, at 11 megabits threshold, say the bandwidth suddenly drops, it's still going to look at the highest-ranked first and, and basically allocate all of the 11 meg to the highest rank. The max it can use is 4, so, that's going to leave 7, that excludes the 8 megabits from the second set, so, it's going to switch down to 4, and now we've got 8 out of 11, we're left with 3, so, that lets us play the 2 meg in the final set. The bandwidth drops even more, to, um, 7 megabits, we're still going to pick the highest bitrate from our highest-ranked set, because we've set it to be most important. We've only got enough bandwidth left for the lowest bitrate in green, purple does not get delivered at all because we have no bandwidth left.
Suhas.
Suhas Nandakumar: Will, can I ask a clarifying question on that slide?
Will Law: Yeah, certainly. Let me go back to—
Suhas Nandakumar: Um, so, I'm, I'm trying to reconcile how, what you're doing with rank, versus what you're doing with fraction. And, maybe it's, is that written down somewhere? Because, like, it, it, it makes sense to me like, I've got 30, I'll take rank 1, I'll get the best track I can, subtract it, go to the next one, and so on. But then, if I have fraction, is that like an independent control? Or, anyway, it's just a little confusing to me.
Will Law: Yeah, the, the rank has highest priority. So, then, you basically evaluate it with the fractions only, uh, at, and, and then repeat that operation based on rank until you run out of allocated bandwidth. The actual, uh, algorithm is more detailed than what I'm showing here, and it's, it's available in the, um, draft.
Suhas Nandakumar: Okay. Thanks.
Will Law: Yeah, and the reason it's relative ranks is we can, we can add new tracks later, and it'll adjust automatically, right? We're not, uh, we're not setting absolute values for these. Oh, are rank, do the ranks, are they exclusive? I can't have two tracks with the same rank? Or two sets with the same rank?
Yeah, it's the, the throughput fraction you want to get, so, you can have two with the same, same rank. So, this text is here, it's, it's a little bit text-dense. Okay. I won't face-plant here, I'm sure there's a way to make it work, keep going. Yeah, but making them relative allows us to add and remove tracks, and we don't have to go redefine the thresholds anymore. It'll basically try to take all available bandwidth and try to give you, your, the highest, the highest items, uh, in your bandwidth.
Um, here's a quick demo. I think it's 90 seconds long. This is a working implementation built by Suhas. And, he put some text over, there's no audio with this. Okay, he's got two tracks there, 720, 1080. And, the upper one is 1080, he's got lots of bandwidth, and with no throttling, well, you can read, you can read the overlay, I don't need to repeat it. And then, he's going to go implement server-side throttling. And, it's automatically switched down to 720. So, it's a working limitation. I think we could obviously watch what you want to see is does, is it stable at a given bitrate? Is it toggling between them? But, this, this can be done, uh, in the future. And then, he's going to turn off throttling, and he should resume his 1080 automatically, and you'll see that that becomes live.
Okay, and then just, some FAQs. Uh, if the publisher stops publishing one of the tracks, if the relay gets a published done, it automatically removes that track from any switching sets it's assigned to. So, there's no need for the client to have to do anything in that case. It also forwards the published done to the client, so, the client also knows that that's not part of a switching set. Um, there was debate should we add a mechanism to declare the maximum number of current subscriptions you're willing to handle. And, it's yes, we could negotiate this. Um, we could negotiate it both a limit for total, total throughput, and also max number of tracks, because you might have a million, oh, not a million, you might have 100 tracks of 1 kilobit each, or you might want 5 tracks of gigabit each, you don't want to switch those. Um, Alan commented switching set assignment is sent on request update, but it defines a switching set, would a new message type be better? We thought this through, but the awkwardness of it being applied, uh, the fact that it's modifying a switching set, doesn't really warrant creating a whole new message type here. And, the fact that we've got it down to a single parameter that we can use in two different ways, uh, I think is relatively concise. We could of course refactor this into a new message type if you wanted that. Uh, and is it an error to send it on request update for track that hasn't been allocated a switching set? Yes.
That's the end of the presentation. Are there any questions?
Alan.
Alan Frindell: I had another, um, question which I've put on the draft, this, or on, on the repo this morning when I read it, which is that it seems to me that the fraction assumes that the only thing you're doing on the session is switching, is, is switching sets. But, in reality, you'll probably have a mix, some tracks that are switching sets, and some tracks that are not. And, so, how can I, do you need to expand that mechanism to—
Will Law: Oh, yeah, the fraction is exactly that. It's the fraction of your total throughput that you're willing to allocate to this switching set. So, if I set it to, to, to 30%, right? It, to 30%. Then, if I have, if, if the relay's estimating 10 megabits of bandwidth, it's only going to consider this set being eligible for 3 meg of that bandwidth. No, but if you, in your, in your little text there, you've got this thing where it's like fraction over sum, right? So, somewhere you're summing all the fractions.
Will Law: Yeah.
Alan Frindell: And, and then giving a proportional amount. So, like, somebody says fraction 3, and somebody says fraction 6, whatever, and then, then you're dividing it up. But, what I'm saying is that, like, I'm not sure I understand from the draft, and maybe it just needs to be clarified, exactly how you're trying to partition bandwidth, and how you reserve bandwidth for tracks that are not in any switching set.
Will Law: So, when you, when you allocate bandwidth to your switching set, you do that. So, if you know that you have other tracks that are going to consume bandwidth, you don't want your switching set eating into their bandwidth. So, you're going to, you're going to take it out. I guess if you, an interesting thing to do, would be to just define a switching set, which is only one track. Um, and then, you would allocate, you could allocate the same fraction in the same fraction system, uh, here. Maybe this design is assuming that all items are allocated in a switching set, and it's a good point you raise that there might be items that are not in switching sets. But, we don't have any mechanism today to allocate it. Okay, thanks. Yeah, I think, I think we can make it work. Keep going. Yeah, but making them relative allows us to add and remove tracks, and we don't have to go redefine the thresholds anymore. It'll basically try to take all available bandwidth and try to give you, your, the highest, the highest items, uh, in your bandwidth.
Ian Swett: Thanks. Um, I, I actually like the parameter approach, I think it fits into the design a lot more cleanly and, um, I mean, overall, this seems pretty well thought through. Uh, I think I have some follow up questions that, um, Alan was alluding to on exactly how the switching like algorithm decision-making works. But, like, I, you know, I think this is, this is certainly a good shape. I think, I don't know, it's a really complicated problem, like, so, I'm not trying to diminish it. It, it's just very difficult for me to reason through like, all these use cases. Um, but, I think, there was one other thing I wanted to say. Um, oh, in terms of limiting the number of things in a switching set, yeah, I think we probably want some number where you can't like, have a thousand things in there or something like, insane, just, but, I don't, but I hopefully we can get by without the bandwidth limit, but maybe the bandwidth limit is useful for something else, so, if you want it for some other reason, then, like, I wouldn't stand in your way. But, I mean, it, it largely seems reasonable to me. I don't know.
Will Law: Okay, good. Thanks. Victor.
Victor Vasiliev: I had another, um, I didn't understand that answer. Can you say more just about the times when only some of the groups are aligned?
Will Law: Yeah, so, this, it's, it's, comes at, at the next one. So, the— unless Mo wants to, to, so, what, just, just to, to, the selection of the smallest common group boundary, so, the switching point, the switching group, here, it's G switch. It is, the group G switch exists for both track A and track B at the relay. Meaning, buffering cache or information the relay has. And, what is in the spec is that we say that the two, the group exists when at least the header of the first object of the group has been received. So, if I received group 34 object 0, just the beginning for track A, and the same for track B, I say, "Hey, this is a group boundary because there is a request for switching from track A and track B, and both tracks have the same group number as, as far as I can see." And so, I consider this is a, this is a group alignment. There is no timeout for this. Sorry, Mo.
Mo Zanaty: Yeah, um, just, uh, to clarify. SWITCH, uh, the base SWITCH is for a single other track, right? And it's still purely a client-side ABR decision. So, the bandwidth estimate is coming from the client, and the target SWITCH track is only one of them, and that's coming also from the client, right? So, I just want to make sure that before we get to DTS that this SWITCH is a single client-side ABR fully driven by local bandwidth decisions, nothing to do with the relays.
Will Law: It, it, it is driven by whatever, as I put in the first slides, which is the decision of the player, which is based on any kind of information it has.
Mo Zanaty: Okay.
Will Law: Which can be application level.
Mo Zanaty: Got it. That's it.
Will Law: Yeah, can we move quickly, uh, because I have couple of other information we need to, Ian for queue?
Ian Swett: Yeah, sorry, Meetecho booted me for a sec. Uh, can you go forward one slide? I had one more clarification question. Um, the, is the SWITCH only for groups that are in the past? Like, oh, two more slides, sorry. One forward. Uh, two more. Oh, this one? Okay.
Ian Swett: I think slide 5. Yeah, the transition group. I was trying to read through the transition group logic. Do the, does the transition group have to be a, it says, "the group G switch exists for both A and B at the relay." So, it must be in the past in some sense.
Will Law: No, no, the minimum switching group can be in the past or it can be in the future. It is just one indication. So, the, the, the choice of this smallest group boundary G switch, it is G switch exists for both A and B at the relay. G switch is greater than or equal to the minimum switching group. And so, if you put switch, "Hey, I want to switch at group number 40," which is, I mean, which would come later, you can. If you said, "I want to go back in the past and I want to receive groups from, from the past because my buffer is, I don't know," then, it's good as well. For the, for the relay, it's just something which is completely transparent. And, the other information, which is close to what we had in rewind, is that for every group in the G switch life edge, if the group is available for A, the group, the same group should be available for B, meaning that we have continuity for the group between the two tracks. And, at some time, it can happen that the timeout, we didn't, I mean, the relay does not find any common group boundary, and so, it just fails. So, there is a kind of, we, the relay says, "Well, I can, I can guarantee continuity between the time I decided, the G switch I decided and any event in the future." So, this is, I mean, this transition group algorithms is basically checking the buffer, checking the cache and seeing if it can do anything for this. The point is that, because we introduced some, some point of, lagging in the past.
Luke Curley: Yeah, I was just going to piggy back. Uh, it feels like this is kind of like subscribe update, or like request update. The publish seems a little weird, because you need some way of like associating that this publish was caused by the SWITCH, but this is just nitpicking.
Will Law: Well, we discussed this multiple times. I thought—
Luke Curley: I think it's fine. I don't think it's critical to talk about, so, ignore me.
Will Law: If, if we wanted to have a subscribe update and player subscribe update, we needed to, to have the subscriber sending two request ID and so, that play with this. Here, the, the relay can send, can decide the, the request ID and it's, it's, it can of clarifies. And, the uni-stream that carries the fetch, uh, information is, is sent on the uni-stream. I have a slide for just this because this is something which is, which is a bit new I want to say in this debates. Uh, so, the SWITCH creates one target track request context at the relay. And, publish seems to me as a natural downstream semantic for this because we want to have something which is close to subscribe. Okay. But, if G switch is in the past, we need to send catch up, I mean, we need to catch up data, okay? Um, and so, the relay opens the dedicated unidirectional stream for catch up, start with fetch header, delivers group, and then, the live objects following on the sub-group. And so, we don't need extra request ID, we don't need any cross-stream correlation for this. And, while the catch up is in flight, live objects accumulate in the relay queue, and are delivered in order. So, this is something which doesn't require any subscriber, subscriber coordination with the priority, uh, management for this.
Magnus Westerlund: Okay, we are about, we are about to run through our time, so I'm going to close the queue very soon. Victor.
Victor Vasiliev: Yeah, I, I think so. This is, this is general good direction that we, we might and probably will bike-share the actual spelling. One question that I do not quite get is so, how does the relay in the parameters of the tracks like their bandwidth, etc.
Will Law: It knows nothing about the tracks, it's told that information by the client. So, it's that, that throughput threshold value you see, the second one there. All the relay does is it says, "I have this track, and if there is this amount of bitrate available and allocated to this track, then I will, I will pick the highest track."
Victor Vasiliev: Oh, okay. So, the throughput threshold is the client communicating expected bitrates.
Will Law: Yes, client communicates. We don't want the relay trying to figure out bitrates of tracks, we don't want it reading properties on the track.
Victor Vasiliev: Why is it the client and not the original publisher, though?
Will Law: Well, the original publisher would publish a, so, originally we had another design that was two parts here, and one, it was the publisher, right? A publisher, any of these values being set here can actually be set as properties on the track. You can set track properties. But then, the client still needs to activate the switching. So, we needed, we wanted some client control in here. But, if, if you really wanted, we can communicate the throughput threshold and the switching set ID as just predefined properties set by a publisher, and then a relay when it's intercepting these tracks would automatically allocate them, uh, to switching groups. But, the client at that point, the client at that point would have no control over the process at all. It wouldn't be able to stop it or start it. And, it might start switching if it got the low bitrate track first and, uh, it, you can't guarantee which one's going to get to the relay first. The relay might give a client with a 4K screen the lowest bitrate because that's the object that happened to arrive first for the switching set.
Victor Vasiliev: I-I-I think this, I think this makes sense. Uh, I think this is a good start, but like, I do think we need to, if we have more time to bake, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Uh, Suhas.
Suhas Nandakumar: Uh, I, I, I think from the spec, it's, it's clear, um, I-I would, I would rec— like, it would be nice for, to provide the inputs on where the algorithm is, is complicated or not, because I think I agree that we have not spent too much time reading about it, but that might be a call to people to kind of read and see, what are the concerns.
Will Law: Thanks for building it, too. Colin.
Cullen Jennings: Um, I was just going to say that, I, I think that one of the, the things I like about this is, it also works for non-caching relays, like, if we're going to make it MTI to implement, um, and I think that's one of the things we need to work on on, um, SWITCH a little bit, is just figure out how it works with non-caching relays. Uh, I, I think that's fixable in it, but I, I think it doesn't right now. Um, so, this sort of does, and I, I think that also, when I think about what we'd need to do to make the base, let's say we decide to do this as an extension, we'd have to make sure that we had the right places in the base draft so it was possible to insert an extension like this, and I think that that would, um, also be a lot of work to do. So, I, I sort of like the idea of this being towards the, the base spec as well. Um, thanks.
Gwendal Simon: Uh, I, I just wanted to reply, uh, Colin, that SWITCH doesn't imply that you have a cache in, in, it's just that in the transition, when you need to find the group boundary, the common group boundary, if you don't have cache, you should wait for what you have in your buffer next to send, and you, I mean, it covers this, this, this use case. But, indeed, the, the use cases are different. The mechanics is very different, but both, uh, approaches are complementary and, I, it's, it's, it just that it covers different use cases.
Cullen Jennings: Oh, okay, thank you, thank you for correcting me on that. I misunderstood that. I just, I'll, I'll read more carefully with that, that part. I, I get what you're saying.
Gwendal Simon: But, indeed, the, the use cases are different, the mechanics is very different, but both approaches are complementary and I think it's, it's just that it covers different use cases.
Martin Duke: Okay, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It's, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Martin Duke: Will? Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It's, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Martin Duke: Will? Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Martin Duke: Will? Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Martin Duke: Will? Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Martin Duke: Will? Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Martin Duke: Will? Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Martin Duke: Will? Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisheris, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind, current approach, maybe worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Martin Duke: Will? Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It, it's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It, it's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It, it's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It, it's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It, it's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It, it's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, i will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It, it's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It, it's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It, it's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH? I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond. I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link. But, Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge. So, blind current approach may be worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It, it's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH; I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond, I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link? But Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge, so, blind current approach maybe worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH; I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond, I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link? But Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge, so, blind current approach maybe worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH; I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond, I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link? But Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge, so, blind current approach maybe worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH; I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond, I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link? But Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge, so, blind current approach maybe worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH; I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond, I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link? But Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge, so, blind current approach maybe worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH; I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond, I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link? But Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge, so, blind current approach maybe worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH; I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond, I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link? But Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge, so, blind current approach maybe worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH; I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond, I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link? But Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge, so, blind current approach maybe worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH; I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond, I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link? But Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge, so, blind current approach maybe worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking pretty interesting, I think there's a lot of value there, I think people are going to implement it. It, it seems like it needs probably, I don't know, I'm going to like, stick my finger in the air and say like, six months of people going back and forth and getting the spelling exactly right, interoperability, um, it just seems like it, it's relatively new and needs a little bit more bake time, especially, you know, not that many people have really taken a hard look at it. It, it's very new.
Martin Duke: Okay, we are about, we are about to run through our time, so I'm going to close the queue here very soon. Victor.
Victor Vasiliev: Yeah, uh, regarding DTS specifically, like, I, I think this is a good start, but like, I do think we need to, if we have more time to, give it to bake, and like, we have more interop experience, like, we definitely need more of that for DTS because it's like a very complex in terms of does this actually work in practice, like, in real production.
Will Law: Oh, Suhas?
Suhas Nandakumar: Uh, I-I-I just had one point to say. How, um, this, we have server-side, kind of, ABR, client-side ABR is, is, is the other half of the story. Because server-side ABR is good enough, but client-side, client is the, or the player is the final person who can make the right choice. Uh, having a solution to solve that is important. Is it called SWITCH; I'm not sure, but, but we need to basically have a way to solve that problem in MoQ.
Martin Duke: I, if I could just briefly respond, I think my email makes the case that, that there is a solution for client-side ABR in the draft today. Uh, it has some drawbacks, it has some trade-offs, and I think that's what we need to evaluate. Ian.
Ian Swett: Yeah, I was mostly going to just say what Martin said. So, yes, that I, I think, I think better understanding, like, what the marginal value we are getting out of, whether it's SWITCH as proposed now or any additional client-side ABR change we make over the status quo, would be really helpful because, I mean, for a lot of cases, the status quo is like pretty good, actually.
Mo Zanaty: Um, yeah, I agree that the status quo, we do have client-side ABR with a blind SWITCH. I think what SWITCH is adding is instead of a blind SWITCH, you have, uh, a relay confirmed SWITCH, uh, a relay chosen SWITCH. So, I guess the, the real question is whether or not that adds enough value in enough cases. Um, and I hear Victor's point about, you know, um, when would you actually have a problem on the publisher link? But Gwendal also mentioned, you know, points where the publisher is, is remote and far, um, not, not a YouTube server, you know, with stored content. Um, so, I think there may, there may be some cases where the relay may have more knowledge, so, blind current approach maybe worse than a relay-mediated approach.
Martin Duke: Thank you, Mo. Do we have any other comments before we start asking questions? Um, Gwendal.
Gwendal Simon: Uh, I, I just want to remind that after Boulder, people promised that they would send comments on the PR, I got no news. So, uh, please, do it, I would be very happy to, to go into more details and to revamp the design. I'm completely open to this. It's just that if I don't get feedback, I cannot do anything.
Martin Duke: Well Gwendal, um, as an individual, I did, I did, I did actually go and read the PR finally before this meeting. I did leave a couple of review comments, I think they're sort of spelling issues. Um, I, frankly, personally have no opinion on whether we should do this or not. Okay. Excellent. Wonderful. All right, I'm going to start asking questions. Please start the timer, Magnus. Okay. So once again, I'm going to start with the adopted in some form, uh, question. I'll, I'll keep saying it, but I'm going to say it again, like, uh, you, if you want to go read the PR before you opine, you want to go read the email chain that I just started before you opine, you have till June 4th to do it. If you've already done those things, if you feel you already have a based on this presentation or your previous reading, like, you're ready to, to opine, please opine. Okay. Here we go. Sorry for capitalization. I do not love the text editor that writes these questions. Okay, that's 16. I think there are 16 people actively voting under the foot that we have here today, so, I'm going to, uh, I, I think we're done, but please raise your hand using the tool if you need more time. I hope no one there is trying to raise their hand on their camera and not, not working, because they should be using the tool. Okay, no one has done so. So, uh, let the record show that six people think we should adopt, six people think we should not adopt, and, uh, four people have no opinion. All right, I will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and ask the question. Go right ahead. Okay, it seems like there are, there are 16 people actively participating. Once again, raise your hand using the tool if you need more time to vote. No, the 17th person decided to participate. Excellent. Uh, all right, um, okay, let the record show that six people have said yes, we should incorporate this into the base draft, 10 people have declined to, to support that position, and one person has no opinion. Okay, we will terminate the show of hands now. Um, maybe this is, well, okay. Well, I'll go ahead and announce results shortly after the 4th. Uh, okay, I will, we have like three minutes here. Um, I will once again point people to the chair slides, which you can access in the datatracker, that have all the deadlines coming up for our working group. There are two consensus calls open right now. There are, we have an interim coming up, we have a request for comment on virtual interim dates between London and Vienna. Um, and, uh, does anyone else have anything else for the good of the order? Alan.
Alan Frindell: Uh, just I was poking at draft 18 implementation stuff and found a couple of ambiguities. I filed some issues, um, but which maybe people could take a look at. But, one in particular was around bidirectional streams and cancellation, which is that we went from having one way to cancel something, like you could send unsubscribe, and now there's three different things you can do. You can stop sending, you can reset stream, and you can fin. Um, and it's unclear if, from the draft, if, if all of them mean the same thing, or if one of them is authoritative, or, and then also the peer can respond in different ways and it, it has some imp— the answer to that question impacts how I'm going to implement a little bit, so, if people could weigh on those issues, it might give like some direction, or think about them as you go about your draft 18.
Martin Duke: Thank you, Alan. That was useful. Um, All right, well, thank you finishing ahead of schedule. Um, as promised, we're going to have a series of shows of hands. I'm going to start with DTS because I think we might finish a little early and have at least some time to discuss SWITCH, we didn't really have time to discuss SWITCH. Victor, yes?
Victor Vasiliev: Uh, is this the last time for like discussion before the show hands?
Martin Duke: For DTS, yes.
Victor Vasiliev: Okay. Uh, I just wanted to clarify that, like, I don't think I seen people seem to be really averse to extensions. I will point out that QUIC has a lot of extensions, and MoQ literally requires you to implement them. And, those, the sky has not fallen in practice. And, like, TLS requires God knows how many extensions and this just works and I, I don't see why people are so concerned about those.
Martin Duke: Thank you. Luke.
Luke Curley: Yeah, I was just going to plus one what Victor is saying. Like, I, I, I just don't want to increase the burden, like everybody has to implement something, um, if it would be easy to say, "I support this." And, that's, yeah.
Alan Frindell: Yeah, I think I want to say plus one to what Victor said, just that, like, um, where, where the text of something lives does not really, like, determine whether people are going to implement it or not. I think the valid point is like, do we have the right extension points in the MoQ transport draft? That's really important that we do, um, for whatever we're going to do. Extensibility is kind of the only feature we have to get right in V1, um, so, I think having actual real-life extensions that we're trying to ship like, will force us to make sure that our extensibility story is right, so, it's kind of another reason why we do that. And, I, I like, like, the shape of DTS is like, looking