Which network to use when - Socket Intents
Enghardt, Theresa
Hacking the Socket API for fun and research Nowadays, most end devices have multiple network interfaces to connect to the Internet. They usually pick a statically configured default interface, such as WiFi, which they prefer over LTE when both are available, but this is not necessarily the choice that provides the best performance to the application. Socket Intents is a research prototype that addresses the problem of finding policies of which network interface to pick for what kind of traffic or application. It provides several networking APIs through which an application can specify its "Intents", i.e., what it knows or assumes about its own traffic. The prototype then decides which of the available network interfaces to use.
 Welcome to my talk. My name is Theresa and I'm going to present you my research prototype which is about managing multiple network interfaces in user space on Linux. So I am a researcher and PhD student at TU Berlin and I'm at the Internet Network Architectures Group with Professor Anja Feldman. This research that I'm presenting now is joint work with my colleague Philipp Teesel. We have been developing the prototype for about four to five years. So yeah, it's all research code. But yeah, the scenario that I want to talk about is about a multi-access client. So we got an end device like a notebook that is running Linux and it has multiple network interfaces and it's connected to different access networks over these interfaces. For example, one is LTE and one is Wi-Fi like with an LTE stick. It could also be Ethernet and Wi-Fi. But the point is that the client can now reach the Internet or some server on the Internet over both these interfaces. So usually, like if you're on a smartphone, usually Wi-Fi would be preferred over LTE. It's usually the default. But actually it's not always better in terms of performance. So there has already been a research paper from 2014 where these researchers have measured the Wi-Fi and LTE performance in terms of download bandwidth and also latency. And they found that in about 40% of the cases, LTE was actually better than Wi-Fi like where they just had lots of samples from some smartphones that were connected to Wi-Fi and LTE and basically in the same place at the same time comparing their performance. So they found that LTE is often actually better than Wi-Fi in terms of performance. And so it suggests that maybe there is not always just one default interface that we should use while ignoring the other one. So my research is basically in the scenario, which one would you pick? How do you pick the better one? Is even the better one or maybe can you use both at the same time? So right now, let's say we have this laptop. It has an interface called WN0 connected to a Wi-Fi network. It has a PPP0 connected to some cellular network. And now one of them is going to be the default interface and the other one basically never used. Which one is the default? I guess it depends on the routing configuration of the system. And there is some system-wide static default route usually. Like it's very simple. You look at the routing table and then there's the default route and you just use it. So one way where you could make use of the other interface as well is that you configure policy routing. So you configure two routing tables, one over the WLAN interface, one over the PPP interface. And then you can configure routing rules. So for example, if the application explicitly specifies one IP address of your configured addresses as a source, then it would go over this particular interface. So for several applications you could say, please always bind to that IP address and then it would go over this interface. So the problem with this is, okay, so first let's see. Let's take a look at the socket API, which is what many applications are using. And they are accessing the internet. So first they would resolve a name with get other info, just putting in a host name and getting back one or more IP addresses of the server that they are trying to connect to. Then they set up a socket with the socket call. And then optionally they can bind the socket to one of their local IP addresses. So here they could, at this point, they could make a decision as an application, okay, I got this and this IP address, so which interface would I actually prefer? And then it would connect to the server over this IP address and then close the socket like after doing whatever the application wants to do. So this is all good, but now we have many applications on the client. And if we think about that every application would have to implement its own decision logic to differentiate between the interfaces and to pick one of the interfaces or the other. And then also sometimes it's important what is the current performance of the interface. And so imagine that every application would have to periodically like monitor the interfaces, get some statistics on it, which one is currently used the most or maybe did I lose my, like did I lose performance? Or is the Wi-Fi congested something like this? So one problem would be that a lot of code would have to be duplicated within all the applications and it would also get really complicated. And the other one is that, so if we then try to unify this in some way, which is what we are doing with the socket-intense framework, then on the other hand you have the problem that the applications do have different requirements. Like if you just provide one single API and you say, okay, so now at one central library we always make the decision which interface would be better in this case, then maybe the same default interface doesn't always work for the different applications with their different needs and different kinds of traffic that they have. And so in the socket-intense framework we are trying to basically substitute this socket interface by a more enhanced API and provide a framework that manages different network interfaces and that can make decisions for the applications which of the available interfaces to use for example the next connection. So I'm going to explain how this works in a little more detail. So first socket-intense is a concept about the different requirements and needs of the applications. So by default through the socket interface the application can only basically say, okay, I want a TCP connection, I want a UDP connection, which is nice but over this connection there can be lots of different things, right, it can just be some small and short queries that just have to be finished as fast as possible. It could also be a huge file transfer and it could also be like a long-lived video streaming session. So one socket-intent that we introduce which is a piece of additional information that the application can give to the library and to the socket-intense library through the enhanced socket API is about the category of the traffic. So for example, is it a query, is it a stream, is it a bulk transfer? So we can differentiate between different connections that the application opens when we make our decisions later. And another intent would be the object size of the transfer. If it's a transfer then are we talking about a 10-kilobyte object or are we talking about 1 megabyte or 100 megabyte? Then also something about the duration, like is there a fixed duration that we know this connection is going to last? And then also about the timeliness which we named it, which is basically, is it a time-critical traffic, is it going to be something that the user is going to be interacting with or is it just in the background and we don't care if it's finished within five minutes or 10 minutes. So all these pieces of information are optional but the application can specify them as additional hints to the socket-intent library. And this can do this in the hope that then the library can make a better decision on which of the available interfaces would fit the requirements of the new connection from the application. So this is not quality of service. So there are no service guarantees. It's not intended that you specify I need 10 megabyte per second guaranteed bandwidth. But more like, okay, I would like some kind of like duration of a stream transfer and maybe you can set a bit rate. But it's not about guaranteeing anything. It's about the best effort of the system. And also if multiple applications would set these intents, then the system would have to balance their requirements in a fair way. So it's not about quality of service and it's also not about prioritization that one application says, okay, my traffic is now the most important. So yeah, this is the concept of socket-intents. And now we are building, oh yeah, resilience to connection loss, I forgot. So it's also a question of if this TCP connection was to be interrupted, how bad would it be? Is it just a transfer I can resume or is it like a stream that would get interrupted for the user? So our socket-intents library basically is sitting on top of the usual socket library that I already showed. The application would first use this. And yeah, so then the socket library, the socket-intents library talks to the multi-access manager, which is a standalone application. It's like a demon that runs once for the whole system and it gathers performance estimates from the interfaces that are currently configured. And then later on it has the task to choose an interface. So how it works is that there is an application that uses the socket-intents library. And yeah, it makes a request. It says, okay, I want to set up a new connection with these particular features or intents. Or like this is my idea of what to optimize for in this connection. And then the socket-intents library queries the multi-access manager says, okay, so this is all the application that I got from the information. Which interface do I use for it? What do you think? And then the multi-access manager has a policy which is a module that can be dynamically loaded. So also in different environments you can use different policies for choosing your interfaces. For example, the multi-access manager would then say, okay, you should use WLAN0 for this connection and it sends this information back to the socket-intents library which can then bite the connection to WLAN0 and connect the socket. So this is in a little more detail. So the application starts up and then the policy on the right which runs within the multi-access manager also starts up. And then the application can, for example, already specify its intents on some data structure that we pass to all our socket calls which are not on the slide, but we have to link the socket calls all together in some way. And for example, you can do it by handling socket context for the same connection. So you can do some setSocketOptCall that we extended by the socket-intents. And then when the application doesn't get other info to resolve a name, the Intents library makes the policy resolve that name. So why do we need rainbow solution here? Well, if you have multiple access networks which you connect to, then the same server might be reachable over both interfaces, but also maybe you're talking to a content delivery network and then there is multiple servers for the same host name. And then if you do a get other info over one interface, you get maybe a different set of IP addresses than if you do it over the other interface. And to our knowledge, there is not yet software in Linux that handles this explicitly that you can get different resolver responses over different interfaces. And then how do you manage it? If you then establish the connection later over one interface, but you use the IP address that you have resolved over the other interface, maybe your performance could suffer from it. And so this is what we're trying to address here when we already resolve the name in the policy and already choose some destination IP. So basically you could issue a DNS request over both interfaces at the same time and see what comes first. Or you could just make a decision and then choose which IP address to actually give back through the library to the application. And at that point, the application can set up its socket and then do a connect. So the application now does not have to call bind explicitly, but it can just call connect because the socket intense library internally handles the connect and like sends the connect request to the policy, which would then choose one of the local interfaces or choose the IP address that intense library then binds the socket to which already exists at that point. And then the application can do something on the socket and close the socket later. So yeah, this is the rather like basic classic socket API, which is also unfortunately blocking. We also have a few non-blocking libraries or APIs though for applications. And we, for example, have socket connect, which is another API that basically we developed. And the idea is that here we wanted to have just one call for the application that the application can say, hey, I want to connect to this URL on this board and with this intense for the connection. And then the socket intense library would give back a socket that is already connected to the application or it would, if it's not blocking, it would just give back like a placeholder that is going to be connected later and then the application can later use the socket like by Paul. And so the socket connect works kind of similarly, but the resolving and choosing of the destination IP and local IP address basically happen all in one call to the policy. So when it's called the very first time, then there is no existing socket. So the policy would basically find out the parameters for the socket that the application should use. And then the socket intense library sets up the socket and gives it back to the application. So now the application can use the socket for read, write, whatever. And then it does not have to close it yet. It can also use a socket release which says, okay, let's leave the socket open, but I don't need it anymore for now. And then for the next socket connect, the application might get the same socket back, but it might also get back a different socket like a new socket, for example. So here we can have several sockets that the socket instance library manages for the application and the application can just say, okay, now I want a socket that is suitable for this intent and now there's a socket that is suitable for like a different intent and then it doesn't have to care which interface it is. It can just use the socket that it gets from the intense library. So for example, if we have two interfaces and there is a TCP connection over one interface and there's one over the other interface, then you could do one HTTP request over the one TCP connection. You could do the next request over the other connection and use them in Barrel and also this works when you have more streams or when you have more TCP connections. So usually there would be like a number of connections open over both interfaces. And then for each request, like for example, if you're in a web browser and you're fetching a website with different objects, then you can fetch object one over like one interface and the next object over another connection over the same interface or maybe over a different interface. So with socket connect, you manage a set of sockets and the application doesn't have to consider which interface to use because it just always gets back a socket that it can use to read or write on. Most likely just first write and then read. Anyway, so yeah, but the socket connect API exists in different variants. Yeah, but the details are for example in the draft that I linked on the page of the talk and I can also give you the details if you're interested later. So yeah, these are two APIs that we developed and then we also developed policies which were the component just on the right that we saw. They are, they get as input the socket intents per connection or maybe per message per object what the application wants to do and then also it gathers the interface statistics passively. So right now we just observe existing traffic over the interface and we see like, okay, what are the round trip times of the TCP connections that already exists? What is like the minimum? What is the median? And try to guess something from these round trip times. And also we observe the interface counters and basically see, okay, what is the maximum change in interface counter which means like used bandwidth like send or received bytes that we see like per 100 milliseconds. And then we can have a guess about the capacity of the interface like at maximum download or upload bandwidth over the interface. And from these inputs, we can now choose a local interface. So simple baselines to compare against would be that we use only one of the interfaces or that we use both like one after the other in like around Robin fashion. So first interface one interface two then one and two and so on like always go back and forth. And then also we could have a policy that just always picks the interface with the lower RTT or that always picks the interface with the higher bandwidth. And then one policy that we developed is the earliest predicted arrival time or early arrival policy. And this one would now make use of the intent called object size. So the idea behind that is that if you have a large object, then you want to prefer the interface with the high bandwidth. But if you have a small object, then the interface with a lower RTT if it's a different interface would be more beneficial because for the small object, you don't need a high bandwidth, but you just want the download to be finished as fast as possible. But for the larger objects, a higher bandwidth is important because otherwise you will have to wait longer for your object. And so the policy basically tries to predict based on the interface statistics that it got previously. It tries to predict how long will I need over one interface, how long do I need over the other interface, and so which one do I prefer in this case. And then also, as I said already, it can choose a remote IP address among multiple resolved IP addresses. And also said arbitrary socket options. Actually we also have like, we have the option to switch on or to enable a multi-path TCP per connection. This is not something I evaluated yet, but like we also built this into the prototype. So the prototype is still being extended with like some of these nice features. So now I'm going to show you an evaluation setup that I'm currently working with. It's also fairly simple. So I don't use an actual LTE network, but I have a Wi-Fi and then an internet connection from a laptop that is going via a traffic shaper and then to a server. So the client runs a web browser and it uses the socket intense framework for its connections. And then the traffic shaper can emulate different network conditions like you can specify an RTT that is imposed on all the traffic that goes through all of these networks and you can shape the bandwidth. You can limit the bandwidth that can go through the shaper and also you can configure packet loss on the traffic. So yeah, I emulate different network conditions on both paths basically. And then there's the web server which can or which hosts different web pages of different sizes. And so far it's just a static workload like just some websites with a number of images, which I'm going to show you on the next slide. So this is going to be the details of like a preliminary evaluation that I'm doing right now because right now I'm still like trying out which are the best policies and how to optimize the performance for example for web browsing. So in this case the connection on the top in green is over the Wi-Fi interface and it has a shaped RTT of only 10 milliseconds. So it's quite fast but also it only has 2 megabit per second as a download bandwidth which is like not a lot and in blue on the bottom over the ethernet I shaped a RTT of 100 milliseconds but of 20 megabit per second downstream. So here again the idea is that for very small queries, very small objects you would prefer the one in green with the Wi-Fi interface with 10 milliseconds and for larger objects you would prefer the one with 20 megabit per second download because that would be the faster one in each case. So the websites I have more websites but these are the ones that I'm going to be showing and the plot on the next slide is there's one static website where it's one HTML file and then for 10 kilobyte images or 8 kilobyte images or 16 images or 400 kilobyte images and usually webpages are going to be more objects and bigger sizes but the evaluation is going to continue in that direction to more realistic workloads and websites. And then the policies that I used for this preliminary evaluation that I'm going to be showing is only over one interface WLAN0 only over ETH0, the other interface and then both with the earliest arrival policy that for each of the objects predicts the download time and then uses either WLAN0 or ETH0. So here is my plot. So on the x-axis you see the different scenarios like this is 10 kilobyte 4 images, 10 kilobyte 8 images, 10 kilobyte 16 and 100 kilobyte 4 images and basically always the socket intense then ETH0 only and then WLAN0 only and on the y-axis is the page load time in seconds and it's like between 0.3 and 1.8 or so seconds for this particular quite small workload. So these are box plots so they show of different of many repetitions they show you the median basically and then in some cases like from where to where did we see values. So for the very small page of only 4 images of 10 kilobyte ETH0 was apparently quite fast because lower is better of course for page load time and WLAN0 was slower and then socket intense used ETH0 the faster interface basically. Also in this case so WLAN is slower so socket intense uses the better interface but then as the images get more or the workload gets bigger at some point WLAN which had the higher bandwidth becomes better because if we are going to download many more images then at some point the bandwidth is going to get clogged on a 2 megabyte interface and so here socket intense uses the WLAN0 interface because it's faster and then the last case is particularly nice because here we use a combination so this one is up here the ETH0 interface has now become actually quite slow because it has only 2 megabyte per second download bandwidth and WLAN is way faster but then socket intense is even faster because it can make use of both interfaces. So as I said this is only a preliminary evaluation and right now I'm working on a like more extensive one and improving my policies and the matrix and performance estimates that I get from the interfaces. So yeah so keeping in mind that this is a research prototype and not a production code still I'm wondering if like okay so for socket intense the application needs to be modified I'm aware that this is going to be quite hard like I'm not expecting that every browser is going to support socket intense in the future but still it's a question of like how to get applications to use socket intense or something like this or how to how should the application if it should do it communicate its needs or expectations about the traffic and then also how to come up with smarter policies to choose between network interfaces and also which I find an interesting question how to integrate this with other Linux user space software or what networking libraries exist that could inform the socket intense framework or vice versa or yeah how does it work so if anybody has any input or questions on this I'm looking forward to that. So this is my summary so the goal of my research is to use multiple network interfaces the prototype we developed is called socket intense it's a networking library in user space which applications can do can specify can use to specify what it knows about its traffic and then to get like to get its interface picked basically through the multi access manager which chooses the best option and the code is on GitHub and it's released under a BST license so you can check it out you can play around with it and yeah you can talk to us about it so for contacting me Teresa at INET because it's like part of my research but I'm also on Twitter and I'm on Mustodon so if you don't know Mustodon already you should check it out because actually on Mustodon I write more technical stuff and on Twitter it's more like activism so it's Mustodon is basically Twitter but better okay enough ads okay and then I'm also on LinkedIn if that's your thing or I'm also on GitHub. Alright so thank you for your attention and now I think we have a little time for questions if there are any seven minutes I see. Yeah. Hello my name is Luba I work on network manager so this sort of interests me what you said I do have a question I'm wondering you said you do passive monitoring to assess the properties of the interfaces that for the policy to take decisions and I'm wondering how does this work like from the very beginning like when you I suppose you don't have any information then so suppose you start with a slow mobile broadband and the gigabit Ethernet due to round robin from the beginning. Yeah so what we do is that in the multi-access manager we have this callback which currently gets invoked every 100 seconds and then it basically reads out all the statistics like through netlink and from the interface counters that it can find but we assume that there is already ongoing traffic on the system and yeah it needs to be bootstrapped somehow and I guess for the first few requests we should use a sort of round robin but like this kind of thing is what I'm like currently still working on like what is the best way to gather these statistics I'm yeah I also think that this kind of thing could be like coordinated between different processes that actually have an interest in like which interface is the best also we monitor some Wi-Fi statistics like through netlink you can get signal strength and the currently used or the last used modulation rate and also we are working on like looking into how we can get the QBSS information like from the access point which can insert basically the current utilization of the channel which is really interesting because the signal strength it can like up to a point it doesn't matter so much if the signal strength is really good or not so good but the utilization of the medium like how many clients are there and how much traffic are they sending is really interesting and so like we are also gathering these kinds of statistics. Thanks. You also had a question? So did I get it right that it's for client side of the connection or it might be also useful for server side? It could also be used for a server side so the library is not limited to that so for example it could also be used in like in a data center where there's a multi-homed server that wants to open like different connections for different kinds of workloads so I haven't explored that yet and I'm like more interested in the client side but yeah I think it would be possible. I don't know about the exact like networking libraries that exist for the server side but I guess it would be possible. As long as you at some point either establish a connection or you say okay now I have something like some traffic to send now I have something to do please give me a socket to do it. Should be possible. I was wondering about if you've got a lot of interfaces especially if you've got also open VPN interfaces those pseudo interfaces is this library smart enough to well basically use the right one because if you use an open VPN you don't want things to go over the unencrypted channels. Yeah sure. Yes you could configure these things in the policy so in the policy you can configure which interface you want to have considered at all so if you have an interface that you deem insecure then you wouldn't consider it at all maybe and we don't have a security intent so far but we could edit. I was wondering if you tested with so you did some simulation with limited bandwidth for example do you change that limit over time. Not yet but yeah that's also something that is planned because of course the mobile performance is can also be very flaky but what we did do is that we introduce a cross traffic on the wireless channel from multiple clients and then of course we see the performance drastically drop like no matter what is shaped later on if there is many clients on your channel or if your signal gets bad then at some point you're going to like see the performance change but with these dynamic network conditions it's also an interesting question so I set this framework up and now I can play around with like lots of different scenarios. Have you tried to model what kind of effects in the case of the Wi-Fi and the LTE which is a very common case have you tried to model what kind of effects it would have if you turn this on because you know LTE is generally more of a scarce resource so if everyone started acting like rationally but selfishly would you come you know do you think you'd come into a situation where the overall network is worse overall because everybody is acting rationally. Yeah I have looked into like or like we started considering some communication with the network like of course from the access point we can have the medium utilization but from the LTE network I think we don't get as much information right but then yeah I already looked into how you could coordinate different clients but I like don't have a ready simulation of it yet but it's also an interesting question also there is one socket intent that I didn't mention that is basically about for this connection would it be okay to use something that costs money or like that uses up your data your data mobile data thing or not and so this we also have like in mind. Have you given it some thought how you would integrate this with applications sandboxing especially mobile devices you generally don't want applications accessing through arbitrary network interfaces but why the white listed one. So mobile sandboxing we haven't done yet so far or prototype runs on the on a notebook with either like Linux or Mac OS and I mostly with Linux and yeah but you have to figure out in the policy you would have to figure out these kinds of things I think like what are the needs of the application and what are the system wide policies and what are the users like preference preferences but also how much is who able to control so this kind of policy framework like with all the different inputs to the potential policies is something that I'm also exploring right now and also my colleague and I are participating in the tabs working group at the IETF which is about choosing between different transport protocols mostly but there we also have like some kind of okay what is the policy like when do we use what kind of transport protocol and what are the different inputs so we are also like discussing this with like the wider community like what are policies and how do they work. Yeah thanks so I think we had one more minute but if there's no more questions here I'm also happy to chat about this later on. Thank you.
 Welcome to my talk.  My name is Theresa and I'm going to present you my research prototype which is about managing  multiple network interfaces in user space on Linux.  So I am a researcher and PhD student at TU Berlin and I'm at the Internet Network Architectures  Group with Professor Anja Feldman.  This research that I'm presenting now is joint work with my colleague Philipp Teesel.  We have been developing the prototype for about four to five years.  So yeah, it's all research code.  But yeah, the scenario that I want to talk about is about a multi-access client.  So we got an end device like a notebook that is running Linux and it has multiple network  interfaces and it's connected to different access networks over these interfaces.  For example, one is LTE and one is Wi-Fi like with an LTE stick.  It could also be Ethernet and Wi-Fi.  But the point is that the client can now reach the Internet or some server on the Internet  over both these interfaces.  So usually, like if you're on a smartphone, usually Wi-Fi would be preferred over LTE.  It's usually the default.  But actually it's not always better in terms of performance.  So there has already been a research paper from 2014 where these researchers have measured  the Wi-Fi and LTE performance in terms of download bandwidth and also latency.  And they found that in about 40% of the cases, LTE was actually better than Wi-Fi like where  they just had lots of samples from some smartphones that were connected to Wi-Fi and LTE and basically  in the same place at the same time comparing their performance.  So they found that LTE is often actually better than Wi-Fi in terms of performance.  And so it suggests that maybe there is not always just one default interface that we  should use while ignoring the other one.  So my research is basically in the scenario, which one would you pick?  How do you pick the better one?  Is even the better one or maybe can you use both at the same time?  So right now, let's say we have this laptop.  It has an interface called WN0 connected to a Wi-Fi network.  It has a PPP0 connected to some cellular network.  And now one of them is going to be the default interface and the other one basically never  used.  Which one is the default? I guess it depends on the routing configuration of the system.  And there is some system-wide static default route usually.  Like it's very simple.  You look at the routing table and then there's the default route and you just use it.  So one way where you could make use of the other interface as well is that you configure  policy routing. So you configure two routing tables, one over the WLAN interface, one over  the PPP interface.  And then you can configure routing rules.  So for example, if the application explicitly specifies one IP address of your configured  addresses as a source, then it would go over this particular interface. So for several  applications you could say, please always bind to that IP address and then it would  go over this interface.  So the problem with this is, okay, so first let's see.  Let's take a look at the socket API, which is what many applications are using.  And they are accessing the internet.  So first they would resolve a name with get other info, just putting in a host name and  getting back one or more IP addresses of the server that they are trying to connect to.  Then they set up a socket with the socket call.  And then optionally they can bind the socket to one of their local IP addresses.  So here they could, at this point, they could make a decision as an application, okay, I  got this and this IP address, so which interface would I actually prefer?  And then it would connect to the server over this IP address and then close the socket  like after doing whatever the application wants to do.  So this is all good, but now we have many applications on the client.  And if we think about that every application would have to implement its own decision logic  to differentiate between the interfaces and to pick one of the interfaces or the other.  And then also sometimes it's important what is the current performance of the interface.  And so imagine that every application would have to periodically like monitor the interfaces,  get some statistics on it, which one is currently used the most or maybe did I lose my, like  did I lose performance?  Or is the Wi-Fi congested something like this?  So one problem would be that a lot of code would have to be duplicated within all the  applications and it would also get really complicated.  And the other one is that, so if we then try to unify this in some way, which is what we  are doing with the socket-intense framework, then on the other hand you have the problem  that the applications do have different requirements.  Like if you just provide one single API and you say, okay, so now at one central library  we always make the decision which interface would be better in this case, then maybe the  same default interface doesn't always work for the different applications with their  different needs and different kinds of traffic that they have.  And so in the socket-intense framework we are trying to basically substitute this socket  interface by a more enhanced API and provide a framework that manages different network  interfaces and that can make decisions for the applications which of the available interfaces  to use for example the next connection.  So I'm going to explain how this works in a little more detail.  So first socket-intense is a concept about the different requirements and needs of the  applications.  So by default through the socket interface the application can only basically say, okay,  I want a TCP connection, I want a UDP connection, which is nice but over this connection there  can be lots of different things, right, it can just be some small and short queries that  just have to be finished as fast as possible.  It could also be a huge file transfer and it could also be like a long-lived video streaming  session.  So one socket-intent that we introduce which is a piece of additional information that the  application can give to the library and to the socket-intense library through the enhanced  socket API is about the category of the traffic.  So for example, is it a query, is it a stream, is it a bulk transfer?  So we can differentiate between different connections that the application opens when  we make our decisions later.  And another intent would be the object size of the transfer.  If it's a transfer then are we talking about a 10-kilobyte object or are we talking about  1 megabyte or 100 megabyte?  Then also something about the duration, like is there a fixed duration that we know this  connection is going to last?  And then also about the timeliness which we named it, which is basically, is it a time-critical  traffic, is it going to be something that the user is going to be interacting with or  is it just in the background and we don't care if it's finished within five minutes  or 10 minutes.  So all these pieces of information are optional but the application can specify them as additional  hints to the socket-intent library.  And this can do this in the hope that then the library can make a better decision on  which of the available interfaces would fit the requirements of the new connection from  the application.  So this is not quality of service.  So there are no service guarantees.  It's not intended that you specify I need 10 megabyte per second guaranteed bandwidth.  But more like, okay, I would like some kind of like duration of a stream transfer and  maybe you can set a bit rate.  But it's not about guaranteeing anything.  It's about the best effort of the system.  And also if multiple applications would set these intents, then the system would have  to balance their requirements in a fair way.  So it's not about quality of service and it's also not about prioritization that one application  says, okay, my traffic is now the most important.  So yeah, this is the concept of socket-intents.  And now we are building, oh yeah, resilience to connection loss, I forgot.  So it's also a question of if this TCP connection was to be interrupted, how bad would it be?  Is it just a transfer I can resume or is it like a stream that would get interrupted for  the user?  So our socket-intents library basically is sitting on top of the usual socket library  that I already showed.  The application would first use this.  And yeah, so then the socket library, the socket-intents library talks to the multi-access  manager, which is a standalone application.  It's like a demon that runs once for the whole system and it gathers performance estimates  from the interfaces that are currently configured.  And then later on it has the task to choose an interface.  So how it works is that there is an application that uses the socket-intents library.  And yeah, it makes a request.  It says, okay, I want to set up a new connection with these particular features or intents.  Or like this is my idea of what to optimize for in this connection.  And then the socket-intents library queries the multi-access manager says, okay, so this  is all the application that I got from the information.  Which interface do I use for it?  What do you think?  And then the multi-access manager has a policy which is a module that can be dynamically  loaded.  So also in different environments you can use different policies for choosing your interfaces.  For example, the multi-access manager would then say, okay, you should use WLAN0 for this  connection and it sends this information back to the socket-intents library which can then  bite the connection to WLAN0 and connect the socket.  So this is in a little more detail.  So the application starts up and then the policy on the right which runs within the  multi-access manager also starts up.  And then the application can, for example, already specify its intents on some data structure  that we pass to all our socket calls which are not on the slide, but we have to link  the socket calls all together in some way.  And for example, you can do it by handling socket context for the same connection.  So you can do some setSocketOptCall that we extended by the socket-intents.  And then when the application doesn't get other info to resolve a name, the Intents  library makes the policy resolve that name.  So why do we need rainbow solution here?  Well, if you have multiple access networks which you connect to, then the same server  might be reachable over both interfaces, but also maybe you're talking to a content delivery  network and then there is multiple servers for the same host name.  And then if you do a get other info over one interface, you get maybe a different set of  IP addresses than if you do it over the other interface.  And to our knowledge, there is not yet software in Linux that handles this explicitly that  you can get different resolver responses over different interfaces.  And then how do you manage it?  If you then establish the connection later over one interface, but you use the IP address  that you have resolved over the other interface, maybe your performance could suffer from it.  And so this is what we're trying to address here when we already resolve the name in the  policy and already choose some destination IP.  So basically you could issue a DNS request over both interfaces at the same time and see  what comes first.  Or you could just make a decision and then choose which IP address to actually give back  through the library to the application.  And at that point, the application can set up its socket and then do a connect.  So the application now does not have to call bind explicitly, but it can just call connect  because the socket intense library internally handles the connect and like sends the connect  request to the policy, which would then choose one of the local interfaces or choose the  IP address that intense library then binds the socket to which already exists at that  point.  And then the application can do something on the socket and close the socket later.  So yeah, this is the rather like basic classic socket API, which is also unfortunately blocking.  We also have a few non-blocking libraries or APIs though for applications.  And we, for example, have socket connect, which is another API that basically we developed.  And the idea is that here we wanted to have just one call for the application that the  application can say, hey, I want to connect to this URL on this board and with this intense  for the connection.  And then the socket intense library would give back a socket that is already connected  to the application or it would, if it's not blocking, it would just give back like a placeholder  that is going to be connected later and then the application can later use the socket like  by Paul.  And so the socket connect works kind of similarly, but the resolving and choosing of the destination  IP and local IP address basically happen all in one call to the policy.  So when it's called the very first time, then there is no existing socket.  So the policy would basically find out the parameters for the socket that the application  should use.  And then the socket intense library sets up the socket and gives it back to the application.  So now the application can use the socket for read, write, whatever.  And then it does not have to close it yet.  It can also use a socket release which says, okay, let's leave the socket open, but I don't  need it anymore for now.  And then for the next socket connect, the application might get the same socket back,  but it might also get back a different socket like a new socket, for example.  So here we can have several sockets that the socket instance library manages for the application  and the application can just say, okay, now I want a socket that is suitable for this intent  and now there's a socket that is suitable for like a different intent and then it doesn't  have to care which interface it is.  It can just use the socket that it gets from the intense library.  So for example, if we have two interfaces and there is a TCP connection over one interface  and there's one over the other interface, then you could do one HTTP request over the  one TCP connection.  You could do the next request over the other connection and use them in Barrel and also  this works when you have more streams or when you have more TCP connections.  So usually there would be like a number of connections open over both interfaces.  And then for each request, like for example, if you're in a web browser and you're fetching  a website with different objects, then you can fetch object one over like one interface  and the next object over another connection over the same interface or maybe over a different  interface.  So with socket connect, you manage a set of sockets and the application doesn't have  to consider which interface to use because it just always gets back a socket that it  can use to read or write on.  Most likely just first write and then read.  Anyway, so yeah, but the socket connect API exists in different variants.  Yeah, but the details are for example in the draft that I linked on the page of the talk  and I can also give you the details if you're interested later.  So yeah, these are two APIs that we developed and then we also developed policies which  were the component just on the right that we saw.  They are, they get as input the socket intents per connection or maybe per message per object  what the application wants to do and then also it gathers the interface statistics passively.  So right now we just observe existing traffic over the interface and we see like, okay,  what are the round trip times of the TCP connections that already exists?  What is like the minimum?  What is the median?  And try to guess something from these round trip times.  And also we observe the interface counters and basically see, okay, what is the maximum  change in interface counter which means like used bandwidth like send or received bytes  that we see like per 100 milliseconds.  And then we can have a guess about the capacity of the interface like at maximum download or  upload bandwidth over the interface.  And from these inputs, we can now choose a local interface.  So simple baselines to compare against would be that we use only one of the interfaces  or that we use both like one after the other in like around Robin fashion.  So first interface one interface two then one and two and so on like always go back and  forth.  And then also we could have a policy that just always picks the interface with the lower  RTT or that always picks the interface with the higher bandwidth.  And then one policy that we developed is the earliest predicted arrival time or early arrival  policy.  And this one would now make use of the intent called object size.  So the idea behind that is that if you have a large object, then you want to prefer the  interface with the high bandwidth.  But if you have a small object, then the interface with a lower RTT if it's a different interface  would be more beneficial because for the small object, you don't need a high bandwidth, but  you just want the download to be finished as fast as possible.  But for the larger objects, a higher bandwidth is important because otherwise you will have  to wait longer for your object.  And so the policy basically tries to predict based on the interface statistics that it  got previously.  It tries to predict how long will I need over one interface, how long do I need over the  other interface, and so which one do I prefer in this case.  And then also, as I said already, it can choose a remote IP address among multiple resolved  IP addresses.  And also said arbitrary socket options.  Actually we also have like, we have the option to switch on or to enable a multi-path TCP  per connection.  This is not something I evaluated yet, but like we also built this into the prototype.  So the prototype is still being extended with like some of these nice features.  So now I'm going to show you an evaluation setup that I'm currently working with.  It's also fairly simple.  So I don't use an actual LTE network, but I have a Wi-Fi and then an internet connection  from a laptop that is going via a traffic shaper and then to a server.  So the client runs a web browser and it uses the socket intense framework for its connections.  And then the traffic shaper can emulate different network conditions like you can specify an  RTT that is imposed on all the traffic that goes through all of these networks and you  can shape the bandwidth.  You can limit the bandwidth that can go through the shaper and also you can configure packet  loss on the traffic.  So yeah, I emulate different network conditions on both paths basically.  And then there's the web server which can or which hosts different web pages of different  sizes.  And so far it's just a static workload like just some websites with a number of images,  which I'm going to show you on the next slide.  So this is going to be the details of like a preliminary evaluation that I'm doing right  now because right now I'm still like trying out which are the best policies and how to  optimize the performance for example for web browsing.  So in this case the connection on the top in green is over the Wi-Fi interface and it  has a shaped RTT of only 10 milliseconds.  So it's quite fast but also it only has 2 megabit per second as a download bandwidth  which is like not a lot and in blue on the bottom over the ethernet I shaped a RTT of  100 milliseconds but of 20 megabit per second downstream.  So here again the idea is that for very small queries, very small objects you would prefer  the one in green with the Wi-Fi interface with 10 milliseconds and for larger objects  you would prefer the one with 20 megabit per second download because that would be the  faster one in each case.  So the websites I have more websites but these are the ones that I'm going to be showing  and the plot on the next slide is there's one static website where it's one HTML file  and then for 10 kilobyte images or 8 kilobyte images or 16 images or 400 kilobyte images  and usually webpages are going to be more objects and bigger sizes but the evaluation  is going to continue in that direction to more realistic workloads and websites.  And then the policies that I used for this preliminary evaluation that I'm going to be  showing is only over one interface WLAN0 only over ETH0, the other interface and then both  with the earliest arrival policy that for each of the objects predicts the download time  and then uses either WLAN0 or ETH0.  So here is my plot.  So on the x-axis you see the different scenarios like this is 10 kilobyte 4 images, 10 kilobyte  8 images, 10 kilobyte 16 and 100 kilobyte 4 images and basically always the socket intense  then ETH0 only and then WLAN0 only and on the y-axis is the page load time in seconds  and it's like between 0.3 and 1.8 or so seconds for this particular quite small workload.  So these are box plots so they show of different of many repetitions they show you the median  basically and then in some cases like from where to where did we see values.  So for the very small page of only 4 images of 10 kilobyte ETH0 was apparently quite fast  because lower is better of course for page load time and WLAN0 was slower and then socket  intense used ETH0 the faster interface basically.  Also in this case so WLAN is slower so socket intense uses the better interface but then  as the images get more or the workload gets bigger at some point WLAN which had the higher  bandwidth becomes better because if we are going to download many more images then at  some point the bandwidth is going to get clogged on a 2 megabyte interface and so here socket  intense uses the WLAN0 interface because it's faster and then the last case is particularly  nice because here we use a combination so this one is up here the ETH0 interface has  now become actually quite slow because it has only 2 megabyte per second download bandwidth  and WLAN is way faster but then socket intense is even faster because it can make use of  both interfaces.  So as I said this is only a preliminary evaluation and right now I'm working on a like more extensive  one and improving my policies and the matrix and performance estimates that I get from  the interfaces.  So yeah so keeping in mind that this is a research prototype and not a production code  still I'm wondering if like okay so for socket intense the application needs to be modified  I'm aware that this is going to be quite hard like I'm not expecting that every browser  is going to support socket intense in the future but still it's a question of like how  to get applications to use socket intense or something like this or how to how should  the application if it should do it communicate its needs or expectations about the traffic  and then also how to come up with smarter policies to choose between network interfaces  and also which I find an interesting question how to integrate this with other Linux user  space software or what networking libraries exist that could inform the socket intense  framework or vice versa or yeah how does it work so if anybody has any input or questions  on this I'm looking forward to that.  So this is my summary so the goal of my research is to use multiple network interfaces the  prototype we developed is called socket intense it's a networking library in user space which  applications can do can specify can use to specify what it knows about its traffic and  then to get like to get its interface picked basically through the multi access manager  which chooses the best option and the code is on GitHub and it's released under a BST  license so you can check it out you can play around with it and yeah you can talk to us  about it so for contacting me Teresa at INET because it's like part of my research but  I'm also on Twitter and I'm on Mustodon so if you don't know Mustodon already you should  check it out because actually on Mustodon I write more technical stuff and on Twitter  it's more like activism so it's Mustodon is basically Twitter but better okay enough ads  okay and then I'm also on LinkedIn if that's your thing or I'm also on GitHub.  Alright so thank you for your attention and now I think we have a little time for questions  if there are any seven minutes I see.  Yeah.  Hello my name is Luba I work on network manager so this sort of interests me what you said  I do have a question I'm wondering you said you do passive monitoring to assess the properties  of the interfaces that for the policy to take decisions and I'm wondering how does this work  like from the very beginning like when you I suppose you don't have any information then  so suppose you start with a slow mobile broadband and the gigabit Ethernet due to round robin  from the beginning.  Yeah so what we do is that in the multi-access manager we have this callback which currently  gets invoked every 100 seconds and then it basically reads out all the statistics like  through netlink and from the interface counters that it can find but we assume that there  is already ongoing traffic on the system and yeah it needs to be bootstrapped somehow  and I guess for the first few requests we should use a sort of round robin but like  this kind of thing is what I'm like currently still working on like what is the best way  to gather these statistics I'm yeah I also think that this kind of thing could be like  coordinated between different processes that actually have an interest in like which interface  is the best also we monitor some Wi-Fi statistics like through netlink you can get signal strength  and the currently used or the last used modulation rate and also we are working on like looking  into how we can get the QBSS information like from the access point which can insert basically  the current utilization of the channel which is really interesting because the signal strength  it can like up to a point it doesn't matter so much if the signal strength is really good  or not so good but the utilization of the medium like how many clients are there and  how much traffic are they sending is really interesting and so like we are also gathering  these kinds of statistics.  Thanks.  You also had a question?  So did I get it right that it's for client side of the connection or it might be also  useful for server side?  It could also be used for a server side so the library is not limited to that so for  example it could also be used in like in a data center where there's a multi-homed server  that wants to open like different connections for different kinds of workloads so I haven't  explored that yet and I'm like more interested in the client side but yeah I think it would  be possible.  I don't know about the exact like networking libraries that exist for the server side but  I guess it would be possible.  As long as you at some point either establish a connection or you say okay now I have something  like some traffic to send now I have something to do please give me a socket to do it.  Should be possible.  I was wondering about if you've got a lot of interfaces especially if you've got also  open VPN interfaces those pseudo interfaces is this library smart enough to well basically  use the right one because if you use an open VPN you don't want things to go over the  unencrypted channels.  Yeah sure.  Yes you could configure these things in the policy so in the policy you can configure  which interface you want to have considered at all so if you have an interface that you  deem insecure then you wouldn't consider it at all maybe and we don't have a security  intent so far but we could edit.  I was wondering if you tested with so you did some simulation with limited bandwidth  for example do you change that limit over time.  Not yet but yeah that's also something that is planned because of course the mobile performance  is can also be very flaky but what we did do is that we introduce a cross traffic on  the wireless channel from multiple clients and then of course we see the performance  drastically drop like no matter what is shaped later on if there is many clients on your  channel or if your signal gets bad then at some point you're going to like see the performance  change but with these dynamic network conditions it's also an interesting question so I set  this framework up and now I can play around with like lots of different scenarios.  Have you tried to model what kind of effects in the case of the Wi-Fi and the LTE which  is a very common case have you tried to model what kind of effects it would have if you  turn this on because you know LTE is generally more of a scarce resource so if everyone started  acting like rationally but selfishly would you come you know do you think you'd come  into a situation where the overall network is worse overall because everybody is acting  rationally.  Yeah I have looked into like or like we started considering some communication with the network  like of course from the access point we can have the medium utilization but from the LTE  network I think we don't get as much information right but then yeah I already looked into  how you could coordinate different clients but I like don't have a ready simulation  of it yet but it's also an interesting question also there is one socket intent that I didn't  mention that is basically about for this connection would it be okay to use something that costs  money or like that uses up your data your data mobile data thing or not and so this  we also have like in mind.  Have you given it some thought how you would integrate this with applications sandboxing  especially mobile devices you generally don't want applications accessing through arbitrary  network interfaces but why the white listed one.  So mobile sandboxing we haven't done yet so far or prototype runs on the on a notebook  with either like Linux or Mac OS and I mostly with Linux and yeah but you have to figure  out in the policy you would have to figure out these kinds of things I think like what  are the needs of the application and what are the system wide policies and what are  the users like preference preferences but also how much is who able to control so this  kind of policy framework like with all the different inputs to the potential policies  is something that I'm also exploring right now and also my colleague and I are participating  in the tabs working group at the IETF which is about choosing between different transport  protocols mostly but there we also have like some kind of okay what is the policy like  when do we use what kind of transport protocol and what are the different inputs so we are  also like discussing this with like the wider community like what are policies and how do  they work.  Yeah thanks so I think we had one more minute but if there's no more questions here I'm  also happy to chat about this later on.  Thank you.
2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_0_155.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_156_2123.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_2124_3875.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_3876_4067.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_4068_4451.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_4452_4655.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_4656_4799.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_4800_6227.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_6228_6899.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_6900_6983.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_6984_7667.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_7668_9971.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_9972_10787.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_10788_11663.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_11664_15935.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_15936_18323.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_18324_18635.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_18636_22199.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_22200_23495.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_23496_29243.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_29244_30911.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_30912_34127.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_34128_36131.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_36132_36215.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_36216_36299.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_36300_36347.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_36348_36575.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_36576_39731.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_39732_40799.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_40800_41651.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_41652_42719.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_42720_43667.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_43668_44627.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_44628_45323.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_45324_45383.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_45384_45431.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_45432_45479.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_45480_45551.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_45552_45611.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_45612_45671.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_45672_45731.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_45732_45779.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_45780_46079.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_46080_46139.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_46140_46367.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_46368_47231.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_47232_47591.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_47592_52223.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_52224_53495.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_53496_57215.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_57216_59339.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_59340_59759.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_59760_59807.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_59808_59867.png 2017_Which_network_to_use_when_-_Socket_Intents_801YVIR6Oto_59868_59903.png
Welcome to my talk. My name is Theresa and I'm going to present you my research prototype which is about managing multiple network interfaces in user space on Linux. So I am a researcher and PhD student at TU Berlin and I'm at the Internet Network Architectures Group with Professor Anja Feldman. This research that I'm presenting now is joint work with my colleague Philipp Teesel. We have been developing the prototype for about four to five years. So yeah, it's all research code. But yeah, the scenario that I want to talk about is about a multi-access client. So we got an end device like a notebook that is running Linux and it has multiple network interfaces and it's connected to different access networks over these interfaces. For example, one is LTE and one is Wi-Fi like with an LTE stick. It could also be Ethernet and Wi-Fi. But the point is that the client can now reach the Internet or some server on the Internet over both these interfaces. So usually, like if you're on a smartphone, usually Wi-Fi would be preferred over LTE. It's usually the default. But actually it's not always better in terms of performance. So there has already been a research paper from 2014 where these researchers have measured the Wi-Fi and LTE performance in terms of download bandwidth and also latency. And they found that in about 40% of the cases, LTE was actually better than Wi-Fi like where they just had lots of samples from some smartphones that were connected to Wi-Fi and LTE and basically in the same place at the same time comparing their performance. So they found that LTE is often actually better than Wi-Fi in terms of performance. And so it suggests that maybe there is not always just one default interface that we should use while ignoring the other one. So my research is basically in the scenario, which one would you pick? How do you pick the better one? Is even the better one or maybe can you use both at the same time? So right now, let's say we have this laptop. It has an interface called WN0 connected to a Wi-Fi network. It has a PPP0 connected to some cellular network. And now one of them is going to be the default interface and the other one basically never used. Which one is the default? I guess it depends on the routing configuration of the system. And there is some system-wide static default route usually. Like it's very simple. You look at the routing table and then there's the default route and you just use it. So one way where you could make use of the other interface as well is that you configure policy routing. So you configure two routing tables, one over the WLAN interface, one over the PPP interface. And then you can configure routing rules. So for example, if the application explicitly specifies one IP address of your configured addresses as a source, then it would go over this particular interface. So for several applications you could say, please always bind to that IP address and then it would go over this interface. So the problem with this is, okay, so first let's see. Let's take a look at the socket API, which is what many applications are using. And they are accessing the internet. So first they would resolve a name with get other info, just putting in a host name and getting back one or more IP addresses of the server that they are trying to connect to. Then they set up a socket with the socket call. And then optionally they can bind the socket to one of their local IP addresses. So here they could, at this point, they could make a decision as an application, okay, I got this and this IP address, so which interface would I actually prefer? And then it would connect to the server over this IP address and then close the socket like after doing whatever the application wants to do. So this is all good, but now we have many applications on the client. And if we think about that every application would have to implement its own decision logic to differentiate between the interfaces and to pick one of the interfaces or the other. And then also sometimes it's important what is the current performance of the interface. And so imagine that every application would have to periodically like monitor the interfaces, get some statistics on it, which one is currently used the most or maybe did I lose my, like did I lose performance? Or is the Wi-Fi congested something like this? So one problem would be that a lot of code would have to be duplicated within all the applications and it would also get really complicated. And the other one is that, so if we then try to unify this in some way, which is what we are doing with the socket-intense framework, then on the other hand you have the problem that the applications do have different requirements. Like if you just provide one single API and you say, okay, so now at one central library we always make the decision which interface would be better in this case, then maybe the same default interface doesn't always work for the different applications with their different needs and different kinds of traffic that they have. And so in the socket-intense framework we are trying to basically substitute this socket interface by a more enhanced API and provide a framework that manages different network interfaces and that can make decisions for the applications which of the available interfaces to use for example the next connection. So I'm going to explain how this works in a little more detail. So first socket-intense is a concept about the different requirements and needs of the applications. So by default through the socket interface the application can only basically say, okay, I want a TCP connection, I want a UDP connection, which is nice but over this connection there can be lots of different things, right, it can just be some small and short queries that just have to be finished as fast as possible. It could also be a huge file transfer and it could also be like a long-lived video streaming session. So one socket-intent that we introduce which is a piece of additional information that the application can give to the library and to the socket-intense library through the enhanced socket API is about the category of the traffic. So for example, is it a query, is it a stream, is it a bulk transfer? So we can differentiate between different connections that the application opens when we make our decisions later. And another intent would be the object size of the transfer. If it's a transfer then are we talking about a 10-kilobyte object or are we talking about 1 megabyte or 100 megabyte? Then also something about the duration, like is there a fixed duration that we know this connection is going to last? And then also about the timeliness which we named it, which is basically, is it a time-critical traffic, is it going to be something that the user is going to be interacting with or is it just in the background and we don't care if it's finished within five minutes or 10 minutes. So all these pieces of information are optional but the application can specify them as additional hints to the socket-intent library. And this can do this in the hope that then the library can make a better decision on which of the available interfaces would fit the requirements of the new connection from the application. So this is not quality of service. So there are no service guarantees. It's not intended that you specify I need 10 megabyte per second guaranteed bandwidth. But more like, okay, I would like some kind of like duration of a stream transfer and maybe you can set a bit rate. But it's not about guaranteeing anything. It's about the best effort of the system. And also if multiple applications would set these intents, then the system would have to balance their requirements in a fair way. So it's not about quality of service and it's also not about prioritization that one application says, okay, my traffic is now the most important. So yeah, this is the concept of socket-intents. And now we are building, oh yeah, resilience to connection loss, I forgot. So it's also a question of if this TCP connection was to be interrupted, how bad would it be? Is it just a transfer I can resume or is it like a stream that would get interrupted for the user? So our socket-intents library basically is sitting on top of the usual socket library that I already showed. The application would first use this. And yeah, so then the socket library, the socket-intents library talks to the multi-access manager, which is a standalone application. It's like a demon that runs once for the whole system and it gathers performance estimates from the interfaces that are currently configured. And then later on it has the task to choose an interface. So how it works is that there is an application that uses the socket-intents library. And yeah, it makes a request. It says, okay, I want to set up a new connection with these particular features or intents. Or like this is my idea of what to optimize for in this connection. And then the socket-intents library queries the multi-access manager says, okay, so this is all the application that I got from the information. Which interface do I use for it? What do you think? And then the multi-access manager has a policy which is a module that can be dynamically loaded. So also in different environments you can use different policies for choosing your interfaces. For example, the multi-access manager would then say, okay, you should use WLAN0 for this connection and it sends this information back to the socket-intents library which can then bite the connection to WLAN0 and connect the socket. So this is in a little more detail. So the application starts up and then the policy on the right which runs within the multi-access manager also starts up. And then the application can, for example, already specify its intents on some data structure that we pass to all our socket calls which are not on the slide, but we have to link the socket calls all together in some way. And for example, you can do it by handling socket context for the same connection. So you can do some setSocketOptCall that we extended by the socket-intents. And then when the application doesn't get other info to resolve a name, the Intents library makes the policy resolve that name. So why do we need rainbow solution here? Well, if you have multiple access networks which you connect to, then the same server might be reachable over both interfaces, but also maybe you're talking to a content delivery network and then there is multiple servers for the same host name. And then if you do a get other info over one interface, you get maybe a different set of IP addresses than if you do it over the other interface. And to our knowledge, there is not yet software in Linux that handles this explicitly that you can get different resolver responses over different interfaces. And then how do you manage it? If you then establish the connection later over one interface, but you use the IP address that you have resolved over the other interface, maybe your performance could suffer from it. And so this is what we're trying to address here when we already resolve the name in the policy and already choose some destination IP. So basically you could issue a DNS request over both interfaces at the same time and see what comes first. Or you could just make a decision and then choose which IP address to actually give back through the library to the application. And at that point, the application can set up its socket and then do a connect. So the application now does not have to call bind explicitly, but it can just call connect because the socket intense library internally handles the connect and like sends the connect request to the policy, which would then choose one of the local interfaces or choose the IP address that intense library then binds the socket to which already exists at that point. And then the application can do something on the socket and close the socket later. So yeah, this is the rather like basic classic socket API, which is also unfortunately blocking. We also have a few non-blocking libraries or APIs though for applications. And we, for example, have socket connect, which is another API that basically we developed. And the idea is that here we wanted to have just one call for the application that the application can say, hey, I want to connect to this URL on this board and with this intense for the connection. And then the socket intense library would give back a socket that is already connected to the application or it would, if it's not blocking, it would just give back like a placeholder that is going to be connected later and then the application can later use the socket like by Paul. And so the socket connect works kind of similarly, but the resolving and choosing of the destination IP and local IP address basically happen all in one call to the policy. So when it's called the very first time, then there is no existing socket. So the policy would basically find out the parameters for the socket that the application should use. And then the socket intense library sets up the socket and gives it back to the application. So now the application can use the socket for read, write, whatever. And then it does not have to close it yet. It can also use a socket release which says, okay, let's leave the socket open, but I don't need it anymore for now. And then for the next socket connect, the application might get the same socket back, but it might also get back a different socket like a new socket, for example. So here we can have several sockets that the socket instance library manages for the application and the application can just say, okay, now I want a socket that is suitable for this intent and now there's a socket that is suitable for like a different intent and then it doesn't have to care which interface it is. It can just use the socket that it gets from the intense library. So for example, if we have two interfaces and there is a TCP connection over one interface and there's one over the other interface, then you could do one HTTP request over the one TCP connection. You could do the next request over the other connection and use them in Barrel and also this works when you have more streams or when you have more TCP connections. So usually there would be like a number of connections open over both interfaces. And then for each request, like for example, if you're in a web browser and you're fetching a website with different objects, then you can fetch object one over like one interface and the next object over another connection over the same interface or maybe over a different interface. So with socket connect, you manage a set of sockets and the application doesn't have to consider which interface to use because it just always gets back a socket that it can use to read or write on. Most likely just first write and then read. Anyway, so yeah, but the socket connect API exists in different variants. Yeah, but the details are for example in the draft that I linked on the page of the talk and I can also give you the details if you're interested later. So yeah, these are two APIs that we developed and then we also developed policies which were the component just on the right that we saw. They are, they get as input the socket intents per connection or maybe per message per object what the application wants to do and then also it gathers the interface statistics passively. So right now we just observe existing traffic over the interface and we see like, okay, what are the round trip times of the TCP connections that already exists? What is like the minimum? What is the median? And try to guess something from these round trip times. And also we observe the interface counters and basically see, okay, what is the maximum change in interface counter which means like used bandwidth like send or received bytes that we see like per 100 milliseconds. And then we can have a guess about the capacity of the interface like at maximum download or upload bandwidth over the interface. And from these inputs, we can now choose a local interface. So simple baselines to compare against would be that we use only one of the interfaces or that we use both like one after the other in like around Robin fashion. So first interface one interface two then one and two and so on like always go back and forth. And then also we could have a policy that just always picks the interface with the lower RTT or that always picks the interface with the higher bandwidth. And then one policy that we developed is the earliest predicted arrival time or early arrival policy. And this one would now make use of the intent called object size. So the idea behind that is that if you have a large object, then you want to prefer the interface with the high bandwidth. But if you have a small object, then the interface with a lower RTT if it's a different interface would be more beneficial because for the small object, you don't need a high bandwidth, but you just want the download to be finished as fast as possible. But for the larger objects, a higher bandwidth is important because otherwise you will have to wait longer for your object. And so the policy basically tries to predict based on the interface statistics that it got previously. It tries to predict how long will I need over one interface, how long do I need over the other interface, and so which one do I prefer in this case. And then also, as I said already, it can choose a remote IP address among multiple resolved IP addresses. And also said arbitrary socket options. Actually we also have like, we have the option to switch on or to enable a multi-path TCP per connection. This is not something I evaluated yet, but like we also built this into the prototype. So the prototype is still being extended with like some of these nice features. So now I'm going to show you an evaluation setup that I'm currently working with. It's also fairly simple. So I don't use an actual LTE network, but I have a Wi-Fi and then an internet connection from a laptop that is going via a traffic shaper and then to a server. So the client runs a web browser and it uses the socket intense framework for its connections. And then the traffic shaper can emulate different network conditions like you can specify an RTT that is imposed on all the traffic that goes through all of these networks and you can shape the bandwidth. You can limit the bandwidth that can go through the shaper and also you can configure packet loss on the traffic. So yeah, I emulate different network conditions on both paths basically. And then there's the web server which can or which hosts different web pages of different sizes. And so far it's just a static workload like just some websites with a number of images, which I'm going to show you on the next slide. So this is going to be the details of like a preliminary evaluation that I'm doing right now because right now I'm still like trying out which are the best policies and how to optimize the performance for example for web browsing. So in this case the connection on the top in green is over the Wi-Fi interface and it has a shaped RTT of only 10 milliseconds. So it's quite fast but also it only has 2 megabit per second as a download bandwidth which is like not a lot and in blue on the bottom over the ethernet I shaped a RTT of 100 milliseconds but of 20 megabit per second downstream. So here again the idea is that for very small queries, very small objects you would prefer the one in green with the Wi-Fi interface with 10 milliseconds and for larger objects you would prefer the one with 20 megabit per second download because that would be the faster one in each case. So the websites I have more websites but these are the ones that I'm going to be showing and the plot on the next slide is there's one static website where it's one HTML file and then for 10 kilobyte images or 8 kilobyte images or 16 images or 400 kilobyte images and usually webpages are going to be more objects and bigger sizes but the evaluation is going to continue in that direction to more realistic workloads and websites. And then the policies that I used for this preliminary evaluation that I'm going to be showing is only over one interface WLAN0 only over ETH0, the other interface and then both with the earliest arrival policy that for each of the objects predicts the download time and then uses either WLAN0 or ETH0. So here is my plot. So on the x-axis you see the different scenarios like this is 10 kilobyte 4 images, 10 kilobyte 8 images, 10 kilobyte 16 and 100 kilobyte 4 images and basically always the socket intense then ETH0 only and then WLAN0 only and on the y-axis is the page load time in seconds and it's like between 0.3 and 1.8 or so seconds for this particular quite small workload. So these are box plots so they show of different of many repetitions they show you the median basically and then in some cases like from where to where did we see values. So for the very small page of only 4 images of 10 kilobyte ETH0 was apparently quite fast because lower is better of course for page load time and WLAN0 was slower and then socket intense used ETH0 the faster interface basically. Also in this case so WLAN is slower so socket intense uses the better interface but then as the images get more or the workload gets bigger at some point WLAN which had the higher bandwidth becomes better because if we are going to download many more images then at some point the bandwidth is going to get clogged on a 2 megabyte interface and so here socket intense uses the WLAN0 interface because it's faster and then the last case is particularly nice because here we use a combination so this one is up here the ETH0 interface has now become actually quite slow because it has only 2 megabyte per second download bandwidth and WLAN is way faster but then socket intense is even faster because it can make use of both interfaces. So as I said this is only a preliminary evaluation and right now I'm working on a like more extensive one and improving my policies and the matrix and performance estimates that I get from the interfaces. So yeah so keeping in mind that this is a research prototype and not a production code still I'm wondering if like okay so for socket intense the application needs to be modified I'm aware that this is going to be quite hard like I'm not expecting that every browser is going to support socket intense in the future but still it's a question of like how to get applications to use socket intense or something like this or how to how should the application if it should do it communicate its needs or expectations about the traffic and then also how to come up with smarter policies to choose between network interfaces and also which I find an interesting question how to integrate this with other Linux user space software or what networking libraries exist that could inform the socket intense framework or vice versa or yeah how does it work so if anybody has any input or questions on this I'm looking forward to that. So this is my summary so the goal of my research is to use multiple network interfaces the prototype we developed is called socket intense it's a networking library in user space which applications can do can specify can use to specify what it knows about its traffic and then to get like to get its interface picked basically through the multi access manager which chooses the best option and the code is on GitHub and it's released under a BST license so you can check it out you can play around with it and yeah you can talk to us about it so for contacting me Teresa at INET because it's like part of my research but I'm also on Twitter and I'm on Mustodon so if you don't know Mustodon already you should check it out because actually on Mustodon I write more technical stuff and on Twitter it's more like activism so it's Mustodon is basically Twitter but better okay enough ads okay and then I'm also on LinkedIn if that's your thing or I'm also on GitHub. Alright so thank you for your attention and now I think we have a little time for questions if there are any seven minutes I see. Yeah. Hello my name is Luba I work on network manager so this sort of interests me what you said I do have a question I'm wondering you said you do passive monitoring to assess the properties of the interfaces that for the policy to take decisions and I'm wondering how does this work like from the very beginning like when you I suppose you don't have any information then so suppose you start with a slow mobile broadband and the gigabit Ethernet due to round robin from the beginning. Yeah so what we do is that in the multi-access manager we have this callback which currently gets invoked every 100 seconds and then it basically reads out all the statistics like through netlink and from the interface counters that it can find but we assume that there is already ongoing traffic on the system and yeah it needs to be bootstrapped somehow and I guess for the first few requests we should use a sort of round robin but like this kind of thing is what I'm like currently still working on like what is the best way to gather these statistics I'm yeah I also think that this kind of thing could be like coordinated between different processes that actually have an interest in like which interface is the best also we monitor some Wi-Fi statistics like through netlink you can get signal strength and the currently used or the last used modulation rate and also we are working on like looking into how we can get the QBSS information like from the access point which can insert basically the current utilization of the channel which is really interesting because the signal strength it can like up to a point it doesn't matter so much if the signal strength is really good or not so good but the utilization of the medium like how many clients are there and how much traffic are they sending is really interesting and so like we are also gathering these kinds of statistics. Thanks. You also had a question? So did I get it right that it's for client side of the connection or it might be also useful for server side? It could also be used for a server side so the library is not limited to that so for example it could also be used in like in a data center where there's a multi-homed server that wants to open like different connections for different kinds of workloads so I haven't explored that yet and I'm like more interested in the client side but yeah I think it would be possible. I don't know about the exact like networking libraries that exist for the server side but I guess it would be possible. As long as you at some point either establish a connection or you say okay now I have something like some traffic to send now I have something to do please give me a socket to do it. Should be possible. I was wondering about if you've got a lot of interfaces especially if you've got also open VPN interfaces those pseudo interfaces is this library smart enough to well basically use the right one because if you use an open VPN you don't want things to go over the unencrypted channels. Yeah sure. Yes you could configure these things in the policy so in the policy you can configure which interface you want to have considered at all so if you have an interface that you deem insecure then you wouldn't consider it at all maybe and we don't have a security intent so far but we could edit. I was wondering if you tested with so you did some simulation with limited bandwidth for example do you change that limit over time. Not yet but yeah that's also something that is planned because of course the mobile performance is can also be very flaky but what we did do is that we introduce a cross traffic on the wireless channel from multiple clients and then of course we see the performance drastically drop like no matter what is shaped later on if there is many clients on your channel or if your signal gets bad then at some point you're going to like see the performance change but with these dynamic network conditions it's also an interesting question so I set this framework up and now I can play around with like lots of different scenarios. Have you tried to model what kind of effects in the case of the Wi-Fi and the LTE which is a very common case have you tried to model what kind of effects it would have if you turn this on because you know LTE is generally more of a scarce resource so if everyone started acting like rationally but selfishly would you come you know do you think you'd come into a situation where the overall network is worse overall because everybody is acting rationally. Yeah I have looked into like or like we started considering some communication with the network like of course from the access point we can have the medium utilization but from the LTE network I think we don't get as much information right but then yeah I already looked into how you could coordinate different clients but I like don't have a ready simulation of it yet but it's also an interesting question also there is one socket intent that I didn't mention that is basically about for this connection would it be okay to use something that costs money or like that uses up your data your data mobile data thing or not and so this we also have like in mind. Have you given it some thought how you would integrate this with applications sandboxing especially mobile devices you generally don't want applications accessing through arbitrary network interfaces but why the white listed one. So mobile sandboxing we haven't done yet so far or prototype runs on the on a notebook with either like Linux or Mac OS and I mostly with Linux and yeah but you have to figure out in the policy you would have to figure out these kinds of things I think like what are the needs of the application and what are the system wide policies and what are the users like preference preferences but also how much is who able to control so this kind of policy framework like with all the different inputs to the potential policies is something that I'm also exploring right now and also my colleague and I are participating in the tabs working group at the IETF which is about choosing between different transport protocols mostly but there we also have like some kind of okay what is the policy like when do we use what kind of transport protocol and what are the different inputs so we are also like discussing this with like the wider community like what are policies and how do they work. Yeah thanks so I think we had one more minute but if there's no more questions here I'm also happy to chat about this later on. Thank you.
on the Internet over both these interfaces. So one IP address of your configured addresses as a actually prefer? And then it would connect to the between the interfaces and to pick one of the you have the problem that the applications do available interfaces to use for example the next default through the socket interface the decision on which of the available interfaces from the application. So this is not quality of use an actual LTE network, but I have a Wi-Fi and are the best policies and how to optimize the is a research prototype and not a production code multiple network interfaces the prototype we applications can do can specify can use to specify what it knows about its traffic and then when do we use what kind of transport protocol