Session Date/Time: 21 Jul 2026 14:30
[00:00:14] Lenny Giuliano: K. It looks like that drove, that drove Jeffrey out of the room. Just a reminder, we can this flight cannot take off without a without a notetaker. So
[00:01:10] Max Franke: I'll do it. I don't wanna be here all day.
[00:01:12] Lenny Giuliano: Alright. Thank you for succumbing to the peer pressure. Thank you, Kyle. Thanks for helping. Alright. We'll wait one more minute for folks to trickle in, maybe. Okay. Greg, what do you think? Jeffrey, are we ready? Fire. Okay. So okay, folks. Welcome welcome to, mboned. Here's the note well, just as a reminder of, that, participation, signifies you are following all policies, all IETF policies, including those on intellectual property, conducts, and other standards of conduct. This is the note well. Please review it. And if you have any questions, please talk to working directors, working group chairs, or area directors. The session is being recorded. For those in person, please do make sure we will manage the the mic queues through the, app. So please don't just walk up to the mic. To be fair to those who are remote, please, join the queue via the app. You can use the the light version, if you are in the room. And, of course, with remote folks, the usual, keep your audio and video off until you are presenting. Okay. Here is the agenda for today. We have a a full agenda, very exciting agenda. Lots of we're very heavy on, deployment experiences, and some really, really interesting, updates in terms of deployments, in particular on, streaming over, browsers and technologies that are tangential to that. Does anybody did we miss anything? Any bashes to this agenda? Okay. Alright. In terms of active working group documents, the yang AMT yang draft is in the editor queue. It's been there for a little while, so that should be coming up soon. The next three drafts did not had, went through working group last call in March, and all three failed to gain, sufficient consensus to advance. In the case of the multicast Yang models, there were zero non author responses during working group last call. Subsequent to that, there was a rereview from the Yang doctor, who initially reviewed it. That review was provided. The draft is updated, and, I believe, got a thumbs up from that yang, reviewer, Dhruv. The next one is the the red first, do we have any coauthors on the multicast yang models draft that have anything to add to that? Say, when the authors are ready, we can do another review, working group. Sorry. Working group last call. The next one is the redundant ingress failover draft. This also had a working group last call in March. There were zero nonauthor responses. Subsequent to that, there were last year, there were some directorate reviews, and the authors, have requested rereview of those, of the updates. Tim, I'm seeing that you're looking to share a document. Is that correct? Tim, let's
[00:06:33] Tim Chown: Oh, yeah. I just yeah.
[00:06:40] Lenny Giuliano: Tim, is there something you're looking to add? What file the share is higher?
[00:06:46] Tim Chown: Yeah. I just put something down on my phone on the share side button on my phone. That's all.
[00:06:50] Lenny Giuliano: Oh, okay. A a butt share. Well, sorry. Never mind. It was a accidental share. Too much sharing. Okay. The so the next draft is the nonsource routed SR multicast draft. This went through a working group last call in March as well, only had two nonauthor responses. Subsequent to that, there were routing area and ops area directorate reviews. Both of those came in that the draft was updated, and it looks like, if I recall correctly, that those reviewers thumbed up those the updates. Jeffrey, do you have anything to add about the status of this document?
[00:07:41] Jeffrey Zhang: Yeah. So, during the last call, I was sidetracked and didn't pay close attention to it. Otherwise, I could have reminded people to send in more support for that. The two directory direct reviews from routing and ops area, the feedback was were all pretty good. I addressed their comments, and I I believe this document is very valuable. It represents the the common beliefs among many of our vendors and operators here. It's I think it's useful to to progress. So, if we could do another last call, that would be appreciated. Thanks.
[00:08:38] Lenny Giuliano: Great. You believe it's it's ready for working group last call now? Okay. So just overall, I think it we did three, concurrent working group last calls last time, I think we learned our lesson that maybe that was too many. So we're going to do consecutive and not we'll do one at a time going forward. But we do need folks to review and comment. We know it's possible because the AMT Yang doc got very, very strong consensus and lots of responses. So it can be done. So authors of those three documents, please reach out to the chairs when you think, it's it's ready. The last one is the last active draft. Well, it's not the last active. Kyle, do you wanna talk about the multicast security draft? And Yeah.
[00:09:38] Kyle Rose: I just wanna say that, Max and I were both astonished at the thoroughness and, attention to detail of that review. This is my sarcastic face.
[00:09:48] Lenny Giuliano: That's I I believe you're talking about the dorms draft, review.
[00:09:52] Kyle Rose: Oh, is that dorms? Oh, okay. Yeah.
[00:09:54] Lenny Giuliano: Yes. That was a, exceedingly underwhelming review. But, yes. Start with, start with the multicast security draft. What's what's, any anything to add on that? And then you can talk about dorms.
[00:10:10] Kyle Rose: The there have been no updates. There's there are issues in GitHub that we've added, but we haven't actually updated the text yet. I think we're just waiting for waiting for for additional work to to multicast quick to kind of, I don't marry the two, make them more in line with each other. So it just it didn't seem like a priority compared to getting work done on multicast quick.
[00:10:39] Lenny Giuliano: Gotcha. And dorms?
[00:10:42] Max Franke: Hi. Sorry. One one one quick addition for the the security thing. I haven't taught Kaidas yet because I forgot, but I have a student who writes her thesis about multicast security right now, and she's doing a full threat analysis and modeling and everything. So hopefully, after she's done, then we can use some of that for the draft. For DOMs maybe, yeah. Long story. Anyway, for these three, I think for DOMs, yes, as Kyle already mentioned, the review was basically not that valuable, unfortunately. So they all say it's ready, but I think at the moment, we don't really know what to do with it. Right? Because from the time it was written and the state it is in, our understanding of what we might want it to do has changed somewhat. Yeah. I I guess what I
[00:11:32] Kyle Rose: would say about dorms is we probably will need it, but we don't know quite what for yet. And so I think the conclusion we came to was, let's wait until we have a concrete use case that we need it for and then use that to drive it. Because I think until then, we're kinda it's kinda like a shot in the dark until we have a a specific use case for it.
[00:11:58] Lenny Giuliano: Do should are you suggesting we park that one as well?
[00:12:02] Max Franke: Yes. Maybe. Right? The the the there were two use cases, which are Seabeck and Emmy, but since they're parked now, it might make sense to park this for now, but maybe not quite as thoroughly park it as the other two.
[00:12:14] Lenny Giuliano: We'll park it close to the entrance, not far.
[00:12:17] Max Franke: Thank you.
[00:12:18] Lenny Giuliano: We'll use we'll use the near parking lot, not the, remote parking lot. Okay. Next up is Max. Any any, anything else anyone else has to add about any of those, any of these documents or other updates anybody wants to share? Alright. Cool. Max, you are up to talk about multicast extensions to Quik and getting Firefox to run multicast.
[00:12:54] Max Franke: Yes. Oh, sorry. I think I'm
[00:12:57] Lenny Giuliano: going to do this.
[00:13:02] Max Franke: Alright. Hi, everyone. So, yes, this is okay. I'm I'm gonna start from a bit wider perspective. Right? So last year, actually, almost exactly one year ago, I got an email who from one guy from one of the incubators that we have in Germany. Right? So in Germany, we currently have this thing where we have a lot of research, but it doesn't really end up in industry. So the government is spending a lot of money on trying to get that research into startups. So because I was part of a big six g project at the ITF, it's actually one year ago, some guy emailed me, hey. Don't you want to have something to apply for these startups? We have money left over. So I thought, why not apply with multicast quick and see where it goes? And long story short, it got accepted. So now we have five people full time working on multicast quick for a year. And this is right. So we officially started on June 1, so this is, like, the first few results of that. And I hope there will be many more results to come over the next year, so let's see. But, yes, m c quick. Right? You probably are all familiar with it by now. We talked about it quite a few times in mboned. We but the key idea is to just recap. We extend QUIC, right, to have make it use or allow it to use multicast. And basically, it's somewhat of a hybrid. The the regular QUIC unicast connection stays there, and it's basically a trust anchor. And you use it for things like encryption and make sure integrity frames and so on that basically you keep as many of the security and privacy properties that QUIC offers as possible. Of course, there's inherent trade offs with multicast. And then in addition to this to a unicast connection, you can have one or more multicast channels, which are unidirectional, right, SSM channels that the server coordinates. So the server announces these channels to the clients, and it tells the clients to join them. And then the client can decide whether or not to join those channels or not, right? And then it tries to SSM join. And if it actually gets multicast packets, it'll acknowledge these packets and that way the server know that the multicast path is green. And one of the first things we learned now that we have a working implementation in the browser is that so far we thought, okay, you try multicast first and then you do a unicast fallback. But, of course, now in hindsight, it's obvious. You do unicast first, and if multicast goes green, you stop sending unicast. So that way it's all quite seamless now. Okay. So that's mcquick. Then really quickly about mock, right, because I assume most people in this room might not be that familiar with mock, but mock is media over QUIC. It's got another lot of traction right now. At this IETF, they have free meetings with six hours in total, right, and they have almost monthly side meetings. But basically, it's an architecture that uses QUIC to efficiently distribute media and, for our use case, particular interest, real time media. And it's basically somewhat of a successor to both WebSockets and WebRTC and so on. I have based on web transport and all of these things. Right? So you make use of the the things that Quick gives you, like multiple streams, avoid head of line blocking, and and all of these of these things. But, yeah, basically, what you have is from the architecture point of view, you have a publisher, right, which is the mock publisher that in basically is the media source. It ingests the the video to one or multiple mock relays. And these mock relays are basically a CDN, and then they connect and distribute this media to the to the clients. Right? So and they cache this the the media and so on and do whatever CDN would do. And so, yes, these objects. Anyway, I don't want to spend too much time on this. The important part is that with mock, why it's good for us and why we use it is that it maps very well to what we had in mind with multicast- quick anyway. Right? We have this fan out and so on. So what we do now is that the mock relay, right, which is supposedly close to the edge anyway, is now also the multicast source. Right? So in addition to it sending the data over unicast, it also provides it over m c quick. So if a client does have a multicast path to that to that relay, then it will get it over multicast. Otherwise, we'll just get it seamlessly over over unicast. The other nice thing is because this is mock, and mock uses web transport, and web transport is now in basically every browser. Right? So Safari edited or WebKit edited. I think now it's two months ago. Firefox and Chrome and Brave all had it already. Basically, now you can just go to our website. Right? And no matter what browser you have, you will just see the video playing. But if you have the modified Firefox that I will talk about now, you will get multicast. Right? And you don't need any special tricks. You don't need anything, right, the same website without any hidden triggers or whatever. You just go to the website. If multicast arrives on your device, for example, through AMT, you would just get multicast, and the client, the user won't even notice it. Right? The the user doesn't have to do anything special at all. Okay. So, yes, the point here is that, as was intended with design of m t quick, all of this multicast stuff is, as I mentioned, transparent to the user, but also transparent to even mock in web transport. Right? There was a few things, particularities of web transport that make it not perfectly fit to web multicast, but we were able to solve most of them. Right? For example, web transport and mock, in particularly, they all use reliable data. Right? So they use stream frames, not datagram frames, which you might think, okay, this is not a great fit for multicast, right, because maybe we don't want reliable data. But they actually figured it out, it all works surprisingly well, to be honest. So, yeah, this basically is the general architecture, and what we have right now, right, is this this free, I'll call it, of of things, right, the publisher, the origin, it generates h two sixty four video, but can generate whatever. It publishes the mock objects, then we have our reader and our edge, and that is basically the fan out, the CDN, and this is also the the owner of the multicast channels and the fallback. And then we have a browser, right, the modified Firefox, but we also have a different app and so on on Android and Mac OS and so on that can just render and then display this. Yeah. This is basically what I already mentioned. Right? You prove that multicast delivery works by having this cutover, so you send regular mock first. And so the video starts playing for the user immediately. There's no delay or anything because you need to set up the multicast tree. And then when multicast goes green, if it goes green, you automatically fall over to multicast. And you also automatically fall back to unicast, if multicast transmission stops. And basically, with the implementation we have now, you don't notice it at all. Right? Like, the cutover from multicast back to unicast, you get a very, you know, maybe two frames freeze, but that's it. And I mean, this is also something you can tune and so on, configure more. So, yes, there's now two open source implementations of mcquick. One is extension of Quiche, right, CloudFare Quiche, and that's the one we use for the back end, for the servers. And then Nico, which is the one that is used by Firefox, is is the quick implementation. Well, that's used for Firefox, right? So both of them now support mcquick, right? Not the current draft, but the previous version eight. Things are quite fluid. In the newest version, there's quite a lot of learnings from these implementations and so on. So this is, again, an iterative process, and we just started and very much will develop this further. But, yes, what works today, you can more or less inject any video you want with the complete regular mock architecture. And there's a lot of open source on it already, so you can just inject it, use the regular mock relays. Well, not the regular mock relays, but you could use a regular mock relay and just add this multicast capability, right, which, again, is not that complicated if you already have the implementation in Quiche. And to cut it short is that we already see, right, so we have integrity frames. That means you can't inject traffic because multicast or the quick packets are protected by AEAD, but that alone isn't enough because all the receivers share the same keying material. So in theory, one of the receivers could inject a valid packet into the multicast stream. So in addition to that, we also have these integrity frames which basically hash every single packet. And the question then was, does this add a lot of overhead? Does this add a lot of, you know, latency or something? And the answer from the implementation is no. Right? So this is, again, a very naive and unoptimized implementation. But even now, we already see, right, 80% reduction in egress traffic if you use the multicast, which, again, is secured and encrypted and everything over the unicast. And the whole multicast path additions, so the integrity checks and everything, it's about sixty milliseconds of latency, right, which is nothing. But this is the other thing. The mock is incredibly low latency. Right? So we have end to end latencies now of two hundred milliseconds, right, which is, again, this is from a Le Node in Frankfurt streaming to your phone. Right? This is very low latencies anyway. So this is actually another great fit because it just the sixty millisecond, it doesn't really matter here. So, yes. That's yeah. That's basically it. I mean, the other thing is, as I mentioned already, you can just the the user doesn't notice if the paths change and so on. It's very seamless for them. There's no hitching hitch ups or anything, and, yeah, that's it. And, of course, because of the nature of things, you can because the unicast is built in, you don't need widespread multicast deployment. Right? You just have this client and you have the server. And if multicast works, that's great. Right? If multicast works end to end, that's great. If it doesn't work, all you do is at the beginning of the connection send three extra frames. Right? And if it's not negotiated, if multicast support doesn't exist in the network, then that's it. Then you just have regular mock without any overhead at all. Right? So this is actually quite attractive and nice deployment path, right, because it can be very incremental. You can also have some islands where you deploy SSM, sorry, AMT. And these islands, for example, the campus, then they that on that campus, you get the multicast, and everybody else gets it just for regular regular mock. Right? So nobody is really losing much here. Yeah. Some stats. I think you can see when I turned off AMT and when I turned it back on, or otherwise, the other way around. I turned it off and back on, and you can see the slight dip in egress traffic. But, yeah, that's it. So the idea now is that we try sorry, present this tomorrow at quick as well along with the the Flexicast work and so on from Louis and Olivier. And the hackathon the hackathon, we also had a minimal quick extension for multicast. Right? So we just edit one frame and just to see what is the basic thing you need to add to get any multicast with quick working. So, yeah, this is this is the path forward. And then, of course, we hope to see at some point maybe we can actually try to run this somewhere, right, and just try it in some more realistic scenario than I mean, again, it's live now on the Internet. Right? You can just go to the website on your phone and and and try it, but somewhere where people might actually want to watch it. Right? And you actually get some real users and and and so on. So, yeah, that's pretty much it. Thanks.
[00:26:18] Lenny Giuliano: Omar, it looks like you have a question. Let's see.
[00:26:22] Omar El-Sadek: Yep. Can you
[00:26:23] Lenny Giuliano: hear me? Yes. Yep.
[00:26:27] Omar El-Sadek: Yeah. So first of all, great work, with this, Max. I've been working with the Chrome team actually on implementing multicast. So this is really awesome because, you know, the the approach that I went and and and and Chrome has been doing was with the direct sockets API. So that's a WICG, w three c draft for how to do direct sockets that can be UDP, TCP, anything in nature that Firefox, a number of years ago, just didn't have the appetite for. So I'm curious as to how you're actually, you know, what is there I I don't I don't know how Firefox actually works on this stuff. Is there a bug tracker? Is this number one, like, you know, active upstream? And, like, what are the interfaces for, like, how we're actually exposing it? Because there's a lot of considerations as well. I think that, you know, we're talking about security, so, you know, access controls, you know, origin policies. So Chrome has put everything behind the isolated web app, which kind of just pushes it under the rug a bit, honestly, without really addressing how it's going to be integrated into ecosystem. But I think that there would be some great use in kind of coordinating efforts and and and how we can open this up to general availability, what are the gaps. So that's on the browser side. On the multicast quick side, I've also been working on some stuff there. So keen to, get in touch with you. Approach that we went has been, MMT based. So that has, you know, headers that offer, you know, 40 air correction, and and, you know, other facilities that, I'm curious how you are going about for reliability, especially the fact that we're doing this potentially over the Internet where you might not have, you know, lossless connectivity?
[00:29:18] Max Franke: Yes. So for the first question, this is changing the quick implementation that Firefox uses. Right? So this is not something that you can just add to Firefox. You need to change the underlying Neko quick implementation. Right? So this is not something that will be there in, you know, six months or probably not even a year or whatever. Right? So to get this upstream into Firefox, you need a specification and all of that. Right? So this is very much a demo and not something you could use use in production anytime soon. Regarding the second part, there's actually yes. I I I also noticed that relatively quickly, and this is actually about the thing I will present at the end if there's time, which is AMT over QUIC, which might sound kind of crazy, but the the point is there if you lose a packet in the tunnel, right, in the AMT tunnel, you don't have to retransmit it if it's reliable data, which, again, WebTransport is and mock is. A thousand times for all the clients behind the AMT. You just have to transmit it one retransmit it once in the in the tunnel. And with that, it's one approach I hope you can, you know, avoid the catastrophic impacts you get with losing multicast packets in in the core. Yep.
[00:30:32] Omar El-Sadek: Well, I'm I'm really excited about what you're doing, so, we should definitely, you know, bring our efforts together. Sure. Yeah. I'd love to hear. About.
[00:30:42] Lenny Giuliano: For those in the queue, we're we're we're looking to move on, so please, quickly answer the or ask questions.
[00:30:50] Kyle Rose: Oh, Kyle Rose. I was just gonna I was just gonna say, quickly that, sorry. I didn't no. Sorry. I'm not in the queue. My apologies.
[00:31:04] Lenny Giuliano: Chris, you're up.
[00:31:07] Chris Needham: Hi. So, yeah, Chris Needham, BBC. So I'm very active in the w three Like, I'm chair of the media working group, which hand handles the the web codecs API that, you know, that rendering of of this would rely on. I'm actually very encouraged to see, like, the the implementation work you're doing in Firefox and also particularly what you mentioned, Omar, about the work that you're doing in Chrome. So I'm very much happy to, like, work with you both to sort of coordinate how we move forward in in the sort of browser context of, like, what the API support there might look like. So yeah.
[00:31:40] Max Franke: I I remember when Jake was at W3C probably now four or five years ago, and they are basically what immediately popped up is you will need some kind of pop up from the browser to tell users, hey. You're now using multicast. You will share some of your data. Some of this will not as be as private as a regular web connection. Right? So I don't know. That was that's the the the thing I remember about that. Yeah. But I would love to get it to work on that. Yeah. Let let's follow-up. Yeah. Yeah. Thank you. Yep. Thanks.
[00:32:06] Lenny Giuliano: Great. And, Max, just a you have a a link that is is this available for people to demo? Or
[00:32:15] Max Franke: Yeah. Sure. Everybody can so the the the website I I I will send the mail to the the list as well after this. Again, sorry. This is all a bit most of this actually got working in, like, the last week or two, and this this statistic dashboard where is it I I actually edit the slides ten minutes ago. You didn't notice, Lenny, so I'm thankful for that. But I got this working, like, an hour ago to to have to have the statistics and dashboard. So this is all quite fluid, but the link for the Firefox let me see. It's all on there's there's a GitHub organization called QuickCast, and they it has all the the repos. Right? There's more to it. I don't want to spend too much time, but I also basically did a newer version of Jake's old m c I x receive library, which you can is in Rust now and has a bunch of bindings to Python and so on, which now should support pretty much any platform you can just throw in, and it will do all the nasty stuff about joining SSM and ASM and all of these things quite well. And there's a new open source AMT implementation, Relay, and Gateway. And as opposed to the old one, it should actually be RC compliant and also has drier than all of these things. So, yeah, if you're interested, check out yeah. It is the github.com/quickcast, and it has all the all the repos.
[00:33:29] Lenny Giuliano: Great. Any other questions? And Max is gonna be coming up at the end to talk about AMT over quick.
[00:33:38] Max Franke: Alright. Thanks. Cool.
[00:33:40] Lenny Giuliano: Thank you. Sanjay, you are up. Let me bring up your slides.
[00:33:51] Sanjay Mishra: Thank you. Hopefully, everybody can hear me.
[00:33:57] Max Franke: Yes.
[00:34:07] Sanjay Mishra: Cool. Awesome. Oh, let me see. I do need to get okay. I got slide control too, so I think we're all set. Well, good evening, good morning, good whatever time zone you are in. Okay. So I think, what I will do is I'll walk everybody through just a quick reminder of what Aircast is doing and the progress we're making. We've made, similar presentations in the past, so we will go through this really, really quickly, at least the introductory parts. So Aircast, right, is we started with we were all frustrated with the delays that we've seen in IP, streaming of live events. Right? Somewhere between twenty seconds to you know, there doesn't seem to be an upper bound. Could be a few minutes as well at times. And frustrated with that, we said, okay. Let's come up with a way that we can do sub second end to end latency for any IP client anywhere in the world irrespective of whatever device OS, you're on, and let's reuse, IETF standards, to the degree if possible. And if we have to invent something, then we will go do it. Right? So this is kind of what our vision was when we started, and let's see where we have where we have reached. Right? So the kind of the technical underpinnings of what we're doing is really rather than chunking up the incoming video stream, we've decided to use, you know, really a flow based. Right? So you capture a frame, you send a frame rather than try and collect a few frames. To help with the scalability issues that that are created when we do this, we decided to use multicast as the core transport. And then, you know, we are all aware that we are not going to have multicast supported everywhere. And where it is not, we use, AMT. Right? That I think everybody here, in this mboned group is quite familiar with. And then, you know, the question that kept coming up was, hey. Where are we gonna do all the different features, whether it is ads or security or other things? And our approach has been we're gonna do all of the features to the degree possible at the edges. Right? So really try and keep the transport network, minimize the complexity in the network itself so we can actually really, really allow us to scale. Okay. Now we started this by actually use the system for in venue distribution of content. So think of, you know, you got a venue with a couple of 100,000 people in there, and, you wanna distribute multiples video streams and audio streams over Wi Fi or IP. And and, really, you know, there was wasn't any other feasible approach to do it. Unicast wasn't gonna, cut it in this kind of a framework. Right? So, literally, this is what we did here. And I think I've shared this picture with everybody here before, but we'll do it quickly for for folks who are new here is we have our own little AirCast, encoder box that we bring. It ingests the content, packages it in IP, and then we send it over to the in venue network where we distribute it over Wi Fi and the local guest Wi Fi network. So and then we've extended this concept with, hey. Look. It's not just the in venue network. What if we were to to try and achieve what we set out to do, which is distribute the content to any other IP client, whether in Venue or over the public or a managed IP network. Right? So we have, what we call them the Aircast traffic servers in various geographies, and then we run AMT between the AR traffic servers and the clients as needed. Okay. So let's, in terms of, the real, you know, I've always maintained. Right? You know, you have a good plan, and then when it hits, the rubber meets the road, you really find out how good you are. Right? So over the last, twelve months or ten months roughly, we've done, more than a few actually fairly high profile deployments. We started at the US Open Tennis tournament last summer where we did, multicast over Wi Fi in the venue itself. So this was, something that we provided an update. This was actually quite a successful deployment. We demonstrated that we could do a latency of about three hundred to four hundred milliseconds end to end from, when we receive, the analog content into our system and when it is rendered on on on a device. Then we actually the Australian opened, we'd said, okay. Let's take a step forward. How do we distribute this content not only in in the venue or Wi Fi, but what if there were people watching at home or on a cell phone but over a cellular connection as opposed to Wi Fi. That deployment was actually very successful as well. The delays, of course, were a little bit larger over cellular, but still actually somewhere between five hundred to eight hundred milliseconds depending on a few underlying factors that we can talk about. And then, you know, we did a a recent deployment at the Wimbledon that just concluded a couple of weeks ago, where for the first time, we actually had multiple, AMT relays and multiple traffic servers, and we were routing clients to one or the multiple AMT relays, and, we'll walk you through, what we observed there. So some of the key things that we've done since the Australian Open, actually, if people remember, we had some issues with the VLC client not being able to support RTP. So we were just using UDP directly. Since then, we have actually fixed that issue, on the client side. So now we have support for r d RTP over UDP. Also, I think folks would remember we had some issues. We were using a direct, external connection, and we had some issues with firewall and NAT translation. Since then, that issue has been resolved as well, and we've actually, tested it, quite extensively, including at, the Wimbledon event last, earlier this month. We've also now implemented what I would say stream rate adaption adaptation. So in case, you know, depending on your bandwidth, we may be able to change the stream, that you're receiving. And and finally, we have a unified Aircast app, which includes both the in venue support and, you know, outside the venue support available now. You can download it, from the Apple App Store. And by the way, it's only available on iOS for now. We've kind of just, we have an early Android client, but we've kind of decided to, pause the effort till we, get a certain amount of maturity on the iOS side. And then, of course, our plan is to make those changes on the Android side as well. So we just appreciate everybody's patience while we're doing it. And by the way, feel free to go download the AirCast app from the App Store. We have usually some content there, and, occasionally, we will have, you know, some of these, bigger marquee events. You may need a little bit of, approval given a lot of the content that we do feature on our on our app is, you know, the owners are a little bit, as you can understand, sensitive about who gets to access these, really low latency streams given that's not what everybody else has access to today. Okay. So this is kind of the high level transport architecture that you will see that we've implemented today. So we have the in venue system, which takes in the content, typically over HDMI or SDI or any other format, really. We do the encoding, and we do all of the multicast IP packaging and so on that we need to do. And then we send it one of two ways or both ways, really, to the in venue network, which is really, you know, in venue Wi Fi network and so on, or we tunnel this traffic over to our, AMT relays and so on. And the AMT relays then send it to our, our clients, today on iOS or PC. Right? So it's a relatively straightforward architecture. And, so let's talk about the challenges, that we that are kinda unique to, what we saw at Wimbledon. Right? And to our surprise, by the way, at Wimbledon, right, you know, we find out that the preferred partner cellular, provider at, that Wimbledon had was an I p v six only network. Right? And, previously, we'd always been working with an I p v four, I p v four, and v six network. The particular provider in this case had was exclusively I p v six, and it's something that we had not tested before. And we find out that, we had a few challenges that, you know, the Aircast team and I know Sada is here from the Aircast team today, and, he can provide additional color as well. But let me just walk everybody through to what happened. Right? So the AMT multicast basically failed to work when we had, an I p v six only network. And I'm not gonna walk you through so you can see what was happening is the network had a NAT 64 translator in it, and, we had an I p v six client. Clearly, an iPhone supports I p v six, and we would get an I p v six IP number, and we're talking to an AMT relay that's I p v four only. The discovery of the AMT relay was working just fine. It was the next level handshake where we had the troubles, and the tunnel would not get established, clearly. To the credit of the team, they were able to quickly, diagnose the problem and, overnight come up with a fix, for this. Right? Really, what we did was we fixed the client itself. We were getting the the NAT 64 address already from the relay in the step one in the first level of exchange that we did. And, instead of rebuilding that address every time, let's just make sure we continue to use the address that we received. Clearly, you know, I think we can do this better. We, longer term, of course, we need to get the Relay I p v six capable. So so I think this is, something that
[00:47:08] Lenny Giuliano: Did we just lose Sanjay?
[00:47:10] Max Franke: Yeah.
[00:47:15] Lenny Giuliano: It's the
[00:47:18] Sanjay Mishra: Okay. Hold on. Okay.
[00:47:19] Lenny Giuliano: Cut him. The v six police cut him off.
[00:47:22] Sanjay Mishra: Yeah. I think so. I think v six was not happy about me. Okay. I think I'm back again. Right? Yes.
[00:47:31] Lenny Giuliano: We hear you.
[00:47:32] Sanjay Mishra: Okay. Perfect. Perfect. Awesome. Okay. So I'm not gonna walk bore everybody through all of the the details here. We're happy to answer all the questions and what we did. But, really, you know, I think, as I said, the performance was actually just as we expected. No big surprises there. The glass to glass delay was between five hundred to eight hundred milliseconds depending on where you were. If you were, being served by a relay ride in London and consuming the traffic in London, the delay was actually closer to five hundred milliseconds even below it. But if you were in Boston and trying to consume the stream in London, you probably, your delay was closer to, eight hundred milliseconds or so. We delivered streams at multiple, resolutions. Everything, worked flawlessly, and I think we were, you know, faster than any of the IPTV streaming that was happening locally, including, the own private network that, the Wimbledon team had in Venue itself. Right? We were actually significantly ahead of, pretty much any other IP stream that was available anywhere. So I think, in terms of what's coming, you know, last time I promised we're gonna be working on the authentication of gateways and relays and adding, you know, really what I would say are things related to security and making the solution robust. So obfuscating our relay addresses, building in encryption capability, and so on. Some of this work has maybe just gotten a little bit delayed, but I think we are making progress. And, you know, I would like to thank Max and everybody else who we've had conversations with in this regard and appreciate everybody's feedback here. So stay tuned. We should have updates on some of these other topics, in the coming, meetings, by the way. I think this was probably the last slide from me. Happy to take questions. And by the way, yeah, here's a little QR code. If you wanna download the Aircast app, please do it. And, you know, we'll keep everybody updated on the events, that we'll be supporting in the in the near future now. So open to questions.
[00:50:18] Lenny Giuliano: Tim? Oh, you're trying to slide, share slides again. That's okay. You're good.
[00:50:32] Tim Chown: It's very very easy to press that button on your phone by mistake. Yeah. Yeah. So excellent stuff. Thank you. Yeah. We ran into so I'm from Jisc, The UK's National Research Education Network. The acronym is the same thing here in Austria. And we work with Jayant to provide the connectivity between all the European NRENs. And we had we've set up AMT relays on that Jayant network, and I think Lenny and others have been in involved in that. And we were trying to do what you were doing with AMT relays before and finding that you do VLC AMT colon blah blah blah. And you can only put v four addresses in. And we've, five years ago, we put in a an issue or whatever it was somewhere in the VLC repositories or whatever asking for v six support. I kind of assumed it would be here by now, so I'm really depressed that five years have gone by. And obviously, with what you're doing and what your company is doing, I would hope you got a little bit more leverage to convince them to add that support. But, yeah, you're absolutely right. That's the long term solution. Now I'd love to see all this working with v six and SSM and so on, but just a bit depressed that five years on, we're still in this position.
[00:51:47] Sanjay Mishra: Well, I wish we had talked to you before and saved ourselves a couple of sleepless nights. Right?
[00:51:54] Tim Chown: Yeah. But it's not your fault. It's yeah. So but your thing's right.
[00:52:00] Sanjay Mishra: No. And by the way, you no. No. That's okay. And we are working to to get us all there. The good news is it's not a showstopper. Right? If you if you need help, we'll be absolutely eager to provide you the support that you need. It's no longer a showstopper. Our system worked absolutely fine, and I would say it is kind of battle tested out in the field now. So so we do have a workaround. Is it the ideal setup? I would say probably we could it will be great if we have the relays supporting I p v six, natively. So absolutely. But but thank you, and, yeah, looking forward to working together, by the way.
[00:52:43] Tim Chown: Yeah. We could've yeah. And you as well that you have been doing v six only in the handset for lots of years as well in the Yeah. Six four x. So I think that's not uncommon now in mobile operators to do that. So if you hadn't found it there, you'd have found it somewhere else. But, anyways, Absolutely. It's it's good work you're doing.
[00:53:00] Sanjay Mishra: Thank you. Thank you.
[00:53:02] Max Franke: Yes. So the relay I talked about or the AMT implementation I talked about earlier, right, the ones the one we made, it does v six on everything. So both relay and gateway.
[00:53:14] Sanjay Mishra: Awesome.
[00:53:15] Max Franke: Yeah. Also, regarding one slide before with the AMT encryption and so on, I promise I didn't look at your slides before, but basically, AMT over quick is hopefully solving all of that. So I am reassured that maybe it wasn't a stupid idea after all. So I I would present it. Thanks.
[00:53:34] Sanjay Mishra: No. I'm I'm I'm looking forward to that, Max. And, yeah, we definitely should connect offline and love to leverage your work, by the way.
[00:53:45] Tim Chown: Someone in the queue ahead of me, or was that you?
[00:53:48] Sanjay Mishra: I think Omar got in ahead.
[00:53:50] Tim Chown: Alright. Go on, Omar. Go ahead. Or maybe he pressed the button accidentally. I was just gonna say, Max, that we'd be happy for the shout thing to look at deploying your Relay. Maybe we can talk about that.
[00:54:08] Omar El-Sadek: I I was muted. Can you hear me?
[00:54:11] Sanjay Mishra: Yes. We can hear you, Omar.
[00:54:13] Omar El-Sadek: Yep. We've got a v six Linux relay implementation, actually. So I'll touch very, very briefly on it in my presentation, but part of improving capability for soft relays have a number of patches for Linux around Mhmm. Stability for v four, as well as, some v six implementation. So, yeah, would love to learn more and
[00:54:44] Sanjay Mishra: No. Thank you.
[00:54:47] Omar El-Sadek: Yeah. Use.
[00:54:54] Sanjay Mishra: Go ahead, Omar. Sorry.
[00:54:57] Omar El-Sadek: Can you hear me?
[00:54:57] Sanjay Mishra: Yeah. I think we lost you in between. At least I lost you in between.
[00:55:02] Omar El-Sadek: Oh, yeah. I was just I was just saying we've got a v six implementation for Linux. So still haven't upstreamed it yet, but if you that's something you'd be interested to test, we should get in touch.
[00:55:15] Sanjay Mishra: Definitely. Definitely. Thank you, Omar. Absolutely.
[00:55:25] Lenny Giuliano: Great. Any other, questions? And, Tim, did I hear a commitment to, deploy a relay for, Sanjay, for his next, I don't know, grand slam event?
[00:55:44] Tim Chown: Certainly. I'm very happy to to look at that.
[00:55:47] Sanjay Mishra: We'll definitely take you up on that, Tim. We're always looking, as we're looking to scale up, we need, you know, more and more relays and more and more geographies, so we'll absolutely take you up.
[00:55:58] Lenny Giuliano: Yep. Okay. And and for what it's worth, there there is Tim, which which we is we? Is it the is it Geonnt? Is it the the relay sorry. The RNA network, your JISC?
[00:56:13] Tim Chown: It could be Jant and or JISC. Yeah. The the Jant network is the network we operate. Yeah. So Gotcha. Yeah. We can look at that.
[00:56:21] Lenny Giuliano: Yeah. And and, just as a reminder, there there is we we do have the a couple of Internet two, networks that are connected, with. So, like, Karen, at George Washington University, has a connection to, and that's where you get the content on multicast sorry. Menu.multicast.net. So maybe, you know, could could add the content there and for that, connect to that connect to that global multicast deployment. Okay. Any other questions, for Sanjay? Alright. Thank you, Sanjay. That was, great update.
[00:57:09] Sanjay Mishra: Oh, thank you.
[00:57:25] Lenny Giuliano: Alright. Next up, Omar.
[00:57:33] Omar El-Sadek: Alright. You
[00:57:34] Lenny Giuliano: have about, let's say, twenty three minutes.
[00:57:41] Omar El-Sadek: Okay. Alright. So this is our experience with building out a native a multicast native CDN with Blockcast and, you know, our implementation of the TreeDN architecture end to end, spanning from the core, with dynamic tunnels all the way to the browser in Chrome. So a lot of this is new to me, so bear with me with the DIMT side. But, you know, saw that draft, and it solves a problem that, you know, we we've been out to solve, which is, you know, there's no, way to get native multicast into, other domains, and that, you know, there's gaps with coverage that, also, if you wanna open this up to other ISPs that, you know, it's how do you make a state that is scalable. And, you know, we want this to be something that is permissionless, and, you know, not behind licenses. So, we took the decision to make an open source implementation, that's purely, you know, it's just on demand. Everything is on demand. So when a content piece of content is requested over PIM, that's the only time it's sent over the network. So this text is a little bit small. Let's see. Hopefully, y'all can read. So walking through this, we've got on the left side a implementation of Chrome with SSM that is now main line. I've dropped a chat link. So within a month, that should be hitting Chrome beta in around three months, to Chrome stable. And, I've got a wrapper. I mean, I'll I'll go in a little bit into that and, essentially allows for, a browser tab to open up via the isolated web app, a native direct socket. In the case that there is a path to, you know, our, receive side distribution point natively. If there isn't native multicast, it will fall back to AMT and discover via dryad. And, essentially so we've implemented this in FRR and have interop against a Junos upstream. And, yeah, the the primary principle is no static state. So, you know, we've defined a CIDR, with all of our multicast sources. We have a combination of video, financial data. And, yeah, on the left side, have demonstrated with a off the shelf router, you know, the establishment of the tunnels, and, on demand multicast joints and leaves. So the, yeah, there's a lot of details that were, kinda left as an implementation, exercise with the DIMT draft. But, essentially, we put a multicast VPN address family, into FRR, just focused source specific multicast only, global table, just the smallest useful slice. And, yeah, that will be upstreamed and have demonstrated that this can establish a session with the Juno side, without any, static, RPFs. And, yep, we, so dynamic Internet multicast tunnels is how two multicast networks peer without having a standing config. And, you know, so one tunnel is established per peer pair, and that's built on top of the first PIM join and torn down on leave. And, you know, discovery is all through the BGP extended community and not through DNS. And, yeah, the idea is that we wanna be able to set up AMT relays and enable, you know, service providers to set up native peering without exposing their routers and network to conflicting, you know, state with multicast, and for people that are outside of those networks to be able to use AMT at the last mile. So yeah. The draft, you know, it's it gives you field layouts, but not the actual code points and doesn't really specify things like equal preference, tie breaks, or how the extended communities ride bill routes in global table use. So, you know, we've designed this in the shape of the draft, but, you know, the behavior is our own implementation, and love to continue to work with authors and see how this evolves within the ecosystem. So for our design choices, you know, we chose config knobs and code points that, you know, we could change because this is you know, hasn't been assigned yet. But, yeah, it's, carried on, you know, normal Unicast routes covering the stores. And we did have issues with extended communities and interop, so the router was only supporting large communities, not extended communities. But, yeah, that's something that we'd like to see supported in that, you know, extended communities are nontransitive, so it is a little bit easier for a network administrator or operator to, you know, swallow setting up multicast, without the foot gun of, you know, transitive routes. So, yeah, it works. We've got some early results. And, yeah, it can connect to an AMT relay, and making that work with, dynamic tunnels was quite interesting. So there's a number of patches that we had to work on. The most important one is, essentially, upstreaming of, iGMP MLD host reports, from the relay so that we can signal to establish the dynamic tunnels. So these are still to be upstream. Part of it also is experimental IP v six support, and some scalability patches to allow for a larger number of sources. I think right now it's hard coded at, like, two dozen sources. So, yeah, that will be upstreamed. But, yeah, as I was saying, that third patch is the most important and allows for that membership state to be, sent to the hosts, into FRR so that we don't have to specify static routes. So, yeah, a little bit about the browser side. So we've defined a interface window dot multicast, and this is where keen to work with Macs and and folks working on Firefox, w three c on how we want to expose, multicast to browsers, but this is my take on it. So, yeah, essentially, you can dial using the direct sockets interface. And, yeah, that works also over the LAN. So it requires an isolated web app. Isolated web app is kind of a kind of like a browser extension, But what's cool is that you can have this running on one browser, somewhere in your LAN, and any other device in your network will be able to detect the isolated web app over MDNS. And yeah. So we have a proof of concept of MMTP over QUIC, and that allows for, you know, just regular quick video delivery join over quick when you first get the page. And then if the page detects the isolated web app context, it will try to establish if the service is advertising some multicast, try to establish the connection natively. If that doesn't work, it will fall back to dryad. And only after it successfully switches to multicast, it will terminate the unicast link. So, yeah, the idea is that we wanna be able to scale this to, you know, any operator, any publisher who wants to deliver multicast over the Internet. So thinking a lot about how do you wanna scale this. So, well, first of all, how do we make this permissionless? I think there's a lot of questions around, you know, encryption and authenticity. Encryption is kind of a debatable concept when we're talking about group delivery, but I think you definitely need to have authenticity. And but, yeah, when you're actually establishing these routes, you know, how do you permission it and keep it permissionless? Are there any security, you know, vectors that we should be aware out of, in our goal? That's, I think, an open question to you guys. But, yeah, I wanna make the state, you know, part of this is should be proportional to the actual services that are traversing it. You don't want flooding of traffic, unnecessary state, explosion, and, you know, looking at the scale of, you know, how many ASNs are there, you know, tens of thousands. So how do we scale that to that number of communities? So these are some of the goals that we're working towards from a stealing perspective. But, yeah, we'll be contributing back drafts. So of this and parts of this. So, look out for feedback, but definitely wanna see these drafts moving forward. And, yeah, at a high level, you know, we've got a lot of pieces coming together here, and pieces that haven't been discussed. So, yeah, with that, you know, just some high level asks. Is, on the draft. So, if we wanna have something around tunnel life cycle and liveness, we did run into some challenges with, you know, tunnels that are not active, and what does that mean from, you know, an availability state. But that might be out of scope here. And, yeah, the discovery mechanisms. So, yeah, curious who is also running BGP, MVPs, or GTM and looking at Interop. And, yeah, happy to share sources. So trying to get this upstreamed. If anyone is interested, please reach out. But with that, we'll turn it over to questions. I think we have one.
[01:15:14] Jeffrey Zhang: Yeah. So this is Jeffrey. I'm very very impressive work. I'm very impressed that that draft-zhang already implemented in your deployment. It's interesting to see that it is used together with GTM, and I I think you also mentioned there was no InterAIS. So I think there there are a lot of details that I need to find out. I'll I'll I'll I'll reach out to you offline. And, also, the the DMT draft itself, yes, you are driving us now. We put out the put out that idea, and then we have not got a chance to refine it. And now that you're you're pushing us forward. It's great to see that. And we actually have some thoughts about changing the extended community to attributes because we got the feedback from some BGP experts that operators has great flexibility in in swallowing the the extended communities on on the route propagation and changing to a to separate a different prop attributes maybe it may make it a little bit harder for them to do that. So that is something that we thought about. So we we can discuss it more now that you've already implemented the extended community method. And also the non transitive way, the suggestion, I also need to we need also need to talk about that because the idea was that that extended community with the travel across ASs. And even if you have routers not understanding that, you will still be able to pass it along and so that the downstream router can still use it. So we I all need to understand better why, your purpose.
[01:17:36] Omar El-Sadek: I I think that what we really you know, I and this is just my just based off of my biases. Right? And I think what would be a great exercise, and I think you've already started that, is talking to vendors and knowing what are the capabilities that are within reach. You know, I think a big part is, like, we don't want this to be an academic exercise and, you know, another, you know, hardware release cycle. So what what is what is what is available within, you know, the vendor ecosystem that we can easily build on top of. But also from an operator perspective, you know, what are the concerns, and, you know, folks have been around this group longer, understand that with, you know, greater depth than I do. But, yeah, when you're task asking an operator to open up multicast, I think it's very different now with SSM. So there might be things in there that, you know, I'm overcomplicating. But, yeah, if it is transitive and it can go across, ASs, I think that's better. But I'm not sure what are the susceptible what are what are the potential risks or perceived risks even where there may need to be, like, some education around its safety and deployment?
[01:19:07] Tim Chown: Yeah.
[01:19:08] Jeffrey Zhang: Yeah. Yeah. Let's talk about it more offline. It's I'm very, very happy to see the the the progress here. Yeah.
[01:19:20] Omar El-Sadek: Thank you for for the draft. Well, we've got another question?
[01:19:27] Lenny Giuliano: Tim, you're up.
[01:19:32] Tim Chown: Hi. Tim again. Thank you for the oops. Destroying the microphone. Thank you for the presentation. You said, I think it was the very first slide, you were implying that there's something difficult about inter domain SSM. I mean, it's three or four years ago, we pushed out RFC 8815 that was advocating strongly to use SSM for inter domain multicast rather than ASM. And I assume everything we've talked about in the room today is targeting SSM wherever the mock relay is within the the infrastructure. And I I think what we should be doing in this group, in mboned, is pushing forward anything that things simple. And I really like Max's essentially opportunistic use of multicast through the browser and and MOQ. Looks really, really exciting. I've been quite optimistic from an mboned- dean session for months that something might happen. The problem we have in the R and E network, so maybe this is where the likes of Aircast can help, is content. We still, even with SSM and SSM configured quite widely across the R and E networks, we we just don't have content. We have some one research project that uses it. And other than that, there is just no multicast on our network because we have no content. That's the other issue, the the elephant in the room, so to speak.
[01:20:53] Omar El-Sadek: I am working on open sourcing, and and this wasn't ready for this meeting, but hoping for the next ITF, I'll have this series of drafts for multicast quick using MMTP. But there is a library that I'm giving out to folks right now. And, you know, one of the big things is, you know, to to make it worthwhile if it's if it's in pure AS or, you know, there are risks that if there is content that is valuable, I think that a lot of operators will, you know, weigh that into their math and and accept those risks. So, yeah, big push has been on making applications more natively available. So, yeah, I know there's folks like Aircast are doing great stuff with, AMT and VLC. There's just so many challenges with doing, multicast over the Internet. So I I'd also love to chat more with Sanjay and how you're doing, like, reliability. And, you know, like, there are things like SRT you can put at the transport and then add some layer of reliability. But what we liked about MMT is that, there's a lot IP native. Right? It's not just digital, but allows for a lot more finer management of the media flows. So there's certain things that you can't lose. Like, you can't lose your key frames, so you can add extra forward error correction, or you can only repair those particular frames. But if you if you drop out, say, p frames, which are like the motion within a group of pictures, it's okay if you lose some of those. So our renderer can drop those and just repeat the last frame. So it's a massive undertaking. But if you do have content, you know, you know, we are we're worth advocating for publishers to start using this if you're an operator to make your network available, because it's a well known chicken and egg. There's nowhere to distribute it for the content providers who could, you know, actually provide it. So if you do have a network and you are interested, we'd love to get in touch.
[01:23:36] Tim Chown: Yeah. I mean, it's probably simpler in a way in the R and E networks in that we're not all the NRENs like ourselves are not in competition with each other, and we all highly collaborate with each other. There's one NREN in each country, and we all collaborate intensively on what we do. And that maybe makes it easier to deploy and to make things work. But, again, we have the content. Because we're not commercial. We don't have commercial content. We you know, in the in the old days, you'd look at the content. It would be like NASA feeds and stuff like But
[01:24:04] Omar El-Sadek: So I'm I'm putting together some, like, demo services, pulling things from NASA. You know? But I think even internally, right, and if you're an educational network, whether it's for conferences or, you know, courses or stuff like that, there may be opportunities to enable things. So I think it's a great target. You know? So would love to connect and see how
[01:24:33] Lenny Giuliano: we can Okay. Thank you. Okay. We, unfortunately, we're running low on time. So, Sanjay, if you wanna ask the question very quickly as Max steps up, to the plate.
[01:24:50] Sanjay Mishra: Yeah. No. I was gonna say it's really not a question, but more an observation. Right? I think it's great that we're starting to finally build the community around, multicast and so on and and happy to collaborate with everybody. Right? You know, we are, we do have access to content, content that people actually wanna watch, quite often. So, depending on what constraints are put on it some put on us sometimes, we will be happy to share that with everybody and help us all move forward.
[01:25:22] Omar El-Sadek: Yeah. Let's get your stuff working in the browser.
[01:25:25] Sanjay Mishra: Absolutely. Absolutely, Omar. Very interested in that, and let's definitely check offline.
[01:25:31] Omar El-Sadek: Looking forward to it.
[01:25:35] Max Franke: Alright.
[01:25:36] Lenny Giuliano: Great. And, so, Max, you're last. You have till the end of the meeting till people start working.
[01:25:43] Greg Shepherd: My hand up.
[01:25:44] Lenny Giuliano: Oh, sorry.
[01:25:45] Greg Shepherd: Just one bit. Thank you for the last comment about building the community. I just wanted to highlight we're rebuilding the community that was hope and prayers back twenty plus years ago. And now I think we've got some inertia that's very, very encouraging. I'll point out too that it was twenty three years ago this week. We were in Vienna where we, hosted the, multicast last mile BOF, which became AMT. So, yeah, great to see it's all still moving. Appreciate it.
[01:26:16] Lenny Giuliano: Alright. Yes.
[01:26:17] Max Franke: Okay. So so I'll be quick. One thing before I start because I forgot earlier, If you're at all interested in getting multicast into QUIC and into browser, I highly encourage you to show up at QUIC tomorrow. We will hopefully present at the end, right, Louis and Olivier and Kai and I, and just be there and maybe get in the queue, ask questions, whatever. Just show that there's actually people out here that care about multicast and that actually use multicast as a delivery method today. Okay. So so this, I am too over quick. As I already mentioned a lot of times, this came up when I was implementing the the mock thing. Right? And I was, you know, implementing a mock an AMT relay and an AMT gateway, and I thought, okay. This is using UDP. And then I thought, okay. But with mock, we have reliable multicast traffic. Right? And a lot of different applications might use reliable multicast traffic. So if you lose the the as I already mentioned, in the tunnel, you lose your multicast traffic in the tunnel, you have to retransmit it maybe a thousand times. However often you would have to retransmit it because you need to retransmit it to every client individually if you use multicast quick, right, because it's unicast transmission. But if you have quick in the tunnel, then you can just retransmit it once in the tunnel, and that's it. Right? And in addition to this, which was, again, the the thing I cared about at the moment was that you also get what Sanjay asked about or said about TIS authentication and encryption rights. You can make sure this is encrypted tunnel. You can still send datagrams. You can still send unreliable traffic. You can be maybe better about discovery. Right? You can just do DNS based discovery, say okay. I am gonna hurry here. But for example.com, youexample.com, or you could say Twitch, they have their own AMT relay, you just do start a gateway and connect it to that relay, and you get all the traffic from example.com or Twitch. And you make sure because it's authenticated and this relay is associated through QUIC with the domain from Twitch, so with through TLS and authentication chain, you make you you can pretty much be sure that you will only get multicast traffic that is actually relevant to QUIC through your through your gateway and not some random multicast group that might spam your network. So, yes, there's an implementation that's actually running now. It's the thing I use for for the the demo, which is tunneling. Again, it's empty over quick. And I'm gonna skip all of that, but basically, yes, of course, the performance CPU wise is slightly worse, but you also get a lot of benefits. And the questions I have is, does this make sense? Is there something obvious I'm overlooking? And if it does make sense and there isn't something obvious I'm overlooking, would there be interest from the working group to maybe pursue this a bit further? And there's also a draft. It's not on a data tracker yet, but if there is interest, I could work on it and by the next IT, I'll put it out there and discuss this more in-depth. Alright. Thanks.
[01:29:32] Omar El-Sadek: Omar? Yep. I am interested. So I think I wanna find more about what the framing what do you mean by AMT over quick? And, you know, are you are you encapsulating AMT directly into a No.
[01:29:55] Max Franke: It would be a different tunnel. Right? So sorry. It it it would be basically, you put the multicast packets. You now put in the AMT tunnel. You would put into a quick tunnel that is connecting the gateway and the the relay.
[01:30:08] Omar El-Sadek: Got it. Yeah. I think they're well, they so part of our our our our our kinda last I wouldn't say last mile. Our our in home, to the browser is, you know, you get native multicast TV that has a nay native antenna built into it, but then you wanna watch it on your phone. So part of that isolated web app is converting from native multicast or could be coming in over AMT and converting it into web transport quick. So I have something that's a similar component to this. And where I I think it'd be, interesting is, you know, for us to sit down and think about multicast on the web and what it can be from. You know, I I think that certain things like reliability I I've won a very different approach. So I wanna compare, you know, understand how doing things like retransmission and how that can be done through AMT. I think that's a very interesting idea, or whether that should be done higher up in the stack. And same thing as well for encryption. Those are, I think, some design decisions that we should see.
[01:31:35] Max Franke: Yeah. We can sit down and discuss it. Right? The the nice thing about QUIC, of course, is you can choose individually. You can have one tunnel between a gateway and a relay that is reliable multicast traffic and one tunnel that is unreliable because you would just use datagram frames in one and then stream frames in the other. You can be even selective with saying, Okay, I want this traffic to be retransmitted, and this traffic, I don't want to be retransmitted. It's lost, then it's lost. Right? So, yeah, there's there's all these I think there's quite a lot of things you could do. Right? Like, the design space opens up quite a bit if if you consider this. Yeah.
[01:32:08] Omar El-Sadek: Yeah. It's it's a tricky design space. But if you're aware of the application that's going over it, you know, you're you might be right, and I think that it can be a lot simpler just using this at the transport. But this stuff is hard. Yeah. So thanks for thanks for sharing.
[01:32:34] Max Franke: Alright. Thanks.
[01:32:39] Lenny Giuliano: Any other questions for Max? So overall, to, echo, Greg's point, it it it feels like what we're seeing is all of the parts come together that we were trying to make come together, you know, twenty five years ago. And, maybe we were a little ahead of our time. Maybe they there there just wasn't enough live streaming video on at the time, but, it feels like now is, there's there's definitely, a lot more interest, and it's awesome to see all these pieces come together. And this is this is the purpose of mboned is to bring, folks like this in the room to discover, that peanut butter can be dipped into chocolate, to make a delicious Reese's. So, hopefully, this leads to more more collaboration, and, let's use the mailing list, to help facilitate all that collaboration. If you wanna be part of, any of these, speak up. If you have some interesting components to contribute, whether that be relays that are connected to the you know, one of the r and e networks, and you'd like like to be part of this. If you can help with if you have content, if you have, you know, any any any any ingredients you have to make this pie. I think it's we'd we'd we'd all welcome your contribution. So with that, anything else? Any questions, comments, before we close? Great. Thank you, everybody, and we'll see you in, San Francisco. Hopefully, we'll have even more, more interesting, deployment experiences and updates. Thank you.
[01:34:38] Max Franke: Bye, everyone.
[01:34:41] Greg Shepherd: Bye. Thanks. Thank you, everyone. Have a beer tonight for me, please. Cheers.