Session Date/Time: 21 Jul 2026 07:00
[00:00:45] Jana Iyengar: Just give it a couple of minutes. Should we just give it a
[00:00:48] Leslie Daigle: couple of minutes?
[00:00:49] Matt Green: Yes. I think it's
[00:00:51] Leslie Daigle: the first session of the day.
[00:00:52] Jana Iyengar: Yeah. There's a coffee line downstairs. Like, we went down to the barista,
[00:00:59] Matt Green: and it
[00:00:59] Steve: was just, like,
[00:01:00] Jana Iyengar: winding up. Can't do this.
[00:01:03] Leslie Daigle: Yeah. I am here as much as I could in the breakfast room, and that's
[00:01:06] Jana Iyengar: It's silly. I'm not I don't I don't always require coffee. When I require coffee, I require coffee. You got it. I love that.
[00:01:37] Leslie Daigle: Treat the meds. Alright. I think we're gonna get started. Welcome to the MOPS working group session. My name is Lassie Daigle, my co chair, Jenna. We are going to get started shortly. Do note the note well well. As I can see, everybody is studying it carefully. We do attempt to have a a professional working environment at the IETF, so these are the things that you keep in mind, and you should keep in mind also the elements of IPR as noted here. If you haven't already and you're in the room, please do use the QR code or sign in to the on-site tool on-site tool from the agenda. If you are remote, please remember to keep your audio and video off if you're not using if you're not engaged in the actual discussion of the minute. And we encourage the use of a headset. And we are going to ask we are going to manage the queue through Meetecho, so that's another reason to be logged in even if you're in the room. And also, when you come up to the mic to ask a question or make a contribution, please also state your name and affiliation then. You'll have, you know, you'll have identified yourself by getting into the Meetecho queue, but that doesn't actually get caught in the audio stream. So anybody listening to the audio stream later will have no idea who's making contributions unless you state your name. There are some resources for the IETF one twenty six meeting. If you haven't found them already, you probably wanna have a look. And this is our agenda for today. We have noted well. I would like to thank Chris Lemmons for being our notetaker today. Are there any bashes to our agenda? Alright. Not hearing any bashes to our agenda. Let's leap right into our industry panel. Jenna?
[00:04:29] Jana Iyengar: Alright. Should we yeah. Should we should we just move to the front?
[00:04:39] Leslie Daigle: You should move to the front. So we have two remote panelists this morning and one in the room. So, Matt, if you would come up and we're gonna organize some seats of some description. Yeah. Bring your own chair. There you go. It's a DIY a DIY panel. Yeah. I think maybe here so that it's likely to be in the in the camera angle. Yeah. The camera will find you. Sorry. This isn't this isn't new and an experiment as you may be able to tell. This is actually a format that we're hoping to replicate at future IETF meetings bringing in people from industry in the local geography to talk about specific things that they that they experience operationally. And particularly because it turns out that even though the world is all using Internet technologies, experiences of of how networks have been deployed causes differences in different parts of the world. So apart from just generally having industry input into the session, we thought it would be interesting to be a little bit geographically specialized. So, Jana, have I given you enough air cover?
[00:05:53] Jana Iyengar: Thank you, Leslie, and thank you all for being here. I know it's early in the morning, and it's only just Tuesday, but I hope you've got your coffee. And if not, I hope this panel wakes you up anyway. The context that Leslie said is is exactly right. I'll just add one thing to it that we are hoping to make this a recurring thing. So if you, after the session, have any thoughts or feedback to us about how we might be, how could panel could be more useful, more beneficial, please feel free to send us feedback. We would love to hear more on that as well. So with that, I'd like to introduce our panelists for this game show. We have I'll I'll just let them introduce themselves. Matt, why don't you start? Sorry. So I'm actually gonna ask you a question, which is to say, introduce yourself and also tell us which part of the video ecosystem you engage with.
[00:06:50] Matt Green: Okay. Hi. Yeah. Matt Green at Sky. So I'm a CDN architect at Sky. So I'm responsible for both kind of content delivery on the broadband network. So talking to the major content suppliers, providers that we we deliver, but also for our own content. We have a fairly large TV service in The UK. So how do we how do we deliver that to our own ISP end users, but also third parties, other ISPs in The UK, and also in Italy, and it was Germany until recently.
[00:07:34] Jana Iyengar: Thank you, Matt. We have two remote folks. Guillaume, do you wanna go next?
[00:07:44] Guillaume Bichaud: Hi. So my name is Guillaume Bichaud. I work for Broadpeak. I'm the CTO of Broadpeak. And in Broadpeak, we are we have been mostly perceived as a infrastructure provider, CDN infrastructure provider, and especially for operator telecom operators. And since a couple of years and now, we know we we accelerate regarding this this new strategy, we are we have a, you know, a broad pick dot io as a service platform. And with this platform, we are more perceived as an operator now. So streaming operators. And I will tell you more details about what what it means exactly.
[00:08:40] Jana Iyengar: Thank you, Guillaume. Steve?
[00:08:44] Steve: Hi. So I work for BT, so telecoms operator in The UK. I run a research team. We work with various things, but one of the things we've got care is content delivery. My team engages mostly with the network operator bit of the company even though we do have our own content service. But I I we tend not to work so closely with them on a day to day basis. So most of our interest today is in the network to do.
[00:09:11] Jana Iyengar: Excellent. Thank you all. Let me just do a quick check, though. Can folks in the room hear clearly, especially hear the remote participants clearly? Very good. BT guy's a bit mumbly. Mhmm. I'm not gonna say it that way. But, Steve,
[00:09:28] Steve: can you speak up just a little bit? Yeah. Okay. Yep. Will do.
[00:09:40] Jana Iyengar: This it's it's hard to hear up in the front here. And I have to wear glasses now because it's early in the morning, and I've not had enough coffee. I'm gonna start off this was it oh, thank you, Kai. This is a sort of a broad two part direction setting type question. And I'm I'm gonna basically ask you all to speak in in in turn about this. Can you speak to the largest traffic events that you deal with? Live events, linear TV, downloads, any others that you deal with? And the part two there is how do you deal with these peaks of large concurrent viewership? Every ISP, steamer, and operator, streamer, and operator is likely to have their own answer to this question. Are there scaling issues or other issues that you look at that you're addressing? And what are the biggest network scaling hurdles that you see and intend how do you intend to resolve them? So it's a bit of a broad question. I appreciate that, but I hope the context is clear. So we'll start with you again, man. Okay.
[00:10:54] Matt Green: Yeah. So, I mean, the the biggest stream events we see on the network are the football streams, certainly in The UK. So the World Cup we've had recently, but also Premier League, Champions League. And they're very impacted by how they're offered. So in some cases, they're on linear TV and satellite as well. So the there are other way non Internet ways to view them, and so that helps reduce the load. But others are purely Internet delivered, and so that's that creates a lot of load on the network. And we do still see some we do still see big game downloads as well. They're they're they're a driver, the kind of Fortnite and Call of Duty. Those kind of things are a big driver of traffic on the network, but they're not as big as the as the football events. And they tend to be it's it tends to be more of a problem when they sync. Every now and then, you get a popular football match and the game download happening at the same time, and that that can be pretty scary. But yeah. It's so for us, I mean, we've been deploying caches in our network for a long time, and trying to get those as deep in the network as possible has been helpful, taking a lot of the load off the the kind of core backbone links that we've got. But the main the main issue we see with that these days is that everybody is building their own CDNs these days. And so if you have a spike on one CDN, you know, one if you want to deal with a spike on on one streaming delivery service, they've got their CDN in your network, and then another one has another CDN in your network, and suddenly you've got five of these things deployed. And they're they're not doing yeah. They're not running at peak majority of the time, and every now and then, one of them will spike.
[00:12:58] Jana Iyengar: So you've got a lot
[00:12:59] Matt Green: of network infrastructure built out. Yeah. I think that's that's the main kind of thing from us.
[00:13:11] Jana Iyengar: You, Matt. I wanna come back to one of the a point that you just made. Think about that, the multiple CDNs and and where you think you might wanna go with that. I'll I'll but before I poke further, let me ask Guillaume. Do you have thoughts on this?
[00:13:29] Guillaume Bichaud: Yes. Of course, World Cup was the most important event recently. I have some facts because I'm trying to we started to collect, you know, ISPs and and telecom operator that are equipped and and powered with Broadpeak's infrastructure, collect facts. I have no of course, not yet all the numbers, but okay. It's interesting. First of all, regarding EMEA, Europe, it's okay. It's both it's a smallest, world, right, comparing, for example, South Of America, or even, APAC. But in Europe, we've been, we we have one so I won't give name, but we have an telecom operators that that was that used and and took the opportunity with this World Cup to test multicast. So multicast adaptive streaming. And that was interesting. So it got, overall, something like during the first game, you know, something like 200,000 sessions concurrent sessions that would represent that represented more or less more than five 600 gigabits per seconds. And and then it it it it it it was able to manage more than 40,000 concurrent session through this multicast network. That was, again, a way to test it and and 98% of efficiency, meaning for all decisions served over the multicast, 98% efficiency means most of the traffic, most of the bytes delivered to the to the consumers, to the end user consumers were multicast. Because, you know, the multicast technology, if you don't know it, we call it MABR. This multicast technology is is is hybrid. Right? It's it's it's mostly multicast, but it can be assisted by unicast if if there is a need. Yeah. We we had the same things in in another country if in Europe, roughly, you know, more than 200 thousands concurrent sessions, more than 600 thousands customers. Same thing. Only in, for this one, only in multicast. So multicast was really, great and was really, very important, in this, tournament, in this World Cup. And now I jumped in America, in South Of America. We have important customers over there. When I say customer, it's always telecom operators. We have an important one that that that was able to you know, during the opening game, the facts I've got is one dot 6,000,000 concurrent streams at peak, you know, only in multicast, only in MMBR. We will throughput nearly more than one dot five terabits per seconds. And then we had the second week. In the second week, they even break the the record more than 30% increase, more than two terabit per seconds with nearly 2,000,000 of concurrent session epic only in only in multicast. So multicast was very great. So now now the facts. Over interesting fact. The worry was not about streaming because it was multicast, so no worries. That's the no bottleneck. You know, that's the beauty of the thing. The worry was right after the transmission when each of the guys when each of the end users was was ready to Zap and switch to another unicast channel. You know? And that's the most important problem because there is no provisions for that. And the CMS platform, for example, just exploded. And that's the the so that's something we have to we have to, you know, pay attention and and try to solve this. So the massive load in the in the load balancers on on the in the, you know, in the on the network side and on the CMS, on the application side, was was difficult to digest. So that's one important lesson for that. Well, there are other customers in South Of America and mobile network. Everything was was okay. Right? So especially low latency. We had also a very important low latency. Like I said, some ISPs use these WorldCups to experiment and and engage more in a multicast idea, others try to engage with low latency. And that was great. That works. So not really other than that, not really big deal. You know? We have to yeah. It's a very important lessons, and and we continue. What should I then say then? I know that previous speaker mentioned game download. That's also a big thing this year that we've got from one of the operator we we deal with. He was very annoyed by game download because sometimes game download happen and especially when it comes from America, it in it it happened in Europe at the busy time, you know, 11AM, 12AM. This is awful. And it just it just overload this network this access network. It overload everything, and it it last it may last an entire day. You know? So that was a complaint that we've got. And we the way we'd address that so there are two mostly two ways. You can address that with your, you know, typical Unicast infrastructure by, doing, you know, some kind of request routing in you know, smart request routing and such kind of things. But you can also handle that with multicast again. And that's why we have experimented successfully, I would say. That's another way. So it's not only about video, it's about transporting big files, huge files through multicast in a way that offers the same experience to the end users and just, you know, relax the the unicast infrastructure.
[00:19:59] Jana Iyengar: Thank you, Guillaume. That was very, very helpful. It's great to hear about the successes you're having with with multicast ABR. A lot of us were watching the soccer the the the World Cup this past week. Do you think we might have seen something on Broadpeak?
[00:20:19] Guillaume Bichaud: What do you mean? Sorry. I didn't
[00:20:20] Jana Iyengar: catch we might have seen something delivered via Broadpeak while we were watching the finals or the semifinals this past week.
[00:20:26] Guillaume Bichaud: Everything I was talking about is is delivered from Broadpeak. You mean, Broadpix technology, not the Broadpix CDN itself, which is under construction. But I would give you more words later.
[00:20:38] Jana Iyengar: Understood. Well, thank you again, and thanks for, again, repeating the games download points. It's something that I wanna dig into a bit. But, Guillaume, for you, I the next question that's coming up is probably gonna be an interesting one for you around ads and dynamic ads. Just keep that in mind. We'll come back to that. Steve, do you wanna take a stab at the question?
[00:20:58] Steve: Yeah. Sure. Thank you. So my answer is sort of almost a bit of maths and a bit of Guillaume's, really.
[00:21:03] Jana Iyengar: Can you speak up just a little bit, Steve?
[00:21:05] Steve: I'm sorry. I'm trying to hear. Let me let me get there. See if I can adjust my headset here. Sorry about that. I, yeah, it doesn't always pick up very well. So, yeah, my answer is sort of halfway between Matt's and Guillaume's. So I certainly experienced the same things as as Matt's talking about. Sporting events generating large peaks on the network. We also see game downloads, but the game downloads aren't quite as problematic as the large large sporting events. And the coincidence of these things all at once is is a is a headache. Just another observation with the games downloads. If if game download takes, like, 10% longer, it's not a disaster from a customer experience point of view. Whereas if a video stream can't quite stream the four k resolution, that's a bit of a disaster, I think. So it's far more sensitive to the to video streaming is far more sensitive, you know, to to congestion than than the games downloads will be. So biggest content. So so just how we deal with it partly at the moment is by working with content providers, CDN operators. They they work closely with the network operators to provide estimates of how much traffic they expect to see on each CDN for the big events. And we work with them to make sure that between us, we have enough capacity in place to handle those events. So it's a constant a constant cycle of trying to predict what's coming up and then making sure the capacity is in place for that. But the thing that's frightening us in the long term in a way, frightening might be too strong a word, but it's the terrestrial broadcast evolution, where that's going. So in The UK, the regulator Ofcom produced a green paper recently, which talked about the options for terrestrial broadcast. And the preferred option is a complete switch off in 2034. Now if broadband is really the only delivery mechanism for live events, then that puts a sort of pressure on it that it hasn't had to date, I would say. So it's not just sporting events then, I would suggest. So during COVID, for example, we had the the governmental briefings every day giving us advice on what to do. That went out over broadcast television. Suddenly, that would go over broadband, that kind of thing. And and would the capacity planning then becomes far more of a nightmare? Because, obviously, we can't we we haven't got a schedule for pandemics, you know, planned. So we we can't really put capacity in place in the same way as we can with sporting events. So terrestrial broadcast switch off is definitely something in our minds and something we're trying to to, you know, get our hands around how we deal with. The solution we believe, as as Guillaume's touched on, is multicast in some form to get live content to people, linear content to people. We in the research labs, we came up with a variant of the multicast ABR that Guillaume referenced, which is intended to integrate with over the top providers a little bit more easily than the current solution does. So the peaks that we see on our network are not from BT's own content service. They're from other people's content, generally. And so we've we've thought about how we integrate with CDNs to provide them with the control and visibility that they would normally require. And, you know, and and the we've worked with broadcasters as well to work out what they require from this to make sure that all three elements of content delivery, the the content provider, the CDN operators, and the network operator are kinda happy enough with the solution. And we've been working with Broadpeak, in fact, on on that evolution now, and we're we're currently going into trial on that as we as we speak. And so that that's progressing well. So that's where we're headed on that.
[00:24:43] Leslie Daigle: Just a quick interruption. I'm going to remind everybody in the room that if you haven't already, please do log in to the local on-site Meetecho tools so that we can get an accurate headcount. Thank you.
[00:24:58] Jana Iyengar: Thank you, Steve. That's very, very interesting as well. I I wanna come back to a I mean, I I'm I'm I've got a couple of questions coming out here, but I'm gonna actually ask you one of the questions before I ask follow ups on this one. I'm very, very interested to hear about how you're thinking about the the OTT or non ISP content provider peaks. But I will come back to that after I ask this question first, which is just switching a little bit to ads and ad insertion or or how we think about this. This is a very interesting problem when it comes to actually doing delivery at scale over IP technologies as compared to existing linear TV or whatever we have there. Are you involved in advertising? If so, how does that impact or shape how you scale live events or other broadcast delivery mechanisms? Do you have thoughts or preferences between server side or client side insertion? Let me start this one with you, Steve.
[00:26:05] Steve: Okay. Yeah. So we're not directly involved in the advertising itself, but we're certainly interested in how adverts get delivered. So especially personalized ads, I think you're touching on. So if it's other people's advertising, other people's content service, we have to think carefully about how we can deliver those efficiently because, clearly, there's there's limited limited control from our point of view on those services. So, we have been working with, experimenting with some techniques for doing this. The most obvious thing you can do is if you can get advanced sight of what ads are coming up in a given break, then we can preload a certain amount of advertising to the to our home gateway in advance. And we can do that either over the unicast or over multicast, and that takes a certain amount out of the peak. And if we can also kind of be a bit clever about the way that we use the multicast group so that we can mix those a little bit more dynamically according to who is seeing which ad. So as a as a it's still a research activity, but we've been looking at how we mix preloading and better use of multiple multicast groups to take the the the spike out of the ads that we would see. I guess just to be clear, one thing that sometimes has has confused people is that you do you always see the ad you're supposed to. So when you're personalizing ads with a multicast ABR system, you do see the ad that was intended. It's not like an IPTV solution where you push things to the set top box and you watch whatever's pushed. It's just that during the ad break, you drop back onto Unicast to get the personalized ads by default, and we don't want to see those peaks. You know, as as Guillaume said, it's the it's the switch to to Unicast that causes a bit of a problem. So, yeah, we've been looking at various techniques for how we might deliver them, but we do need some advanced site of what ad is coming up in which break so that we can make sure that that's delivered as efficiently as possible. Quite difficult to do if you don't get any advanced notes of that.
[00:28:02] Jana Iyengar: Thanks, Steve. You, Matt?
[00:28:06] Matt Green: Yeah. So we do deliver adverts in our streams. We use dynamic advertising for some streams, and that's done via manifest manipulation to the client. So but it's I mean, when we've reviewed multicast solutions in the past, then dynamic advertising has always been a a problem. Challenge. Yeah. So it's interesting to hear that you've got you might have an answer for that, Steve.
[00:28:36] Jana Iyengar: Mhmm. But,
[00:28:39] Matt Green: yeah, it's I mean, I don't get too involved in the the advertising business side of things, so it's it's another service on our CDN that we deliver. And, yeah, when we've reviewed multicast systems in the past, then the problem was just, you know, you'd switch to unicast for the adverts, and then all you're doing is condensing your spike of viewers down to a very short time window, so you still have to have all the capacity deployed to to to deliver that. So yeah. Thank
[00:29:09] Jana Iyengar: you, Matt. I am sure that Guillaume's sort of, like, waiting for his turn to respond to this. So, Guillaume, you go next.
[00:29:16] Guillaume Bichaud: Well, okay. In Broadpeak, we only deal with well, only. We mostly deal with server side ad insertion. It's part of our as a service platform. Right? So we can do that as a service or we can do that on prem. You know? We have two solutions. So server side ad insertion as a, yeah, add some interesting, you know, functionalities. You know you know them. Right? It's a most protected for the for the customers, most protected technology. It did avoid mostly avoid skipping the ads and all that stuff. The question the big question, how does it scale? So it scales because we've mentioned earlier. So we need to rely on the on the manifest manipulator, and it's a piece of software which is extremely needs to be extremely scalable, extremely well designed, and that's the that's the point. Although, otherwise, other than that, we don't have an issue particular issue in in in adding session. Oh, okay. I forgot also that we also deal with AGAI for those who know several guided adding sessions. So that's we we cannot work on client side adding session because we don't master and we don't control at all the mostly not the the the end user terminal. What we do have implemented and deployed AGI because it's a good compromise between server side and and and client, you know, and the facility, you know, AGI release a little bit the pressure on the on the on the server. That's why AGI is interesting. It distribute a little bit more the the CPU requirements, the power requirements to the device, to the end user device. That that's a interesting technology, especially when you are talking about low latency or even very low latency streaming experience. Yeah. So coming back to this technology, I don't have much to add. I mean, it it's yeah. There was a mention from Steve and a bit a little bit also about the the fact that it might be it might not scale in multicast, but we don't have frankly, we we never really experimented big issue with that. When you have huge event, you don't have personalization. Right? Mhmm. So at least we didn't we didn't get it. We because with huge events, the the price of the ad is so big that it's just, you know, you have big players distributing the same ads to to everybody. When you have, you know, medium sized events, yes, you have you have personalized events. Very often, these these are replacements. Do you have national ads or, let's say, main ads, and then they got replaced? And the replacement doesn't occur during all the breaks. So very often, only this is this is my experience. Right? Very often, only part of the break is replaced by personalized ads, which makes overall an all in one. It makes the the ad insertion not a big issue in multicast. Although it can be, you know, as as Steve said, it can be enhanced and it can be it can still be you know, we can still make progress on this on this space. Yeah.
[00:32:50] Jana Iyengar: Thank you, Guillaume. That was great. So I'm I'm I'm just gonna try to, like, reconcile the different things that I've heard. First, there's streaming, there's game downloads that seems to have come from all of you. You were all mentioning game downloads as one of the secondary peaks. Maybe not the primary one. And as Steve was pointing out, not the most sensitive traffic to latency. So the impact of scaling is much more important for streaming. And does that that usually comes over what I would call OTT or, like, you know, other content publishers and CDNs. Then there's the ISP itself, the operator itself delivering its own linear channel streams to its customers, and the rest CDNs that deliver both streaming and game downloads and things like that. To me, this feels like a very sort of a fragmented world. I mean, I I I just wonder if you have thoughts, and this is sort of my next question. And I'll also ask people to start thinking about lining up and asking questions. This is not just us here. We would love to have people come up to the mic. But do you have thoughts on this fragmentation on how I mean, it seems like fragmentation because there's technology that can be used. For example, we're talking about multicast. Right? The CDNs are looking at caching and deploying caches deep inside the network. This is all about delivery, of course, but I just wanna ask you, how do you see the network evolving? How do you see this do you see this fragmentation continuing? Do you see technology sort of unifying? How do you see this progressing? Let me start with you, Guillaume.
[00:34:35] Leslie Daigle: And and and not to interrupt, but just to point out, we're starting to get some questions in the chat that I know you can't see, Janet. So so maybe we should ask them to come up to the mic after your next round.
[00:34:47] Jana Iyengar: Yeah. So let's do a quick round of answers on this one. If you could keep it to less than a minute, I would appreciate that. And then we can go to questions from the floor. Guillaume, you go first.
[00:35:00] Guillaume Bichaud: Yeah. So Steve mentioned also the the switch off, you know, digital terrestrial TV is going to is going to TT and all that stuff. That makes people worries about the future of adaptive streams. So the future of streaming. So would we Could we handle all these, you know, all these sessions, all these potential traffic with with adaptive streaming? So I think we have many telecom operators have a lot of they all have their own network. Right? But they are not federated. They are some kind of isolated islands. Steve mentioned that we can federate them through multicast, and this is part of the answer. Yes. And we are working on this. The other thing that we are dealing with in Broadpeak is that we think that our own network, we are going to be published public. Right? We are going to offer and expose a public CDN service. And our public CDN service is just based on the federation of existing CDN. Steve mentioned that also. Many islands, many CDNs already exist. We just need to federate them in order to provide a kind of uniform service that will deal with this huge peak of traffic. That's that's one answer. The other answer is the technology ABR adaptive bitrate streaming is nice. But if we are going to keep with a huge increase in term of traffic, then we will have to think about the next step. And the next step may be MoQ. MoQ is made over quick. We are working on it's it's it's a bit like the in the past. Right? RTP streamings, like, It's a standardized fully standardized WebRTC kind of framework. You can think about it for MoQ. And MoQ is great because it's much more efficient in term of streaming. So in a way that it can it could probably cope with much more concurrent sessions, and that's part of the answer to deal with this increase I mean, coming increase in term of in term of traffic.
[00:37:05] Jana Iyengar: Thank you, Guillaume. Steve, do you wanna go next?
[00:37:09] Steve: Yeah. Thanks. Thanks, John. So I think your question related effectively to the fact that so multicast ABR and multicast perhaps provides a solution for live streaming. Then But we find there's something else like big games downloads that we have to deal with, and then perhaps there's something else. The whole business case for using multicast is the fact that you don't have to build out your unicast capacity. And if you've missed one of those things and it turns out, actually, you do have to build out your unit CAS capacity, then, you know, maybe it wasn't so worth it. So I think there's a compromise. There's a compromise between how much of a risk you're willing to take by deploying point technologies to solve particular problems. I also think the point technologies are a bit of an insurance policy, if you like, because we particularly for multicast ABR, predicting the sizes of these peaks and even the events that generate those peaks is quite difficult to do. And if you're broadcasting over, like, a terrestrial, you know, over air terrestrial broadcast, you have no issue if the audience turns out to be five times the size you thought it was going to be. It just handles it. On broadband, of course, it doesn't work that way unless you're using multicast. So for me, the one of the strengths of using multicast, especially for live streaming, is this unpredictability of demand. The fact that it'll just deal with it, however big that is. If you if you messed up in the predictions, it's fine. It'll it'll it'll handle it. So I take your point that we do kind of need to it is a point solution, but it's a point solution to a very important problem class, I think.
[00:38:41] Jana Iyengar: Thank you, Steve. Matt?
[00:38:44] Matt Green: Yeah. I mean, I think we we've ended up here because everybody's deploying HTTP servers. Right? And and so and the economics of CDNs is such that when you get to a certain point, it's worth looking at building your own CDN. So we've got all of these disparate systems spread across the network. I don't and I think that any discussions, efforts that have been had to try and persuade companies to use more, you know, single systems has been unsuccessful so far. So and, yeah, that's down to how companies have built their pipelines for deploying servers and managing their capacity and under you know, they've they've got a really good understanding of their the capacity they've got. So and I think the the issue we're gonna face on multicast is, again, one of industry consensus in that yeah. If you if you deploy a multicast system and everybody who's delivering the big peaks on your network signs up to use it, then great. But then as Steve said, if someone else got yeah. If if you get a peak that you hadn't expected on a Unicast system, if another provider comes along and out bids us for Premier League rights or whatever and suddenly delivers all of that over Unicast, then you've gotta have the network capacity to cope with So I think, yeah, industry consensus is the the the big thing here.
[00:40:34] Jana Iyengar: Yeah. I definitely appreciate that. I mean, it feels like there's something over the horizon that we need to sort of try and bring towards us. So let me let me switch gears just a second. Like, do we have questions?
[00:40:50] Leslie Daigle: Yep. Alan, do you wanna would you like to share with the rest of the room?
[00:40:56] Alan Frindell: Hi. Alan Frindell from Meta. I am I don't know a ton about multicast and obviously involved in the in the MoQ world. So I had just asked in the chat, could somebody explain where in the network do we feel the most pain with Unicast broadcasting? And then there's that spawned a lot in the chat. So if somebody you guys could share where you feel that pain and, just help some of us who know less about multicast understand. Thanks.
[00:41:19] Matt Green: So most pain in the network, it's probably deep in the network, down towards the the end users. So not in the access network specifically, but just before that. I think that's right now the most expensive part of the network to uplift, and your ability to stat marks on with smaller numbers of end users is is less there as well. So kind of that's that's yeah. But but the the the other thing here, I suppose, is the economies of these different bits of the network is constantly changing. So how much you pay for WDM links has changed a lot over the years. How much you pay for transit connectivity or peering routers or whatever. These are all fluctuating in relation to each other all the time. So that pain changes over time.
[00:42:21] Jana Iyengar: But when you say not the access, do you mean from delivery, it says an aggregation point before the access?
[00:42:30] Matt Green: Yeah. So I think I mean, UK is a bit different as well in our access networks are provided by the incumbent, and then there's another smaller fiber company starting up as well. So we don't have our own access network. So but it it's it's kind of it's at that that area closer to the handoff. I think that's yeah.
[00:42:58] Jana Iyengar: Just quickly, Guillaume or Steve, do you have anything to add to that?
[00:43:03] Guillaume Bichaud: I can add that most of the time, we don't have issues. Right? So we have a good I mean, our customers, the the ISPs, the the telcos don't have issue most most of the time. The the issue comes when you have big events. When you have big events because the network has not been really scaled for that for that for this big event, then then come the issue. That's that's the I would say. Since 2020, I would say the major issue is to increase the the quality of the video. You know? Since 2020, I we don't see big issues. I mean, all our customers are happy, but when they would start to think and to to to explain that they would like to streams now Ultra HD or such kind of things, then comes the problem. It's just a matter of dimensioning the edge network. Right? The edge caches. Otherwise and also, of course, the pipe can be limited, but, like, Matt was suggesting the the last mile. But it has to be, you know, it has to be optical fiber, something like can cope with the with with this this format. But otherwise, like I said, no big deal, but problems when it comes when you have big events, which, again, the infrastructure the Unicast infrastructure has not been and won't be, you know, designed for such big events. And this is where you need to rely on multicast, like Steve was explaining. Steve?
[00:44:35] Jana Iyengar: Thanks, Kim. Steve?
[00:44:36] Steve: Yeah. So it it it sets my sets really. Networks get more expensive per user as you get towards the edge, generally. Access network is the most expensive bit, but it's upgraded like big lumps. We go from copper to fiber. And once you've got the fiber, then you have no real incremental cost issues on the fiber as such. It starts to cost it's become expensive once you get a degree of aggregation. And exactly as Matt says, the first aggregation point is just as the access network enters the backhaul. And it's those switches that that really it's the incremental cost on those switches for for growing the capacity on those that is is the single biggest cost for upgrading capacity.
[00:45:16] Jana Iyengar: Got it. Well, thank you, folks. We're doing the mic queue?
[00:45:22] Leslie Daigle: Yep. Go ahead.
[00:45:23] Glenn Deen: Hi there. Glendeen, Comcast NBC Universal, sort of Sky. I have a couple questions that aren't involving multicast or access ban. And, Steve, you brought up this in your opening bit about the conversion of terrestrial content to nontarrestrial broadcast mechanisms. I'm kinda curious, and and I'm not asking anybody to divulge any company secrets here. But I am an American. I spend most of my time in The US. So I'm familiar with the breakdown of linear, as we call it, and and broadcasts and and VOD and live content on the Internet in The US. I'm curious from your perspectives in the European and UK market areas. What is the current sort of rough breakdown of the amount of linear broadcast stuff you currently have that's on that's carried over streaming on the Internet? What the mix between sort of VOD access, prerecorded access, and live sports is, just sort of a rough as like like and it'd be like you figure it's a 100%. A breakdown in rough percentages would be would be fine. What it is today and sort of give me an insight of where you think it might be in two to five years from now, what what that similar breakdown in the markets you're familiar with are. Does that make sense? Steve, you're looking very like like, you're thinking very hard on this one. So did that question make sense or not?
[00:46:56] Steve: No. That actually makes sense. Yeah. Yeah. So what's what's the what's the evolution of the balance in mind? Yeah.
[00:47:05] Matt Green: So I'm I'm I'm gonna hand this over to Steve, I think, because I know you
[00:47:10] Steve: Thanks, Matt. Gosh. Yes. So the mix. I think I think they did well, statistics depends on what statistic you choose to a large extent. So we see that on linear broadcast tech technology, the number of viewed minutes per week is declining very rapidly on that. But what we found when we looked at the stats is actually the peak audiences aren't declining on linear broadcast. So if that migrates onto broadband, then broadband currently is not generally seeing peaks that big, not as big as this broadcast television does. So that'll be an issue for us. And we're not saved by this average linear minutes per week declining. It's the peaks that matter for us from a content delivery perspective. Have to dimension for those. Viewers are migrating onto broadband, though. And one of the stimuli for this in The UK especially is that if you want four k four k content, you can get it either at satellite, I guess, but mostly people will get it over broadband. You can't get it over broadcast networks. So I think that's I think recently with the sport, we've seen a lot more four k being streamed online, and that's a real incentive for people to do it online. I don't have the numbers to hand for that, but it's it's definitely growing, but still broadcast is bigger. But it there will be a point at which the broadband overtakes.
[00:48:39] Matt Green: Yeah. I think the the growth in four k viewing is going to be an interesting impact on broadband networks. Yeah. I do though I do think as well the with the the switch off terrestrial being in, you know, mid '20 thirties probably, then the the broadband networks are gonna be that much bigger by the time that happens. So, like like, if you look at the the additional numbers that you could expect now, that's that's a sizable increase. But in ten years time, if you compare our networks to how they were ten years ago, that it's not percentage wise as much an increase.
[00:49:20] Glenn Deen: Can I ask a quick follow on? Because you brought up a point I had not considered. Today in and and I'm guessing Steve and and and my colleague from Sky are talking about The UK marketplace. Can you talk about Yeah. This transition. Today in that UK marketplace, is broadband or sorry. A broadcast terrestrial offering four k? Or is it is HD HD is the the highest resolution?
[00:49:46] Guillaume Bichaud: Yeah.
[00:49:46] Glenn Deen: And is it is it a digital broadcast, or is it still a good old fashioned non digital over the air broadcast? Like, because The US went digital. Right? So Yeah.
[00:49:56] Matt Green: It's d v DVBT.
[00:49:57] Glenn Deen: Okay. So okay. Try to understand because, again, you're an American.
[00:50:04] Matt Green: But at Sky, we do UHD broadcasts over the satellite system. So there is there is some UHD linear non IP out there.
[00:50:19] Leslie Daigle: I'd I'll just note that because we're sadly running out of time, I've locked the queue. So we've got one more question from the floor. And then, yeah, if you wanna wrap up. The I I note there are other questions in the chat that we're not gonna get to today. People wanna look in the chat and and talk amongst yourselves. That's fine. Otherwise, I'll take it as motivation for doing this again sometime, say, in San Francisco.
[00:50:47] Mike Blanche: Hi. Mike Blanche. I used to work for a content provider. This is this is a really interesting discussion, so thank you for having it. And I've got another question that's not also not multicast related, but about these peaks and the peaks talking about communication between networks and communicating the peaks that could be coming and so you can capacity plan for them or or put in, if necessary, kind of emergency measures in place so you're not overwhelmed by traffic. And you everyone was talking about gaming downloads, but, obviously, there's sometimes there's sports events, sometimes, like, celebrities or royalty die or something, and things happen. Right? And there's even potentially regulation coming in Europe that's going to require greater communication between different networks. So the Digital Networks Act that's coming in in the European Union, it talks a lot about interconnection between networks and making sure that's efficient and reliable and all sorts of other subjective terms. So a question to everyone, and and in particular, Matt, really interesting because you're both a network and a content provider, and a and a bunch of your content gets delivered over other people's networks. What mechanisms could be put in place to improve that communication between networks about peaks, and what would be a scalable way of doing that that would be scalable both for a content provider sending out those notifications and an access provider receiving them and doing something with it?
[00:52:19] Steve: So
[00:52:20] Matt Green: we have a lot of conversations with the the content providers. So I think if there was an automated way of us receiving forecasts of events, that would be really useful. But I think we also get a lot of good use out of actually having these conversations with these people. So because you you you get more than just the the forecast. You get kind of their future plans for content delivery in general. But, yeah, I mean, we we have a lot of these conversations with these people and rely on those. Those are those are really useful. The forecasting varies between companies and how
[00:53:09] Steve: how long they've been doing their delivery.
[00:53:12] Matt Green: So sorry. So you find that they get better at it over time. But, yeah, it's the surprise events as well, the the the COVID briefings, the famous people dying kind of big news situations are ones that we can't really plan for. So, yeah, you just have to take those ones as best you can.
[00:53:44] Mike Blanche: So is there a do you think there's a more scalable way of as well as having the face to face conversations, is there something that perhaps could be done in this forum to improve the back communication once the once you've got the the human relationship?
[00:54:00] Matt Green: Yeah. I mean, I you you could see some kind of API interface kinda setup where where they can publish their oh, yeah. We can bring up an API endpoint that the content providers can publish their their forecast too. That would be really nice because then that can feed directly into our pipelines, we don't have to take this Excel spreadsheet and manually enter it. So, yeah, that that could be beneficial.
[00:54:29] Jana Iyengar: With that, Guillaume, do you wanna add something quickly?
[00:54:33] Guillaume Bichaud: Yeah. We just it's interesting. We have a you know, in our act as a service platform that we expose the our delivery infrastructure service. We have an API that that that's also something that is very close to what we try to standardize with the SVTA, which is called OpenCasting, which and and with this API, we have we have two business model. You know, the typical business model that that is linked with a CDN is the price for a for a for a quantity, you know, the price per bytes delivered. That's that's how a CDN business model CDN is today. We have introduced the notion of capacity. I mean, we we are not the only one, but capacity is now the new the new term, the new business model. So capacity means peak. How how much you can how much peak you can support in your in your service. So then that's the new business model. And there is an API for doing that. And if there is an API, then there is there is a way to communicate this peak request to, you know, downstream CDNs along all potential CDN that could participate in the delivery. Because, you know, when there is an overload, you need to communicate quickly with your back backup CDN and so on. So there is there is a kind of momentum around this notion of peak capacity, and I think this is probably the the answer that the person in the microphone was was looking for.
[00:56:05] Leslie Daigle: So I know that the timer disappeared. It it it went over and then it disappeared, which is not actually a helpful behavior. But anyway I
[00:56:12] Jana Iyengar: I just thought that we opened up the time.
[00:56:14] Leslie Daigle: Well, much as we might all like to spend the rest of the time talking through these things, I think we have a few bits of working
[00:56:20] Jana Iyengar: Yeah.
[00:56:21] Leslie Daigle: Group business we need to get to.
[00:56:22] Jana Iyengar: But I wanna just take a moment to thank the panelists again for volunteering, for engaging, for making the time to engage with us. So one quick round for the panelists, please. And to echo what my coach has said, we are gonna try we're gonna do this again, I think I think. And we'd love to hear feedback on the format, on the types of questions you'd like to hear. Tell your friends. And
[00:56:55] Leslie Daigle: And feedback from the panelists too if you have thoughts.
[00:56:58] Jana Iyengar: Yes, please. And thank you all again. And to the panelists, please hang around. The chat has questions. Feel free to engage there. We have other working group items to get to know.
[00:57:08] Leslie Daigle: Yep. Thank you. Sanjay, I think you're doing the honors.
[00:57:39] Sanjay Mishra: Well, I wouldn't say honors. And especially after the entertaining session we had. So this one is gonna be disappointing for you. It's not gonna be as entertaining as you just heard. Turn the mic off. I turned the mic off. I'm fiddled with it. Okay. Yes.
[00:57:57] Guillaume Bichaud: You're
[00:57:58] Sanjay Mishra: on. That's better now. Okay. There you go. Okay. So I'll give a quick update on the draft network overlay impacts to streaming media. I'm the coauthor, Sanjay Mishra, Verizon, and my coauthor is Glenn Dean, Comcast NBC Universal. So we submitted draft version zero four, just before the, ITF one twenty six, and I think we have kept the cadence of, submitting the draft the last day of the submission. So we we keep that, you know, speed at which we deliver at the end. So there were a few updates to add to the draft, and I'll walk through what those changes were. So the the large part was feedback that we had received from Dave Skenazi. He reviewed draft back in February, and we didn't really get to it until now. And we at least, we took out four key items from his feedback. One was that we had a long winded introduction section, and we never really, you know, said what we wanted what we were trying to say. So the first feedback from him was that there's no clear call to action in the end. So we reworked the introduction section, and I'll go through in the in the subsequent slides there. So but sort of four points that really we that caught our attention from his feedback. So that was one. And second thing was we had an appendix section. I guess maybe we just didn't figure out where it belonged initially. And he had some good feedback on appendix a and and I'll go through that also in the subsequent slide. So we worked that part also. And then another suggestion was to align with RFC ninety four nineteen. And but after we did the whole rework of appendix as a new section 2.2, didn't and we thought we addressed the issue without having to make a reference, so we didn't need wanted to add an additional reference when really not needed, so we let that one fall to the side unless, you know, we wanna go back and revisit. And then there was a typo that he caught, thankfully, so we fixed that one. We flipped the digits there for the RFC seventy six twenty four. We had it seventy two sixty four, so we fixed that one. Sort of going back to the changes that drove, you know, all the four questions that Dave has had. So the first one was we the introduction, if you look at version three, it was like, I wouldn't say two pages long, but it was pretty long. And so they that reworked section is really focused on on three things. One is to clearly state the scope and just which is operational impacts on network overlay for streaming video. So that's the scope. And that the fact that we talk about the tension with between the need for privacy enhancements to protect the users, but at the same time, the challenge of operational blind spots that that happened due to that. And then the explicit statement that this is a problem statement document and that any of the mitigations would probably be best focused on a separate document and not to mix the two together. So that was one. And then looking at the appendix, Dave actually had raised a good point and he said that VPNs because we we talked about we gave an explanation about VPN and how VPNs are different than the network overlay because there is still some visibility in it. And Dave's point was that VPN is is nothing but essentially a subset of an overlay. So and Glenn's point was that he agreed with that case but also said that the the difference is the there's VPNs are still visible to the operators and and newer network overlays are not. So the so we did two things. One is we moved up the section from appendix into its own section in the main body, And we try to address both the both points from Dave and from Glenn. So one is that the the rework section is now clearly articulating the the the point as that the distinction is now transparency and connection autonomy and not the protocol category. So we're not trying to say that VPN is something different, but try to focus on the point that there's transparency and there's connection autonomy. And second thing is, so we also addressed David's point that the mechanism that causes the problem in this document, they are the same whether we call it a VPN or network overlay. So so the document now says that explicitly. And also to Glenn's point, we still keep the fact that the distinction between, you know, why we call out VPN as more transparent than the network overlays. And I'm not doing a good job at explaining that, but have a look at the draft, the section 2.2, and you'll see the distinction that we have laid out. And it comes out better than leaving the section as an appendix.
[01:04:02] Steve: The
[01:04:06] Sanjay Mishra: next slide is the last slide. Okay. That was pretty quick. So the so besides the rework of the introduction and lot of editorial changes that we have done throughout the document to make it more reader friendly and fix the grammar, etcetera, and all of that, Really, the question open for us is that we don't see any blocking items right now on the on the document that we have. So there there are a couple of things that we still need to clean up. One is that we still see some redundancies in the text in the section three and in section four as you see here that I have laid out. So we end up repeating ourselves. So we need to go back and and clean that up a little bit so that we're not repetitive on the same thing. And then we also had a PR from Jay Robertson that's been sitting in for a while. We didn't pick that up. But but for the most part, we have addressed issues that Jay actually raised in his PR. So we have to just go back and if we can cherry pick what has not been already addressed, so fix pick up those changes. So really, that's really what we have. These are non blocking, mostly editorial type of changes. So I think we're close to doing that. The question really for the team is for the for the working group is that, you know, should we be thinking about working group last call? And I see some team on the
[01:05:45] Leslie Daigle: mic here. Sorry. Let me unlock the queue if that's not
[01:05:49] Sanjay Mishra: on the queue.
[01:05:51] Tim Chown: Hi. Tim Chown. In the document, you do acknowledge that VPNs can be used as a way of getting access to content that you shouldn't be able to get to. Something that's happened in the last year or so in Australia and The UK is bans on social media for kids, basically. And there is an assertion in the in the media that VPNs are being used or will be used as a means of getting around that. And part of the ban applies to streamed content. Do you think that's worth bringing up in this document or just to completely avoid it?
[01:06:28] Sanjay Mishra: Looks like Glenn has something to say on that.
[01:06:31] Tim Chown: Just curious.
[01:06:33] Glenn Deen: Yeah. So as one of the the coeditors here, I'll say
[01:06:36] Leslie Daigle: And you are?
[01:06:37] Glenn Deen: Oh, sorry. I'm Glenn Dean from Comcast NBCUniversal, one of the coeditors. And I'll say, I think that's out of scope for this because what we're trying to capture in this one is the operational conflict between particular behaviors of network overlays and the video ecosystem and how it operationally impacts it. Whereas, it's a really interesting question you bring up about access and all the things, I think that's out of scope. Sure.
[01:07:04] Leslie Daigle: So to to emphasize Sanjay's question, question, I think that the the document editors feel that this is all but ready to go to working group last call. I think you want one more rev to deal with the non blocking items, if I understand you correctly. Yeah. So I'm not hearing, not seeing any particular comments suggesting that if this if we put out a working group last call on this document in the next month or so, there will be further issues. I mean, of course, you review it when it comes out for working group last call, but nobody knows of anything that would be a reason not to do that. Is that enough negatives for this early in the morning? Alright. Thank you, Sanjay. I think that that's sounds positive. Alright. Thank you.
[01:08:11] Glenn Deen: Hi there. I'm Glenn Dean from Comcast NBC Universal. I'm a little Skye. Little bit Skye. And I'm here to do the regular update on the Streaming Video Technology Alliance to the media operations group. For those who don't know, the SVTA is an organization of essentially professional media delivery orgs, the technology behind how you do streaming, the streaming platforms, and the content providers that provide content into that space. It's sort of a professional group. Sometimes the analogy I sometimes think to the ITF is the SVTA is kinda like Nanog or other groups that do the, you know, the the more operation style of thing of taking ITF technology and deploying it. And so that's why we do these crossover feedback things. In particular, the document Sanjay just talked about, the network overlays actually started as an operational document over at the SVTA where a bunch of people had highlighted a operational problem they were seeing in deployments. And we talked about it there, and then we brought it over to the ITF as work, as an RFC. So that's how these two things go back and forth. And that's why on these when we do ITF meetings, I come by and I give an update on what's going on with the SVTA. So this one's pretty quick. Since we last met well, and and the rest of the year, these are the work projects that the SVTA has been engaged in. So DashIF has produced a number of documents and published since January. There is open caching. Open caching is a implementation and an extension of all the other pieces around CDNI from here at the ITF. So if you took CDNI and then you added all the other pieces that you would need to operationally deploy those RFCs from the ITF, that is open caching from the SVTA. And so we've published a whole series of new documents there. There's a group called Edge. Edge Compute is essentially working on the problem of how do you host caches, many, many, many, many caches at the edge right at the access network. So that in the previous discussion we had where we're talking about multicast and other tasks to get content to the edge to deliver at scale to users, the edge working group, the SVTA is working on that problem space. And we have measurements and QOE because you gotta have data and you want your content to look beautiful. And so that group there focuses on how do you do that and how do you monitor that and how you do analytics so that the content at the edge is of high quality at all times. And, of course, there's another group that I actually am the cochair of I called networking and transport, and we published a quick versus TCP report. We did a long running POC where we essentially asked the question, is quick and this is not I'm not talking about quick as in MoQ. I'm talking about QUIC as in HTTP three. How does that stack up compared to HTTP two or prior for delivery of streaming content? We did and so we did a report there. By the way, the answer is long running. It's no worse. It's no better. Quick HTTP three is about just as good as HTTP two. Pick the one you like and use it or you pick both and use it, but you won't take a real major hit. So the next thing I'd like to highlight to people because we have a lot of people in the room that are also SVTA members. We have an upcoming memory meeting where we're gonna be talking about all these technologies and and all of our work groups will meet. That's in Rennes, France, a beautiful place. If you've never been to Rennes, come to the meeting just for the purpose of going to Rennes. It's an awesome city. And in fact, Guillaume, one of our panelists, lives there. So so, you know, there's a real connection here. That's gonna be in the first week of October in REN. Thursday and Friday, the SVTA meets. But and this is for even people that are not SVTA members. On the Monday and the Tuesday, we are having a special workshop on AI in media distribution. We're not this is not a marketing exercise. We are not allowing marketing people to come do pitches. This is not an exercise about how to generate pictures of cats and dogs and people you don't like doing terrible things through generative AI. This is focused from engineer to engineer. The question of how are you going to take or how are you currently taking AI technologies and using them as tools in AgenTeq workflows, in production workflows, in analytics for your data so that you can understand your QE and your behavior types data. How are you using AI technology in your work stuff? We know we're having talks that are gonna cover things like AI driven encoding or AI assisted encoding, CDM log analysis, that type of stuff. So the Monday afternoon is an in person hackathon. So bring computers and sit down and and we're gonna code together. And then the Tuesday is gonna be, like, a full day in person workshop. And for those people who are SVTA people, the meeting on Thursday, Friday, the work groups, that's all hybrid. You don't have to come to
[01:13:25] Jana Iyengar: But the first part of the week is gonna be in person only, so do come to
[01:13:28] Glenn Deen: Rand. Rand. It the the AI portion is open to anybody. And so if you just go here, if you're not an SVTA member, it's $250. Come join code. Listen. Participate. You are an SVTA member, it's already included in your registration fees. But it's gonna be really awesome. We realize that AI is a hot button for a lot of people, both good and bad. This really and I I emphasize it again, is not a marketing exercise. This is engineers working with other engineers to talk about practical ways you're using it and to explore new ideas. So and that's that. Thank you very much. Any questions? If not, find me later on.
[01:14:11] Leslie Daigle: Alright. Thank you, Glenn. Alright. Alright. So we actually have some oh, I'm gonna stop that timer. It may feel like we've only got two minutes to talk about this, but there we go. The MOPS charter has been in place for almost seven years, and I think that we've been unbiased opinion. I think we've been delivering on on its main deliverables, namely regularly industry updates as Glenn noted just now. And we published three RFCs with a fourth already in the works. And it was it's important to note it was originally chartered as an experiment. We feel that well, it's not just me that feel it's been successful in its own right. Other working groups have been formed on the same model of being an operational working group to bring in industry perspectives and into the IETF work. So the with that, after seven years, we think that the the last line of the text in the charter should go. This is even this is almost updating a milestone. The ISG is establishing this working group on an experimental basis and intends to review it for re chartering to to continue or else closure in two years. We did have a review after two years and we're told to carry on, but the the major point of the charter update is to remove that sentence. What we wanted to talk about today is, are there other suggestions for updates to the charter? We can start noting them now. We don't need to have a raging debate about it today, but we will be discussing this on the MOPS mailing list, which is an advert for please join the mailing list for the next couple of weeks before we actually submit something to the ISG for consideration. Eric, do you wanna add anything to that?
[01:16:39] Eric Vyncke: So in effect, the responsibility for MOPS. Yes. This sentence was there for a long time. It was so abused that the working group was running fine. And as you said, right, we created the working group and the charter years ago, it was new. It was not easy to do. Now with IoT ops, s r v six ops, and, yeah, this is common now. So thanks again, Leslie and and mainly Glenn for pushing to get this working group. And, yeah, the first chairs as well. Right? So Kai and so on. And the new chair.
[01:17:14] Leslie Daigle: Okay. Any alright. Yes. Tim.
[01:17:21] Tim Chown: Hi. Tim Chern. Yeah. I don't normally come to this working group. It just happens that it doesn't there's nothing, I'll be honest, nothing more interesting to come to. So we don't do that much.
[01:17:31] Leslie Daigle: Thanks, man.
[01:17:32] Tim Chown: We don't source video content as one of the national research and education networks. Obviously, we take a lot in. You know, we would love to see you in this discussion earlier about more multicast, and I've been an advocate of more use of SSM and done an RFC about that. I just wonder if there's at the moment, there's no milestone set, and the last one was 2022. I don't know if ADs require milestones or not. Maybe a
[01:17:57] Leslie Daigle: That's my other work
[01:17:58] Tim Chown: for the room is, should there be a milestone? Should there be a a goal, something to work towards? And while I'm up here also, I noticed in the achieved milestones, one that was, again, 2022, I think. I think it points to the wrong RFC. It's pointing to something about AR, and it should be low latency. But it's the first time I've read the charter, but it that seemed a a typo.
[01:18:19] Leslie Daigle: Yeah. I'm not sure if that's pointing to the wrong RFC or if it's just that we shifted mid flight. But, anyway, Eric, your comments.
[01:18:26] Tim Chown: Yeah. Yeah.
[01:18:28] Eric Vyncke: Just to be clear. Right? So they are the milestone that typically updatable by the chairs, and we put some estimate of the timing of the delivery. What really cares in the charter are the work items, which are part of the contract between the ITF community and this working group. So what we will be updating in the process starting with this slide is the contract between the ITF community because the charter change will go through an ITF last call, anybody can object to the charter. But this contract is fixed for couple of months or year. The milestone they sell can can be changed. It's typically indicative. We try to put them good faith. They are not requiring. And, typically, I have yet to see a milestone edit at the bottom of the charter, right, outside of the charter, which is respected. It depends sometimes, most probably, but most of our working group, they are pretty much optimistic. Yeah. We'll be done in two years. Four years after, it's still somewhere in the in the cloud. Right? So, no, the milestone below the charter. Right? They are not required.
[01:19:35] Tim Chown: Okay. Thanks, Eric.
[01:19:40] Leslie Daigle: And and I made a crack about that's my other working group. The WGChairs working group is actually working on a question of milestones for working groups in general. And and I think my view is that we should make sure that the charter text is still current and valid, and then we can work on updating the the milestone section to reflect something that's a better version of reality. Any other thoughts on this topic this morning? If not, we can declare victory early.
[01:20:21] Sanjay Mishra: Yeah?
[01:20:22] Jana Iyengar: I think so.
[01:20:23] Leslie Daigle: Alright. Well, as I said, this will go to the mailing list for further discussion. Please make sure you're on the mailing list if you aren't already, and thank you very much for coming out. Thank you for our presenters. Thank you again to Chris Lemmons for being our notetaker and thank you for our panelists. Thank you everyone.