The Future of Networking APIs
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 50 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/43127 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
All Systems Go! 201812 / 50
1
4
11
12
13
14
16
17
19
23
24
25
29
30
32
34
35
39
40
41
43
44
50
00:00
SpacetimeSystem programmingComputer networkComputer configurationSanitary sewerMobile appGroup actionComputer networkLecture/ConferenceComputer animation
00:31
Server (computing)Computer configurationFatou-MengeComputer networkServer (computing)LaptopTopological vector spaceLocal ringPoint (geometry)Multiplication
01:00
Server (computing)Computer configurationSystem programmingComputer networkSocket-SchnittstelleDifferent (Kate Ryan album)AbstractionKolmogorov complexityService (economics)Address spaceCommunications protocolStack (abstract data type)IP addressPoint (geometry)Remote procedure callLibrary (computing)BitAbstractionMereologySingle-precision floating-point formatCommunications protocolService (economics)Cartesian coordinate systemNetwork socketComputer networkGroup actionInterface (computing)Computer configurationOperating systemLatent heatImplementationServer (computing)Arithmetic progressionConnected spaceRevision controlStreaming mediaDefault (computer science)FamilyDifferent (Kate Ryan album)Axiom of choiceComplex (psychology)Direction (geometry)Covering spaceNeuroinformatikTrailGateway (telecommunications)Graph coloringComputer data loggingStorage area networkBeat (acoustics)Moment <Mathematik>Selectivity (electronic)Open setProduct (business)Information securitySoftware developerTable (information)Ring (mathematics)Device driverMathematicsPresentation of a groupProcess (computing)InternetworkingLattice (order)1 (number)XML
07:20
Address spaceCommunications protocolService (economics)TransportprotokollSystem programmingHeat transferServer (computing)Interface (computing)Manufacturing execution systemCellular automatonSystem callEvent horizonPoint (geometry)Error messageObject (grammar)Cartesian coordinate systemCache (computing)Abstraction1 (number)Template (C++)Communications protocolPhysical systemInformationChannel capacityConnected spaceMathematical optimizationNetwork socketLatent heatResultantMereologyDifferent (Kate Ryan album)Software developerData transmissionMessage passingSet (mathematics)Heat transferStreaming mediaGame controllerInformation securityCategory of beingComputer networkMultiplication signPrototypeRevision controlRemote procedure callAlgorithmValidity (statistics)MultiplicationDimensional analysisWeb pageService (economics)Interface (computing)Information and communications technologyTwitterWaveLevel (video gaming)FreezingSource codeSoftware development kitGodElectronic visual displayLine (geometry)Machine visionGroup actionPlastikkarte
13:40
Cellular automatonCommunications protocolInformation securitySystem programmingError messageNetwork socketComputer networkSoftware frameworkImplementationFingerprintFreewareReading (process)Cartesian coordinate systemInformationChannel capacityÜberlastkontrolleDifferent (Kate Ryan album)Data conversionGame controllerCartesian coordinate systemCategory of beingInterface (computing)CodeInformation securityMereologyInverse elementAttribute grammarAuthorizationCellular automatonOpen setSelectivity (electronic)Projective planeMessage passingConnected spaceCASE <Informatik>ImplementationSoftware developerWeb pageRevision controlTap (transformer)Point (geometry)Physical systemQuicksortNetwork socketAxiom of choiceArithmetic meanResolvent formalismComputer networkCommunications protocolLatent heatBackupCryptographyComputer configurationEmailElectronic mailing listAbstractionFrame problemLibrary (computing)Combinational logicOrder (biology)WhiteboardComplex (psychology)HypermediaPrototypeLink (knot theory)Local ringRight anglePerimeterOverlay-NetzMobile appSoftware frameworkProduct (business)Inclusion mapSpecial unitary groupMultiplication signEvent horizonInternetworkingOpen sourceGodLevel (video gaming)Moment (mathematics)WaveView (database)Game theoryBit rateDeutscher FilmpreisStability theoryForm (programming)Numbering schemeLattice (order)XMLComputer animation
21:41
Physical systemKernel (computing)Roundness (object)Cartesian coordinate systemObject (grammar)Connected spaceCommunications protocolRight angleImplementationGoogolAndroid (robot)Network socketComputer configurationRow (database)EmailMusical ensembleService (economics)Projective planeSoftware development kitMeeting/Interview
25:11
System programmingResonator
Transcript: English(auto-generated)
00:06
Hello, I'm Teresa and I'm a PhD candidate and researcher at TU 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 TABS Working Group right now.
00:24
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 connect to the server through a network
00:44
and it's connected to the Wi-Fi via some local access point, so first it resolves a host name for the server and it gets back maybe an IPv4 and an IPv6 address or multiple and then it just tries to connect to that address, right? And first problem, IPv6 failed for some reason.
01:06
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?
01:25
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
01:43
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
02:07
and also monitor whether like 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
02:24
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 QUIC and we don't really know beforehand
02:45
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
03:02
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
03:20
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
03:45
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
04:03
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 complexity, then it would be nice to choose the best option,
04:22
we are not always sure which is the best option, this is something I actually talked about last year here, this is part of the research that I am doing, but there should be some way within this or beneath this API to optimise these choices and then also very important point is that our API should stay stable if new protocols are being developed, so now we have QUIC as a new
04:47
transport protocol, we don't know, maybe this is the start of like 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
05:03
change if a new protocol is developed? Well, it shouldn't, right? So Tabs 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,
05:21
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.
05:48
So, yes, 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 host name that it wanted to connect to, and maybe some more details like security-related to make sure that that
06:06
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 host name. About paths, well, the application doesn't always have to know which
06:22
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.
06:42
And then also about the protocols, well, is there a way to abstract protocols? We have every basic abstraction in the socket API, there is basically stream protocols and data cram protocols, and stream protocol is right now basically always TCP, data cram is always UDP,
07:01
so that goes in this direction of just telling us about a 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,
07:21
for example, reliable data transfer, does the protocol have it or not? Or some more fancy features, for example, multipath, so there's multipath TCP, or, for example, for some, for SCTP, the stream control transmission protocol, you can have different messages
07:41
and then configure stuff on the different messages, and you have different streams, and, yes, 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
08:02
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
08:26
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 a transport
08:43
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, yes, that would mean that the application says something like this,
09:02
something hopefully rather basic. It can also be more complicated. Of course, some applications want to optimise 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
09:20
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.
09:44
So, a few more details on how this looks like, or what this looks like in our current draft, and you can also read up on the details. I hope that a new version gets published in like
10:01
a few weeks' time. We have this notion of a preconnection in the API. An application would set up some kind of like prototype or 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,
10:25
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 crypto algorithms that it wants to use or not, and then, after it
10:47
has set up this preconnection object that is basically a template for what the new connection should look like, it would call initiate on the preconnection and get back this connection, and, underneath, within the API, now, the API would first start by resolving the name,
11:02
maybe over all the different interfaces, it would get some information maybe from its cache about how what transfer protocols it knows are available, what protocols might work over this path, and which ones it wants to try first, and then the transport system does something,
11:23
and the application will at some point get a call back when the actual connection has been established, and so it only has to call initiate once, and then 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,
11:44
but here, the optimisation 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 end point, it could specify a host name and a service, or also it could also specify an IP address,
12:03
of course, and then the remote specifier can also be reused for multiple connections or rather multiple preconnections, maybe even with different results. And now the transport properties. Transport properties are fun because those are the transport features that I mentioned
12:21
earlier. Do I want reliable data transfer? Do I want to configure checksums? You can configure, in UDPLite, you can configure whether you want the checksum to cover all the package or just part of the packages, some very specific features that some transport protocols have. I was also surprised when reading about them, and so if you are interested in those kind of
12:42
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
13:02
or even prohibit, and then it can also add some more properties to this transport properties object that is then going to be tied to the preconnection. For example, we have this thing called capacity profile, which says do I want the new connection to be optimised for
13:21
low latency, or would I like to optimise it for high bandwidth, and based on that, the transport system could do different things, enable some algorithms, or choose a different path maybe, or also maybe this is just background traffic, and I just wanted to run in, we call
13:40
it 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
14:07
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
14:23
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
14:40
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, than 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
15:06
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
15:25
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.
15:44
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-share key, you can add an add 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
16:04
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
16:20
request that explicitly, and then we would initiate this connection, and now 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,
16:43
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 sort them in a kind of order in which to try them, so it would start with
17:02
the first option of a combination of a local interface, a transport protocol, and a specific endpoint, it will try to establish a combination on that, and then if it doesn't work maybe after 100 milliseconds or some other timeout, it would try a different protocol, and then at some point
17:26
when it has successfully established a connection, it would generate the ready event, 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
17:43
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 framer, you can just plug into the TAPS API and then the application that works on top of HTTP
18:06
can just get an HTTP message and send an HTTP message, so there's this nice concept and then 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
18:24
have a lifetime attribute for the messages, and now of course a connection might also fail, and you can get a 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,
18:41
as I said, this is a proposed abstraction for such an API, and now it needs to be implemented, and there is a socket-intense prototype, which is 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 an EU project that developed
19:06
a lot of this transport feature stuff also, and implements, I think, a lot of it. It's also a 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,
19:24
but I'm not sure how much it's going to be, like, how much it's going to advance and, like, 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
19:45
this year at the developer conference where they introduced it, 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 we would have some implementation of this API that
20:03
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.
20:24
So that is something that I dream about, but for now, I would just invite you to read our drafts. I linked the 01 versions 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
20:42
on the mailing list or on GitHub 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 neat and socket intense, and maybe make your own. I mean, yeah, one can dream, right?
21:01
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, paths, so the application doesn't have to deal with the low-level networking details,
21:24
and it would hopefully stay stable as new protocols are being developed. The steps API or the steps abstraction for an API is being standardised in the IETF, and we would like more implementations, and we also would like more people to read our drafts. With this, thank you, and are there any questions?
21:50
Do you expect that new kernel features will be required? I'm sorry, what? Do you expect that new kernel features will be required? New kernel features, I don't think so, because we only, right now we only provide
22:05
features that are already implemented in transport protocols today, but I think this can be probably implemented on top of the socket API, but yes, I'm not sure, but I don't think so.
22:23
Is there any buy-in from vendors at this point, which are the libc developers, Android, Google, Apple, Microsoft, basically? I am not currently aware of anybody from Google who is actively developing anything like
22:42
in this, or from Android. That would be nice, but I tried asking somebody, they didn't reply to me. 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.
23:01
I am a bit concerned about having too much freedom in choosing a transport protocol. I fear that having to attempt multiple protocols will cause higher latencies in new connections.
23:20
Has this been discussed? Does it support SRV records in the DNS? What is the plan? Thank you. Well, 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 write a question on the mailing list, that would be nice.
23:41
About the other stuff, of course it would introduce new latency if you have to try another transport protocol first, but the transport protocol 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 want to introduce additional latency for an application just
24:05
because we want to try out some weird new features, right? Is Tabs offering anything server-side or is it only client-side? It's also server-side. The example I now use is client-side, but it's also possible to have a listener,
24:23
which is another object than a connection. Wait, no. You can have a preconnection and then you can turn this preconnection 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
24:42
preconnection, so the listener also has these features, but 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 on the draft who knows a lot about peer-to-peer, it's not me.
25:01
Thanks a lot, Theresa. Unfortunately, we're out of time, but I guess there will always be the hallway track, so thanks and another round of applause.