A Minimal Set of Transport Services for TAPS Systems

An application has an intended usage and demands for transport services, and the task of any system that implements TAPS is to offer these services to its applications, i.e. the applications running on top of TAPS, without binding an application to a particular transport protocol. The present draft is based on and follows the same terminology (also listed below). We include an "inversion" (in the database sense) of , in that, based on the lists of protocol components in we list all protocol features, and for each feature, we list the Transport Protocols that support this feature (as a component). The resulting list is very long. If the list of Transport Services that a TAPS system offers to applications was a simple copy of this list, the resulting system would be very hard to use. It is therefore necessary to minimize the number of services that are offered. We begin this by grouping these transport features. The groups of features offered to applications are divided as follows: functional vs. non-functional static vs. initialization vs. dynamic single-sided vs. both-sided Because QoS is out of scope of TAPS, this document assumes a "best effort" service model [RFC5290, RFC7305]. Applications using a TAPS system can therefore not make any assumptions about e.g. the time it will take to send a message. There are however certain requirements that are strictly kept by transport protocols today, and a TAPS system. Functional features use components that cannot be used without the application knowing about them, or else they violate assumptions that might cause the application to break. Components implementing non-functional features may be used without involving the application. For example, unordered message delivery is a functional feature: it cannot be used without the application knowing about it because the application's assumption could be that messages arrive in-order, and in this case unordered delivery could cause the application to break. Multihoming and data bundling (Nagle in TCP) are non-functional features: if a TAPS system autonomously decides to enable or disable them, an application will not break (but a TAPS system may be able to communicate more efficiently if the application is in control of this feature). If a transport protocol offers a feature that can not be changed or opted out, this feature is called static in this protocol. An application uses a static feature either because it has requested it (and TAPS decide to fulfill this request by a protocol that has a component that implements this feature as static), or the static feature is offered to the application implicitly because TAPS chooses a protocol that implements it. For example, if an application chooses byte-stream-oriented delivery, it automatically also gets reliable delivery. Initialization features can be chosen when communication begins but not adjusted later; this assumes that a TAPS system does not change protocols during a communication session. Examples of initialization features are flow control and congestion control. Dynamic features are changeable during runtime. An example of a dynamic feature is data bundling (Nagle in TCP). Single-sided features can be provided via components that are implemented only on the side where they applications requests the Transport Service. An example of a single-sided feature is data bundling (Nagle in TCP). Both-sided features can only be provided via components that are implemented on both sides. An example is error detection (checksum). Possibly certain features could benefit from, but do not need to be, implemented on both sides. Since the point of categorization is to determine the minimal set of Transport Services that a TAPS system must provide, the essential property of such features is that they *can* be implemented on only one side.

The following terms are defined throughout this document, and in subsequent documents produced by TAPS describing the composition and decomposition of transport services. a specific end-to-end feature that a transport service provides to its clients. Examples include confidentiality, reliable delivery, ordered delivery, message-versus-stream orientation, etc. a set of transport service features, without an association to any given framing protocol, which provides a complete service to an application. an implementation that provides one or more different transport services using a specific framing and header format on the wire. an implementation of a transport service feature within a protocol. an arrangement of transport protocols with a selected set of features and configuration parameters that implements a single transport service, e.g. a protocol stack (RTP over UDP). an entity that uses the transport layer for end-to-end delivery data across the network (this may also be an upper layer protocol or tunnel encapsulation).

provides a list of known IETF transport protocols and transport protocols frameworks. Here all features from are listed: unicast: TCP SCTP UDP-Lite DCCP NORM IPv6 multicast and anycast: UDP IPv4 broadcast, multicast and anycast: UDP UDP-Lite multicast: NORM unidirectional: UDP bidirectional: TCP message-oriented delivery: SCTP UDP UDP-Lite DCCP byte-stream-oriented delivery: TCP user message fragmentation and reassembly: SCTP IPv6 jumbograms: UDP connection setup with feature negotiation and application-to-port mapping: TCP SCTP DCCP port multiplexing: TCP SCTP UDP UDP-Lite DCCP port multiplexing (UDP ports): NORM 2-tuple endpoints: UDP transport layer multihoming for resilience: SCTP transport layer mobility: SCTP non-reliable delivery: UDP-Lite DCCP reliable delivery: TCP NORM reliable or partially reliable delivery: SCTP drop notification: DCCP ordered delivery: DCCP ordered delivery for each byte stream: TCP ordered delivery for each byte or message stream: NORM ordered and unordered delivery within a stream (of messages): SCTP unordered delivery: UDP-Lite UDP unordered delivery of in-memory data or file bulk content objects: NORM object-oriented delivery of discrete data or file items: NORM partial integrity protection: UDP-Lite DCCP checksum optional: UDP error detection (checksum): TCP UDP error detection (UDP checksum): NORM strong error detection (CRC32C): SCTP packet erasure coding (both proactively and as part of ARQ): NORM flow control: TCP SCTP flow control (slow receiver function): DCCP flow control (timer-based and/or ack-based): NORM segmentation: TCP NORM stream-oriented delivery in a single stream: TCP NORM support for multiple concurrent streams: SCTP support for stream scheduling prioritization: SCTP data bundling (Nagle's algorithm): TCP NORM user message bundling: SCTP congestion control: TCP SCTP NORM no congestion control: UDP timestamps: DCCP

This section presents a grouping of the features from according to the three categories: functional vs. non-functional; static vs. initialization vs. dynamic; one-sided vs. two-sided. The current version only includes the functional vs. non-functional categorization. The other categories will be included in future versions.

What is delivered (delivery type): message-oriented delivery: SCTP UDP UDP-Lite DCCP byte-stream-oriented delivery: TCP object-oriented delivery of discrete data or file items: NORM Reliability of delivery: non-reliable delivery: UDP UDP-Lite DCCP reliable delivery: TCP NORM reliable or partially reliable delivery: SCTP drop notification: DCCP Direction of communication: unidirectional: UDP bidirectional: TCP Ordered or unordered delivery: ordered delivery: DCCP ordered delivery for each byte stream: TCP ordered delivery for each byte or message stream: NORM ordered and unordered delivery within a stream (of messages): SCTP unordered delivery: UDP-Lite UDP unordered delivery of in-memory data or file bulk content objects: NORM Unicast, anycast, multicast or broadcast: unicast: TCP SCTP UDP UDP-Lite DCCP NORM IPv6 multicast and anycast: UDP IPv4 broadcast, multicast and anycast: UDP UDP-Lite multicast: NORM

These are features that the application can optionally specify. If a feature is not specified by the application it is undefined, i.e. the TAPS system may choose an implementation of any of the features listed. Congestion control: congestion control: TCP SCTP NORM no congestion control: UDP Resilience: multihoming: SCTP no resilience: UDP UDP-lite TCP Connection oriented (or not): connection oriented: TCP DCCP SCTP not connection oriented: UDP UDP-Lite Message sizes and fragmentation: user message fragmentation and reassembly: SCTP IPv6 jumbograms: UDP Setup negotiation: connection setup with feature negotiation and application-to-port mapping: TCP SCTP DCCP Flow control: flow control: TCP SCTP flow control (slow receiver function): DCCP flow control (timer-based and/or ack-based): NORM no flow control: UDP Multiplexing: multistreaming: SCTP port multiplexing: TCP SCTP UDP UDP-Lite DCCP port multiplexing (UDP ports): NORM 2-tuple endpoints: UDP Transport layer mobility: transport layer mobility: SCTP Error detection, protection, FEC and integrity (divided into more groups?): partial integrity protection: UDP-Lite DCCP checksum optional: UDP error detection (checksum): TCP UDP error detection (UDP checksum): NORM strong error detection (CRC32C): SCTP packet erasure coding (both proactively and as part of ARQ): NORM content privacy to in-path devices: ? (intro of ) Streams: stream-oriented delivery in a single stream: TCP NORM support for multiple concurrent streams: SCTP support for stream scheduling prioritization: SCTP Bundling: data bundling (Nagle's algorithm): TCP NORM user message bundling: SCTP

Segmentation: segmentation: TCP NORM Timestamps: timestamps: DCCP Service Codes: DCCP

This work has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No. 644334 (NEAT). The views expressed are solely those of the author(s).

XX RFC ED - PLEASE REMOVE THIS SECTION XXX This memo includes no request to IANA.

Security will be considered in future versions of this document.