A Minimal Set of Transport Services for End Systems
RFC 8923
Internet Engineering Task Force (IETF) M. Welzl
Request for Comments: 8923 S. Gjessing
Category: Informational University of Oslo
ISSN: 2070-1721 October 2020
A Minimal Set of Transport Services for End Systems
Abstract
This document recommends a minimal set of Transport Services offered
by end systems and gives guidance on choosing among the available
mechanisms and protocols. It is based on the set of transport
features in RFC 8303.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8923.
Copyright Notice
Copyright (c) 2020 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
(https://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.
Table of Contents
1. Introduction
2. Terminology
3. Deriving the Minimal Set
4. The Reduced Set of Transport Features
4.1. CONNECTION-Related Transport Features
4.2. DATA-Transfer-Related Transport Features
4.2.1. Sending Data
4.2.2. Receiving Data
4.2.3. Errors
5. Discussion
5.1. Sending Messages, Receiving Bytes
5.2. Stream Schedulers without Streams
5.3. Early Data Transmission
5.4. Sender Running Dry
5.5. Capacity Profile
5.6. Security
5.7. Packet Size
6. The Minimal Set of Transport Features
6.1. ESTABLISHMENT, AVAILABILITY, and TERMINATION
6.2. MAINTENANCE
6.2.1. Connection Groups
6.2.2. Individual Connections
6.3. DATA Transfer
6.3.1. Sending Data
6.3.2. Receiving Data
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. The Superset of Transport Features
A.1. CONNECTION-Related Transport Features
A.2. DATA-Transfer-Related Transport Features
A.2.1. Sending Data
A.2.2. Receiving Data
A.2.3. Errors
Acknowledgements
Authors' Addresses
1. Introduction
Currently, the set of Transport Services that most applications use
is based on TCP and UDP (and protocols that are layered on top of
them); this limits the ability for the network stack to make use of
features of other transport protocols. For example, if a protocol
supports out-of-order message delivery but applications always assume
that the network provides an ordered byte stream, then the network
stack can not immediately deliver a message that arrives out of
order; doing so would break a fundamental assumption of the
application. The net result is unnecessary head-of-line blocking
delay.
By exposing the Transport Services of multiple transport protocols, a
transport system can make it possible for applications to use these
services without being statically bound to a specific transport
protocol. The first step towards the design of such a system was
taken by [RFC8095], which surveys a large number of transports, and
[RFC8303] as well as [RFC8304], which identify the specific transport
features that are exposed to applications by the protocols TCP,
Multipath TCP (MPTCP), UDP(-Lite), and Stream Control Transmission
Protocol (SCTP), as well as the Low Extra Delay Background Transport
(LEDBAT) congestion control mechanism. LEDBAT was included as the
only congestion control mechanism in this list because the "low extra
delay background transport" service that it offers is significantly
different from the typical service provided by other congestion
control mechanisms. This memo is based on these documents and
follows the same terminology (also listed below). Because the
considered transport protocols conjointly cover a wide range of
Show full document text