P3185R0
A proposed direction for C++ Standard Networking based on IETF TAPS

1. Background

2. What is Transport Services Application Programming Interface (TAPS)?

2.1. Why TAPS?

• TAPS is an IETF initiative to shape future networking API design based on lessons learned from building networking systems on Berkeley Sockets based designs.

• TAPS proposes a language agnostic API that covers areas that have been raised as shortcomings of the current Networking TS:

  • Named connections, including DNS resolution

  • Transport Layer Security

• TAPS seeks to address the inconsistent concepts and naming of existing networking APIs (often derived from Berkeley Sockets) where names and concepts often vary as a pure quirk of the history of "how we got to here" and based on the protocol being used.

• The TAPS architecture aims to redefine the interface between applications and transports in a way that allows the transport layer to evolve without fundamentally changing the contract with the application.

• The TAPS recommendations aim to make common use cases simple and consistent while still providing more fine grained control over the transport layer for those applications that require it.

2.2. API Model

• Create connections and transfer data using a Sockets API.

• The Socket API provides the interface to implementations of the TCP and UDP protocols (typically provided by the system’s kernel, or e.g. lwIP [lwip] in embedded systems).

• The TCP and UDP implementation send and receive data over the network layer interfaces.

• Sockets are bound directly to transport-layer and network-layer addresses, obtained via a separate resolution step, usually performed by a system-provided DNS stub resolver.

+-----------------------------------------------------+
|                    Application                      |
+-----------------------------------------------------+
        |                 |                  |
  +------------+     +------------+    +--------------+
  |  DNS stub  |     | Stream API |    | Datagram API |
  |  resolver  |     +------------+    +--------------+
  +------------+          |                  |
                    +---------------------------------+
                    |    TCP                UDP       |
                    |    Kernel Networking Stack      |
                    +---------------------------------+
                                    |
+-----------------------------------------------------+
|               Network Layer Interface               |
+-----------------------------------------------------+

TAPS simplifies and modernizes this API structure to -

+-----------------------------------------------------+
|                    Application                      |
+-----------------------------------------------------+
                          |
+-----------------------------------------------------+
|              Transport Services API                 |
+-----------------------------------------------------+
                          |
+-----------------------------------------------------+
|          Transport Services Implementation          |
|  (Using: DNS, UDP, TCP, SCTP, DCCP, TLS, QUIC, etc) |
+-----------------------------------------------------+
                          |
+-----------------------------------------------------+
|               Network Layer Interface               |
+-----------------------------------------------------+

The API defines an interface for creating connections and transferring data, combining interfaces for multiple interaction patterns into a unified whole. The API offers generic support for protocols as protocol specific mappings for, e.g. TCP, UDP, etc. These protocol mappings are extensible to future protocol definitions, e.g. QUIC [rfc9000] or perhaps even the Binary Lexical Octet Ad-Hoc Transport [rfc3252].

By combining name resolution with connection establishment and data transfer, the API allows for more flexible implementations (a library QoI decision) to provide path and transport protocol agility on the application’s behalf.

Key differences exist between the architecture of the TAPS design and the architecture of the Socket API: the TAPS API is asynchronous and event-driven; it uses messages to represent data transfer to applications; and it describes how an application can resolve Endpoint Identifiers to use multiple IP addresses, multiple protocols, multiple paths, and provide multiple application streams.

2.3. TAPS Concepts

In contrast to this model, all interactions with TAPS are expected to be asynchronous and the API is defined around an event driven model. For example, when an application uses the TAPS API to receive data, it issues an asynchronous call to receive new data (a value) from the Connection. When delivered data becomes available, this data (value) is delivered to the application using asynchronous events (receiver::set_value) that contain the data (a complete framed message value). Error handling is also asynchronous, resulting in asynchronous error events (receiver::set_error). In a design that meshes well with the sort of asynchronous programming model envisioned by [p2300].

Additional events are delivered asynchronously to the application regarding the lifetime of a connection and changes in network availability, which were not previously made explicit in the Socket API.

Separate from events, callbacks are also provided for interactions with the TAPS API that are not directly related to events on the network or network interfaces, typically for negotiating transport layer security.

2.4. All data transfer is by Messages

TAPS represents data as messages, which more closely matches the way applications use the network. There are additional benefits to this message-oriented approach:

• Provide additional information to the protocol stack and application (e.g. a structured header type, separate from the message body).

• Ability to associate deadlines with messages, for applications that care about timing

• Ability to control reliability, which messages to retransmit when there is packet loss, and how best to make use of the data that arrived

• Ability to automatically assign messages and connections to underlying transport connections to utilize multi-streaming and pooled connections.

This message oriented approach is generally backwards compatible with existing usages where application code would have previously provided the framing of messages, while giving more information to the protocol stack in a consistent fashion that allows the application to adapt to transport level changes in a consistent manner. For protocols that inherently use streaming, or where applications use a non-standard or custom message framing, Framers bridge the gap between abstractions.

2.5. Flexible Connection establishment

• Handling multiple candidate endpoints, protocols, and paths

• Support for candidate protocol racing to select the most optimal stack in each situation

• Support multipath and multistreaming protocols

• State caching and application control over it.

A TAPS implementation is intended to be flexible at connection establishment time, considering many different options to select the most optimal connection that meets the requested criteria, with appropriate fallback strategies.

Information used in connection establishment (e.g. cryptographic resumption tokens, information about usability of certain protocols on the path, results of racing in previous connections) are cached by the implementation and applications have control over whether this information is used for a specific establishment, in order to allow trade offs between efficiency and link capability.

TAPS also allows for flexibility after connection reestablishment, for instance migration between multiple network-layer interfaces, allowing the application to react to interface changes, quality of service, etc.

3. Architecture

• Flexible

• Fallback Handling

• Sending

• Receiving

• Custom framing

  • [zeromq]

  • [rfc3252]

4. Open Question(s)

• Should a C++ Networking Standard provide a high level interface, e.g. TAPS, or should it provide low level facilities, sufficient to build higher level application interfaces?

• Should a C++ Networking Standard admit the possibility to support more "interesting" transports, e.g. InfiniBand, RDMA, etc.?

  • If so, how does a more primitive networking standard’s surface area support that? How does a TAPS based interface?

• TAPS has significant implementation complexity. Can the stdlib implementers adopt a proposal of this complexity?

  • I would argue it is an equivalent "lift" to what has already been proposed by the Networking TS along with enhancements to support Sender/Receiver, connection-by-name, and secure-by-default proposals.

  • A donated reference implementation would be helpful but not required, many of TAPS facilities are provided by existing libraries and operating systems. Standard libraries could choose to base their implementations on these libraries.

  • Any donated implementation would require something akin to the standard libraries adopting [range_v3], [stdpar], [p2300], etc.

  • If we adopt TAPS, we could finally foreclose on SG4 (circa 2012)'s most pressing concern, "What to do about IPv8"; with TAPS, this is simple, we approve an IPv8 transport and property set which is supported by the generic TransportProperties type. One could only dream of this job stability.

5. Conclusion

• A new async model

• Connection-by-name, endpoint resolvers, etc.

• Transport security

• etc.

Would such an effort yield a similarly cohesive result as the IETF’s TAPS initiative?