Diff: rfc8923xml2.original.xml

	rfc8923xml2.original.xml	rfc8923.xml

	<?xml version="1.0" encoding="US-ASCII"?>	<?xml version="1.0" encoding="UTF-8"?>
	<!-- This template is for creating an Internet Draft using xml2rfc,	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	which is available here: http://xml2rfc.ietf.org. -->
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!-- One method to get references from the online citation libraries.
	There has to be one entity for each item to be referenced.
	An alternate method (rfc include) is described in the references. -->
	<!--<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/ref
	erence.RFC.2119.xml">
	-->
	<!-- http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml-->
	<!--<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/re
	ference.RFC.2119.xml">-->
	<!--<!ENTITY RFC2309 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/ref
	erence.RFC.2309.xml">
	<!ENTITY RFC2481 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.2481.xml">
	<!ENTITY RFC3168 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.3168.xml">
	<!ENTITY RFC3649 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.3649.xml">
	<!ENTITY RFC3742 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.3742.xml">
	<!ENTITY RFC3758 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.3758.xml">
	<!ENTITY RFC4340 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.4340.xml">
	<!ENTITY RFC4774 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.4774.xml">
	<!ENTITY RFC4895 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.4895.xml">
	<!ENTITY RFC4960 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.4960.xml">
	<!ENTITY RFC5562 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.5562.xml">
	<!ENTITY RFC5670 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.5670.xml">
	<!ENTITY RFC5681 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.5681.xml">
	<!ENTITY RFC5696 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.5696.xml">
	<!ENTITY RFC6040 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.6040.xml">
	<!ENTITY RFC6679 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.6679.xml">
	<!ENTITY RFC6789 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.6789.xml">
	<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml2rfc.tools
	.ietf.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis
	.xml">
	-->
	<!ENTITY RFC8085 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.8085.xml">
	<!ENTITY RFC3758 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.3758.xml">
	<!ENTITY RFC4895 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.4895.xml">
	<!ENTITY RFC4987 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.4987.xml">
	<!ENTITY RFC5925 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.5925.xml">
	<!ENTITY RFC6897 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.6897.xml">
	<!ENTITY RFC7305 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.7305.xml">
	<!ENTITY RFC7413 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.7413.xml">
	<!ENTITY RFC7496 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.7496.xml">
	<!ENTITY RFC8095 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.8095.xml">
	<!ENTITY RFC8260 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.8260.xml">
	<!ENTITY RFC8303 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.8303.xml">
	<!ENTITY RFC8304 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.8304.xml">
	<!ENTITY I-D.ietf-tsvwg-rtcweb-qos SYSTEM "http://xml2rfc.tools.ietf.org/public/
	rfc/bibxml3/reference.I-D.ietf-tsvwg-rtcweb-qos.xml">
	<!ENTITY I-D.ietf-taps-interface SYSTEM "http://xml2rfc.tools.ietf.org/public/rf
	c/bibxml3/reference.I-D.draft-ietf-taps-interface-01.xml">
	<!ENTITY I-D.ietf-taps-transport-security SYSTEM "http://xml2rfc.tools.ietf.org/
	public/rfc/bibxml3/reference.I-D.draft-ietf-taps-transport-security-02.xml">
	]>

	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<!-- used by XSLT processors -->
	<!-- For a complete list and description of processing instructions (PIs),
	please see http://xml2rfc.ietf.org/authoring/README.html. -->
	<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
	might want to use.
	(Here they are set differently than their defaults in xml2rfc v1.32) -->
	<?rfc strict="yes" ?>
	<!-- give errors regarding ID-nits and DTD validation -->
	<!-- control the table of contents (ToC) -->
	<?rfc toc="yes"?>
	<!-- generate a ToC -->
	<?rfc tocdepth="3"?>
	<!-- the number of levels of subsections in ToC. default: 3 -->
	<!-- control references -->
	<?rfc symrefs="yes"?>
	<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
	<?rfc sortrefs="yes" ?>
	<!-- sort the reference entries alphabetically -->
	<!-- control vertical white space
	(using these PIs as follows is recommended by the RFC Editor) -->
	<?rfc compact="yes" ?>
	<!-- do not start each main section on a new page -->
	<?rfc subcompact="yes" ?>
	<!-- do not keep one blank line between list items -->
	<!-- end of list of popular I-D processing instructions -->
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
	<rfc category="info" docName="draft-ietf-taps-minset-11" ipr="trust200902">
	<!-- noModificationTrust200902 noDerivativesTrust200902 pre5378Trust20
	0902">-->

	<!-- updates="6298"> -->

	<!-- ipr="full3978"> -->

	<!-- category values: std, bcp, info, exp, and historic
	ipr values: full3667, noModification3667, noDerivatives3667
	you can add the attributes updates="NNNN" and obsoletes="NNNN"
	they will automatically be output with "(if approved)" -->


	<!-- *** FRONT MATTER *** -->	<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
		docName="draft-ietf-taps-minset-11" number="8923" ipr="trust200902"
		obsoletes="" updates="" submissionType="IETF" category="info"
		consensus="true" xml:lang="en" tocInclude="true" tocDepth="3"
		symRefs="true" sortRefs="true" version="3">

	<front>	<front>

	<!-- The abbreviated title is used in the page header - it is only neces
	sary if the
	full title is longer than 39 characters -->

	<!-- <title abbrev="Abbreviated Title">Coupled congestion control</title
	> -->

	<title abbrev="Minimal Transport Services">A Minimal Set of Transport Se rvices for End Systems</title>	<title abbrev="Minimal Transport Services">A Minimal Set of Transport Se rvices for End Systems</title>

		<seriesInfo name="RFC" value="8923"/>


	<!-- add 'role="editor"' below for the editors if appropriate -->

	<!-- Another author who claims to be an editor -->
	<author fullname="Michael Welzl" initials="M." surname="Welzl">	<author fullname="Michael Welzl" initials="M." surname="Welzl">

	<organization>University of Oslo</organization>	<organization>University of Oslo</organization>
		<address>
	<address>	<postal>
	<postal>	<pobox>PO Box 1080 Blindern</pobox>
	<street>PO Box 1080 Blindern</street>	<code>N-0316</code>
		<city>Oslo</city>
	<!-- Reorder these if your country does things differently -	<country>Norway</country>
	->	</postal>
		<phone>+47 22 85 24 20</phone>
	<code>N-0316</code>	<email>michawe@ifi.uio.no</email>

	<city>Oslo</city>

	<region></region>

	<country>Norway</country>
	</postal>

	<phone>+47 22 85 24 20</phone>

	<email>michawe@ifi.uio.no</email>


	<!-- uri and facsimile elements may also be added -->
	</address>	</address>

	</author>	</author>
		<author fullname="Stein Gjessing" initials="S." surname="Gjessing">
	<author fullname="Stein Gjessing" initials="S." surname="Gjessing">	<organization>University of Oslo</organization>
	<organization>University of Oslo</organization>	<address>
		<postal>
	<address>	<pobox>PO Box 1080 Blindern</pobox>
	<postal>	<code>N-0316</code>
	<street>PO Box 1080 Blindern</street>	<city>Oslo</city>
		<country>Norway</country>
	<!-- Reorder these if your country does things differently -	</postal>
	->	<phone>+47 22 85 24 44</phone>
		<email>steing@ifi.uio.no</email>
	<code>N-0316</code>

	<city>Oslo</city>

	<region></region>

	<country>Norway</country>
	</postal>

	<phone>+47 22 85 24 44</phone>

	<email>steing@ifi.uio.no</email>


	<!-- uri and facsimile elements may also be added -->
	</address>	</address>

	</author>	</author>

	<!-- <date day="06" month="June" year="2015" /> -->
	<date year="2018" />

	<!-- If the month and year are both specified and are the current ones,
	xml2rfc will fill
	in the current day for you. If only the current year is specified, xml2
	rfc will fill
	in the current day and month for you. If the year is not the current on
	e, it is
	necessary to specify at least a month (xml2rfc assumes day="1" if not s
	pecified for the
	purpose of calculating the expiry date). With drafts it is normally su
	fficient to
	specify just the year. -->


	<!-- Meta-data Declarations -->	<date year="2020" month="October" />

	<area>Transport</area>	<area>Transport</area>

		<workgroup>TAPS</workgroup>


	<workgroup>TAPS</workgroup>	<keyword>taps</keyword>
		<keyword>transport services</keyword>
	<!-- WG name at the upperleft corner of the doc,
	IETF is fine for individual submissions.
	If this element is not present, the default is "Network Working Group",
	which is used by the RFC Editor as a nod to the history of the IETF. --
	>

	<keyword>taps, transport services</keyword>

	<!-- Keywords will be incorporated into HTML output
	files in a meta tag but they have no effect on text or nroff
	output. If you submit your draft to the RFC Editor, the
	keywords will be used for the search engine. -->

	<abstract>	<abstract>

	<t>This draft recommends a minimal set of Transport Services offered	<t>This document recommends a minimal set of Transport Services offered
	by end systems,	by end systems and gives guidance on choosing among the available
	and gives guidance on choosing among the available mechanisms and pr	mechanisms and protocols. It is based on the set of transport features
	otocols. It is based on the set of	in RFC 8303.</t>
	transport features in RFC 8303.</t>	</abstract>
	</abstract>	</front>
	</front>	<middle>

	<middle>
	<!-- <section title="Definitions" anchor='sec-def'>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in <xref
	target="RFC2119">RFC 2119</xref>.</t>

	<t><list style="hanging" hangIndent="6">
	<t hangText="Wha'ever:">
	<vspace />
	Wha'ever is short for Whatever.</t>
	</list></t>

	</section>
	-->

	<section anchor="sec-intro" title="Introduction">
	<t>Currently, the set of transport services
	that most applications use is based on TCP and UDP (and protocols th
	at 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 su
	pports 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 fund
	amental assumption of the application. The net result
	is unnecessary head-of-line blocking delay.</t>

	<t>By exposing the transport services of multiple transport protocol
	s, 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
	<xref target="RFC8095"></xref>, which
	surveys a large number of transports, and <xref target="RFC8303"
	></xref> as well as <xref target="RFC8304"/>, which identify the specific
	transport features that are exposed to applications by the proto
	cols TCP, MPTCP, UDP(-Lite) and SCTP
	as well as the LEDBAT congestion control mechanism. LEDBAT was i
	ncluded 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 me
	chanisms.
	This memo is based on these documents and follows the same termi
	nology (also listed below).
	Because the considered transport protocols conjointly cover
	a wide range of transport features, there is reason to hope that
	the resulting set (and the
	reasoning that led to it) will also apply to many aspects of oth
	er transport protocols that may be in use today,
	or may be designed in the future.
	</t>

	<t>By decoupling applications from transport protocols, a transport
	system provides a different abstraction level
	than the Berkeley sockets interface <xref target="POSIX"/>. As w
	ith high- vs. low-level programming languages, a higher abstraction
	level allows more freedom for automation below the interface, ye
	t it takes some control away from
	the application programmer. This is the design trade-off that a
	transport system developer is facing, and
	this document provides guidance on the design of this abstractio
	n level. Some transport features
	are currently rarely offered by APIs, yet they must be offered o
	r they can never be used.
	Other transport features are offered by the APIs of the protocol
	s covered here,
	but not exposing them in an API would allow for more freedom to
	automate protocol usage in a transport system.
	The minimal set presented here is an effort to find a middle gro
	und that can be recommended
	for transport systems to implement, on the basis of the transpor
	t features discussed in <xref target="RFC8303"/>.</t>


	<t>Applications use a wide variety of APIs today. While this documen	<section anchor="sec-intro" numbered="true" toc="default">
	t was created to ensure the API developed in the	<name>Introduction</name>
	Transport Services (TAPS) Working Group (<xref target="I-D.ietf-	<t>Currently, the set of Transport Services that most applications use
	taps-interface" />) includes the most important	is based on TCP and UDP (and protocols that are layered on top of them);
	transport features, the minimal set	this limits the ability for the network stack to make use of features of
	presented here must be reflected in all network APIs in order	other transport protocols. For example, if a protocol supports
	for the underlying functionality to	out-of-order message delivery but applications always assume that the
	become usable everywhere. For example, it does not help an applicati	network provides an ordered byte stream, then the network stack can not
	on that talks to a library which offers its	immediately deliver a message that arrives out of order; doing so would
	own communication interface if the underlying	break a fundamental assumption of the application. The net result is
	Berkeley Sockets API is extended to offer "unordered message deliver	unnecessary head-of-line blocking delay.</t>
	y", but the library only exposes an	<t>By exposing the Transport Services of multiple transport protocols, a
	ordered bytestream. Both the Berkeley Sockets API and the library wo	transport system can make it possible for applications to use these
	uld have to	services without being statically bound to a specific transport
	expose the "unordered message delivery" transport feature	protocol. The first step towards the design of such a system was taken
	(alternatively, there may be ways for certain types of libraries to	by <xref target="RFC8095" format="default"/>, which surveys a large
	use this	number of transports, and <xref target="RFC8303" format="default"/> as
	transport feature without exposing it, based on knowledge about the	well as <xref target="RFC8304" format="default"/>, which identify the
	applications -- but this is not the general case). Similarly, transp	specific transport features that are exposed to applications by the
	ort protocols such as SCTP offer	protocols TCP, Multipath TCP (MPTCP), UDP(-Lite), and Stream Control
	multi-streaming, which cannot be utilized, e.g., to prioritize messa	Transmission Protocol (SCTP), as well as the Low Extra Delay Background
	ges between streams,	Transport (LEDBAT) congestion control mechanism. LEDBAT was included as
	unless applications communicate the priorities and the group of conn	the only congestion control mechanism in this list because the "low
	ections upon which these	extra delay background transport" service that it offers is
	priorities should be applied.	significantly different from the typical service provided by other
	In most situations, in the interest of being as flexible and efficie	congestion control mechanisms. This memo is based on these documents
	nt as possible, the best choice will be for	and follows the same terminology (also listed below). Because the
	a library to expose at least all of the transport features that are	considered transport protocols conjointly cover a wide range of
	recommended as a "minimal set" here.	transport features, there is reason to hope that the resulting set (and
	<!-- MICHAEL: The point of the example below was to mention somethin	the reasoning that led to it) will also apply to many aspects of other
	g that's already valid today - but now I don't	transport protocols that may be in use today or may be designed in the
	think this is necessary or improves the text quality.-->	future.
	<!--As an example	</t>
	considering only TCP and UDP, a middleware or library that only offe	<t>By decoupling applications from transport protocols, a transport
	rs TCP's reliable bytestream cannot make use	system provides a different abstraction level than the Berkeley sockets
	of UDP (unless it implements extra functionality on top of UDP) - do	interface <xref target="POSIX" format="default"/>. As with high-
	ing so could break a	vs. low-level programming languages, a higher abstraction level allows
	fundamental assumption that applications make about the data they se	more freedom for automation below the interface, yet it takes some
	nd and receive.-->	control away from the application programmer. This is the design
	</t>	trade-off that a transport system developer is facing, and this document
		provides guidance on the design of this abstraction level. Some
		transport features are currently rarely offered by APIs, yet they must
		be offered or they can never be used. Other transport features are
		offered by the APIs of the protocols covered here, but not exposing them
		in an API would allow for more freedom to automate protocol usage in a
		transport system. The minimal set presented here is an effort to find a
		middle ground that can be recommended for transport systems to
		implement, on the basis of the transport features discussed in <xref
		target="RFC8303" format="default"/>.</t>
		<t>Applications use a wide variety of APIs today. While this document
		was created to ensure the API developed in the Transport Services (TAPS)
		Working Group <xref target="I-D.ietf-taps-interface"
		format="default"/> includes the most important transport features, the
		minimal set presented here must be reflected in all network APIs in
		order for the underlying functionality to become usable everywhere. For
		example, it does not help an application that talks to a library that
		offers its own communication interface if the underlying Berkeley
		Sockets API is extended to offer "unordered message delivery", but the
		library only exposes an ordered byte stream. Both the Berkeley Sockets
		API and the library would have to expose the "unordered message
		delivery" transport feature (alternatively, there may be ways for
		certain types of libraries to use this transport feature without
		exposing it, based on knowledge about the applications, but this is not
		the general case). Similarly, transport protocols such as the Stream
		Control Transmission Protocol (SCTP) offer multi-streaming, which cannot
		be utilized, e.g., to prioritize messages between streams, unless
		applications communicate the priorities and the group of connections
		upon which these priorities should be applied. In most situations, in
		the interest of being as flexible and efficient as possible, the best
		choice will be for a library to expose at least all of the transport
		features that are recommended as a "minimal set" here.


	<t>	</t>
		<t>
	This "minimal set" can be implemented "one-sided" over TCP. Thi s means	This "minimal set" can be implemented "one-sided" over TCP. Thi s means
	that a sender-side transport system can talk to a standard TCP r eceiver,	that a sender-side transport system can talk to a standard TCP r eceiver,
	and a receiver-side transport system can talk to a standard TCP sender.	and a receiver-side transport system can talk to a standard TCP sender.
	If certain limitations are put in place, the "minimal set" can a lso be	If certain limitations are put in place, the "minimal set" can a lso be
	implemented "one-sided" over UDP. While the possibility of such "one-sided"	implemented "one-sided" over UDP. While the possibility of such "one-sided"
	implementation may help deployment, it comes at the cost of limi ting the	implementation may help deployment, it comes at the cost of limi ting the
	set to services that can also be provided by TCP (or, with furth er	set to services that can also be provided by TCP (or, with furth er
	limitations, UDP). Thus, the minimal set of transport features h ere is	limitations, UDP). Thus, the minimal set of transport features h ere is

	applicable for many, but not all, applications: some application	applicable for many, but not all, applications; some application
	protocols have requirements that are not met by this "minimal se t".	protocols have requirements that are not met by this "minimal se t".

	</t>	</t>
		<t>
	<t>
	Note that, throughout this document, protocols are meant to be u sed	Note that, throughout this document, protocols are meant to be u sed

	natively. For example, when transport features of UDP, or "imple	natively. For example, when transport features of TCP, or "imple
	mentation over"	mentation over"
	UDP is discussed, this refers to native usage of UDP.	TCP is discussed, this refers to native usage of TCP rather
	</t>	than TCP being encapsulated in some other transport protocol
		such as UDP.
	</section>	</t>
		</section>
	<section title="Terminology">	<section numbered="true" toc="default">
		<name>Terminology</name>
	<!-- <t>The following terms are used throughout this document, and in
	subsequent documents produced by TAPS that describe the composit
	ion and
	decomposition of transport services.</t>


	<t><list style="hanging">	<dl newline="false" >
	<t hangText='Transport Feature:'>	<dt>Transport Feature:</dt>
	a specific end-to-end feature that the transport layer provi	<dd>
	des to	A specific end-to-end feature that the transport layer
	an application. Examples include confidentiality, reliable d	provides to an application. Examples include
	elivery, ordered	confidentiality, reliable delivery, ordered delivery,
	delivery, message-versus-stream orientation, etc.</t>	message-versus-stream orientation, etc.</dd>
	<t hangText='Transport Service:'>	<dt>Transport Service:</dt>
	a set of Transport Features, without an association to any g	<dd>
	iven	A set of Transport Features, without an association to any g
	framing protocol, which provides a complete service to an ap	iven
	plication.</t>	framing protocol, that provides a complete service to an app
	<t hangText='Transport Protocol:'>	lication.</dd>
	an implementation that provides one or more different transp	<dt>Transport Protocol:</dt>
	ort services	<dd>
	using a specific framing and header format on the wire.</t>	An implementation that provides one or more different Transp
	<t hangText='Application:'>	ort Services
	an entity that uses a transport layer interface for end-to-e	using a specific framing and header format on the wire.</dd>
	nd delivery of data	<dt>Application:</dt>
	across the network (this may also be an upper layer protocol	<dd>
	or tunnel	An entity that uses a transport-layer interface for end-to-e
	encapsulation).</t>	nd delivery of data
	<t hangText='Application-specific knowledge:'>	across the network (this may also be an upper-layer protocol
	knowledge that only applications have.</t>	or tunnel
	<t hangText='End system:'>	encapsulation).</dd>
	an entity that communicates with one or more other end syste	<dt>Application-specific knowledge:</dt>
	ms using	<dd>
	a transport protocol. An end system provides a transport lay	Knowledge that only applications have.</dd>
	er interface	<dt>End system:</dt>
		<dd>
		An entity that communicates with one or more other end syste
		ms using
		a transport protocol. An end system provides a transport-lay
		er interface
	to applications.	to applications.

	</t>	</dd>
	<t hangText='Connection:'>	<dt>Connection:</dt>
	shared state of two or more end systems that persists	<dd>
	across messages that are transmitted between these end syste	Shared state of two or more end systems that persists
	ms.</t>	across messages that are transmitted between these end syste
	<t hangText='Connection Group:'>	ms.</dd>
	a set of connections which share the same configuration (con	<dt>Connection Group:</dt>
	figuring	<dd>
	one of them causes all other connections in the same	A set of connections that share the same configuration
	group to be configured in the same way). We call connections	(configuring one of them causes all other connections in
	that	the same group to be configured in the same way). We call
	belong to a connection group	connections that belong to a connection group "grouped",
	"grouped", while "ungrouped" connections are not a part of	while "ungrouped" connections are not a part of a
	a connection group.</t>	connection group.</dd>
	<t hangText='Socket:'>	<dt>Socket:</dt>
	the combination of a destination IP address and a destinatio	<dd>
	n port number.</t>	The combination of a destination IP address and a destinatio
		n port number.</dd>
		</dl>


	</list></t>	<t>Moreover, throughout the document, the protocol name "UDP(-Lite)" is used
	<t>Moreover, throughout the document, the protocol name "UDP(-Lite)"	when
	is used when
	discussing transport features that are equivalent for UDP and UD P-Lite; similarly,	discussing transport features that are equivalent for UDP and UD P-Lite; similarly,
	the protocol name "TCP" refers to both TCP and MPTCP.	the protocol name "TCP" refers to both TCP and MPTCP.

	</t>	</t>
		</section>
	</section>	<section anchor="deriving" numbered="true" toc="default">
		<name>Deriving the Minimal Set</name>
	<section anchor="deriving" title="Deriving the minimal set">	<t>

	<t><!-- MICHAEL: Gorry suggested this is unnecessary to state. -->
	<!--Because QoS is out of scope of TAPS, this document assumes a
	"best effort" service
	model <xref target="RFC5290"></xref>, <xref target="RFC7305"></
	xref>. Applications using a TAPS system can
	therefore not make any assumptions
	about e.g. the time it will take to send a message.
	-->
	We assume that 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 m
	ust also be kept by a transport system.
	Some of these requirements relate to transport features that we
	call "Functional".
	</t>

	<t>Functional transport features provide functionality that cannot b
	e used without the application knowing
	about them, or else they violate assumptions that might cause th
	e application to fail.
	For example, ordered message delivery is a functional transport
	feature: it cannot be configured without
	the application knowing about it because the application's assum
	ption could be that
	messages always arrive in order. Failure includes any change of
	the application behavior that is not
	performance oriented, e.g. security.
	</t>

	<t>"Change DSCP" and "Disable Nagle algorithm" are examples of trans
	port features
	that we call "Optimizing":
	if a transport system autonomously decides to enable or disable
	them, an
	application will not fail, but a transport system may be able to
	communicate more efficiently if the application is in control of
	this
	optimizing transport feature. These
	transport features require application-specific knowledge (e.g.,
	about delay/bandwidth
	requirements or the length of future data blocks that are to be
	transmitted).
	</t>

	<t>
	The transport features of IETF transport protocols that do not r
	equire application-specific knowledge and could therefore
	be utilized by a transport system on its own without involving t
	he application are called "Automatable".
	</t>

	<t>We approach the construction of a minimal set of transport featur
	es in the following way:
	<list style="numbers">
	<t>Categorization (<xref target="super"/>): the superset of
	transport features from <xref target="RFC8303"></xref> is presented,
	and transport features are categorized as Functional, Op
	timizing or Automatable for later reduction.</t>
	<t>Reduction (<xref target="Reduction"/>): a shorter list of
	transport features is derived from the categorization in the
	first step. This removes all transport features that do
	not require application-specific knowledge
	or would result in semantically incorrect behavior if th
	ey were implemented
	over TCP or UDP.</t>
	<t>Discussion (<xref target="Discussion"/>): the resulting l
	ist shows a number of peculiarities that are discussed, to provide a basis
	for constructing the minimal set.</t>
	<t>Construction (<xref target="minset"/>): Based on the redu
	ced set and the discussion of the transport features therein, a
	minimal set is constructed.</t>
	</list></t>

	<t>Following <xref target="RFC8303"></xref> and retaining its te
	rminology, we divide the transport
	features into two main groups as follows:
	<list style="numbers">
	<t>CONNECTION related transport features <vspace />
	- ESTABLISHMENT<vspace />
	- AVAILABILITY<vspace />
	- MAINTENANCE<vspace />
	- TERMINATION<vspace />
	</t>
	<t>DATA Transfer related transport features <vspace />
	- Sending Data<vspace />
	- Receiving Data<vspace />
	- Errors<vspace />
	</t>
	</list>
	</t>

	</section>

	<section anchor="Reduction" title="The Reduced Set of Transport Features
	">


	<t>By hiding automatable transport features from the application, a	We assume that applications have no specific requirements that
	transport system can	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 transport system. Some of these requirements relate to
		transport features that we call "Functional".
		</t>
		<t>Functional transport 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,
		ordered message delivery is a functional transport feature: it cannot be
		configured without the application knowing about it because the
		application's assumption could be that messages always arrive in
		order. Failure includes any change of the application behavior that is
		not performance oriented, e.g., security.
		</t>
		<t>"Change DSCP" and "Disable Nagle algorithm" are examples of transport
		features that we call "Optimizing"; if a transport system autonomously
		decides to enable or disable them, an application will not fail, but a
		transport system may be able to communicate more efficiently if the
		application is in control of this optimizing transport feature. These
		transport features require application-specific knowledge (e.g., about
		delay/bandwidth requirements or the length of future data blocks that
		are to be transmitted).
		</t>
		<t>
		The transport features of IETF transport protocols that do not
		require application-specific knowledge and could therefore be
		utilized by a transport system on its own without involving
		the application are called "Automatable".
		</t>
		<t>We approach the construction of a minimal set of transport features
		in the following way:
		</t>
		<ol type="1">
		<li>Categorization (<xref target="super" format="default"/>): The
		superset of transport features from <xref target="RFC8303"
		format="default"/> is presented, and transport features are
		categorized as Functional, Optimizing, or Automatable for later
		reduction.</li>
		<li>Reduction (<xref target="Reduction" format="default"/>): A shorter
		list of transport features is derived from the categorization in the
		first step. This removes all transport features that do not require
		application-specific knowledge or would result in semantically
		incorrect behavior if they were implemented over TCP or UDP.</li>
		<li>Discussion (<xref target="Discussion" format="default"/>): The
		resulting list shows a number of peculiarities that are discussed, to
		provide a basis for constructing the minimal set.</li>
		<li>Construction (<xref target="minset" format="default"/>): Based on
		the reduced set and the discussion of the transport features therein,
		a minimal set is constructed.</li>
		</ol>
		<t>Following <xref target="RFC8303" format="default"/> and retaining its
		terminology, we divide the transport features into two main groups as
		follows:
		</t>
		<ol type="1">
		<li>
		<t>CONNECTION-related transport features</t>
		<ul spacing="compact">
		<li>ESTABLISHMENT</li>
		<li>AVAILABILITY</li>
		<li>MAINTENANCE</li>
		<li>TERMINATION</li>
		</ul>
		</li>
		<li>
		<t>DATA-Transfer-related transport features</t>
		<ul spacing="compact">
		<li>Sending Data</li>
		<li>Receiving Data</li>
		<li>Errors</li>
		</ul>
		</li>
		</ol>
		</section>
		<section anchor="Reduction" numbered="true" toc="default">
		<name>The Reduced Set of Transport Features</name>
		<t>By hiding automatable transport features from the application, a transp
		ort system can
	gain opportunities to automate the usage of network-related func tionality. This can facilitate	gain opportunities to automate the usage of network-related func tionality. This can facilitate
	using the transport system	using the transport system
	for the application programmer and it allows for optimizations t hat may not be possible	for the application programmer and it allows for optimizations t hat may not be possible
	for an application. For instance, system-wide configurations	for an application. For instance, system-wide configurations
	regarding the usage of multiple interfaces can better be exploit ed if the choice of the	regarding the usage of multiple interfaces can better be exploit ed if the choice of the
	interface is not entirely up to the application. Therefore, sinc e they are not strictly	interface is not entirely up to the application. Therefore, sinc e they are not strictly
	necessary to expose in a transport system,	necessary to expose in a transport system,
	we do not include automatable transport features in the reduced set of transport	we do not include automatable transport features in the reduced set of transport
	features. This leaves us with only the transport features that	features. This leaves us with only the transport features that
	are either optimizing or functional.	are either optimizing or functional.

	</t>	</t>
	<t>A transport system should be able to communicate via TCP or UDP i	<t>A transport system should be able to communicate via TCP or UDP if
	f alternative transport protocols	alternative transport protocols are found not to work. For many
	are found not to work. For many transport features, this is poss	transport features, this is possible, often by simply not doing
	ible -- often by simply	anything when a specific request is made. For some transport features,
	not doing anything when a specific request is made.	however, it was identified that direct usage of neither TCP nor UDP is
	For some transport features, however, it was identified that dir	possible; in these cases, even not doing anything would incur
	ect usage of neither	semantically incorrect behavior. Whenever an application would make use
	TCP nor UDP is possible: in these cases, even not doing anything	of one of these transport features, this would eliminate the possibility
	would incur semantically	to use TCP or UDP. Thus, we only keep the functional and optimizing
	incorrect behavior.	transport features for which an implementation over either TCP or UDP is
	Whenever an application would make use of one of these transport	possible in our reduced set.
	features, this would eliminate the	</t>
	possibility to use TCP or UDP. Thus, we only keep the functional	<t>The following list contains the transport features from <xref
	and optimizing transport features	target="super" format="default"/>, reduced using these rules. The
	for which an implementation over either TCP or UDP is possible i	"minimal set" derived in this document is meant to be implementable
	n our reduced set.	"one-sided" over TCP and, with limitations, UDP. In the list, we
	</t>	therefore precede a transport feature with "T:" if an implementation
	<t>The following list contains the transport features from <xref tar	over TCP is possible, "U:" if an implementation over UDP is possible,
	get="super"/>, reduced	and "T,U:" if an implementation over either TCP or UDP is possible.
	using these rules. The "minimal set" derived in this document is	</t>
	meant to be implementable "one-sided"	<section anchor="conn-reduced" numbered="true" toc="default">
	over TCP, and, with limitations, UDP. In the list, we therefore	<name>CONNECTION-Related Transport Features</name>
	precede a transport	<t>ESTABLISHMENT:
	feature with "T:" if an implementation over TCP	</t>
	is possible, "U:" if an implementation over UDP is possible, and	<ul spacing="compact">
	"T,U:" if an implementation	<li>T,U: Connect</li>
	over either TCP or UDP is possible.	<li>T,U: Specify number of attempts and/or timeout for the first estab
	</t>	lishment message</li>
		<li>T,U: Disable MPTCP</li>
	<section anchor="conn-reduced" title="CONNECTION Related Transport F	<li>T: Configure authentication</li>
	eatures">	<li>T: Hand over a message to reliably transfer (possibly multiple
		times) before connection establishment</li>
	<t>ESTABLISHMENT:<vspace />	<li>T: Hand over a message to reliably transfer during connection esta
		blishment</li>
	<list style="symbols">	</ul>
	<t>T,U: Connect</t>
	<t>T,U: Specify number of attempts and/or timeout for th
	e first establishment message</t>
	<t>T,U: Disable MPTCP</t>
	<t>T: Configure authentication</t>
	<t>T: Hand over a message to reliably transfer (possibly
	multiple times) before connection establishment</t>
	<t>T: Hand over a message to reliably transfer during co
	nnection establishment</t>
	</list></t>

	<t>AVAILABILITY:<vspace />

	<list style="symbols">
	<t>T,U: Listen</t>
	<t>T,U: Disable MPTCP</t>
	<t>T: Configure authentication</t>
	</list></t>

	<t>MAINTENANCE:<vspace />

	<list style="symbols">
	<t>T: Change timeout for aborting connection (using retr
	ansmit limit or time value)</t>
	<t>T: Suggest timeout to the peer</t>
	<t>T,U: Disable Nagle algorithm</t>
	<t>T,U: Notification of Excessive Retransmissions (early
	warning below abortion threshold)</t>
	<t>T,U: Specify DSCP field</t>
	<t>T,U: Notification of ICMP error message arrival</t>
	<t>T: Change authentication parameters</t>
	<t>T: Obtain authentication information</t>
	<t>T,U: Set Cookie life value</t>
	<t>T,U: Choose a scheduler to operate between streams of
	an association</t>
	<t>T,U: Configure priority or weight for a scheduler</t>
	<t>T,U: Disable checksum when sending</t>
	<t>T,U: Disable checksum requirement when receiving</t>
	<t>T,U: Specify checksum coverage used by the sender</t>
	<t>T,U: Specify minimum checksum coverage required by re
	ceiver</t>
	<t>T,U: Specify DF field</t>
	<t>T,U: Get max. transport-message size that may be sent
	using a non-fragmented IP packet from the configured interface</t>
	<t>T,U: Get max. transport-message size that may be rece
	ived from the configured interface</t>
	<t>T,U: Obtain ECN field</t>
	<t>T,U: Enable and configure a "Low Extra Delay Backgrou
	nd Transfer"</t>
	</list></t>

	<t>TERMINATION:<vspace />

	<list style="symbols">
	<t>T: Close after reliably delivering all remaining data
	, causing an event informing the application on the other side</t>
	<t>T: Abort without delivering remaining data, causing a
	n event informing the application on the other side</t>
	<t>T,U: Abort without delivering remaining data, not cau
	sing an event informing the application on the other side</t>
	<t>T,U: Timeout event when data could not be delivered f
	or too long</t>
	</list></t>

	</section>

	<section anchor="data-reduced" title="DATA Transfer Related Transpor
	t Features">

	<section anchor="data-sending-reduced" title="Sending Data">

	<t><list style="symbols">
	<t>T: Reliably transfer data, with congestion control</t
	>
	<t>T: Reliably transfer a message, with congestion contr
	ol</t>
	<t>T,U: Unreliably transfer a message</t>
	<t>T: Configurable Message Reliability</t>
	<t>T: Ordered message delivery (potentially slower than
	unordered)</t>
	<t>T,U: Unordered message delivery (potentially faster t
	han ordered)</t>
	<t>T,U: Request not to bundle messages</t>
	<t>T: Specifying a key id to be used to authenticate a m
	essage</t>
	<t>T,U: Request not to delay the acknowledgement (SACK)
	of a message</t>
	</list></t>

	</section>

	<section anchor="data-receiving-reduced" title="Receiving Data">

	<t>
	<list style="symbols">
	<t>T,U: Receive data (with no message delimiting)</t
	>
	<t>U: Receive a message</t>
	<t>T,U: Information about partial message arrival</t
	>
	</list>
	</t>
	</section>


	<section anchor="data-errors-reduced" title="Errors">	<t>AVAILABILITY:
	<t>This section describes sending failures that are associat	</t>
	ed with a	<ul spacing="compact">
	specific call to in the "Sending Data" category (<xref t	<li>T,U: Listen</li>
	arget="data-sending-pass3"/>).</t>	<li>T,U: Disable MPTCP</li>
	<t>	<li>T: Configure authentication</li>
	<list style="symbols">	</ul>
	<t>T,U: Notification of send failures</t>
	<t>T,U: Notification that the stack has no more user
	data to send</t>
	<t>T,U: Notification to a receiver that a partial me
	ssage delivery has been aborted</t>
	</list>
	</t>
	</section>


	</section>	<t>MAINTENANCE:
		</t>
		<ul spacing="compact">
		<li>T: Change timeout for aborting connection (using retransmit limit
		or time value)</li>
		<li>T: Suggest timeout to the peer</li>
		<li>T,U: Disable Nagle algorithm</li>
		<li>T,U: Notification of Excessive Retransmissions (early warning belo
		w abortion threshold)</li>
		<li>T,U: Specify DSCP field</li>
		<li>T,U: Notification of ICMP error message arrival</li>
		<li>T: Change authentication parameters</li>
		<li>T: Obtain authentication information</li>
		<li>T,U: Set Cookie life value</li>
		<li>T,U: Choose a scheduler to operate between streams of an associati
		on</li>
		<li>T,U: Configure priority or weight for a scheduler</li>
		<li>T,U: Disable checksum when sending</li>
		<li>T,U: Disable checksum requirement when receiving</li>
		<li>T,U: Specify checksum coverage used by the sender</li>
		<li>T,U: Specify minimum checksum coverage required by receiver</li>
		<li>T,U: Specify DF field</li>
		<li>T,U: Get max. transport-message size that may be sent using a non-
		fragmented IP packet from the configured interface</li>
		<li>T,U: Get max. transport-message size that may be received from the
		configured interface</li>
		<li>T,U: Obtain ECN field</li>
		<li>T,U: Enable and configure a "Low Extra Delay Background Transfer"<
		/li>
		</ul>


		<t>TERMINATION:
		</t>
		<ul spacing="compact">
		<li>T: Close after reliably delivering all remaining data, causing
		an event informing the application on the other side</li>
		<li>T: Abort without delivering remaining data, causing an event
		informing the application on the other side</li>
		<li>T,U: Abort without delivering remaining data, not causing an
		event informing the application on the other side</li>
		<li>T,U: Timeout event when data could not be delivered for too long</
		li>
		</ul>
		</section>
		<section anchor="data-reduced" numbered="true" toc="default">
		<name>DATA-Transfer-Related Transport Features</name>
		<section anchor="data-sending-reduced" numbered="true" toc="default">
		<name>Sending Data</name>
		<ul spacing="compact">
		<li>T: Reliably transfer data, with congestion control</li>
		<li>T: Reliably transfer a message, with congestion control</li>
		<li>T,U: Unreliably transfer a message</li>
		<li>T: Configurable Message Reliability</li>
		<li>T: Ordered message delivery (potentially slower than unordered)<
		/li>
		<li>T,U: Unordered message delivery (potentially faster than ordered
		)</li>
		<li>T,U: Request not to bundle messages</li>
		<li>T: Specifying a key id to be used to authenticate a message</li>
		<li>T,U: Request not to delay the acknowledgement (SACK) of a messag
		e</li>
		</ul>
	</section>	</section>

		<section anchor="data-receiving-reduced" numbered="true" toc="default">
		<name>Receiving Data</name>
		<ul spacing="compact">
		<li>T,U: Receive data (with no message delimiting)</li>
		<li>U: Receive a message</li>
		<li>T,U: Information about partial message arrival</li>
		</ul>
		</section>
		<section anchor="data-errors-reduced" numbered="true" toc="default">
		<name>Errors</name>
		<t>This section describes sending failures that are associated with
		a specific call to in the "Sending Data" category (<xref
		target="data-sending-pass3" format="default"/>).</t>
		<ul spacing="compact">
		<li>T,U: Notification of send failures</li>
		<li>T,U: Notification that the stack has no more user data to send</
		li>
		<li>T,U: Notification to a receiver that a partial message delivery
		has been aborted</li>
		</ul>
		</section>
		</section>
		</section>


	<section anchor="Discussion" title="Discussion">	<section anchor="Discussion" numbered="true" toc="default">
		<name>Discussion</name>
	<t>The reduced set in the previous section exhibits a number of pecu	<t>The reduced set in the previous section exhibits a number of
	liarities,	peculiarities, which we will discuss in the following. This section
	which we will discuss in the following. This section focuses on	focuses on TCP because, with the exception of one particular transport
	TCP because,	feature ("Receive a message"; we will discuss this in <xref
	with the exception of one particular transport feature ("Receive	target="sendmsg" format="default"/>), the list shows that UDP is
	a message" --	strictly a subset of TCP. We can first try to understand how to build a
	we will discuss this in <xref target="sendmsg"/>), the list show	transport system that can run over TCP, and then narrow down the result
	s that UDP is	further to allow that the system can always run over either TCP or UDP
	strictly a subset of TCP. We can	(which effectively means removing everything related to reliability,
	first try to understand how to build a transport system that can	ordering, authentication, and closing/aborting with a notification to the
	run over	peer).
	TCP, and then narrow down the result further to allow that the s	</t>
	ystem can always	<t>Note that, because the functional transport features of UDP are, with
	run over either TCP or UDP (which effectively means removing	the exception of "Receive a message", a subset of TCP, TCP can be used
	everything related to reliability, ordering, authentication and	as a replacement for UDP whenever an application does not need message
	closing/aborting	delimiting (e.g., because the application-layer protocol already does
	with a notification to the peer).	it). This has been recognized by many applications that already do this
	</t>	in practice, by trying to communicate with UDP at first and falling
	<t>Note that, because the functional transport features of UDP are -	back to TCP in case of a connection failure.
	- with the	</t>
	exception of "Receive a message" -- a subset of	<section anchor="sendmsg" numbered="true" toc="default">
	TCP, TCP can be used as a replacement for UDP whenever an applic	<name>Sending Messages, Receiving Bytes</name>
	ation does not need	<t>For implementing a transport system over TCP, there are several
	message delimiting (e.g., because the application-layer protocol	transport features related to sending, but only a single transport
	already does it).	feature related to receiving: "Receive data (with no message
	This has been recognized by many applications that already do th	delimiting)" (and, strangely, "information about partial message
	is in practice,	arrival"). Notably, the transport feature "Receive a message" is also
	by trying to communicate with UDP at first, and falling back to	the only non-automatable transport feature of UDP(-Lite) for which no
	TCP in case of a	implementation over TCP is possible.</t>
	connection failure.
	</t>

	<section anchor="sendmsg" title="Sending Messages, Receiving Bytes">

	<t>For implementing a transport system over TCP, there are sever
	al transport features related to
	sending, but only a single transport feature
	related to receiving: "Receive data (with no message delimit
	ing)" (and, strangely, "information about
	partial message arrival"). Notably, the transport feature
	"Receive a message" is also the only non-automatable transpo
	rt feature of UDP(-Lite) for
	which no implementation over TCP is possible.</t>
	<!-- FROM MICHAEL: this is true, but not helping the explanation
	.

	It is also represents the only way
	that UDP(-Lite) applications can receive data today.</t>
	-->

	<t>To support these TCP receiver semantics, we define an "Applic
	ation-Framed Bytestream" (AFra-Bytestream).
	AFra-Bytestreams allow senders to operate on messages while
	minimizing changes to the TCP socket API. In particular, not
	hing changes on the receiver side - data can be accepted via a normal TCP socket
	.
	</t>

	<t>In an AFra-Bytestream, the sending application can optionally
	inform the transport about message
	boundaries and required properties per message (configurable
	order and reliability, or embedding
	a request not to delay the acknowledgement of a message). Wh
	enever the sending application
	specifies per-message properties that relax the notion of re
	liable in-order delivery of bytes,
	it must assume that the receiving application is 1) able to
	determine message boundaries, provided
	that messages are always kept intact, and 2) able to accept
	these relaxed per-message properties.
	Any signaling of such information to the peer is up to an ap
	plication-layer protocol
	and considered out of scope of this document.
	</t>
	<!-- <t>For the transport to operate on messages,
	it only needs be informed about them as they are handed
	over by a sending application; on the receiver side, giving an
	application a message only differs from
	giving it a bytestream in that a message-oriented receiver-side
	transport informs the application
	about message boundaries. When the application knows about thes
	e boundaries on its own, this
	information is unnecessary.</t>
	-->

	<t>For example, if an application requests to transfer fixed-siz
	e messages
	of 100 bytes with partial reliability, this needs the receiv
	ing application to be prepared to accept data
	in chunks of 100 bytes. If, then, some of these 100-byte mes
	sages are missing (e.g., if SCTP with
	Configurable Reliability is used), this is the expected appl
	ication behavior. With TCP, no messages
	would be missing, but this is also correct for the applicati
	on, and the possible retransmission delay is
	acceptable within the best-effort service model (see <xref t
	arget="RFC7305"/>, Section 3.5). Still, the receiving
	application would separate the byte stream into 100-byte chu
	nks.
	</t>

	<t>Note that this usage of messages does not require all message
	s to be equal in size.
	Many application protocols use some form of Type-Length-Valu
	e (TLV) encoding, e.g. by defining a header including
	length fields; another alternative is
	the use of byte stuffing methods such as COBS <xref target="
	COBS"/>. If an application needs
	message numbers, e.g. to restore the correct sequence of mes
	sages, these must also be encoded
	by the application itself, as the sequence number related tr
	ansport features of SCTP
	are not provided by the "minimum set" (in the interest of en
	abling usage of TCP).
	</t>

	</section>


	<section anchor="nostream" title="Stream Schedulers Without Streams"	<t>To support these TCP receiver semantics, we define an
	>	"Application-Framed Byte Stream" (AFra Byte Stream).
	<t>We have already stated that multi-streaming does not require	AFra Byte Streams allow senders to operate on messages while
	application-specific knowledge.	minimizing changes to the TCP socket API. In particular,
		nothing changes on the receiver side; data can be accepted
		via a normal TCP socket.
		</t>
		<t>In an AFra Byte Stream, the sending application can optionally
		inform the transport about message boundaries and required properties
		per message (configurable order and reliability, or embedding a
		request not to delay the acknowledgement of a message). Whenever the
		sending application specifies per-message properties that relax the
		notion of reliable in-order delivery of bytes, it must assume that the
		receiving application is 1) able to determine message boundaries,
		provided that messages are always kept intact, and 2) able to accept
		these relaxed per-message properties. Any signaling of such
		information to the peer is up to an application-layer protocol and
		considered out of scope of this document.
		</t>
		<t>For example, if an application requests to transfer
		fixed-size messages of 100 bytes with partial reliability,
		this needs the receiving application to be prepared to accept
		data in chunks of 100 bytes. Then, if some of these 100-byte
		messages are missing (e.g., if SCTP with Configurable
		Reliability is used), this is the expected application
		behavior. With TCP, no messages would be missing, but this is
		also correct for the application, and the possible
		retransmission delay is acceptable within the best-effort
		service model (see <xref target="RFC7305" sectionFormat="of"
		section="3.5"/>). Still, the receiving application would
		separate the byte stream into 100-byte chunks.
		</t>
		<t>Note that this usage of messages does not require all messages to
		be equal in size. Many application protocols use some form of
		Type-Length-Value (TLV) encoding, e.g., by defining a header including
		length fields; another alternative is the use of byte stuffing methods
		such as Consistent Overhead Byte Stuffing (COBS) <xref target="COBS" for
		mat="default"/>. If an application
		needs message numbers, e.g., to restore the correct sequence of
		messages, these must also be encoded by the application itself, as SCTP'
		s
		transport features that are related to the sequence number are not provi
		ded by
		the "minimum set" (in the interest of enabling usage of TCP).
		</t>
		</section>
		<section anchor="nostream" numbered="true" toc="default">
		<name>Stream Schedulers without Streams</name>
		<t>We have already stated that multi-streaming does not require applicat
		ion-specific knowledge.
	Potential benefits or disadvantages of, e.g., using two stre ams of an SCTP association	Potential benefits or disadvantages of, e.g., using two stre ams of an SCTP association
	versus using two separate SCTP associations or TCP connectio ns are related to knowledge	versus using two separate SCTP associations or TCP connectio ns are related to knowledge
	about the network and the particular transport protocol in u se, not the application.	about the network and the particular transport protocol in u se, not the application.
	However, the transport features "Choose a scheduler to opera te between streams of	However, the transport features "Choose a scheduler to opera te between streams of
	an association" and "Configure priority or weight for a sche duler" operate on streams.	an association" and "Configure priority or weight for a sche duler" operate on streams.
	Here, streams identify communication channels between which a scheduler operates, and	Here, streams identify communication channels between which a scheduler operates, and
	they can be assigned a priority. Moreover, the transport fea tures in the MAINTENANCE	they can be assigned a priority. Moreover, the transport fea tures in the MAINTENANCE

	category all operate on assocations in case of SCTP, i.e. th	category all operate on associations in case of SCTP, i.e.,
	ey apply to all streams in	they apply to all streams in
	that assocation.	that association.
	</t>	</t>
	<t>With only these semantics necessary to represent, the interfa	<t>With only these semantics necessary to represent, the interface to
	ce to a transport system becomes	a transport system becomes easier if we assume that connections may be
	easier if we assume that connections may be not only a trans	not only a transport protocol's connection or association, but could
	port protocol's connection or association,	also be a stream of an existing SCTP association, for example. We only
	but could also be a stream of an existing SCTP association,	need to allow for a way to define a possible grouping of
	for example. We only need to	connections. Then, all MAINTENANCE transport features can be said to
	allow for a way to define a possible grouping of connections	operate on connection groups, not connections, and a scheduler
	. Then, all	operates on the connections within a group.
	MAINTENANCE transport features can be said to operate	</t>
	on connection groups, not connections, and a scheduler opera	<t>To be compatible with multiple transport protocols and uniformly
	tes on	allow access to both transport connections and streams of a
	the connections within a group.	multi-streaming protocol, the semantics of opening and closing need to
	</t>	be the most restrictive subset of all of the underlying options. For
		example, TCP's support of half-closed connections can be seen as a
	<t>To be compatible with multiple transport protocols and unifor	feature on top of the more restrictive "ABORT"; this feature cannot be
	mly allow access to both transport connections	supported because not all protocols used by a transport system
	and streams of a multi-streaming protocol, the semantics of	(including streams of an association) support half-closed connections.
	opening and closing need to be	</t>
	the most restrictive subset of all of the underlying options	</section>
	. For example, TCP's support of half-closed connections	<section anchor="earlydata" numbered="true" toc="default">
	can be seen as a feature on top of the more restrictive "ABO	<name>Early Data Transmission</name>
	RT"; this feature cannot be supported	<t>There are two transport features related to transferring a message
	because not all protocols used by a transport system (includ	early: "Hand over a message to reliably transfer (possibly multiple
	ing streams of an association)	times) before connection establishment", which relates to TCP Fast
	support half-closed connections.	Open <xref target="RFC7413" format="default"/>, and "Hand over a
	</t>	message to reliably transfer during connection establishment", which
		relates to SCTP's ability to transfer data together with the
	</section>	COOKIE-Echo chunk. Also without TCP Fast Open, TCP can transfer data
		during the handshake, together with the SYN packet; however, the
	<section anchor="earlydata" title="Early Data Transmission">	receiver of this data may not hand it over to the application until
	<t>There are two transport features related to transferring a me	the handshake has completed. Also, different from TCP Fast Open, this
	ssage early: "Hand over a message to reliably transfer	data is not delimited as a message by TCP (thus, not visible as a
	(possibly multiple times) before connection establishment",	"message"). This functionality is commonly available in TCP and
	which relates to TCP Fast Open <xref target="RFC7413"/>, and	supported in several implementations, even though the TCP
	"Hand over a message to reliably transfer during connection	specification does not explain how to provide it to applications.
	establishment", which relates to SCTP's ability	</t>
	to transfer data together with the COOKIE-Echo chunk. Also w	<t>A transport system could differentiate between the cases of
	ithout TCP Fast Open, TCP can transfer data during	transmitting data "before" (possibly multiple times) or "during" the
	the handshake, together with the SYN packet -- however, the	handshake. Alternatively, it could also assume that data that are
	receiver of this data may not hand it over to the	handed over early will be transmitted as early as possible, and
	application until the handshake has completed. Also, differe	"before" the handshake would only be used for messages that are
	nt from TCP Fast Open, this data is	explicitly marked as "idempotent" (i.e., it would be acceptable to
	not delimited as a message by TCP (thus, not visible as a ``	transfer them multiple times).
	message'').	</t>
	This functionality is commonly available in TCP and supporte	<t>The amount of data that can successfully be transmitted before or
	d	during the handshake depends on various factors: the transport
	in several implementations, even though the TCP specificatio	protocol, the use of header options, the choice of IPv4 and IPv6, and
	n does not explain how to provide it to applications.	the Path MTU. A transport system should therefore allow a sending
	</t>	application to query the maximum amount of data it can possibly
	<t>A transport system could differentiate between the cases of t	transmit before (or, if exposed, during) connection establishment.
	ransmitting data "before" (possibly multiple times) or	</t>
	"during" the handshake. Alternatively, it could also assume	</section>
	that data that are handed over early will be transmitted	<section anchor="rundry" numbered="true" toc="default">
	as early as possible, and "before" the handshake would only	<name>Sender Running Dry</name>
	be used for messages that are explicitly marked as "idempotent" (i.e., it would	<t>The transport feature "Notification that the stack has no more user
	be acceptable to transfer them multiple times).	data to send" relates to SCTP's "SENDER DRY" notification. Such
	</t>	notifications can, in principle, be used to avoid having an
	<t>The amount of data that can successfully be transmitted befor	unnecessarily large send buffer, yet ensure that the transport sender
	e or during the handshake depends on various factors:	always has data available when it has an opportunity to transmit it.
	the transport protocol, the use of header options, the choic	This has been found to be very beneficial for some applications <xref
	e of IPv4 and IPv6 and the Path MTU. A transport system	target="WWDC2015" format="default"/>. However, "SENDER DRY" truly
	should therefore allow a sending application to query the ma	means that the entire send buffer (including both unsent and
	ximum amount of data it can possibly transmit before (or,	unacknowledged data) has emptied, i.e., when it notifies the sender,
	if exposed, during) connection establishment.	it is already too late; the transport protocol already missed an
	</t>	opportunity to send data. Some modern TCP implementations now include
	</section>	the unspecified "TCP_NOTSENT_LOWAT" socket option that was proposed in
		<xref target="WWDC2015" format="default"/>, which limits the amount of
	<section anchor="rundry" title="Sender Running Dry">	unsent data that TCP can keep in the socket buffer; this allows
	<t>The transport feature "Notification that the stack has no mor	specifying at which buffer filling level the socket becomes writable,
	e user data to send" relates to SCTP's "SENDER DRY"	rather than waiting for the buffer to run empty.
	notification. Such notifications can, in principle, be used	</t>
	to avoid having an unnecessarily large send buffer,	<t>SCTP allows configuring the sender-side buffer too; the
	yet ensure that the transport sender always has data availab	automatable Transport Feature "Configure send buffer size" provides
	le when it has an opportunity to transmit it.	this functionality, but only for the complete buffer, which includes
	This has been found to be very beneficial for some applicati	both unsent and unacknowledged data. SCTP does not allow to control
	ons <xref target="WWDC2015"/>. However, "SENDER DRY"	these two sizes separately. It therefore makes sense for a transport
	truly means that the entire send buffer (including both unse	system to allow for uniform access to "TCP_NOTSENT_LOWAT" as well as
	nt and unacknowledged data) has	the "SENDER DRY" notification.
	emptied -- i.e., when it notifies the sender, it is already	</t>
	too late, the	</section>
	transport protocol already missed an opportunity to send dat	<section anchor="profile" numbered="true" toc="default">
	a. Some modern TCP implementations now include	<name>Capacity Profile</name>
	the unspecified "TCP_NOTSENT_LOWAT" socket option that was p	<t>The transport features:
	roposed in <xref target="WWDC2015"/>, which limits the amount of	</t>
	unsent data that TCP can keep in the socket buffer; this all	<ul spacing="compact">
	ows to specify at which buffer filling level the socket	<li>Disable Nagle algorithm</li>
	becomes writable, rather than waiting for the buffer to run	<li>Enable and configure a "Low Extra Delay Background Transfer"</li>
	empty.	<li>Specify DSCP field</li>
	</t>	</ul>
	<t>SCTP allows to configure the sender-side buffer too: the auto	<t>
	matable Transport Feature "Configure send buffer size"	All relate to a QoS-like application need such as "low
	provides this functionality, but only for the complete buffe	latency" or "scavenger". In the interest of flexibility of
	r, which includes both unsent and unacknowledged	a transport system, they could therefore be offered in a
	data. SCTP does not allow to control these two sizes separat	uniform, more abstract way, where a transport system
	ely. It therefore makes sense for	could, e.g., decide by itself how to use combinations of
	a transport system to allow for uniform access to "TCP_NOTSE	LEDBAT-like congestion control and certain DSCP values,
	NT_LOWAT" as well as the "SENDER DRY" notification.	and an application would only specify a general "capacity
	</t>	profile" (a description of how it wants to use the
	</section>	available capacity). A need for "lowest possible latency
		at the expense of overhead" could then translate into
	<section anchor="profile" title="Capacity Profile">	automatically disabling the Nagle algorithm.
	<t>The transport features:	</t>
	<list style="symbols">	<t>In some cases, the Nagle algorithm is best controlled directly by
	<t>Disable Nagle algorithm</t>	the application because it is not only related to a general profile
	<t>Enable and configure a "Low Extra Delay Background Tr	but also to knowledge about the size of future messages. For
	ansfer"</t>	fine-grain control over Nagle-like functionality, the "Request not to
	<t>Specify DSCP field</t>	bundle messages" is available.
	</list>	</t>
	all relate to a QoS-like application need such as "low laten	</section>
	cy" or "scavenger". In the interest	<section anchor="security" numbered="true" toc="default">
	of flexibility of a transport system, they could therefore b	<name>Security</name>
	e offered in a uniform, more abstract way,	<t>Both TCP and SCTP offer authentication. TCP authenticates complete
	where a transport system could e.g. decide by itself how to	segments. SCTP allows configuring which of SCTP's chunk types must
	use combinations of LEDBAT-like congestion control	always be authenticated; if this is exposed as such, it creates an
	and certain DSCP values, and an application would only speci	undesirable dependency on the transport protocol. For compatibility
	fy a general "capacity profile" (a description	with TCP, a transport system should only allow to configure complete
	of how it wants to use the available capacity).	transport layer packets, including headers, IP pseudo-header (if any)
	A need for "lowest possible latency at the expense of overhe	and payload.
	ad" could then translate into automatically	</t>
	disabling the Nagle algorithm.	<t>Security is discussed in a separate document <xref target="RFC8922"
	</t>	format="default"/>. The minimal set presented in the present document
	<t>In some cases, the Nagle algorithm is best controlled directl	excludes all security-related transport features from <xref
	y by the application because it is not	target="super" format="default"/>: "Configure authentication", "Change
	only related to a general profile but also to knowledge abou	authentication parameters", "Obtain authentication information", and
	t the size of future messages.	"Set Cookie life value", as well as "Specifying a key id to be used to
	For fine-grain control over Nagle-like functionality, the "R	authenticate a message". It also excludes security transport features
	equest not to bundle messages"	not listed in <xref target="super" format="default"/>, including
	is available.	content privacy to in-path devices.
	</t>	</t>
	</section>	</section>
		<section anchor="packetsize" numbered="true" toc="default">
	<section anchor="security" title="Security">	<name>Packet Size</name>
	<t>Both TCP and SCTP offer authentication. TCP authenticates com	<t>UDP(-Lite) has a transport feature called "Specify DF field". This
	plete segments.	yields an error message in the case of sending a message that exceeds th
	SCTP allows to configure which of SCTP's chunk types	e
	must always be authenticated -- if this is exposed as such,	Path MTU, which is necessary for a UDP-based application to be able to
	it creates an undesirable dependency	implement Path MTU Discovery (a function that UDP-based applications
	on the transport protocol. For compatibility with TCP, a tra	must do by themselves). The "Get max. transport-message size that may
	nsport system should only allow to configure	be sent using a non-fragmented IP packet from the configured
	complete transport layer packets, including headers, IP pseu	interface" transport feature yields an upper limit for the Path MTU
	do-header (if any) and payload.	(minus headers) and can therefore help to implement Path MTU Discovery
	</t>	more efficiently.</t>
	<t>Security is discussed in a separate document <xref target="I-
	D.ietf-taps-transport-security"/>.
	The minimal set presented in the present document excludes a
	ll security related transport
	features from <xref target="super"/>: "Configure authenticat
	ion",
	"Change authentication parameters", "Obtain authentication i
	nformation"
	and "Set Cookie life value" as well as "Specifying a key id
	to be used to authenticate a message".
	It also excludes security transport features
	not listed in <xref target="super"/>, including content priv
	acy to in-path devices.
	</t>
	</section>


	<section anchor="packetsize" title="Packet Size">
	<t>UDP(-Lite) has a transport feature called "Specify DF field".
	This yields an error message in case
	of sending a message that exceeds the Path MTU, which is nec
	essary for a UDP-based application to
	be able to implement Path MTU Discovery (a function that UDP
	-based applications must do by themselves).
	The "Get max. transport-message size that may be sent using
	a non-fragmented IP packet from the
	configured interface" transport feature yields an upper limi
	t for the Path MTU (minus headers) and
	can therefore help to implement Path MTU Discovery more effi
	ciently.</t>
	<!-- <t>This also relates to the fact that th
	e choice of path is automatable: if a TAPS system can switch
	a path at any time, unknown to an application, yet the applicat
	ion intends to do Path MTU Discovery,
	this could yield a very inefficient behavior. Thus, a TAPS syst
	em should probably inform the
	application about path changes when the application
	requests to disallow fragmentation with the "Specify DF field"
	feature.
	</t>
	-->
	</section>	</section>

		</section>


	</section>	<section anchor="minset" numbered="true" toc="default">
		<name>The Minimal Set of Transport Features</name>
	<section anchor="minset" title="The Minimal Set of Transport Features">	<t> Based on the categorization, reduction, and discussion in <xref
		target="deriving" format="default"/>, this section describes a minimal
	<t> Based on the categorization, reduction, and discussion in <xref	set of transport features that end systems should offer. Any
	target="deriving"/>, this section	configuration based on the described minimum set of transport feature can
	describes a minimal set of transport features that end systems s	always be realized over TCP but also gives the transport system
	hould offer.	flexibility to choose another transport if implemented. In the text of
	Any configuration based the described minimum set of	this section, "not UDP" is used to indicate elements of the system that
	transport feature can always be realized over TCP but also gives	cannot be implemented over UDP. Conversely, all elements of the system
	the transport	that are not marked with "not UDP" can also be implemented over UDP.
	system flexibility to choose another transport if implemented.	</t>
	In the text of this section, "not UDP" is used to indicate eleme	<t> The arguments laid out in <xref target="Discussion"
	nts of the	format="default"/> ("discussion") were used to make the final
	system that cannot be implemented over UDP. Conversely, all elem	representation of the minimal set as short, simple, and general as
	ents of the system that are	possible. There may be situations where these arguments do not apply,
	not marked with "not UDP" can also be implemented over UDP.	e.g., implementers may have specific reasons to expose multi-streaming
	<!-- To implement a transport	as a visible functionality to applications, or the restrictive
	system that can also work over UDP, these marked transport featu	open/close semantics may be problematic under some circumstances. In
	res should	such cases, the representation in <xref target="Reduction"
	be excluded.-->	format="default"/> ("reduction") should be considered.
		</t>
	<!--We categorize them as before, but instead of connections the	<t> As in <xref target="deriving" format="default"/>, <xref
	y operate on NEAT flows.	target="Reduction" format="default"/>, and <xref target="RFC8303"
	Since the "Errors" category only contains errors related to send	format="default"/>, we categorize the minimal set of transport features
	ing a particular message and there	as 1) CONNECTION related (ESTABLISHMENT, AVAILABILITY, MAINTENANCE,
	is only one transport feature left in this category, this catego	TERMINATION) and 2) DATA Transfer related (Sending Data, Receiving Data,
	ry was removed and	Errors). Here, the focus is on connections that the transport system
	the only transport feature in it was moved to the "Sending data"	offers as an abstraction to the application, as opposed to connections
	category. -->	of transport protocols that the transport system uses.
	</t>

	<t> The arguments laid out in <xref target="Discussion" /> ("discuss
	ion") were used to make the final representation
	of the minimal set as short, simple and general as possible. The
	re may be
	situations where these arguments do not apply -- e.g., implement
	ers may have specific reasons
	to expose multi-streaming as a visible functionality
	to applications, or the restrictive open / close semantics may b
	e problematic under some circumstances.
	In such cases, the representation in <xref target="Reduction" />
	("reduction") should be considered.
	</t>

	<t> As in <xref target="deriving"/>, <xref target="Reduction"/> and
	<xref target="RFC8303"></xref>, we
	categorize the minimal set of transport
	features as 1) CONNECTION related (ESTABLISHMENT, AVAILABILITY,
	MAINTENANCE, TERMINATION) and
	2) DATA Transfer related (Sending Data, Receiving Data, Errors).
	Here, the focus is on
	connections that the transport system offers as an abstraction t
	o the application, as opposed
	to connections of
	transport protocols that the transport system uses.
	<!--We categorize them as before, but instead of connections the
	y operate on NEAT flows.
	Since the "Errors" category only contains errors related to send
	ing a particular message and there
	is only one transport feature left in this category, this catego
	ry was removed and
	the only transport feature in it was moved to the "Sending data"
	category. -->
	</t>

	<section anchor="minset-init" title="ESTABLISHMENT, AVAILABILITY and
	TERMINATION">

	<t>A connection must first be "created" to allow for some initia
	l configuration
	to be carried out before the transport system can actively o
	r passively establish communication
	with a remote end system. As a configuration of the newly cr
	eated connection, an application
	can choose to disallow usage of MPTCP. Furthermore, all conf
	iguration
	parameters in <xref target="minset-groupconfig"/>
	can be used initially, although some of them may only take e
	ffect
	when a connection has been established with a chosen transpo
	rt protocol. Configuring a
	connection early helps a transport system
	make the right decisions. For example, grouping information
	can influence the
	transport system to implement a connection as a stream of a
	multi-streaming protocol's
	existing association or not.
	</t>
	<t>
	For ungrouped connections, early configuration is necessary
	because it
	allows the transport system to
	know which protocols it should try to use.
	In particular, a transport system that only makes a one-time
	choice for a particular protocol must know early about stric
	t
	requirements that must be kept, or it can end up in a deadlo
	ck situation (e.g.,
	having chosen UDP and later be asked to support reliable tra
	nsfer). As an example description of how to correctly
	handle these cases,
	we provide the following decision tree (this is derived from
	<xref target="conn-reduced"/>
	excluding authentication, as explained in <xref target="Secu
	rity"/>):
	<figure align="left">
	<!--<preamble>Preamble</preamble>-->
	<artwork align="left">
	<![CDATA[
	- Will it ever be necessary to offer any of the following?
	* Reliably transfer data
	* Notify the peer of closing/aborting
	* Preserve data ordering

	Yes: SCTP or TCP can be used.
	- Is any of the following useful to the application?
	* Choosing a scheduler to operate between connections
	in a group, with the possibility to configure a priority
	or weight per connection
	* Configurable message reliability
	* Unordered message delivery
	* Request not to delay the acknowledgement (SACK) of a message

	Yes: SCTP is preferred.
	No:
	- Is any of the following useful to the application?
	* Hand over a message to reliably transfer (possibly
	multiple times) before connection establishment
	* Suggest timeout to the peer
	* Notification of Excessive Retransmissions (early
	warning below abortion threshold)
	* Notification of ICMP error message arrival

	Yes: TCP is preferred.
	No: SCTP and TCP are equally preferable.


	No: all protocols can be used.	</t>
	- Is any of the following useful to the application?
	* Specify checksum coverage used by the sender
	* Specify minimum checksum coverage required by receiver


	Yes: UDP-Lite is preferred.	<section anchor="minset-init" numbered="true" toc="default">
	No: UDP is preferred.	<name>ESTABLISHMENT, AVAILABILITY, and TERMINATION</name>
	]]>	<t>A connection must first be "created" to allow for some initial
	</artwork>	configuration to be carried out before the transport system can
	<!--<postamble>Figure 1: RTO restart example</postamble>	actively or passively establish communication with a remote end
	-->	system. As a configuration of the newly created connection, an
	</figure>	application can choose to disallow usage of MPTCP. Furthermore, all
	</t>	configuration parameters in <xref target="minset-groupconfig"
	<t>Note that this decision tree is not optimal for all cases.	format="default"/> can be used initially, although some of them may
	For example, if an application wants to use "Specify checksu	only take effect when a connection has been established with a chosen
	m coverage used by the sender",	transport protocol. Configuring a connection early helps a transport
	which is only offered by UDP-Lite, and "Configure priority o	system make the right decisions. For example, grouping information can
	r weight for a scheduler", which	influence whether or not the transport system implements a connection as
	is only offered by SCTP, the above decision tree will always	a stream
	choose UDP-Lite, making it	of a multi-streaming protocol's existing association.
	impossible to use SCTP's schedulers with priorities between	</t>
	grouped connections. Also,	<t>
	several other factors may influence the decisions for or aga	For ungrouped connections, early configuration is
	inst a protocol -- e.g.	necessary because it allows the transport system to know
	penetration rates, the ability to work through NATs, etc.	which protocols it should try to use. In particular, a
	We caution implementers to be	transport system that only makes a one-time choice for a
	aware of the full set of trade-offs, for which we recommend	particular protocol must know early about strict
	consulting the list	requirements that must be kept, or it can end up in a
	in <xref target="conn-reduced"/> when deciding how to initia	deadlock situation (e.g., having chosen UDP and later be
	lize a connection.	asked to support reliable transfer). As an example
	</t>	description of how to correctly handle these cases, we
		provide the following decision tree (this is derived from
		<xref target="conn-reduced" format="default"/> excluding
		authentication, as explained in <xref target="Security"
		format="default"/>):


	<t>To summarize, the following parameters serve as input for the	</t>
	transport system to help it
	choose and configure a suitable protocol:</t>
	<t>
	<list style="symbols">
	<t>Reliability: a boolean that should be set to true whe
	n any of the following will be useful to the
	application: reliably transfer data; notify the peer
	of closing/aborting; preserve data ordering.</t>
	<t>Checksum coverage: a boolean to specify whether it wi
	ll be useful to the application
	to specify checksum coverage when sending or receivi
	ng.</t>
	<t>Configure message priority: a boolean that should be
	set to true when any of the following per-message
	configuration or prioritization mechanisms will be u
	seful to the application: choosing a scheduler to
	operate between grouped connections, with the possib
	ility to configure a priority or weight per connection;
	configurable message reliability; unordered message
	delivery; requesting not to delay the acknowledgement
	(SACK) of a message.</t>
	<t>Early message timeout notifications: a boolean that s
	hould be set to true when any of the following
	will be useful to the application: hand over a messa
	ge to reliably transfer (possibly multiple times)
	before connection establishment; suggest timeout to
	the peer; notification of excessive retransmissions
	(early warning below abortion threshold); notificati
	on of ICMP error message arrival.</t>
	</list>
	</t>


	<t>Once a connection is created, it can be queried for the maxim	<artwork>
	um amount of data that	+----------------------------------------------------------+
	an application can possibly expect to have reliably transmit	\| Will it ever be necessary to offer any of the following? \|
	ted before or during transport	\| * Reliably transfer data \|
	connection establishment	\| * Notify the peer of closing/aborting \|
	(with zero being a possible answer) (see <xref target="mins	\| * Preserve data ordering \|
	et-maintenance-grouped"/>).	+----------------------------------------------------------+
	An application can also give the connection a message for re	\| \|
	liable transmission before or during connection	\|Yes \|No
	establishment (not UDP); the transport system will then try	\| (SCTP or TCP) \| (All protocols
	to transmit it as early as possible. An application	\| can be used.) \| can be used.)
	can facilitate sending a message particularly early by marki	V V
	ng it as "idempotent" (see <xref target="minset-datatrans-sending"/>);	+--------------------------------------+ +-----------------------------+
	in this case,	\| Is any of the following useful to \| \| Is any of the following \|
	the receiving application must be prepared to potentially re	\| the application? \| \| useful to the application? \|
	ceive multiple	\| * Choosing a scheduler to operate \| \| * Specify checksum coverage \|
	copies of the message (because idempotent messages are relia	\| between connections in a group, \| \| used by the sender \|
	bly transferred, asking for idempotence	\| with the possibility to configure \| \| * Specify minimum checksum \|
	is not necessary for systems that support UDP).	\| a priority or weight per connection\| \| coverage required by the \|
	</t>	\| * Configurable message reliability \| \| receiver \|
	<t>	\| * Unordered message delivery \| +-----------------------------+
	After creation, a transport system can actively establish co	\| * Request not to delay the \| \| \|
	mmunication with a peer, or it can	\| acknowledgement (SACK) of a message\| \|Yes \|No
	passively listen for incoming connection requests. Note that	+--------------------------------------+ \| \|
	active establishment may or may not	\| \| \| \|
	trigger a notification on the listening side. It is possible	\|Yes \|No \| \|
	that the first notification on the listening side is the arr	V \| V V
	ival of the first data that	SCTP is \| UDP-Lite is UDP is
	the active side sends (a receiver-side transport system coul	preferred. \| preferred. preferred.
	d handle this by continuing to block	V
	a "Listen" call, immediately followed by issuing "Receive",	+------------------------------------------------------+
	for example; callback-based	\| Is any of the following useful to the application? \|
	implementations could simply skip the equivalent of "Listen"	\| * Hand over a message to reliably transfer (possibly \|
	). This also means that	\| multiple times) before connection establishment \|
	the active opening side is assumed to be the first side send	\| * Suggest timeout to the peer \|
	ing data.	\| * Notification of Excessive Retransmissions (early \|
	</t>	\| warning below abortion threshold) \|
		\| * Notification of ICMP error message arrival \|
		+------------------------------------------------------+
		\| \|
		\|Yes \|No
		V V
		TCP is preferred. SCTP and TCP
		are equally preferable.
		</artwork>


	<t>A transport system can actively close a connection, i.e. term	<t>Note that this decision tree is not optimal for all cases. For
	inate it after reliably delivering all	example, if an application wants to use "Specify checksum coverage
	remaining data to the peer (if reliable data delivery was re	used by the sender", which is only offered by UDP-Lite, and "Configure
	quested earlier (not UDP)), in which case the	priority or weight for a scheduler", which is only offered by SCTP,
	peer is notified that the connection is closed. Alternativel	the above decision tree will always choose UDP-Lite, making it
	y, a connection	impossible to use SCTP's schedulers with priorities between grouped
	can be aborted without delivering outstanding data to the pe	connections. Also, several other factors may influence the decisions
	er. In case reliable or	for or against a protocol, e.g., penetration rates, the ability to
	partially reliable data delivery was requested earlier (not	work through NATs, etc. We caution implementers to be aware of the
	UDP), the peer is notified	full set of trade-offs, for which we recommend consulting the list in
	that the connection is aborted.	<xref target="conn-reduced" format="default"/> when deciding how to
	A timeout can be configured to abort	initialize a connection.
	a connection when data could not be delivered for too long (	</t>
	not UDP); however, timeout-based abortion does not	<t>To summarize, the following parameters serve as input for the
	notify the peer application that the connection has been abo	transport system to help it choose and configure a suitable
	rted. Because half-closed connections	protocol:</t>
	are not supported, when a host implementing a transport syst
	em receives a notification that the
	peer is closing or aborting
	the connection (not UDP), its peer may not be able to read o
	utstanding data. This means
	that unacknowledged data residing in a transport system's se
	nd buffer may have to be dropped from
	that buffer upon arrival of a "close" or "abort" notificatio
	n from the peer.
	</t>


	</section>	<dl>
		<dt>Reliability:
		</dt>
		<dd>a boolean that should be set to true when any of the following will be
		useful to the application: reliably transfer data; notify the peer of
		closing/aborting; or preserve data ordering.
		</dd>
		<dt>Checksum coverage:
		</dt>
		<dd>a boolean to specify whether it will be useful to the application to
		specify checksum coverage when sending or receiving.
		</dd>


	<section anchor="minset-groupconfig" title="MAINTENANCE">	<dt>Configure message priority:
		</dt>
		<dd>a boolean that should be set to true when any of the following
		per-message configuration or prioritization mechanisms will be useful to the
		application: choosing a scheduler to operate between grouped connections, with
		the possibility to configure a priority or weight per connection; configurable
		message reliability; unordered message delivery; or requesting not to delay the
		acknowledgement (SACK) of a message.
		</dd>
		<dt>Early message timeout notifications:
		</dt>
		<dd>a boolean that should be set to true when any of the following will be
		useful to the application: hand over a message to reliably transfer (possibly
		multiple times) before connection establishment; suggest timeout to the peer;
		notification of excessive retransmissions (early warning below abortion
		threshold); or notification of ICMP error message arrival.
		</dd>
		</dl>


	<t>A transport system must offer means to group connections, but	<t>Once a connection is created, it can be queried for the maximum
	it cannot	amount of data that an application can possibly expect to have
	guarantee truly grouping them using the transport protocols	reliably transmitted before or during transport connection
	that it uses (e.g., it cannot	establishment (with zero being a possible answer) (see <xref
	be guaranteed that connections	target="minset-maintenance-grouped" format="default"/>). An
	become multiplexed as streams on a single SCTP association w	application can also give the connection a message for reliable
	hen SCTP may not be available).	transmission before or during connection establishment (not UDP); the
	The transport system must therefore ensure that group- versu	transport system will then try to transmit it as early as possible. An
	s non-group-configurations	application can facilitate sending a message particularly early by
	are handled correctly in some way (e.g., by applying the con	marking it as "idempotent" (see <xref
	figuration to all grouped	target="minset-datatrans-sending" format="default"/>); in this case,
	connections even when they are not multiplexed, or informing	the receiving application must be prepared to potentially receive
	the application about	multiple copies of the message (because idempotent messages are
	grouping success or failure).	reliably transferred, asking for idempotence is not necessary for
	</t>	systems that support UDP).
		</t>
		<t>
		After creation, a transport system can actively establish
		communication with a peer, or it can passively listen for
		incoming connection requests. Note that active
		establishment may or may not trigger a notification on the
		listening side. It is possible that the first notification
		on the listening side is the arrival of the first data
		that the active side sends (a receiver-side transport
		system could handle this by continuing to block a "Listen"
		call, immediately followed, for example, by issuing
		"Receive"; callback-based implementations could simply
		skip the equivalent of "Listen"). This also means that the
		active opening side is assumed to be the first side
		sending data.
		</t>
		<t>A transport system can actively close a connection, i.e., terminate
		it after reliably delivering all remaining data to the peer (if
		reliable data delivery was requested earlier (not UDP)), in which case
		the peer is notified that the connection is closed. Alternatively, a
		connection can be aborted without delivering outstanding data to the
		peer. In case reliable or partially reliable data delivery was
		requested earlier (not UDP), the peer is notified that the connection
		is aborted. A timeout can be configured to abort a connection when
		data could not be delivered for too long (not UDP); however,
		timeout-based abortion does not notify the peer application that the
		connection has been aborted. Because half-closed connections are not
		supported, when a host implementing a transport system receives a
		notification that the peer is closing or aborting the connection (not
		UDP), its peer may not be able to read outstanding data. This means
		that unacknowledged data residing in a transport system's send buffer
		may have to be dropped from that buffer upon arrival of a "close" or
		"abort" notification from the peer.
		</t>
		</section>


	<t>As a general rule, any configuration described below should b	<section anchor="minset-groupconfig" numbered="true" toc="default">
	e carried	<name>MAINTENANCE</name>
		<t>A transport system must offer means to group connections, but it
		cannot guarantee truly grouping them using the transport protocols
		that it uses (e.g., it cannot be guaranteed that connections become
		multiplexed as streams on a single SCTP association when SCTP may not
		be available). The transport system must therefore ensure that group-
		versus non-group-configurations are handled correctly in some way
		(e.g., by applying the configuration to all grouped connections even
		when they are not multiplexed, or informing the application about
		grouping success or failure).
		</t>
		<t>As a general rule, any configuration described below should be carrie
		d
	out as early as possible to aid the transport system's decis ion making.	out as early as possible to aid the transport system's decis ion making.

	</t>	</t>

	<section anchor="minset-maintenance-grouped" title="Connection g
	roups">

	<t>The following
	transport features and notifications (some directly from
	<xref target="Reduction"/>,
	some new or changed, based on the discussion in <xref ta
	rget="Discussion"/>)
	automatically apply to all grouped connections:
	</t>

	<t>(not UDP) Configure a timeout: this can be done with the
	following parameters:</t>
	<t><list style="symbols">
	<t>A timeout value for aborting connections, in seco
	nds</t>
	<t>A timeout value to be suggested to the peer (if p
	ossible), in seconds</t>
	<t>The number of retransmissions after which the app
	lication should be notifed
	of "Excessive Retransmissions"</t>
	</list>
	</t>

	<t>Configure urgency: this can be done with the following pa
	rameters:</t>
	<t><list style="symbols">
	<t>A number to identify the type of scheduler that s
	hould be used to operate
	between connections in the group (no guarantees
	given). Schedulers are
	defined in <xref target="RFC8260"/>.</t>
	<t>A "capacity profile" number to identify how an ap
	plication wants to use its available capacity.
	Choices can be "lowest possible latency at the e
	xpense of
	overhead" (which would disable any Nagle-like al
	gorithm),
	"scavenger", or values that help determine the D
	SCP value
	for a connection (e.g. similar to table 1 in <x
	ref target="I-D.ietf-tsvwg-rtcweb-qos"/>).</t>
	<t>A buffer limit (in bytes); when the sender has le
	ss than the provided limit of
	bytes in the buffer, the application may be noti
	fied. Notifications are not guaranteed,
	and it is optional for a transport system to sup
	port buffer limit values greater than 0.
	Note that this limit and its notification should
	operate across the buffers of the whole transport system, i.e.
	also any potential buffers that the transport sy
	stem itself may use on top of the transport's send buffer.</t>
	</list>
	</t>

	<t>Following <xref target="packetsize"/>, these properties c
	an be queried:</t>
	<t><list style="symbols">
	<t>The maximum message size that may be sent without
	fragmentation via the configured interface. This is optional for a transport sy
	stem to offer, and may return an error ("not available"). It can aid application
	s implementing Path MTU Discovery.</t>
	<t>The maximum transport message size that can be se
	nt, in bytes. Irrespective of fragmentation, there is a size limit for the
	messages that can be handed over to SCTP or UDP(
	-Lite); because the service provided by
	a transport system is independent
	of the transport protocol, it must allow an appl
	ication to query this value -- the maximum size
	of a message in an Application-Framed-Bytestream
	(see <xref target="sendmsg"/>). This may
	also return an error when data
	is not delimited ("not available").</t>
	<t>The maximum transport message size that can be re
	ceived from the configured interface, in bytes (or "not available").</t>
	<t>The maximum amount of data that can possibly be s
	ent before or
	during connection establishment, in bytes.</t>
	</list>
	<vspace blankLines="1"/>
	</t>

	<t>In addition to the already mentioned closing / aborting n
	otifications and possible send
	errors, the following notifications can occur:</t>
	<t><list style="symbols">
	<t>Excessive Retransmissions: the configured (or a d
	efault) number of retransmissions
	has been reached, yielding this early warning be
	low an abortion threshold.</t>
	<t>ICMP Arrival (parameter: ICMP message): an ICMP p
	acket carrying the conveyed ICMP message
	has arrived.</t>
	<t>ECN Arrival (parameter: ECN value): a packet carr
	ying the conveyed ECN value has arrived.
	This can be useful for applications implementing
	congestion control.</t>
	<t>Timeout (parameter: s seconds): data could not be
	delivered for s seconds.</t>
	<t>Drain: the send buffer has either drained below t
	he configured buffer limit or
	it has become completely empty. This is a generi
	c notification that tries to enable uniform access
	to "TCP_NOTSENT_LOWAT" as well as the "SENDER DR
	Y" notification (as discussed in <xref target="rundry"/> --
	SCTP's "SENDER DRY" is a special case where the
	threshold (for unsent data) is 0 and there is also no more
	unacknowledged data in the send buffer).</t>
	</list>
	</t>

	</section>

	<section anchor="minset-maintenance-individual" title="Individua
	l connections">

	<t>Configure priority or weight for a scheduler, as describe
	d in <xref target="RFC8260"/>.</t>

	<t>Configure checksum usage: this can be done with the follo
	wing parameters, but there is no
	guarantee that any checksum limitations will indeed be e
	nforced (the default behavior
	is "full coverage, checksum enabled"):</t>
	<t><list style="symbols">
	<t>A boolean to enable / disable usage of a checksum
	when sending</t>
	<t>The desired coverage (in bytes) of the checksum u
	sed when sending</t>
	<t>A boolean to enable / disable requiring a checksu
	m when receiving</t>
	<t>The required minimum coverage (in bytes) of the c
	hecksum when receiving</t>
	</list>
	</t>
	</section>

	</section>

	<section anchor="minset-datatrans" title="DATA Transfer">

	<section anchor="minset-datatrans-sending" title="Sending Data">


	<t>When sending a message, no guarantees are given about the pre	<section anchor="minset-maintenance-grouped" numbered="true" toc="defaul
	servation of message	t">
	boundaries to the peer; if message boundaries are needed, th	<name>Connection Groups</name>
	e receiving application at the	<t>The following transport features and notifications (some directly
	peer must know about them beforehand (or the transport syste	from <xref target="Reduction" format="default"/>; some new or
	m cannot use TCP). Note	changed, based on the discussion in <xref target="Discussion"
	that an application should already be able to hand over data	format="default"/>) automatically apply to all grouped connections:
	before the transport system	</t>
	establishes a connection with a chosen transport protocol. R	<t>Configure a timeout (not UDP)<br/>This can be done with the followi
	egarding the message	ng parameters:</t>
	that is being handed over, the following parameters can be u	<ul>
	sed:</t>	<li>A timeout value for aborting connections, in seconds.</li>
	<t><list style="symbols">	<li>A timeout value to be suggested to the peer (if possible), in se
	<t>Reliability: this parameter is used to convey a choic	conds.</li>
	e of: fully reliable with congestion control (not UDP),	<li>The number of retransmissions after which the application
	unreliable without congestion control, unreliable wi	should be notified of "Excessive Retransmissions".</li>
	th congestion control (not UDP),	</ul>
	partially reliable with congestion control (see <xre	<t>Configure urgency<br/>This can be done with the following parameter
	f target="RFC3758"/> and <xref target="RFC7496"/> for details	s:</t>
	on how to specify partial reliability) (not UDP). Th	<ul>
	e latter two choices are optional for a transport	<li>A number to identify the type of scheduler that should be used
	system to offer and may result in full reliability.	to operate between connections in the group (no guarantees
	Note that applications sending	given). Schedulers are defined in <xref target="RFC8260"
	unreliable data without congestion control should themse	format="default"/>.</li>
	lves perform congestion control
	in accordance with <xref target="RFC8085"/>.</t>
	<t>(not UDP) Ordered: this boolean parameter lets an app
	lication choose between ordered
	message delivery (true) and possibly unordered, pote
	ntially faster message delivery
	(false).</t>
	<t>Bundle: a boolean that expresses a preference for all
	owing to bundle messages (true) or not (false).
	No guarantees are given.</t>
	<t>DelAck: a boolean that, if false, lets an application
	request that the peer would not
	delay the acknowledgement for this message.</t>
	<t>Fragment: a boolean that expresses a preference for a
	llowing to fragment messages (true) or not (false), at the IP level. No guarante
	es are given.</t>
	<t>(not UDP) Idempotent: a boolean that expresses whethe
	r a message is
	idempotent (true) or not (false). Idempotent message
	s may arrive multiple
	times at the receiver (but they will arrive at least
	once). When data is idempotent
	it can be used by the receiver immediately on a
	connection establishment attempt. Thus, if data is h
	anded over before the transport system
	establishes a connection with a chosen transport pro
	tocol,
	stating that a message is idempotent facilitates tra
	nsmitting it to the peer application
	particularly early.
	</t>
	</list>
	</t>


	<t>An application can be notified of a failure to send a specifi	<li>A "capacity profile" number to identify how an application
	c message. There is no	wants to use its available capacity. Choices can be "lowest
	guarantee of such notifications, i.e. send failures can also	possible latency at the expense of overhead" (which would disable
	silently occur.</t>	any Nagle-like algorithm), "scavenger", or values that help
		determine the DSCP value for a connection.</li>
		<li>A buffer limit (in bytes); when the sender has less than the
		provided limit of bytes in the buffer, the application may be
		notified. Notifications are not guaranteed, and it is optional for
		a transport system to support buffer limit values greater than 0.
		Note that this limit and its notification should operate across
		the buffers of the whole transport system, i.e., also any
		potential buffers that the transport system itself may use on top
		of the transport's send buffer.</li>
		</ul>
		<t>Following <xref target="packetsize" format="default"/>, these prope
		rties can be queried:</t>
		<ul>
		<li>The maximum message size that may be sent without
		fragmentation via the configured interface. This is optional for a
		transport system to offer and may return an error ("not
		available"). It can aid applications implementing Path MTU
		Discovery.</li>
		<li>The maximum transport message size that can be sent, in
		bytes. Irrespective of fragmentation, there is a size limit for
		the messages that can be handed over to SCTP or UDP(-Lite);
		because the service provided by a transport system is independent
		of the transport protocol, it must allow an application to query
		this value: the maximum size of a message in an
		Application-Framed Byte Stream (see <xref target="sendmsg"
		format="default"/>). This may also return an error when data is
		not delimited ("not available").</li>
		<li>The maximum transport message size that can be received from
		the configured interface, in bytes (or "not available").</li>
		<li>The maximum amount of data that can possibly be sent before or
		during connection establishment, in bytes.</li>
		</ul>
		<t>In addition to the already mentioned closing/aborting
		notifications and possible send errors, the following notifications
		can occur:</t>


	</section>	<dl>
		<dt>Excessive Retransmissions:
		</dt>
		<dd>The configured (or a default) number of retransmissions has been
		reached, yielding this early warning below an abortion threshold.
		</dd>
		<dt>ICMP Arrival (parameter: ICMP message):
		</dt>
		<dd>An ICMP packet carrying the conveyed ICMP message has arrived.
		</dd>
		<dt>ECN Arrival (parameter: ECN value):
		</dt>
		<dd>A packet carrying the conveyed Explicit Congestion Notification (ECN) va
		lue has arrived. This can be
		useful for applications implementing congestion control.
		</dd>
		<dt>Timeout (parameter: s seconds):
		</dt>
		<dd>Data could not be delivered for s seconds.
		</dd>
		<dt>Drain:
		</dt>
		<dd>The send buffer has either drained below the configured buffer limit
		or it has become completely empty. This is a generic notification that
		tries to enable uniform access to "TCP_NOTSENT_LOWAT" as well as the
		"SENDER DRY" notification (as discussed in <xref target="rundry"/>; SCTP's "
		SENDER
		DRY" is a special case where the threshold (for unsent data) is 0 and
		there is also no more unacknowledged data in the send buffer).
		</dd>
		</dl>


	<section anchor="minset-datatrans-receiving" title="Receiving Da	</section>
	ta">	<section anchor="minset-maintenance-individual" numbered="true" toc="def
	<t>A receiving application obtains an "Application-Framed By	ault">
	testream" (AFra-Bytestream); this concept is further described in <xref target="	<name>Individual Connections</name>
	sendmsg"/>). In line with TCP's receiver semantics, an AFra-Bytestream is just	<t>Configure priority or weight for a scheduler, as described in
	a stream of bytes to the receiver. If message boundaries	<xref target="RFC8260" format="default"/>.</t>
	were specified by the sender, a receiver-side transport system implementing	<t>Configure checksum usage: This can be done with the following
	only the minimum set of transport services defined here	parameters, but there is no guarantee that any checksum limitations
	will still not	will indeed be enforced (the default behavior is "full coverage,
	inform the receiving application about them (this limita	checksum enabled"):</t>
	tion is only needed for transport systems that	<ul>
	are implemented to directly use TCP).</t>	<li>a boolean to enable/disable usage of a checksum when sending</li
	<t>Different from TCP's semantics,	>
	if the sending application has allowed that	<li>the desired coverage (in bytes) of the checksum used when sendin
	messages are not fully reliably transferred, or delivere	g</li>
	d out of order,	<li>a boolean to enable/disable requiring a checksum when receiving<
	then such re-ordering or unreliability may be reflected	/li>
	per message in	<li>the required minimum coverage (in bytes) of the checksum when re
	the arriving data. Messages will always stay intact - i.	ceiving</li>
	e. if an incomplete	</ul>
	message is contained at the end of the arriving data blo
	ck, this message
	is guaranteed to continue in the next arriving data bloc
	k.</t>
	</section>
	</section>
	</section>	</section>

		</section>
		<section anchor="minset-datatrans" numbered="true" toc="default">
		<name>DATA Transfer</name>


	<!-- </section> -->	<section anchor="minset-datatrans-sending" numbered="true" toc="default"
		>
		<name>Sending Data</name>
		<t>When sending a message, no guarantees are given about the
		preservation of message boundaries to the peer; if message
		boundaries are needed, the receiving application at the peer must
		know about them beforehand (or the transport system cannot use
		TCP). Note that an application should already be able to hand over
		data before the transport system establishes a connection with a
		chosen transport protocol. Regarding the message that is being
		handed over, the following parameters can be used:</t>


	<section anchor="Acknowledgements" title="Acknowledgements">	<dl>
	<t>The authors would like to thank all the participants of the TAPS	<dt>Reliability:
	Working Group and the NEAT and	</dt>
	MAMI research projects for valuable input to this document. We e	<dd>This parameter is used to convey a choice of: fully reliable with
	specially thank Michael Tuexen	congestion control (not UDP), unreliable without congestion control,
	for help with connection connection establishment/teardown, Gorr	unreliable with congestion control (not UDP), and partially reliable with
	y Fairhurst for	congestion control (see <xref target="RFC3758" format="default"/> and
	his suggestions regarding fragmentation and packet sizes, and Sp	<xref target="RFC7496" format="default"/> for details on how to specify
	encer Dawkins for his	partial reliability) (not UDP). The latter two choices are optional for a
	extremely detailed and constructive review.	transport system to offer and may result in full reliability. Note that
	This work has received funding from the European Union's Horizon	applications sending unreliable data without congestion control should
	2020 research	themselves perform congestion control in accordance with <xref
	and innovation programme under grant agreement No. 644334 (NEAT)	target="RFC8085" format="default"/>.
	.	</dd>
	<!-- The views expressed are solely those of the author(s).-->
	</t>


	</section>	<dt>Ordered (not UDP):
		</dt>
		<dd>This boolean lets an application choose between ordered
		message delivery (true) and possibly unordered, potentially faster message
		delivery (false).
		</dd>
		<dt>Bundle:
		</dt>
		<dd>This boolean expresses a preference for allowing to bundle messages
		(true) or not (false). No guarantees are given.
		</dd>
		<dt>DelAck:
		</dt>


	<!-- Possibly a 'Contributors' section ... -->	<dd>This boolean, if false, lets an application request that the peer not
		delay the acknowledgement for this message.
		</dd>
		<dt>Fragment:
		</dt>
		<dd>This boolean expresses a preference for allowing to fragment
		messages (true) or not (false), at the IP level. No guarantees are given.
		</dd>
		<dt>Idempotent (not UDP):
		</dt>
		<dd>This boolean expresses whether a message is idempotent (true) or not
		(false). Idempotent messages may arrive multiple times at the receiver
		(but they will arrive at least once). When data is idempotent, it can be
		used by the receiver immediately on a connection establishment
		attempt. Thus, if data is handed over before the transport system
		establishes a connection with a chosen transport protocol, stating that a
		message is idempotent facilitates transmitting it to the peer application
		particularly early.
		</dd>
		</dl>


	<section anchor="IANA" title="IANA Considerations">	<t>An application can be notified of a failure to send a specific
	<t>This memo includes no request to IANA.</t>	message. There is no guarantee of such notifications, i.e., send
		failures can also silently occur.</t>
	</section>	</section>

		<section anchor="minset-datatrans-receiving" numbered="true" toc="defaul
	<section anchor="Security" title="Security Considerations">	t">
	<t>Authentication, confidentiality protection, and integrity protect	<name>Receiving Data</name>
	ion are identified as transport features by <xref target="RFC8095"/>. Often, the	<t>A receiving application obtains an "Application-Framed
	se features are provided by a protocol or layer on top of the transport protocol	Byte Stream" (AFra Byte Stream); this concept is further described in
	; none of the full-featured standards-track transport protocols in <xref target=	<xref target="sendmsg" format="default"/>. In line with TCP's
	"RFC8303"/>, which this document is based upon, provides all of these transport	receiver semantics, an AFra Byte Stream is just a stream of bytes to
	features on its own. Therefore, they are not considered in this document, with t	the receiver. If message boundaries were specified by the sender, a
	he exception of native authentication capabilities of TCP and SCTP for which the	receiver-side transport system implementing only the minimum set of
	security considerations in <xref target="RFC5925"/> and <xref target="RFC4895"/	Transport Services defined here will still not inform the receiving
	> apply. The minimum requirements for a secure transport system are discussed in	application about them (this limitation is only needed for transport
	a separate document (Section 5 on Security Features and Transport Dependencies	systems that are implemented to directly use TCP).</t>
	of <xref target="I-D.ietf-taps-transport-security"/>).</t>	<t>Different from TCP's semantics, if the sending application has
		allowed that messages are not fully reliably transferred, or
		delivered out of order, then such reordering or unreliability may
		be reflected per message in the arriving data. Messages will always
		stay intact, i.e., if an incomplete message is contained at the end
		of the arriving data block, this message is guaranteed to continue
		in the next arriving data block.</t>
	</section>	</section>

		</section>
		</section>


	</middle>	<section anchor="IANA" numbered="true" toc="default">
		<name>IANA Considerations</name>
	<!-- ***BACK MATTER *** -->	<t>This document has no IANA actions.
		</t>
	<back>	</section>
	<!-- References split into informative and normative -->	<section anchor="Security" numbered="true" toc="default">
		<name>Security Considerations</name>
	<!-- There are 2 ways to insert reference entries from the citation libr	<t>Authentication, confidentiality protection, and integrity protection
	aries:	are identified as transport features by <xref target="RFC8095"
	1. define an ENTITY at the top, and use "ampersand character"RFC2629; h	format="default"/>. Often, these features are provided by a protocol or
	ere (as shown)	layer on top of the transport protocol; none of the full-featured
	2. simply use a PI "less than character"?rfc include="reference.RFC.211	standards-track transport protocols in <xref target="RFC8303"
	9.xml"?> here	format="default"/>, which this document is based upon, provide all of
	(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis	these transport features on its own. Therefore, they are not considered
	.xml")	in this document, with the exception of native authentication
		capabilities of TCP and SCTP for which the security considerations in
	Both are cited textually in the same manner: by using xref elements.	<xref target="RFC5925" format="default"/> and <xref target="RFC4895"
	If you use the PI option, xml2rfc will, by default, try to find include	format="default"/> apply.
	d files in the same
	directory as the including file. You can also define the XML_LIBRARY en
	vironment variable
	with a value containing a set of directories to search. These can be e
	ither in the local
	filing system or remote ones accessed by http (http://domain/dir/... ).
	-->

	<references title="Normative References">
	&RFC8095;
	&RFC8303;
	&I-D.ietf-taps-transport-security;
	</references>


	<references title="Informative References">	The minimum requirements for a secure transport system are discussed in a
	<!--&RFC2119;-->	separate document <xref target="RFC8922" format="default"/>.
	&RFC8085;
	&RFC3758;
	&RFC4895;
	&RFC4987;
	&RFC5925;
	&RFC6897;
	&RFC7305;
	&RFC7413;
	&RFC7496;
	&RFC8260;
	&RFC8304;
	&I-D.ietf-tsvwg-rtcweb-qos;
	&I-D.ietf-taps-interface;


	<!-- unnecessary	</t>


	<reference anchor="RFC793bis" target="">	</section>
	<front>	</middle>
	<title>Transmission Control Protocol Specification</title>


	<author fullname="Wesley Eddy" initials="W." surname="Eddy"> </author>	<back>


	<date month="July" year="2017" />	<displayreference target="I-D.ietf-taps-interface" to="TAPS-INTERFACE"/>
	</front>


	<seriesInfo name="Internet-draft"	<references>
	value="draft-ietf-tcpm-rfc793bis-06" />	<name>References</name>
	</reference>	<references>
	-->	<name>Normative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8095.
		xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8303.
		xml"/>


	<reference anchor="LBE-draft" target="">	<reference anchor="RFC8922" target="https://www.rfc-editor.org/info/rfc8922">
	<front>	<front>
	<title>A Lower Effort Per-Hop Behavior (LE PHB)</title>	<title>A Survey of the Interaction between Security Protocols and Transport Serv
		ices</title>


	<author fullname="Roland Bless" initials="R." surname="Bless	<author initials='T' surname='Enghardt' fullname='Theresa Enghardt'>
	"></author>	<organization />
		</author>


	<date month="February" year="2018" />	<author initials='T' surname='Pauly' fullname='Tommy Pauly'>
	</front>	<organization />
		</author>


	<seriesInfo name="Internet-draft"	<author initials='C' surname='Perkins' fullname='Colin Perkins'>
	value="draft-tsvwg-le-phb-03" />	<organization />
	</reference>	</author>


	<reference anchor="COBS">	<author initials='K' surname='Rose' fullname='Kyle Rose'>
	<front>	<organization />
	<title>Consistent Overhead Byte Stuffing</title>	</author>
	<author fullname="Stuart Cheshire" initials="S" surname="Che
	shire">
	<organization>Stanford University</organization></author
	>
	<author fullname="Mary Baker" initials="M" surname="Bak
	er" >
	<organization>Stanford University</organization></author
	>
	<date month="April" year="1999" />
	</front>
	<seriesInfo name="IEEE/ACM Transactions on Networking"
	value="Vol. 7, No. 2"/>
	</reference>


	<reference anchor="WWDC2015"	<author initials='C' surname='Wood' fullname='Christopher Wood'>
	target="https://developer.apple.com/videos/wwdc/2015/?id=719">	<organization />
	<front>	</author>
	<title>Your App and Next Generation Networks</title>


	<author fullname="Prabhakar Lakhera" initials="P." surname=" Lakhera"></author>	<date month="October" year='2020' />


	<author fullname="Stuart Cheshire" initials="S." surname="Ch	</front>
	eshire"></author>	<seriesInfo name="RFC" value="8922"/>
		<seriesInfo name="DOI" value="10.17487/RFC8922"/>
		</reference>


	<date month="June" year="2015" />	</references>
	</front>	<references>
		<name>Informative References</name>


	<seriesInfo name="Apple Worldwide Developers Conference"	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8085.
	value="2015, San Francisco, USA" />	xml"/>
	</reference>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3758.
		xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4895.
		xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4987.
		xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5925.
		xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6897.
		xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7305.
		xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7413.
		xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7496.
		xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8260.
		xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8304.
		xml"/>


	<reference anchor="POSIX"	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ta
	target="http://www.opengroup.org/onlinepubs/9699919799/functions	ps-interface.xml"/>
	/contents.html">
	<front>
	<title>IEEE Standard for Information Technology--Portable Op
	erating System Interface (POSIX(R)) Base Specifications, Issue 7</title>
	<author fullname="IEEE"></author>


	<date month="January" year="2018" />	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8622.
	</front>	xml"/>
	<seriesInfo name="IEEE Std" value= "1003.1-2017 (Revision of IEE
	E Std 1003.1-2008)" />
	</reference>


	<reference anchor="SCTP-stream-1">	<reference anchor="COBS">
	<front>	<front>
	<title>Transparent Flow Mapping for NEAT</title>	<title>Consistent overhead byte stuffing</title>
	<author fullname="Felix Weinrank" initials="F" surname="Wein
	rank"></author>
	<author fullname="Michael Tuexen" initials="M" surname=
	"Tuexen" ></author>
	<date month="June" year="2017" />
	</front>
	<seriesInfo name="IFIP NETWORKING Workshop on Future of Internet
	Transport" value ="(FIT 2017)"/>
	</reference>


	<reference anchor="SCTP-stream-2">	<author fullname="Stuart Cheshire" initials="S" surname="Cheshire">
	<front>	<organization>Stanford University</organization>
	<title>Beneficial Transparent Deployment of SCTP</title>	</author>
	<author fullname="Michael Welzl" initials="M" surname="Welzl	<author fullname="Mary Baker" initials="M" surname="Baker">
	"></author>	<organization>Stanford University</organization>
	<author fullname="Florian Niederbacher" initials="F" su	</author>
	rname="Niederbacher" ></author>	<date month="April" year="1999"/>
	<author fullname="Stein Gjessing" initials="S" surname=
	"Gjessing" ></author>
	<date month="December" year="2011" />
	</front>
	<seriesInfo name="IEEE GlobeCom" value="2011"/>
	</reference>


	</references>	</front>
		<seriesInfo name="DOI" value="10.1109/90.769765"/>


	<!-- Change Log	<refcontent>IEEE/ACM Transactions on Networking, Volume 7, Issue 2
	v00 2006-03-15 EBD Initial version	</refcontent>
		</reference>


	-->	<reference anchor="WWDC2015" target="https://developer.apple.com/videos/
		wwdc/2015/?id=719">
		<front>
		<title>Your App and Next Generation Networks</title>
		<author fullname="Prabhakar Lakhera" initials="P." surname="Lakhera"
		/>
		<author fullname="Stuart Cheshire" initials="S." surname="Cheshire"/
		>
		<date month="June" year="2015"/>
		</front>
		<refcontent>Apple Worldwide Developers Conference 2015</refcontent>
		<refcontent>San Francisco, USA</refcontent>
		</reference>


	<section anchor="super" title="The Superset of Transport Features">	<reference anchor="POSIX" target="https://www.opengroup.org/onlinepubs/9
		699919799/functions/contents.html">
		<front>
		<title>IEEE Standard for Information Technology--Portable Operating
		System Interface (POSIX(R)) Base Specifications, Issue 7</title>
		<author><organization>The Open Group</organization></author>
		<date month="January" year="2018"/>
		</front>
		<seriesInfo name="IEEE Std" value="1003.1-2017"/>
		<refcontent>(Revision of IEEE Std 1003.1-2008)</refcontent>
		</reference>


	<t>	<reference anchor="SCTP-STREAM-1">
	In this description, transport features are	<front>
	presented following the nomenclature "CATEGORY.[SUBCATEGORY]	<title>Transparent Flow Mapping for NEAT</title>
	.FEATURENAME.PROTOCOL",	<author fullname="Felix Weinrank" initials="F" surname="Weinrank"/>
	equivalent to "pass 2" in <xref target="RFC8303" />.	<author fullname="Michael Tuexen" initials="M" surname="Tuexen"/>
	<!-- this was moved to terminology because it applies throug	<date month="June" year="2017"/>
	hout:	</front>
	The PROTOCOL name "UDP(-Lite)" is used when transport featu	<refcontent>IFIP Networking 2017</refcontent>
	res are equivalent	<refcontent>Workshop on Future of Internet Transport (FIT 2017)</refcontent>
	for UDP and UDP-Lite; the PROTOCOL name "TCP" refers to both
	TCP and MPTCP.
	-->
	We also sketch how functional or optimizing transport featur
	es can be implemented by a transport system.
	The "minimal set" derived in this document is meant to be im
	plementable "one-sided"
	over TCP, and, with limitations, UDP. Hence, for all transpo
	rt features that are categorized as
	"functional" or "optimizing", and for
	which no matching TCP and/or UDP primitive exists in "pass 2
	" of <xref target="RFC8303" />, a brief
	discussion on how to implement them over TCP and/or UDP is i
	ncluded.
	</t>


	<t>We designate some transport features as "automatable" on the	</reference>
	basis of a broader decision
	that affects multiple transport features:
	<list style="symbols">
	<t>Most transport features that are related to multi-str
	eaming were designated as "automatable".
	This was done because the decision on whether to use
	multi-streaming or not does not depend on application-specific
	knowledge. This means that a connection that is exhi
	bited to an application could be
	implemented by using a single stream of an SCTP asso
	ciation instead of mapping it to
	a complete SCTP association or TCP connection. This
	could be achieved by using more than one stream when
	an SCTP association is first established (CONNECT.SC
	TP parameter "outbound stream count"),
	maintaining an internal stream number, and using thi
	s stream number
	when sending data (SEND.SCTP parameter "stream numbe
	r"). Closing or aborting
	a connection could then simply free the stream numbe
	r for future use.
	This is discussed further in <xref target="nostream"
	/>.
	</t>
	<t>With the exception of "Disable MPTCP",
	all transport features that are related to using mul
	tiple paths or the choice
	of the network interface were designated as "automat
	able". For example, "Listen" could
	always listen on all available
	interfaces and "Connect" could use the default inter
	face for the destination IP address.
	</t>
	</list>
	</t>


	<t>	<reference anchor="SCTP-STREAM-2">
	Finally, in three cases, transport features are aggregated a	<front>
	nd/or slightly changed from <xref target="RFC8303" /> in the description below.	<title>Beneficial Transparent Deployment of SCTP: The Missing Pieces
	These transport	</title>
	features are marked as "CHANGED FROM RFC8303". These do not	<author fullname="Michael Welzl" initials="M" surname="Welzl"/>
	add any new functionality but just represent a	<author fullname="Florian Niederbacher" initials="F" surname="Nieder
	simple refactoring step that helps to streamline the derivat	bacher"/>
	ion process (e.g., by removing	<author fullname="Stein Gjessing" initials="S" surname="Gjessing"/>
	a choice of a parameter for the sake of applications that ma	<date month="December" year="2011"/>
	y not care about this choice).	</front>
	The corresponding transport features are automatable,	<seriesInfo name="DOI" value="10.1109/GLOCOM.2011.6133554"/>
	and they are listed immediately below the "CHANGED FROM RFC8	<refcontent>IEEE GlobeCom 2011</refcontent>
	303" transport feature.	</reference>
	</t>	</references>
		</references>


	<section anchor="conn-super" title="CONNECTION Related Transport	<section anchor="super" numbered="true" toc="default">
	Features">	<name>The Superset of Transport Features</name>
		<t>
		In this description, transport features are presented
		following the nomenclature
		"CATEGORY.[SUBCATEGORY].FEATURENAME.PROTOCOL", equivalent
		to "pass 2" in <xref target="RFC8303" format="default"/>.
		We also sketch how functional or optimizing transport
		features can be implemented by a transport system. The
		"minimal set" derived in this document is meant to be
		implementable "one-sided" over TCP and, with limitations,
		UDP. Hence, for all transport features that are
		categorized as "functional" or "optimizing", and for which
		no matching TCP and/or UDP primitive exists in "pass 2" of
		<xref target="RFC8303" format="default"/>, a brief
		discussion on how to implement them over TCP and/or UDP is
		included.
		</t>
		<t>We designate some transport features as "automatable" on the basis of
		a broader decision that affects multiple transport features:
		</t>
		<ul>
		<li>Most transport features that are related to multi-streaming were
		designated as "automatable". This was done because the decision on
		whether or not to use multi-streaming 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 or TCP connection. This could be achieved by using more
		than one stream when an SCTP association is first established
		(CONNECT.SCTP parameter "outbound stream count"), maintaining an
		internal stream number, and using this stream number when sending data
		(SEND.SCTP parameter "stream number"). Closing or aborting a
		connection could then simply free the stream number for future use.
		This is discussed further in <xref target="nostream"
		format="default"/>.
		</li>
		<li>With the exception of "Disable MPTCP", all transport features that
		are related to using multiple paths or the choice of the network
		interface were designated as "automatable". For example, "Listen"
		could always listen on all available interfaces and "Connect" could
		use the default interface for the destination IP address.
		</li>
		</ul>


	<t>ESTABLISHMENT:<vspace />	<t>
		Finally, in three cases, transport features are aggregated
		and/or slightly changed from <xref target="RFC8303"
		format="default"/> in the description below. These
		transport features are marked as "CHANGED FROM
		RFC 8303". These do not add any new functionality but just
		represent a simple refactoring step that helps to
		streamline the derivation process (e.g., by removing a
		choice of a parameter for the sake of applications that
		may not care about this choice). The corresponding
		transport features are automatable, and they are listed
		immediately below the "CHANGED FROM RFC 8303" transport
		feature.
		</t>
		<section anchor="conn-super" numbered="true" toc="default">
		<name>CONNECTION-Related Transport Features</name>
		<t>ESTABLISHMENT:


	<list style="symbols">	</t>
	<t>Connect <vspace />	<ul>
	Protocols: TCP, SCTP, UDP(-Lite) <vspace />	<li>
	Functional because the notion of a connection is	<t>Connect </t>
	often reflected in applications	<t>
	as an expectation to be able to communicate afte	Protocols: TCP, SCTP, UDP(-Lite) </t>
	r a "Connect" succeeded,	<t>
	with a communication sequence relating to this t	Functional because the notion of a connection
	ransport feature that is defined by the	is often reflected in applications as an
	application protocol.<vspace />	expectation to be able to communicate after a
	Implementation: via CONNECT.TCP, CONNECT.SCTP or	"Connect" succeeded, with a communication
	CONNECT.UDP(-Lite).<vspace />	sequence relating to this transport feature
	<vspace blankLines='1'/>	that is defined by the application
	</t>	protocol.</t>
		<t>
		Implementation: via CONNECT.TCP, CONNECT.SCTP or
		CONNECT.UDP(-Lite).</t>
		<t/>
		</li>
		<li>
		<t>Specify which IP Options must always be used</t>
		<t>
		Protocols: TCP, UDP(-Lite)</t>
		<t>
		Automatable because IP Options relate to
		knowledge about the network, not the
		application.</t>
		<t/>
		</li>
		<li>
		<t>Request multiple streams</t>
		<t>
		Protocols: SCTP</t>
		<t>
		Automatable because using multi-streaming does
		not require application-specific knowledge
		(example implementations of using
		multi-streaming without involving the
		application are described in <xref
		target="SCTP-STREAM-1" format="default"/> and
		<xref target="SCTP-STREAM-2"
		format="default"/>).</t>
		<t>
		Implementation: see <xref target="nostream" form
		at="default"/>.
		</t>
		<t/>
		</li>
		<li>
		<t>Limit the number of inbound streams</t>
		<t>
		Protocols: SCTP</t>
		<t>
		Automatable because using multi-streaming does n
		ot require application-specific knowledge.</t>
		<t>
		Implementation: see <xref target="nostream" form
		at="default"/>.
		</t>
		<t/>
		</li>
		<li>
		<t>Specify number of attempts and/or timeout for the first establish
		ment message</t>
		<t>
		Protocols: TCP, SCTP</t>
		<t>
		Functional because this is closely related to
		potentially assumed reliable data delivery for
		data that is sent before or during connection
		establishment.</t>
		<t>
		Implementation: using a parameter of CONNECT.TCP
		and CONNECT.SCTP.</t>
		<t>
		Implementation over UDP: do nothing (this is
		irrelevant in the case of UDP because there,
		reliable data delivery is not assumed).
		</t>


	<t>Specify which IP Options must always be used<vspa	<t/>
	ce />	</li>
	Protocols: TCP, UDP(-Lite)<vspace />	<li>
	Automatable because IP Options relate to knowled	<t>Obtain multiple sockets</t>
	ge about the network, not the application.<vspace />	<t>
	<vspace blankLines='1'/>	Protocols: SCTP</t>
	</t>	<t>
	<t>Request multiple streams<vspace />
	Protocols: SCTP<vspace />
	Automatable because using multi-streaming does n
	ot require application-specific knowledge
	(example implementations of using multi-streamin
	g without involving the application
	are described in <xref target="SCTP-stream-1"/>
	and <xref target="SCTP-stream-2"/>).<vspace />
	Implementation: see <xref target="nostream"/>.
	<vspace blankLines='1'/>
	</t>
	<t>Limit the number of inbound streams<vspace />
	Protocols: SCTP<vspace />
	Automatable because using multi-streaming does n
	ot require application-specific knowledge.<vspace />
	Implementation: see <xref target="nostream"/>.
	<vspace blankLines='1'/>
	</t>
	<t>Specify number of attempts and/or timeout for the
	first establishment message<vspace />
	Protocols: TCP, SCTP<vspace />
	Functional because this is closely related to po
	tentially assumed reliable data delivery for
	data that is sent before or during connection es
	tablishment.<vspace />
	Implementation: Using a parameter of CONNECT.TCP
	and CONNECT.SCTP.<vspace />
	Implementation over UDP: Do nothing (this is irr
	elevant in case of UDP because there, reliable
	data delivery is not assumed).
	<vspace blankLines='1'/>
	</t>
	<t>Obtain multiple sockets<vspace />
	Protocols: SCTP<vspace />
	Automatable because the non-parallel usage of mu ltiple paths to communicate between the same end	Automatable because the non-parallel usage of mu ltiple paths to communicate between the same end
	hosts relates to knowledge about	hosts relates to knowledge about

	the network, not the application.<vspace />	the network, not the application.</t>
	<vspace blankLines='1'/>	<t/>
	</t>	</li>
	<t>Disable MPTCP<vspace />	<li>
	Protocols: MPTCP<vspace />	<t>Disable MPTCP</t>
	Optimizing because the parallel usage of multipl	<t>
	e paths to communicate between the same end hosts	Protocols: MPTCP</t>
	can improve performance. Whether to use this fea	<t>
	ture depends on knowledge about the	Optimizing because the parallel usage of
	network as well as application-specific knowledg	multiple paths to communicate between the same
	e (see Section 3.1 of <xref target="RFC6897"/>).<vspace />	end hosts can improve performance. Whether or
	Implementation: via a boolean parameter in CONNE	not to use this feature depends on knowledge
	CT.MPTCP.<vspace />	about the network as well as
	Implementation over TCP: Do nothing.<vspace />	application-specific knowledge (see <xref
	Implementation over UDP: Do nothing.	target="RFC6897" sectionFormat="of" section="3.1"
	<vspace blankLines='1'/>	/>).</t>
	</t>	<t>
	<t>Configure authentication<vspace />	Implementation: via a boolean parameter in CONNE
	Protocols: TCP, SCTP<vspace />	CT.MPTCP.</t>
	Functional because this has a direct influence o	<t>
	n security.<vspace />	Implementation over TCP: do nothing.</t>
	Implementation: via parameters in CONNECT.TCP an	<t>
	d CONNECT.SCTP.	Implementation over UDP: do nothing.
	With TCP, this allows to configure Master Key Tu	</t>
	ples (MKTs) to	<t/>
	authenticate complete segments (including the TC	</li>
	P IPv4 pseudoheader, TCP header, and TCP data).	<li>
	With SCTP, this allows to specify which chunk ty	<t>Configure authentication</t>
	pes must always be authenticated.	<t>
	Authenticating only certain chunk types creates	Protocols: TCP, SCTP</t>
	a reduced level of security that is not	<t>
	supported by TCP; to be compatible, this should	Functional because this has a direct influence o
	therefore only allow to authenticate all chunk types.	n security.</t>
	Key material must be provided in a way that is c	<t>
	ompatible with both <xref target="RFC4895"/> and <xref target="RFC5925"/>.<vspac	Implementation: via parameters in CONNECT.TCP
	e />	and CONNECT.SCTP. With TCP, this allows
	Implementation over UDP: Not possible (UDP does	configuring Master Key Tuples (MKTs) to
	not offer this functionality).	authenticate complete segments (including the
	<vspace blankLines='1'/>	TCP IPv4 pseudoheader, TCP header, and TCP
	</t>	data). With SCTP, this allows specifying
	<t>Indicate (and/or obtain upon completion) an Adapt	which chunk types must always be
	ation Layer via an adaptation code point<vspace />	authenticated. Authenticating only certain
	Protocols: SCTP<vspace />	chunk types creates a reduced level of
	Functional because it allows to send extra data	security that is not supported by TCP; to be
	for the sake	compatible, this should therefore only allow
	of identifying an adaptation layer, which by its	to authenticate all chunk types. Key material
	elf is application-specific.<vspace />	must be provided in a way that is compatible
	Implementation: via a parameter in CONNECT.SCTP.	with both <xref target="RFC4895"
	<vspace />	format="default"/> and <xref target="RFC5925"
	Implementation over TCP: not possible (TCP does	format="default"/>.</t>
	not offer this functionality).<vspace />	<t>
	Implementation over UDP: not possible (UDP does	Implementation over UDP: not possible (UDP does
	not offer this functionality).<vspace />	not offer this functionality).
	<vspace blankLines='1'/>	</t>
	</t>	<t/>
	<t>Request to negotiate interleaving of user message	</li>
	s<vspace />	<li>
	Protocols: SCTP<vspace />	<t>Indicate (and/or obtain upon completion) an Adaptation Layer via
		an adaptation code point</t>
		<t>
		Protocols: SCTP</t>
		<t>
		Functional because it allows sending extra
		data for the sake of identifying an adaptation
		layer, which by itself is application
		specific.</t>
		<t>
		Implementation: via a parameter in CONNECT.SCTP.
		</t>
		<t>
		Implementation over TCP: not possible. (TCP does
		not offer this functionality.)</t>
		<t>
		Implementation over UDP: not possible. (UDP does
		not offer this functionality.)</t>
		<t/>
		</li>
		<li>
		<t>Request to negotiate interleaving of user messages</t>
		<t>
		Protocols: SCTP</t>
		<t>
	Automatable because it requires using multiple s treams, but	Automatable because it requires using multiple s treams, but
	requesting multiple streams in the CONNECTION.ES TABLISHMENT category is	requesting multiple streams in the CONNECTION.ES TABLISHMENT category is

	automatable.<vspace />	automatable.</t>
		<t>
	Implementation: controlled via a parameter in CO NNECT.SCTP. One possible	Implementation: controlled via a parameter in CO NNECT.SCTP. One possible

	implementation is to always try to enable interl	implementation is to always try to enable interl
	eaving.<vspace />	eaving.</t>
	<vspace blankLines='1'/>	<t/>
	</t>	</li>
	<t>Hand over a message to reliably transfer (possibl	<li>
	y multiple times) before connection establishment<vspace />	<t>Hand over a message to reliably transfer (possibly multiple times
	Protocols: TCP<vspace />	) before connection establishment</t>
		<t>
		Protocols: TCP</t>
		<t>
	Functional because this is closely tied to prope rties of the data that an application	Functional because this is closely tied to prope rties of the data that an application

	sends or expects to receive.<vspace />	sends or expects to receive.</t>
	Implementation: via a parameter in CONNECT.TCP.<	<t>
	vspace />	Implementation: via a parameter in CONNECT.TCP.<
	Implementation over UDP: not possible (UDP does	/t>
	not provide reliability).	<t>
	<vspace blankLines='1'/>	Implementation over UDP: not possible. (UDP does
	</t>	not provide reliability.)
	<t>Hand over a message to reliably transfer during c	</t>
	onnection establishment<vspace />	<t/>
	Protocols: SCTP<vspace />	</li>
	Functional because this can only work if the mes	<li>
	sage is limited in size, making it closely	<t>Hand over a message to reliably transfer during connection establ
	tied to properties of the data that an applicati	ishment</t>
	on	<t>
	sends or expects to receive.<vspace />	Protocols: SCTP</t>
	Implementation: via a parameter in CONNECT.SCTP.	<t>
	<vspace />	Functional because this can only work if the
	Implementation over TCP: not possible (TCP does	message is limited in size, making it closely
	not allow identification of message boundaries	tied to properties of the data that an
	because it provides a byte stream service)<vspac	application sends or expects to receive.</t>
	e />	<t>
	<!--	Implementation: via a parameter in CONNECT.SCTP.
	The text below is wrong because TCP is not mess	</t>
	age-based!	<t>
		Implementation over TCP: transmit the message
	Implementation over TCP: this is also possible	with the SYN packet, sacrificing the ability
	with TCP, but not addressed	to identify message boundaries.
	in <xref target="RFC8303"/> because the specific	</t>
	ation that it is based upon	<t>
	does not clearly specify how to implement it	Implementation over UDP: not possible. (UDP is
	using the TCP's ``user commands''.	unreliable.)
	This will be addressed in an	</t>
	update <xref target="RFC793bis"/>.<vspace />	<t/>
	-->	</li>
	Implementation over UDP: not possible (UDP is un	<li>
	reliable).	<t>Enable UDP encapsulation with a specified remote UDP port number<
	<vspace blankLines='1'/>	/t>
	</t>	<t>
	<t>Enable UDP encapsulation with a specified remote	Protocols: SCTP</t>
	UDP port number<vspace />	<t>
	Protocols: SCTP<vspace />	Automatable because UDP encapsulation relates
	Automatable because UDP encapsulation relates to	to knowledge about the network, not the
	knowledge about the network, not the application.<vspace />	application.</t>
	<vspace blankLines='1'/>	<t/>
	</t>	</li>
		</ul>
	</list></t>	<t>AVAILABILITY:

	<t>AVAILABILITY:<vspace />


	<list style="symbols">	</t>
	<t>Listen<vspace />	<ul >
	Protocols: TCP, SCTP, UDP(-Lite)<vspace />	<li>
	Functional because the notion of accepting conne	<t>Listen</t>
	ction requests is often reflected	<t>
	in applications as an expectation to be able to	Protocols: TCP, SCTP, UDP(-Lite)</t>
	communicate after a "Listen" succeeded,
	with a communication sequence relating to this t
	ransport feature that is defined by the
	application protocol.<vspace />
	CHANGED FROM RFC8303. This differs from the 3 au
	tomatable transport features below in that it leaves the choice
	of interfaces for listening open.<vspace />
	Implementation: by listening on all interfaces v
	ia LISTEN.TCP (not providing a local IP address)
	or LISTEN.SCTP (providing SCTP port number / add
	ress pairs for all local IP addresses).
	LISTEN.UDP(-Lite) supports both methods.<vspace
	blankLines='1'/>
	</t>
	<t>Listen, 1 specified local interface<vspace />
	Protocols: TCP, SCTP, UDP(-Lite)<vspace />
	Automatable because decisions about local interf
	aces relate to knowledge about the
	network and the Operating System, not the applic
	ation.<vspace />
	<vspace blankLines='1'/>
	</t>
	<t>Listen, N specified local interfaces<vspace />
	Protocols: SCTP<vspace />
	Automatable because decisions about local interf
	aces relate to knowledge about the
	network and the Operating System, not the applic
	ation.<vspace />
	<vspace blankLines='1'/>
	</t>
	<t>Listen, all local interfaces<vspace />
	Protocols: TCP, SCTP, UDP(-Lite)<vspace />
	Automatable because decisions about local interf
	aces relate to knowledge about the
	network and the Operating System, not the applic
	ation.<vspace />
	<vspace blankLines='1'/>
	</t>
	<t>Specify which IP Options must always be used<vspa
	ce />
	Protocols: TCP, UDP(-Lite)<vspace />
	Automatable because IP Options relate to knowled
	ge about the network, not the application.<vspace />
	<vspace blankLines='1'/>
	</t>
	<t>Disable MPTCP<vspace />
	Protocols: MPTCP<vspace />
	Optimizing because the parallel usage of multipl
	e paths to communicate between the same end hosts
	can improve performance. Whether to use this fea
	ture depends on knowledge about the
	network as well as application-specific knowledg
	e (see Section 3.1 of <xref target="RFC6897"/>).<vspace />
	Implementation: via a boolean parameter in LISTE
	N.MPTCP.<vspace />
	Implementation over TCP: Do nothing.<vspace />
	Implementation over UDP: Do nothing.
	<vspace blankLines='1'/>
	</t>
	<t>Configure authentication<vspace />
	Protocols: TCP, SCTP<vspace />
	Functional because this has a direct influence o
	n security.<vspace />
	Implementation: via parameters in LISTEN.TCP and
	LISTEN.SCTP.<vspace />
	Implementation over TCP: With TCP, this allows t
	o configure Master Key Tuples (MKTs) to
	authenticate complete segments (including the TC
	P IPv4 pseudoheader, TCP header, and TCP data).
	With SCTP, this allows to specify which chunk ty
	pes must always be authenticated.
	Authenticating only certain chunk types creates
	a reduced level of security that is not
	supported by TCP; to be compatible, this should
	therefore only allow to authenticate all chunk types.
	Key material must be provided in a way that is c
	ompatible with both <xref target="RFC4895"/> and <xref target="RFC5925"/>.<vspac
	e />
	Implementation over UDP: not possible (UDP does
	not offer authentication).
	<vspace blankLines='1'/>
	</t>
	<t>Obtain requested number of streams<vspace />
	Protocols: SCTP<vspace />
	Automatable because using multi-streaming does n
	ot require application-specific knowledge.<vspace />
	Implementation: see <xref target="nostream"/>.
	<vspace blankLines='1'/>
	</t>
	<t>Limit the number of inbound streams<vspace />
	Protocols: SCTP<vspace />
	Automatable because using multi-streaming does n
	ot require application-specific knowledge.<vspace />
	Implementation: see <xref target="nostream"/>.
	<vspace blankLines='1'/>
	</t>
	<t>Indicate (and/or obtain upon completion) an Adapt
	ation Layer via an adaptation code point<vspace />
	Protocols: SCTP<vspace />
	Functional because it allows to send extra data
	for the sake
	of identifying an adaptation layer, which by its
	elf is application-specific.<vspace />
	Implementation: via a parameter in LISTEN.SCTP.<
	vspace />
	Implementation over TCP: not possible (TCP does
	not offer this functionality).<vspace />
	Implementation over UDP: not possible (UDP does
	not offer this functionality).
	<vspace blankLines='1'/>
	</t>
	<t>Request to negotiate interleaving of user message
	s<vspace />
	Protocols: SCTP<vspace />
	Automatable because it requires using multiple s
	treams, but
	requesting multiple streams in the CONNECTION.ES
	TABLISHMENT category is
	automatable.<vspace />
	Implementation: via a parameter in LISTEN.SCTP.<
	vspace />
	<vspace blankLines='1'/>
	</t>
	</list></t>


	<t>MAINTENANCE:<vspace />	<t>
		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 feature that is defined by the
		application protocol.</t>
		<t>
		CHANGED FROM RFC 8303. This differs from the 3
		automatable transport features below in that
		it leaves the choice of interfaces for
		listening open.</t>
		<t>
		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.UDP(-Lite) supports both
		methods.</t>
		<t/>
		</li>
		<li>
		<t>Listen, 1 specified local interface</t>
		<t>
		Protocols: TCP, SCTP, UDP(-Lite)</t>
		<t>
		Automatable because decisions about local
		interfaces relate to knowledge about the
		network and the Operating System, not the
		application.</t>
		<t/>
		</li>
		<li>
		<t>Listen, N specified local interfaces</t>
		<t>
		Protocols: SCTP</t>
		<t>
		Automatable because decisions about local
		interfaces relate to knowledge about the
		network and the Operating System, not the
		application.</t>
		<t/>
		</li>
		<li>
		<t>Listen, all local interfaces</t>
		<t>
		Protocols: TCP, SCTP, UDP(-Lite)</t>
		<t>
		Automatable because decisions about local
		interfaces relate to knowledge about the
		network and the Operating System, not the
		application.</t>
		<t/>
		</li>
		<li>
		<t>Specify which IP Options must always be used</t>
		<t>
		Protocols: TCP, UDP(-Lite)</t>
		<t>
		Automatable because IP Options relate to
		knowledge about the network, not the
		application.</t>
		<t/>
		</li>
		<li>
		<t>Disable MPTCP</t>
		<t>
		Protocols: MPTCP</t>
		<t>
		Optimizing because the parallel usage of
		multiple paths to communicate between the same
		end hosts can improve performance. Whether or
		not to use this feature depends on knowledge
		about the network as well as
		application-specific knowledge (see <xref
		target="RFC6897" sectionFormat="of"
		section="3.1"/>).</t>
		<t>
		Implementation: via a boolean parameter in
		LISTEN.MPTCP.</t>
		<t>
		Implementation over TCP: do nothing.</t>
		<t>
		Implementation over UDP: do nothing.
		</t>
		<t/>
		</li>
		<li>
		<t>Configure authentication</t>
		<t>
		Protocols: TCP, SCTP</t>
		<t>
		Functional because this has a direct influence o
		n security.</t>
		<t>
		Implementation: via parameters in LISTEN.TCP and
		LISTEN.SCTP.</t>
		<t>
		Implementation over TCP: with TCP, this allows
		configuring Master Key Tuples (MKTs) to
		authenticate complete segments (including the
		TCP IPv4 pseudoheader, TCP header, and TCP
		data). With SCTP, this allows specifying
		which chunk types must always be
		authenticated. Authenticating only certain
		chunk types creates a reduced level of
		security that is not supported by TCP; to be
		compatible, this should therefore only allow
		to authenticate all chunk types. Key material
		must be provided in a way that is compatible
		with both <xref target="RFC4895"
		format="default"/> and <xref target="RFC5925"
		format="default"/>.</t>
		<t>
		Implementation over UDP: not possible. (UDP does
		not offer authentication.)
		</t>
		<t/>
		</li>
		<li>
		<t>Obtain requested number of streams</t>
		<t>
		Protocols: SCTP</t>
		<t>
		Automatable because using multi-streaming does
		not require application-specific
		knowledge.</t>
		<t>
		Implementation: see <xref target="nostream" form
		at="default"/>.
		</t>
		<t/>
		</li>
		<li>
		<t>Limit the number of inbound streams</t>
		<t>
		Protocols: SCTP</t>
		<t>
		Automatable because using multi-streaming does
		not require application-specific
		knowledge.</t>
		<t>
		Implementation: see <xref target="nostream" form
		at="default"/>.
		</t>
		<t/>
		</li>
		<li>
		<t>Indicate (and/or obtain upon completion) an Adaptation Layer via
		an adaptation code point</t>
		<t>
		Protocols: SCTP</t>
		<t>
		Functional because it allows sending extra
		data for the sake of identifying an adaptation
		layer, which by itself is
		application specific.</t>
		<t>
		Implementation: via a parameter in LISTEN.SCTP.<
		/t>
		<t>
		Implementation over TCP: not possible. (TCP does
		not offer this functionality.)</t>
		<t>
		Implementation over UDP: not possible. (UDP does
		not offer this functionality.)
		</t>
		<t/>
		</li>
		<li>
		<t>Request to negotiate interleaving of user messages</t>
		<t>
		Protocols: SCTP</t>
		<t>
		Automatable because it requires using multiple
		streams, but requesting multiple streams in
		the CONNECTION.ESTABLISHMENT category is
		automatable.</t>
		<t>
		Implementation: via a parameter in LISTEN.SCTP.<
		/t>
		<t/>
		</li>
		</ul>
		<t>MAINTENANCE:


	<list style="symbols">	</t>
	<t>Change timeout for aborting connection (using ret	<ul >
	ransmit limit or time value)<vspace />	<li>
	Protocols: TCP, SCTP<vspace />	<t>Change timeout for aborting connection (using retransmit limit or
	Functional because this is closely related to po	time value)</t>
	tentially assumed reliable data delivery.<vspace />	<t>
	Implementation: via CHANGE_TIMEOUT.TCP or CHANGE	Protocols: TCP, SCTP</t>
	_TIMEOUT.SCTP.<vspace />	<t>
	Implementation over UDP: not possible (UDP is un	Functional because this is closely related to po
	reliable and there is no connection timeout).<vspace />	tentially assumed reliable data delivery.</t>
	<vspace blankLines='1'/>	<t>
	</t>	Implementation: via CHANGE_TIMEOUT.TCP or
	<t>Suggest timeout to the peer<vspace />	CHANGE_TIMEOUT.SCTP.</t>
	Protocols: TCP<vspace />	<t>
	Functional because this is closely related to po	Implementation over UDP: not possible. (UDP is u
	tentially assumed reliable data delivery.<vspace />	nreliable and there is no connection timeout.)</t>
	Implementation: via CHANGE_TIMEOUT.TCP.<vspace /	<t/>
	>	</li>
	Implementation over UDP: not possible (UDP is un	<li>
	reliable and there is no connection timeout).<vspace />	<t>Suggest timeout to the peer</t>
	<vspace blankLines='1'/>	<t>
	</t>	Protocols: TCP</t>
	<t>Disable Nagle algorithm<vspace />	<t>
	Protocols: TCP, SCTP<vspace />	Functional because this is closely related to
	Optimizing because this decision depends on know	potentially assumed reliable data
	ledge about the size of future data blocks	delivery.</t>
	and the delay between them.<vspace />	<t>
	Implementation: via DISABLE_NAGLE.TCP and DISABL	Implementation: via CHANGE_TIMEOUT.TCP.</t>
	E_NAGLE.SCTP.<vspace />	<t>
	Implementation over UDP: do nothing (UDP does no	Implementation over UDP: not possible. (UDP is
	t implement the Nagle algorithm).<vspace />	unreliable and there is no connection
	<vspace blankLines='1'/>	timeout.)</t>
	</t>	<t/>
	<t>Request an immediate heartbeat, returning success	</li>
	/failure<vspace />	<li>
	Protocols: SCTP<vspace />	<t>Disable Nagle algorithm</t>
	Automatable because this informs about network-s	<t>
	pecific knowledge.<vspace />	Protocols: TCP, SCTP</t>
	<vspace blankLines='1'/>	<t>
	</t>	Optimizing because this decision depends on
	<t>Notification of Excessive Retransmissions (early	knowledge about the size of future data blocks
	warning below abortion threshold)<vspace />	and the delay between them.</t>
	Protocols: TCP<vspace />	<t>
	Optimizing because it is an early warning to the	Implementation: via DISABLE_NAGLE.TCP and DISABL
	application, informing it of an impending	E_NAGLE.SCTP.</t>
	functional event.<vspace />	<t>
	Implementation: via ERROR.TCP.<vspace />	Implementation over UDP: do nothing (UDP does no
	Implementation over UDP: do nothing (there is no	t implement the Nagle algorithm).</t>
	abortion threshold).<vspace />	<t/>
	<vspace blankLines='1'/>	</li>
	</t>	<li>
	<t>Add path<vspace />	<t>Request an immediate heartbeat, returning success/failure</t>
	Protocols: MPTCP, SCTP<vspace />	<t>
	MPTCP Parameters: source-IP; source-Port; destin	Protocols: SCTP</t>
	ation-IP; destination-Port<vspace />	<t>
	SCTP Parameters: local IP address<vspace />	Automatable because this informs about network-s
		pecific knowledge.</t>
		<t/>
		</li>
		<li>
		<t>Notification of Excessive Retransmissions (early warning below ab
		ortion threshold)</t>
		<t>
		Protocols: TCP</t>
		<t>
		Optimizing because it is an early warning to
		the application, informing it of an impending
		functional event.</t>
		<t>
		Implementation: via ERROR.TCP.</t>
		<t>
		Implementation over UDP: do nothing (there is no
		abortion threshold).</t>
		<t/>
		</li>
		<li>
		<t>Add path</t>
		<t>
		Protocols: MPTCP, SCTP</t>
		<t>
		MPTCP Parameters: source-IP; source-Port; destin
		ation-IP; destination-Port</t>
		<t>
		SCTP Parameters: local IP address</t>
		<t>
	Automatable because the choice of paths to commu nicate between the same end hosts relates to	Automatable because the choice of paths to commu nicate between the same end hosts relates to

	knowledge about the network, not the application	knowledge about the network, not the application
	.<vspace />	.</t>
	<vspace blankLines='1'/>	<t/>
	</t>	</li>
	<t>Remove path<vspace />	<li>
	Protocols: MPTCP, SCTP<vspace />	<t>Remove path</t>
	MPTCP Parameters: source-IP; source-Port; destin	<t>
	ation-IP; destination-Port<vspace />	Protocols: MPTCP, SCTP</t>
	SCTP Parameters: local IP address<vspace />	<t>
		MPTCP Parameters: source-IP; source-Port; destin
		ation-IP; destination-Port</t>
		<t>
		SCTP Parameters: local IP address</t>
		<t>
	Automatable because the choice of paths to commu nicate between the same end host relates to	Automatable because the choice of paths to commu nicate between the same end host relates to

	knowledge about the network, not the application	knowledge about the network, not the application
	.<vspace />	.</t>
	<vspace blankLines='1'/>	<t/>
	</t>	</li>
	<t>Set primary path<vspace />	<li>
	Protocols: SCTP<vspace />	<t>Set primary path</t>
		<t>
		Protocols: SCTP</t>
		<t>
	Automatable because the choice of paths to commu nicate between the same end hosts relates to	Automatable because the choice of paths to commu nicate between the same end hosts relates to

	knowledge about the network, not the application	knowledge about the network, not the application
	.<vspace />	.</t>
	<vspace blankLines='1'/>	<t/>
	</t>	</li>
	<t>Suggest primary path to the peer<vspace />	<li>
	Protocols: SCTP<vspace />	<t>Suggest primary path to the peer</t>
		<t>
		Protocols: SCTP</t>
		<t>
	Automatable because the choice of paths to commu nicate between the same end hosts relates to	Automatable because the choice of paths to commu nicate between the same end hosts relates to

	knowledge about the network, not the application	knowledge about the network, not the application
	.<vspace />	.</t>
	<vspace blankLines='1'/>	<t/>
	</t>	</li>
	<t>Configure Path Switchover<vspace />	<li>
	Protocols: SCTP<vspace />	<t>Configure Path Switchover</t>
		<t>
		Protocols: SCTP</t>
		<t>
	Automatable because the choice of paths to commu nicate between the same end hosts relates to	Automatable because the choice of paths to commu nicate between the same end hosts relates to

	knowledge about the network, not the application	knowledge about the network, not the application
	.<vspace />	.</t>
	<vspace blankLines='1'/>	<t/>
	</t>	</li>
	<t>Obtain status (query or notification)<vspace />	<li>
	Protocols: SCTP, MPTCP<vspace />	<t>Obtain status (query or notification)</t>
	SCTP parameters: association	<t>
	connection state; destination transport address	Protocols: SCTP, MPTCP</t>
	list; destination transport	<t>
	address reachability states;	SCTP parameters: association connection state;
	current local and peer receiver window size; cur	destination transport address list;
	rent local congestion	destination transport address reachability
	window sizes; number of unacknowledged DATA chun	states; current local and peer receiver window
	ks; number of DATA chunks	size; current local congestion window sizes;
	pending receipt; primary path; most recent SRTT	number of unacknowledged DATA chunks; number
	on primary path; RTO on	of DATA chunks pending receipt; primary path;
	primary path; SRTT and RTO on other destination	most recent SRTT on primary path; RTO on
	addresses; MTU per path;	primary path; SRTT and RTO on other
	interleaving supported yes/no<vspace />	destination addresses; MTU per path;
	MPTCP parameters: subflow-list (identified by so	interleaving supported yes/no</t>
	urce-IP; source-Port; destination-IP; destination-Port)<vspace />	<t>
		MPTCP parameters: subflow-list (identified by so
		urce-IP; source-Port; destination-IP; destination-Port)</t>
		<t>
	Automatable because these parameters relate to k nowledge about	Automatable because these parameters relate to k nowledge about

	the network, not the application.<vspace />	the network, not the application.</t>
	<vspace blankLines='1'/>	<t/>
	</t>	</li>
	<t>Specify DSCP field<vspace />	<li>
	Protocols: TCP, SCTP, UDP(-Lite)<vspace />	<t>Specify DSCP field</t>
	Optimizing because choosing a suitable DSCP valu	<t>
	e requires application-specific knowledge.<vspace />	Protocols: TCP, SCTP, UDP(-Lite)</t>
	Implementation: via SET_DSCP.TCP / SET_DSCP.SCTP	<t>
	/ SET_DSCP.UDP(-Lite)<vspace />	Optimizing because choosing a suitable DSCP valu
	<vspace blankLines='1'/>	e requires application-specific knowledge.</t>
	</t>	<t>
	<t>Notification of ICMP error message arrival<vspace	Implementation: via SET_DSCP.TCP / SET_DSCP.SCTP
	/>	/ SET_DSCP.UDP(-Lite).</t>
	Protocols: TCP, UDP(-Lite)<vspace />	<t/>
	Optimizing because these messages can inform abo	</li>
	ut success or failure of functional	<li>
	transport features	<t>Notification of ICMP error message arrival</t>
	(e.g., host unreachable relates to "Connect")<vs	<t>
	pace />	Protocols: TCP, UDP(-Lite)</t>
	Implementation: via ERROR.TCP or ERROR.UDP(-Lite	<t>
	).<vspace />	Optimizing because these messages can inform
	<vspace blankLines='1'/>	about success or failure of functional
	</t>	transport features (e.g., host unreachable
	<t>Obtain information about interleaving support<vsp	relates to "Connect").</t>
	ace />	<t>
	Protocols: SCTP<vspace />	Implementation: via ERROR.TCP or ERROR.UDP(-Lite
	Automatable because it requires using multiple s	.)</t>
	treams, but	<t/>
	requesting multiple streams in the CONNECTION.ES	</li>
	TABLISHMENT category is	<li>
	automatable.<vspace />	<t>Obtain information about interleaving support</t>
	Implementation: via STATUS.SCTP.<vspace />	<t>
	<vspace blankLines='1'/>	Protocols: SCTP</t>
	</t>	<t>
	<t>Change authentication parameters<vspace />	Automatable because it requires using multiple
	Protocols: TCP, SCTP<vspace />	streams, but requesting multiple streams in
	Functional because this has a direct influence o	the CONNECTION.ESTABLISHMENT category is
	n security.<vspace />	automatable.</t>
	Implementation: via SET_AUTH.TCP and SET_AUTH.SC	<t>
	TP.<vspace />	Implementation: via STATUS.SCTP.</t>
	Implementation over TCP: With SCTP, this allows	<t/>
	to adjust key_id, key, and hmac_id.	</li>
	With TCP, this allows to change the preferred ou	<li>
	tgoing MKT (current_key)	<t>Change authentication parameters</t>
	and the preferred incoming MKT (rnext_key), resp	<t>
	ectively, for a segment that is sent on the connection.	Protocols: TCP, SCTP</t>
	Key material must be provided in a way that is c	<t>
	ompatible with both <xref target="RFC4895"/> and <xref target="RFC5925"/>.<vspac	Functional because this has a direct influence o
	e />	n security.</t>
	Implementation over UDP: not possible (UDP does	<t>
	not offer authentication).<vspace />	Implementation: via SET_AUTH.TCP and SET_AUTH.SC
	<vspace blankLines='1'/>	TP.</t>
	</t>	<t>
	<t>Obtain authentication information<vspace />	Implementation over TCP: with SCTP, this
	Protocols: SCTP<vspace />	allows adjusting key_id, key, and hmac_id.
	Functional because authentication decisions may	With TCP, this allows changing the preferred
	have been made by the peer,	outgoing MKT (current_key) and the preferred
	and this has an influence on the necessary appli	incoming MKT (rnext_key), respectively, for a
	cation-level measures to provide a	segment that is sent on the connection. Key
	certain level of security.<vspace />	material must be provided in a way that is
	Implementation: via GET_AUTH.SCTP.<vspace />	compatible with both <xref target="RFC4895"
	Implementation over TCP: With SCTP, this allows	format="default"/> and <xref target="RFC5925"
	to obtain key_id and a chunk list.	format="default"/>.</t>
	With TCP, this allows to obtain current_key and	<t>
	rnext_key from a previously received segment.	Implementation over UDP: not possible. (UDP does
	Key material must be provided in a way that is c	not offer authentication.)</t>
	ompatible with both <xref target="RFC4895"/> and <xref target="RFC5925"/>.<vspac	<t/>
	e />	</li>
	Implementation over UDP: not possible (UDP does	<li>
	not offer authentication).<vspace />	<t>Obtain authentication information</t>
	<vspace blankLines='1'/>	<t>
	</t>	Protocols: SCTP</t>
	<t>Reset Stream<vspace />	<t>
	Protocols: SCTP<vspace />	Functional because authentication decisions
	Automatable because using multi-streaming does n	may have been made by the peer, and this has
	ot require application-specific knowledge.<vspace />	an influence on the necessary
	Implementation: see <xref target="nostream"/>.	application-level measures to provide a
	<vspace blankLines='1'/>	certain level of security.</t>
	</t>	<t>
	<t>Notification of Stream Reset<vspace />	Implementation: via GET_AUTH.SCTP.</t>
	Protocols: STCP<vspace />	<t>
	Automatable because using multi-streaming does n	Implementation over TCP: with SCTP, this
	ot require application-specific knowledge.<vspace />	allows obtaining key_id and a chunk list.
	Implementation: see <xref target="nostream"/>.	With TCP, this allows obtaining current_key
	<vspace blankLines='1'/>	and rnext_key from a previously received
	</t>	segment. Key material must be provided in a
	<t>Reset Association<vspace />	way that is compatible with both <xref
	Protocols: SCTP<vspace />	target="RFC4895" format="default"/> and <xref
	Automatable because deciding to reset an associa	target="RFC5925" format="default"/>.</t>
	tion does not require application-specific knowledge.<vspace />	<t>
	Implementation: via RESET_ASSOC.SCTP.<vspace />	Implementation over UDP: not possible. (UDP does
	<vspace blankLines='1'/>	not offer authentication.)</t>
	</t>	<t/>
	<t>Notification of Association Reset<vspace />	</li>
	Protocols: STCP<vspace />	<li>
	Automatable because this notification does not r	<t>Reset Stream</t>
	elate to application-specific knowledge.<vspace />	<t>
	<vspace blankLines='1'/>	Protocols: SCTP</t>
	</t>	<t>
	<t>Add Streams<vspace />	Automatable because using multi-streaming does n
	Protocols: SCTP<vspace />	ot require application-specific knowledge.</t>
	Automatable because using multi-streaming does n	<t>
	ot require application-specific knowledge.<vspace />	Implementation: see <xref target="nostream" form
	Implementation: see <xref target="nostream"/>.	at="default"/>.
	<vspace blankLines='1'/>	</t>
	</t>	<t/>
	<t>Notification of Added Stream<vspace />	</li>
	Protocols: STCP<vspace />	<li>
	Automatable because using multi-streaming does n	<t>Notification of Stream Reset</t>
	ot require application-specific knowledge.<vspace />	<t>
	Implementation: see <xref target="nostream"/>.	Protocols: STCP</t>
	<vspace blankLines='1'/>	<t>
	</t>	Automatable because using multi-streaming does n
	<t>Choose a scheduler to operate between streams of	ot require application-specific knowledge.</t>
	an association<vspace />	<t>
	Protocols: SCTP<vspace />	Implementation: see <xref target="nostream" form
	Optimizing because the scheduling decision requi	at="default"/>.
	res application-specific knowledge.	</t>
	However, if a transport system would not use thi	<t/>
	s, or wrongly configure it on its own, this would only	</li>
	affect the performance of data transfers; the ou	<li>
	tcome would still be correct within the "best effort"	<t>Reset Association</t>
	service model.<vspace />	<t>
	Implementation: using SET_STREAM_SCHEDULER.SCTP.	Protocols: SCTP</t>
	<vspace />	<t>
	Implementation over TCP: do nothing (streams are	Automatable because deciding to reset an associa
	not available in TCP, but no guarantee is	tion does not require application-specific knowledge.</t>
	given that this transport feature has any effect	<t>
	).<vspace />	Implementation: via RESET_ASSOC.SCTP.</t>
	Implementation over UDP: do nothing (streams are	<t/>
	not available in UDP, but no guarantee is	</li>
	given that this transport feature has any effect	<li>
	).<vspace />	<t>Notification of Association Reset</t>
	<vspace blankLines='1'/>	<t>
	</t>	Protocols: STCP</t>
	<t>Configure priority or weight for a scheduler<vspa	<t>
	ce />	Automatable because this notification does not r
	Protocols: SCTP<vspace />	elate to application-specific knowledge.</t>
	Optimizing because the priority or weight requir	<t/>
	es application-specific knowledge.	</li>
	However, if a transport system would not use thi	<li>
	s, or wrongly configure it on its own, this would only	<t>Add Streams</t>
	affect the performance of data transfers; the ou	<t>
	tcome would still be correct within the "best effort"	Protocols: SCTP</t>
	service model.<vspace />	<t>
	Implementation: using CONFIGURE_STREAM_SCHEDULER	Automatable because using multi-streaming does n
	.SCTP.<vspace />	ot require application-specific knowledge.</t>
	Implementation over TCP: do nothing (streams are	<t>
	not available in TCP, but no guarantee is	Implementation: see <xref target="nostream" form
	given that this transport feature has any effect	at="default"/>.
	).<vspace />	</t>
	Implementation over UDP: do nothing (streams are	<t/>
	not available in UDP, but no guarantee is	</li>
	given that this transport feature has any effect	<li>
	).<vspace />	<t>Notification of Added Stream</t>
	<vspace blankLines='1'/>	<t>
	</t>	Protocols: STCP</t>
	<t>Configure send buffer size<vspace />	<t>
	Protocols: SCTP<vspace />	Automatable because using multi-streaming does n
	Automatable because this decision relates to kno	ot require application-specific knowledge.</t>
	wledge about the	<t>
	network and the Operating System, not the applic	Implementation: see <xref target="nostream" form
	ation (see also the	at="default"/>.
	discussion in <xref target="rundry"/>).<vspace /	</t>
	>	<t/>
	<vspace blankLines='1'/>	</li>
	</t>	<li>
	<t>Configure receive buffer (and rwnd) size<vspace /	<t>Choose a scheduler to operate between streams of an association</
	>	t>
	Protocols: SCTP<vspace />	<t>
	Automatable because this decision relates to kno	Protocols: SCTP</t>
	wledge about the network and the	<t>
	Operating System, not the application.<vspace />	Optimizing because the scheduling decision
	<vspace blankLines='1'/>	requires application-specific knowledge.
	</t>	However, if a transport system would not use
	<t>Configure message fragmentation<vspace />	this, or wrongly configure it on its own, this
	Protocols: SCTP<vspace />	would only affect the performance of data
	Automatable because this relates to knowledge ab	transfers; the outcome would still be correct
	out the network and the Operating System,	within the "best effort" service model.</t>
	not the application. Note that this SCTP feature	<t>
	does not control IP-level fragmentation,	Implementation: using SET_STREAM_SCHEDULER.SCTP.
	but decides on fragmentation of messages by SCTP	</t>
	, in the end system.<vspace />	<t>
	Implementation: by always enabling it with CONFI	Implementation over TCP: do nothing (streams
	G_FRAGMENTATION.SCTP and auto-setting the	are not available in TCP, but no guarantee is
	fragmentation size based on network or Operating	given that this transport feature has any
	System conditions.<vspace />	effect).</t>
	<vspace blankLines='1'/>	<t>
	</t>	Implementation over UDP: do nothing (streams
	<t>Configure PMTUD<vspace />	are not available in UDP, but no guarantee is
	Protocols: SCTP<vspace />	given that this transport feature has any
	Automatable because Path MTU Discovery relates t	effect).</t>
	o knowledge about the network, not the	<t/>
	application.<vspace />	</li>
	<vspace blankLines='1'/>	<li>
	</t>	<t>Configure priority or weight for a scheduler</t>
	<t>Configure delayed SACK timer<vspace />	<t>
	Protocols: SCTP<vspace />	Protocols: SCTP</t>
	Automatable because the receiver-side decision t	<t>
	o delay sending SACKs relates to knowledge about the network,	Optimizing because the priority or weight
	not the application (it can be relevant for a se	requires application-specific knowledge.
	nding application to request not to delay the SACK	However, if a transport system would not use
	of a message, but this is a different transport	this, or wrongly configure it on its own, this
	feature).<vspace />	would only affect the performance of data
	<vspace blankLines='1'/>	transfers; the outcome would still be correct
	</t>	within the "best effort" service model.</t>
	<t>Set Cookie life value<vspace />	<t>
	Protocols: SCTP<vspace />	Implementation: using CONFIGURE_STREAM_SCHEDULER
	Functional because it relates to security (possi	.SCTP.</t>
	bly weakened by keeping a cookie very long) versus	<t>
	the time between connection establishment attemp	Implementation over TCP: do nothing (streams
	ts. Knowledge about both issues can be application-specific.<vspace />	are not available in TCP, but no guarantee is
	Implementation over TCP: the closest specified T	given that this transport feature has any
	CP functionality is the cookie in TCP Fast Open; for this, <xref target="RFC7413	effect).</t>
	"/>	<t>
	states that the server "can expire the cookie at	Implementation over UDP: do nothing (streams
	any time to enhance security" and section 4.1.2 describes an	are not available in UDP, but no guarantee is
	example implementation where updating the key on	given that this transport feature has any
	the server side causes the cookie to expire.	effect).</t>
	Alternatively, for implementations that do not s	<t/>
	upport TCP Fast Open, this transport feature could also	</li>
	affect the validity of SYN cookies (see Section	<li>
	3.6 of <xref target="RFC4987"/>).	<t>Configure send buffer size</t>
	<vspace />	<t>
	Implementation over UDP: not possible (UDP does	Protocols: SCTP</t>
	not offer this functionality).<vspace />	<t>
	<vspace blankLines='1'/>	Automatable because this decision relates to
	</t>	knowledge about the network and the Operating
	<t>Set maximum burst<vspace />	System, not the application (see also the
	Protocols: SCTP<vspace />	discussion in <xref target="rundry"
		format="default"/>).</t>
		<t/>
		</li>
		<li>
		<t>Configure receive buffer (and rwnd) size</t>
		<t>
		Protocols: SCTP</t>
		<t>
		Automatable because this decision relates to
		knowledge about the network and the Operating
		System, not the application.</t>
		<t/>
		</li>
		<li>
		<t>Configure message fragmentation</t>
		<t>
		Protocols: SCTP</t>
		<t>
		Automatable because this relates to knowledge
		about the network and the Operating System,
		not the application. Note that this SCTP
		feature does not control IP-level
		fragmentation, but decides on fragmentation of
		messages by SCTP, in the end system.</t>
		<t>
		Implementation: done by always enabling it with
		CONFIG_FRAGMENTATION.SCTP and auto-setting the
		fragmentation size based on network or
		Operating System conditions.</t>
		<t/>
		</li>
		<li>
		<t>Configure PMTUD</t>
		<t>
		Protocols: SCTP</t>
		<t>
		Automatable because Path MTU Discovery relates
		to knowledge about the network, not the
		application.</t>
		<t/>
		</li>
		<li>
		<t>Configure delayed SACK timer</t>
		<t>
		Protocols: SCTP</t>
		<t>
		Automatable because the receiver-side decision
		to delay sending SACKs relates to knowledge
		about the network, not the application (it can
		be relevant for a sending application to
		request not to delay the SACK of a message,
		but this is a different transport
		feature).</t>
		<t/>
		</li>
		<li>
		<t>Set Cookie life value</t>
		<t>
		Protocols: SCTP</t>
		<t>
		Functional because it relates to security
		(possibly weakened by keeping a cookie very
		long) versus the time between connection
		establishment attempts. Knowledge about both
		issues can be application specific.</t>
		<t>
		Implementation over TCP: the closest specified
		TCP functionality is the cookie in TCP Fast
		Open; for this, <xref target="RFC7413"
		format="default"/> states that the server "can
		expire the cookie at any time to enhance
		security", and <xref target="RFC7413" sectionFor
		mat="of"
		section="4.1.2"/> describes an
		example implementation where updating the key
		on the server side causes the cookie to
		expire. Alternatively, for implementations
		that do not support TCP Fast Open, this
		transport feature could also affect the
		validity of SYN cookies (see <xref target="RFC49
		87"
		section="3.6" sectionFormat="of"/>).
		</t>
		<t>
		Implementation over UDP: not possible. (UDP does
		not offer this functionality.)</t>
		<t/>
		</li>
		<li>
		<t>Set maximum burst</t>
		<t>
		Protocols: SCTP</t>
		<t>
	Automatable because it relates to knowledge abou t the network, not the	Automatable because it relates to knowledge abou t the network, not the

	application.<vspace />	application.</t>
	<vspace blankLines='1'/>	<t/>
	</t>	</li>
	<t>Configure size where messages are broken up for p	<li>
	artial delivery<vspace />	<t>Configure size where messages are broken up for partial delivery<
	Protocols: SCTP<vspace />	/t>
	Functional because this is closely tied to prope	<t>
	rties of the data that an application	Protocols: SCTP</t>
	sends or expects to receive.<vspace />	<t>
	Implementation over TCP: not possible (TCP does	Functional because this is closely tied to
	not offer identification of message boundaries).<vspace />	properties of the data that an application
	Implementation over UDP: not possible (UDP does	sends or expects to receive.</t>
	not fragment messages).<vspace />	<t>
	<vspace blankLines='1'/>	Implementation over TCP: not possible. (TCP does
	</t>	not offer identification of message boundaries.)</t>
	<t>Disable checksum when sending<vspace />	<t>
	Protocols: UDP<vspace />	Implementation over UDP: not possible. (UDP does
	Functional because application-specific knowledg	not fragment messages.)</t>
	e is necessary to decide whether	<t/>
	it can be acceptable to lose data integrity with	</li>
	respect to random corruption.<vspace />	<li>
	Implementation: via SET_CHECKSUM_ENABLED.UDP.<vs	<t>Disable checksum when sending</t>
	pace />	<t>
	Implementation over TCP: do nothing (TCP does no	Protocols: UDP</t>
	t offer to disable the checksum, but	<t>
	transmitting data with an intact checksum will n	Functional because application-specific
	ot yield a semantically wrong result).	knowledge is necessary to decide whether
	<vspace blankLines='1'/>	it can be acceptable to lose data integrity
	</t>	with respect to random corruption.</t>
	<t>Disable checksum requirement when receiving<vspac	<t>
	e />	Implementation: via SET_CHECKSUM_ENABLED.UDP.</t
	Protocols: UDP<vspace />	>
	Functional because application-specific knowledg	<t>
	e is necessary to decide whether	Implementation over TCP: do nothing (TCP does
	it can be acceptable to lose data integrity with	not offer to disable the checksum, but
	respect to random corruption.<vspace />	transmitting data with an intact checksum will
	Implementation: via SET_CHECKSUM_REQUIRED.UDP.<v	not yield a semantically wrong result).
	space />	</t>
	Implementation over TCP: do nothing (TCP does no	<t/>
	t offer to disable the checksum, but	</li>
	transmitting data with an intact checksum will n	<li>
	ot yield a semantically wrong result).	<t>Disable checksum requirement when receiving</t>
	<vspace blankLines='1'/>	<t>
	</t>	Protocols: UDP</t>
	<t>Specify checksum coverage used by the sender<vspa	<t>
	ce />	Functional because application-specific
	Protocols: UDP-Lite<vspace />	knowledge is necessary to decide whether
	Functional because application-specific knowledg	it can be acceptable to lose data
	e is necessary to decide for which	integrity with respect to random
	parts of the data it can be acceptable to lose d	corruption.</t>
	ata integrity with respect to random corruption.<vspace />	<t>
	Implementation: via SET_CHECKSUM_COVERAGE.UDP-Li	Implementation: via SET_CHECKSUM_REQUIRED.UDP.</
	te.<vspace />	t>
	Implementation over TCP: do nothing (TCP does no	<t>
	t offer to limit the checksum length, but	Implementation over TCP: do nothing (TCP does
	transmitting data with an intact checksum will n	not offer to disable the checksum, but
	ot yield a semantically wrong result).<vspace />	transmitting data with an intact checksum will
	Implementation over UDP: if checksum coverage is	not yield a semantically wrong result).
	set to cover payload data, do nothing.	</t>
	Else, either do nothing (transmitting data with	<t/>
	an intact checksum	</li>
	will not yield a semantically wrong result), or	<li>
	use the transport feature "Disable checksum	<t>Specify checksum coverage used by the sender</t>
	when sending".	<t>
	<vspace blankLines='1'/>	Protocols: UDP-Lite</t>
	</t>	<t>
	<t>Specify minimum checksum coverage required by rec	Functional because application-specific
	eiver<vspace />	knowledge is necessary to decide for which
	Protocols: UDP-Lite<vspace />	parts of the data it can be acceptable to lose
		data integrity with respect to random
		corruption.</t>
		<t>
		Implementation: via SET_CHECKSUM_COVERAGE.UDP-Li
		te.</t>
		<t>
		Implementation over TCP: do nothing (TCP does
		not offer to limit the checksum length, but
		transmitting data with an intact checksum will
		not yield a semantically wrong result).</t>
		<t>
		Implementation over UDP: if checksum coverage
		is set to cover payload data, do nothing.
		Else, either do nothing (transmitting data
		with an intact checksum will not yield a
		semantically wrong result), or use the
		transport feature "Disable checksum when
		sending".
		</t>
		<t/>
		</li>
		<li>
		<t>Specify minimum checksum coverage required by receiver</t>
		<t>
		Protocols: UDP-Lite</t>
		<t>
	Functional because application-specific knowledg e is necessary to decide for which	Functional because application-specific knowledg e is necessary to decide for which

	parts of the data it can be acceptable to lose d	parts of the data it can be acceptable to lose d
	ata integrity with respect to random corruption.<vspace />	ata integrity with respect to random corruption.</t>
	Implementation: via SET_MIN_CHECKSUM_COVERAGE.UD	<t>
	P-Lite.<vspace />	Implementation: via SET_MIN_CHECKSUM_COVERAGE.UD
	Implementation over TCP: do nothing (TCP does no	P-Lite.</t>
	t offer to limit the checksum length, but	<t>
	transmitting data with an intact checksum will n	Implementation over TCP: do nothing (TCP does
	ot yield a semantically wrong result).<vspace />	not offer to limit the checksum length, but
	Implementation over UDP: if checksum coverage is	transmitting data with an intact checksum will
	set to cover payload data, do nothing.	not yield a semantically wrong result).</t>
	Else, either do nothing (transmitting data with	<t>
	an intact checksum	Implementation over UDP: if checksum coverage
	will not yield a semantically wrong result), or	is set to cover payload data, do nothing.
	use the transport feature "Disable checksum	Else, either do nothing (transmitting data
		with an intact checksum will not yield a
		semantically wrong result), or use the
		transport feature "Disable checksum
	requirement when receiving".	requirement when receiving".

	<vspace blankLines='1'/>	</t>
	</t>	<t/>
	<t>Specify DF field <vspace />	</li>
	Protocols: UDP(-Lite)<vspace />	<li>
	Optimizing because the DF field can be used to c	<t>Specify DF field </t>
	arry out Path MTU Discovery, which can	<t>
	lead an application to choose message sizes that	Protocols: UDP(-Lite)</t>
	can be transmitted more efficiently.<vspace />	<t>
	Implementation: via MAINTENANCE.SET_DF.UDP(-Lite	Optimizing because the DF field can be used to
	) and SEND_FAILURE.UDP(-Lite).<vspace />	carry out Path MTU Discovery, which can lead
	Implementation over TCP: do nothing (with TCP, t	an application to choose message sizes that
	he sending application is not in control	can be transmitted more efficiently.</t>
	of transport message sizes, making this function	<t>
	ality irrelevant).	Implementation: via MAINTENANCE.SET_DF.UDP(-Lite
	<vspace blankLines='1'/>	) and SEND_FAILURE.UDP(-Lite).</t>
	</t>	<t>
		Implementation over TCP: do nothing (with TCP,
	<t>Get max. transport-message size that may be sent	the sending application is not in control of
	using a non-fragmented IP packet from the configured interface<vspace />	transport message sizes, making this
	Protocols: UDP(-Lite)<vspace />	functionality irrelevant).
	Optimizing because this can lead an application	</t>
	to choose message sizes that can be transmitted more efficiently.<vspace />	<t/>
	Implementation over TCP: do nothing (this inform	</li>
	ation is not available with TCP).<vspace />	<li>
	<vspace blankLines='1'/>	<t>Get max. transport-message size that may be sent using a non-frag
	</t>	mented IP packet from the configured interface</t>
	<t>Get max. transport-message size that may be recei	<t>
	ved from the configured interface<vspace />	Protocols: UDP(-Lite)</t>
	Protocols: UDP(-Lite)<vspace />	<t>
	Optimizing because this can, for example, influe	Optimizing because this can lead an
	nce an application's memory management.<vspace />	application to choose message sizes that can
	Implementation over TCP: do nothing (this inform	be transmitted more efficiently.</t>
	ation is not available with TCP).<vspace />	<t>
	<vspace blankLines='1'/>	Implementation over TCP: do nothing (this inform
	</t>	ation is not available with TCP).</t>
	<t>Specify TTL/Hop count field<vspace />	<t/>
	Protocols: UDP(-Lite)<vspace />	</li>
	Automatable because a transport system can use a	<li>
	large enough system default to avoid communication failures.	<t>Get max. transport-message size that may be received from the con
	Allowing an application to configure it differen	figured interface</t>
	tly can produce notifications of ICMP error message arrivals	<t>
	that yield information which only relates to kno	Protocols: UDP(-Lite)</t>
	wledge about the network, not the application.<vspace />	<t>
	<vspace blankLines='1'/>	Optimizing because this can, for example,
	</t>	influence an application's memory
	<t>Obtain TTL/Hop count field<vspace />	management.</t>
	Protocols: UDP(-Lite)<vspace />	<t>
	Automatable because the TTL/Hop count field rela	Implementation over TCP: do nothing (this inform
	tes to knowledge about the network, not the application.<vspace />	ation is not available with TCP).</t>
	<vspace blankLines='1'/>	<t/>
	</t>	</li>
	<t>Specify ECN field<vspace />	<li>
	Protocols: UDP(-Lite)<vspace />	<t>Specify TTL/Hop count field</t>
	Automatable because the ECN field relates to kno	<t>
	wledge about the network, not the application.<vspace />	Protocols: UDP(-Lite)</t>
	<vspace blankLines='1'/>	<t>
	</t>	Automatable because a transport system can use
	<t>Obtain ECN field<vspace />	a large enough system default to avoid
	Protocols: UDP(-Lite)<vspace />	communication failures. Allowing an
	Optimizing because this information can be used	application to configure it differently can
	by an application to better carry out congestion control (this is	produce notifications of ICMP error message
	relevant when choosing a data transmission trans	arrivals that yield information that only
	port service that does not already do congestion control).<vspace />	relates to knowledge about the network, not
	Implementation over TCP: do nothing (this inform	the application.</t>
	ation is not available with TCP).<vspace />	<t/>
	<vspace blankLines='1'/>	</li>
	</t>	<li>
	<t>Specify IP Options<vspace />	<t>Obtain TTL/Hop count field</t>
	Protocols: UDP(-Lite)<vspace />	<t>
	Automatable because IP Options relate to knowled	Protocols: UDP(-Lite)</t>
	ge about the network, not the application.<vspace />	<t>
	<vspace blankLines='1'/>	Automatable because the TTL/Hop count field rela
	</t>	tes to knowledge about the network, not the application.</t>
	<t>Obtain IP Options<vspace />	<t/>
	Protocols: UDP(-Lite)<vspace />	</li>
	Automatable because IP Options relate to knowled	<li>
	ge about the network, not the application.<vspace />	<t>Specify ECN field</t>
	<vspace blankLines='1'/>	<t>
	</t>	Protocols: UDP(-Lite)</t>
	<t>Enable and configure a "Low Extra Delay Backgroun	<t>
	d Transfer"<vspace />	Automatable because the ECN field relates to kno
	Protocols: A protocol implementing the LEDBAT co	wledge about the network, not the application.</t>
	ngestion control mechanism<vspace />	<t/>
	Optimizing because whether this feature is appro	</li>
	priate or not depends on	<li>
	application-specific knowledge. However, wrongly	<t>Obtain ECN field</t>
	using this will only	<t>
	affect the speed of data transfers (albeit inclu	Protocols: UDP(-Lite)</t>
	ding other transfers that may compete	<t>
	with the transport system's transfer in the netw	Optimizing because this information can be
	ork),	used by an application to better carry out
	so it is still correct within the "best effort"	congestion control (this is relevant when
	service model.<vspace />	choosing a data transmission Transport Service
	Implementation: via CONFIGURE.LEDBAT and/or SET_	that does not already do congestion
	DSCP.TCP / SET_DSCP.SCTP / SET_DSCP.UDP(-Lite) <xref target="LBE-draft"/>.<vspac	control).</t>
	e />	<t>
	Implementation over TCP: do nothing (TCP does no	Implementation over TCP: do nothing (this inform
	t support LEDBAT congestion control, but	ation is not available with TCP).</t>
	not implementing this functionality will not yie	<t/>
	ld a semantically wrong behavior).<vspace />	</li>
	Implementation over UDP: do nothing (UDP does no	<li>
	t offer congestion control).<vspace />	<t>Specify IP Options</t>
	<vspace blankLines='1'/>	<t>
	</t>	Protocols: UDP(-Lite)</t>
		<t>
	</list></t>	Automatable because IP Options relate to
		knowledge about the network, not the
	<t>TERMINATION:<vspace />	application.</t>
		<t/>
	<list style="symbols">	</li>
	<t>Close after reliably delivering all remaining dat	<li>
	a, causing an event informing the application on the other side<vspace />	<t>Obtain IP Options</t>
	Protocols: TCP, SCTP<vspace />	<t>
	Functional because the notion of a connection is	Protocols: UDP(-Lite)</t>
	often reflected in applications	<t>
	as an expectation to have all outstanding data d	Automatable because IP Options relate to
	elivered and no longer be able	knowledge about the network, not the
	to communicate after a "Close" succeeded,	application.</t>
	with a communication sequence relating to this t	<t/>
	ransport feature that is defined by the	</li>
	application protocol.<vspace />	<li>
	Implementation: via CLOSE.TCP and CLOSE.SCTP.<vs	<t>Enable and configure a "Low Extra Delay Background Transfer"</t>
	pace />	<t>
	Implementation over UDP: not possible (UDP is un	Protocols: a protocol implementing the LEDBAT co
	reliable and hence does not know when	ngestion control mechanism</t>
	all remaining data is delivered; it does also no	<t>
	t offer to cause an event related to	Optimizing because whether this feature is
	closing at the peer).<vspace />	appropriate or not depends on
	<vspace blankLines='1'/>	application-specific knowledge. However,
	</t>	wrongly using this will only affect the speed
	<t>Abort without delivering remaining data, causing	of data transfers (albeit including other
	an event informing the application on the other side<vspace />	transfers that may compete with the transport
	Protocols: TCP, SCTP<vspace />	system's transfer in the network), so it is
	Functional because the notion of a connection is	still correct within the "best effort" service
	often reflected in applications	model.</t>
	as an expectation to potentially not have all ou	<t>
	tstanding data delivered and no longer be able	Implementation: via CONFIGURE.LEDBAT and/or SET_
	to communicate after an "Abort" succeeded. On bo	DSCP.TCP / SET_DSCP.SCTP / SET_DSCP.UDP(-Lite) <xref target="RFC8622" format="de
	th sides of a connection, an application protocol may	fault"/>.</t>
	define a communication sequence relating to this	<t>
	transport feature.<vspace />	Implementation over TCP: do nothing (TCP does
	Implementation: via ABORT.TCP and ABORT.SCTP.<vs	not support LEDBAT congestion control, but not
	pace />	implementing this functionality will not yield
	Implementation over UDP: not possible (UDP does	a semantically wrong behavior).</t>
	not offer to cause an event related	<t>
	to aborting at the peer).<vspace />	Implementation over UDP: do nothing (UDP does no
	<vspace blankLines='1'/>	t offer congestion control).</t>
	</t>	<t/>
	<t>Abort without delivering remaining data, not caus	</li>
	ing an event informing the application on the other side<vspace />	</ul>
	Protocols: UDP(-Lite)<vspace />	<t>TERMINATION:
	Functional because the notion of a connection is
	often reflected in applications
	as an expectation to potentially not have all ou
	tstanding data delivered and no longer be able
	to communicate after an "Abort" succeeded. On bo
	th sides of a connection, an application protocol may
	define a communication sequence relating to this
	transport feature.<vspace />
	Implementation: via ABORT.UDP(-Lite).<vspace />
	Implementation over TCP: stop using the connecti
	on, wait for a timeout.<vspace />
	<vspace blankLines='1'/>
	</t>
	<t>Timeout event when data could not be delivered fo
	r too long<vspace />
	Protocols: TCP, SCTP<vspace />
	Functional because this notifies that potentiall
	y assumed reliable data delivery is no longer provided.<vspace />
	Implementation: via TIMEOUT.TCP and TIMEOUT.SCTP
	.<vspace />
	Implementation over UDP: do nothing (this event
	will not occur with UDP).<vspace />
	<vspace blankLines='1'/>
	</t>

	</list></t>

	</section>


	<section anchor="data-pass3" title="DATA Transfer Related Transp	</t>
	ort Features">	<ul >
		<li>
		<t>Close after reliably delivering all remaining data, causing an
		event informing the application on the other side</t>


	<section anchor="data-sending-pass3" title="Sending Data">	<t>
		Protocols: TCP, SCTP</t>
		<t>
		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 feature that is defined by the
		application protocol.</t>
		<t>
		Implementation: via CLOSE.TCP and CLOSE.SCTP.</t
		>
		<t>
		Implementation over UDP: not possible. (UDP is
		unreliable and hence does not know when all
		remaining data is delivered; it does also not
		offer to cause an event related to closing at
		the peer.)</t>
		<t/>
		</li>
		<li>
		<t>Abort without delivering remaining data, causing an event informi
		ng the application on the other side</t>
		<t>
		Protocols: TCP, SCTP</t>
		<t>
		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. On both sides of a connection, an
		application protocol may define a
		communication sequence relating to this
		transport feature.</t>
		<t>
		Implementation: via ABORT.TCP and ABORT.SCTP.</t
		>
		<t>
		Implementation over UDP: not possible. (UDP
		does not offer to cause an event related to
		aborting at the peer.)</t>
		<t/>
		</li>
		<li>
		<t>Abort without delivering remaining data, not causing an event inf
		orming the application on the other side</t>
		<t>
		Protocols: UDP(-Lite)</t>
		<t>
		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. On both sides of a connection, an
		application protocol may define a
		communication sequence relating to this
		transport feature.</t>
		<t>
		Implementation: via ABORT.UDP(-Lite).</t>
		<t>
		Implementation over TCP: stop using the connecti
		on, wait for a timeout.</t>
		<t/>
		</li>
		<li>
		<t>Timeout event when data could not be delivered for too long</t>
		<t>
		Protocols: TCP, SCTP</t>
		<t>
		Functional because this notifies that
		potentially assumed reliable data delivery is
		no longer provided.</t>
		<t>
		Implementation: via TIMEOUT.TCP and TIMEOUT.SCTP
		.</t>
		<t>
		Implementation over UDP: do nothing (this event
		will not occur with UDP).</t>
		<t/>
		</li>
		</ul>
		</section>
		<section anchor="data-pass3" numbered="true" toc="default">
		<name>DATA-Transfer-Related Transport Features</name>
		<section anchor="data-sending-pass3" numbered="true" toc="default">
		<name>Sending Data</name>
		<ul >
		<li>
		<t>Reliably transfer data, with congestion control</t>
		<t>
		Protocols: TCP, SCTP</t>
		<t>
		Functional because this is closely tied to
		properties of the data that an application
		sends or expects to receive.</t>
		<t>
		Implementation: via SEND.TCP and SEND.SCTP.</t>
		<t>
		Implementation over UDP: not possible. (UDP is u
		nreliable.)</t>
		<t/>
		</li>
		<li>
		<t>Reliably transfer a message, with congestion control</t>
		<t>
		Protocols: SCTP</t>
		<t>
		Functional because this is closely tied to
		properties of the data that an application
		sends or expects to receive.</t>
		<t>
		Implementation: via SEND.SCTP.</t>
		<t>
		Implementation over TCP: via SEND.TCP. With
		SEND.TCP, message boundaries will not be
		identifiable by the receiver, because TCP
		provides a byte-stream service.</t>
		<t>
		Implementation over UDP: not possible. (UDP is u
		nreliable.)</t>
		<t/>
		</li>
		<li>
		<t>Unreliably transfer a message</t>
		<t>
		Protocols: SCTP, UDP(-Lite)</t>
		<t>
		Optimizing because only applications know
		about the time criticality of their
		communication, and reliably transferring a
		message is never incorrect for the receiver of
		a potentially unreliable data transfer, it is
		just slower.</t>
		<t>
		CHANGED FROM RFC 8303. This differs from the 2
		automatable transport features below in that
		it leaves the choice of congestion control
		open.</t>
		<t>
		Implementation: via SEND.SCTP or SEND.UDP(-Lite)
		.</t>
		<t>
		Implementation over TCP: use SEND.TCP. With
		SEND.TCP, messages will be sent reliably, and
		message boundaries will not be identifiable by
		the receiver.</t>
		<t/>
		</li>
		<li>
		<t>Unreliably transfer a message, with congestion control</t>
		<t>
		Protocols: SCTP</t>
		<t>
		Automatable because congestion control relates t
		o knowledge about the network, not the application.</t>
		<t/>
		</li>
		<li>
		<t>Unreliably transfer a message, without congestion control</t>
		<t>
		Protocols: UDP(-Lite)</t>
		<t>
		Automatable because congestion control relates t
		o knowledge about the network, not the application.</t>
		<t/>
		</li>
		<li>
		<t>Configurable Message Reliability</t>
		<t>
		Protocols: SCTP</t>
		<t>
		Optimizing because only applications know
		about the time criticality of their
		communication, and reliably transferring a
		message is never incorrect for the receiver of
		a potentially unreliable data transfer, it is
		just slower.</t>
		<t>
		Implementation: via SEND.SCTP.</t>


	<t><list style="symbols">	<t>
	<t>Reliably transfer data, with congestion control<v	Implementation over TCP: done by using SEND.TCP
	space />	and
	Protocols: TCP, SCTP<vspace />	ignoring this configuration. Based on the
	Functional because this is closely tied to prope	assumption of the best-effort service model,
	rties of the data that an application	unnecessarily delivering data does not violate
	sends or expects to receive.<vspace />	application expectations. Moreover, it is not
	Implementation: via SEND.TCP and SEND.SCTP.<vspa	possible to associate the requested
	ce />	reliability to a "message" in TCP anyway.</t>
	Implementation over UDP: not possible (UDP is un	<t>
	reliable).<vspace />	Implementation over UDP: not possible. (UDP is u
	<vspace blankLines='1'/>	nreliable.)</t>
	</t>	<t/>
	<t>Reliably transfer a message, with congestion cont	</li>
	rol<vspace />	<li>
	Protocols: SCTP<vspace />	<t>Choice of stream</t>
	Functional because this is closely tied to prope	<t>
	rties of the data that an application	Protocols: SCTP</t>
	sends or expects to receive.<vspace />	<t>
	Implementation: via SEND.SCTP.<vspace />	Automatable because it requires using multiple
	Implementation over TCP: via SEND.TCP. With SEND	streams, but requesting multiple streams in
	.TCP, message	the CONNECTION.ESTABLISHMENT category is
	boundaries will not be identifiable by the recei
	ver, because TCP
	provides a byte stream service.<vspace />
	Implementation over UDP: not possible (UDP is un
	reliable).<vspace />
	<vspace blankLines='1'/>
	</t>
	<t>Unreliably transfer a message<vspace />
	Protocols: SCTP, UDP(-Lite)<vspace />
	Optimizing because only applications know about
	the time criticality of their communication,
	and reliably transfering a message is never inco
	rrect for the receiver of a potentially
	unreliable data transfer, it is just slower.<vsp
	ace />
	CHANGED FROM RFC8303. This differs from the 2 au
	tomatable transport features below in that it leaves the choice
	of congestion control open.<vspace />
	Implementation: via SEND.SCTP or SEND.UDP(-Lite)
	.<vspace />
	Implementation over TCP: use SEND.TCP. With SEND
	.TCP, messages will be sent reliably, and
	message boundaries will not be identifiable by t
	he receiver.<vspace />
	<vspace blankLines='1'/>
	</t>
	<t>Unreliably transfer a message, with congestion co
	ntrol<vspace />
	Protocols: SCTP<vspace />
	Automatable because congestion control relates t
	o knowledge about the network, not the application.<vspace />
	<vspace blankLines='1'/>
	</t>
	<t>Unreliably transfer a message, without congestion
	control<vspace />
	Protocols: UDP(-Lite)<vspace />
	Automatable because congestion control relates t
	o knowledge about the network, not the application.<vspace />
	<vspace blankLines='1'/>
	</t>
	<t>Configurable Message Reliability<vspace />
	Protocols: SCTP<vspace />
	Optimizing because only applications know about
	the time criticality of their communication,
	and reliably transfering a message is never inco
	rrect for the receiver of a potentially
	unreliable data transfer, it is just slower.<vsp
	ace />
	Implementation: via SEND.SCTP.<vspace />
	Implementation over TCP: By using SEND.TCP and i
	gnoring this configuration:
	based on the assumption of the best-effort
	service model, unnecessarily delivering data doe
	s
	not violate application expectations. Moreover,
	it is not possible to associate the requested
	reliability to a "message" in TCP anyway.<vspace
	/>
	Implementation over UDP: not possible (UDP is un
	reliable).<vspace />
	<vspace blankLines='1'/>
	</t>
	<t>Choice of stream<vspace />
	Protocols: SCTP<vspace />
	Automatable because it requires using multiple s
	treams, but
	requesting multiple streams in the CONNECTION.ES
	TABLISHMENT category is
	automatable.	automatable.

	Implementation: see <xref target="nostream"/>.	</t>
	<vspace blankLines='1'/>	<t>
	</t>	Implementation: see <xref
	<t>Choice of path (destination address)<vspace />	target="nostream" format="default"/>.
	Protocols: SCTP<vspace />	</t>
		<t/>
		</li>
		<li>
		<t>Choice of path (destination address)</t>
		<t>
		Protocols: SCTP</t>
		<t>
	Automatable because it requires using multiple s ockets, but	Automatable because it requires using multiple s ockets, but
	obtaining multiple sockets in the CONNECTION.EST ABLISHMENT category is	obtaining multiple sockets in the CONNECTION.EST ABLISHMENT category is

	automatable.<vspace />	automatable.</t>
	<vspace blankLines='1'/>	<t/>
	</t>	</li>
	<t>Ordered message delivery (potentially slower than	<li>
	unordered)<vspace />	<t>Ordered message delivery (potentially slower than unordered)</t
	Protocols: SCTP<vspace />	>
	Functional because this is closely tied to prope	<t>
	rties of the data that an application	Protocols: SCTP</t>
	sends or expects to receive.<vspace />	<t>
	Implementation: via SEND.SCTP.<vspace />	Functional because this is closely tied to
	Implementation over TCP: By using SEND.TCP. With	properties of the data that an application
	SEND.TCP, messages will not be identifiable	sends or expects to receive.</t>
	by the receiver.<vspace />	<t>
	Implementation over UDP: not possible (UDP does	Implementation: via SEND.SCTP.</t>
	not offer any guarantees regarding ordering).<vspace />	<t>
	<vspace blankLines='1'/>	Implementation over TCP: done by using
	</t>	SEND.TCP. With SEND.TCP, messages will not be
	<t>Unordered message delivery (potentially faster th	identifiable by the receiver.</t>
	an ordered)<vspace />	<t>
	Protocols: SCTP, UDP(-Lite)<vspace />	Implementation over UDP: not possible. (UDP
		does not offer any guarantees regarding
		ordering.)</t>
		<t/>
		</li>
		<li>
		<t>Unordered message delivery (potentially faster than ordered)</t
		>
		<t>
		Protocols: SCTP, UDP(-Lite)</t>
		<t>
	Functional because this is closely tied to prope rties of the data that an application	Functional because this is closely tied to prope rties of the data that an application

	sends or expects to receive.<vspace />	sends or expects to receive.</t>
	Implementation: via SEND.SCTP.<vspace />	<t>
	Implementation over TCP: By using SEND.TCP and a	Implementation: via SEND.SCTP.</t>
	lways sending data ordered:	<t>
	based on the assumption of the best-effort	Implementation over TCP: done by using
	service model, ordered delivery may just be slow	SEND.TCP and always sending data ordered.
	er and does	Based on the assumption of the best-effort
	not violate application expectations. Moreover,	service model, ordered delivery may just be
	it is not possible to associate the requested	slower and does not violate application
	delivery order to a "message" in TCP anyway.<vsp	expectations. Moreover, it is not possible to
	ace />	associate the requested delivery order to a
	<vspace blankLines='1'/>	"message" in TCP anyway.</t>
	</t>	<t/>
	<t>Request not to bundle messages<vspace />	</li>
	Protocols: SCTP<vspace />	<li>
	Optimizing because this decision depends on know	<t>Request not to bundle messages</t>
	ledge about the size of future data blocks	<t>
	and the delay between them.<vspace />	Protocols: SCTP</t>
	Implementation: via SEND.SCTP.<vspace />	<t>
	Implementation over TCP: By using SEND.TCP and D	Optimizing because this decision depends on
	ISABLE_NAGLE.TCP to disable the Nagle algorithm when	knowledge about the size of future data blocks
	the request is made and enable it again when the	and the delay between them.</t>
	request is no longer made. Note that this	<t>
	is not fully equivalent because it relates to th	Implementation: via SEND.SCTP.</t>
	e time of issuing the request rather than
	a specific message.<vspace />	<t>
	Implementation over UDP: do nothing (UDP never b	Implementation over TCP: done by using SEND.TCP
	undles messages).<vspace />	and
	<vspace blankLines='1'/>	DISABLE_NAGLE.TCP to disable the Nagle
	</t>	algorithm when the request is made and enable
	<t>Specifying a "payload protocol-id" (handed over a	it again when the request is no longer
	s such by the receiver)<vspace />	made. Note that this is not fully equivalent
	Protocols: SCTP<vspace />	because it relates to the time of issuing the
	Functional because it allows to send extra appli	request rather than a specific message.</t>
	cation data with every message, for the sake	<t>
	of identification of data, which by itself is ap	Implementation over UDP: do nothing (UDP never b
	plication-specific.<vspace />	undles messages).</t>
	Implementation: SEND.SCTP.<vspace />	<t/>
	Implementation over TCP: not possible (this func	</li>
	tionality is not available in TCP).<vspace />	<li>
	Implementation over UDP: not possible (this func	<t>Specifying a "payload protocol-id" (handed over as such by the
	tionality is not available in UDP).<vspace />	receiver)</t>
	<vspace blankLines='1'/>	<t>
	</t>	Protocols: SCTP</t>
	<t>Specifying a key id to be used to authenticate a	<t>
	message<vspace />	Functional because it allows sending extra
	Protocols: SCTP<vspace />	application data with every message, for the
	Functional because this has a direct influence o	sake of identification of data, which by
	n security.<vspace />	itself is application specific.</t>
	Implementation: via a parameter in SEND.SCTP.<vs	<t>
	pace />	Implementation: SEND.SCTP.</t>
	Implementation over TCP: This could be emulated	<t>
	by using SET_AUTH.TCP before and after the message is sent.	Implementation over TCP: not possible. (This fun
	Note that this is not fully equivalent because i	ctionality is not available in TCP.)</t>
	t relates to the time of issuing the request rather than	<t>
	a specific message.<vspace />	Implementation over UDP: not possible. (This fun
	Implementation over UDP: not possible (UDP does	ctionality is not available in UDP.)</t>
	not offer authentication).<vspace />	<t/>
	<vspace blankLines='1'/>	</li>
	</t>	<li>
	<t>Request not to delay the acknowledgement (SACK) o	<t>Specifying a key id to be used to authenticate a message</t>
	f a message<vspace />	<t>
	Protocols: SCTP<vspace />	Protocols: SCTP</t>
		<t>
		Functional because this has a direct influence o
		n security.</t>
		<t>
		Implementation: via a parameter in SEND.SCTP.</t
		>
		<t>
		Implementation over TCP: this could be
		emulated by using SET_AUTH.TCP before and
		after the message is sent. Note that this is
		not fully equivalent because it relates to the
		time of issuing the request rather than a
		specific message.</t>
		<t>
		Implementation over UDP: not possible. (UDP does
		not offer authentication.)</t>
		<t/>
		</li>
		<li>
		<t>Request not to delay the acknowledgement (SACK) of a message</t
		>
		<t>
		Protocols: SCTP</t>
		<t>
	Optimizing because only an application knows for which message it wants to quickly be informed	Optimizing because only an application knows for which message it wants to quickly be informed

	about success / failure of its delivery.<vspace	about success/failure of its delivery.</t>
	/>	<t>
	Implementation over TCP: do nothing (TCP does no	Implementation over TCP: do nothing (TCP does
	t offer this functionality, but ignoring	not offer this functionality, but ignoring
	this request from the application will not yield	this request from the application will not
	a semantically wrong behavior).<vspace />	yield a semantically wrong behavior).</t>
		<t>
	Implementation over UDP: do nothing (UDP does no t offer this functionality, but ignoring	Implementation over UDP: do nothing (UDP does no t offer this functionality, but ignoring

	this request from the application will not yield	this request from the application will not yield
	a semantically wrong behavior).<vspace />	a semantically wrong behavior).</t>
	<vspace blankLines='1'/>	<t/>
	</t>	</li>
	</list></t>	</ul>
		</section>
	</section>	<section anchor="data-receiving-pass3" numbered="true" toc="default">
		<name>Receiving Data</name>
	<section anchor="data-receiving-pass3" title="Receiving Data	<ul >
	">	<li>
		<t>Receive data (with no message delimiting)</t>
	<t>	<t>
	<list style="symbols">	Protocols: TCP</t>
	<t>Receive data (with no message delimiting)<vsp	<t>
	ace />	Functional because a transport system must b
	Protocols: TCP<vspace />	e able to send and receive data.</t>
	Functional because a transport system must b	<t>
	e able to send and receive data.<vspace />	Implementation: via RECEIVE.TCP.</t>
	Implementation: via RECEIVE.TCP.<vspace />	<t>
	Implementation over UDP: do nothing (UDP onl y works on messages; these can be handed over,	Implementation over UDP: do nothing (UDP onl y works on messages; these can be handed over,

	the application can still ignore the message	the application can still ignore the message
	boundaries).<vspace />	boundaries).</t>
	<vspace blankLines='1'/>	<t/>
	</t>	</li>
	<t>Receive a message<vspace />	<li>
	Protocols: SCTP, UDP(-Lite)<vspace />	<t>Receive a message</t>
	Functional because this is closely tied to p	<t>
	roperties of the data that an application	Protocols: SCTP, UDP(-Lite)</t>
	sends or expects to receive.<vspace />	<t>
	Implementation: via RECEIVE.SCTP and RECEIVE	Functional because this is closely tied to
	.UDP(-Lite).<vspace />	properties of the data that an application
	Implementation over TCP: not possible (TCP d	sends or expects to receive.</t>
	oes not support identification of message boundaries).<vspace />	<t>
	<vspace blankLines='1'/>	Implementation: via RECEIVE.SCTP and RECEIVE
	</t>	.UDP(-Lite).</t>
	<t>Choice of stream to receive from<vspace />	<t>
	Protocols: SCTP<vspace />	Implementation over TCP: not possible. (TCP
		does not support identification of message boundaries.)</t>
		<t/>
		</li>
		<li>
		<t>Choice of stream to receive from</t>
		<t>
		Protocols: SCTP</t>
		<t>
	Automatable because it requires using multip le streams, but	Automatable because it requires using multip le streams, but
	requesting multiple streams in the CONNECTIO N.ESTABLISHMENT category is	requesting multiple streams in the CONNECTIO N.ESTABLISHMENT category is

	automatable.<vspace />	automatable.</t>
	Implementation: see <xref target="nostream"/	<t>
	>.	Implementation: see <xref target="nostream"
	<vspace blankLines='1'/>	format="default"/>.
	</t>	</t>
	<t>Information about partial message arrival<vsp	<t/>
	ace />	</li>
	Protocols: SCTP<vspace />	<li>
	Functional because this is closely tied to p	<t>Information about partial message arrival</t>
	roperties of the data that an application	<t>
	sends or expects to receive.<vspace />	Protocols: SCTP</t>
	Implementation: via RECEIVE.SCTP.<vspace />	<t>
	Implementation over TCP: do nothing (this in	Functional because this is closely tied to
	formation is not available with TCP).<vspace />	properties of the data that an application
	Implementation over UDP: do nothing (this in	sends or expects to receive.</t>
	formation is not available with UDP).<vspace />	<t>
	<vspace blankLines='1'/>	Implementation: via RECEIVE.SCTP.</t>
	</t>	<t>
	</list>	Implementation over TCP: do nothing (this
	</t>	information is not available with
	</section>	TCP).</t>
		<t>
	<section anchor="data-errors-pass3" title="Errors">	Implementation over UDP: do nothing (this in
	<t>This section describes sending failures that are asso	formation is not available with UDP).</t>
	ciated with a	<t/>
	specific call to in the "Sending Data" category (<xr	</li>
	ef target="data-sending-pass3"/>).</t>	</ul>
		</section>
	<t>	<section anchor="data-errors-pass3" numbered="true" toc="default">
	<list style="symbols">	<name>Errors</name>
	<t>Notification of send failures<vspace />	<t>This section describes sending failures that are associated with
	Protocols: SCTP, UDP(-Lite)<vspace />	a specific call to in the "Sending Data" category (<xref
	Functional because this notifies that potent	target="data-sending-pass3" format="default"/>).</t>
	ially assumed reliable data delivery is no longer provided.<vspace />	<ul >
	CHANGED FROM RFC8303. This differs from the	<li>
	2 automatable transport features below in that it does not distinugish between	<t>Notification of send failures</t>
	unsent and unacknowledged messages.<vspace /	<t>
	>	Protocols: SCTP, UDP(-Lite)</t>
	Implementation: via SENDFAILURE-EVENT.SCTP a	<t>
	nd SEND_FAILURE.UDP(-Lite).<vspace />	Functional because this notifies that
	Implementation over TCP: do nothing (this no	potentially assumed reliable data delivery
	tification is not available and will therefore not occur with TCP).<vspace />	is no longer provided.</t>
	<vspace blankLines='1'/>	<t>
	</t>	CHANGED FROM RFC 8303. This differs from
	<t>Notification of an unsent (part of a) message	the 2 automatable transport features below
	<vspace />	in that it does not distinguish between
	Protocols: SCTP, UDP(-Lite)<vspace />	unsent and unacknowledged messages.</t>
	Automatable because the distinction between	<t>
	unsent and unacknowledged does not relate to application-specific knowledge. <vs	Implementation: via SENDFAILURE-EVENT.SCTP a
	pace />	nd SEND_FAILURE.UDP(-Lite).</t>
	<vspace blankLines='1'/>	<t>
	</t>	Implementation over TCP: do nothing (this
	<t>Notification of an unacknowledged (part of a)	notification is not available and will
	message<vspace />	therefore not occur with TCP).</t>
	Protocols: SCTP<vspace />	<t/>
	Automatable because the distinction between	</li>
	unsent and unacknowledged does not relate to application-specific knowledge. <vs	<li>
	pace />	<t>Notification of an unsent (part of a) message</t>
	<vspace blankLines='1'/>	<t>
	</t>	Protocols: SCTP, UDP(-Lite)</t>
	<t>Notification that the stack has no more user	<t>
	data to send<vspace />	Automatable because the distinction
	Protocols: SCTP<vspace />	between unsent and unacknowledged does not
	Optimizing because reacting to this notifica	relate to application-specific
	tion requires the application to be involved,	knowledge. </t>
	and ensuring that the stack does not run dry	<t/>
	of data (for too long) can improve performance.<vspace />	</li>
	Implementation over TCP: do nothing (see the	<li>
	discussion in <xref target="rundry"/>).<vspace />	<t>Notification of an unacknowledged (part of a) message</t>
	Implementation over UDP: do nothing (this no	<t>
	tification is not available and will therefore not occur with UDP).<vspace />	Protocols: SCTP</t>
	<vspace blankLines='1'/>	<t>
	</t>	Automatable because the distinction
	<t>Notification to a receiver that a partial mes	between unsent and unacknowledged does not
	sage delivery has been aborted<vspace />	relate to application-specific
	Protocols: SCTP<vspace />	knowledge. </t>
	Functional because this is closely tied to p	<t/>
	roperties of the data that an application	</li>
	sends or expects to receive.<vspace />	<li>
	Implementation over TCP: do nothing (this no	<t>Notification that the stack has no more user data to send</t>
	tification is not available and will therefore not occur with TCP).<vspace />	<t>
	Implementation over UDP: do nothing (this no	Protocols: SCTP</t>
	tification is not available and will therefore not occur with UDP).<vspace />	<t>
	<vspace blankLines='1'/>	Optimizing because reacting to this
	</t>	notification requires the application to
	</list>	be involved, and ensuring that the stack
	</t>	does not run dry of data (for too long)
	</section>	can improve performance.</t>
		<t>
	</section>	Implementation over TCP: do nothing (see
		the discussion in <xref target="rundry"
	</section>	format="default"/>).</t>
		<t>
	<section title="Revision information">	Implementation over UDP: do nothing (this
	<t> XXX RFC-Ed please remove this section prior to publication.</t	notification is not available and will
	>	therefore not occur with UDP).</t>
		<t/>
	<t>-02: implementation suggestions added, discussion section added,	</li>
	terminology extended, DELETED category removed,	<li>
	various other fixes; list of Transport Features adjusted to -01	<t>Notification to a receiver that a partial message delivery
	version of	has been aborted</t>
	<xref target="RFC8303"/> except that MPTCP is not included.</t>	<t>
		Protocols: SCTP</t>
	<t>-03: updated to be consistent with -02 version of <xref target="R	<t>
	FC8303"/>.</t>	Functional because this is closely tied to
		properties of the data that an application
	<t>-04: updated to be consistent with -03 version of <xref target="R	sends or expects to receive.</t>
	FC8303"/>.	<t>
	Reorganized document, rewrote intro and conclusion, and made a first	Implementation over TCP: do nothing (this
	stab at creating a real "minimal set".</t>	notification is not available and will
		therefore not occur with TCP).</t>
	<t>-05: updated to be consistent with -05 version of <xref target="R	<t>
	FC8303"/> (minor changes). Fixed a mistake regarding Cookie Life value. Exclusio	Implementation over UDP: do nothing (this no
	n of security related transport features (to be covered in a separate document).	tification is not available and will therefore not occur with UDP).</t>
	Reorganized the document (now begins with the minset, derivation is in the appe	<t/>
	ndix). First stab at an abstract API for the minset.</t>	</li>
		</ul>
	<t>draft-ietf-taps-minset-00: updated to be consistent with -08 vers	</section>
	ion of <xref target="RFC8303"/> ("obtain message delivery number" was removed, a	</section>
	s this has also been removed in <xref target="RFC8303"/> because it was a mistak	</section>
	e in RFC4960. This led to the removal of two more transport features that were o
	nly designated as functional because they affected "obtain message delivery numb
	er"). Fall-back to UDP incorporated (this was requested at IETF-99); this also a
	ffected the transport feature "Choice between unordered (potentially faster) or
	ordered delivery of messages" because this is a boolean which is always true for
	one fall-back protocol, and always false for the other one. This was therefore
	now divided into two features, one for ordered, one for unordered delivery. The
	word "reliably" was added to the transport features "Hand over a message to reli
	ably transfer (possibly multiple times) before connection establishment" and "Ha
	nd over a message to reliably transfer during connection establishment" to make
	it clearer why this is not supported by UDP. Clarified that the "minset abstract
	interface" is not proposing a specific API for all TAPS systems to implement, b
	ut it is just a way to describe the minimum set. Author order changed.
	</t>

	<t>WG -01: "fall-back to" (TCP or UDP) replaced (mostly with "implem
	entation over"). References to post-sockets removed (these were statments that a
	ssumed that post-sockets requires two-sided implementation). Replaced "flow" wit
	h "TAPS Connection" and "frame" with "message" to avoid introducing new terminol
	ogy. Made sections 3 and 4 in line with the categorization that is already used
	in the appendix and <xref target="RFC8303"/>, and changed style of section 4 to
	be even shorter and less interface-like. Updated reference draft-ietf-tsvwg-sctp
	-ndata to RFC8260.
	</t>


	<t>WG -02: rephrased "the TAPS system" and "TAPS connection" etc. to	<section anchor="Acknowledgements" numbered="false" toc="default">
	more generally talk about transport after the intro (mostly replacing "TAPS sys	<name>Acknowledgements</name>
	tem" with "transport system" and "TAPS connection" with "connection". Merged sec	<t>The authors would like to thank all the participants of the TAPS
	tions 3 and 4 to form a new section 3.	Working Group and the NEAT and MAMI research projects for valuable input
	</t>	to this document. We especially thank <contact fullname="Michael
	<t>WG -03: updated sentence referencing <xref target="I-D.ietf-taps-	Tüxen"/> for help with connection establishment/teardown,
	transport-security"/> to say that "the minimum security requirements for a taps	<contact fullname="Gorry Fairhurst"/> for his suggestions regarding
	system are discussed in a separate security document", wrote "example" in the pa	fragmentation and packet sizes, and <contact fullname="Spencer Dawkins"/>
	ragraph introducing the decision tree. Removed reference draft-grinnemo-taps-he-	for his extremely detailed and constructive review. This work has
	03 and the sentence that referred to it.	received funding from the European Union's Horizon 2020 research and
	</t>	innovation program under grant agreement No. 644334 (NEAT).
	<t>WG -04: addressed comments from Theresa Enghardt and Tommy Pauly.
	As part of that, removed "TAPS" as a term everywhere (abstract, intro, ..).
	</t>
	<t>WG -05: addressed comments from Spencer Dawkins.
	</t>
	<t>WG -06: Fixed nits.
	</t>
	<t>WG -07: Addressed Genart comments from Robert Sparks.
	</t>
	<t>WG -08: Addressed one more Genart comment from Robert Sparks.
	</t>
	<t>WG -09: Addressed comments from Mirja Kuehlewind, Alvaro Retana,
	Ben Campbell, Benjamin Kaduk and Eric Rescorla.
	</t>
	<t>WG -10: Addressed comments from Benjamin Kaduk and Eric Rescorla.
	</t>
	<t>WG -11: Addressed comments from Alissa Cooper.
	</t>


	</section>	</t>
		</section>


	</back>	</back>
	</rfc>	</rfc>

End of changes. 118 change blocks.
	3028 lines changed or deleted	2930 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/