On this page On this page
Episode 8 – Fuchsia's Netstack3 with Bruno Dal Bo Silva.
In this episode our guest is Bruno Dal Bo Silva, Staff Software Engineer at Google. We will dive into his path into networking and Rust, and the story behind netstack3, the Rust-based networking stack built for Google’s Fuchsia operating system. We cover its origins from the Go-based netstack, why Rust was chosen, and the challenges of implementing a full range of protocols — from TCP and UDP with their POSIX socket API to the many less-visible but essential pieces like ARP, ICMP, IPv6, DHCP, and more. We hope you brought a bowl as you're in or a juicy letter soup with this one. Bruno also shares insights on where he sees the future of netstack3 — including its potential beyond Google.
If you like this podcast you might also like our modular network framework in Rust: https://ramaproxy.org
00:00 00:42 04:37 06:56 10:08 17:35 24:45 28:00 34:41 40:52 46:53 55:22 01:00:36 01:04:50 01:06:25 01:11:37 01:15:32
Music for this episode was composed by Dj Mailbox. Listen to his music at https://on.soundcloud.com/4MRyPSNj8FZoVGpytj
Elizabeth (Plabayo)
0:15 | 🔗
This is netstack.fm, your weekly podcast about networking, Rust, and everything in between. You are listening to episode eight, recorded on the 2nd of October, 2025, where Glen has a conversation with Bruno Dal Bo Silva, Staff Software Engineer at Google, where he works on NetStack 3 and Fuchsia Welcome this week in another episode of netstack.fm. This week we will talk with Bruno. He is working for Google at Netstack 3, which despite the similar name of our podcast has nothing to do with us. However, today we will learn all about it. Welcome Bruno. Thank you for having me. Yeah, it's nice to meet you. Yes, so before we get into the technicalities, I would like to get to know you bit better as I don't know you yet. So could you tell a bit more about your origin story and why you are here where you are now? Sure. All right. So I'm originally from Brazil. So certain part of Brazil, place called Porto Alegre. And so let's start with just how I got into computers and programming. Both my parents were in IT as like not programmers, but in IT generally. So like I had some contact with it until one important day where I found my cousin who had a little software house programming. Like I asked my father, what is he doing? ⁓ he's coding. ⁓ and so I want to do that. And that was the beginning of it. it started with visual basic books and then quickly into like a PHP and then flash courses and books. And then I got into C plus plus systems programming, then went to school. and for some hubris of a 17 year old, I decided to study electronic engineering at school because I felt like I already knew how to program. sheer hubris. I tried to undo that mistake with the masters later on in life, but I ended up dropping out. And yeah, so I did a quick stint in Northern France as part of schooling, which was, you know, I guess, ⁓ interesting and studied a lot of different things in France. And that's when I when I started to look for jobs. I realized that knowing how to code was the thing that was getting me job offers and not all of the engineering studies. So then, you know, found, went back from France to Brazil and an acquaintance that I met there, he had come back to, and he was running a firmware team at a small shop. So I started with firmware, just Cortex, M3 embedded, and I was doing poor quality measurements, a lot of DSP. I loved doing digital signal processing. It was so much fun. And, you know, switching jobs here and there, did a stint at HP. I was doing a lot of mobile development, a little bit of web. But then at HP was when I started connectivity related work with Bluetooth. And that was fun. That was like reading RFCs, coding up the thing. was doing a little bit of firmware then to just writing up Bluetooth protocols and whatnot. And but not really networking per se, just connectivity, you know? And from there, you know, job offer at Google, I remember during the interview, the guy asked, oh, you know, actually run a Bluetooth and a networking team. Do you want to keep doing Bluetooth? I'm like, nah, I'm all done. I want to try something new. And I was just really looking to do something different. And that's when I joined Google and Fuchsia, right, as part of the networking stack team. ⁓ so that's been the past seven years there and I had very little exposure to actual networking by then, ⁓ it's as opposed, you know, except for I could configure a home router. knew roughly what the DHCP was TCP UDP, but that's it. And similarly for Rust by the way, I was doing mostly C/C++ and some like Java mobile app developer for most of my career. And fuchsia was invested heavily into Rust And so like, that's what I did. And I learned and I, I absolutely fell in love with it, to be honest. so expressive and, you know, that's how I ended up here, you know, and joined, ⁓ it's straight into the future team. I've been there for seven years. Well, that's a heck of a story. Thank you very much for sharing that. Now, before we go further with Fuchsia which I do want to dive into, like, as you mentioned, you had like a background in more traditional engineering. Do you feel like it helped you in any way in the rest of your career? Mm-hmm. That is a great question. I ended up in engineering because I really liked studying math at school. So it helped me early on in my DSP ventures, right? Because there's like, it's very math heavy. I had a little detour into AR at my time at HP and so augmented reality and so like the math helped there too with computer vision. But not really, I think like just... If I had to say mostly the logical thinking that comes from the engineering thing and just liking to tinker is what helps me today. A part of me regrets not studying computer science formally. Life taught me what I needed to learn about those things. I love reading about it and that's the part of me that regrets going to W.E. understand but at the same time I often feel that it might be easier to learn computer science on your own especially if you have good peers at a company like Google compared to learning something like digital signal processing and I don't know electronic routing and all that stuff which I imagine might be easier to learn in school That's fair. That is very, very fair. Yeah. I have a lot of my peers at Google to thank you just like really bringing me up to speed on a lot of things. It's an amazing company and like I have amazing peers and like the people who taught me Rust are all still there and I'm thankful for that too. Yes, and then you also after that did a lot of work on Bluetooth as well as before that digital signal processing. I mean, in a way it is kind of related to networking as you are still dealing with communication, you are dealing with encoding, decoding, you are dealing with protocols. I suppose that experience it helped you a lot getting quite quickly to speak with the networking team at Fuchsia. It is definitely relatable, ⁓ I find. The underlying theme, think, for all my career has been systems programming. And I see networking as the level of networking which I work on is like it's a big branch of systems programming for sure. Yes and the kind of networking you do is the kind of networking I love as well. So let's go for it. Now most folks might know Fuchsia or maybe not, I am not really certain. So could you perhaps introduce Fuchsia as well as how did it get started and how did they come up picking Rust? Right, so I'm not the best Fuchsia historian because it predates me, but so Fuchsia is a modern operating system that aims to be like simple, secure, updatable and performant. That's the goal. It's a general purpose operating system. Okay. And it's open source. You can go look at all the documentation that we have at fuchsia.dev. ⁓ For a little bit more in-depth vision on the technicals there, Fuchsia is built on a microkernel architecture. The kernel is called Zircon and pretty much everything runs in user space. That includes, our conversation, the network stack itself, the network drivers, it's all in user space. And in very early Fuchsia, we needed a network stack. That was before my time. There was an attempt at a network stack with LWIP. It was somewhat short-lived, like it served the purpose at the time, as I understand. And then there was this push to go into what we call netstack2 now that is based on the gVisor stack. So like gVisor is a big project at Google to that. intercepts this is called with the layer with containers, right? And we're all, you know, siblings at the company. We reached out and we pulled in the GVisor TCP IP package, they call it. So like basically the IP stack implementation and put Fuchsia bindings around it. GVisor is written in Go. So that also meant at the time that Fuchsia had a Go fork so that Fuchsia was an available target for the Go runtime, right? And over time, at the time other systems ⁓ in Fuchsia were using Go, right? But over time, we just learned that like at this level, the garbage collector and the runtime costs are just too high, right? GVisor was fantastic for us. It still serves a great purpose. The TCP implementation is very mature. We were missing a couple of things and we actually worked with the GVisor team to add the things that we were missing at the time. It was very fruitful. But ultimately, other systems within Fuchsia have moved away from from the Go runtime, and the NetStack was there. Around the time I joined, NetStack 3 was starting to be talked about. ⁓ we want, it would be great to have a network stack in Rust. We will stop paying the goal runtime costs and you'll be able to build something that like we can iterate fast on for a fuchsia. And you know, the bugs are like, you know, seven years later, we're still working on it. You know, most, most targets on fuchsia today are using next step three. haven't managed. to move everything off of stack too. It is happening. And part of it, you don't want to maintain two things. You want to be able to focus on one thing, but partly that stack three is proving fruitful in the things that we wanted it ⁓ to be good, which is fast iteration, be able to go deep in fusion necessities for the stack. And the memory footprint is massively lower because you're not paying runtime costs. You have deterministic memory. You know, you're not dealing with the GC. like it's paying off. Wow, okay, thank you. There is so much to unpack there, so I'm gonna go at it bit by bit. Now, you mentioned, okay, it comes from Hypervisor, NETSTACK 2. Like, I didn't know NETSTACK 2 and I was gonna ask you about it, so I'm very glad you mentioned it. I did know about NETSTACK 1 or just NETSTACK. Did everybody that was on NETSTACK just move to NETSTACK 2 or were these two systems living next to each other? I don't know. This was before my time. I joined when netstack 2 was already pretty mature and in place. netstack 1 was a memory at the time. Okay. Okay, fair enough. Okay, and then as you mentioned a bit about footprint and I don't want to go too deep into it, but I do find an interesting topic which does not get mentioned enough in the Rust community. Like, do you do anything specifically around allocations? Like do you use arena allocators, other kinds of custom allocators, or is it just purely the Rust allocation like what it provides you like allocating a Vec and whatever? That- That's a great question. Not currently. You could look at our code. We're not doing anything that is very fancy there. It's basically just using the allocators that we get from the system. We run in user space, so we just get a heap, right? Most of the wing here is just really... The Go runtime is big, right? And so it itself carries a lot of it with... the scheduler with the memory module and everything. So a lot of our wins are there, but a lot of our wins are also in terms of like deterministic memory management, right? Because the Go runtime has its own heuristics and you can tune them, but to a point, right? In building AppStack 3, we really wanted to be accountable for all of the memory. Right. And so we have like fine control over it. I have really good control of over what is the memory allocated for TCP buffers, for device buffers, for neighbor tables, routing tables, all of that. So it's really easy to account for and either optimize if needed, or at the very least just get rid of them. When I, you know, ⁓ with RAII, I'm just going to drop the thing and the memory should be good. Yes, exactly. Very cool. And then you mentioned Fuchsia is a microkernel. I love that kind of system. I think it's the future. Of course, it's difficult to move away from all the monolithic ones. I suppose that means that compared to something like Linux, you have relatively few updates required to the kernel itself, because if you look at the Linux development, they are releasing updates very frequently. the kernel itself because a lot of it is contained within the kernel but for you guys I suppose you don't have to touch the core of it which is the kernel space to often or am I wrong? That's correct. I've been there for a while. I've touched many components in the system. I read the kernel source often. I don't think I ever published ⁓ a change request for it ever. ⁓ But yeah, it's part of the core of fuchsia updateability, right? And having your system more fragmented in that sense with stable API boundaries and ABI boundaries is part of the updateability story. Okay. Yes. Okay, and I was only impression, but I don't know too much about Fujiya, so do correct me, that it was mostly for embedded systems. Or is that not correct? What is the aim? Like what are you mostly aiming to use Fuchsia and It is a general purpose operating system and it's growing and we're adding what we need to be a general purpose operating system. ⁓ Okay, would it one day like be used to replace Android or is it like a whole different kind of story? Yeah, okay, that's fair enough. And then way before I knew about Fuchsia, I did know about Redux, which is like another operating system written in Rust and I have contributed to it a bit in the past, very minor things. Have you looked at that kind of code? You were in the team and what do you think about that system? Mm-hmm. I'm not super familiar with that, right? I am excited that so many people are trying toy OSS's these days. ⁓ it's very fun. It is very easy to underestimate how much work it is. I think you can see sprinkles of that in the community, right? ⁓ but yeah. And I think there's a lot of work in the embedded space. There's a little bit. less work in the general purpose operating system space, but there is some, which is the most exciting part because sometimes you got to try to reinvent things to discover interesting things along the way. I really like these tiny OS projects around the Rust community and experimenting with stuff and how can you make a full kernel, for example, with memory safety? It's very, very exciting. But I am a fuchsia native person at heart and I just I spend 90 % of my time on it and I've done very little exploring except for reading blog posts and staring at the code here and there for other things. I understand. And I know like in companies like Apple and I think it used to be in at Microsoft and I'm not sure anymore. It's the same through anymore. But at least in Apple, I think they used to dog feed on their own system. So they would like develop from like their own systems on the edge. Do you in your team also work from Fuchsia like in your as a dev environment or like what I mean is like it is your daily driver to work and I use a computer or not. No, no, not at all. So my flow is more, the fuchsia development environment is tuned to work on Linux, right? And I run fuchsia on an emulator. A lot of the time we have some hardware targets that we experiment with, both ARM and x64 and... You know, that's so I communicate with it. So right now, actually, the big development bridge is ⁓ networking. So like the network stack is really, really in there because most of the development hope and happens over like some sort of TCP or SSH socket. So, you know, part of what is very cool of writing a new stack there, given we're talking about development is that to move targets to netstack3 We had to be good enough to not interfere with the development of anyone that was working on that target. That set a very high bar as replacement in the beginning. It had to be pretty workable. Even if the target was just experimental, you need this for the developers to work on it and continue developing the target. So that was very cool. I can imagine you have a lot of like insider war stories there, but let's not go there. Now when we talked a bit before the podcast about Netstack3 you mentioned hit at like two interesting points. I mean, in general it is interesting, but you mentioned two interesting things, which is one, implementing the protocols themselves for wire compatibility and two, implementing a POSIX compatible API. I would like to dive a bit in the second point first. The POSIX compatible API, it mostly because developers are familiar with it and that's like nicer to work in? Or is there like a technical reason why you need POSIX compatibility there in this new system, which in the end lives on itself? Yeah, that's a great question. So, Fuchsia aims to be POSIX compatible, right? So, like we have, can build a component for Fuchsia and you can like use libc and it's going to look like a POSIX API, right? So, how does this work in Fuchsia? The network stack is not in the kernel, it's a component. So, if you are going to make a socket call, this becomes an IPC call to the network stack process, right? So libc exists and it translates the POSIX calls to what we call FIDL, which is the Fusion Interface Definition Language. So that's our IPC mechanism to the network stack. So the POSIX API is mostly for familiarity. Familiarity is one of the most powerful things you can have when you're introducing a new system if you want to drive adoption. So it really, really helps. And netstack. 3 really aims to be POSIX compatible. all of, and that includes, we tend to think of just the data path, but that includes, so many things and so many behaviors. Think of all the socket options, the Anselera metadata that you can get from a UDP socket. You can get most of the IP layer options when you use RecVMessage, for example. There's a lot of complexity there. And there's some fuchsia-flavored complexity about doing this performantly over an IP C call Okay, and so let's start diving a bit into the protocols, because of course we could start with TCP, but below TCP there are also a lot of important protocols way before you even get to TCP, including also the drivers to talk to the hardware, which I assume you might need to also write or maybe you can port them from existing systems. So let's start perhaps with like a bit of an overview, like what's living in that land. Okay, let's do you want to do life of a packet maybe? Yeah, that sounds very cool. Let's do that. Sure, let's do that and then we can sprinkle protocols along the way. So, life of a packet in Fuchsia looks like you're going to have a driver. That driver is developed for a Fuchsia because the driver ABI is completely different. It's going to be different. So that driver is specified for a Fuchsia. We have an API for a driver to communicate with our stack that involves shared memory. So we reduce data copying and all of that. ⁓ an ingress packet is going to go into that shared memory, the network stack gets notified of however many packets are in the receive queue, and it pops one at a time. So that's going to traverse the stack. You're going to typically have then on the parsing side, you're going to parse the packet. It's probably going to be like Ethernet. You're going to check is this for me, is this not for me? And then you're going to hit, you're going to demux the Ethernet protocols. generally ARP IPv4 or IPv6, right? So ARP is address resolution protocol, which is a thing that you don't hear a lot about if you're not in networking. And those are the three big ones. Then you're gonna demock set up web one layer. So we get to the IP layer and that's where I'm gonna plug in Rust in that stack three that I really enjoyed how we managed to get most of the IP processing. in that sec three to be, to use the type system so that I can write the code once and just differentiate behavior based on IP version here and there. Right? Because a lot of the behavior is common. And do you use the standard library for that, like the STD net, or is it like something custom? Well, we have our own create called net types. Right. We provide some conversions between this crate and standard if we need to interpret, but within we don't use the, so we have our own types and there's like basically an IP trait. And then we implement for concrete types of view for an IPv6. like if you browse netstack3 code, a lot of the code has been I type parameter on it that is bound on IP. And that's a function that can be called either for IPv4 or IPv6, for example. So let's say I have an IPv4 packet that is going to hit via monomorphization, it's going to hit the IPv4 ⁓ ingress path. Then you have the things that look more like general purpose network stack things. We're going to hit filtering hooks, connection tracking hooks, that's for firewalling. You're going to hit your routing table to decide, is this packet for me? Should I forward it later to someone? That's a lot of the IP layer complexity if you're thinking about the OSI layer models. Let's say this was a TCP packet, so you're going to dispatch this up to the TCP layer. Then you're going to hit the TCP DMUX because TCP has ports. Your source port is going to tell you which socket is going to receive that. You'll find the socket. Now you're going to parse the rest of the TCP segment and stat... ⁓ process the TCP state machine in the case of TCP for UDP it's easier just stash that in a receive queue if that's good. And for TCP there's like you kick the state machine to send X if necessary and whatnot. So that's basically the life of an inbound of an ingress packet. And that entire, like from start to finish what you told now, you were saying that this is all allocated once and it's reusing that same memory throughout the entire stack. Or that we already have to, yeah, well, that's cool. That's correct. That's correct, yes. Yeah, that's all done. The shared memory part requires a little bit of unsafe, to be fair, because it's shared memory. So we have a safe API for a little bit of unsafe inside. But the rest is basically abstracted behind a buffer trait. And it's backed by either a slice or an own buffer. And it just crosses the stack and it's good. And then when you hit, for example, UDP, like a DUDP receive queue, if you have a slice, you have to make it own because you're going to return now. That's another thing where memory goes. And for TCP, you need to put it in a different type of queue that looks more like a ring buffer. Very cool, so once we're at that point, at that point, I should be able to compile any usual Rust program that has the target as Fuchsia, and I can just bind to a TCP socket and I will receive packets, right? Wow, that's really cool. And so you are correct that I'm familiar with like IPv4, IPv6, but you also mentioned like ARP, Could you maybe give a quick intro for me? Yeah, of course. let's say, ARP is for IPv4. ART is the address resolution protocol for IPv4. So, if you're on a LAN, your computer wants to send, let's say, a TCP segment to your router, so it makes it to the internet. Your IP frame is going to have the IP address of the website you're trying to reach. But how does your computer know that the next thing here is the router, right? So that's in your routing table. Your routing table is gonna first say, yeah, like this is your default gateway, right? And then it has your router's IP address as your gateway. But at the ethernet layer, which also happens for Wi-Fi, you need to unicast this packet to your router using the router's ethernet MAC address. And ARP is the protocol by which you resolve that. So your packet effectively gets queued up until I'm able to resolve the unicast. And then we send an R packet that says, you know, let's say your router is 10, 0, 0, 1. You send an ARP packet says who has 10, 0, 0, 1. And the router responds, I have 0, 0, 1. And here is my MAC address. And then you send your IP packet that has been in the queue all this time gets an ethernet header with source MAC, my MAC, destination MAC, the one I just learned. and you know, ⁓ ethernet protocol IPv4 and then you send that to the router. That's what ARP is doing. It's called, you know, in, ⁓ since the introduction of IPv6, we tend to call this like a lot neighbor resolution. That's what it's called in IPv6. So like this is the neighbor table is like your neighbors on the LAN and how do you resolve their addresses. Yes, okay, very nice. That was very far in my back, so I'm very glad that you have refreshed my memory a bit. And so, of course, we also have Ethernet, which is like the only one I have ever used, I think within data centers and so possibly within Google, you might also have other protocols on that layer, or am I wrong? It's all possible. The most common by far is Ethernet, but there are other things that could be. You could have IP encapsulated in IP, so you have a lot of things that you can do there. NetStack 3 right now supports just two things. Either pure IP, where the driver tells me it's somehow capable of dealing with pure IP, IPv4, IPv6 frames, or an Ethernet frame. That's what we support right now. Okay, very cool. And then let's also perhaps dive a bit into DHCP because you also mentioned it at the start that you knew about it a bit. And then I guess it's very nice that you are now able to actually implement these protocols or at least further improve them. I know about DHCP. I do not know about DHCPv6, which I do think you also implement. So maybe let's start introducing DHCP because not everybody will know about it. And then let's also go... how DHCPv6 has improved it. Okay, I'll use that to plug IPv6 and how awesome it is. So let's start with DHCP. DHCP Dynamic Host Configuration Protocol, if memory serves me right. This is like, you see this a lot in your LAN at home, right? Typically your router is going to run a DHCP server that's listening on a special UDP port. And when you turn on your laptop, your phone, it's going to broadcast. a message asking like, is there a DHCP server here? I want an IP address. And so DHCP is basically configuring IP address plus other things for your LAN. And so when the server is gonna give you a lease on an IP address that has a certain duration, DNS servers like use these DNS servers to reach the internet, maybe like search domains, other things, this all typically over a few years far is gonna come from a DHCP message. on the LAN. it's called like, DHCP is called a stateful thing there because the server side is keeping tabs on who it vended addresses to, right? And then, so it both tries to... Is that by the way based on the Mac address? Like how does it know that something incoming is the same ⁓ system or... It can be the MAC address and the protocol also supports like a client identifier if needed. Yeah. But it's. And is that something the client chooses or what is on what is that based at client identifier? I think the RFC, I'm off, I'm riffing now, but I think the RFC doesn't specify what must be a client identifier, but it's an optional thing. So it should fall back to the source MAC address when it's absent. Okay, thank you very much. I believe so. Yeah. So this is how typically you're going to get configured when you're bootstrapping yourself on a LAN with IPv4, right? IPv6 is very, very different. So IPv6 relies on this other thing. And I love the lettersoup of protocols I had to learn to implement in our stack, but it's called SLAAC that's stateless address auto configuration. If you've heard about it. ⁓ But it's stateless because like think of it the play as the address space is so large you can pretty much randomize your address and you're almost guaranteed to not get a conflict on your LAN because you have Quite a bit of address space that is randomized, right? So typically on the land you're gonna randomize the last 64 bits of the address And then you on top of that you're gonna run DAD which is duplicate address detection to check before you assign the address, does anybody else have this address? And then you take it. And then with that, your router is doing, instead of DHCP advertisements, which is not in broadcasts, it's doing what is called router advertisements. So it's saying, hey, I'm a router. I can reach the internet. Here are some other parameters about this LAN, like the MTU you can use, prefixes, sorry, DNS servers. And then, an address, a global address assignment prefix. That's the big thing because on IPv6 you've got a global address directly. You don't need NAT, which is network address translation. So, so IPv6 works very differently there, but in some situations you want to have a stateful controlled address vending mechanism. And that's where DHCPv6 is in you. So it's somewhat similar to DHCP in what it does, but not really how it operates a bit different. But you have a stateful server that you reach out to and it can give you parameters just like DHCPv4 would. And it will give you addresses, will give you prefixes. So if you're chaining routers, you can ask an upstream router, give me a prefix, a subset of your global prefix so I can give to downstream things to me in my own array. So DHCPv6 is very powerful that way. And yeah, but a lot, I can say in my land, don't have the DHCPv6 Like, IPv6 can work without it because of SLAAC Okay, and so there are two things I want to ask you about. The first is about you are mentioning that you have the DAD and it was like for deduplication of addresses because the Nick on the LAN, it can choose a random IPv6 but it does need to check if it's not taken yet. How does it do that? Is that like some another unicast and anybody who already has it can just respond to it or how that works. I love how deep we're getting. Yeah, so this when you I'll go as deep as I can and just tell me to stop if it's too deep. But when you when you choose a tentative address saying like I want to assign this address to myself, you join a multicast group that has a formation rule based on the address that you're trying to assign to yourself. It's called a solicited node multicast address. So you basically blast a multicast. And so this multicast is not a broadcast. Not everybody on the line is interested. Only somebody that has that address or address that is like by the formation rule ends up being the same, right? Actually receives that. Right. And so you send a probe out to this multicast group, say, Hey, you know, does anyone have this address? And if they do, they're going to unicast reply back to you. Right. And if they don't, then you're going to time out. And this is all like tunables configurable, like how many tries you're going to do. Right. And so typically you're going to now assign the address and then I forget if the RFC specifies that an advertisement period after that, just like to say, got this. I don't remember. But yeah, that's kind of how it works. there's this well-formed multicast group and everybody. So once you've assigned the address, you continue listening on that address group in case somebody asks. And the interesting thing for that on IPv6 is that the ARP equivalent for IPv6, which is NDP, Neighbor Discovery Protocol, uses roughly the same mechanism as that. So you keep listening on that address and then a message could come in saying like either, you know, does anybody have this or just like, do you have this? Because I want to resolve the Mac, the Mac address for ethernet to send you some packets, right? And it uses the same packets, which is built on ICMPv6. Okay, very cool. That's bunch of letters to our soup. Now, before I dive into ICMP because I don't want to touch too much topics at the same time, you mentioned that DHCPv6 is not really needed. What we didn't highlight enough, I think, what are some good reasons when you do really want to use DHCPv6. Yeah. So to my knowledge, the what is basically network administration preferences. If you want to keep track of your clients, if you want to then specific addresses to specific clients, right? That's what you would do typically like, you know, in a home network, you don't have the necessity, you just want things to work, right? But on an enterprise setting, you might want to so that you can keep tabs on all the clients. You know, maybe you have other protocols like Mac security that are gonna clear before that or something. Yeah, and the other big reason that I see this being used more is for prefix delegation. So we touched on a little bit before, this is used with the MatterSpec, if you're aware. The MatterSpec is this open specification for home IoT devices. They rely a lot on thread networks, so that's... a different radio and the radio runs on IPv6. And so you want your IoT network to get global IPv6 addresses if your IoT devices want to talk to the internet directly without network address translation. So if you have an HTTPv6 server on your LAN, you can ask it for a prefix. Hey, you know, I want to be a router for my low-pen network. So give me... a prefix. it's part of the, let's think for a home network, you're going to get some two to 64 addresses allowance from your internet service provider, right? And you can allocate down, sometimes you get two to the 68, for example, right? So that gives you like a certain number of prefixes that you can then down to downstream lens and IPv6 routers. So that's a big use that I see that might be coming up with with better getting getting bigger, but it really depends on like There are a lot of things that need to go right for this to go right, but it's I think that's the To my knowledge. That's the most common use of it That I could see Okay, yeah, that's fair enough. And by the way, I also really like IPv6, especially because I used to do a lot of peer-to-peer networking and writing those protocols and building all those protocols. it was always really annoying that you had to hole punch and pray that you could get through the network. And there was like, you had to have like a multi-tier system where like, if this fails, try this, if this fails, try this. It was really very fallible and yeah, IPv6 solves a lot of that. That said, we do a lot of consulting and I feel that when I work with European customers, I have ⁓ a lot less trouble with IPv6 than with American customers where especially their firewalls are often not really be able to route or traffic if we use IPv6 and it results in very... very hard to debug issues, which is why sometimes we just disable it completely because it's, yeah, when it happens, it's very hard to find that was the cause. you, how is your experience with that within Google and I don't know in general. That tracks my experience. I cannot speak for larger Google. see that IPv6 works seamlessly for me when I am mostly dealing with an enterprise level network at a company the size of Google. Is that true of my home network? No. With my internet service provider, I... have more than once, I don't know the reason, I cannot even theorize why that would be, but I lose IPv6 connectivity and I still have IPv4. And I would never have known that if I was not in networking and know to go into my router and find that that was the problem and just turn off IPv6 on my devices for a bit until upstream IPv6 come back. It beats me why this is a problem, but it is. Yeah, okay. Very, yeah, that's networking, I guess. And so we mentioned this, okay. Now, in order to help the world with transitioning to IPv6, there's also the Happy Eyes protocol. And we also have now recently, well, not that recently, but I think there's a Happy Eyeball v2. And then I know, like, Curl recently improved that. I know in my own network framework, which is called Rama, we also... have an implementation of the first version still I think of happy eyeballs. Is that something you also implement within NETSTACK 3 and does it have a lot of benefit because even though I implemented it, still sometimes question like how useful it really is, especially because then sometimes if it's enabled and there are IPv6, like IPv6 sometimes not allowed on a certain enterprise network or corporate network and then. you're kind of giving priorities to something that anyway will not really resolve to anything. How is it for, yeah, sorry, that's a lot at once, but in general, it's about happy eyeballs. Yeah, now I'm familiar. We've implemented Happy Eyeballs in Fuchsia ⁓ as a library on top of POSIX, right? So NetSec 3 is not opinionated about that. We were giving you a POSIX socket. We're not solving any more problems than that for now. see that as like, our system is componentized and we see that as a higher layer problem, right? So... That's where we are on Happy Eyeballs. I actually don't have any sense of just how much that actually helps in practice to raise the two connections, how many more wins you get. Yeah, I live below L4. That's a no-five-plus problem. Hahaha I understand. Yeah. I have the opposite. live above it. So yeah, that's very cool. Even though I do like to dive deeper sometimes below it, but that's usually just to inspect some traffic or learn about it. Now that said, one of the reasons that Google, I think it was Google push for like quick and then doing it on top of like UDP. and doing it in user space was because then you have more control etc. I suppose given that, I mean imagine if the world was more built around micro kernels, then TCP would also be more in user space. I imagine they might have not really done that move because you could just do a lot of improvements directly into the system. Or am I missing something there? I think there might have been more motivations to QUIC than just that, but I heard that was a big one. And listen, it's hard to theorize what it would have been if the world was different for the past 30 years or so. yeah, feel like just because the system is updatable, for being realistic, just because the system is updatable doesn't mean it gets updated sometimes. So it's an infrastructure problem and infrastructure is hard to move, right? So my understanding is like the decision for Quick to be over UDP is not really that it was not available over TCP, is that doing a different ⁓ L4 protocol was just too costly in terms of infrastructure, right? ⁓ Because if every router is doing NAT'ing along the way, every router needs to understand your new protocol and the install basis method. I think that does play a part, but I don't think the microkernel thing plays that much into it, in terms of being on top of UDP, if that makes sense. I'm sensing there was another point to your thing is just like implementing it in user space or not. That's another part of it. And I love, I really like that topic about QUIC being implemented in user space versus in kernel space or not. Right? Because you could argue that the protocol can happen over UDP, but you could have a POSIX API for QUIC and implement it into the kernel. Right? You could. ⁓ It's possible. That gets more into like your... not infrastructure side of the updateability for new protocols that gets more into your like, where do I want to implement this thing on my host? Right. And yeah, that's where just being more updateable, could, there have been no concrete conversations about this, but within the architecture of Fuchsia, there's a legitimate conversation that could be had just like where, you know. should the application implement QUIC or should NetStack 3 eventually offer a QUIC type socket, right? There are many problems with this. there's the QUIC also has the security layer embedded in it. There's a lot of things to consider. But the thing, the reason that I really liked that topic is that I've read already, I think a cloudflare and a Mozilla post about challenges with QUIC and syscall taxes Right. And that's fascinating because of POSIX. So if you're, if you have a TCP socket, right. You, the kernel is going to give you a streamed interface over POSIX and you can read as many bytes as they're available. And as many you give in to your recv message call, right. Same for send message, right. ⁓ as long as the kernel can just copy your user bytes into the TCP buffers, that's a single sys call for a lot of bytes. Right. For UDP, you're typically gonna be, if you're not using the advanced syscalls, if you're just using rec, know, send and receive. For UDP, that's one datagram. So that's one syscall per roughly one kilobyte of data that you send and receive, right? ⁓ And I see a lot of people that are moving too quick in other applications, nowhere near Fuchsia, right? That are facing these troubles that are like the, if you're pushing enough traffic, you are doing if in one TCP read you were reading 100K now it takes you if you're just using regular receive calls, it's taking 100 Sys calls to feed them that same amount of data from the network. And it's an interesting challenge that like, you know, big protocols over, over UDP brain. And I just this week I read the blog post from Mozilla. and how they changed Firefox to use GRO, GRO is Generic Receive Offload on Linux, and things like send mMessage to be able to just single syscall multiple messages and rec the mMessage as well. So yeah, it's a really cool topic because I care about the performance on that layer very deeply, right? That's what I'm really working on. Yeah, yeah, for sure. And I have a feeling that eventually it will move to kernel space even within a microkernel. I have a feeling for certain that NETSTACK 3 will eventually implement it for the same reason that TLS used to live outside the kernel and it mostly still does. But now you also have KTLS in Linux. It's not hard to imagine that also within... Like you already have Boring SSL at Google. So it's not that hard to imagine that you will maybe using Boring SSL or maybe the successor to it. I'm not sure if there is one that you might just, or maybe you will adopt Rustls possible. don't know, but I mean, there is definitely a good reason why, because that would mean that your application doesn't need to again, choose this, doesn't need to implement it. Like it's a lot easier to, for developers. And as you said, there is so much freedom you can do as a... as a developer of the microkernel and the modules around it to really deal with the performance and make it very nice to use. Yeah, the performance thing is what excites me about doing something like this in a in fuchsia type architecture is because in terms of developer ergonomics, if I give you a good library that is implementing QUIC with all the good things that like your ergonomics are mostly there, right? But now there is the interface between your library and the system, right? And ⁓ being as composable as Fuchsia as we can make some interesting choices about, I'll give you an IPC API that gives you QUIC streams. It's doable within the architecture, for sure. And I think it's an exciting thing to consider and that for a lot of things. Yeah, for sure. And then if we wind up it back to TCP, which is pretty much where my story usually ends, is I notice that depending on the Linux variant or POSIX variant or whatever, like for example, if it's Dragon or if it's FreeBSD or whatever, they all come with their unique set of... options only available to them and I know also in Android there are a couple of them. What are some of the custom options you have for example in Fuchsia and yeah why was there a good enough reason to then add that to it because in a way you kind of like break POSIX then I mean not that not really break because it's like extra but still like I suppose it must be a very good reason to have such an extra option. I think we're mostly following the Linux-flavored POSIX for most things. The one addition that we have that it's in the code base, but I actually don't think it's exported in libc, is we have... This is very deep, but we have... ⁓ In Linux, you have the context of marking a socket and that you can match that on firewall rules. And in Fuchsia, we have more than one mark. So like that's a Fuchsia flavor thing. If you want to match sockets to firewall rules or even routing rules, ⁓ can, ⁓ Linux has this thing called FW mark, I think it's what it's called. And it's the socket option is SO underscore mark. In Fuchsia that works differently. have more than one mark. Those are the just 32 bit scalars that get matched in matching rules. And we, yeah, but I don't think we explored that in libc at all, we, today. So, you know, if you're just using POSIX, you wouldn't be able to see that. So we haven't needed to, but in fairness, we have decades less then a lot of these other systems to have built these things. So the need hasn't come, right. understand so could still come I suppose now yeah that's that but then my next question is often when you're dealing with operating systems you are also dealing with unsafe code because in the end you have to go down to system called etc but given that fushia is fully in rust does that mean that you barely have any unsafe code or do you still have some And why is that then? Yeah, so yes, just to nitpick, fuchsia is not fully in Rust. netstack 3 is fully in Rust. Fuchsia, you could call it 95 % Rust and C++. I don't know between those two languages what the split is. So for netstack 3 is fully in Rust. And netstack 3 is organized as follows. We have what we call a core crate that doesn't care what system we're running on. it has no fuchsia concepts inside it. Okay. And that's where all the protocols are implemented. That's where most of the POSIX API things look like they're implemented, but it doesn't know, right? It basically has hooks for everything that is outside of the core protocol machinery, right? And then we have fuchsia bindings around it. Core, which is all of the protocol... we managed to do without almost any unsafe. It's been a bit since I did an audit, but I think we had something around maybe an init, slices. That was the only like really memory and safety thing there. ⁓ And we do rely super heavily on ⁓ types as statements for checks that have happened on a data structure. So I have a type that is like, this is a Unicast IP address. I have checked it. So it's a Unicast IP address, name of the type, and you can only construct that type if you've run the checks that do the Unicast. So we have a couple of unsafe versions of that. If you want to skip the checking, just construct none of that. So it's not really memory and safety. And if you just grab for unsafe, you're going to find that we use that a lot in test code to declare costs. Now for fuchsia bindings where things get real, because you're tying now to the shared memory of the driver, we do have some use of unsafe there. Because you have some area of map memory ⁓ and it's just one giant chunk of memory and the protocol with the driver tells you how to slice it. We, it's, you have an unsafe pointer that at the end, and then we just put a safe API around it that basically gives you something that looks like a slice out of it. and, what else? and in the lower layer, we have, I think it's still around maybe, we have manually dropped for ⁓ all of our resources, everything that is a dynamic resource. So interfaces, sockets, all of that. We use this special data structure that we always make strong statements. It's kind of an arc that dropping the last one is special. I want to know that dropping the last one actually happened to make sure the system cleanup happened. that is an auxiliary crate to core where implemented that, and that has a little bit of unsafe. You could replace this with arc, but like we really cared about knowing when the last thing went out. And so we have this thing that wraps an arc. But buffer copying, all of that, we really try to not use unsafe. That was the goal in the beginning of Netsafe 3. There's always the temptation, right? Oh, if I just unsafe this, it would be so much easier to get it done. But you pay the cost later, right? So you don't want to, you want to really do it. So netstack 3 is heavily built in terms of parking. In terms of byte manipulation, we build heavily on zero copy, which is a project that was born out of Fuchsia and it's out there in the Rust community, has so many downloads. So zero copy is the base and we have our packet parsing and serialization crates and then they all build on zero copy. So that gives me lot of guarantee that I'm doing zero copy parsing of data as much as I can with the zero copy guarantees there. And we call it... ⁓ packet formats, crate I think. We do all of our ⁓ parsing and serialization. So that, in terms of byte manipulation, we rely on that and that solves a lot of the things that would be shady, or that you might want to use in Salesforce or something. Does that make sense? Okay, yeah, and yeah, it makes sense totally and it more or less falls in the expectation of what I would think you would still use unsafe for I also know about Zero Copy. I like the crate a lot, perhaps not all of our audience knows about Zero Copy. So could you just give like a quick summary of what Zero Copy does and why you would want to use it? Right, so zero copy gives you at its core safe traits and derives to do safe transmute, basically. Think of it like a really safe transmute. It gives you guarantees that you're interpreting this slice of bytes as a struct or as a scalar of any kind, right? ⁓ And like that's incredibly useful for networking because that's what we're doing. We're parsing things as struct to be want to avoid all the UBs that happen. If you're reading unaligned, if you're reading, you know, or ⁓ if you're just reading out of life, you're reading on panic or whatever. Yeah. So we heavily use it. All of the parsing serialization crates rely on zero copy to do safe parsing serialization, but without the cost of copying it out of the buffer. Very nice. That's indeed a good way to describe it. Thank you for that. And then in Rust you also have asynchronous programming like in many modern languages. Is it used in netstack 3? And if so, which kind of runtime do you use? Okay, that's a great question. So I talked before about the layers netstack 3 is built around. ⁓ Core does not have async. Okay, so like the fuchsia bindings do use async and we have our own runtime. It's called fuchsia underscore async. And it's built heavily on the zircon port primitive. So think of it as... It's exactly like the ports. think Mac OS X has ports as well that look a lot like this. But yeah, it's called Fuchsia Async. It's our runtime. It works really good for Fuchsia because of the port mechanism, because a lot of components in Fuchsia are really just sitting to make IPC calls and the IPC call shows up on the port. It is way leaner than Tokio ⁓ Not in the good way, in the bad way, in which Tokio has a lot of really cool features. The Tokio work scheduler is absolutely awesome. Ours is a little bit more naive still. There's work to do there, if you ask me. ⁓ That's how we do it. We can't run Tokio on Fuchsia. today is my understanding as like the Tokio runtime. Okay, that's fair enough. And are there any things that you like about the Fuchsia Asynchronous runtime that you think Tokio on its turn could benefit from, or maybe adopting of learning lessons from? Oof, The problem is I work so little with Tokio. I would be surprised if we have something that they don't. We did a big push for scopes in future async. Whenever you are spawning a new task, you... You can have a hierarchy of scopes and then you can cancel the hierarchy of scopes and just like that kills all the tests. Like it's a structured asynchronous. I heard that Tokio was introducing something like that. I never followed up. That's been working well for us to keep track of all the async tests that you do. And we integrate that with our debugger, which is like zxDB. So I can interactively just print all the tasks that are currently queued or whatever, there's, ⁓ you know, by pausing the program. That's super useful. Like if you've ever had a gigantic program with so many async tasks running, regardless of how many threads your executor has, that's objectively useful. Yeah, for sure. But then I cannot stop to wonder like I know Alice who is currently the head maintainer of Tokio took over kind of like the duties of Carl like she works in at Google. Is he then also maybe in contact with the Fushia Async runtime team or are you not aware of it at all? I mean, did you ever talk to Alice about this kind of stuff or? It's like a completely different department. The company is too big. The company is just too big for me to know everyone. Maybe I have interacted and just don't remember, to be honest with you. There's a growing Rust community within the company and it's even hard to keep track of everything that happens to them. Yeah, yeah, I believe if I recall correctly, she works on the Android team, but I might be wrong. ⁓ So, yeah, fair enough. Okay. And then something which I wonder is like, okay, it's one thing to have async and also it makes completely sense that your core crate is just pure code without a sync because you don't really need it there because it's about protocols, about how do you encode it, how you decode it. that makes totally a lot of sense. But then within the actual async code, do you make use a lot of the new features or do you still write more like your own futures, et cetera, or how that works there? Or do you... I try so much to not write our own futures, so much. So if you can just use the sugar, use the sugar and rely on the compiler to do the right thing for you. That's kind of what do. have utilities creates. So if you use a monorepo, right? We have a single utilities creates around the repository. for things that are very common for dealing with like fuchsia-flavoured IPC, for example, that justify hand rolling a future for some things. And then I think we do hand roll for things that are very important for the data path being fast, for example, right? So like I need to notify, like wake up a task so that it sends more data to the driver, for example, right? I believe that notifiers a hand rolled future today. Okay, very cool. then besides this, there is also, okay, so you have your own TCP stack and your own coder on that. And I wanna talk in a bit about how you see the future of netstack tree. And I know you have like a bug tracker of like wider adoption outside of Fuchsia. So I wanna go into there, but I am aware of one crate, which is smolltcp which is already... used in several different projects including which I think is Redox but I'm not sure but it's definitely used in a couple of such projects. What do you know about that project and how does it compare a bit? I mean I know you are like a native Fuchsia, you're a native netstack so I'm not like expecting you to do like here like a full analysis but still you're an expert in your field and I'm sure your opinion is well respected. Yeah, I've browsed the code. I've never done anything serious with smolltcp. If I had infinite time, I would spend all of my extra time writing embedded code and I would use it because I miss writing embedded code. ⁓ So I think that's one of the big differences, right? Smolltcp first of all, they seem to be targeting way smaller systems than we are, right? And they do it in a really nice way. So they're very careful about memory locations. And probably like the general code footprint of the program, And so they seem less bound by the POSIX requirements than us, maybe reasonable minds could differ there because everybody has the same kind of expectations sometimes about these things. So it looks pretty complete and Very easy to use from my perspective for an embedded system, but we diverge in the sense that if I was comparing it with NSX3, we really want to be like a general purpose OS thing. So, you know, I have multiple user threads opening multiple different sockets. need, you know, my DMUX to be fast. I need netting. I need a stateful firewall. All the letter soup protocols that we talked about to my knowledge, small TDP laments them all. Maybe not the HTTPv6. I don't remember. So it's a very complete stack. But in terms of how you build the architecture, I think we differ quite a bit in the sense that we're targeting... I don't want to say bigger systems, but I'm lacking the word. It's more like general purpose, more like almost more desktop-y. if that's a thing, right? And that changes how you write the code, right? Where I use a space stack. So I have a heap, I have an allocator. I would like to be able to, when allocator API stabilizes, to actually be explicit about the allocators everywhere, right? In that stack three, we don't do that today. I just have some Vec's (Vectors) around that I just push onto and it works, right? I think that would be like the big difference for me there that I see. and one thing that I learned at great pains when building a network stack is that most of your problems, the bugs and the, you know, the delicate bits come from in your system changes, right? Interface goes online, offline interface gets removed, interface gets added. Right. and so like, I, I find that likely not the, that common in embedded systems or systems as smolltcp is trying to target. And in, ⁓ and maybe that's solvable as the user of those multi-CP API, we took a stance that we want core to be a little bit more opinionated about just like, you know, I want to make sure that like, if you want to remove the interface, I'm going to, you know, either allow a packet that is referenced in the interface to make it fully through the stack. Right. So we have, we use arc. we abstract locking mutexes to a different crate, but we're said mutexes or like a fuchsia specific mutex implementation. Right. So it's, if you stare at the code, it's very, very different, but I think because we're solving different, we're trying to different problems. Yeah, for sure. That makes sense. And so I wonder, let's say you have a very special purpose and you need, like despite the fact that you have to deploy on Linux, but you do need to have control over the TCP stack. Is there a way, even though you're on Linux, to use something like smolltcp or maybe in the future, like Fuchsia and do your own TCP so that you can have more control or... Is that something that is just not possible as a user from user space? Boy, I never thought about that question. Like, I don't want to write code on the fly with you, but it- it- there must be a way. The question is how do you do that in a way that is performant? And that you also take out the Linux TCP stack thing. So if you wanted me to do that today with you, I would use Linux Tuntap networking to do this. So you create a user space interface and then you're going to get raw bytes. You're going to get raw ethernet bytes with a tap interface. then, you just throw that into smolltcp or netstack3 right? And let it do the full processing, right? Of the frames. Not only, you know, not trying to extract the TCP bits, if that makes sense. Hmm... Yeah, that makes sense. yeah, totally, that's indeed what I had in mind, but it's cool that you had a similar vision. I mean, of course, it's something very niche, but just sometimes wonder a bit about it. And so as we are nearing the end, I do want to talk a bit about the future. I mean, I know we don't have a magic orb and telling the future is always a bit difficult, but... Given there is an issue tracker about it and given there are sometimes questions about, can we use netstack 3 outside? Just for the same reason that netstack 1, at least I'm aware of, maybe netstack 2 also had like a lot of different use cases even outside Google. Like, what do you see the roadmap to be there or is it still very undefined? We know the problems were, right? So we got some interest in our issue tracker to get netstack 3 in crates.io so people could use it. What is in the way? The obvious things are, Fuchsia uses the GN build system, a little bit of Bazel. And so I want to do this in a way that I have like a good cargo-toml build system that people can use in crates.io and that hopefully we can just tie it up that it gets updated in a way that is maintainable for us, right? ⁓ That it doesn't become like a major chore to keep this. That's number one. Number two is ⁓ over the years, we've tried to make sure the core crate is no std But it has dependencies. if people... And specifically talking about something like Redox, that would be work to do there, maybe, to make sure that this can compile on what effectively they're doing in kernel space. There will be work there. So, like, out dependencies that made it into the crates by mistake or just... as intentional tech data that we know you would have to remove, those would have to get all weeded out. And then basically figure out, like you have to figure out this pipeline, you have to figure out all the dependencies because that's like three is not a single crate, right? We build on zero copy, we have the packet parsing and serialization framework crate, and then packet formats, which uses the framework to just define all the network packets that we use for all the protocols. And then I sec three core itself is like one crate per layer roughly. So we have the device IP ⁓ and then for the socket, CCP UDP crates. So all of that would have to make up and be, figure out some sort of stability API, because this is just something that people do. And then back to your original question. this is a massive code base. So it's, I think it's a very tall as test of anybody to use this without a sample program. So we would have to do something like what you suggested, just like, is the toy program that I could write, that runs on Linux, for example, that, that shows Netstack3 working right as a starting point for somebody that wants to integrate it into whatever system they want. Right. Those are the immediate things that I see that we would want to do so that this is usable, right? Because it is open source, right? So like going back to what were talking about, far familiarity is what matters here, right? I want to make sure that this feels like a Rust open ecosystem crate, right? Not, and there's work there because it has lived for all its life in the Fusion Monorepo. Yeah, for sure. Now, I do wonder, is there anything, I mean, I suppose there is, but what is technically stopping you, for example, from using Cargo natively and using that as a core in the Bazel setup that you have for in the, you call it GM, but I guess relate to Bazel, but in a way that you just, so you still have all your... base of workflows and all those things, but for just building and compiling the Rust crates, it would like piggyback on your cargo ⁓ workflow. Is that possible or will it always be something separate? I don't know. I haven't spent enough time looking at it. What I can tell you is that the netstack itself is not yet migrated to Bazel. We're still using gm which makes this way harder. ⁓ So I think that's my number one, right? And we have to still sit down and explore what the option space here is, right? So that we do it like, listen, we just got the interest. ⁓ It's always been in our hearts to consider this, right? And we're developing this in the open, right? There's a usability barrier here that we need to cross, but there are some technical challenges with it for sure. Yeah, and then besides being a good citizen and contributing back to the world, like, is there like a true incentive to do this? Because it seems like a massive work and I suppose it's not like an easy sell to the higher ups to undertake such a massive project of like preparing it to bring it to the open. I don't think it's a hard sell, honestly. If one of these operating systems is really interested, it's the sort of thing where we would probably eventually get contributions back or at least learnings. So if you're just thinking coldly about that, not the fact that you're contributing with the world, I believe that has its own benefits. Why do people have... plug fasts, right? People have plug fasts because connectivity is hard and you sometimes you have to put these two peers together so that they break together or something. So in my view, anything that is related to connectivity, the more people using it, you are going to derive some benefit, right? Maybe somebody picks it up and tries to use it on a school project to like a satellite network and then discovers that. you know, ⁓ like the this insane latency that I work with actually breaks netstack That's fun, right? That hasn't happened. I'm just riffing on a friend of mine's school project. He actually did that and found the network stack at the time. I don't even know it was back in Brazil that... completely buckled under satellite levels of latency. So this has stuck with me when I, ⁓ this resurfaced in my head when I started working with networking, it's just like, there's so many crazy uses for this. And I am not working on this, but people may. And if it makes my stack more robust, then yeah, I think there's an incentive there. I cannot speak for the higher ups, but yeah, it feels like there's an incentive there. Yeah, for sure. That's very interesting. And so we are coming a bit near the ending. We talked about a lot already. I do want to give you a chance, like is there for example, like a certain kind of protocol that you really like or a kind of detail or something there that you really want to share because like you're very passionate about it or you thought that's really like interesting, unexpected, whatever. I think we touched on my favorite thing, which is, I love SLAAC but it's stateless address auto configuration. It's. It's so great. It's so great. It's it's it. And I love it. Just like read the RFC. If you have the opportunity, it's, it's a gem ⁓ maybe some people see probably that I don't see. Of course, nothing is perfect, but it's really, really, really cool. for. plug and play type things, right? So like it just works. It's less set up. Yeah, IPv6 is going to eventually take over the world. It's taking over the world. It's great. Always update plug for it. And yeah, I am always going to plug Fuchsia. This is the most fun thing I've done in my career by a mile. and so if you like systems programming or just like low level operating system things, fuchsia.dev has a lot of fun reads just for, you know, learning a thing or two. Okay, and how is the hiring like, let's say someone really wants to work with you or your peers on Fuchsia or netstack 3. that something you also like open to or is it like for now you have sufficient amount of people and you just want to wait a bit with it? ⁓ yeah, the, the, canned answer is jobs.google.com or Google careers. Just go there. Apply. Yeah. Okay, that's very good advice. So with that in mind, I want to thank you for your time. It was an amazing conversation. I learned a lot. feel we could talk for hours about protocols and honestly, I hope one day we can share a drink and do so. I will gladly take up you on that opportunity. Yeah, take care and enjoy the rest of your life. Thank you for having me, Glen, it was awesome Elizabeth (Plabayo)
1:15:32 | 🔗
Netstack.fm is brought to you by Plabayo building secure, open, and resilient infrastructure with Rust protocols, and purpose. This show is also made possible by Rama, the open source networking framework. Plabayo offers service contracts and welcome sponsorships to keep building and supporting its ecosystem. The theme music of this podcast was composed by DJ Mailbox. If you enjoyed this episode, don't forget to subscribe on your favorite podcast platform and leave a five-star review. It really helps others discover the show. Thanks for tuning in. We'll see you next time for the next handshake.