]> University of Oslo

PO Box 1080 Blindern N-0316 Oslo Norway +47 22 85 24 44 steing@ifi.uio.no

University of Oslo

PO Box 1080 Blindern N-0316 Oslo Norway +47 22 85 24 20 michawe@ifi.uio.no

Transport TAPS taps, transport services This draft recommends a minimal set of IETF Transport Services offered by end systems supporting TAPS, and gives guidance on choosing among the available mechanisms and protocols. It is based on the set of transport services given in the TAPS document draft-ietf-taps-transports-usage-00.

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 and follows the same terminology (also listed below). The purpose of these two drafts is, according to the TAPS charter, to "Define a set of Transport Services, identifying the services provided by existing IETF protocols and congestion control mechanisms." This is item 1 in the list of working group tasks. Also according to the TAPS charter, the working group will then "Specify the subset of those Transport Services, as identified in item 1, that end systems supporting TAPS will provide, and give guidance on choosing among available mechanisms and protocols. Note that not all the capabilities of IETF Transport protocols need to be exposed as Transport Services." Hence it is necessary to minimize the number of services that are offered. We begin this by grouping the transport service features. Following , we divide the transport service features into two main groups as follows: CONNECTION related transport service features - ESTABLISHMENT - AVAILABILITY - MAINTENANCE - TERMINATION DATA Transfer Related transport service features - Sending Data - Receiving Data - Errors Because QoS is out of scope of TAPS, this document assumes a "best effort" service model , . 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 these must also be kept by a TAPS system. Some of these requirements relate to transport service features that we call "Functional". Functional transport service features provide functionality that cannot be used without the application knowing about them, or else they violate assumptions that might cause the application to fail. For example, unordered message delivery is a functional transport service feature: it cannot be used without the application knowing about it because the application's assumption could be that messages arrive in order. "Change DSCP" and "Disable Nagle algorithm" are what we call "Optimizing" transport service features: if a TAPS system autonomously decides to enable or disable them, an application will not fail, but a TAPS system may be able to communicate more efficiently if the application is in control of this optimizing transport service feature. "Change DSCP" and "Disable Nagle algorithm" are examples of transport service features that require application-specific knowledge (about delay/bandwidth requirements and the length of future data blocks that are to be transmitted, respectively). To summarize, transport service features that this memo recommends to offer to applications are divided into two groups as follows: Functional This transport service feature has to be specified by the application, since if not, it cannot be used or the application logic may break. Optimizing This transport service feature may be specified by the application, and when specified can optimize the performance of the application. The transport service features of IETF transport protocols that are not exposed to the TAPS user because they include functionality that could be transparently utilized by a TAPS system are called "Automatable". Finally, some transport service features are aggregated or slightly changed in the TAPS API. These transport service features are marked as "ADDED". The corresponding transport service feature(s) is/are automatable, and they are listed immediately below the "ADDED" transport service feature. This document also sketches how some of the TAPS transport services can be implemented. Wherever it is not obvious how to implement a service via TCP or UDP [**UDP: NOT YET**], a brief discussion is included. IETF transport services are presented following the nomenclature "CATEGORY.[SUBCATEGORY].SERVICENAME.PROTOCOL".

The following terms are used throughout this document, and in subsequent documents produced by TAPS that describe the composition and decomposition of transport services. a specific end-to-end feature that the transport layer provides to an application. Examples include confidentiality, reliable delivery, ordered delivery, message-versus-stream orientation, etc. a set of Transport 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 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). knowledge that only applications have. an entity that communicates with one or more other endpoints using a transport protocol. shared state of two or more endpoints that persists across messages that are transmitted between these endpoints. the combination of a destination IP address and a destination port number.

This section is based on the classification of the transport service features in pass 3 of . For every transport service feature, a brief explanation of the classification is provided. Some more general decisions affect multiple transport service features (e.g. the decision that multi-streaming is automatable); the rationale for such decisions is provided in .

ESTABLISHMENT: Connect Protocols: TCP, SCTP Functional because the notion of a connection is often reflected in applications as an expectation to be able to communicate after a "Connect" succeeded, with a communication sequence relating to this transport service feature that is defined by the application protocol. Implementation: via CONNECT.TCP or CONNECT.SCTP. Specify IP Options Protocols: TCP Automatable because IP Options relate to knowledge about the network, not the application. Request multiple streams Protocols: SCTP Automatable because using multi-streaming does not require application-specific knowledge. Implementation: see . Obtain multiple sockets Protocols: SCTP Automatable because the usage of multiple paths to communicate to the same end host relates to knowledge about the network, not the application. Implementation: see . AVAILABILITY: Listen Protocols: All Functional because the notion of accepting connection requests is often reflected in applications as an expectation to be able to communicate after a "Listen" succeeded, with a communication sequence relating to this transport service feature that is defined by the application protocol. ADDED. This differs from the 3 automatable transport service features below in that it leaves the choice of interfaces for listening open. Implementation: by listening on all interfaces via LISTEN.TCP (not providing a local IP address) or LISTEN.SCTP (providing SCTP port number / address pairs for all local IP addresses). Listen, 1 specified local interface Protocols: TCP, SCTP Automatable because decisions about local interfaces relate to knowledge about the network and the Operating System, not the application. Listen, N specified local interfaces Protocols: SCTP Automatable because decisions about local interfaces relate to knowledge about the network and the Operating System, not the application. Listen, all local interfaces Protocols: TCP, SCTP Automatable because decisions about local interfaces relate to knowledge about the network and the Operating System, not the application. Obtain requested number of streams Protocols: SCTP Automatable because using multi-streaming does not require application-specific knowledge. Implementation: see . MAINTENANCE: Change timeout for aborting connection (using retransmit limit or time value) Protocols: TCP, SCTP Functional because this is closely related to potentially assumed reliable data delivery. Implementation: via CHANGE-TIMEOUT.TCP or CHANGE-TIMEOUT.SCTP. Control advertising timeout for aborting connection to remote endpoint Protocols: TCP Functional because this is closely related to potentially assumed reliable data delivery. Implementation: via CHANGE-TIMEOUT.TCP. Disable Nagle algorithm Protocols: TCP, SCTP Optimizing because this decision depends on knowledge about the size of future data blocks and the delay between them. Implementation: via DISABLE-NAGLE.TCP and [**Not yet included in FOR SCTP**]. Request an immediate heartbeat, returning success/failure Protocols: SCTP Automatable because this informs about network-specific knowledge. Set protocol parameters Protocols: SCTP SCTP parameters: RTO.Initial; RTO.Min; RTO.Max; Max.Burst; RTO.Alpha; RTO.Beta; Valid.Cookie.Life; Association.Max.Retrans; Path.Max.Retrans; Max.Init.Retransmits; HB.interval; HB.Max.Burst Automatable because these parameters relate to knowledge about the network, not the application. Notification of Excessive Retransmissions (early warning below abortion threshold) Protocols: TCP Optimizing because it is an early warning to the application, informing it of an impending functional event. Implementation: via ERROR.TCP. Notification of ICMP error message arrival Protocols: TCP Optimizing because these messages can inform about success or failure of functional transport service features (e.g., host unreachable relates to "Connect") Implementation: via ERROR.TCP. Status (query or notification) Protocols: SCTP SCTP parameters: association connection state; socket list; socket reachability states; current receiver window size; current congestion window sizes; number of unacknowledged DATA chunks; number of DATA chunks pending receipt; primary path; most recent SRTT on primary path; RTO on primary path; SRTT and RTO on other destination addresses; socket becoming active / inactive Automatable because these parameters relate to knowledge about the network, not the application. Set primary path Protocols: SCTP Automatable because it requires using multiple sockets, but obtaining multiple sockets in the CONNECTION.ESTABLISHMENT category is automatable. Implementation: see . Change DSCP Protocols: TCP Optimizing because choosing a suitable DSCP value requires application-specific knowledge. Implementation: via CHANGE-DSCP.TCP and [**Not yet included in FOR SCTP**] TERMINATION: Close after reliably delivering all remaining data, causing an event informing the application on the other side Protocols: TCP, SCTP Functional because the notion of a connection is often reflected in applications as an expectation to have all outstanding data delivered and no longer be able to communicate after a "Close" succeeded, with a communication sequence relating to this transport service feature that is defined by the application protocol. Implementation: via CLOSE.TCP and CLOSE.SCTP. Abort without delivering remaining data, causing an event informing the application on the other side Protocols: TCP, SCTP Functional because the notion of a connection is often reflected in applications as an expectation to potentially not have all outstanding data delivered and no longer be able to communicate after an "Abort" succeeded, with a communication sequence relating to this transport service feature that is defined by the application protocol. Implementation: via ABORT.TCP and ABORT.SCTP. Timeout event when data could not be delivered for too long Protocols: TCP, SCTP Functional because this notifies that potentially assumed reliable data delivery is no longer provided. Implementation: via TIMEOUT.TCP and TIMEOUT.SCTP.

Reliably transfer data Protocols: TCP, SCTP Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation: via SEND.TCP and SEND.SCTP. Message identification Protocols: SCTP Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation: via SEND.SCTP. Fall-back to TCP: By using SEND.TCP and providing a means to let the application query whether messages can be identified or not. Choice of stream Protocols: SCTP Automatable because it requires using multiple streams, but requesting multiple streams in the CONNECTION.ESTABLISHMENT category is automatable. Implementation: see . Choice of path (destination address) Protocols: SCTP Automatable because it requires using multiple sockets, but obtaining multiple sockets in the CONNECTION.ESTABLISHMENT category is automatable. Implementation: see . Message lifetime Protocols: SCTP Optimizing because only applications know about the time criticality of their communication. Implementation: via SEND.SCTP. Fall-back to TCP: By using SEND.TCP and ignoring the lifetime request: based on the assumption of the best-effort service model, unnecessarily delivering data does not violate application expectations. Moreover, it is not possible to associate the requested lifetime to a "message" in TCP anyway. Choice between unordered (potentially faster) or ordered delivery of messages Protocols: SCTP Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation: via SEND.SCTP. Fall-back to TCP: By using SEND.TCP and always sending data ordered: based on the assumption of the best-effort service model, ordered delivery may just be slower and does not violate application expectations. Moreover, it is not possible to associate the requested delivery order to a "message" in TCP anyway. Request not to bundle messages Protocols: SCTP Optimizing because this decision depends on knowledge about the size of future data blocks and the delay between them. Implementation: via SEND.SCTP. Fall-back to TCP: By using SEND.TCP and DISABLE-NAGLE.TCP to disable the Nagle algorithm when the request is made and enable it again when the request is no longer made. Specifying a "payload protocol-id" (handed over as such by the receiver) Protocols: SCTP Functional because it allows to send extra application data with every message, for the sake of identification of data, which by itself is application-specific. Implementation: SEND.SCTP. Fall-back to TCP: Not possible.

Receive data Protocols: TCP, SCTP Functional because a TAPS system must be able to send and receive data. Implementation: via RECEIVE.SCTP and RECEIVE.TCP Choice of stream to receive from Protocols: SCTP Automatable because it requires using multiple streams, but requesting multiple streams in the CONNECTION.ESTABLISHMENT category is automatable. Implementation: see . Message identification Protocols: SCTP Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation: via RECEIVE.SCTP. Fall-back to TCP: By using RECEIVE.TCP and providing a means to let the application query whether messages can be identified or not. Information about partial message arrival Protocols: SCTP Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation: via RECEIVE.SCTP. Fall-back to TCP: Not possible (do not provide this event).

Notification of send failures Protocols: TCP, SCTP Functional because this notifies that potentially assumed reliable data delivery is no longer provided. ADDED. This differs from the 2 automatable transport service features below in that it does not distinugish between unsent and unacknowledged messages. Implementation: via SENDFAILURE-EVENT.SCTP. Fall-back to TCP: Not possible (do not provide this event). Notification of unsent messages Protocols: SCTP Automatable because the distinction between unsent and unacknowledged is network-specific. Notification of unacknowledged messages Protocols: SCTP Automatable because the distinction between unsent and unacknowledged is network-specific.

Some of transport service features in were designated as "automatable" on the basis of a broader decision that affects multiple transport service features. These decisions are explained here: All transport service features that are related to multi-streaming were removed. The decision on whether to use multi-streaming or not does not depend on application-specific knowledge. This means that a connection that is exhibited to an application could be implemented by using a single stream of an SCTP association instead of mapping it to a complete SCTP association. This could be achieved by using more than one stream when an SCTP association is first established (CONNECT.SCTP parameter "outbound stream count"), an internal stream number could be maintained by the TAPS system, and this stream number would then be used when sending data (SEND.SCTP parameter "stream number"). Closing or aborting a connection could then simply free the stream number for future use. All transport service features that are related to usage of multiple paths or the choice of the network interface were removed. Choosing a path or an interface does not depend on application-specific knowledge. For example, "Listen" could always listen on all available interfaces and "Connect" could use the default interface for the destination IP address.

By decoupling applications from transport protocols, a TAPS system provides a different abstraction level than the Berkeley sockets interface. As with high- vs. low-level programming languages, a higher abstraction level allows more freedom for automatization below the interface, yet it takes some control away from the application programmer. This is the design trade-off that a TAPS system developer is facing, and this document provides guidance on the design of this abstraction level. Some transport service features are currently rarely offered by APIs, yet they must be offered or they can never be used ("functional" transport service features). Other transport service features are offered by the APIs of the protocols covered here, but not exposing them in a TAPS API would allow for more freedom to automate protocol usage in a TAPS system. The eventual recommendations are: A TAPS system should expose all functional transport service features that are offered by the transport protocols that it uses because these transport service features could otherwise not be utilized by the TAPS system. It can still be possible to implement a TAPS system that does not offer all functional transport service features, e.g. for the sake of uniform application operation across a broader set of protocols, but then the corresponding functionality of transport protocols is not exploited. If a protocol that provides a functional transport service feature is not available, a TAPS system should automatically fall back to a different protocol (e.g. TCP or UDP) whenever possible to reduce the potential for protocol dependence in applications. A TAPS system should exhibit all application-specific optimizing transport service features. If an application-specific optimizing transport service feature is only available in a subset of the transport protocols used by the TAPS system, it should be acceptable for the TAPS system to ignore its usage when the transport protocol that is currently used does not provide it because of the performance-optimizing nature of the transport service feature and the initially mentioned assumption of "best effort" operation. By hiding automatable transport service features from the application, a TAPS system can gain opportunities to automatize network-related functionality. This can facilitate using the TAPS system for the application programmer and it allows for optimizations that may not be possible for an application. For instance, a kernel-level TAPS system that hides SCTP multi-streaming from applications could theoretically map application-level connections from multiple applications onto the same SCTP association. Similarly, system-wide configurations regarding the usage of multiple interfaces could be exploited if the choice of the interface is not given to the application. However, if an application wants to directly expose such choices to its user, not offering this functionality can become a disadvantage of a TAPS system. This is a trade-off that must be considered in TAPS system design.

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.

&RFC5290; &RFC7305;

XXX RFC-Ed please remove this section prior to publication. -02: implementation suggestions added, discussion section added, terminology extended, DELETED category removed, various other fixes; list of Transport Service Features adjusted to -01 version of except that MPTCP is not included.