 Hello, I'm Teresa and I'm a PhD candidate and researcher at Tew Berlin. I'm going to be talking about the future of networking APIs today, which is part of some work that we're doing in the ITF in the TAPS working group right now. And so basically, why do we need a new networking API, right? It is because networking is actually pretty complicated. Let's assume we are the laptop here and it wants to, yeah, this laptop wants to connect to the server through a network and it's connected to the Wi-Fi via some local access point. So first it resorts a host name for the server and it gets back maybe an IPv4 and IPv6 address or multiple and then it just tries to connect to that address, right? And first problem, oh, IPv6 failed for some reason, we don't really know why, all right? Now our application hopefully notices that at some point and doesn't come back with everything failed but it remembers that there's still IPv4 and so it can connect to the server and basically implement this fallback itself probably, right? And then there could also be a different option to connect to the same server because maybe our Wi-Fi is actually really shitty, maybe we are in some, I don't know, in some cafe and the Wi-Fi hotspot is really congested and we need kind of a better connection to that server so maybe it would be an option to go through a different interface from the same computer but how do we really know about it within the operating system or within the application? Right now the application would have to discover somehow that there is this different interface and then it would have to use this path, basically pick this path itself and also monitor whether which of the paths is better and then there might also be an alternate server over this other path because we could resolve the same name on different networks and then maybe we get different answers based on which network we actually resolve the name on and then, yeah, we have to pick which of those remote IP addresses we actually connect to and then also maybe we want to speak a different transport protocol because TCP is nice but now there's also quick and we don't really know beforehand which one will be available, we could try out both but again with the socket API because the socket API provides a very basic abstraction our application would have to do all this by itself or like some library within the networking stack of the operating system obviously but the point is that for all these different options there's just a lot of choice and it's getting more complex and right now applications are not always benefiting from all this diversity of different paths, different endpoints and different transport protocols and then also like IPv4 versus v6, is there a fallback, is it working in a smart way so the point is networking is more complex than just opening a single bit pipe to some endpoint that we know and yeah, maybe we can have something better with that and that is what we are trying to do with this new abstraction for an API so the new API should hide the complexity of the network so the application doesn't have to discover the different paths discover the different endpoints, discover the different transport protocols, set up this socket then try this other socket if the first one didn't work but it should just say I want a connection and then it should get its connection and whatever happens underneath should not be the problem of the application so that is what I mean by hiding the complexity then it would be nice to choose the best option we are not always sure which is the best option this is something I actually talked about last year here that is part of the research that I'm doing but there should be some way within or beneath this API to optimize these choices and then also a very important point is that our API should stay stable if new protocols are being developed so now we have quick as a new transport protocol we don't know maybe this is the start of a new family of transport protocols or we don't know what protocols are going to be developed in the future but do we really have to bother the application with this and does the application have to change if a new protocol is developed? well it shouldn't, right? so TAPS is now a proposed abstraction for such an API so the work I'm presenting is one this is work in progress and some of the details might change I'm presenting it based on the drafts in the version 01 but we are still working on them and like figuring out the details and then another thing is that this is not one specific implementation but it's a proposed abstraction for an API so it is the principles of how such an API should work and then there is implementations that actually I'm going to talk about at the end so yeah something more about how this abstraction should work well if you want to hide whether it's an IPv4 or an IPv6 address you can just give your application a hostname that it wanted to connect to and maybe some more details like security related to make sure that that all works out but you don't actually have to give your application an IPv4 or IPv6 address you can just work based on some remote endpoint identifier for example a hostname about paths well the application doesn't always have to know which local interface it is using of course maybe the application wants to voice a preference do not use the cellular ever because it might cost the user money for example but if it doesn't say anything or maybe there's also a default policy the application doesn't need to be the only one that knows about the paths and then also and then about the protocols well is there a way to abstract protocols we have every basic abstraction in the socket API there's basically stream protocols and datacram protocols and stream protocol is right now basically always TCP datacram is always UDP so that is that goes in this direction of just telling us about the generic feature of the transport protocol but in our opinion it doesn't go far enough so the first steps in the transport services working group tabs is that we abstracted features of existing transport protocols for example reliable data transfer does the protocol have it or not and or some more fancy features for example multi-path so this multi-path TCP or for example for some for STTP you the stream control transmission protocol you can have like different messages and then configure stuff on the different messages and you have different streams and yeah so there's features that different transport protocols have that maybe many developers have never heard about and we don't want them to have to learn all the details of these protocols but they have to just say I want this feature on my connection it needs to be reliable or maybe there is this part that needs to be reliable and this other part doesn't need to be reliable because either it arrives and then that's good or if it doesn't arrive I don't want to bother resending it so the application could just ask for abstract features of transport protocols and then there's a set of transport features that comprises a transport service which corresponds to like what a transport protocol can offer but that would not be tied to a specific transport protocol but okay that is just some details on terminology the important point is that the application specifies a transport feature and the transport system then based on those requirements picks a transport protocol it might be TCP but it might also be something else that the application developer has never heard about and does not need to hear about so yeah then that would mean that the application says something like this something hopefully rather basic it can also be more complicated of course some applications want to optimize low-level networking details they can still do that through our API but maybe it only wants to say these three things and then the tabs API gives back not one socket where you can either send or not but it can give back a connection object and on this connection that is going to be a valid connection at some point a valid transport layer connection to some end point the application can send messages and then later it's also going to receive messages on it and it doesn't have to care about the details of the protocols or paths right so a few more details on how we how this looks like or what this looks like in our current draft and you can also read up on the details I hope I hope that a new a new version gets published in like a few weeks time we have this notion of a pre-connection in the API an application would set up some kind of like prototype or some some kind of thing that it wants a connection to be later on and that one can be reused it could specify a remote end point that it wants to connect to for example based on a host name it could specify some properties that I'm going to talk about on one of the next slides and then it can also specify security parameters for example some private keys or some some crypto algorithms that it wants to use or not and then after it has set up this pre-connection object that is basically a template for what the new connection should look like it would call initiate on the pre-connection and get back this connection and underneath within the API now the API would first start by resolving the name maybe over all the different interfaces it would get some information maybe from its cash about how what what transport protocols it knows are available what protocols might work over this path and which ones it wants to try first and then the the transport system does something and the application will at some point get a callback when the actual connection has been established and so it only has to call initiate once and then it either it gets the connected event at some point if any connection could be established at all with the properties that were specified or maybe it would get a connection error if that was not possible but here the optimization doesn't have to happen above the API but below the API and now it can send messages and it can also receive messages on it now to specify an endpoint it could yeah it could specify a host name and a service or also it could also specify an IP address of course and then the remote specifier can also be reused for multiple connections or rather multiple pre connections maybe even with different results and now the transport properties transport properties are fun because those are the transport features that I mentioned earlier do I want reliable data transfer do I want to configure checksums you can configure in UDP light you can configure whether you want to check some to cover all the package or just part of the packages some very like specific features that some transport protocols have I was also surprised when reading about them and so if you are if you're interested in those kind of details you can also find them in the draft but let's just say the application requires some reliable data transfer and that is a require it could also just say I have a preference for this specific kind of feature or I want to avoid a protocol that has this specific kind of feature or even prohibit and then it can also add some more properties to this precon or to this transport properties object that is then going to be tied to the pre connection for example we have this nice thing called capacity profile which says which says do I want the new connection to be optimized for low latency or would I like to optimize it for high bandwidth and based on that the transport system could do different things enable some algorithms or choose a different path maybe also maybe this is just background traffic and I just wanted to run in we call that scavenger mode where it just takes all the capacity that it can if nobody else is using it that would be a different congestion control algorithm so there's this additional information that the application could add for this new connection and then also the interface it could say please avoid cellular interfaces but I think if you have a preference either for cellular or Wi-Fi interfaces oftentimes it's kind of you actually want to say a different thing maybe you want to say oh I think cellular is going to cost money so let's go over the Wi-Fi because the Wi-Fi is not going to cost money but is this always the case right and will this stay the case in the future at all the time so we would also introduce some features that can that you can express explicitly what you want or what you don't want and then you don't have to tell us the actual interface you can just say I don't want an interface that might cost the user money or maybe I'm okay with picking an interface that costs the user money or maybe it's just a backup path or something like this but that is some way more high level information that the application would give us then if it has to take care of is there a cellular interface and can we like ask the user for permission whether we can use it and that is why we chose yeah we chose this abstraction of properties and we are like right now figuring out which properties we actually need and how we actually represent them but so far we got we got so far that we know there will be requirements there will be preferences and there will also be hints of what to avoid and what to prohibit and then as I said it's also possible to ask for a specific feature of a specific transport protocol if you pick TCP then please don't do use this option for example because some applications really want that all right now that we have specified transport properties let's also just quickly take a look at the security parameters for example you can add a pre-shared key you can add an at a private key or you can add some information on crypto algorithms because we want security to be an integral part of this API doesn't mean we always have to bother the application with it again but it would be nicer if this API like if this API just tried to pick a secure transport protocol that could be TLS over TCP by default even if the application doesn't request that explicitly and then we would initiate this connection and now as I as I said earlier the application just calls initiate and it can then just wait for the callback to happen and beneath the transport system will resolve host names will gather protocol and path candidates and it sorts those candidates in some order for example whether the transport protocol meets these preferred features that the application wanted or whether it does not meet those features and then it will it will sort them in a kind of order in which to try them so it would start with the first option of combination of a local interface and transport protocol and a specific endpoint it would try to establish a combination on a connection on that and then if it doesn't work maybe after a hundred milliseconds or some other time out it would try a different protocol and then at some point when it has successfully established the connection it would generate the ready events and then the application knows the connection is ready all right then there's messages that you can send over these connections and receive over these connections the interesting part here is one that we introduced the concept of framers TCP doesn't provide framed messages right HTTP has to do that you have to do the framing in HTTP but if the application just wants to send and receive an HTTP message maybe the HTTP library would implement the framework you can just plug into the tabs API and then the application that works on top of HTTP can just get an HTTP message and send an HTTP message so there's this nice concept and then also messages can have their own properties too for example maybe one message has a different priority than the other we call this niceness which is the inverse of property and we also have a lifetime attribute for the messages and now of course a connection might also fail and you can get the send error you can get a connection error you can get a close all right now about implementations which I think is the most interesting part for this crowd as I said this is a proposed abstraction for such an API and now it needs to be implemented and there is the socket intense prototype which is a part of my research which I talked about last year at this conference it's a research prototype it does not do transport protocol selection but path selection and there is the need API need was a EU project that developed a lot of this transport feature stuff also and implements I think a lot of it it's also research prototype and a famous quote by one of the authors is well it's open source somebody should develop it but it's not me right now right so this code is there but I'm not sure how much it's going to be like how much it's going to advance and like to to get closer to the API that we're now actually developing oops and then one other nice implementation but rather closed is the Apple network framework application they had a talk this year at their developer conference where they introduced it was a really nice talk but you know I can't look at the code it would be nice to have more implementations anyway so maybe and I would really like that maybe you would have some implementation of this API that runs on Linux and yeah that we can play with and that might also at some point become one viable choice for an application developed on Linux for its networking so applications can benefit from all this nice networking stuff without having to do it all by themselves so that is something that I dream about but for now I would just invite you to read our drafts I linked the zero one versions on the on the page for this talk in the schedule but also you can just go to the data tracker and get the most current versions you can comment on our drafts on the mailing list or on github where we are where we are collaborating on those drafts and you can play with the implementations which are also linked on the page in the schedule I think at least needs and socket intense and maybe make your own I'm I mean yeah one can dream right all right so just to wrap it up the socket API is a very simple abstraction for networking it's too complex or it puts a too high burden on the application for dealing with all this complexity and now the tabs API could provide a better abstraction for addresses protocols path so the application doesn't have to deal with the low-level networking details and it would hopefully stay stable as new protocols are being developed the steps API or the steps abstraction for an API is being standardized in the ITF and we would like more implementations and we also would like more people to read our drafts with this thank you and are any questions do you expect that the new kernel features will be required I'm sorry what do you expect that new kernel features will be required you kernel features I don't think so because we only right now we only provide features that are already implemented in transport protocols today and but I think this can be probably implemented on top of the office socket API but yeah I'm not sure but I don't think so is there any buy-in for for from vendors at this point which are the libc developers and Android Google Apple Microsoft basically I'm not currently aware of anybody from Google who is actively developing anything like in this or from Android that would be nice but I'm I tried asking somebody they didn't reply to me something I know that Apple is in there and I know there has been a person from Microsoft but about Android I don't know I don't think there is anybody right now last question I am a bit concerned about having too much freedom in choosing transport protocol I fear that having having to attempt multiple protocols who will cause higher latencies in the new connections as this being discussed does it support SRV records in the DNS what is the plan thank you well and does it support SRV records well an implementation would have to do that right now we don't have anything about it in our drafts but maybe if you can take a look at our drafts and like write a question on the mailing list that would be nice about the other stuff yeah of course it would introduce new latency if you have to if you have to try another transport protocol first but you know the transport protocols is just one thing that you can try you can also just try the safe option that you know works and then you have it so we would of course not introduce it want to introduce additional latency for an application just because we want to try out some we had new features right he stops offering anything server side or is it only client side it's also server side as example I know used is a client side but it's also possible to have a listener which is another object than a connection in wait no you can have a pre-connection and then you can turn this pre-connection into either via initiate you initiate a connection or you do listen and then you have a listener and then you listen for incoming connections and you have specified the features on the pre-connection so the listener also has like these features but it it will probably be implemented a little differently but yeah this is supposed to be working both for initiating and listening and also rendezvous which is peer-to-peer we also have a person in the on the draft who knows a lot about peer-to-peer it's not me but yeah so thanks a lot Teresa and for sure we are the time but I guess there will always be the hallway track so thanks and another round of applause