TAPS S. Gjessing Internet-Draft M. Welzl Intended status: Informational University of Oslo Expires: May 4, 2017 October 31, 2016 A Minimal Set of Transport Services for TAPS Systems draft-gjessing-taps-minset-03 Abstract 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-02. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 4, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Gjessing & Welzl Expires May 4, 2017 [Page 1] Internet-Draft Minimal TAPS Transport Services October 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Superset of Transport Service Features . . . . . . . . . 5 3.1. CONNECTION Related Transport Service Features . . . . . . 5 3.2. DATA Transfer Related Transport Service Features . . . . 15 3.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 15 3.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 17 3.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . 18 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Informative References . . . . . . . . . . . . . . . . . . . 21 Appendix A. Revision information . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction 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 [TAPS1] and [TAPS2] 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 [TAPS2], we divide the transport service features into two main groups as follows: 1. CONNECTION related transport service features - ESTABLISHMENT - AVAILABILITY - MAINTENANCE Gjessing & Welzl Expires May 4, 2017 [Page 2] Internet-Draft Minimal TAPS Transport Services October 2016 - TERMINATION 2. 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 [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. It also assumes that TAPS applications have no specific requirements that need knowledge about the network, e.g. regarding the choice of network interface or the end-to-end path. Even with these assumptions, there are 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. Failure includes any change of the application behavior that is not performance oriented, e.g. security. "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: o Functional This transport service feature has to be specified by the application, since if not, it cannot be used or the application may fail (e.g. crash or be less secure). o Optimizing Gjessing & Welzl Expires May 4, 2017 [Page 3] Internet-Draft Minimal TAPS Transport Services October 2016 This transport service feature may be specified by the application, and when specified can optimize the performance. 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, a brief discussion is included. IETF transport services are presented following the nomenclature "CATEGORY.[SUBCATEGORY].SERVICENAME.PROTOCOL". The PROTOCOL name "UDP(-Lite)" is used when transport service features are equivalent for UDP and UDP-Lite; the PROTOCOL name "TCP" refers to both TCP and MPTCP. 2. Terminology The following terms are used throughout this document, and in subsequent documents produced by TAPS that describe the composition and decomposition of transport services. Transport Service Feature: 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. Transport Service: a set of Transport Features, without an association to any given framing protocol, which provides a complete service to an application. Transport Protocol: an implementation that provides one or more different transport services using a specific framing and header format on the wire. Transport Service Instance: 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). Application: 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). Application-specific knowledge: knowledge that only applications have. Gjessing & Welzl Expires May 4, 2017 [Page 4] Internet-Draft Minimal TAPS Transport Services October 2016 Endpoint: an entity that communicates with one or more other endpoints using a transport protocol. Connection: shared state of two or more endpoints that persists across messages that are transmitted between these endpoints. Socket: the combination of a destination IP address and a destination port number. 3. The Superset of Transport Service Features This section is based on the classification of the transport service features in pass 3 of [TAPS2]. 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 Section 4. 3.1. CONNECTION Related Transport Service Features ESTABLISHMENT: o Connect Protocols: TCP, SCTP, UDP(-Lite) 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, CONNECT.SCTP or CONNECT.UDP(- Lite). o Specify which IP Options must always be used Protocols: TCP Automatable because IP Options relate to knowledge about the network, not the application. o Request multiple streams Protocols: SCTP Automatable because using multi-streaming does not require application-specific knowledge. Implementation: see Section 4. o Obtain multiple sockets Protocols: SCTP Gjessing & Welzl Expires May 4, 2017 [Page 5] Internet-Draft Minimal TAPS Transport Services October 2016 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 Section 4. o Disable MPTCP Protocols: MPTCP Automatable because the usage of multiple paths to communicate to the same end host relates to knowledge about the network, not the application. o Specify which chunk types must always be authenticated Protocols: SCTP Optimizing because a TAPS system could always authenticate all chunk types; knowing which chunk types an application does not care to have authenticated can then improve the performance. o Indicate an Adaptation Layer (via an adaptation code point) Protocols: SCTP Functional because it allows to send extra data for the sake of identifying an adaptation layer, which by itself is application- specific. AVAILABILITY: o Listen Protocols: TCP, SCTP, UDP(-Lite) 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). o Listen, 1 specified local interface Gjessing & Welzl Expires May 4, 2017 [Page 6] Internet-Draft Minimal TAPS Transport Services October 2016 Protocols: TCP, SCTP, UDP(-Lite) Automatable because decisions about local interfaces relate to knowledge about the network and the Operating System, not the application. o Listen, N specified local interfaces Protocols: SCTP, UDP(-Lite) Automatable because decisions about local interfaces relate to knowledge about the network and the Operating System, not the application. o Listen, all local interfaces Protocols: TCP, SCTP, UDP(-Lite) Automatable because decisions about local interfaces relate to knowledge about the network and the Operating System, not the application. o Specify which IP Options must always be used Protocols: TCP Automatable because IP Options relate to knowledge about the network, not the application. o Disable MPTCP Protocols: MPTCP Automatable because the usage of multiple paths to communicate to the same end host relates to knowledge about the network, not the application. o Specify which chunk types must always be authenticated Protocols: SCTP Optimizing because a TAPS system could always authenticate all chunk types; knowing which chunk types an application does not care to have authenticated can then improve the performance. o Obtain requested number of streams Protocols: SCTP Gjessing & Welzl Expires May 4, 2017 [Page 7] Internet-Draft Minimal TAPS Transport Services October 2016 Automatable because using multi-streaming does not require application-specific knowledge. Implementation: see Section 4. o Indicate an Adaptation Layer (via an adaptation code point) Protocols: SCTP Functional because it allows to send extra data for the sake of identifying an adaptation layer, which by itself is application- specific. MAINTENANCE: o 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. o Control advertising timeout for aborting connection to remote endpoint Protocols: TCP Functional because this is closely related to potentially assumed reliable data delivery. o 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 [TAPS2] FOR SCTP**]. o Request an immediate heartbeat, returning success/failure Protocols: SCTP Automatable because this informs about network-specific knowledge. Gjessing & Welzl Expires May 4, 2017 [Page 8] Internet-Draft Minimal TAPS Transport Services October 2016 o 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; PotentiallyFailed.Max.Retrans; Primary.Switchover.Max.Retrans; Remote.UDPEncapsPort Automatable because these parameters relate to knowledge about the network, not the application. o 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. o Notification of ICMP error message arrival Protocols: TCP, UDP(-Lite) 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. o Status (query or notification) Protocols: SCTP, MPTCP 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 MPTCP parameters: subflow-list (identified by source-IP; source- Port; destination-IP; destination-Port) Automatable because these parameters relate to knowledge about the network, not the application. o Change authentication parameters Protocols: SCTP Gjessing & Welzl Expires May 4, 2017 [Page 9] Internet-Draft Minimal TAPS Transport Services October 2016 Optimizing because a TAPS system could always authenticate all chunk types; changing this behavior can then improve the performance. o Obtain authentication information Protocols: SCTP Functional because authentication decisions may have been made by the peer, and this has an influence on the necessary application- level measures to provide a certain level of security. o 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 Section 4. o Specify DSCP field Protocols: TCP, SCTP Optimizing because choosing a suitable DSCP value requires application-specific knowledge. Implementation: via CHANGE-DSCP.TCP and [**Not yet included in [TAPS2] FOR SCTP**] o Reset Stream Protocols: SCTP Automatable because using multi-streaming does not require application-specific knowledge. Implementation: see Section 4. o Notification of Stream Reset Protocols: STCP Automatable because using multi-streaming does not require application-specific knowledge. Implementation: see Section 4. o Reset Association Protocols: SCTP Gjessing & Welzl Expires May 4, 2017 [Page 10] Internet-Draft Minimal TAPS Transport Services October 2016 Functional because it affects "Obtain a message delivery number", which is functional. o Notification of Association Reset Protocols: STCP Functional because it affects "Obtain a message delivery number", which is functional. o Add Streams Protocols: SCTP Automatable because using multi-streaming does not require application-specific knowledge. Implementation: see Section 4. o Notification of Added Stream Protocols: STCP Automatable because using multi-streaming does not require application-specific knowledge. Implementation: see Section 4. o Set peer primary path Protocols: SCTP Automatable because decisions about local interfaces relate to knowledge about the network and the Operating System, not the application. o Add subflow Protocols: MPTCP MPTCP Parameters: source-IP; source-Port; destination-IP; destination-Port Automatable because the usage of multiple paths to communicate to the same end host relates to knowledge about the network, not the application. o Remove subflow Protocols: MPTCP MPTCP Parameters: source-IP; source-Port; destination-IP; destination-Port Gjessing & Welzl Expires May 4, 2017 [Page 11] Internet-Draft Minimal TAPS Transport Services October 2016 Automatable because the usage of multiple paths to communicate to the same end host relates to knowledge about the network, not the application. o Add local address Protocols: SCTP Automatable because decisions about local interfaces relate to knowledge about the network and the Operating System, not the application. o Remove local address Protocols: SCTP Automatable because decisions about local interfaces relate to knowledge about the network and the Operating System, not the application. o Disable checksum when sending Protocols: UDP Functional because application-specific knowledge is necessary to decide whether it can be acceptable to lose data integrity. o Disable checksum requirement when receiving Protocols: UDP Functional because application-specific knowledge is necessary to decide whether it can be acceptable to lose data integrity. o Specify checksum coverage used by the sender Protocols: UDP-Lite Functional because application-specific knowledge is necessary to decide for which parts of the data it can be acceptable to lose data integrity. o Specify minimum checksum coverage required by receiver Protocols: UDP-Lite Gjessing & Welzl Expires May 4, 2017 [Page 12] Internet-Draft Minimal TAPS Transport Services October 2016 Functional because application-specific knowledge is necessary to decide for which parts of the data it can be acceptable to lose data integrity. o Specify DF field Protocols: UDP(-Lite) Optimizing because the DF field can be used to carry out Path MTU Discovery, which can lead an application to choose message sizes that can be transmitted more efficiently. Implementation: via MAINTENANCE.SET_DF and SEND_FAILURE.UDP(-Lite) o Specify TTL/Hop count field Protocols: UDP(-Lite) Automatable because a TAPS system can use a large enough system default to avoid communication failures. Allowing an application to configure it differently can produce notifications of ICMP error message arrivals that yield information which only relates to knowledge about the network, not the application. o Obtain TTL/Hop count field Protocols: UDP(-Lite) Automatable because the TTL/Hop count field relates to knowledge about the network, not the application. o Specify ECN field Protocols: UDP(-Lite) Automatable because the ECN field relates to knowledge about the network, not the application. o Obtain ECN field Protocols: UDP(-Lite) Automatable because the ECN field relates to knowledge about the network, not the application. o Specify IP Options Protocols: UDP(-Lite) Gjessing & Welzl Expires May 4, 2017 [Page 13] Internet-Draft Minimal TAPS Transport Services October 2016 Automatable because IP Options relate to knowledge about the network, not the application. o Obtain IP Options Protocols: UDP(-Lite) Automatable because IP Options relate to knowledge about the network, not the application. TERMINATION: o 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. o 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. o 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. Gjessing & Welzl Expires May 4, 2017 [Page 14] Internet-Draft Minimal TAPS Transport Services October 2016 3.2. DATA Transfer Related Transport Service Features 3.2.1. Sending Data o Reliably transfer data, with congestion control 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. o Reliably transfer a message, with congestion control 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. o Unreliably transfer a message Protocols: SCTP, UDP(-Lite) Optimizing because only applications know about the time criticality of their communication, and reliably transfering a message is never incorrect for the receiver of a potentially unreliable data transfer, it is just slower. ADDED. This differs from the 2 automatable transport service features below in that it leaves the choice of congestion control open. Implementation: via SEND.SCTP or SEND.UDP. o Unreliably transfer a message, with congestion control Protocols: SCTP Automatable because congestion control relates to knowledge about the network, not the application. o Unreliably transfer a message, without congestion control Protocols: UDP(-Lite) Automatable because congestion control relates to knowledge about the network, not the application. Gjessing & Welzl Expires May 4, 2017 [Page 15] Internet-Draft Minimal TAPS Transport Services October 2016 o Configurable Message Reliability Protocols: SCTP Optimizing because only applications know about the time criticality of their communication, and reliably transfering a message is never incorrect for the receiver of a potentially unreliable data transfer, it is just slower. Implementation: via SEND.SCTP. Fall-back to TCP: By using SEND.TCP and ignoring this configuration: 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 reliability to a "message" in TCP anyway. o 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 Section 4. o 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 Section 4. o 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. o 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. Gjessing & Welzl Expires May 4, 2017 [Page 16] Internet-Draft Minimal TAPS Transport Services October 2016 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. o 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. o Specifying a key id to be used to authenticate a message Protocols: SCTP Functional because this has a direct influence on security. o Request not to delay the acknowledgement (SACK) of a message Protocols: SCTP Optimizing because only an application knows for which message it wants to quickly informed about success / failure of its delivery. 3.2.2. Receiving Data o 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 o Receive a message 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. Gjessing & Welzl Expires May 4, 2017 [Page 17] Internet-Draft Minimal TAPS Transport Services October 2016 Fall-back to TCP: By using RECEIVE.TCP and providing a means to let the application query whether messages can be identified or not. o 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 Section 4. o 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). o Obtain a message delivery number Protocols: SCTP Functional because this number can let applications detect and, if desired, correct reordering. Whether messages are in the correct order or not is closely tied to properties of the data that an application sends or expects to receive. 3.2.3. Errors o 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). o Notification of unsent messages Protocols: SCTP, UDP(-Lite) Gjessing & Welzl Expires May 4, 2017 [Page 18] Internet-Draft Minimal TAPS Transport Services October 2016 Optimizing because the DF field can be used to carry out Path MTU Discovery, which can lead an application to choose message sizes that can be transmitted more efficiently. Implementation: via MAINTENANCE.SET_DF and SEND_FAILURE.UDP(-Lite) o Notification of unacknowledged messages Protocols: SCTP Automatable because the distinction between unsent and unacknowledged is network-specific. 4. Discussion Some of transport service features in Section 3 were designated as "automatable" on the basis of a broader decision that affects multiple transport service features. These decisions are explained here: o All transport service features that are related to multi-streaming were designated as "automatable". 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. o All transport service features that are related to usage of multiple paths or the choice of the network interface were designated as "automatable". 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. 5. Conclusion 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 Gjessing & Welzl Expires May 4, 2017 [Page 19] Internet-Draft Minimal TAPS Transport Services October 2016 higher abstraction level allows more freedom for automation 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: o 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. o 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. o 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 Gjessing & Welzl Expires May 4, 2017 [Page 20] Internet-Draft Minimal TAPS Transport Services October 2016 system. This is a trade-off that must be considered in TAPS system design. 6. Acknowledgements 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). 7. IANA Considerations XX RFC ED - PLEASE REMOVE THIS SECTION XXX This memo includes no request to IANA. 8. Security Considerations Security will be considered in future versions of this document. 9. Informative References [RFC5290] Floyd, S. and M. Allman, "Comments on the Usefulness of Simple Best-Effort Traffic", RFC 5290, DOI 10.17487/RFC5290, July 2008, . [RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT)", RFC 7305, DOI 10.17487/RFC7305, July 2014, . [TAPS1] Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services provided by IETF transport protocols and congestion control mechanisms", Internet-draft draft-ietf-taps- transports-12, July 2016. [TAPS2] Welzl, M., Tuexen, M., and N. Khademi, "An Approach to Identify Services Provided by IETF Transport Protocols and Congestion Control Mechanisms", Internet-draft draft-ietf- taps-transports-usage-02, October 2016. Appendix A. Revision information 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; Gjessing & Welzl Expires May 4, 2017 [Page 21] Internet-Draft Minimal TAPS Transport Services October 2016 list of Transport Service Features adjusted to -01 version of [TAPS2] except that MPTCP is not included. -03: updated to be consistent with -02 version of [TAPS2]. Authors' Addresses Stein Gjessing University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway Phone: +47 22 85 24 44 Email: steing@ifi.uio.no Michael Welzl University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway Phone: +47 22 85 24 20 Email: michawe@ifi.uio.no Gjessing & Welzl Expires May 4, 2017 [Page 22]