 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 hate them from some time ago. 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 this was a really good design back in the day when the internet started, because computers were kind of stupid and slow. 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. In this network you just immediately notice, okay, this stopped working, you switch to the yellow path and you're done. 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 was trying to do something stupid, of course, because it's late. 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. And for this protocol, as we are talking Switzerland finance, the regulations are really fucking crazy. 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. You get it vagrant up. That's probably something very simple for people and you, and you run it. 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. So not your home network, but a bunch of ISPs. 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. And you know, you pay the money, they will provide you whatever you need. 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. So this is a very, let me say, stupid way of routing because you just tell router what should be the next hop. 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.