TAPS Transport Services API
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Untertitel |
| |
| Serientitel | ||
| Anzahl der Teile | 102 | |
| Autor | ||
| Lizenz | CC-Namensnennung 4.0 International: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/43259 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
Chaos Communication Camp 201928 / 102
1
6
8
14
17
18
19
20
25
27
28
29
30
34
35
36
39
41
47
52
53
54
55
58
59
63
65
67
71
79
81
84
85
86
87
91
92
93
94
95
96
97
98
99
100
101
00:00
UnordnungTelekommunikationSocketUnrundheitSocketARM <Computerarchitektur>Dienst <Informatik>Arithmetische FolgeSchaltwerkGruppenoperationReibungswärmeDruckspannungJSONXMLVorlesung/KonferenzUML
00:54
SocketDruckspannungSocketInternetworkingReibungswärmeTLSQuick-SortImplementierungARM <Computerarchitektur>JSONXMLUMLVorlesung/Konferenz
01:29
Physikalisches SystemTemplateSocketInterprozesskommunikationVirtualisierungDateiverwaltungSocketElektronische PublikationMaßerweiterungProzess <Informatik>InternetworkingMultiplikationsoperatorGruppenoperationGanze FunktionPhysikalischer EffektTelekommunikationCASE <Informatik>SystemaufrufTUNIS <Programm>Hinterlegungsverfahren <Kryptologie>Virtuelle MaschineComputeranimation
02:25
SocketSocket-SchnittstelleSoftwareStreaming <Kommunikationstechnik>TemplatePublic-domain-SoftwareBildschirmfensterGamecontrollerElektronische PublikationProtokoll <Datenverarbeitungssystem>Message-PassingBildgebendes VerfahrenTouchscreenTreiber <Programm>DigitaltechnikVorlesung/Konferenz
03:42
ProgrammierungSocket-SchnittstelleRechnernetzVolumenServerFehlermeldungSocketBitSocketKlassische PhysikMailing-ListeBitrateAuflösung <Mathematik>SkriptspracheProgrammMobiles InternetBildgebendes VerfahrenRechenwerkVerschlingungResultanteGanze ZahlProgrammschemaElektronische PublikationKonfigurationsraumInformationSystemaufrufLoopParametersystemComputeranimation
05:25
HalbleiterspeicherInternetworkingProtokoll <Datenverarbeitungssystem>ProgrammierungRechnernetzSocket-SchnittstelleVolumenServerParallele SchnittstelleFehlermeldungSocketComputersicherheitParallelrechnerInternetworkingMessage-PassingSoftwareMomentenproblemGroßrechnerZweiBasis <Mathematik>CodeEinfach zusammenhängender RaumChiffrierungModemDifferenteResolventeResultanteDirekte numerische SimulationVerschlingungBenutzerbeteiligungQuantenzustandInformationLoopComputersicherheitLuenberger-BeobachterSchlüsselverwaltungSocketStrömungsrichtungProgrammImplementierungBrowserWeb SiteSchreib-Lese-KopfProtokoll <Datenverarbeitungssystem>MultiplikationProgrammbibliothekMereologieHecke-OperatorNetzadresseKeller <Informatik>Interface <Schaltung>Lesen <Datenverarbeitung>Kartesische KoordinatenGrenzschichtablösungTrennschärfe <Statistik>Gewicht <Ausgleichsrechnung>Zellularer AutomatServerEin-AusgabeMultiplikationsoperatorARM <Computerarchitektur>Formale SemantikPufferüberlaufEreignisdatenanalyseTermTLSTelekommunikationFlächeninhaltDigitaltechnikProdukt <Mathematik>EinsMathematikNeunzehnEndliche ModelltheoriePunktAuflösung <Mathematik>Besprechung/InterviewComputeranimation
12:39
SocketGruppenoperationSchaltwerkCodeARM <Computerarchitektur>GrenzschichtablösungQuick-SortVorlesung/Konferenz
13:32
Socket-SchnittstelleFramework <Informatik>Konfiguration <Informatik>Einfach zusammenhängender RaumSoftwareVollständiger VerbandGebäude <Mathematik>SchaltwerkDifferenteHecke-OperatorOvalStandardabweichungARM <Computerarchitektur>GruppenoperationQuick-SortComputeranimation
14:31
HalbleiterspeicherCodeStandardabweichungAbstimmung <Frequenz>Gemeinsamer SpeicherWasserdampftafelDienst <Informatik>DifferenteRichtungRobotikBeobachtungsstudieBesprechung/InterviewComputeranimation
15:38
CodeGemeinsamer SpeicherDifferenteStandardabweichungAbstimmung <Frequenz>Knoten <Statik>Rechter WinkelComputeranimation
16:16
FlächeninhaltComputersicherheitInternetworkingUDP <Protokoll>SoftwareentwicklerProtokoll <Datenverarbeitungssystem>ZeitabhängigkeitAbstraktionsebeneEchtzeitsystemProtokoll <Datenverarbeitungssystem>FlächeninhaltAbstimmung <Frequenz>Kartesische KoordinatenGruppenoperationDienst <Informatik>VersionsverwaltungNichtlinearer OperatorMaschinenschreibenFitnessfunktionComputersicherheitMehrfachzugriffInternetworkingIPSecTransportproblemReelle ZahlSchaltwerkSoftwareDatenverwaltungSoftwaretestEinflussgrößeARM <Computerarchitektur>DruckspannungVorlesung/KonferenzComputeranimation
18:21
UDP <Protokoll>SoftwareentwicklerProtokoll <Datenverarbeitungssystem>ZeitabhängigkeitAbstraktionsebeneSchaltwerkEvoluteSoftwareentwicklerProtokoll <Datenverarbeitungssystem>Arithmetisches MittelKartesische KoordinatenSocketCodeWärmeübergangARM <Computerarchitektur>Gewicht <Ausgleichsrechnung>EinsVorlesung/KonferenzComputeranimation
19:40
UDP <Protokoll>SoftwareentwicklerProtokoll <Datenverarbeitungssystem>ZeitabhängigkeitAbstraktionsebeneFormale SpracheGrenzschichtablösungTermWasserdampftafelSchaltwerkProtokoll <Datenverarbeitungssystem>AbstraktionsebeneUmwandlungsenthalpieStandardabweichungEin-AusgabePrimitive <Informatik>AppletProzess <Informatik>Vorlesung/KonferenzComputeranimation
20:32
HalbleiterspeicherFormale SpracheInteraktives FernsehenEin-AusgabeDatenfeldÄhnlichkeitsgeometrieDifferenteMusterspracheObjekt <Kategorie>InternetworkingVerkehrsinformationVorlesung/Konferenz
21:11
GruppenoperationGüte der AnpassungFlächeninhaltInternetworkingProzess <Informatik>Inverser LimesZahlenbereichPackprogrammKette <Mathematik>ARM <Computerarchitektur>BitrateBeobachtungsstudieRoutingUnrundheitMenütechnikXMLComputeranimation
22:59
Elektronische PublikationFlächeninhaltProzess <Informatik>UnrundheitGruppenoperationt-TestStandardabweichungVorlesung/Konferenz
23:42
p-BlockMessage-PassingEreignishorizontKonditionszahlRechnernetzSoftwareUnrundheitEreignishorizontInformationsspeicherungMomentenproblemSchaltwerkSocket-SchnittstelleKartesische KoordinatenBeobachtungsstudieGrenzschichtablösungEinfach zusammenhängender Raump-BlockElektronisches ForumGruppenoperationBitFlächeninhaltTexteditorXMLComputeranimation
25:01
p-BlockEreignishorizontMessage-PassingKonditionszahlRechnernetzEreignishorizontWarteschlangeUmwandlungsenthalpieMusterspracheFormale SpracheImplementierungSystemaufrufExistenzaussageSchaltwerkTouchscreenOrdnung <Mathematik>EvoluteProtokoll <Datenverarbeitungssystem>GruppenoperationDigitaltechnikInformationGüte der AnpassungKartesische KoordinatenSocketComputeranimationVorlesung/Konferenz
25:55
ZeitabhängigkeitProtokoll <Datenverarbeitungssystem>Dienst <Informatik>Konfiguration <Informatik>Migration <Informatik>MultiplikationImplementierungSocketStreaming <Kommunikationstechnik>Kategorie <Mathematik>Kartesische KoordinatenPhysikalisches SystemZweiProtokoll <Datenverarbeitungssystem>Einfach zusammenhängender RaumMultiplikationsoperatorEvoluteDienst <Informatik>Trennschärfe <Statistik>PunktGruppenoperationComputeranimation
26:42
RechenwerkProtokoll <Datenverarbeitungssystem>ZeitabhängigkeitDienst <Informatik>Konfiguration <Informatik>MultiplikationMigration <Informatik>ImplementierungSchreib-Lese-KopfEinfach zusammenhängender RaumDifferenteProtokoll <Datenverarbeitungssystem>VerschlingungTrennschärfe <Statistik>ZweiTLSMultiplikationsoperatorDatenfeldComputeranimation
27:19
HalbleiterspeicherZweiEinfach zusammenhängender RaumSchreib-Lese-KopfMigration <Informatik>Protokoll <Datenverarbeitungssystem>Streaming <Kommunikationstechnik>MultiplikationsoperatorKartesische KoordinatenSoftwareMessage-PassingDatentransferParallele SchnittstelleMathematikTouchscreenGebäude <Mathematik>AdditionEndliche ModelltheorieRichtungGruppenoperationVorlesung/Konferenz
28:20
Message-PassingWärmeübergangKontrollstrukturBasis <Mathematik>Dienst <Informatik>MultiplikationTelekommunikationInterface <Schaltung>Strukturierte ProgrammierungStreaming <Kommunikationstechnik>HIP <Kommunikationsprotokoll>Protokoll <Datenverarbeitungssystem>Message-PassingInteraktives FernsehenEndliche ModelltheorieTouchscreenRahmenproblemStreaming <Kommunikationstechnik>Interface <Schaltung>Protokoll <Datenverarbeitungssystem>SoftwarePhysikalisches SystemKartesische KoordinatenGamecontrollerProdukt <Mathematik>Computeranimation
29:15
WärmeübergangMessage-PassingKontrollstrukturTelekommunikationStrukturierte ProgrammierungInterface <Schaltung>Protokoll <Datenverarbeitungssystem>Streaming <Kommunikationstechnik>Dienst <Informatik>Basis <Mathematik>RechenwerkBasis <Mathematik>Message-PassingEinfach zusammenhängender RaumPuffer <Netzplantechnik>SocketOffene MengeWeb SiteQuantenzustandGeradeComputeranimation
29:59
Streaming <Kommunikationstechnik>Protokoll <Datenverarbeitungssystem>Prozess <Informatik>Message-PassingTelekommunikationKontrollstrukturDruckverlaufDesintegration <Mathematik>Einfach zusammenhängender RaumBrowserPhysikalisches SystemSocketMessage-PassingCodeTouchscreenPuffer <Netzplantechnik>DatenverwaltungKartesische KoordinatenVollständigkeitEinflussgrößeHardwareVorlesung/KonferenzComputeranimation
30:56
Streaming <Kommunikationstechnik>Protokoll <Datenverarbeitungssystem>Message-PassingProzess <Informatik>TelekommunikationDruckverlaufDesintegration <Mathematik>KontrollstrukturRechenwerkInterrupt <Informatik>Kartesische KoordinatenMessage-PassingProtokoll <Datenverarbeitungssystem>BitRechter WinkelFitnessfunktionStreaming <Kommunikationstechnik>Kategorie <Mathematik>Mechanismus-Design-TheorieComputeranimationVorlesung/Konferenz
31:37
Message-PassingInterface <Schaltung>Minkowski-MetrikProtokoll <Datenverarbeitungssystem>Physikalisches SystemEgo-ShooterWärmeübergangRadikal <Mathematik>Abgeschlossene MengeProtokoll <Datenverarbeitungssystem>Kategorie <Mathematik>Einfach zusammenhängender RaumMessage-PassingSkalarproduktPhysikalisches SystemGlobale OptimierungWärmeübergangSoftwaretestInteraktives FernsehenGeradeCodeRPCObjekt <Kategorie>Trennschärfe <Statistik>KonfigurationsraumDiagrammNamensraumDefaultDifferenteUmwandlungsenthalpieTermPartikelsystemLeistung <Physik>EreignishorizontEinflussgrößeBasis <Mathematik>Data DictionaryMaßerweiterungComputeranimation
33:31
Radikal <Mathematik>Abgeschlossene MengeMessage-PassingMessage-PassingObjekt <Kategorie>Einfach zusammenhängender RaumMAPEreignishorizontMailing-ListeCASE <Informatik>Computeranimation
34:17
Radikal <Mathematik>Abgeschlossene MengeMessage-PassingKanalkapazitätBenutzerprofilAbstraktionsebeneStreaming <Kommunikationstechnik>EreignishorizontMessage-PassingKategorie <Mathematik>KanalkapazitätEinfach zusammenhängender RaumObjekt <Kategorie>Profil <Aerodynamik>Framework <Informatik>Streaming <Kommunikationstechnik>ParametersystemComputersicherheitExogene VariableDienst <Informatik>COMFigurierte ZahlChiffrierungRahmenproblemPräkonditionierungKontextbezogenes SystemOrdnung <Mathematik>RoutingVorlesung/KonferenzComputeranimation
35:40
Message-PassingAbstraktionsebeneHochdruckSynchronisierungComputersicherheitLoopRechnernetzFramework <Informatik>SoftwareentwicklerSocketMessage-PassingPhysikalisches SystemSocketTelekommunikationSoftwareEin-AusgabeKonfigurationsraumImplementierungDefaultProjektive EbeneKartesische KoordinatenMomentenproblemEinfach zusammenhängender Raumt-TestFramework <Informatik>SchaltwerkProzess <Informatik>ARM <Computerarchitektur>RahmenproblemRechenschieberDemoszene <Programmierung>Güte der AnpassungVorlesung/KonferenzComputeranimation
37:24
HalbleiterspeicherDokumentenserverGruppenkeimProgrammSoftwareFramework <Informatik>CASE <Informatik>Rechter WinkelDokumentenserverEin-AusgabeFehlermeldungMailing-ListeGenerator <Informatik>SocketVarietät <Mathematik>Güte der AnpassungKontextbezogenes SystemTorusVersionsverwaltungVorlesung/KonferenzComputeranimation
38:33
ComputerspielMomentenproblemEchtzeitsystemWärmeübergangQuick-SortSoftwareBiegungMultiplikationsoperatorFlächeninhaltPunktMessage-PassingImplementierungSoftwaretestDeterministischer ProzessBitGeradeKategorie <Mathematik>Smith-DiagrammFunktion <Mathematik>ComputervirusPuffer <Netzplantechnik>Vorlesung/Konferenz
41:00
RichtungTelekommunikationStochastische AbhängigkeitStreaming <Kommunikationstechnik>MusterspracheMessage-PassingDefaultInteraktives FernsehenVorlesung/Konferenz
41:40
StrömungsrichtungTouchscreenPunktSchaltwerkMessage-PassingStreaming <Kommunikationstechnik>GruppenoperationMAPUmwandlungsenthalpieInverser LimesVorlesung/KonferenzBesprechung/Interview
42:15
MAPImplementierungInklusion <Mathematik>DifferenzenrechnungMereologiePhysikalisches SystemKartesische KoordinatenBesprechung/Interview
42:58
ImplementierungInformationSocketWrapper <Programmierung>Spezielle unitäre GruppeTDMAMultiplikationsoperatorMinkowski-MetrikQuantenzustandPunktDigitaltechnikVorlesung/KonferenzBesprechung/Interview
43:38
SocketHyperbelverfahrenPunktWrapper <Programmierung>ImplementierungKartesische KoordinatenUnrundheitSoftwareMultiplikationsoperator
44:12
JSONComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:20
Please give him a grand round of applause, and I'm welcoming him
00:24
to the stage. Hi, so my name is Phil, and I'm today here to talk about Taps, the transport services API. All the work I'm
00:43
presenting today is work in progress, so it has become a highly large group of people working on that, and it's really awesome how much traction it's got, but it's still work in progress. So we have no RFC yet. We're just talking about internet drafts and preliminary stuff we're doing for the API,
01:04
but, on the other hand, we already have a few implementations, and it's really nice seeing how much traction this gets. But before talking about why we want to replace the BSD socket API, or want to retire it, let's see
01:21
what's wrong with that. So, looking at the BSD socket API, we have to go back in its history, and you see the BSD socket API originates from 4.2 BSD from 1983. I was two years old when this was released. Therefore, it has become
01:44
quite old. At this time, they were really very strong in the idea of everything as a file, and, as we didn't have virtual file systems yet in this time, they decided, okay, if we want to do networking, just make it a file handler
02:04
and have, instead of an open call, the socket call, and everything works like a file. And it was implemented as an extension for interprocess communication, so instead of doing interprocess communication on a single machine, we're
02:21
now doing it over the new shiny internet, which was quite small at this place and time, and worked. Yes, as an experiment. And, they decided to say we have two kinds of APIs for interprocess communication, message-based,
02:42
you can easily also create an Linux domain socket, and a stream-based, and, for this, they implemented the user data gram protocol, UDP, which is unreliable, and the transport control protocol, TCP, which is reliable stream.
03:04
And, as this was the first real API that ought to be usable, and it doesn't require to fiddling with network drivers, or putting assembly code, but enabled everyone who was able to write a file to also do network interprocess
03:21
communication, it became the template of most modern networking APIs. If you look at the BSD socket API, and look at the Windows socket API, or other socket APIs on embedded platforms, they look quite the same. They're all modelled after the original BSD socket API. So, let's see what we need to open a socket.
03:46
This is the classical example from Stevens et al. Unix network programming. This is still the reference on how to do this. So you first create an integer
04:03
variable, and then you're very able to put the socket file descriptor, as file descriptors are integers. Then you reserve a struct for the name resolution, configure it a little bit, and call get out of the info with all this
04:24
stuff, and to get the return parameters. Now you have a linked list of stuff that allows you to connect, and as the result of the name resolution. If it fails, you get an error, and then it gets worse. You start a
04:44
while loop iterating about this list and trying, can I connect the socket? If it works, we're fine. If it doesn't work, try the next one. Try to connect. If it works, we're fine. If it doesn't work, it blocks, it
05:01
time-outs, and we go to the next one. Afterwards, we have a socket file descriptor, we have a special free that allows us to free the whole list, and we're done. So, simple question, what's wrong with that?
05:20
And, I'm not thinking about modern APIs, but just on what's wrong if you accept that C is programmed that way, what's still wrong with that? And, the answer is, today's internet transport has changed. We're not in 1983 any more, and, therefore, a few things
05:44
changed. First, we have many more protocols out there than just TCP and UDP. At the narrow waist of the internet, we now have IPv4 and IPv6, and not IPv4 any more. At the transport layer, we don't have
06:05
... we have SCTP as a reliable message-based protocol. We will get quick pretty soon, so it's rolled out at the moment primarily from Google, but
06:22
a lot of other CDNs or contribution networks are on the way to roll out this. So, we will have a second transport protocol pretty soon that is made for replacing TCP at least if HTTP is on top of that. And probably you want to use this transparently.
06:44
As the second change, we have devices that have multiple paths today. So, if you had the mainframe in 1983, you were really lucky if you had a permanent connection to the internet and were not dialing it up through 300 bout modem. Today, you
07:04
have a cell phone that has multiple network interfaces, at least one cellular carrier and at least a Wi-Fi interface. Probably, you can use multiple at the same time. And you might want to really decide on a per-socket basis which path to use. And, finally, you have multiple endpoints
07:25
serving the same data. If you're talking to Google or any other CDN, you just get the front-end cache, and you have several to choose from. And, finally, last but not least, everything today
07:43
should be encrypted. At the old days of the internet, everyone was trusted. We don't need to trust the other few hundred guys on the internet. You'd know them. Today, we need encryption to save everything. And these are all things that
08:02
were not sought of when inventing the BSD Circuit API. So, let's look how we can fix that. We go to our textbook example again, and have first to look at the name resolution.
08:23
We want to resolve names over multiple paths in parallel. And, to make things worse, if you're talking to CDN nodes, you cannot use the same IP addresses through all links, because, if you have a Wi-Fi from the camp, and, for example,
08:43
a T-Mobile LTE on the camp, those will most probably deliver you different DNS results for CDN nodes. And you might not be able to reach the other CDN nodes at all using the wrong link. So, you have to resolve in parallel,
09:04
you have to keep the results separate, and you have to use them in the right way. The BSD Circuit API doesn't provide this feature. So, if you want to do this in an application, for example, the web browser, you have to
09:21
implement your whole DNS yourself. Welcome. Second, if we have results, these DNS results contain information that will be later on useful for your secure connection
09:41
set-up. If you want to use features like SNI encryption that allows, that prevents some observer on the path to see what host name you're connecting to, you have to get a key from DNS. The current Circuit API doesn't provide you this. You will need,
10:02
and you will have to implement DNS yourself. Third thing, if you want to connect, users usually like fast connections. If you have to time out multiple times, if you have to time out 90 seconds per connection attempt,
10:24
the user gets annoyed. If you click on the website on the link, and it takes you three or five minutes to display something, the user is really, really angry. So, what all browsers do today, or what you have to do today, if you want to be state
10:40
of the art, you have to try multiple connections in parallel. So you try IPv4 and IPv6, with a small head start for IPv6, wait which sockets connects first, and use that one. So, no loop any more, but a fancy loop around select
11:01
Who in this audience likes select or epoll or poll as a programming concept? Oh, we have quite a few! So, it really gets ugly to code this.
11:22
And, with things like quick emerging, we will have to do the same for the protocol. So, this is ugly. Then we need to set up a secure transport, so, for example, SSL, which is not part of the socket API, but this is a
11:41
separate library you're using, and you separately take care of that. And finally, you have to pass the transport protocol chosen, so if you use TCP or quick, or whatever you use, back to the application, because the socket might have slightly different
12:01
semantics, whatever you chose. I thought about presenting a code example of that, and we're looking for something. There's no textbook example, there's nothing on Stack Overflow, by the way. The nicest and shortest
12:20
example I found was in libcurl, and it was about 1,200 lines of code. Okay. So, how the heck do we solve that? The usual idea of people asking
12:43
that question say, oh, no way, there's no way of replacing the BSD socket API. Just don't think about it. It won't work. Several researchers tried that and failed, and I only have one
13:02
reason why I'm hoping that this approach might succeed. So why am I standing here? Last year, a bunch of people who got really annoyed about the BSD socket API because they broke their research code, or were really ugly in their API design, met at the
13:24
TAPs working group at the IETF, and said, oh, we have to do something about this. And the group who initially met was first a bunch of academics, and then Apple joined. And we're saying, oh, yes, we built our new network API, we want to
13:42
standardise it here, work together with you, who all have worked on different aspects of this connection set-up, and of this automatic probing of different transport options. Let's work together, and let's build something new, and they really are now trying to release the socket API
14:02
or the new network framework. That's basically what we're currently standardising at the IETF. Okay, I talked about the IETF, the IETF, what the heck is the IETF and what the heck is the TAPs working group? First, the IETF is a standards body.
14:22
That looks, sounds pretty boring. So a lot of people talking about standardisation, and how to operate with things. Not quite, because the IETF is a pretty unusual standard bodies, and also, if you
14:40
visit the meetings, you will find out it's a pretty nerdy place. I think these two quotes characterise the IETF pretty well. So the first is from David Clark and saying we reject kings, presidents, and voting. We believe in rough consensus and we believe in running code, which is
15:01
quite unusual for a standards body because usually, you either standardise something that someone else already had as a product, or you're just standardising something everyone agrees on and nobody knows whether it will ever be implementable. The second one is be conservative in what you send, and
15:22
be liberal in what you accept. If I want to interoperate with others, I should keep to the standards as much as possible, but I should be able to tolerate failures from what the others sent. And also, in the ways the IETF works, you see this
15:42
is quite different from other standards bodies, so there's no voting shares for different companies, but there's individuals in the room that try to find consensus, and they usually decide whether they get some So, instead of saying we raise our hands to vote, there's the question,
16:00
who is in favour of the following proposal, please hum now, and you just get a feeling on how much the people are humming in the room. And if you're really in favour of it, you can hum loudly and really for the full voice, you say, okay, I can live with that, but it's not so convincing, you can hum silently.
16:21
And as it's a very deep voice, you can't really get who is voting for what. So, it's in person, it's in the room, it's easily verifiable, and it's more or less anonymous. That's awesome. So, how is this IETF organised? First, it's divided
16:42
into several areas. So, there are applications in real time, or art areas, mostly concerned about application protocols and on application protocols that are doing real-time transport. Then there's the general area, which is mostly concerned with stuff that touches
17:01
everything else, and doesn't fit closely into one area. There's the internet area, which is really about the IP protocol, version 6, and perhaps looking at what the legacy IP needs for fixes. There's the
17:21
operations and management, which mostly talk about this practice of how to manage networks. The routing area, which is mostly about BGP and other routing protocols, the security area, where things like TLS or IPsec get standardised, and the transport area. And this is the
17:41
area we're talking about today because we're talking about transports like TCP, QUIC, SCTP, and this is also the area where the tabs works. So, what's the tabs working group? So the tabs working group is by its own charter concerned with transport services.
18:01
It started off as a group of people mostly thinking about ways on how to actually deploy a HTTP and get a HTTP deployment, but now with a few people joining and really talking about methods on how to choose sockets, really talking about methods
18:21
on how to use multiple access networks, it got a lot more traction. So the name is a little bit funny because who knows what tabs means for a usual American? Tabs is the melody you usually play
18:41
on a soldier's funeral, which was something because many Americans laughed about the tabs working group. But, today, as we try to retire the BSD socket API, it might get a different meaning now. The idea is to enable application
19:02
developers to use other protocols than TCP and UDP without too much caring about. So you don't want to rewrite your whole code if you want to use QUIC instead of TCP. Actually, if it works, you just would like that it works. Just the same way you did it before.
19:22
We want to enable transport evolution and describe an API, how to use transfers. Wait, API ITF? Isn't the ITF just standardising protocols? Why IPIs? So that's the reason why we really talk about an abstract API.
19:42
And there's a really, really tight separation of concerns on what the ITF specifies in terms of protocols. The ITF specifies abstract protocols. So, basically, what primitives are there? What are the basic interactions? And APIs for concrete
20:02
languages are usually made by their own standard bodies. So, for example, if you look at the Unix C APIs done by POSIX, if you look at the Java API, there's the Java community process for that, and, therefore, what Taps is doing as a specification is
20:23
just input for other standard bodies on how could we implement this in our language? And it's trying to have fairly broad and abstract concepts there that are usually somehow able to be mapped in a different language. So the APIs will
20:42
look a little bit different and can neatly integrate within the language while you have still the same rough, same interaction patterns, and, if you're going from, for example, Objective-C to Python, you will see a similar API, but that fields Objective-C on your iOS device and
21:02
fields Python on Python. That's the idea. So how does this standardisation stuff work in the ITF? So we start with writing an Internet draft. An Internet draft is for the academics from you something like a tech report, or something like
21:21
an archive old paper. Everyone can submit that. Everyone can write that. It has to go through the ITF processing tool chain and provide this beautiful ASCII text, but otherwise there are no real limitations for who and what you can do with an Internet draft. Then you want to decide how do
21:44
I want to publish it, and, if it gets published, it gets an RFC number. So how do we do this? You can either say I'm working, want to do this in a working group, then you carry your Internet draft to the working group and say, I have written this draft,
22:01
do we want to work together on that and adopt it as a working group item? And, if the working group says go away, we're not interested, or the working group says, oh, yes, it's fine. And the following five people also want to join you in working on that. And this is what we did for tabs. There's also this individual submission
22:22
way where individuals can submit stuff, but that's rarely used for real stuff because, mostly, you're not writing Then, you get, if you think it's ready, and you ask the related areas that are
22:43
touching your stuff, please do a review. Look whether it works, and whether you have insights that said it's good or it's a bad idea. And then you iterate over it until the other people are lucky. So this is always because this is the blue file. You iterate another round
23:02
if someone is unlucky and if it doesn't find consensus. So, usually, it gets about five to twenty-five rounds of rewriting a document before it might get an ROC. After the reviewers from the other areas said it's fine, the working group
23:21
said it's fine, it's sent for the Internet Engineering Steering Group for review, which is, again, a group of people who are ATF veterans and are elected by a very interesting process
23:40
who say, okay, we have an overview about most stuff going on at the IETF, we think it's a good idea and it works, or we say, oh no, you have overlooked something, please fix it at the forum. After the ISG review comes in, you send it to the ROC editor for
24:01
publishing, and they will tweak a little bit of the wording, have additional rounds with you on how to fix details, and finally, if all references are fixed, if everything is fine, it gets published as an ROC. So, if you're asking where Tabs is at the moment, Tabs is at the moment here.
24:21
We have it accepted as a working group item, and we are actively working on that, and we will soon get the first reviews from other areas. So, for IETF work, it's quite early in the pipeline. So, what's the idea? How does it work? What are the idea, principles? So, first, it's an event-driven API.
24:44
So, modern networking APIs, or networking applications work as synchronously. You always do select, you always have to look about several sockets and several connections, so you don't want to block anywhere. And Tabs has nothing that blocks.
25:03
So, everything you do, whether you initiate a connection, you listen for incoming connections, read or write, if something is for you, you get an event, and whether the event is implemented as a callback, or as a listener pattern object, or some kind of work queue is totally up to the
25:21
specific language implementation. Whatever fits into the language should be used to implement these kind of events. In addition, if you're looking at the BSD socket API, it's really, really complicated to get information like fire, or ICMP blocked, or ICMP
25:43
rejects. It's really hard to get this information, and Tabs is going to make this information easily available as events to the application, too. The second basic idea, and that's why it's in the Tabs working group, it should enable protocol evolution.
26:03
So, we're focusing on what the application needs. The application doesn't say I want a TCP socket, but the application says I want a reliable in-order stream socket. And whether this is implemented as TCP, or as QUIC, or as SADP, you don't care.
26:21
You get the service you're asking for. And you can narrowly define with properties what you really need, and the system makes a smart choice for you. Second, you want to be really flexible at connection establishment time. So you want to use happy eyeballs for everything, for protocol
26:41
selection, so for transport protocol selection, for IP protocol selection, maybe also for end point selection. And, if you have other preferences, so, for example, you want to use the cheapest possible link or something like that, you just code this into the time-outs, or the
27:02
head start you give for the different kind of connections. So, if you give a 30 millisecond head start for a certain link, these connections will establish first and will be used. But, if the link is broken, or if something else is broken there, just using the least preferred or
27:21
the lesser preferred one, that doesn't have the head start. Still, you don't have to wait for some time-out. You just get a connection, and it feels fast. And the third idea, you want to be flexible after connection establishment, and you want to use features that modern
27:40
transport protocols bring you, like connection migration. If you change your IP address, you don't want to reconnect. You just carry on with your connection. You want to be able to use multi-paths, if you have multiple links, and you want to be able to use multi-streaming to save connection time.
28:01
So, your application shouldn't care about whether you need to open a second TCP connection if you want parallelism, or you open an additional quick stream if you have quick available. And these all should be glossed over in tabs.
28:21
And, as the third main concept, we want to be able to do data transfer using messages. All interactions in model networking applications are message-based. Yes, you have a TCP socket, that's a screen, but you usually chop the screens into messages and work then on those messages.
28:41
And, therefore, we want to support framing and deframing for message-based protocols on stream transports, because we're not going to change the transports with tabs. We're just providing nicer interface to the existing one. That's also the reason why a tab system can, without any problem, interact to any other system, because
29:01
we're not changing the protocols. We're just changing the way you're accessing the protocols. It allows to control a lot of stuff on the individual messages that are available in the protocols, but not exposed by the socket API today, like deadlines. So, for example,
29:20
in SCTP, you just might not want to transmit a message when the receiver hasn't any use for it anymore. So you can associate a deadline with a message, and it might be dropped from the send buffer after this deadline is over. You might want to send certain messages unreliably,
29:40
because you don't care whether they arrive, or don't care too much about whether they arrive, and you can also select this on a per-message basis in a nice and suitable way. And it also allows you to assign messages to underlying transport connections for multi-streaming and for pooled connections. So, if you
30:00
today have a web browser that opens a connection to some CDN node or to some other website, it opens a bunch of connections and distributes the requests among them. We can do this in the socket API, and you don't have to implement it yourself. This should be done by a tab system. How do we learn this? We have
30:21
two concepts that are central to do this. The first one is framers. Framers are pieces of code that allows you to chop a screen transport into individual messages. And the nice idea about this is you can just write a piece of code, and then it
30:42
integrates with the buffer management and you only get a message in your main application code once a complete message arrived. Or a chunk of the message if the messages are too large. But you can really implement this in a nice and sensible way. I think we should also be able to offload
31:01
this, for example, to hardware. If you are able to offload a lot of stuff into your hardware, it might also look for the messages and only send the application in software interrupt when a whole message arrives for it. Finally,
31:25
this concept is mainly for chopping stream protocols, but we might tweak it a little bit, and we might be able to implement simple protocols also within the framing layer. Finally, to control all that stuff, we need some mechanism, and this means
31:41
to configuring our transport properties. So, we have selection properties that influence pass and protocol selection, we have connection properties that influence per connection behaviour, and we have message properties that influence permissions behaviour. They're just used like a dictionary, and we have well-defined namespaces.
32:02
So, we have a default namespace for all stuff we are currently writing in this RFC, and we have different namespaces, for example, for transport protocols, specific stuff, you just write TCP dot and then the property, and, you know, this transfer property is only used if the connection is done using TCP. If it's done using QUIC, this is just ignored.
32:23
So, how does this interaction work? So, if we have this on a textual basis, we say, I want a connection to example using HTTPS, I need a reliable transport, and please optimise for low latency. The test system says, oh,
32:40
yes, nice, here's a connection object. You now can send and receive your messages on this, and you don't have to care about anything else. So, it's not 1,200 lines of code, but it's about 20 lines of code to establish that connection. So, there's this nice ASCII art diagram
33:04
from the current draft that's saying basically the idea. So, you start over with a preconnection. That's an object where you do all the configuration on you want to connect. You specify a local endpoint, a remote endpoint,
33:22
for example, a host name. You specify selection properties, and you specify defaults for the connection and message properties. So, you can, for example, say, we have, even if I get a reliable protocol, I want all my messages sent unreliable if possible.
33:43
You can already specify this in this stage. Then you go into the preconnection. On the preconnection, you can either call initiate and get a connection object once the connection is established, or you can call listen on it and get a listener object that is listening for your
34:01
connections. Once this initiation works, you get an event. So, in this case, the listener, you get a connection received event, or, in this case, an initial completed event, and have a connection object. On this, you can send, can easily call send with a message.
34:22
You receive messages, events out of that, and, if you close, it goes to a closed connection. Fairly simple. So, how does this look in code? We have a remote specifier. I want a remote specifier
34:40
with the host, with the service, I want transport properties, reliable in-order stream. This is a shorthand. You can also specify a bunch of properties that you want reliable, that you want it in order, and so on. I want the capacity
35:02
and profile low latency added to it that you optimise to latency. Then you configure your security parameters for the encryption, and create a preconnection object with all these parameters. On the preconnection, you can say I want an HTTP
35:20
framework that I just want to be want to get HTTP requests and responses as messages, and don't want to care about anything else, and then say preconnection.initiate and get your connection object back. The connection object then sends you an event saying, oh, I'm ready. The connection is set up. Then you can send your messages.
35:42
You can read a new message context, configure it, you want a lifetime of 200 milliseconds and TCP low delay if TCP is used. If not, you don't get it. Then you have the connection. I can sign off. So,
36:03
Theresa who might be in the room here, and a few students of us and I have written this Python AsyncIO tabs as one example implementation which is still on top of the BSD socket API to just see whether this, how this fits into Python, and we see
36:22
have this as an example application that does exactly the same as the two slides before pseudo-coded. So, we're not the only implementation at the moment. There is much more complete as our
36:41
Python implementation. The Apple network framework which is available since iOS 12 or 13, I guess. So, it's it was better in iOS 12 and will now come in iOS 13 as default network communication framework. And it's based on the ideas
37:01
of tabs. And there are also some other projects which are need and socket intents which were pre-runners that gave input into the whole process, but you can get some ideas on what a tab system could do from these implementations.
37:20
But basically, if you want to use tabs today, and you're programming for iOS, you can just use network framework and you get most of the stuff I was talking about today just today by using it. If you're interested in more stuff, the documents are in the ITF data tracker.
37:41
So, you can see it. If you're interested to collaborate, if you have comments on that, subscribe the tabs mailing list from the date, ITF data tracker and start discussing about that stuff. We love input, we love ideas. We love if you see that there are problems because we really want to have
38:01
the next generation socket API there. And therefore, we need input of whether use cases are sort of or whether this works nicely. And if you want about the latest version, the latest discussion, there's also GitHub repository where we also have GitHub
38:21
most detailed discussions as GitHub issues. So, if you have a need or if you found a right spelling error in the documents, just make a GitHub issue and we will take care of that. So, with this, I'm finished with my talk, and I'm happy to take questions.
39:08
Hello. Hi. Sorry, we just had a technical problem. So, thank you so much. This was Philz and we have a bit time left for questions. So, please, don't be shy
39:20
and come to the microphones and ask away. Thank you. You mentioned that the new API is supposed to include deadlines. Are these real absolute deadlines or just time-outs? This is a good question. So, we don't think that
39:40
anyone will really implement a real-time networking API because that's really, really hard. If someone is going into the area of deterministic networking where you can have real deadlines, this might be exposed as well as a transport property, but the time-outs I was seeing here are mostly advisory time-outs like
40:01
your stack, we really don't need to retransmit this packet if it has lurked for about 300 milliseconds in the output buffer. So, it could be real deadlines at some point in time, but at the moment, we are just for the actual implementations today, we're thinking about per-message time-outs.
40:23
Thank you so much. Next question, please. So, in your Python example, you awaited the send and then registered some sort of callback on receive after you awaited the send
40:40
and that looked a bit weird for me. Why do you need to await the send if you use callbacks anyway? You don't need to await it at this point in time. It was just in the example but you don't need to await it in this moment.
41:02
And maybe a related question, so what kind of, you said you wanted to be protocol independent and obviously, there are many communication patterns that are interesting beyond just bidirectional byte streams.
41:20
So, do you only plan to support bidirectional byte streams or something message-oriented broadcasting? So, as I already told in the talk, we are really looking about messages if it's possible. So, the default interaction should be messages, and we have the framers
41:41
to chop a byte stream into messages, and that also should allow you to migrate from stream-oriented transport like TCP to real message-oriented transport once this is available in your current deployment scenario. If you're not looking about point-to-point, we have some people who joined the
42:01
tabs working group and joined our work that are really looking about source-specific multicast, and we definitely want full multicast support within this API, but that's still an early stage. That's not in most of the implementations yet, but it's coming.
42:22
So, it's definitely on our agenda to include multicast in a usable and nice way and in a portable way. Thank you so much, and I think we have a question left. Thanks for your talk. Do you foresee already
42:40
how much of the implementations will be user-mode, and which parts of implementation will be user-mode, and which parts will be kernel-mode, especially regarding the async parts which are usually done differently on different operating systems? That's a very good question. If you're looking
43:01
at the implementations that are currently out there, so there's our Python implementation is mostly a wrapper, as the need implementation is mostly a wrapper around the socket API. The implementation is actually doing most stuff in user-mode, and it's just using the kernel-mode for demultiplexing,
43:21
and I think this is the way it should go in the next years. So, on the other hand, I think seeing that both is possible should also allow an implementation to change that at some point in time. So, hopefully, it's possible to start with
43:41
wrapper on the BSD socket API and go to some user-space networking implementation at a later point in time without changing the API to the application. That's what we hope to achieve. Thank you so much. So, thank you so much to Philz, and please give him a great round
44:01
of applause.