Hello, everyone. Yeah. So here's the next presentation. And Matiushko Valsky and Kamil Sochkova, they will tell you about the future of our future Internet. Yeah. Please welcome guys. Thank you. So we would like to introduce ourselves and our talk, but it seems the Internet has already done it for us. So we have learned things about our talk. Our attempt will be to do something slightly different. So yeah, we are people coming from a university, but we are not academics, and we are kind of concerned about whether things can be at least somewhat useful in practice. And an important thing is we don't think we have fixed the Internet. We think the Internet has many layers, and we are trying to provide a tool that helps in the toolbox of the many things you need to fix the Internet. So yeah. And also, our thing can let you communicate with more than 12 computers. So let's move on to who we are. We are not academics. Yeah. So I'm Matiushko on this slide. I deployed stuff that really works, which definitely defines me as I'm not an academic. In my past, I spent few years working in corporations, bigger or smaller. Then I decided this is not the way to go.  I spent few years of my life working at CERN on various open source projects, mainly OpenStack. Then I moved to ETH, and then from ETH, I moved to Anapaya Systems. This is our spin-off. You will see what it is about in the presentation. And I'm Kamila Soczkova, and I think of myself as the sort of person who comes to your system and kicks it until it starts working, or at least kicks it until the system tells us why it's not working. And yeah, I know a little bit about a lot of things. I get excited about the new open source thing every week. This week I'm very excited about FreeBSD, but I'm excited about a bunch of other things as well. And I am weird. I like hardware, and I like monitoring. So those are two things that define weird people, I think. And this is my cat. So let's talk about what we're going to talk about. So we are trying to design a new internet, if we say it in a very grandiose way. But actually, as mentioned, we are doing not quite redesigning everything, but we are trying to redesign a single, one tool in the many tools needed to fix the internet. So why do we think it might be useful to do that? And what we are trying to do is going to be the first part of the talk. And then in the second part, that's going to be more interesting, perhaps. We will tell you about how you can use and try out our idea yourself. So let's start. So you've probably seen on occasion the internet doing weird things. And there quite often happens that something looks fishy with the internet. So as an example, sometime at the beginning of last summer, a large fraction of the European traffic float, like you would send a packet from Zurich to Bern, and it would go through China. And there was nothing you as a user could do about that. You just don't send the packet if you don't want that. So yeah, the internet, as it is designed today, it does a lot of the heavy lifting of the routing. And all of the thinking about moving data through the network, it does it for you.  And so you wanted the network to do the heavy lifting. But so how it works is you throw the packet and then you somehow hope that the routers in the network somehow deliver it to the right place. And don't go through China when you're sending a packet for 20 kilometers and something along those lines. However, nowadays we can actually do, we have more options. So the design where the network does all of the difficult things for you is one option. But it's not the only option now, because nowadays end hosts are a lot faster, a lot smarter. And there might be different pathways that we could take and take a look at that might or might not work better. But we won't know until we try, right? So essentially what our project is doing is trying this other way, or like trying one of the other ways that we can do networks. And only reality can tell us whether it's any good. So that's where you come in. And that's why I'm telling you about it. So that you can try it out and see whether it works better or worse. So our specific idea is called SCION. And it is designed for route control, failure isolation, and explicit trust information for end-to-end communication. So what does that mean? End-to-end is the first interesting part. That means your end host, so your laptop, can make the decisions relevant for how the network delivers your packets. It also has the option to make decisions about trust. So like nowadays your ISP has the routes from somewhere and they work somehow and you have no idea about that. While in our system your end host knows about where this information comes from and can decide to trust it or not. And there's also a lot more emphasis on failure isolation. So back in the days when the Internet was designed, it wasn't really meant as a highly reliable or it was meant as a highly reliable system. But know that this scale and know that it's a lot more difficult to scale failure resilience when things get several orders of magnitude larger than what you expected. So today convergence in today's Internet can take a while and in our system hopefully this is better. We think, it remains to be seen in reality whether it's actually true. So and of course the interesting part here is route control. And that's kind of the route control aspect is the one where I am going to remove my salesman hat and I'm going to be like, yeah, now our system is nice and does things and blah and stuff but the route control is a general concept that applies not only to our system but to general thinking about how you design networks and that's why it's interesting and that's why we are bringing our thing not to sell you our thing and to tell you we have fixed the Internet once and for all but to tell you, hey, this concept exists, give it a try, figure out whether it suits your application. So that's what we're doing. So let me give a quick overview of why these things are interesting. So what does it mean to have route control? It means that if you have two hosts somewhere in the Internet, you can make some decisions about how your packet gets from here to there. So for example, in today's Internet there is this issue with if you're sending a packet that's on the picture upright, if you're sending a packet from Europe to the like to Southeast Asia or Middle East or one of those, usually the route that your packet takes is the long way around. It goes through the US, which means you have pretty high latency because you can't beat speed of light. And this is because it's cheaper for the ISP to put the packet to let the packet go the long way rather than to go the shorter way but pay more per packet because that route is more expensive. So today you don't have a choice and you just are stuck with the decision that your ISP made for you but in our system you can make the decision yourself. So for example, if you're having, I don't know, an important video call or something like that, you can choose yourself to use the lower latency path. So that's interesting. Another use case is that, for example, if you're sharing a lot of data, I don't know, you're doing some research, you have medical images or you have particle physics in CERN, that's a lot of data. And nowadays you can only stuff as much data into the pipe as the pipe is wide. But this is kind of wasteful because many places have backup links or have multiple connections that they can use for failover but they cannot use it to transmit more data at a time. So if your university has a 10 gigabit connection and a 10 gigabit backup connection with a normal internet, you only get to have 10 gigabit even though you're paying for 20. But with our system you can send some data through the first, some data through the second and that way you get a lot higher bandwidth and that way that enables you to add the same cost, have more interesting or like more bandwidth intensive applications. And another interesting feature of this path control is that, for example, let's say you're doing something very critical, like you need high reliability from the network, for example, you're operating a drone remotely or something like that, then it's very interesting for you to have control over your network instead of having to wait for the network to make your decisions. So let's say you're operating your robot, you're using this violet path to send the packets and then at some point something goes wrong, one of the nodes dies or something. In today's internet you have to wait for the network to start rerouting your packets.  You have switched within milliseconds and you have a working path despite failures in the network. So those are the interesting use cases. And now how does this work? So that's in general. And how does it work specifically in Scion in our architecture? So as mentioned, your end host has a choice about the path, but it cannot make it up completely arbitrarily. So it is not source routing. Source routing has many issues. In this case, the host chooses from a given set of options. So it's kind of a middle ground which tries to avoid the common pitfalls with source routing, but also it gives you the end user a lot more control than in today's internet. And then the advantage of this, so what we do is your end host chooses the path and then it puts the path onto the packet. So it has a stack of hops in the packet header. Now this kind of sounds bad at first sight because that means your packet headers get large and it is kind of annoying, especially if you're trying to do it high performance. That is annoying, but the nice thing is that the routers can then just follow the instructions that are written on the packet. So the routers don't have to have these huge routing tables. We already see it in today's world. The routing tables are like 10,000 entries or I don't know, you're running out of memory, you're paying a lot of money for routers with a lot of fast memory. In our system, there are no routing tables. You just have it on the packets. This packet wants to go to that hop next. So you don't have to think about it. You don't have to store that in memory on the routers. But in order to make sure that the packets only contain the allowed paths, as mentioned before, this is not source routing. So we have to make sure that the path is allowed that is from the set of allowed paths. So what we do is we have a very fast cryptographic Mac on every hop field, which verifies that this path came from the ISP who has the private key. You as the user, you don't have it. Not private keys, it's symmetric for performance reasons. But the ISP has the key, you don't have it. You cannot create arbitrary paths. You can only use the things given to you by the ISP so that tries to find the balance between giving you choice but also not letting you completely break your ISP by making up random paths or loops or I don't know, something like that. So yeah, that's for the paths. Now there's another interesting concept that's also interesting from the security perspective, but it also helps with scaling. And that is the concept of isolation domains. So an isolation domain is kind of a sovereign part of the internet. So you would still be connected to the other isolation domains, but the other isolation domains cannot affect you in malicious ways. So an example could be that a country is an isolation domain. So now your country has control over the routing, control over the route of trust for HTTPS certificates for DNS, all of that. And some, I don't know, China or the US or something cannot affect these things from the outside. They would first kind of need to infiltrate your isolation domain. And without that step, they are unable to influence your routing. They are unable to cause the issue, I mentioned at the beginning where packets go through China when they shouldn't. So that's why the isolation domains are interesting. And from this design, from the combination of isolation domains and path control, you get some pretty nice properties. So one thing is the scalability. As mentioned, the routers don't have to have these huge routing tables. They are stateless, so they can be potentially more efficient. And you also get the hierarchical routing thanks to the isolation domains, because you first do things inside the isolation domain, then you figure out the route between, then you do the routing inside the destination isolation domain. So even if you're going through the whole world, there isn't as much overhead as with one global flat internet structure. And of course you have native multipath, because if you are writing the path of the packet on the header, then nothing stops you from writing different paths on different packets. So you just get multipath kind of for free. And then you have the fault tolerance. So there's the usual things in the control plane, things notice when routers go down and so on. But the interesting part is the do-it-yourself aspect, where if you notice this path isn't working, you can immediately, within a millisecond or whatever, switch to a different path and you don't have to wait for the network at all. It's instant. So. Okay, so now there'll be demo part. It sounded so academic guys, you have to admit. Let's do something real now. So we've heard about few features, some of them nicer, some of them maybe less, wherever you judge it. So what I'm going to show you in the demo, I tested it around 50 times before this talk, it will fame, I'm pretty sure. So I'm going to show you a few scenarios. Namely, one of them will be, I will have a traffic going through Bern to South, from Bern in Switzerland to South Korea. You will see by default, we will have a traffic engineer to go through China. However, we do not like our traffic going through China. So we'll create a policy which will be enforcing on the protocol level. So on the internet itself, what we designed, that the traffic cannot ever enter the China and we'll see how it's enforced. I will not be going into details. We can talk about this later, but you will see that it just works. The second scenario, we are talking about this very fast rerouting in case something breaks. I don't know how many people in here in the room are familiar with BGP, BFD, and this kind of concepts? Not much. Okay, so for people who know this, you probably know this stuff is bad. For people who do not know this, do not go into this direction, you don't want to know this. And the first scenario I will show you, something very useful from the traffic engineering perspective, and here we go a bit into money and this kind of scenarios. So let's imagine we want to have a traffic coming from Europe to Australia. So the very first question we have, do we want to go through Asia or through US? Wherever, from a distance perspective, it should be something similar. We shouldn't really care. But if we go into money perspective into business, we will see that this is much, much cheaper for our traffic to go from Europe to US and then to Australia instead of going through Asia and jumping to Australia. However, if someone is doing some maths at this moment that starts calculating distance, maybe speed of light even, you will see that this path, which I'm telling you is cheaper, is twice as slow in terms of latency, in terms of how long does the light needs to go over the fiber from one place to another, going through the globe on the other way, which means depends whether we need something to go fast or we need something to go cheap. We want a different solution. And of course, you as an end user currently with your laptop going to google.com or whatever, you cannot make this choice. It's imposed by your ISP, by some bunch of people somewhere sitting and looking through dollars at the end of Friday every week, but it's not your choice. Let's see how we can do it. I hope it will work. Okay, so the resolution of the screen is not super big. So let me tell you briefly what we have. So you can see we have some points on the map. So these are sites where we are present at the moment. So you can see we have something here in Asia. We have something in Japan, something in China, Singapore, Europe. We'll have one thing in Sydney. Sorry, I cannot show you the whole map at once, but yeah, technology in 21st century still amazes me. So the very first scenario, let me. So we are talking about the scenario of something going from Korea. Yeah, I cannot zoom out anymore. Well, okay. So something going from Korea to Bern. And we see we have some path marked and this path goes through China, then Singapore, then Europe. And you can see some statistics. So we have path with the latency 150, bandwidth three megabits per second, wherever. This is some traffic, some workload. We do not really care what's there. The only thing we care about is that it goes through China and we do not want it to do it. So let me just change the policy in, so a bit more into details. We have deployed some routers, software defined routers, because we are in the area of SDN. This is fancy nowadays, we want to do it. We will change configuration of this router in cell because this is source of our traffic. And as Camilla said before, it's the source, it's the end host sending the traffic deciding how to route it. So the source of our traffic will be explicitly stating whatever happens, do not go through China. So through this UI, I will create a traffic policy. So what I'm doing now, everything can be done through command line, just a bunch of JSON files, but of course, for the purpose of demo, especially at this hour, when we all just want to go home, beer, whatever. It's much nicer to do this through the UI, just click, click, click, some fancy stuff appears on the map, rather than just some bunch of guys writing JSONs in the terminal. So I'll create a path policy and I will name it avoid China, because this is what we want to do. And I will configure ACL with the default policy allow. However, I will select the, and now I'm missing the map, that's lovely. Yes, I should be able to do control minus on the whole window, perfect. Yes, that's exactly. Can someone from the back of the room tell me whether it's okay or should I make it bigger? Like this, better? Yes, but now I don't see the map. So you have to trust me. I will click what I want to click and you believe me, I'm doing what I'm saying. So I'm selecting this router in China and now it appeared here, selected A as Hong Kong Telecom. I do not like these guys, I will not give them my traffic. So now we can see on the left hand side, this traffic will be denied. Let me save my policy. Let me save it once again. And now on this router, so in the cell, I will modify the default policy to use the path which I just defined, which means avoid China. I will save it and if I click save enough times, here you can see just if someone is interested, this is a diff in JSON which happens in the background because this is just a bunch of files somewhere on the server running. I will deploy the config. I would click show logged but I'm afraid I will see some bad stuff there so I won't show you this. I just hope it deployed properly. So I will go back to the map and yes, we have the same traffic and as you can see, it's not going through China. We are avoiding this one dude here who's stealing our traffic and selling it to someone. So okay, so the first scenario is covered. What I'm going to do now, I will revert this change because I will need this Chinese guy later on. In the next step, just to give you some heads up, I will take down this Chinese router in order to show you the fast rerouting. So we go back again, we allow this traffic and we should see the path as previously. Let me zoom out, this is a cool feature. Yes, if some people do not see the colors, this yellowish goes back through China so everything happened correctly. So Camilla was saying about this scenario of fast rerouting, I beached a bit about BGPBFD so let me show you now what happens. I will log in manual through the console to this router in China, I will take it down, we will see the traffic immediately goes around, avoid this node and we'll see also on the map some fancy stuff will appear. I hope my terminal remembers what I wanted to do and I hope internet is fast enough. I don't remember the numbers so I don't know if I'm taking the correct one down now but well, let's see, live demos, that's that. So Docker Compose because we are running all this stuff in containers so we have containers for routers, for different services, for selecting paths, certificates and so on. I don't want to go into detail so I will just take down everything. So Docker Compose down, it's my perfect. Yeah, that's my favorite stuff. I just, yeah, I like destroying stuff. Yes, and it's the correct guy. So we can see immediately stuff, something started happening, we see some red signs. For people who are going to read us later, it means that the beacons, so the small packets which routers send to each other to announce paths in the state of the network, they stopped flowing. So we have so-called revocations which tell us, no, this path is not available anymore. Please do not use it. Okay, let's keep this guy like this. I do not care about him anymore. I will show you the last scenario because we are, yes, everyone wants to go from this room already, I think, so I will show you the scenario of traffic going from burn, can I click burn? Yes, no, I cannot. Now I can. Okay, so we have the traffic going to Australia. We have five megabits per second of traffic and it goes with latency around 140. So this is the best we can get going in this direction. It goes to Singapore, Australia. But this is too expensive. If you've seen the bill for this traffic, it's enormous. So I will change the policy in burn. Here I pre-created some stuff because it would be boring to show you all of this. So I created traffic class high prior and default. And the high prior means this is the traffic which I want to go fast. It doesn't matter the price and default. It can be slower. People do not pay. It's, you know, best effort, no SLA, let them do it. I will create a path policy then. Low latency, go through Asia. And I think I'm selecting everything properly. Okay, I have this policy already created.  So I'll create a traffic policy, ABCD, whatever. Let's name it like this. For the high priority traffic, and the high priority traffic will be going East through Singapore. This will be my policy. And the second policy will be wherever for any traffic. You see it was like logical truth. So this is always, always true. It will be going West. And if I click save enough times and everything deployed correctly, which I hope because I sacrificed a lot for this demo to work, we should see exactly what we want to see. Oh, yes. Okay, colors are playing tricks with us now. But you have to believe me that we have now. It's the orange and the lighter orange. Yes. So we have this traffic with four megabits going with the high latency path and the very low bandwidth traffic with the low latency going by the other. So if I zoom out, you can see that the path which was the fastest before it stays. And we have some traffic going around. So it goes to Spain, US, then probably Japan. If I can read maps correctly, geography is not my best side, and then Australia. So this is what we have. And now the bill will be much, much cheaper customer will be happy. So yes, so this was for this demo. Okay, so now let's go into something more practical because we just show you some stuff on summer, some UI. But maybe, yeah, what happens, what happens next? Do we really use it? Like this dude from the internet, he wrote we have like 12 users. No, this is not true. So in fact, we have two separate deployments. One is driven by the Anapaya, so I told you, spin-off of ETH in Zurich. This is a production network. And this production network is already used by few entities. One of them is Swiss National Bank. They have deployed Scion already two years ago and they use it for hike. From their perspective, this is a mission-critical traffic. What they are now deploying is a project in Switzerland. For people maybe, okay, so I will say something as inter-bank clearance. This means different banks in the same country in order to send money from one to the other need to use a very specific protocol.  This is so difficult. I was working in the past in one company which had to go through the audit of this, whether the systems are really compliant. This is crazy. You do not want to do this ever. So yes, they decided to use Scion for this deployment because they feel like this serves the purpose. Another use case, this is once again Switzerland and the government. We have some of Swiss embassies around the world. I can recall now from my mind, Berlin and South Korea, they are also using Scion in order to connect their premises offshore with the headquarters in Bern, Switzerland. Also what we are doing in a smaller scale, so national, we are now in a process of deploying Scion to connect all the universities in Switzerland. So the high availability, high bandwidth and all these nice features will be available for different people working in different scientific entities in Switzerland. And as you can see, this is a BGP-free. So yes, we have this nice sticker, Camillad wrote it like a few hours ago. This network is not using BGP, which means you are covered by definition from all these problems which were described at the beginning of the presentation. So we are not running on top of the current internet. Yes, it's not running on the current internet. This is going back to this dude from N-something, yes. He does it every year, he's just trashing all the talks on the main track. And then for people who want to try, who want to do some experiments, perform some research, maybe you want to discover some new features, we have Scion Lab Research Network. This is network consisting of around 60 scientific institutes in four continents at the moment. We have widely deployed Scion Lab backbone, which is managed by people at ETH and then in different countries, continents, we have created for them their own isolation domain. They can join at any point in time, they can try, they can do research. I think the biggest, not really customer, but the biggest user right now are some people in Korea. They are using Scion as Scion Lab extensively. They are doing really nice research. They are writing papers like crazy. They are delivering results and they say Scion Lab really helps them. I think some guys in Netherlands, I don't remember the name. The SIDN, maybe that means something to people. Yeah, whatever. Some guys in Netherlands, they are using this for more production research. I think they are trying to do something with P4 and programming FPGAs, if this says something to someone. So this network is big and this is something you can join wherever you want and just play around, just discover some stuff. Yeah. And Camilla is going to tell you some fun facts about how to run this. Yeah, so that's all very nice. What we've told you, but how do you yourself sit down tonight at 1 a.m. after you've done your drinking and deploy this on your home router? So that's my home router. The most important feature, of course, on any home router is ICE. And this is a small passively cooled computer that can run Scion to test it out. So it runs on any PC. The sources for our reference implementation are on GitHub and you can deploy it on a PC or in a VM to try it out quite easily. What's interesting is that it is possible to use Scion also for IP traffic by letting it go through a gateway. So of course, if you want your application to make full use of the offensive features, your application needs to be able to select the path itself so it has to be Scion aware. But if you don't have a Scion aware application, but I don't know, you have your video calls or you have your not torrent streaming nowadays, you can use the Scion IP gateway to make different choices about IP traffic and define policies for your IP traffic to go through different paths in the Scion network. So kind of use it as an overlay. And it is also possible to deploy Scion and IP on the same networks. Then it would kind of have Scion on top of IP. And then if you use the Scion IP gateway, then you have IP on top of Scion on top of IP. But it kind of makes sense because you still have the path control policies. So that means you don't have to have a dedicated network and you don't have to write all shiny new applications. But you can literally start using it without all that extra work. But in case you do want to write an application, in case you do want to make use of the offensive features, this is what it looks like in a hello world fashion. So it's pretty similar to normal networking, to IP-based networking. The interesting thing is you have to get the paths to your destination. You get, I don't know, three paths. And then you can choose it somehow, depending on what your needs are. You may try all the paths, find out which one is fastest, or find out which one is cheapest, or I don't know. And then you do a connect, but you just give it the selected path as well. Right now you have to give it one path and if you want to use multi-path, you open different connections. But we are working on a native default multi-path thing, but that's in the works. Yeah. And we are very curious about people coming up with ideas of what you can do with a pathway or network like this. You could have some interesting use cases for path control. I don't know, the video calls is an obvious example. Maybe online games might be interesting, some streaming, I don't know, things. There's lots of things about efficiently using multi-path because there are issues with how do you actually make use of the fact that you have multiple paths, improve the network utilization. There are a bunch of security implications that might be interesting to explore. And from the ISP viewpoint, there's the question of, okay, your users are choosing paths now. How do we do traffic engineering? How do we define path policies that make sense both for our users and for us? So we are curious to see what people do. Sorry, we are running out of time, so I won't be showing you any more demos. I will just tell you what I wanted to show you. So in order to join the ScionLab Research Network, what do you provide you? We have a very simple web interface in which you can register. So yeah, you just create an account. We provide you vagrant files, so you can just run Scion inside a VM. It will connect to ScionLab transparently from you. So effectively, what you need to do, you go to the website, you register. We do not need any data from you, just email address so we know the person. So we know that there is someone behind, it's not just a bunch of bots from Pakistan, China, India, wherever you name it. You register that, yes, I want to download a vagrant file to join ScionLab.   To run some top of Ubuntu, we do not do any fancy stuff inside. So yeah, just a bunch of scripts which we provide to you in order to make it very simple. Of course, if you want some more advanced scenario, you can even build it from code because this is on GitHub, the links are later. So yeah, do as you want. We provide Debian packages. I don't know. I think RPMs are not available. I built them a few times, but I never published. So this is something yet to go. But Debian packages ready to go, vagrant file built from source, these are the options you can do. So yes, so we have some links. Go through them later. So we will upload the slides. I think they should be up. So Scion Architecture, if you want to know something more about the architecture itself, Scion Lab as I described. Ana Payanet, if you are ever interested in the production network, Scion Protocion is the protocol itself. The reference implementation for all the stuff you've seen there. And NetSec ETH Scion Apps, you have some examples you've seen on the slide. Hello world, because of course we do, we won't be pasting the source code. But if you want to see some applications already in place, this is in the repo Scion Apps. And yes, if you want to keep in touch with us, please feel free. There is a lot of ways to contact us. Also feel free to catch up with us later. And I think we have 10 minutes for questions. So let's go. Thank you. Mateusz Kamilla, for interesting. So I guess you can share my microphone, yeah, okay. So if this allows users to determine which route they go through the internet with, does that involve a completely different thing at internet backbone level? And does it change the way that ISP billing would work? Yeah, so this is kind of interesting on the larger scale of things.  And yeah, it's kind of an interesting question of why the ISPs should care. And I think it's like, if you as the end users want it, the ISPs will then have an incentive to start providing it. Yeah, so at some of this, we already have ISPs in Switzerland and I think we are working with one in Korea to start providing this for end users. So you don't need to build anything on top if you are based in Switzerland, you can just in some time from now call Swisscom, tell them I want on top of the internet which I have at home from the network outlet, I want to have Sion natively there. And I think they are already working on a commercial offer for this. I don't know for residential customers if it's going to be available anytime soon, but for businesses, this is something you can already talk with ISPs and they will be very happy to quote you on this.  Thank you for your presentation. I'm just wondering if my ISP changes the available routes to something that is not compatible with the policies that I have set up, then I'm just out of luck or what happens then? Yeah, so it can happen that there are no paths that are compatible with your policy because the ISP makes the decision of what is available and you rockily make the decision of what you want. So yeah, if it's incompatible, you are sad, you get no paths and you have to talk to your ISP to make them change their policy or you change your policy. But it's still, we think an improvement over the current internet because at least you know if they're doing something you don't like and you can make yourself the decision of okay, will I not be so picky or will I try to make them do what I want, right? Hello, thank you for the presentation. I have a question about the protocol itself. So you defined it as a priori definition of a path. So what I understand, you design your path in the same way as Tor does it. And what you do is you always have one path. So you are exposed to a problem, the same problem which cities have with roads because people tend to choose the same roads over and over again. So this way you lure people into thinking that they are designing something better by themselves which actually is, they actually perform what is performed currently by routers of ISP. So first of all, people are becoming routers themselves, well business people. And second of all, fixed paths force you to send your configuration with the packet. So for example, if I would have five blacklist routers, yes, I can use a bloom filter and I could zip my MAC addresses into the packet that it would not be very big. But if I would have something more fancy like ignore these routers, profile these ones and not go through here and so on, then you suddenly can send megabytes of additional data just because you forgot, yeah. So it's a, it's a- So there's the second part. This is not really true. Maybe we did not explain it fully but this whole configuration, you do not attach it to the packet because this is not really source routing what you are doing. You just as a client, you select the path. So you do not send the packet saying to the next router on the way, I want to avoid China. That's not what happens. The decision you want to avoid China happens at the moment when you send the packet from your machine, which means no router on the way knows that you have a policy avoid China. The only thing they see is that you've made a choice of arbitrary routers on the way. They do not know what incentive do you have behind this.  You are not telling router to make any kind of decision. Router is not decisive in this path because you've made a selection when you constructed your packet. Of course, if something happens and the path is not available, your packet will not make it because router will not be allowed to make the change. As for the first part of the question, which was like, yeah, okay, but people will kind of do the default routes that they are doing anyway and just think they have the choice. We think that it is an interesting question to design the paths in a way that makes better use of the internet than it is today. So for example, if you give the users three paths and all of them go to the first path, then that path will suddenly be congested and will have a higher latency. So it is actually in the user's own self-interest to try to kind of load balance things, right? But then it is up to us, the programmers, to design good algorithms that are able to do this without introducing oscillations and stuff, but there can be options which are where it is useful for the user from the selfish perspective to do the right thing for the network. Yeah, and the problem with this design is that I don't know which routers will be down in the future. So that's what I care. Thanks. Hi, I was just wondering, let's say I'm a business and I want to start using Scion and I have an ISP and they're prepared to start offering Scion. In practice at the moment, could an ISP just start offering it to their customers or would they be waiting on a number of other organizations to all start offering it for the, to communicate with the other side of the world? So this really depends on the case. So I'm not sure how much I can tell you without paying debt till end of my life and getting fired as soon as I leave the building, but I believe we already have at least one ISP who prepared a commercial offer to a customer to run native Scion. So this answers partially the question. However, I believe if I as a private customer, Mateusz Kowalski, living XYZ, if I went to another ISP and I told them, hey guys, can you give me native Scion connection to my home? They would tell me, yeah, sure, but 100 million Swiss francs and maybe in 10 years. So this is a very tricky question, but of course as with any business, it depends on your size, it depends who you are in the country, what power do you have? We are somehow in Switzerland in this comfortable situation that we are doing a lot of government projects. So if government decides that we are running this project for banks now, banks have to comply. So some businesses, they do not have a choice, they will just join the party because they are told to do so. But I agree this is very comfortable situation as a private customer, probably it will take you much more effort. I think maybe the question was also about, okay, I want to send Scion traffic from here to there, but it doesn't work if only my ISP says, okay, we'll do Scion for you, but it has to be every, the whole path must be Scion network, right? So it's difficult to do it globally right now because there aren't ASPs in many countries in the world that offer this, but that's again something that we are hoping to fix and also Scion lab research network is on four continents. So if the research network is enough for you, then that's kind of an entity that already does this globally. Yeah, so this is also kind of, yeah, let me get 30 seconds of this. This is what makes it different from standard SD1 and at least lines and MPLS because you do not need to have a dedicated line between every branch of your business. We are building a fabric so we can just join the network fabric and we are building backbone for you, which means it's cheaper because we'll provide you backbone, you just need to provide the end hope. The last hope to both your premises, but you will be consuming the backbone which is provided. A question about how it looks on the wire. So does it mean that every package, every packet has embedded preferred route? Where is this route placed? Is it like IP extension header or like some kind of encapsulation on top of IP or is it UDP or what is it? Yeah, so we have had like people thought about this and figured out that the best way to actually have all of these features and not end up with something completely horrible is actually to design a completely new header. So we have a custom header. We kind of need this because of also the cryptographic checks that we do. So we put the, we have our own header and we have a reference implementation and we have given some thought to whether this header is doable in hardware and we have made some changes to the format of the header so that it is possible to do it at high performance in hardware. But yeah, it's a custom header. Okay, last question now, okay. Do you under multicast routing? Multicast? Do you under only unicast or also multicast routing? Oh, multicast. We, there has been some thought given to multicast but I think it's probably too early because we are still like flashing out the details of that. So we don't have anything publishable right now but there is some research ongoing at our university. Yeah, if I remember correctly there was one project working on multicast. It never made it to the reference implementation but it wasn't only technical choice as far as I remember there was a lot of discussions whether we really want to provide multicast. Like what is the real use case of multicast? Why people want to do it? And if they really want maybe they are doing something wrong because this is kind of a way of thinking we do not want to take the existing protocols and implement exactly the same features because then it does bunch of guys redoing work reinventing the wheel. We want to go back to the beginning and ask what is really the feature you want and why do you want it? Only after this we will provide you a set of stuff that will fulfill your purpose but saying kind of things like I want multicast because I have multicast in IPv4 right now it's, yeah, I do not think people really want to go like this and fight with this kind of arguments. Okay, thank you Mateusz. Thank you Camilla for your enthusiastic and interesting presentation. Thank you audience for the interest.


The traditional way of recognizing good work on Wikipedia is by awarding barn stars. In wiki communities, barn raising, when a community actively comes together for some specific goal, is a central value, so much so that it's often synonymous with the creation of a wiki's community. And so the barn star, a kind of traditional decoration that adorns a barn, is a symbol of appreciation for valuable contributions to a wiki. We give barn stars to each other to say, thanks for all your hard work. You've really made Wikipedia better. It's easy to give someone a barn star using wiki love. Just go to their user page and then click the heart icon. This user, after a little false start, kept at it and created a really interesting article on an ecology concept. And it ended up getting nominated to appear on Wikipedia's main page in the Did You Know section. So I'm going to give them a barn star to say thanks and well done. I select barn star from the wiki love menu and I'll stick with the original barn star. There are all kinds of special barn stars for different kinds of work. And then I'll put in my message and press preview and then press send wiki love. And now a new section will appear at the bottom of their user talk page. With the barn star I just awarded. If you see good work on Wikipedia, don't be shy. Give a barn star.


five times less cheaper than what my actual four-year college in my area was gonna charge me. Say what? Say what? I am back with another video for you guys. Okay, so you guys, if you haven't already done so please go ahead right now and subscribe to this channel and follow me on Instagram, edit down in the PA. But today we are gonna be talking about taking prerequisite courses at a community college versus a four-year college.  Do I have to do it at a four-year college? And I mean I can only speak for myself okay you guys. So for me what I did was I did my research. I looked at the different schools. I looked to see if it was specific and saying hey your prerequisites need to be completed at a four-year college. Or you know no they could be completed anywhere or it didn't specify at all. So with respect to all of that I looked at the schools. I went to their different websites that I was interested in and I did my research and I saw that most schools don't really specify. The only thing that they really specify on is that you had to have completed your bachelor's degree at a four-year institution obviously um and a accredited one. So you needed to have a bachelor's degree. And so if you did that in like overseas or internationally there's a whole process going through that to make sure that you know your classes are verified and there's like a matching and all this stuff done to see that yes it does meet the specific requirements. But other than that the schools that I was applying to weren't specific about that. So of course why would I sit up here just recently you know graduating from a four-year college to now go and retake prerequisites of course is that I already did.    At another four-year college that's costing me like five plus hundred dollars a credit. Say what? And I'm taking these courses that are four credit courses with labs. That just makes no sense. You know it's a waste of money. It's gonna be like ridiculously expensive already as it is applying to PA school. You know through the whole CASA system and sending off your applications. That's an expensive process and that's not even adding any supplemental application payments that you may have to pay. And then if you do get accepted or when you do get accepted right let's you know speak life into this. So when you do get accepted then sitting up here and putting out like seat deposits and then putting out rent deposits and all these other things. So you have to really be mindful of that. You have to take all that into consideration. Therefore is it beneficial for you to take it out of four year college or take it out of community college? I mean for me when I took my microbiology at the community college it wasn't any less difficult than taking it at my four-year college. The only difference was that I was already familiar with the material. So it made it a little bit easier for me because that was part of my major. But at the same time I was still learning the same material. I was still going through the same process.  I was having a test almost every week. So therefore at the end of the day I needed to make sure that I was well versed in the material. And so for me I understand the I guess the quam that people may have. It's like oh it's a community college. So you know it's not up to the level as a four-year institution and you're not learning at the same level. But you are depending on the hour courses and the credit hour courses that you're taking. So if you're taking a four credit microbiology course at a community college more than likely it's going to be very very very similar to the one that you're taking at a four-year college. It's just going to be if you do it over the summer obviously it's going to be very condensed. But if you're taking it throughout the school year I really don't see what the issue would be. So definitely my suggestion is look at the schools that you're applying to. Definitely do your research on them. Make sure that they will accept those credits and those courses. I know all the schools that I applied to sure did. But I made sure and I asked those questions before I even applied because I didn't want to waste my money in applying to a school that would not accept the credits that I've already done. Especially since I already had a bachelor's degree with those credits and those courses already accounted for. So maybe that made the difference. I don't know but you definitely have to make sure that you understand that for yourself so that you're not making a decision that might actually put you at a disadvantage because they want all of your prerequisites done at a four-year college. However from my understanding and from my experience and again I'm only speaking from my experience that was not an issue. So by all means go to your community college that you're in county for and sign up for those less expensive courses. I literally paid like $165 per credit for these four credit courses and three credit courses and labs that I had to do over the summer because it was so much cheaper. I mean it was five times less cheaper than what my actual four-year college in my area was going to charge me. It's just a better option especially when you're trying to apply to PA school in the very near future. Saving money anywhere you possibly can is essential. Okay so I hope this helps you guys. I hope it answers a lot of your questions. Obviously I always end up saying do your research because honestly that is what it's all about. You have to go and make sure that everything is catered to you. So definitely make sure that all the schools that you're looking at will accept all of the things that you have to offer. But other than that you know just go ahead and make the decision that's best for you. Thank you guys so much for watching and again joining me on this journey. Please continue to just follow this journey with me. See how I make it through clinical year and I'll be keeping you guys posted on all of that. If you have any questions or comments go ahead right now. Leave them in the comment section below and if you haven't already done so go ahead and follow me on Instagram at adana.ca. Thank you guys so much for watching. I will talk to you guys next time. Bye!


Okay, let's go ahead and get started. So first off, please add yourself to the attendees list on the agenda. And so we have a few recurring calls that are on. So we have the NSM documents call. We have on hiatus at the moment, we have a use case call and also on hiatus we have a document call. So we will resume those as necessary. We also participate in the CSF, CNCF telecom user group, which occurs every first and third Monday at 8 a.m. Pacific time. The next call I believe should be this coming Monday. That one was canceled if we do the Labor Day. So the one after that will be on the third Monday. Does anyone here know whether or not that particular call is going to occur on Asia time or are we still going to do the 8 a.m. Pacific time? The call on the third Monday in September, September 16th will be the first Asia time call. So instead of being 8 a.m. Pacific time, it'll actually be 4 a.m. Pacific time. So in that scenario, 4 a.m. Pacific time for September 16th. All right, so we have a few major events coming up. We have ONS Europe in Antwerp where we have four talks accepted. There is a telecom user group meetup and the CNF test pet tutorial. We have the open source summit coming up which we had a talk accepted on the introduction of NSM by Ivana and Radislav. We have KubeCon and ConLativeCon coming up. Call for proposals is still being decided upon. We have, but we do have NSMCon. So we definitely request everyone here join us at NSMCon if you'll be in the area. And simultaneously, we're also looking for proposals for talks at the NSMCon as well. So if you have something you would love to talk about that is NSM related, definitely bring it up here. We also have a Kubernetes forum which is gonna occur in Seoul and Sydney. So if anyone would like to talk at either one of them, the call for proposal closes on Friday, September 6th. So Lucina, you have the floor. Hi, thanks. Still making good progress. Increasing across the board on the NServiceMesh Twitter account since last week, 17 more followers and followed 15 more accounts and tweeted and retweeted 25 times. This week to follow up from last week, the VMware open source teams, part two of mess of meshes, breaking down ServiceMesh ecosystem, including Network ServiceMesh was reposted from 168 different accounts on Twitter. And that's kind of slowed down, but last Tuesday through, I think last Thursday, 160 reposts of that blog post. So congratulations, Nikolai, for your successful post. People really liked it. I reposted it twice from our account. I could have reposted it 160 times, but that would be spammy, so I just posted it twice. And I also posted a reminder of today's working group, the call for sponsors for Network ServiceMeshCon at KubeCon North America. And I pinned a new tweet for Network ServiceMeshCon onto the top of the Twitter profile page. And this week's plan, I'll send a 24 hour reminder for our bi-weekly Network ServiceMesh call on Tuesday, the September 3rd, the earlier time. I'll continue announcing the open networking summit, open source summit and KubeCon talks, as well as searching for any mentions and reposting. I'll announce the next release when available. And I did have some questions this week and ServiceMesh was tagged in a post. And I read through their GitHub repo to see if they had forked or mentioned Network ServiceMesh as they tagged and thanked Network ServiceMesh in their product release. But before taking any action, I wanted to confirm that they are in fact an end user. And if so, that would be awesome. I was just a little bit confused how Network ServiceMesh fit into this product release. I think it's an error. Like, it probably has nothing to do with what we do. Oh, that's... For more wireless mesh that they're developing. I don't know why and ServiceMesh makes sense for them. Very good. That was my hunch as well, that it didn't quite add up. Well, we got a free mention. Yeah. I was wondering about other shareable milestones as well. We were recently tagged in a post from, I believe it was Mechery. And they were like, if you like, Winkardy and Istio and Envoy Proxy and Network ServiceMesh then give us a star as they were looking for more stars on their GitHub repo to be included in the CNCF landscape. I believe that non-CNCF hosted projects must have 300 stars on their GitHub repo in order to qualify to be displayed. And so they were looking for more stars. And that just led a question. We have 254 stars in our repo. Do we have any goals to reach any number of stars by any certain day? If so, I can request otherwise. May not request. Wow. Yeah, that's it.  No, I was looking at what Linkardy stars are and what number of stars do they get when it's 5,000. Yeah. Okay. Yeah, that's gonna be one of the interesting things about it because in the long run, I suspect that NSM is going to be more like, I guess you would say like the thing that helps things run, but not necessarily the thing on the front. And so like, if you go see a concert, everyone always cheers for the lead front guy, but they never look at the sound guy behind them. It makes the sound sound really great. And so, it takes the whole team in order to make it work. So I think we could aim for increasing the number of stars. And I do think that that is gonna be a good idea in the long run, but it definitely hasn't been a priority up to now. But we should definitely consider it because increasing the number of stars does increase when people look at GitHub, it does, and they look at like, what projects should I look at? It does help increase that aspect. And as noisy as a metric it is, people sometimes will look at stars to try to work at it. Is this a real project or not? So it may make sense to do a star drive in the long run. Okay, sounds good. Maybe I'll postpone that until the next release. And maybe once we have more end users or more folks including Network Service Mesh with their project, then I'll request, are you using Network Service Mesh for your project? Give us a star. Yeah, I think that'd be a great idea. And just, we wanna be at a point where like, right now you can download and you can run an NSM. The steps to do it are still not as trivial as we want, but we're getting down to the point where you can run Helm install and it just installs it. And so a little bit more work and Nick and I can talk to this. But once we're getting close to a release candidate or production, we get people to start playing around with it, then I think that'd be the perfect time. And that way the people with their first new reaction with it is, if they decide to try it is, hey, this is cool rather than, hey, this looks cool, but it doesn't work. And so once we're close to production, I think that'd be a fantastic time to do that. Awesome, thank you so much for the feedback. Cool, thank you for bringing it up. Absolutely, are there any other shareable milestones we've got stars waiting on hold? We've got the 1,000 commits, which we had passed. So next will be 2,000 commits. We're almost to 400 followers on Twitter. I think we need fewer than 10. Are there any other milestones that you'd like to try to reach? Or share once we do reach? Well, I think that we mentioned whatever is important, at least from my point of view. I mean, the next immediate things that are coming are all these events that we are preparing for and of course the race, so other than that. So, yeah, I think, I think in the same milestone or the same thing at this point as well, there's nothing additional to add in. You've been doing a really great job of keeping track of the existing stuff. So I think we're good. Sounds good, thank you so much. I'll keep on keeping on and that concludes my update. Well, so, Ed is not here today because he's not feeling particularly well. So he's taking a short break. But what I think we can do as well is, depending on who we have on the call, we can ask for a few updates. And so I'll ask for, so the first thing is CircleCI has had some instability. Do we have anyone here who has been focusing on CircleCI in order to increase the stability? Yeah, we're working on our on-exert side on a few issues already. We have a couple of requests on a GitHub. So I hope we will resolve in a few days. Yeah, but these are mostly just glitches in our testing not directly related to CircleCI. Yeah, yeah, yeah, yeah. It's mostly testing glitches. Some tests leave some artifacts, namespaces and so on. So we're adding some testing stuff to improve. Yeah, we have merged some amazing features lately. So of course there are regulations here and there, but we'll be fixed, I believe. Cool. So in terms of stuff that's in progress, do we have any recent updates on DNS? So I saw PR1419 has been merged, which is the sidebar container. Denise, Denise is here. Yes, hello. By my side, I've provided third part of DNS. It's a final part and it's provided, but I have red built and I'll make it ready for review as soon as I can. That's all. Fantastic, thank you. And so on the security aspect, so we're looking at bringing in Spiffy and Spire. So for those who are unfamiliar with Spiffy and Spire, so Spiffy is a specification of how to establish identity of workloads. And Spire is a implementation of that. If you have used Istio to do workload identity, you are using Spiffy, but you use Citadel instead of Spire in that scenario. The reason for using Spire is that Spire works without Istio. So Citadel is designed to work specifically only in Istio and is tightly integrated. So in terms of what we're looking to do is we're looking to use Spiffy to try to work out exactly who is the workload on the other side. So you can think of it as establishing profit, establishing providence, establishing a connection. We can use, because you get tokens on each side that are cryptographically verifiable, you can check to see who is the next person in the chain. And simultaneously, you can also check as each of the tokens gets populated as you connect through your chain, you can look at the list of tokens and work out, do I trust everyone in the chain or do I not trust everyone in the chain? So from a security perspective, it's not the only thing we need to do, but it certainly is a excellent first building block. So with that, we have the security spec. Is there anyone here who is working on that? Unfortunately, Ilya is on location for this week and he's my maintainer for this feature. So as I remember, who requests is mostly ready for review, but I think we already have some comments for it. So let's wait for Ilya to finish his work. Cool, no problem. So this is definitely one of the ones, I mean, I'm excited about all of them, but this is definitely one of the ones that I'm able to use to demonstrate NSM. So it's one of the ones that's coming, I looked at. Do we have anyone on inter-domain? Seems no. Tom is not here. Yeah, but it was merged already, so. Yeah, it's merged, but there's few issues related to stability. In inter-domain testing. So most of the last failure is caused by inter-domains. Tabillages. I was checking the testing today that we have for the inter-domain. And it looks very interesting. I'm actually inclined to somehow have some example in the other, in the examples, where we can demonstrate this with two kinds, deployments or something like that. But yeah, I'll have to figure it out. I mean, we never designed for multi-cluster when we started with the example. So obviously we'll take some refactoring of the infrastructure there. In any case, it's super cool feature. Yeah, PR total 98 was the last PR for the initial inter-domain work, and that has been merged. So we have work on increased plugability, where we're breaking out NSM manager into pieces, such as excluding prefix detection. Is anyone able to talk about that? Yeah, we'll talk a bit. We have merged a few of the pull requests and few is in some progress. And I think Denise, who's working on DNS, started to work over them and to provide some updates in few days, I suppose. So in general, the idea is to have plugins to be able to do all kind of cluster-specific stuff. At the moment, plugins support exclude prefixes and upcoming stuff will provide support for finding endpoints and some parts of inter-domain implementation will be also implemented as a plug-ins. This will give more abilities to have stable NSM manager and few plugins to give additional capabilities like inter-domain. Nice. So I assume that'll probably be an ongoing thing to where even once we get the plug-in design there, as we learn what needs to be built, then we can add more plugins. Yeah. So we have SRV-6 support. Do we have anyone who's able to talk about that? It's also John who is not here. As I know, he's already have a SRV-6 support between local clusters and most of the tests are stable. And right now he's working to add support of a SRV-6 between inter-domains. And I hope it will be merged and not merged, but pull request will be ready in a few days. So he'll be able to review for SRV-6 support. Also for SRV-6, we have few issues on the VPP agent side in case of highly healing tests. So just establishing of a SRV-6 connection is fine. We want to have a VPP agent, but if we do some updates or deleting or trying to do healing, a SRV-6 is not fully working in a VPP agent because of the errors inside the VPP agent. So we're waiting for some response from VPP agent guys. Okay, that makes sense. And so we're effectively blocked on them. Yeah. So we have the NSM forwarding from NSM manager. So we don't have any links to anything on that for spec yet. Is anyone able to talk about that? I think we need to wait for Ed for a bit. He created a few issues related to this in Bit Hub, but it's not fully. Cool. And kernel forwarding playing. So is anyone able to discuss that? So yes, whatever we have was merged already. I know that Rauslaw is working on adding metrics support. And we have been discussing with that about the next steps and all that. And there are some people from your team is going to also join this effort to update network service manager, yeah, network service manager in the data plane selection to have a better support for multiple data planes because today it's a bit opportunistic, like whatever you find first, you just select it and call. Yeah, yeah, yeah, that's pretty simple. Yeah, so depending on the order that they are registered, you can get different essentially scenarios. But I mean, it works for whatever it was designed. We have to move forward. And I know that there had been some discussions around this, some people from your team. So we have to figure out the spec and more concrete implementation in mind and move forward, that's it. Yeah, so one of the nice things on this as well is it definitely helps us work out if any VPP-isms have crept into the code base. So definitely looking forward to that. This also helps me out in a couple other efforts because I'm currently engaging a couple other companies who have data planes and it's making sure that this effort is smooth, is critical to engaging them. We have refactoring to simplify NSM as well at least in return to the SDK. Okay, in a few words, transfer to this work to me. So at the moment, we have a pull request which will reverse logic in the SDK when we define the chain of components. I'm working to stabilize it and fix linking issues. During this work, I've found few issues with open tracing. It will be separate pull request and found a bit of weird issue with our VPP example. In case of yours, it fall into infinite recursion and step by time out. So it also will be a separate pull request for a bit of fixes for this. So I think in a few days it will be ready including examples repo changes. So mostly also in separate pull request, open tracing will be much improved and it will be possible to look for all chain of operations perform it starting from client to all of end points we go across. So while we are here, Andre, I remember that last week you reported that there was a issue with the TLV debugger after we... Still issue actually. Yeah, some of the dependencies in master break the formatting package in the debugger. Not sure why. So we go and stop it to debug our tests and some of operations. Okay, is there an issue with the TLV? Is there something that we can demonstrate? Yeah, we will try, but we still not able to reproduce it on a small example. So we can show it. Really? That's interesting. It's not work with us, but it work if you just have trying to replicate it with just a small go file. So very weird stuff is always so weird. Could it be something related to Yeager? The fact that we have used Yeager all over the place? No, no, no, no, no. Seems like it's related to some formatting libraries somehow rewrite it in our go mode in case of handsome. So our challenge is trying to figure out how to fix it, but he's not too fast today. Okay. I have no details. Okay. Okay, here's what we covered all or is there something else? Maybe this linearizing local remote calls and simplification and create. Is there something about this that we want to say? Oh, okay. Yeah, it's exactly forwarding stuff it created. Yeah. Okay. That's some more complex thing that needs some more reading than talking. Yeah, and also most probably will be doable after we will move the entire MSM to SDK-like approach. Yeah. So having chains of ordering requests. Yeah. So we will be next step after SDK refactoring. Great. Actually, I like where all these things are going. This whole refactoring for that was actually initiated by Ed from what I know, but following the same development pattern all over the code is actually a good thing, I believe. Yeah. Also, as I know, we should have an issue and we will start it in your future to move the page into the plane to be used on SDK. So most of the components will follow SDK approach to having a chain of operations we need to perform. Yeah, for those who are unfamiliar with this, one of the nice side effects of this patch is that it simplifies the path for adding multiple data planes. So if you want access to a special net card or you have, maybe you're using a VPP for certain actions, but you want to use something else for performing a different action based upon the needs, then this helps out tremendously because it gets rewritten on the fly to the correct order. So this definitely helps out tremendously in that space. So we have specs for, specs are currently up for review as well. So what do we want to do in this scenario? Do we want to talk about the specs or should we just tell people where to go to see them? Yeah, so we essentially have this project board which is called Specification and the major specs that we are considering are sitting here. I don't know if we have any others that are not here. I don't know if we need to open them one by one, I think that is a bit redundant, but if there's any specific one that we can call out. So for example, I would really like to talk a little bit about this one. So I don't know if someone from, yeah, I see that Watson is here. Hello Watson. So within this CNF test bed, so I'm working with Taylor and Michael from Taylor Von Volk and Michael from Intel on enabling CNSM there. We already have a simple example and now we reached a point where we would like to be able to send and receive packet from the outside world, from the non NSM world. And that's where we are talking about this ingress and egress gateways and whatever you want to call them. And there has been a really interesting discussion the other day where we were trying to figure out what is the best cloud native approach to this. And there has been different discussions about what actually falls into the NSM domain should NSM be able to manage the hardware sources and the line network to some extent at some point should we be able to actually expose the networking resource in the high speed network. For example, you have some 50 gig network or 100 gig network and you expose it as a service and then you consume it this way. So various discussions there, but one of the ideas that Matt actually from Orange I started this a couple of months ago I was this ingress gateway, I know that he's working I don't think that he's on the call today. Matt, are you here? But we would very much appreciate any ideas around this and we have done a lot of work to actually improve NSM on its own. But I think that we have already also reached a point where we would like to connect to the outside world. And you probably have to go through some iterations or even provide a couple of solutions to this problem. For the time being with the CNF testbed we are going with somehow semi-static manual device assignment for the gateway. So we deployed the VPP based CNF and we will statically assign a PCI device to it so that it can exit the worker node and talk to the packet generator. But that's not where we want to stop. We want to reach a point where the gateway can be expressed in a cloud native way or the networking or the high-speed networking is just a network service that you can subscribe for and get connectivity to it. So interesting discussions around this. So if anyone has anything to add to this please check this back and provide input feedback. Patches, okay, that's what I wanted to call out if there's anything else you can also show. Nice, and just as a heads up I'm sorry to write the spec on CNI interoperability which I think will be of interest to many. I haven't put down the concepts there fully just yet because I'm still thinking through a lot of them. And there's a couple of approaches that I thought up of. The one that I think is the most promising is I was thinking of when we want to gain interoperability with NSM what we can do is we leave the CNI as it is but what we can do is once the interface has been created CNI as a process exits. And so that gives us the interface that's there. So what I'm thinking of is we can migrate that interface to a new network namespace and have NSM create a proxy interface that links to it but in order to register that namespace I was looking at the local linearization patches because what we may be able to do is inject a new data plane that is valid only for that specific request so that when you make the call in it has a registered CNI namespace that's there and it would only move things on demand. There's some things that we have to think through in terms of making this work because this has implications on IP table rules I think you may end up working out okay because the IP tables will still be there they'll still interact on that specific interface and so but we should still be careful with it in terms of how it works. There's a couple other simpler ideas that have popped up as well but I think that one may be the simplest and so the goal at the end of the day is to be able to interact with an existing CNI and to be able to interpose NSM between the network namespace and the actual CNI SDM in such a way that we can inject network services in the middle so if you wanna bring in an intrusion detection system that works with that pod or you wanna bring in a more powerful firewall other than IP tables or so on and bring them in the CNFs that gives you another path to doing so. So just some thoughts that are there. Anyways, I'll have a few paths that I'll write up in the next week or so of different possible approaches and I'm going to ask people for help with reviewing this in more detail because this is something that there's gonna be a lot of edge cases on and I actually don't think we'll be able to solve all the edge cases in the first pass but we want people to be aware of what they are because that gives us the limits as to where we can use it and what the caveats are when you do use it. So, but yeah, I think this has a potential to be really powerful. Are there any questions on that one? Yeah, I mean, I would prefer to see some more concrete writing and maybe one pictures. So yeah, but yeah, it sounds very interesting and I'm sure that if you're pulling a lot of interest and as we said a lot of times, maybe it brings us closer to make NSM one potential helps like one potential solution to the Kubernetes multi-tenancy. Yeah, so I think this one definitely has some interesting aspects but I'll call out some of the use cases as well in document. I think that'd be a good idea. Do you have any specific scenario that you want to play with, like some simple one? What I'm going to aim for is we pick a couple of the most commonly used CNIs to start with. So I think we can pick things like let's see, let's make it work for Calico and Flannel. And so we can start with, you know, start simple but then we can build up from there over time. And so I think between Calico and Flannel and that should cover maybe 95% of all deployments out there. Probably, probably. And Calico taking up 90% of that. And so even if we just focus on Calico the first one I think we'll be in good shape. I'm not sure if Calico would be the easier one but yeah, probably will be the most influential as you said, so. Yeah, it's the necessary one. With that, I don't have anything else and we've run up to the end of the agenda. Is there anything else that everyone wants to discuss? I'd like to talk about the issue with the 15 agent. I've often seen this 15, 20, 12. If anyone, just to raise it, if anyone has an opinion or should work with this it's about not, the BPA agent is not sending statistics. I can't read it or so there are no metrics in the cross-connect one. And I'm currently investigating any opinion that's right. Do you remember for VPPA, is that the plane, the implemented metrics for cross-connect? I didn't have a comment for the BPA agent but I can add my investigations. I compared with the metrics test where there is no VP in the communication and for the metrics test and it's working okay not there. And I looked into the code. So it seems maybe it's problem with the itself, I've been looking for some issues. But if anyone is familiar, anything on this is fine. Not fine, I'm not sure. Probably someone need to check. I can't remember exactly who was implementing the metrics support. If we will check, if it's on sorry site, this work was done, we will check. I don't remember. For the metrics work, for this my integration I'm currently working on adding the pod names to the cross-connect so that we can have the information there for the curies for the metrics so we can search metrics for specific points. And I'm collaborating with Radiswap who is doing the kernel metrics so we can test with the kernel forwarder but it's good to find things for the VP so that we can do the work. Okay, if there's no resolution on this till next week we can bring it again and I don't know if it is here, maybe he can suggest who we can contact on the VPP agent site from Ligato if we need help still. Yeah, it might make sense to reach out to, I don't remember the name of the fellow who was there. Was it Andre? Yeah, well, yeah. Do we think of the, yeah. If it may make sense if it looks like it's a problem with the VP agent and it's not a problem with the VP, it may make sense to ask him about it. At least that's who I would think about it and see if I can get the name. Yeah, Andre Fabri, I probably said the name poorly would be, and at very minimum he would know who to contact in that scenario. So I'll put the name in the, so I don't know the best way to get a hold of them, but we can work that out. I guess creating an issue in the issue tracker on GitHub and referring to our 1512 should be good enough. Yeah, do we have anything that's reproducible for them that we can send, that we can add into the ticket? I can add information, that's local and keep walks. Sorry, the audio is fading out a little bit with volume. Sorry, do you have any? Yeah, I have walks about that and maybe share them. Yeah, definitely go ahead and create the issue with them and fill in as much information as you can. And if it's not the right place, they'll tell us so as well. Sure, no problem. With that, is there anything else we wanna bring up? Fantastic, well, with that, one, a couple of last reminders, NSM call for proposals and number two if you're considering sponsoring NSMCon, the link is on the website in the events section. So with that, I wanna thank everyone for your time and we will see you all again next week at the same time. You all have a good day. Thank you. Cheers. Bye bye. Cheers.


I want to draw your attention to some developing opportunities in the Nasdaq on the daily time frame we've been tracking this trend channel to the upside looking for the third test as a terminal point for a corrective move and you can see this last load to the upside is subdividing nicely into a five-way sequence so I'm looking for any pullback here into the sending trend line support at 14,520, also got weekly range support coming in at 14,506. Watch for bullish reversal patterns there to set long positions to play for the test of the 15,276 and as long as we maintain momentum divergence I'll be watching for bearish reversal patterns to reverse to the short side looking for a move back to test support at 14,089. As always trade this plan to trade the plan and it's important to manage your risk. Until next time, thanks very much.


I am working with Agninoji, Anja Bojic and Rudi Podgornik, my collaborators, and at first let me tell you a brief introduction to viruses. Many of viruses could be approximated as a spherical-like shape for the outside of the virus. Some viruses are made of capsids, which are in fact made of proteins. The proteins are encoded in the viral genome, which could be RNA or DNA. But some viruses like the famous coronavirus are enveloped by a lipid membrane, and the genome is inside this lipid membrane. They also may have spike proteins, and the HIV virus has also the same kind of strategy to impact cells. But many of viruses are non-spherical, as well. For example, some of the first plant's virus, which was the first virus discovered, was tuberculosis virus, which is a rod-like virus. Or some DNA bacteriophages, which means the virus is infecting bacteria. They also have a non-spherical shape, and some of them have very long tails. And all viruses depend on living cells for their reproduction. Now I want to tell you something about importance of electrostatics to viruses. As Ali, I mean, Ali Naji said in his talk yesterday, viral shells are charged. They could have positive or negative charge for the outside or inside of their surface. For example, it is well-established that RNA viruses use electrostatic interactions, direct electrostatic interactions, with the interior part of the capsid of the virus, they're encapsulated inside. But for DNA viruses, for example, some of the bacteriophages, the strategy is different. And we have turret-like shapers made from DNA strands, which is the codes needed for virus to replicate. For this part, you can also remember DNA condensates that Ali talked about yesterday. And for such structures, multivalent ions are crucial, which we also want to focus on in this talk. Actually double-stranded DNA has two elementary charge for every base pair, which is about 3.4 nanometer of its length. And in the solution, we have both monovalent and multivalent ions. In addition, it has been shown that presence of multivalent ions for each virus, there are some multivalent ions which are crucial for its proper formation. And as Ali said yesterday, multivalent ions can cause attraction between same-sline charged surfaces. So to study the effect of multivalent ions on viral capsidizability or viral shell stability, we have used three different models. At first, we used an empty thin shell representing the empty capsid. And we used monocard simulations, we simulated explicitly multivalent ions. Such as spermine with full valency plus full valency. And monovalent salts was, in fact, simulated implicitly as a double screening environment. Then we tried to study the effect of, for example, DNA genome inside a bacteriophage with considering a nanodraplet having a constant volume charge density of rho. And then put this droplet inside the viral shell. So now, in the second model, the viral shell is not empty anymore. In our next model, we used, in fact, we started to simulate a done experiment on BMV viruses encapsulating gold nanoparticles having a coating layer, which you can see over here. This is the gold nanoparticle with radius r0. Then we have the coating layer of the gold nanoparticle with radius r1. This layer is charged, in fact, and could have positive or negative charge density on its surface. And it's impenetrable to multivalent ions. Then we have the viral shell of BMV virus. And the radius is r2. And in fact, it is always positively charged. It has a great positive charge. And for the Hamiltonian of the system, we used both a Debye-Huckel interaction and effective imed charts inside the gold nanoparticle between each pair of ions and between ions and charged surfaces, which are placed at r1 and r2, and between charged surfaces themselves. Our results show that, for example, for the charged anti-shell, which was our first model over here, we saw that we have multivalent counter ions of positive charge for plus 4-valence ions like spermine. Then we observed that for more negative charge density of the viral shell, we have more negative electrostatic pressure, which means more inward force on the shell and this can stabilize the viral shell because the force is not anymore positive because of the same sign charge of the different parts on the viral shell. So this was an effect only arising from 4-valence ions if we replaced the 4-valence ions with 3 or 2-valence ions, then we couldn't see this type of counter-intuitive result. Then when we had a nanodraplet encapsulated inside the virus, not only we saw that for a more negative sign, more negative charge of the volume charge density of the droplet, but in addition, for more negative surface charge density of the capsid, we could have more negative pressure or more stable capsid, which is very counter-intuitive, but also it can explain that why some DNA viruses have negatively charged shells instead of positively charged shells, which comes to mind at first. Then for the... Lelya, I had a question for you. So the negatively charged... So basically the thinking is that the negative charge is screened, that's why it's stabilized? No, by screening, we just will have less repulsive forces. Do you know? But because of multivalent counter-ions, not co-ions, but counter-ions, ions with the opposite sign of charge, we could have this effect because... Let me show you the next slide, please. For example, here we have counter-ions for the shell, and as you see, they condensate very precisely around the opposite charge shell. And then each of them could... This is my imagination. Each of these in fact multivalent counter-ions tries to neutralize some of the positive charge of the viral shell. And when they condensate over this shell, they can in fact induce positive attraction between these different parts. Or for example, between the two shells, which I am going to explain next. Did I answer your question? Yes, thanks. All right. So, Lady, you are keeping track of time, are you? I think you are at 11 minutes at least, because I'm a little confused. So you have maybe two or three minutes. Okay, go on. All right, sure. So in the presence of a golden particle encapsulated, we saw that not only a different sign between the first and second charge surfaces, the difference sign between them is not the only answer for stabilizing this nanoparticle inside the virus, which was the strategy used in the group of Professor Dragny. But also, if we have in here counter-ions are negatively charged, if we have multivalent counter-ions, we could see even attraction between positive R2 and positive R1. And the reason is, as I answered to the question of Alias, so this is a strategy that we could use to stabilize any kind of coating layer for the golden nanoparticle. Then we have used charge regulation kindly for some problem which has been done experimentally. We have been trying to find interaction between an FMT and a viral particle. And now we are working on coronavirus using charge regulation theory, which is more precise and accounts for different dissociation or association of hydrogen charge. And virus-like particles are in general important specifically in medical sciences. For example, virus-like particles do not have a wild-type genome inside them. And so they are used for vaccine production, targeted drug delivery, gene therapy and so on. Thank you all for your attention. Well, thank you very much, Lely, almost at the 14 minutes mark. So, Justin, maybe I make a comment too, because we had one question, to Alias' question, that this is the type of interaction I was talking about in my talk. These are correlation interactions. Basically, it's not screening, it's completely different from device screening. So because you have lots of neutralizing charges in the form of a plasma, a very dense plasma, and basically they manage to show the whole picture, but we can talk about it later. That can create a lot of negative self-energy for the whole complex, complex of nano-particle genome charge within the simple model we are using, actually. So, thank you very much, everybody. So we are 15...