 He was working in the fly phone community when he realized that mesh networking protocols are not as efficient as they could be and that they limit how many nodes can be part of the network. Therefore, he started to simulate mesh networking protocols and today he will talk about that. If you are listening to this and think maybe I can be more part of the audience, we invite you to our virtual audience. We have a beamer here so you can watch the talk and the speaker can see your face and your reactions to that. That is available in a jitzy room under audience.rc3.oio.social. Please join there and that's nothing more to say for me. We're really glad to have you here. Thank you Victor. Hello everyone. This is my talk about how I try to emulate huge mesh networks for the purpose of making better ones and of course start with taking what's already there, putting it into some tests and testing it. Yeah, so let's start. My name is Moritz as I have been already told. My family name is very funny and very confusing which is awesome and I'm a long time free and liberal open source programmer so I do a lot of software related to distributed networks, mashing security even and most of my stuff you can find on GitHub and I've been with the fry phone community since 2011-2012 around that time and I found it awesome to flash Vifarotus, put them out there, let's create a big huge mesh network at least that was my dream and of course to connect people so they can talk to each other, relying on other proprietary infrastructure from Vodafone, Telecom and the likes or even to get even internet to refugee homes stuff like that. So yeah, so that was my idea. I mostly this is idea of making big huge networks that connect everyone but are still distributed and not centralized and over time I learned that well we can get to a few hundred nodes in our community but then it gets problematic since we are using Vifarot and we also these mesh networking protocols that we use they're quite well they're okay that we're good in comparison but they're still a bit inefficient for what we try to achieve which is much much harder than compared to what you want to achieve when you have a data center or stuff like that where you have gigabit links and not like PASCII or horrible Wi-Fi links that break down every few minutes if you're really unlucky. So yeah in general I'm a mesh routing enthusiast and I think we need better protocols so I set out on this journey to create better ones to test the protocols so of course this got me drawn to other people with similar goals and this brought me to the battle mesh for those who don't know the battle mesh is a yearly conference in Europe sometimes it's in it was in Leipzig it was in Vienna it was in well different European countries Slovenia I remember and a lot of like 40 50 people maybe and they bring a few routers and then they do the battle where they put their favorite route mesh routing protocol on these routers and then they do tests throughput and stuff and well yeah then they see in the end after some luck I have some graph as they can say this is one bit better than the other one but that's it and of course it takes a lot of time to set this up then of course of when you change just a different routing protocol then you might be unlucky and somebody is using a microwave and this influences the results very badly and also my personal perspective is that I really want to have like something that is more efficient and more scalable so throughput is maybe not the most important concern but it's connected since if you don't have much throughput then scalability will be a bit harder so yeah so this is not really what I wanted to test I mean it's still interesting but yeah and but scalability it's a bit hard to get a few thousand routers to this event and I mean it's just too costly just too much work so with the corona of course everything became virtual and I thought okay let's do a virtual battle I mean it fits I mean I was already creating some software to do that for myself and I thought okay let's do a virtual battle this has of course drawbacks that you don't really have real hardware real vif interference patterns that and stuff like that but of course I thought okay let's keep it simple what I can achieve right now at least throw everything out like if you're in a balloon and you're going down then you throw everything out until the balloon flies so that was basically what I was doing so I wrote myself a tool for first to do this virtual mesh route the virtual networks where I can run like by far protocols on each note it's like you have the fritz box or some rifle router you put some software in it and it has ability to throw to send some packets and then the packets will be transmitted received transmitted and received by other nodes in you know in reach and then processed and in this way they need to organize themselves so you can reach everybody without much delay without dropping too much package and packages and stuff so what I did was yeah let me yeah I did yeah some tool it is called meshnet lab don't really matter I mean there's some other software out there some is very similar but mostly they do like containers thinking when you think of Kubernetes and stuff since I only had a very small laptop I don't much resources but those are planned to have like emulating like at least a few hundred nodes this was not an option I don't have that much RAM or CPUs or servers so I thought okay let's throw everything out especially containers so what I did I was using Linux network namespaces which is really awesome it's like one of the building blocks of containers on Linux but if I am willing to throw it a lot of stuff I can only use this one and script everything with Python and use IP commands ping SSH stuff like that I mean SSH for running it maybe on two laptops or even more and yeah it's it's on the internet I'll the link will be in the end but I think it's important that it's a CC zero license you can do everything you like is it so just give me maybe a little bit of an introduction to Linux network namespaces which is the core of what I do yes I've told you it's a building block for AXE Docker and so likes and of course on Linux you have other namespaces like file namespaces stuff like that to do some kind of virtualization but I threw everything out and just use the network namespaces so you can already do that if you have a recent Linux kernel with this IP commands you can use this IP net NS which stands for network namespaces namespace and you can add some namespace give it a name like like in the slide here we create a namespace called foo which has its own network namespace and then you can like list it and then you can execute arbitrary commands in there of course if you do something like LS to list all the files since this is a network namespace you only see like yeah you see what you have in on your disk so it's not encapsulated on this file system level but just different network set so if I do like in this namespaces IPA like list all interfaces and addresses I will see only this local host interface which isn't the one I usually see so this is a different one so and then you can go next step you can create a virtual cables which you see by having two interfaces so if you stick in one interface one packet it just comes out of on the other end of the cable on the other interface and then you can put these interfaces into these namespaces and connect these virtual nodes basically okay so yeah okay here are some some commands if you want to try it at home it's not dangerous dangerous dangerous it's fun where you create a cable and then you can stick it in different namespaces and then you see okay we have this interface and this one namespace and the other namespace and of course you can start net some arbitrary network program on a list in this network namespace this is IP net and s exec and then the name of the namespace and then just the command where you start your program and it will just see these interfaces and have this different TCP IP this network stack so so this is this is just the building block of what I fused so and this is like very efficient so I was able to emulate a lot of nodes and how much we will see soon yeah and this whole mesh net lab my little program consists just of a few pricing scripts one that takes a jacel file and sets everything up in a way so I have like this network namespace every network namespace is one node and these are connected by table and I can have a jacel file where I define okay this is the cable with 100 m bit some packet loss stuff like that and connect these and then I have some magic there which I will slow you show you on the next slide that will show you a bit how I managed to make it more Wi-Fi like so thing is I every node will have one interface you send some some pink some packets there and it will arrive in other namespaces not just one but multiple it just depends how I define my network via this JSON file and then of then I can start like for example Batman advanced which is the common routing protocol for Freifunk networks in there in everyone and yeah they will see each other and do mashing and then I can do pings and stuff like that and something that is I should note is that this is an emulation it's not a discrete events simulation so that means just by throwing more CPU powered on it at it it won't like run faster also I have this problem where when I sent a lot of packets then it might influence random things in other parts of my virtual network so this is really my bad for emulating or for testing throughput assault but if you keep your your traffic low to certain amounts then you can get very very big setups so bit of the internals before we go to the results yeah basically you have this namespace so let's say you have like a network with node a b and c and b is connected to a and c and then internally I have this set up this way where we have like three namespaces every namespaces have has an interface in it so every application you start in this net namespaces will only see its own interface and this is one connected the other end to the two different namespace which is basically my my bedrope for all the cables which I just called switch which I've stuffed full of bridges and bridges that are connected to each other according to the JSON file I mean or according to how I want these nodes to be connected and which what I did is that I dumped down those bridges to be hubs so hubs are like well as a network engineer you might still have a hub somewhere for probably not anymore but like 10 years ago it was still valuable if you wanted to do like packet inspection because a hub when you send a packet I mean it's like a switch but if you send a packet on one port it will come out on every other port so this is like a dump switch that doesn't really remember where to send a packet to if it arrived so so you can like put in two devices and they can interact and on all the other ports you can like listen in on all the packets but nowadays you have switches but where you can just configure them so they will do the same thing but like 10 years ago these like old devices they're still gold if you had wanted to listen in on on traffic so this is what I did so since I wanted to have something like a broadcast domain where you just send some some packets that might not even the broadcast packet but maybe just a ping or so but so but this packet will still be received on on all neighboring nodes I mean in the topology so if C sorry B sends out ping on this it's uplink interface it will be received on the uplink interface on a network namespaces A and C so this is basically the magic source I've used here and the switch name space yeah if you use this one so I don't pollute my usual network primary namespace so if I do on my console just IPA I don't have like thousands of bridges which could be really messy okay so let's get started with the tests and so I've already told you that measuring support isn't a really good idea with these kinds of tests but what I wanted to do first of course is to benchmark how many packets can I get through until everything gets screwed so maybe packets getting dropped for no apparent reason and of course con convergence is something that I can test which means that the network every in the network every node every state of this routing protocol instances they know about all other nodes if they don't do anything stupid I mean and so if I change something then it needs to converge again so every node has like there's a coherent view on the network and can route according to its routing protocol also if I change a lot this is called mobility so you can think of like bifurators on on cars I don't know or just say get turned on and off and connect or connect to other devices and of course my favorite topic is scalability so this is really what I want to test here and also did try to test usually IPv6 not all routing protocols have the working implementation for IPv6 but well I tried and of course some limitations I've already told you is yeah real time so it might take some time I can't just throw faster processes on it but it's of course helpful and I have to be very careful for I mean performance issues like I owe in I owe limitations to influence the results that's something I want to avoid of course and I also can't really emulate vifar interference patterns where you have a vifarator it sends something but some other nodes that was previously unseen sense at the same time and then it both trashes with the packet and in air stuff like that I don't have that but well it's not impossible to do let's let's see there are other projects out there that might do that very well I will have to look and of course since it's not real time the testing duration can be quite long so I have some tests that run under an hour but also tests that I mean some of these slides I will show you they took like two one two weeks to to to produce so it was around the clock the CPU was like on mostly on like 5% idling and then the networks got bigger and bigger and your tests and and then the CPU got quite stressed at the end and that's where of course you have to be very wary with your results if they're really like you're showing what you what you hope and not some interference with the CPU or I owe controller so the first thing I do is benchmarking of course but I will have a slide there in a few minutes and one of the tests I have to had to do in like yeah this is a bit was a bit annoying because Batman advanced for those who come from the Freifang community it's a routing protocol that's used a lot there but it's also implemented as a kernel module and they use like a single threaded primitive there that it couldn't get rid of so what I had to do for for this was to get a server with like a lot of CPUs and and for every CPU or two CPUs I use the virtual machine and run my simulation there and connected all this virtual machines over tunnels and yeah but I got it working it was a bit bit hard to do it was and I had a lot of help so thank you for that and so I have some results there as well that are comparable and okay now of course to the routing protocols I actually tried to or test it successfully where for example ectrasil which is mostly a spanning tree protocol with cryptography so all IP addresses there are like derived from from a from a secret key or public key at least a cryptographic key so you can't really choose your IP address and it has spending tree architecture which tries to make a spanning tree out of everything like OSPF maybe but it's more mesh like but it's mostly used for over the internet connections it's interesting and Batman once I've already told you it's used mostly by Freifang communities as far as I know yeah it's for really mobile mesh networks and then there's Babel which is also for for these cases but also focused on over the internet and you couldn't push out routes so it's more you can integrate it very well in professional setups when you are a network engineer stuff like that and working on a ISP and then there's all this one which is also previously used heavily used by the Freifang community which only really supports IPv4 I tried IPv6 support but it was broken but there's a newer version OSR2 which worked quite well in that regard and then there's of course BNX6 and BNX7 which are like descendants of Batman advanced but this is in user space and they have a different protocol and then there's CGDNS which is a bit old also like a bit comparable comparable to ICDRAZIL, CGDNS is like the kind of a predecessor of ICDRAZIL I would say and then I tried also OSPF which I didn't get to work honestly maybe someone can help me with that because it's a bit tricky because I don't have like a I can't manually configure all the nodes I mean then it's meant to be as an ad hoc mesh network so every note note note the rakes up starts up and sees packets and coming and needs to figure out where it is who are the neighbors and stuff like that and OSPF is mostly well it's a bit hard to configure that way so if somebody can drop me a hint that would be awesome so let's get to add some actual results so I've told you first we need to do some benchmarking to see how much nodes can we run before we get into trouble so I said okay I tried an old laptop on the server and what I did was I created some network I think this is like a grid of nodes and I trade with tried this for yeah with different kinds of nodes and they did some pings and then I saw okay how many packets do of these pings arrive at randomly selected pairs of nodes so I'd select some random pair of nodes that are not neighbors and of course not itself and then I sent a ping and said okay if it arrives then all is good and of course some of course them doesn't don't arrive so then I get some some percentage of the arrival there and you can see that when I get to for my laptop this one was my old one when I get to like 120 nodes then one of the routing protocols in this case Batman advanced experience packets to be dropped so I knew okay so much I can go so far if I don't do much traffic and to be safe on the laptop I would go maybe with a hundred nodes tops and for the server it has the more beefier CPU it was the old one I think from 2012 quite old but back then not I got up to 250 nodes so I had a good like ballpark where I can scale this up so my setup also I can distribute over different computers so that was very helpful and a bit to my measurements I mean I've already told you how I measure this packet arrival in percentage so 100% means every note every every ping arrived usually I do like I don't know 200 pings and when half of them arrives then I say okay it's 50% arrival and of course I pick random pairs and these are not meant to be neighbors and of course a path has to in theory exist and yeah but I didn't measure throughput and I didn't try to press that because that would harm my results okay and yeah I also didn't do much pack packet loss because yeah I started with this setup and maybe at the later time I want to introduce something like jitter that you usually see with Wi-Fi packet loss and stuff like that but for now every test you will see here a result is based on an assumption that I have like a hundred megabit links between the nodes with one millisecond delay of course unless stated otherwise okay so for convergence so I've already told you convergence is measured when I well in this case when I change when something changes and then I measure how the connectivity changes I mean how many of these pings arrive and in this case what I did was I set up this whole structure with this namespaces then I started like at time zero here on the axis all the nodes also all the protocol software I mean the same one of course in every namespace and then I did and after two seconds wait I did pings and I saw for example here let's let's say use Batman here which is this light blue line so I did this every two seconds I think and we see up until maybe 27 seconds after start none of these pings arrived but then it got to hundred percent very quickly so and this could be explained someone from the developer team explained it to me so I mean this is not like something like bad so it's just yeah timings and just it's just starting up there's the Batman advanced instance and of course all the instance here so and testing was basically I started so I created this network then I started all the clients waited two seconds measured the pings and then draw the point and then I did everything all over again with the exception that I know waited four seconds then I teared down everything again and started up everything again then waited six seconds so that takes a long time but in the end I got this draft and it's not really that important how fast these protocols go up here but it's still some interesting thing that shows you some implementation some timings that are part of the source code so part of the default configuration so this is not like saying okay this protocol is very lazy or very bad or slow of course you could maybe do it better but in practice it doesn't really matter because this is just like startup time of course at point zero all the instances were already started or just started but then I at this point I got like counting the seconds and one oddities that are found here and it was also reproducible was the CG DNS I don't know what they do at 30 seconds but the convergence goes down so not many pings arrived here I don't know why but well it's interesting to see and of course all this what I test was on a grid structure so I have like notes like yeah on a chess board and they have like four neighbors yeah okay but of course I did the same test not only on the grid but also and on a what I call a random tree it's like a tree structure but it's not balanced I have a picture of it in later slides but it's still I think interesting okay so we have this on it on a random tree which is basically the same result then I did it on the line which is pathological pathological because usually in reality you don't see like mesh networks that are just like a like a line one note and the next line and it only sees it to neighbors and then you have like yeah got up to like 60 notes so usually you don't have that in reality but it was still fun to try out and you see for example bet advanced and other protocols have a lot of problems there even after like 60 seconds oh no I said 60 notes but it's 50 notes that's what it says here in the small font so that must be true and yeah and you see that bubble for example sorry that advance doesn't go up to 100% which is understandable when you see that on the matrix that bubble you that Batman advanced uses doesn't allow so much hops anyway so it can't get up to 100% so it's just some interesting fact but in reality you don't have that many hops in your networks network so if you have like 50 notes I think on a grid I think this is actually 49 like 7 times 7 and then you have like seven square routes yeah around maybe seven hops and so but some of these can take a longer distance and yeah that's where they get dropped okay so yeah this is basically some results here nothing really interesting now I think it hope that we'll get interested more interesting and there I have to change actually because it doesn't show the animation in the presentation mode and here I tested the mobility and you see this graph I have slides like this coming next and what you have to see if you don't if you're too lazy to look at all this grass then look at this bar chart so this is just like the the simulation of what you see in the graph above and what we see here is on the right the animation how the network like moves what I did here was in the station's JSON file I gave every coordinate like a GPS coordinate random one and then I said okay off when two nodes are in a distance of a few hundred meter or 150 meter I don't really know then I make a connection and then every like two seconds I move these notes into this virtual space randomly and then I see which nodes are near each other and if they're in range then I make this connection so is this so it's just a connection or no connection and what I see here is okay there's not much mobility not much changes here but we can see that at least three protocols have a few problems here because they're well they're not really like optimized for mobility but everything else is like yeah a hundred percent of all things arrived and now let's get to the next slide no no that was new slide and I need to start the presentation and you because it has created a new presentation okay why not that is something I can do yeah recover why not okay I can do it I think I want to go there because here we have much more mobility and you see these all other protocols except these three are also having lots of lots more problems I can see where it's very chaotic here but still most of the mesh running protocols that are meant for well optimized from the mobility are holding out very well and every well nearly every packet arrives except for these three protocols let me show here okay next slide so what are the results here I mean these three were cgds icterozil and BMX 7 which are having some problems here well it's not that surprising except maybe for BMX 7 but yeah maybe they can reduce done something we as a configuration but I've also always used like default configurations okay so this is just a different mobility scenario where I've also measured this is a traffic and what you see here is I can't really see it on my screen is that that way it's just too small on my screen yeah but yeah this is like a different time mobility scenario and you see that icterozil for example creates a lot of traffic but for routing it doesn't do so well very badly but I've been told by the developers that they're improving on that situation and all the other protocols here use a lot of low overhead low low traffic and yeah and Batman Advanced and BMX 6 and 7 are doing quite well here okay yeah these are just results so yeah I guess it's no surprise so now to my most favorite result is skill ability so I got hold of of a server which a lot of power and so I was able to simulate up to 2,000 nodes for this one I did a thousand just because 1000 nodes in one line is like horrible for for your routing protocols because in reality it doesn't happen what you what you can see here is that if you go up with a number of nodes that yeah what we have here that we reached something like yeah well what we can see is that the traffic goes up linear for most protocols for some for Batman for example it stays the same but also we also see like this dotted lines here they go down very quickly I mean we can see it here which basically means that this is on the right side that most of the things don't arrive so basically our result here is it doesn't really say much to us so since the traffic doesn't really arrive the pings the packet less is too high we can't really say something is better than a different one they all like bad on in this scenario but in reality of course you don't have like a thousand nodes in one line okay now on a grid it gets more interesting so you see most of the routing protocols they're doing quite well with this scenario I got up to 2,000 nodes in on a grid and most of the pings arrived and what is most interesting here I mean is that for Batman it goes up and down and that means that the amount of traffic they got in in on one single node on average is going down and actually I don't know why but I hope to find out at some point but you can also see that here is the amount of packets that arrive it cramped but it's also going down after this this high point so this is well basically means that yeah Batman has some problems here I don't know what it is maybe it's the CPU since I had to do some special things with Batman here but in in general I can say that our traffic look girl on a link in on average with the size of the network on the on the grid grows linear and for some cases well I don't know what's really happening here but there's a lot of questions here but well I tried to push it by throwing out a lot of stuff and sees us like some average traffic results that I measured there so you can say that all our one is quite doing quite well I've omitted Batman here because the packet loss was just too high so I couldn't really get to like meaningful result and also did this on a random tree but we also see here a lot of traffic packet loss for a lot of protocols which don't really scale to apparently to this size to these sizes and we also got like this hill structure for Batman advance which is probably having with some problems with the metric yeah and yeah that's basically how this random tree looks like yeah it's just not a balanced tree but yeah like a tree but the thing is we don't have any loops which of course in reality you'd never have usually mesh routing protocols tried to avoid loops and in this case it don't have to so I was expecting that I might do well but of course there are a lot of other factors that you have to take into account and also try this on Freiforg networks topologies I don't know that from the Freiforg community sites yeah I mean this I've included this slide but the results are not very conclusive so you can't really say that one is better than the others and yeah and I hope to get my hands on more hardware so I can do more extensive tests that are more meaningful but these at least are interesting and with this I would like to conclude my talk and as I've told you all the results while the project is on github also the results and there are also scripts you can run like there's a test ordner there's a piecing script for each test you can run it and then there's a different one that uses glue plot to produce the exact images as I have and you can just try it for yourself and have fun and I hope to can to use this pro this tool to compare other routing protocols maybe to create my own and see how it goes with other ones before I go to actual hardware and of course I've told you are more interested in scalability for now and with this I would like to conclude my talk and thank you for watching and if you have questions now's the time thank you very much okay thanks for the presentation we have some questions okay I brought my laptop okay questions are arriving from the internet the one question is question about all these nice graphs yes do you have error bars as well I guess you repeated the measurements more than one is this worth looking at that with outliers etc yes I did error bars in the beginning but since one run of the entire graph took like hours it was very tiresome in the beginning I did like 10 iterations of each graph then I noticed some buck then I had to fix it then I tried again and that's how the week pass and now it works but still some tests like skill ability it has it takes like a week maybe I can try of course for one routing protocol which is much much quicker but if you do 10 iterations for your for example for an error graph it just to tedious I would like to have one and what I can say is that the error graphs show like not much that much variability so more most of these results results are if you see them there from the credit the quality wise they're the same if you repeat them thank you another question from the internet that just arrived is why did you choose to cook your own protocol test that thank you that's a good question the thing is that as I said in the beginning is that most test beds I found on the internet I have a list on my mesh net let mesh net lab project page in the bottom on the bottom I have a list of other projects that are doing similar stuff and also I'm using like images Docker images running like that or Kubernetes and stuff and then I go up in the problem that I don't have the resources to run all these like multiple Linux kernels and since I well I use this analogy where in an airship or a balloon and going down so I throw everything out just to get to this amount of notes and I still hope to get like useful results so that's what I did and a few weeks ago I found actually a project a mini net lab Wi-Fi is that I have to look further into I thought they do also like containers which would be too heavy white but somebody else told me no they don't use containers so I would have to look at there I think it's also already listed on my project page so yes I would like to use other ones for me of course now I've written yeah let's reinvent the wheel but of course you learn a lot and yes so I tried but I figured out that way over my head with the resource I don't have that much okay thank you from the internet I don't see anything else right now but I also wrote down questions so one thing I really I saw is that the CJ DNS protocol in all the build-up graphs breaks down again around 20 seconds why is that did you look into that actually no I only knew that it was reproducible and that I could rule out CPU effects which I was very cautious about that it might ruin my results or then I see basically measure how big good my CPU is and then it depends of course on the routing protocol implementation so that's something I like to like to avoid and with CJ DNS and other protocols I sometimes I've asked people that know much more about these protocols and why they think this might happen and I got some replies like yeah this there's some timer or this is some feature you can turn it off and then you won't see it or it will have a bit different outcome or you can adjust the metric and then of course if you have really big national network then of course the metric will be able to cover these distances and because routing protocols is the metric like hop metric says yeah maximum hop count is 30 then of course after 30 hops the picket is dropped beautifully and yeah that's it because in reality you don't have the crazy people yes another thing I thought it was interesting that I think you in the mobility graphs you just drop the connections right so when when the connection when the distance is longer than I think 60 meters so there's no degradation of the Wi-Fi quality and more and more packet loss do you think that might change something if you had these abilities to calculate that into your simulation I don't know I would like to check that I haven't already prepared not the graph but the test I just have to run it but of course the Christmas time is a busy time and yeah I didn't get didn't have time yet to test that but yes I have this prepared I just have to run it of course people can't run it themselves but I have to point out where to like enable it okay yeah and another question that I thought about is so you talked about these that's that's for big networks it's not clear how these protocols perform yes what are applications you could imagine or in your dreams if you think like you do this next round of simulations and everything works really well and how you want to okay let's see later what in what scenario could you help the Fife on Community and build a really big network that was not possible before how could that look like yeah I know most Fife on communities for example in Germany use Batman advanced which is very good but they max out at 500 to 1000 nodes at that point you can't scale it up more because then the management traffic just for the notes to keep say yeah I'm still there it's still like it's gross too much it's gross and linear which I saw in the graph but at some point you just saturate your Wi-Fi connection and that's of course bad and that's something I would like to solve for example okay this is more like a smaller dream maybe where we have we can connect entire city and everybody in a city and you can also put in like low bandwidth nodes sorry connections there that would be awesome I mean but you you don't really want to for example watch a YouTube video over Laura which basically is one of a few words every second you're allowed to I think to send so it would be nice to have a routing protocol that not only scales to these sizes but it's very efficient and doesn't it prevents from misusing like low bandwidth connections with YouTube videos or stuff like that what would be awesome and maybe a more crazy dream would be of course to connect everyone in the city with a decentralized network that doesn't have a centralized authority or so something like that and so traffic that is sent local is meant for my neighbor only stays local in the sense local so if for example some three letter agency wants to spy on us help they should get on a van and drive to your home and get all that the spying equipment but I think it's atrocious that's very bad that every traffic goes through some big box in in Germany maybe or a few of them and you can just do math surveillance there so this is something I would like to to to prevent to give power back to the people so they communicate which is with each other with their neighbors without being like dependent on other things of course you can think of disaster areas where you can apply this or if you get crazy you want to replace the internet with something better I mean it's in ten years we got says saying that the internet doesn't scale anymore which is kind of true but also we got a lot of more like CPU and RAM which helps a lot and dig up pipes so we can just say yeah the banter is the overhead is really low compared to all the traffic YouTube videos and Facebook status messages we send there but yeah for Wi-Fi or for local for cheap devices that don't have that much banners you need a much better protocol so having like a protocol that scales to these big sizes is like really really hard like exceptionally hard so I don't make them say that yeah I will be done like next year probably not but I guess it will be fun right and maybe I can push the boundary a bit so that would be something I dream about cool what a nice outlook I think this this talk where we're done here and we were over the time usually we would have a discussion round in a thing big Lou button room where you could discuss with Morris but in this case he's also doing to two workshops today in our workshop area so after a short break you will just find him there and he's available this this workshop area is available under workshops.rc3.ou.social so you can just join there the times for the workshops is something you can find on the schedule which is also online and with that thank you Morris thank you