 Hey, cloud native Austin. Hey. You're signed in with the wrong thing. Let's see if like zoom is actually working there. Kind of is. Yeah. Yeah, I might. I wish this would let you more easily switch between accounts. That would be nice. You could just rename yourself in this meeting. Yeah, that's a good point. It's cheating. I'm going to see if. Amy, I can message you a couple of things. Or if not try to catch you after the call. Mostly because. I. Shadding through a few thoughts actually will probably explain part of my. Running around with my head cut off. No worries. I know we've got some scheduling stuff coming up for, for you all. And we've got like some basically some projects moving around. It's basically what it looks here. So yeah, happy to catch up. It's okay. Do a little bit of housekeeping here. All right. It's some way more folks to be able to come on in. Yeah. Yeah, that's the, that's the deal. Oh, good. Yeah. And I have curiosity because I can't necessarily see this. Who is presenting the state of seven protocols. We should, we should put that into the dock, but he's about to speak up. Yeah. Hi, John Barry here. Oh, cool. Okay. Yeah. We'll wait for a few more people to come on in and then we'll work it out from there. Perfect. Yeah. You know, we're actually four minutes. So when this is all recorded and I will go ahead and put this up on. I'm the YouTube's afterwards. So Jonathan, take it away. Awesome. Well, this is my first SIG meeting. So thank you for having me and thank you for giving me the opportunity to present on what I've been working on. I have a slide deck. And if we have questions, I am happy to answer questions afterwards. But also during the talk, feel free to stop me if anything comes to mind. So let me, if I can switch to. Screen share. That. Let's try. How does this look? Good. Awesome. Awesome. So, uh, as I mentioned, you know, it's my first time presenting, but I'm actually working on a proposal for the upcoming KubeCon. So this is sort of a good forcing function to, to get ready for that. If it happens. But anyway, the, the, the, the, the, the, the, that is it happens. Um, but anyway, the, this topic is something I've been working on, um, in my spare time. Uh, and it's out of the interest in necessity for my startup that I'm working on. Uh, and it turned out to that it could be useful for the community. So I've been trying to document what I've been learning and getting other folks to get involved and release is about understanding how, um, protocols that are not HTTP. Um, of the ecosystem and how applications and use cases that maybe are slightly not on the happy path could more easily implement what they're trying to do. So some background and some pointers to the doc and some questions at the very end. So a bit about me, I'm a product manager. I worked at companies like Google Nest for a bunch of years and startups and everything in between. The company I'm working on is an IoT startup. We haven't launched yet. And my background is in IoT and protocols and things of that sort. And you can find me afterwards on Twitter. My career handle is Bayer Bear Kicks. I have a boring, lame name, but funny story and it's in and of itself. Bayer Bear Kicks. Yeah, so. I know, I have to interject just to, I've got to hear the story, we've got to. It was a long time ago, I think like eight years ago and we're coming up with Twitter handles. And I kept on doing combinations. There's a very popular Twitter generator at the time and it kept on coming up with Berry Berry, which is a immune deficiency or vitamin deficiency disease. And my co-worker, it was in the morning was eating cereal and he was eating Bayer Bear Kicks cereal. And yeah, it was a group vote. And that's how I got feeling about the Bayer Bear Kicks. Yeah, I wonder, do that's about the only other context in which I've heard, you know, I've seen, yeah, yeah. It also depends on the age of the audience, if they laugh or not in my Twitter handle. Quite telling. But anyway, I mentioned that I'm working on an IoT platform and if you're not really familiar with the space and IoT platform, you know, this fundamentals is trying to have a T a thing that has I internet do something interesting and talk to the cloud. And that cloud infrastructure is doing a lot on behalf of that thing. It's doing the communication between the device and the cloud and the cloud device or device messaging, security, firmware updates, a whole bunch of other stuff. But for the context of networking, we really care about this device messaging component. And part of that is related to IoT protocols. And so IoT protocols or networking protocols, if you're not into the space, you might not know that there are tons of IoT protocols and some might say too many, but they have very specific applications and use cases and different industries where they apply. They're generally designed around the local networking. So device to device communication, device to gateway communication, but many of them are either cloud friendly. So they talk to some backend or have some way to do it or cloud native in the context of they have definitions of how to talk to the cloud. And in part because they're oftentimes IP-based. So it's really natural to integrate that with the cloud backend. And this kind of brings me to what I'm working on. As a platform, we wanna support many protocols over time and we wanna do it in a way that scales. So we don't have to hack different implementations and fake IP or do some protocol marshaling. So to give you sort of how we're thinking about this problem and how we're coming into the cloud native space and why I call it the ecosystem is we're looking at is sort of an iterative approach. So this very first architecture we've built, it looks something like this, right? You have the device again on the left. It's talking over the internet to the cloud that it's using one of these protocols. It's co-app, it's an ITF standard. It's a UDP based protocol. And the interesting part is really our gateway and that speaks co-app on the other end. And within the cluster, it's forwarding basically IP packets around. That's very simplistic. It's really not cloud native at all. This actually runs the exact same way on my local machine as it does on a cluster, as it does in a VM. And this is what I would call not cloud native, right? And our goal is to incrementally add and leverage all the different components of this cloud native ecosystem over time. And the crux of it is around networking. And so as we add more cloud native layers, we look at things like proxies to get observability and marshaling and un-marshalling of, so let's say security context, service to service communication and all the capabilities of something like a service mesh. Because as a platform, we're a single tenant today, single customer oriented, but we wanna be eventually multiple customers running multiple applications in the back end and eventually having those back ends talk to each other, different applications talking to each other and ideally in the native protocol that the device spoke. And there's some benefits there of having native IT protocols from device to the far edge or to the back end, but that's not so important for this context. And then the last part is adding incrementally more capabilities, for example, like serverless. And this is just a frame how I've been thinking about the space and how we've been building to it and kind of how we've got to this survey that we've been working on. It's not an all or nothing binary switch of becoming cloud native, but it's looking at the landscape of what we can leverage to build a new type of IoT platform. Cool. And if you're curious about any of these details, I'll have you to chat more about it later, but for the context of this SIG, we really took that first step would be to augment our gateway with something like Envoy. And it was about a year or so ago when we started looking into this because one part of the gateway is effectively being a front end to figure out how to route those core messages. And so at the time, I raised an issue on Envoy to try to poke at this problem. This is really early thinking and this content is actually in the survey as well because UDP was just being turned on in Alpha on Envoy and within the Envoy project, there were TCP protocols that are also supported, but by and large, HTTP was where a lot of the effort and capabilities were there. And that makes sense. And most of the customers who use Envoy are doing some sort of HTTP traffic and proxying that traffic, excuse me. But my question I was raising to the group was, well, there's all these other use cases. I was just talking about IoT and the different protocols and examples there, but there are other applications where HTTP is not the right networking choice, for example, in gaming or telephony. And so the question I raised was, what would it take or how would we enable people to implement their own protocols, their own L7-like protocols on top of Envoy that weren't HTTP and what would that be like? Does it require just best practices? Is it modifying some of the extensibility? This is before wasm and proxy wasm was available. Is it a spec or what would it take? And that began the rabbit hole of understanding this difference between L7 and HTTP as one category and kind of the bulk of the work that's already been done and everything else. And so I came away with that looking at Envoy and talking to Matt from the project that broadly speaking, the cloud native landscape is really optimized for HTTP and that just makes sense, right? The majority of the workloads that clouds serve are HTTP traffic, web APIs and things like that nature. And as a result though, the projects in that landscape have a lot of assumptions around the traffic being HTTP based and potentially areas where it's harder to implement non-HDP based protocols. And as I started thinking about MySpace and IoT, I found other people who were looking to this exact same problem. So I mentioned gaming earlier, gaming protocol, gaming systems use alternative protocols for game secretization and for game chat and communication and they're also trying to figure out how they could build gaming platforms on top of the cloud native community. So Project Agonis is one project from Google, it's open source, they also have a hosted version and it's for the game servers themselves and Mark over at Google was looking to build a sync server on top of Agonis. Looking into Envoy and we both bumped into each other of trying to run a UDP based protocol and there's really no good solution today. So they have a sample in their GitHub repo and they're not trying to solve it right now. Another use case is telephony and real-time communication and specifically WebRTC comes up a bunch. Pion is actually a set of services, libraries, open source, a project for WebRTC and all the other lower bits that you need. That's actually a really cool project in Go and Sean who's the lead over there has also been thinking about the space a lot. He's actually working on a document after weeks spoke of how to actually do WebRTC load balancing and how that looked like on top of Kubernetes and that's super challenging and we hope to get some use cases out of that. But this made me feel that there's an opportunity to not just try to solve a very specific problem around networking and IoT, but hopefully create best practices and rise the tide for more broadly the community. So, I got... Jonathan, I got distracted for a moment back on the first, it was Argonis. Yeah, yeah. Can you... Could you speak to that one one more time that I got? Yeah, so I'm a far from an expert but it's basically extending Kubernetes, right? It's one of those projects that take the core APIs that are available and I think cost a lot of CRDs to manage the game servers of your game backend. So that's the serving of the game functionality. Now, scale up, scale down and the very specific algorithms that game developers have developed over time of scaling and routing and matchmaking and leveraging that on top of Kubernetes. It's a really cool project. And that's just serving, right? When it comes to the in-app services, so one in particular is game state synchronization. You need to be able to say, or you have two players, you're looking at a virtual world, you want to make sure that the characters are on the same space and the bullets are all flying at the same location, so you build a game sync server and those are pretty complicated to develop and as an industry, they have a couple de facto protocols to synchronize the state of the virtual world. They're largely based off UDP. There's no single one, but they effectively do similar things, serialize the data, synchronize it through some sort of synchronization system and enable game developers to just pull in an API or library to do that. Okay, that makes sense. Yeah, and Google actually now is running this as a managed version as well, again, with just the game serving component solved. Okay. Any other questions? I mean, in Pion, it was the primary use case was focused around WebRTC. Yeah, so it's effectively re-implementing all the WebRTC functions and protocols that are needed to implement a client, a server and even abstractions on top. So the most complete implementation of WebRTC comes from Chromium and so there's basically a rewrite from Go, but some of the harder parts were the protocols that WebRTC uses because WebRTC and it's a collection of specs. It uses a collection of protocols, some for the video streaming, some for the data channels, which is the, you can send, say, text data or other types of data on top of that pipe. It's based off of UDP, it's based off of TCP, it's based off of SCTP, so it's a pretty complicated suite of protocols and Pion has implemented those as standard Go libraries. Interesting. Yeah, yeah. Then when it comes to the sort of routing and load balancing and connections, WebRTC has similar problems and challenges that gaming has, which is similar to some IT use cases. So for example, when you're roaming, the behavior of network traffic, say on your cell phone or your connected scooter running around the Bay Area, jump a player on a mobile phone to a device that might be hopping between different base stations. Those kind of networking challenges are solved at the protocol layer and are very interesting and useful, but also need to be integrated into your network management layer. So for example, if you will want to do congestion control, congestion control for that game server, I would imagine it's finally different than congestion control for the WebRTC. And what I know more about is the congestion control for an IoT device that might be on a cellular link or a satellite link or an Ethernet link, you think about it slightly differently. So is that helpful? Yeah, yeah, it makes sense. Cool, cool. And so this is kind of really just background for this document I've been working on and somehow the screenshot got downresd at least in my view. And that's the link for anyone to go check it out. What I effectively did was starting out with my own IoT use case and looking at that progression from simple ingress of data from the IoT device to the cluster over that IoT protocol, what are the pieces of Kubernetes that exist today that deal with protocols and deals with non-HTB traffic? What's possible today? What's in a cap or something else? And then going through, okay, well, now if I wanna stand up a proxy like Envoy, what parts of Envoy assume HTTP or has already implemented capabilities of HTTP and so on. So the stock is this ongoing survey that I've been developing and it's actually been quite well. I put a week of worth of effort to understand each project is a better degree of detail, but more importantly, I was able to convince some of the project leads and implementers from each one to comment in and validate what I'm saying and add more context and debate and discuss how well each one is solving for. So it took about a week just to kind of cover the basics of Kubernetes and Envoy and service meshes. Then a lot of good feedback came from other folks around, oh, you should look at other aspects like for example, cloud events. How does cloud events think about, transports and protocols? How does the API server think about it? Is there something that they get touched on with that? How does encryption and security assumptions work and et cetera? So this is a living dock. It's still flagged this draft but it's probably a little bit more than draft at this point. And this is the reason why I wanted to share with this group. And just to, if someone doesn't have time to read this or hasn't read it just yet, I just wanna give you a quick example of what kind of analysis I'm doing and others are helping me do and sort of how I'm presenting it. So both the description and the takeaway. So this is the SMI spec. It's a defining standard interface. I'm not gonna read the whole thing. The current focus is HGV, the goals to support more protocols. And so for example, there's this traffic specs and you can add new traffic specs via CRD. So the takeaway for SMI is that it should be able to support alternative protocols as it does already define HB and TCP and provides a traffic spec. As a corollary, there's some other parts that don't have a way to extend in a protocol agnostic way. So my ask for the group is if you're watching it now live or if you're watching it later, please take a look at the dock. I would love comments, feedback, any additional takeaways that I may not have hit on or we haven't hit on yet. Potentially new areas to investigate, to really build out this as a true landscape survey to help everyone who's working on these projects. And I say specifically for the SIG and why I asked to present is, where should I go with the stock? I'm already engaging with the individual projects and getting tons of feedback, but is this helpful for work that's being currently discussed or ideas that are kind of baking within the SIG what's the best way to help enable this to be useful and engage with the SIG? I'm also very new to working with CNCF projects. And if there's any other SIGs that I should be presenting to or sharing this information that might have interest or insights, that's really how can I make this better and more helpful. Yeah, and quick summary, I'm working on a cloud native IT infrastructure, largely I'm noticing that cloud native is a soft and nice way to be. Sometimes alternative protocols are hard to implement and there's a lot of different use cases from other folks beyond IoT that might be interested in this. And my goal is to really make it possible or at least easier to support new protocols. Oh, and these slides are available if you're interested and don't think, thank you. And questions. Thanks for the Jonathan. Actually, this is your, I would say on a good path to engaging well, for the kind of our first time coming over to share, this is good. I share a link to the doc in the chat for those that couldn't read the URL as quickly as that. Oh yeah, I try to make a custom slug. It's alt-l7-signet. A couple random thoughts, like actually the example with respect to SMI supporting additional traffic, it's a timely discussion as there's an active, there's an active discussion happening on support for UDP. Cool. And yeah, the more service messages that participate there, the more each of them bring a little bit of a diverse use case for additional protocol support as an example. Speaking of that, maybe I'll poke it at Ed for a moment and say Ed of, with your NSM hat on. Do you, well, I get, well, here, I'm gonna maybe try to ask two questions at once and that's that Jonathan of some of the protocols that you look at, have any of those been multicast use cases for things like, you know, trying to get the right, maybe. All right, okay. Yeah. Oh, please go ahead. Yeah, I think basically what we is trying to sort of set up as a softball pitch for me, which is appreciated, is that effectively when you talk about this stuff, if you have things that want to think, live life at alt-l7 and think of alt-l7, right, by all means, you should absolutely be going and figuring out how to get additional stuff into Envoy and that kind of stuff. But if you have things that literally have problems living that at alt-3, like multicast, you should probably come and take a look at what network service mesh may be able to offer you, because multicast is a super weird beast and not only is it a super weird beast, but it tends to be very domain isolated. I mean, if you ever really, really want to get a room laughing, go to an analog meeting and suggest, you know, the implementation of multi-service provider, multicast, they will either beat you senseless or laugh you off the stage, maybe both. And so, you know, if you have things, and or if you have things that are more easily solvable down at that layer, then they may be at alt-l7. You know, but if you're looking for alt-l7 intelligence, you're absolutely looking in the right place. But if you actually have needs that live lower down in the stack than that, there are also answers coming through you. Yeah, thanks for the context. The NSM was actually pretty new to me. I just learned about it last week, so I'm excited to dig in further. Awesome. And I think that, to at least earlier question, yes, there's definitely protocols that are multicast, both on the RTC side as well as in the IoT side. And in my experience, in working at, for example, a Nest, we used IPv6 multicast heavily, but only on the local network. And that's largely because you can't really go, you know, can't do IPv6 in most cloud providers and you couldn't do multicast across from local to cloud. This is where actually network service mesh gives you an interesting out, because the way network service mesh thinks about the world is to say that we will allow you to connect to whatever kind of network service you want. So at the granularity of a workload. So if you have a workload that connects to a network service and that network service itself supports multicast, even if that network service has workloads from all over the world, if that network service is supporting multicast, then you can do multicast between those workloads wherever they may be. And part of the reason this becomes tractable is the reason that you don't get multicast across the broader internet is because the nature of the way that the routing state for multicast works just blows the doors off of one single global network, it's just, it's not going to work. But if you're operating on the scale of an application that has workloads in different places, that if you were to put them all into a single data center, multicast would be reasonable, then you can make multicast reasonable for a network service that is servicing those workloads wherever they may be. Does that make sense? Yes, it does. And so like that opens up some interesting doors in terms of how you might want to handle that stuff. But yeah, I mean, that's interesting possibility because you're not the only people who abuse multicast locally, not at all. Used, I wouldn't go so far as abused. Well, I mean, and the other thing is you can do, I don't know if you're familiar with beer, not the beverage. Okay, yeah, I know. Not the tasty beverage. No, so like this is an attempt by some of the, to make multicast more scalable. Not scalable, I mean, if the internet providers are ever going to go on board, but more scalable than things like PIM, for example, and some of its relatives, which scale very poorly. I actually, I have scars. I cut my teeth very early in my career, trying to do large-scale testing of multicast, and oh my God. So, yeah, so anyway, like we would love to chat with you. Go ahead and feel free to pick me. I'm on the CNCS Slack. We've got other people from that community here, like Nikolai, who are on the CNCS Slack. Great, great, great, great. There's a Pound.SN channel and a Pound.SN dev, and we've got weekly meetings and all the usual things. Cool. This sounds like a great way to extend this. When it comes to, you know, multicast is obviously a very complicated and not a lead problem. Oh yeah. There's other parts that are probably simpler when it comes to going beyond L7, right? Because most of these protocols live somewhere between kind of like a hub around L4, and you know, use and abuse parts of L4. And you know, one of the areas, just again, going back to IoT, is around, you know, congestion control, DDoS mitigation, all these other things that are not handled by the L7 protocol. So there's probably some opportunity to also leverage and learn from how you guys are thinking about this problem. Yeah, absolutely. And like I said, we're very much a complement to traditional application service mesh. Like if you need to understand higher layers, we're not gonna do that for you. Lots of people do that really, really intelligently at this point. But if your problem can be solved at lower layers, then man, we got solutions for you. Yeah, and my gut is, especially just kind of thinking about different implementations of these L7 protocols, is there'll be a percentage of protocols that have to live in both worlds, right? There'll be have to be something around, for example, operators, how they think about their TCP, UDP traffic and leverage some of the service mesh stuff at that layer, as well as implement the high level protocol with the assumption that the network service mesh is available. Yeah, and like one of the things that we've actually looked at in network service mesh, we had to talk at NSM about it, is taking a traditional application service mesh and running on top of a network service. So that you can get the particular kind of behavior that you need for your workloads over that. So for example, if you're deploying into a cluster that has already got a service mesh for the cluster, and it's not a service mesh that's going to support the magical things that you want, you would have a network, a network service that workloads, not only from that cluster, but other clusters could connect to, that does have a service mesh that is smart about the kinds of service mesh you need for IoT or gaming or whatever. Because one of the things you're gonna do, it's sort of the, we have this thing we talk about where we talk about don't weld the connectivity domain to the runtime domain. And it's because the things that are doing stuff in your runtime domain, whether that's a Kubernetes cluster or a data center network, they've got a wild variety of needs. And trying to get one connectivity domain to service all of those needs, you can make it work for very common denominator needs. And the Kubernetes community's done that very well. But if you've got niche needs, the probability that you're going to convince your runtime to meet your niche needs without adversely impacting other people, lower. And even if it won't adversely impact them, there's a lot of discussion and work and blah, blah, blah, administratively to make it happen. Yeah, I mean, pre-orchestration and containers, the majority of architectures for IoT were literally separate domains and separate teams, right? You have your device front end suite of services that handle device communication and device management, talks over some sort of, to second effectively cluster, but set of services managed by a different team. So that makes sense, it's where you want to combine them, but also let the people who focus on that part of the problem space have their own. One of the things that's actually super interesting that we're figuring out is, it turns out that one of the major advantages we have is actually has to do with administrative domains, not connectivity domains. In that, if you think about the world as a single administrative domain, possibly so divided on a hierarchy tree, that works great if you're in a single organization. But the minute you're not where you've got two hierarchy trees and administrative control, that's where almost everything breaks down. And we're actually designing for that scenario. I think of a lot of the other use cases where it's not maybe multiple organizations, but some sort of compliance sensitive network versus non-compliance sensitive network. Right, right. Because nobody wants to have the workloads running in their system that require them to have 15 layers of compliance checks. That's annoying, right? But if the compliance checks associate to the connectivity, then make them associate to the connectivity. Yes, and just another use case to throw out there, when it comes to carrier integrations, I threw a slide about that. A lot of times if you have a deep partnership with a carrier, you actually deploy an application in your environment that talks directly to their network. And that has special requirements, very complicated network, routing logic, and, yeah, so that may be your code. No, absolutely. We've had carriers give talks at NSMCon. So there's definitely some interest there. There have been musings about how you could use network service mesh because it's sort of very simple as an underlying architecture to say, okay, I actually want to ask my carrier to put something to connect this workload to that particular magic networking treatment for my carrier, right? Just this workload, not my entire flipping data center, because God knows. And without having to like figure out which IP should be getting this special treatment game, which always makes everyone miserable. Yep, awesome, awesome. I definitely got to dig into network service mesh and come to you next time. Yeah, let me know. If it helps you, I'm happy. And otherwise, also good. Cool, any other questions, feedback? Hey, look at that. I only talked on mute for less than eight seconds. So that's, if you're unaware, there's some implicit like measurement of your own narcissism. You know, my perspective is if you go for over 30 seconds talking to yourself, it's you're probably a narcissist. So I'm all right today. I in part was doing what Ed was saying, which is sort of poking at Ed poking at kind of my point of my area, an area of interest for me around multicast. Given that Matt is here as well and just in context of it, let me ask an ignorant question kind of in context of IoT and embedded devices. Matt, the mobile library, sort of the Envoy's mobile library or the mobile edition of Envoy, if I could characterize it like that, is there a, Jonathan, is there like a tie-in here in terms of part of that? Probably not, just because most of the IoT devices are running on microprocessors and operating systems and constrained environments that it can't run Envoy. Now, over time, you know, for smart devices that are running Linux and are running application processors and like MCUs that actually I am and can run Envoy, I think it's possible. Or a lot of the IoT devices, you know, that are deployed today, it's not really an option. Like most of those devices, they don't have heaps, right? I mean, it's like they're very constrained. So they can't use HTTP2, they can't use GRPC, like they're typically using very basic text protocols like or, you know, maybe basic binary ones or something like what, or, you know, different messaging protocols, but it tends to be really simple environments. So like possibly in the future, I think there are cases where for more expensive, more complicated IoT devices, it will apply, but not all cases. Again, it's sort of interesting because there's this, you know, mobile devices and Envoy mobile is very specific, right? But there's these cases of where there is a capable device. And so in the industrial context, they usually have an industrial controller that's running Linux. It's probably running Java, so it's got heaps of RAM or in more recent non-industrial use cases. I'll explain this. So major retailer, they have refrigerators all along their facility and they have IoT sensors on them. So measure the temperature to make sure it's still operation correctly. And they have a mini cluster on-prem. It's like a single rack type of thing. And that also connects to the radio technology so they can sense all the devices and collect that data locally and then push it off back to their main host solution. So that's also like an IoT gateway, but it's actually capable of running full-fledged Kubernetes Envoy. So the interesting, where would that line live? Will the use cases that make sense to have a gateway-like device, will they actually just be running more traditional Envoy Kubernetes deployment? Or will it actually be even more constrained because of deployability, cost, whatever? But surely the end-to-end IP, there's a lot of value in having it at Envoy at that sort of cloud side and being aware of the protocol, being able to do telemetry and observability and whatnot may come out of it. And just kind of like to bring it home. The device drives the requirements to the cloud. That's sort of one of the things I've learned in my career. So if an IoT device has a very constrained requirements of what you can communicate, how you can communicate, well, you can't really change the constraints of a scooter driving around the city, but you can, for example, implement protocols on the cloud side to match to the device side requirements. Yeah, interesting. Yeah, I guess it hadn't occurred to me until just a moment ago that I've been speaking with a very large manufacturer of, well, geez, the parking meters and a bunch of other style IoT devices or the various styles of those types of meters for airports, parking lots and the like. And much of our conversation was about their potential use of a service mesh. I think that they were considering Istio in this case and what it could really do for them or how it could improve some of their use cases. Yeah, the other interesting bit about specifically IoT is that there's not necessarily one type of network, a network transport, right? Probably in the sensor use case, they have some sort of local sensor communication, some wireless protocol, and it connects eventually to some point to some aggregator. And that aggregator might translate that protocol into an IP-based protocol or it might be an IP-based protocol already, so it's really just shuffling it. But the network that's managing the local communication might not be an IP-based network. So it might not have IP-based traffic routing and network management, but it could be. So if you're a carrier, like we were talking about earlier, you actually might be managing your own IP network. And therefore, things like network service mesh make a ton of sense because all your tower-to-tower communication and device-to-tower communications your own managed network. One other quick thing, you mentioned non-IP networks and that sort of got me, that raised my ears again because there's a thing we don't talk about a network service mesh very much because most people only care about IP. But we are actually payload agnostic in the sense that if you have any kind of a payload that can be broken up into frames of any sort. And you have something that you are willing to stick it onto for transport. If it's moving remotely, we will do that for you. So for example, in addition to IP, we also support Ethernet. So if you come in as an Ethernet frame, not because I think this is a good idea, mind you, I think most of the time the cloud needs Ethernet like it needs a hole in the head. But there are a small number of pathological use cases where it actually is the thing you need. Now, and one of the reasons we kept that agnostic was specifically because even though we don't know enough about IoT to actually know what to do, we did know that IoT had a bunch of what we call exotic network protocols. And so what you're doing is just streaming a serial line where you don't have framing, that I probably can't help you with, right? But if what you have is some frame-based L2 protocol that was invented in the 1970s and you want to go drop that into some kind of appropriate transport and send it on its way, that we can do for you in space. Yeah, some of the extremely low bandwidth protocols, like you might start seeing in lower to satellite communication, but they're not IP based because they don't have the bandwidth for an IP, even a compressed IP header, but they are trying to map the protocol to create a framing protocol on top of it. So once it actually gets to a collector or an aggregator, it can do that translation pretty fast. Yeah, and by framing, what all I mean by framing literally is it doesn't even have to have a framing header. It's just, I can't stream it. I can't do this for an infinitely, a potentially infinitely long thing. I can only do this for something that is going to have a defined length. That's really what I mean by framing. It doesn't even have to have a header for all I care. Then that's more aligned with some of these more exotic protocols that are not IP based, they're dealing with the... Again, mirror may not solve your problem, but we at least try to leave space for it. Yeah, no, that opens up space for sure. Very good. Thank you, Jonathan. Thank you. Yeah, yeah, fantastic. All right, other points of business? Well, yeah, I think you muted yourself again. I don't know how you did it. Was I speaking while muted? You were doing that again, try it again. Wow. All right, good. So, yeah, I'll share the meeting minutes down here briefly, both to, yeah, to two. So next up was a, so sorry, geez, I'm a bit all over the place. Thank you, Jonathan. We'll go ahead and maybe do a couple of things. You'd ask like, hey, sort of, anybody have any feedback, any questions? We've had some good discussion. Are there other suggested next steps? And can this be useful to others beyond how it's been useful to some today? It looks like you've gotten some fairly decent engagement in the document that, you know, in the capturing of the state of those protocols with respect to various cloud native projects. Maybe there's further discussion or other suggestions from folks on the call about that. I think my, the first one that I would suggest is that, that there's a presentations folder within the SIG network repo that can provide some posterity to today's presentation and as a point of interest to those that are, you know, those that might come along later and are interested. Yeah, and I guess maybe I would say, you know, in lieu of anyone else suggesting something else is maybe Jonathan, to do what you can to stick around, you might find opportunity to advance part of that effort in context of this SIG. Right now, are you having trouble getting people to respond or different representatives of those projects to review the doc or to? Actually not. It's been surprisingly amazing. Just I posted when the appropriate Slack group or maybe on Twitter if they're not active there and they just pop right in, add some comments, some project maintainers of competing projects who are having a little discussions, which is also fun. But yeah, I've been getting really good engagement so far. Nice, okay. I mean, one of the questions is, you know, are there other SIGs and sounds like, you know, immediately the network service measures is definitely one of those areas where I need to go deeper in. Yeah. Okay, the other topic that we've had for today was well, actually before we get to that, just with Nicolai here, I'll say kudos on your recent switch of role. So, and timely in terms of it being a topic that we will be discussing further. I bring this up to say, congrats on the role change. Also to hint toward the notion that we're working on schedules now for trying to assign a slot for review of Kuma, presentation of Kuma and review. Thank you. And then, I suppose you already know this, Nicolai, but I mean, Ed had poked me on the side earlier just saying that he was relieved that, you know, to finally be rid of you. And so, just, okay, good. Good, everyone knows I'm joking. Okay, the other topic here was a proposal around a sub-working group, one focused on performance management in context of service meshes. So, I'll bring up a couple of slides to maybe introduce the topics and things that we think would be addressed within there. Actually, on this, I'll ask Matt, do we, the working group for the Universal Data Plane API, that's an ongoing, active, I think? I mean, yes and no, there's not too much activity right now. So, I think there are aspirational goals. I think in practice, most of that work is probably gonna happen, you know, iteratively in the context of the Envoy API. Okay, okay, got it. All right, well, that helps. Of the things to potentially work on in here are, is really something of acknowledgement that there's a couple of service mesh abstractions that have come forth because there are, we currently live in a world of many meshes. And so, SMI was the topic we were just talking on was a project to help standardize an interface for service meshes running on Kubernetes. Recently, well, about a year ago, Hamlet had emerged as a specification for helping federate service catalogs across service meshes. Here in the last month, Hamlet was presented in SMI's regular meetings to explore the emerging of those two abstractions. For my part, I don't think that that will happen based on a number of things and in part the response from the group there. There's another specification that's been worked on by a few different groups. And it's part of what I'm hoping this service mesh performance working group can focus on in advance. Maybe you legitimize. And it's a service mesh performance specification. So it's a format for describing and capturing service mesh performance of the, so that as a topic and a few other topics to chew through in that working group is a few things. So there've been ongoing conversations with the working group, the performance and scalability working group leads of Istio for some time about how to capture, how to describe an environment, how to describe a performance test, the configuration of a service mesh and how to capture those results. And as such, we've been collaborating on what's essentially referred to as the service mesh performance specification and iterating on early versions. We'd like to bring that into discussion within this working group to give it more air. There are a couple of, there's some older initiatives that have yet to be completed, things like really a vendor neutral study of performance, service mesh performance, data plane and control plane under a variety of configurations and to be done using the CNCF labs. And there was an approval to use that lab some time ago. There's been some recent interest in completing that research. And that's in part why the University of Texas and the University of Chicago or University of Texas, Austin rather, and Chicago, there's some post docs and some pre docs involved in some research here. Some of their research is fairly hardware centric and others of their research is just, one of them has just gotten done doing performance benchmarking on search engines. To fund it under a Google initiative. Anyway, lots of folks coming together from different projects. It would be nice to do that in this working group. Also, GSOC just landed and some projects were announced. One of those is hopefully in collaboration with the Envoy Nighthawk team on bringing forth distributed performance testing. I actually consider that it's kind of an interesting thing that we live in a distributed world today or there are more and more workloads being designed in that way. And yet, at least of things that I've seen and maybe I'm ignorant here and that is not a lot around it, distributed performance testing. And so that's sort of the point of that particular GSOC project is to help enable Nighthawk to be, to run many instances of Nighthawk, have them be cognizant of one another and generate load from various vectors against various endpoints, coalesce that performance information. Lastly, another thing to potentially be discussed within that working group is the notion that service mesh performance specification comes forth that each of the service mesh projects that I've spoken to save for Kuma actually, Nikolai. But when I'd spoken with, boy, I forget. Conko. Marco. Yeah, Marco a couple of times now, he didn't necessarily, and it's okay, it's fine. I'm just giving context since you're here. I think he was the only one that maybe didn't bite but the rest of the service mesh is that you could prattle off your tongue we're really interested in. Sort of once this specification is formed, it's sort of running that, each of them consistently running some of the same tests such that there's becomes something of a, maybe a mesh mark. I mean, there's a few ideas in here that this group and these folks that have been collaborating for a while have been stewing on. And that's just the ability to provide, in this particular case for a mesh mark, like that's the ability to, not the ability, but rather a gauge and a scale for identifying the score, the performance score of a given service mesh deployment, considering all of its variables of which there are many between the meshes config, the meshes version, all of what it's doing, all of what's being asked for it which is really the value that it's providing and being able to enable people with an easily understood gauge that could help them weigh the value that they're getting out of their mesh versus the overhead or the performance that it's providing. Sort of the cost of the mesh versus the value of it. And there's some kind of prior art in this context if folks are, and I don't know that many would be, but if people are familiar with app decks from the days of old, yes. There's a simple formula for calculating the, basically the performance of an application, sort of universally. This is probably a lesser known application performance index. We were part of what that group was thinking is that there might be a service mesh performance index, a mesh decks or a mesh mark. And so anyway, I'm just saying, these are kind of topics and things that to explore with a networking group and kind of that's the reason why we were proposing that there would be one. The comments on those initiatives, not really about white papering things here but rather some of the artifacts to be produced. It may include publication of a benchmark, a one-time analysis, potentially publication of something of a specification for uniformly capturing and measuring those environments. Potentially an easy gauge and easy zero to 100 number that you would use to identify the performance of, like I said, kind of the performance of the mesh in context of the value it's providing. And yeah, so yeah, so we figured the reason that I was bringing this forth right now is because both GSOC and Community Bridge are landing in terms of the selection of some of their projects and some of those projects are very relevant. So when you say service mesh performance, how much of this is actually measuring the performance of the proxy itself? I mean, in the end, isn't it just going to be an envoy versus everything else that exists out there in the other meshes? In this case, the spec allows for that, but what the spec also captures is what the control plane is, maybe what functionality is enabled in the control plane. So I think, like as you were to run two tests and contrast them, if the only variable that has changed between those environment configurations is your data plane, in that sense, it could be a comparison between proxies, but doesn't necessarily need to be, if you leave the same proxy config in the same type of proxy across tests, then maybe the thing that you're measuring is just, maybe it's the control plane, maybe it's how much has distributed tracing costing me or rather is sampling at 100%, even though I think I really need that, is it worth it to me given the performance overhead and it may well be, but it's to help people, given that there are so many variables in understanding the overhead of what a mesh, the overhead of a mesh, people get lost in. I think a lot of times people will, not I think, like I've seen it any number of times, people will take a gasp at just how much overhead they're seeing from a mesh, not realizing that all of the value that they're getting out of it, that if they were getting logging or tracing or observability or MTLS or traffic routing and things, if they were getting all of those things from a variety of different implementations and tools in the past, they couldn't really simply measure the overhead of all of that, the value that that infrastructure was providing, they can now. The other thing I might suggest, because it's very analogous to a problem that's near and dear to my heart is, the first pass is, as you said, cost versus value. But the second pass you might want to consider is compared to what? Meaning that a lot of what they're doing now is invisible to them because it's scattered. And so they can't see that. And the reason this comes to mind is it's analogous to something that I deal with, with the VPP data plane for normal networking kinds of stuff, where people look at it and say, yeah, if I run VPP, it's gonna burn two core. And what they're gonna realize is that the kernel is burning five core to do the same amount of work with less throughput. Because the kernels of use of resources is invisible, but the VPP's resources are highly visible to them. And so being able to figure out a way to capture some of that for comparison, because it may also turn out to be the case that in many cases they're like, oh, the service method is costing the X, but it's costing them half X, basically costing them two X to do it the way they're doing it now. And so it's actually a net gain, independent of the initial value. That's fantastic, that's a great point, Ed. Fair enough, we're kind of at top of our, any other comments on this? Very good. We've only made people one minute late, potentially two to their next meeting. Thank you. So I think, Jonathan, for you, we've got the links to the doc and the slides. So we'll look to get those up in the CIG repo. Very good. Thanks, everybody, for coming today. We'll see you in a couple of weeks. Thank you. Thank you. Bye, guys. Cheers.