A Minimal Set of Transport Services for End Systems
RFC 8923

Document Type RFC - Informational (October 2020; No errata)
Authors Michael Welzl  , Stein Gjessing 
Last updated 2020-10-21
Replaces draft-gjessing-taps-minset
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Stream WG state Submitted to IESG for Publication
Document shepherd Theresa Enghardt
Shepherd write-up Show (last changed 2018-08-20)
IESG IESG state RFC 8923 (Informational)
Consensus Boilerplate Yes
Telechat date
Responsible AD Magnus Westerlund
Send notices to Theresa Enghardt <theresa@inet.tu-berlin.de>
IANA IANA review state Version Changed - Review Needed
IANA action state No IANA Actions

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


   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

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.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
   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

   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