draft-ietf-taps-transports-usage-01.txt		draft-ietf-taps-transports-usage-02.txt
	TAPS M. Welzl		TAPS M. Welzl
	Internet-Draft University of Oslo		Internet-Draft University of Oslo
	Intended status: Informational M. Tuexen		Intended status: Informational M. Tuexen
	Expires: January 9, 2017 Muenster Univ. of Appl. Sciences		Expires: May 4, 2017 Muenster Univ. of Appl. Sciences
	N. Khademi		N. Khademi
	University of Oslo		University of Oslo
	July 8, 2016		October 31, 2016
	On the Usage of Transport Service Features Provided by IETF Transport		On the Usage of Transport Service Features Provided by IETF Transport
	Protocols		Protocols
	draft-ietf-taps-transports-usage-01		draft-ietf-taps-transports-usage-02
	Abstract		Abstract
	This document describes how transport protocols expose services to		This document describes how transport protocols expose services to
	applications and how an application can configure and use the		applications and how an application can configure and use the
	features of a transport service.		features of a transport service.
	Status of This Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 9, 2017.		This Internet-Draft will expire on May 4, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Pass 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Pass 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Primitives Provided by TCP . . . . . . . . . . . . . . . 4		3.1. Primitives Provided by TCP . . . . . . . . . . . . . . . . 5
	3.1.1. Excluded Primitives . . . . . . . . . . . . . . . . . 7		3.1.1. Excluded Primitives or Parameters . . . . . . . . . . 7
	3.2. Primitives Provided by MPTCP . . . . . . . . . . . . . . 8		3.2. Primitives Provided by MPTCP . . . . . . . . . . . . . . . 8
	3.3. Primitives Provided by SCTP . . . . . . . . . . . . . . . 9		3.3. Primitives Provided by SCTP . . . . . . . . . . . . . . . 9
	3.3.1. Excluded Primitives . . . . . . . . . . . . . . . . . 12		3.3.1. Excluded Primitives or Parameters . . . . . . . . . . 13
	4. Pass 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12		3.4. Primitives Provided by UDP and UDP-Lite . . . . . . . . . 14
	4.1. CONNECTION Related Primitives . . . . . . . . . . . . . . 13		4. Pass 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	4.2. DATA Transfer Related Primitives . . . . . . . . . . . . 19		4.1. CONNECTION Related Primitives . . . . . . . . . . . . . . 14
	5. Pass 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21		4.2. DATA Transfer Related Primitives . . . . . . . . . . . . . 23
	5.1. CONNECTION Related Transport Service Features . . . . . . 21		5. Pass 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	5.2. DATA Transfer Related Transport Service Features . . . . 25		5.1. CONNECTION Related Transport Service Features . . . . . . 25
	5.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 25		5.2. DATA Transfer Related Transport Service Features . . . . . 30
	5.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 26		5.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . . 30
	5.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . 27		5.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . . 31
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27		5.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . 31
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 27		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27		8. Security Considerations . . . . . . . . . . . . . . . . . . . 32
	9.1. Normative References . . . . . . . . . . . . . . . . . . 27		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
	9.2. Informative References . . . . . . . . . . . . . . . . . 28		9.1. Normative References . . . . . . . . . . . . . . . . . . . 32
	Appendix A. Overview of RFCs used as input for pass 1 . . . . . 29		9.2. Informative References . . . . . . . . . . . . . . . . . . 33
	Appendix B. How to contribute . . . . . . . . . . . . . . . . . 29		Appendix A. Overview of RFCs used as input for pass 1 . . . . . . 35
	Appendix C. Revision information . . . . . . . . . . . . . . . . 31		Appendix B. How to contribute . . . . . . . . . . . . . . . . . . 36
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32		Appendix C. Revision information . . . . . . . . . . . . . . . . 37
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
	1. Terminology		1. Terminology
	Transport Service Feature: a specific end-to-end feature that a		Transport Service Feature: a specific end-to-end feature that a
	transport service provides to its clients. Examples include		transport service provides to its clients. Examples include
	confidentiality, reliable delivery, ordered delivery, message-		confidentiality, reliable delivery, ordered delivery, message-
	versus-stream orientation, etc.		versus-stream orientation, etc.
	Transport Service: a set of transport service features, without an		Transport Service: a set of transport service features, without an
	association to any given framing protocol, which provides a		association to any given framing protocol, which provides a
	complete service to an application.		complete service to an application.
	skipping to change at page 3, line 23 ¶		skipping to change at page 3, line 37 ¶
	endpoints using a transport protocol.		endpoints using a transport protocol.
	Connection: shared state of two or more endpoints that persists		Connection: shared state of two or more endpoints that persists
	across messages that are transmitted between these endpoints.		across messages that are transmitted between these endpoints.
	Primitive: a function call that is used to locally communicate		Primitive: a function call that is used to locally communicate
	between an application and a transport endpoint and is related to		between an application and a transport endpoint and is related to
	one or more Transport Service Features.		one or more Transport Service Features.
	Parameter: a value passed between an application and a transport		Parameter: a value passed between an application and a transport
	protocol by a primitive.		protocol by a primitive.
	Socket: the combination of a destination IP address and a		Socket: the combination of a destination IP address and a
	destination port number.		destination port number.
			Transport Address: the combination of an IP address, transport
			protocol and the port number used by the transport protocol.
	2. Introduction		2. Introduction
	This document presents defined interactions between transport		This document presents defined interactions between transport
	protocols and applications in the form of 'primitives' (function		protocols and applications in the form of 'primitives' (function
	calls). Primitives can be invoked by an application or a transport		calls). Primitives can be invoked by an application or a transport
	protocol; the latter type is called an "event". The list of		protocol; the latter type is called an "event". The list of
	transport service features and primitives in this document is		transport service features and primitives in this document is
	strictly based on the parts of protocol specifications that relate to		strictly based on the parts of protocol specifications that relate to
	what the protocol provides to an application using it and how the		what the protocol provides to an application using it and how the
	skipping to change at page 7, line 35 ¶		skipping to change at page 7, line 46 ¶
	the value of the UTO advertised to the remote TCP peer (default:		the value of the UTO advertised to the remote TCP peer (default:
	system-wide default user timeout); ENABLED (default false) is a		system-wide default user timeout); ENABLED (default false) is a
	boolean-type flag that controls whether the UTO option is enabled		boolean-type flag that controls whether the UTO option is enabled
	for a connection. This applies to both sending and receiving.		for a connection. This applies to both sending and receiving.
	CHANGEABLE is a boolean-type flag (default true) that controls		CHANGEABLE is a boolean-type flag (default true) that controls
	whether the user timeout may be changed based on a UTO option		whether the user timeout may be changed based on a UTO option
	received from the other end of the connection. CHANGEABLE becomes		received from the other end of the connection. CHANGEABLE becomes
	false when an application explicitly sets the user timeout (see		false when an application explicitly sets the user timeout (see
	'send').		'send').
	3.1.1. Excluded Primitives		3.1.1. Excluded Primitives or Parameters
	The 'open' primitive specified in [RFC0793] can be handed optional		The 'open' primitive specified in [RFC0793] can be handed optional
	Precedence or security/compartment information according to		Precedence or security/compartment information according to
	[RFC0793], but this was not included here because it is mostly		[RFC0793], but this was not included here because it is mostly
	irrelevant today, as explained in [RFC7414].		irrelevant today, as explained in [RFC7414].
	The 'status' primitive was not included because [RFC0793] describes		The 'status' primitive was not included because [RFC0793] describes
	this primitive as "implementation dependent" and states that it		this primitive as "implementation dependent" and states that it
	"could be excluded without adverse effect". Moreover, while a data		"could be excluded without adverse effect". Moreover, while a data
	block containing specific information is described, it is also stated		block containing specific information is described, it is also stated
	skipping to change at page 9, line 7 ¶		skipping to change at page 9, line 15 ¶
	send/receive: [RFC6824] states that the sending and receiving of		send/receive: [RFC6824] states that the sending and receiving of
	data does not require any changes to the application when MPTCP is		data does not require any changes to the application when MPTCP is
	being used. The MPTCP-layer will "take one input data stream from		being used. The MPTCP-layer will "take one input data stream from
	an application, and split it into one or more subflows, with		an application, and split it into one or more subflows, with
	sufficient control information to allow it to be reassembled and		sufficient control information to allow it to be reassembled and
	delivered reliably and in order to the recipient application."		delivered reliably and in order to the recipient application."
	The use of the Urgent-Pointer is special in MPTCP and [RFC6824]		The use of the Urgent-Pointer is special in MPTCP and [RFC6824]
	says "a TCP subflow MUST NOT use the Urgent Pointer to interrupt		says "a TCP subflow MUST NOT use the Urgent Pointer to interrupt
	an existing mapping."		an existing mapping."
	address and subflow management:: MPTCP uses different addresses and		address and subflow management: MPTCP uses different addresses and
	allows a host to announce these addresses as part of the protocol.		allows a host to announce these addresses as part of the protocol.
	[RFC6897] says "An application should be able to restrict MPTCP to		[RFC6897] says "An application should be able to restrict MPTCP to
	binding to a given set of addresses." and thus allows applications		binding to a given set of addresses." and thus allows applications
	to limit the set of addresses that are being used by MPTCP.		to limit the set of addresses that are being used by MPTCP.
	Further, "An application should be able to obtain information on		Further, "An application should be able to obtain information on
	the pairs of addresses used by the MPTCP subflows.".		the pairs of addresses used by the MPTCP subflows.".
	3.3. Primitives Provided by SCTP		3.3. Primitives Provided by SCTP
	Section 1.1 of [RFC4960] lists limitations of TCP that SCTP removes.		Section 1.1 of [RFC4960] lists limitations of TCP that SCTP removes.
	skipping to change at page 9, line 31 ¶		skipping to change at page 9, line 39 ¶
	messages, while reliably transferred, do not require to be in order		messages, while reliably transferred, do not require to be in order
	unless the application wants it; 3) multi-homing is supported. In		unless the application wants it; 3) multi-homing is supported. In
	SCTP, connections are called "association" and they can be between		SCTP, connections are called "association" and they can be between
	not only two (as in TCP) but multiple addresses at each endpoint.		not only two (as in TCP) but multiple addresses at each endpoint.
	Section 10 of [RFC4960] further specifies the interaction with the		Section 10 of [RFC4960] further specifies the interaction with the
	application (which RFC [RFC4960] calls the "Upper Layer Protocol"		application (which RFC [RFC4960] calls the "Upper Layer Protocol"
	(ULP)). It is assumed that the Operating System provides a means for		(ULP)). It is assumed that the Operating System provides a means for
	SCTP to asynchronously signal the application; the primitives		SCTP to asynchronously signal the application; the primitives
	representing such signals are called 'events' in this section. Here,		representing such signals are called 'events' in this section. Here,
	we describe the relevant primitives.		we describe the relevant primitives. In addition to the abstract API
			described in Section 10 of [RFC4960], an extension to the socket API
			is described in [RFC6458] covering the functionality of the base
			protocol specified in [RFC4960] and its extensions specified in
			[RFC3758], [RFC4895], and [RFC5061]. For the protocol extensions
			specified in [RFC6525], [RFC6951], [RFC7053], [RFC7496], and
			[RFC7829] the corresponding extensions of the socket API are
			specified in these protocol specifications. The functionality
			exposed to the ULP through this socket API is considered here in
			addition to the abstract API specified in Section 10 of [RFC4960].
	Initialize: Initialize creates a local SCTP instance that it binds		Initialize: Initialize creates a local SCTP instance that it binds
	to a set of local addresses (and, if provided, port number).		to a set of local addresses (and, if provided, port number).
	Initialize needs to be called only once per set of local		Initialize needs to be called only once per set of local
	addresses.		addresses.
	Associate: This creates an association (the SCTP equivalent of a		Associate: This creates an association (the SCTP equivalent of a
	connection) between the local SCTP instance and a remote SCTP		connection) between the local SCTP instance and a remote SCTP
	instance. Most primitives are associated with a specific		instance. Most primitives are associated with a specific
	association, which is assumed to first have been created.		association, which is assumed to first have been created.
	Associate can return a list of destination transport addresses so		Associate can return a list of destination transport addresses so
	that multiple paths can later be used. One of the returned		that multiple paths can later be used. One of the returned
	sockets will be selected by the local endpoint as default primary		sockets will be selected by the local endpoint as default primary
	path for sending SCTP packets to this peer, but this choice can be		path for sending SCTP packets to this peer, but this choice can be
	changed by the application using the list of destination		changed by the application using the list of destination
	addresses. Associate is also given the number of outgoing streams		addresses. Associate is also given the number of outgoing streams
	to request and optionally returns the number of outgoing streams		to request and optionally returns the number of outgoing streams
	negotiated.		negotiated. An optional parameter of 32-bits, the adaptation
			layer indication, can be provided, as specified in [RFC5061]. If
			the extension specified in [RFC4895] is used, the chunk types
			required to be sent authenticated by the peer can be provided.
	Send: This sends a message of a certain length in bytes over an		Send: This sends a message of a certain length in bytes over an
	association. A number can be provided to later refer to the		association. A number can be provided to later refer to the
	correct message when reporting an error, and a stream id is		correct message when reporting an error, and a stream id is
	provided to specify the stream to be used inside an association		provided to specify the stream to be used inside an association
	(we consider this as a mandatory parameter here for simplicity: if		(we consider this as a mandatory parameter here for simplicity: if
	not provided, the stream id defaults to 0). An optional maximum		not provided, the stream id defaults to 0). A condition to
	life time can specify the time after which the message should be		abandon the message can be specified (for example limiting the
	discarded rather than sent. A choice (advisory, i.e. not		number of retransmissions or the lifetime of the user message).
	guaranteed) of the preferred path can be made by providing a		This allows to control the partial reliability extension specified
	socket, and the message can be delivered out-of-order if the		in [RFC3758] and [RFC7496]. An optional maximum life time can
	unordered flag is set. Another advisory flag indicates whether		specify the time after which the message should be discarded
	the application prefers to avoid bundling user data with other		rather than sent. A choice (advisory, i.e. not guaranteed) of the
	outbound DATA chunks (i.e., in the same packet). A payload		preferred path can be made by providing a socket, and the message
			can be delivered out-of-order if the unordered flag is set. An
			advisory flag indicates that the peer should not delay the
			acknowledgement of the user message provided by making use of the
			I-bit specified in [RFC7053]. Another advisory flag indicates
			whether the application prefers to avoid bundling user data with
			other outbound DATA chunks (i.e., in the same packet). A payload
	protocol-id can be provided to pass a value that indicates the		protocol-id can be provided to pass a value that indicates the
	type of payload protocol data to the peer.		type of payload protocol data to the peer. If the extension
			specified in [RFC4895] is used, the key identifier used for
			authenticating the DATA chunks can be provided.
	Receive: Messages are received from an association, and optionally a		Receive: Messages are received from an association, and optionally a
	stream within the association, with their size returned. The		stream within the association, with their size returned. The
	application is notified of the availability of data via a DATA		application is notified of the availability of data via a DATA
	ARRIVE notification. If the sender has included a payload		ARRIVE notification. If the sender has included a payload
	protocol-id, this value is also returned. If the received message		protocol-id, this value is also returned. If the received message
	is only a partial delivery of a whole message, a partial flag will		is only a partial delivery of a whole message, a partial flag will
	indicate so, in which case the stream id and a stream sequence		indicate so, in which case the stream id and a stream sequence
	number are provided to the application.		number are provided to the application. A delivery number lets
			the application detect reordering.
	Shutdown: This primitive gracefully closes an association, reliably		Shutdown: This primitive gracefully closes an association, reliably
	delivering any data that has already been handed over to SCTP. A		delivering any data that has already been handed over to SCTP. A
	return code informs about success or failure of this procedure.		return code informs about success or failure of this procedure.
	Abort: This ungracefully closes an association, by discarding any		Abort: This ungracefully closes an association, by discarding any
	locally queued data and informing the peer that the association		locally queued data and informing the peer that the association
	was aborted. Optionally, an abort reason to be passed to the peer		was aborted. Optionally, an abort reason to be passed to the peer
	may be provided by the application. A return code informs about		may be provided by the application. A return code informs about
	success or failure of this procedure.		success or failure of this procedure.
	skipping to change at page 11, line 10 ¶		skipping to change at page 11, line 36 ¶
	enable/disable heartbeats and optionally specify a heartbeat		enable/disable heartbeats and optionally specify a heartbeat
	frequency as well as requesting a single heartbeat to be carried		frequency as well as requesting a single heartbeat to be carried
	out upon a function call, with a notification about success or		out upon a function call, with a notification about success or
	failure of transmitting the HEARTBEAT chunk to the destination.		failure of transmitting the HEARTBEAT chunk to the destination.
	Set Protocol Parameters: This allows to set values for protocol		Set Protocol Parameters: This allows to set values for protocol
	parameters per association; for some parameters, a setting can be		parameters per association; for some parameters, a setting can be
	made per socket. The set listed in [RFC4960] is: RTO.Initial;		made per socket. The set listed in [RFC4960] is: RTO.Initial;
	RTO.Min; RTO.Max; Max.Burst; RTO.Alpha; RTO.Beta;		RTO.Min; RTO.Max; Max.Burst; RTO.Alpha; RTO.Beta;
	Valid.Cookie.Life; Association.Max.Retrans; Path.Max.Retrans;		Valid.Cookie.Life; Association.Max.Retrans; Path.Max.Retrans;
	Max.Init.Retransmits; HB.interval; HB.Max.Burst.		Max.Init.Retransmits; HB.interval; HB.Max.Burst. In addition to
			these, the Quick Failover Algorithm specified in [RFC7829] can be
			controlled by the PotentiallyFailed.Max.Retrans and
			Primary.Switchover.Max.Retrans parameter. A remote UDP
			encapsulation port can be set for using UDP encapsulation as
			specified in [RFC6951].
	Set Primary: This allows to set a new primary default path for an		Set Primary: This allows to set a new primary default path for an
	association by providing a socket. Optionally, a default source		association by providing a socket. Optionally, a default source
	address to be used in IP datagrams can be provided.		address to be used in IP datagrams can be provided.
			Set / Get Authentication Parameters: This allows an endpoint to add/
			remove key material to/from an association. In addition, the
			chunk types being authenticated can be queried. This is provided
			by the protocol extension defined in [RFC4895].
			Change Local Address / Set Peer Primary: This allows an endpoint to
			add/remove local addresses to/from an association. In addition,
			the peer can be given a hint which address to use as the primary
			address. This is provided by the protocol extension defined in
			[RFC5061].
			Add / Reset Streams, Reset Association: This allows an endpoint to
			add streams to an existing association or or to reset them
			individually. Additionally, the association can be reset. This
			is provided by the protocol extension defined in [RFC6525].
	Status: The 'Status' primitive returns a data block with information		Status: The 'Status' primitive returns a data block with information
	about a specified association, containing: association connection		about a specified association, containing: association connection
	state; socket list; destination transport address reachability		state; socket list; destination transport address reachability
	states; current receiver window size; current congestion window		states; current receiver window size; current congestion window
	sizes; number of unacknowledged DATA chunks; number of DATA chunks		sizes; number of unacknowledged DATA chunks; number of DATA chunks
	pending receipt; primary path; most recent SRTT on primary path;		pending receipt; primary path; most recent SRTT on primary path;
	RTO on primary path; SRTT and RTO on other destination addresses.		RTO on primary path; SRTT and RTO on other destination addresses.
	COMMUNICATION UP notification: When a lost communication to an		COMMUNICATION UP notification: When a lost communication to an
	endpoint is restored or when SCTP becomes ready to send or receive		endpoint is restored or when SCTP becomes ready to send or receive
	user messages, this notification informs the application process		user messages, this notification informs the application process
	about the affected association, the type of event that has		about the affected association, the type of event that has
	occurred, the complete set of sockets of the peer, the maximum		occurred, the complete set of sockets of the peer, the maximum
	number of allowed streams and the inbound stream count (the number		number of allowed streams and the inbound stream count (the number
	of streams the peer endpoint has requested).		of streams the peer endpoint has requested).
	DATA ARRIVE notification: When a message is ready to be retrieved		DATA ARRIVE notification: When a message is ready to be retrieved
	via the Receive primitive, the application is informed by this		via the Receive primitive, the application is informed by this
	notification.		notification.
	SEND FAILURE notification / Receive Unsent Message		SEND FAILURE notification / Receive Unsent Message / Receive
	/ Receive Unacknowledged Message:		Unacknowledged Message: When a message cannot be delivered via an
	When a message cannot be delivered via an association, the sender		association, the sender can be informed about it and learn whether
	can be informed about it and learn whether the message has just		the message has just not been acknowledged or (e.g. in case of
	not been acknowledged or (e.g. in case of lifetime expiry) if it		lifetime expiry) if it has not even been sent.
	has not even been sent.
	NETWORK STATUS CHANGE notification: The NETWORK STATUS CHANGE		NETWORK STATUS CHANGE notification: The NETWORK STATUS CHANGE
	notification informs the application about a socket becoming		notification informs the application about a socket becoming
	active/inactive.		active/inactive.
	COMMUNICATION LOST notification: When SCTP loses communication to an		COMMUNICATION LOST notification: When SCTP loses communication to an
	endpoint (e.g. via Heartbeats or excessive retransmission) or		endpoint (e.g. via Heartbeats or excessive retransmission) or
	detects an abort, this notification informs the application		detects an abort, this notification informs the application
	process of the affected association and the type of event (failure		process of the affected association and the type of event (failure
	OR termination in response to a shutdown or abort request).		OR termination in response to a shutdown or abort request).
	SHUTDOWN COMPLETE notification: When SCTP completes the shutdown		SHUTDOWN COMPLETE notification: When SCTP completes the shutdown
	procedures, this notification is passed to the upper layer,		procedures, this notification is passed to the upper layer,
	informing it about the affected assocation.		informing it about the affected assocation.
	3.3.1. Excluded Primitives		AUTHENICATION notification: When SCTP wants to notify the upper
			layer regarding the key management related to the extension
			defined in [RFC4895], this notification is passed to the upper
			layer.
			ADAPTATION LAYER INDICATION notification: When SCTP completes the
			association setup and the peer provided an adaptation layer
			indication, this is passed to the upper layer. This extension is
			defined in [RFC5061] and [RFC6458].
			STREAM RESET notification: When SCTP completes the procedure for
			resetting streams as specified in [RFC6525], this notification is
			passed to the upper layer, informing it about the result.
			ASSOCIATION RESET notification: When SCTP completes the association
			reset procedure as specified in [RFC6525], this notification is
			passed to the upper layer, informing it about the result.
			STREAM CHANGE notification: When SCTP completes the procedure used
			to increase the number of streams as specified in [RFC6525], this
			notification is passed to the upper layer, informing it about the
			result.
			3.3.1. Excluded Primitives or Parameters
	The 'Receive' primitive can return certain additional information,		The 'Receive' primitive can return certain additional information,
	but this is optional to implement and therefore not considered. With		but this is optional to implement and therefore not considered. With
	a COMMUNICATION LOST notification, some more information may		a COMMUNICATION LOST notification, some more information may
	optionally be passed to the application (e.g., identification to		optionally be passed to the application (e.g., identification to
	retrieve unsent and unacknowledged data). SCTP "can invoke" a		retrieve unsent and unacknowledged data). SCTP "can invoke" a
	COMMUNICATION ERROR notification and "may send" a RESTART		COMMUNICATION ERROR notification and "may send" a RESTART
	notification, making these two notifications optional to implement.		notification, making these two notifications optional to implement.
	The list provided under 'Status' includes "etc", indicating that more		The list provided under 'Status' includes "etc", indicating that more
	information could be provided. The primitive 'Get SRTT Report'		information could be provided. The primitive 'Get SRTT Report'
	returns information that is included in the information that 'Status'		returns information that is included in the information that 'Status'
	provides and is therefore not discussed. Similarly, 'Set Failure		provides and is therefore not discussed. Similarly, 'Set Failure
	Threshold' sets only one out of various possible parameters included		Threshold' sets only one out of various possible parameters included
	in 'Set Protocol Parameters'. The 'Destroy SCTP Instance' API		in 'Set Protocol Parameters'. The 'Destroy SCTP Instance' API
	function was excluded: it erases the SCTP instance that was created		function was excluded: it erases the SCTP instance that was created
	by 'Initialize', but is not a Primitive as defined in this document		by 'Initialize', but is not a Primitive as defined in this document
	because it does not relate to a Transport Service Feature.		because it does not relate to a Transport Service Feature.
			3.4. Primitives Provided by UDP and UDP-Lite
			The primitives provided by UDP and UDP-Lite are described in [FJ16].
	4. Pass 2		4. Pass 2
	This pass categorizes the primitives from pass 1 based on whether		This pass categorizes the primitives from pass 1 based on whether
	they relate to a connection or to data transmission. Primitives are		they relate to a connection or to data transmission. Primitives are
	presented following the nomenclature:		presented following the nomenclature
	"CATEGORY.[SUBCATEGORY].PRIMITIVENAME.PROTOCOL". The CATEGORY can be		"CATEGORY.[SUBCATEGORY].PRIMITIVENAME.PROTOCOL". The CATEGORY can be
	CONNECTION or DATA. Within the CONNECTION category, ESTABLISHMENT,		CONNECTION or DATA. Within the CONNECTION category, ESTABLISHMENT,
	AVAILABILITY, MAINTENANCE and TERMINATION subcategories can be		AVAILABILITY, MAINTENANCE and TERMINATION subcategories can be
	considered. The DATA category does not have any SUBCATEGORY (as of		considered. The DATA category does not have any SUBCATEGORY (as of
	now). A connection is a general protocol-independent concept and		now). The PROTOCOL name "UDP(-Lite)" is used when primitives are
	refers to, e.g., TCP connections (identifiable by a unique pair of IP		equivalent for UDP and UDP-Lite; the PROTOCOL name "TCP" refers to
	addresses and TCP port numbers) as well as SCTP associations		both TCP and MPTCP. We present "connection" as a general protocol-
	(identifiable by multiple IP address and port number pairs).		independent concept and use it to refer to, e.g., TCP connections
			(identifiable by a unique pair of IP addresses and TCP port numbers),
			SCTP associations (identifiable by multiple IP address and port
			number pairs), as well UDP and UDP-Lite connections (identifiable by
			a unique socket pair).
	Some minor details are omitted for the sake of generalization --		Some minor details are omitted for the sake of generalization --
	e.g., SCTP's 'close' [RFC4960] returns success or failure, whereas		e.g., SCTP's 'close' [RFC4960] returns success or failure, whereas
	this is not described in the same way for TCP in [RFC0793], but this		this is not described in the same way for TCP in [RFC0793], but this
	detail plays no significant role for the primitives provided by		detail plays no significant role for the primitives provided by
	either TCP or SCTP.		either TCP or SCTP.
	The TCP 'send' and 'receive' primitives include usage of an "URGENT"		The TCP 'send' and 'receive' primitives include usage of an "URGENT"
	mechanism. This mechanism is required to implement the "synch		mechanism. This mechanism is required to implement the "synch
	signal" used by telnet [RFC0854], but SHOULD NOT be used by new		signal" used by telnet [RFC0854], but SHOULD NOT be used by new
	applications [RFC6093]. Because pass 2 is meant as a basis for the		applications [RFC6093]. Because pass 2 is meant as a basis for the
	creation of TAPS systems, the "URGENT" mechanism is excluded. This		creation of TAPS systems, the "URGENT" mechanism is excluded. This
	also concerns the notification "Urgent pointer advance" in the		also concerns the notification "Urgent pointer advance" in the
	ERROR_REPORT described in Section 4.2.4.1 of [RFC1122].		ERROR_REPORT described in Section 4.2.4.1 of [RFC1122].
	4.1. CONNECTION Related Primitives		4.1. CONNECTION Related Primitives
	ESTABLISHMENT:		ESTABLISHMENT:
	Active creation of a connection from one transport endpoint to one or		Active creation of a connection from one transport endpoint to one or
	more transport endpoints.		more transport endpoints.
			Interfaces to UDP and UDP-Lite allow both connection-oriented and
			connection-less usage of the API [I-D.ietf-tsvwg-rfc5405bis]
	o CONNECT.TCP:		o CONNECT.TCP:
	Pass 1 primitive / event: 'open' (active) or 'open' (passive) with		Pass 1 primitive / event: 'open' (active) or 'open' (passive) with
	socket, followed by 'send'		socket, followed by 'send'
	Parameters: 1 local IP address (optional); 1 destination transport		Parameters: 1 local IP address (optional); 1 destination transport
	address (for active open; else the socket and the local IP address		address (for active open; else the socket and the local IP address
	of the succeeding incoming connection request will be maintained);		of the succeeding incoming connection request will be maintained);
	timeout (optional); options (optional)		timeout (optional); options (optional)
	Comments: If the local IP address is not provided, a default		Comments: If the local IP address is not provided, a default
	choice will automatically be made. The timeout can also be a		choice will automatically be made. The timeout can also be a
	retransmission count. The options are IP options to be used on		retransmission count. The options are IP options to be used on
	all segments of the connection. At least the Source Route option		all segments of the connection. At least the Source Route option
	is mandatory for TCP to provide.		is mandatory for TCP to provide.
	o CONNECT.SCTP:		o CONNECT.SCTP:
	Pass 1 primitive / event: 'initialize', followed by 'associate'		Pass 1 primitive / event: 'initialize', followed by 'associate'
	Parameters: list of local SCTP port number / IP address pairs		Parameters: list of local SCTP port number / IP address pairs
	(initialize); 1 socket; outbound stream count		(initialize); 1 socket; outbound stream count; adaptation layer
			indication; chunk types required to be authenticated
	Returns: socket list		Returns: socket list
	Comments: 'initialize' needs to be called only once per list of		Comments: 'initialize' needs to be called only once per list of
	local SCTP port number / IP address pairs. One socket will		local SCTP port number / IP address pairs. One socket will
	automatically be chosen; it can later be changed in MAINTENANCE.		automatically be chosen; it can later be changed in MAINTENANCE.
	o Disable-MPTCP.MPTCP:		o CONNECT.MPTCP:
	Pass 1 primitive / event: 'open' (active) or 'open' (passive)		This is similar to CONNECT.TCP except for one additional boolean
	Parameters: one boolean value		parameter that allows to enable or disable MPTCP for a particular
	Comments: MPTCP is by default enabled on all TCP connections.		connection or socket (default: enabled).
	However, an application is still able to disable MPTCP for a
	particular connection or socket prior to the CONNECT.TCP and		o CONNECT.UDP(-Lite):
	LISTEN.TCP primitives.		Pass 1 primitive / event: 'connect' followed by 'send'.
			Parameters: 1 local IP address (default (ANY), or specified); 1
			destination transport address; 1 local port (default (OS chooses),
			or specified); 1 destination port (default (OS chooses), or
			specified).
			Comments: Associates a transport address creating a UDP(-Lite)
			socket connection. This can be called again with a new transport
			address to create a new connection. The CONNECT function allows
			an application to receive errors from messages sent to a transport
			address.
	AVAILABILITY:		AVAILABILITY:
	Preparing to receive incoming connection requests.		Preparing to receive incoming connection requests.
	o LISTEN.TCP:		o LISTEN.TCP:
	Pass 1 primitive / event: 'open' (passive)		Pass 1 primitive / event: 'open' (passive)
	Parameters: 1 local IP address (optional); 1 socket (optional);		Parameters: 1 local IP address (optional); 1 socket (optional);
	timeout (optional)		timeout (optional)
	Comments: if the socket and/or local IP address is provided, this		Comments: if the socket and/or local IP address is provided, this
	waits for incoming connections from only and/or to only the		waits for incoming connections from only and/or to only the
	provided address. Else this waits for incoming connections		provided address. Else this waits for incoming connections
	without this / these constraint(s). ESTABLISHMENT can later be		without this / these constraint(s). ESTABLISHMENT can later be
	performed with 'send'.		performed with 'send'.
	o LISTEN.SCTP:		o LISTEN.SCTP:
	Pass 1 primitive / event: 'initialize', followed by 'COMMUNICATION		Pass 1 primitive / event: 'initialize', followed by 'COMMUNICATION
	UP' notification		UP' notification and possibly 'ADAPTATION LAYER' notification
	Parameters: list of local SCTP port number / IP address pairs		Parameters: list of local SCTP port number / IP address pairs
	(initialize)		(initialize)
	Returns: socket list; outbound stream count; inbound stream count		Returns: socket list; outbound stream count; inbound stream count;
			adaptation layer indication; chunks required to be authenticated
	Comments: initialize needs to be called only once per list of		Comments: initialize needs to be called only once per list of
	local SCTP port number / IP address pairs. COMMUNICATION UP can		local SCTP port number / IP address pairs. COMMUNICATION UP can
	also follow a COMMUNICATION LOST notification, indicating that the		also follow a COMMUNICATION LOST notification, indicating that the
	lost communication is restored.		lost communication is restored. If the peer has provided an
			adaptation layer indication, an 'ADAPTATION LAYER' notification is
			issued.
			o LISTEN.MPTCP:
			This is similar to LISTEN.TCP except for one additional boolean
			parameter that allows to enable or disable MPTCP for a particular
			connection or socket (default: enabled).
			o LISTEN.UDP(-Lite):
			Pass 1 primitive / event: 'receive'.
			Parameters: 1 local IP address (default (ANY), or specified); 1
			destination transport address; local port (default (OS chooses),
			or specified); destination port (default (OS chooses), or
			specified).
			Comments: The receive function registers the application to listen
			for incoming UDP(-Lite) datagrams at an endpoint.
	MAINTENANCE:		MAINTENANCE:
	Adjustments made to an open connection, or notifications about it.		Adjustments made to an open connection, or notifications about it.
	These are out-of-band messages to the protocol that can be issued at		These are out-of-band messages to the protocol that can be issued at
	any time, at least after a connection has been established and before		any time, at least after a connection has been established and before
	it has been terminated (with one exception: CHANGE-TIMEOUT.TCP can		it has been terminated (with one exception: CHANGE-TIMEOUT.TCP can
	only be issued when DATA.SEND.TCP is called).		only be issued for an open connection when DATA.SEND.TCP is called).
			In some cases, these primitives can also be immediately issued during
			ESTABLISHMENT or AVAILABILITY, without waiting for the connection to
			be opened (e.g. CHANGE-TIMEOUT.TCP can be done using TCP's 'open'
			primitive). For UDP and UDP-Lite, these functions may establish a
			setting per connection, but may also be changed per datagram message.
	o CHANGE-TIMEOUT.TCP:		o CHANGE-TIMEOUT.TCP:
			Pass 1 primitive / event: 'open' or 'send' combined with
	Pass 1 primitive / event: 'send' combined with unspecified control		unspecified control of per-connection state variables
	of per-connection state variables
	Parameters: timeout value (optional); ADV_UTO (optional); boolean		Parameters: timeout value (optional); ADV_UTO (optional); boolean
	UTO_ENABLED (optional, default false); boolean CHANGEABLE		UTO_ENABLED (optional, default false); boolean CHANGEABLE
	(optional, default true)		(optional, default true)
	Comments: when sending data, an application can adjust the		Comments: when sending data, an application can adjust the
	connection's timeout value (time after which the connection will		connection's timeout value (time after which the connection will
	be aborted if data could not be delivered). If UTO_ENABLED is		be aborted if data could not be delivered). If UTO_ENABLED is
	true, the user timeout value (or, if provided, the value ADV_UTO)		true, the user timeout value (or, if provided, the value ADV_UTO)
	will be advertised for the TCP on the other side of the connection		will be advertised for the TCP on the other side of the connection
	to adapt its own user timeout accordingly. UTO_ENABLED controls		to adapt its own user timeout accordingly. UTO_ENABLED controls
	whether the UTO option is enabled for a connection. This applies		whether the UTO option is enabled for a connection. This applies
	skipping to change at page 15, line 40 ¶		skipping to change at page 17, line 36 ¶
	Association.Max.Retrans defines after how many unsuccessful		Association.Max.Retrans defines after how many unsuccessful
	heartbeats the connection will be terminated; thus these two		heartbeats the connection will be terminated; thus these two
	primitives / parameters together can yield a similar behavior to		primitives / parameters together can yield a similar behavior to
	CHANGE-TIMEOUT.TCP.		CHANGE-TIMEOUT.TCP.
	o DISABLE-NAGLE.TCP:		o DISABLE-NAGLE.TCP:
	Pass 1 primitive / event: not specified		Pass 1 primitive / event: not specified
	Parameters: one boolean value		Parameters: one boolean value
	Comments: the Nagle algorithm delays data transmission to increase		Comments: the Nagle algorithm delays data transmission to increase
	the chance to send a full-sized segment. An application must be		the chance to send a full-sized segment. An application must be
	able to disable this algorithm for a connection. This is related		able to disable this algorithm for a connection.
	to the no-bundle flag in DATA.SEND.SCTP.
	o REQUESTHEARTBEAT.SCTP:		o REQUESTHEARTBEAT.SCTP:
	Pass 1 primitive / event: 'Request HeartBeat'		Pass 1 primitive / event: 'Request HeartBeat'
	Parameters: socket		Parameters: socket
	Returns: success or failure		Returns: success or failure
	Comments: requests an immediate heartbeat on a path, returning		Comments: requests an immediate heartbeat on a path, returning
	success or failure.		success or failure.
	o SETPROTOCOLPARAMETERS.SCTP:		o SETPROTOCOLPARAMETERS.SCTP:
	Pass 1 primitive / event: 'Set Protocol Parameters'		Pass 1 primitive / event: 'Set Protocol Parameters'
	Parameters: RTO.Initial; RTO.Min; RTO.Max; Max.Burst; RTO.Alpha;		Parameters: RTO.Initial; RTO.Min; RTO.Max; Max.Burst; RTO.Alpha;
	RTO.Beta; Valid.Cookie.Life; Association.Max.Retrans;		RTO.Beta; Valid.Cookie.Life; Association.Max.Retrans;
	Path.Max.Retrans; Max.Init.Retransmits; HB.interval; HB.Max.Burst		Path.Max.Retrans; Max.Init.Retransmits; HB.interval; HB.Max.Burst;
			PotentiallyFailed.Max.Retrans; Primary.Switchover.Max.Retrans;
			Remote.UDPEncapsPort.
	o SETPRIMARY.SCTP:		o SETPRIMARY.SCTP:
	Pass 1 primitive / event: 'Set Primary'		Pass 1 primitive / event: 'Set Primary'
	Parameters: socket		Parameters: socket
	Returns: result of attempting this operation		Returns: result of attempting this operation
	Comments: update the current primary address to be used, based on		Comments: update the current primary address to be used, based on
	the set of available sockets of the association.		the set of available sockets of the association.
			o SETPEERPRIMARY.SCTP:
			Pass 1 primitive / event: Change Local Address / Set Peer Primary
			Parameters: local IP address
			Comments: this is only advisory for the peer.
			o SETAUTH.SCTP:
			Pass 1 primitive / event: Set / Get Authentication Parameters
			Parameters: key_id, key, hmac_id
			o GETAUTH.SCTP:
			Pass 1 primitive / event: Set / Get Authentication Parameters
			Parameters: key_id, chunk_list
			o RESETSTREAM.SCTP:
			Pass 1 primitive / event: Add / Reset Streams, Reset Association
			Parameters: sid, direction
			o RESETSTREAM-EVENT.SCTP:
			Pass 1 primitive / event: STREAM RESET notification
			Parameters: information about the result of RESETSTREAM.SCTP.
			Comments: This is issued when the procedure for resetting streams
			has completed.
			o RESETASSOC.SCTP:
			Pass 1 primitive / event: Add / Reset Streams, Reset Association
			Parameters: information related to the extension defined in
			[RFC3260].
			o RESETASSOC-EVENT.SCTP:
			Pass 1 primitive / event: ASSOCIATION RESET notification
			Parameters: information about the result of RESETASSOC.SCTP.
			Comments: This is issued when the procedure for resetting an
			association has completed.
			o ADDSTREAM.SCTP:
			Pass 1 primitive / event: Add / Reset Streams, Reset Association
			Parameters: number if outgoing and incoming streams to be added
			o ADDSTREAM-EVENT.SCTP:
			Pass 1 primitive / event: STREAM CHANGE notification
			Parameters: information about the result of ADDSTREAM.SCTP.
			Comments: This is issued when the procedure for adding a stream
			has completed.
	o ERROR.TCP:		o ERROR.TCP:
	Pass 1 primitive / event: 'ERROR_REPORT'		Pass 1 primitive / event: 'ERROR_REPORT'
	Returns: reason (encoding not specified); subreason (encoding not		Returns: reason (encoding not specified); subreason (encoding not
	specified)		specified)
	Comments: soft errors that can be ignored without harm by many		Comments: soft errors that can be ignored without harm by many
	applications; an application should be able to disable these		applications; an application should be able to disable these
	notifications. The reported conditions include at least: ICMP		notifications. The reported conditions include at least: ICMP
	error message arrived; Excessive Retransmissions.		error message arrived; Excessive Retransmissions.
			o ERROR.UDP(-Lite):
			Pass 1 primitive / event: 'ERROR_REPORT'.
			Returns: Error report
			Comments: This returns soft errors that may be ignored without
			harm by many applications; An application must connect to be able
			receive these notifications.
	o STATUS.SCTP:		o STATUS.SCTP:
	Pass 1 primitive / event: 'Status' and 'NETWORK STATUS CHANGE'		Pass 1 primitive / event: 'Status' and 'NETWORK STATUS CHANGE'
	notification		notification
	Returns: data block with information about a specified		Returns: data block with information about a specified
	association, containing: association connection state; socket		association, containing: association connection state; socket
	list; destination transport address reachability states; current		list; destination transport address reachability states; current
	receiver window size; current congestion window sizes; number of		receiver window size; current congestion window sizes; number of
	unacknowledged DATA chunks; number of DATA chunks pending receipt;		unacknowledged DATA chunks; number of DATA chunks pending receipt;
	primary path; most recent SRTT on primary path; RTO on primary		primary path; most recent SRTT on primary path; RTO on primary
	path; SRTT and RTO on other destination addresses. The NETWORK		path; SRTT and RTO on other destination addresses. The NETWORK
	STATUS CHANGE notification informs the application about a socket		STATUS CHANGE notification informs the application about a socket
	becoming active/inactive.		becoming active/inactive.
	o STATUS.MPTCP:		o STATUS.MPTCP:
	Pass 1 primitive / event: not specified		Pass 1 primitive / event: not specified
	Returns: list of pairs of tuples of IP address and TCP port number		Returns: list of pairs of tuples of IP address and TCP port number
	of each subflow. The first of the pair is the local IP and port		of each subflow. The first of the pair is the local IP and port
	number, while the second is the remote IP and port number.		number, while the second is the remote IP and port number.
	o CHANGE-DSCP.TCP:		o SET_DSCP.TCP:
	Pass 1 primitive / event: not specified		Pass 1 primitive / event: not specified
	Parameters: DSCP value		Parameters: DSCP value
	Comments: this allows an application to change the DSCP value.		Comments: this allows an application to change the DSCP value for
	For TCP this was originally specified for the TOS field [RFC1122],		outgoing segments. For TCP this was originally specified for the
	which is here interpreted to refer to the DSField [RFC3260].		TOS field [RFC1122], which is here interpreted to refer to the
			DSField [RFC3260].
			o SET_DSCP.UDP(-Lite):
			Pass 1 primitive / event: 'SET_DSCP'
			Parameter: DSCP value
			Comments: This allows an application to change the DSCP value for
			outgoing UDP(-Lite) datagrams. [RFC7657] and
			[I-D.ietf-tsvwg-rfc5405bis] provide current guidance on using this
			value with UDP.
	o ADD_SUBFLOW.MPTCP:		o ADD_SUBFLOW.MPTCP:
	Pass 1 primitive / event: not specified		Pass 1 primitive / event: not specified
	Parameters: local IP address and optionally the local port number		Parameters: local IP address and optionally the local port number
	Comments: the application specifies the local IP address and port		Comments: the application specifies the local IP address and port
	number that must be used for a new subflow.		number that must be used for a new subflow.
			o ADD_ADDR.SCTP:
			Pass 1 primitive / event: Change Local Address / Set Peer Primary
			Parameters: local IP address
	o REM_SUBFLOW.MPTCP:		o REM_SUBFLOW.MPTCP:
	Pass 1 primitive / event: not specified		Pass 1 primitive / event: not specified
	Parameters: local IP address, local port number, remote IP		Parameters: local IP address, local port number, remote IP
	address, remote port number		address, remote port number
	Comments: the application removes the subflow specified by the IP/		Comments: the application removes the subflow specified by the IP/
	port-pair. The MPTCP implementation must trigger a removal of the		port-pair. The MPTCP implementation must trigger a removal of the
	subflow that belongs to this IP/port-pair.		subflow that belongs to this IP/port-pair.
			o REM_ADDR.SCTP:
			Pass 1 primitive / event: Change Local Address / Set Peer Primary
			Parameters: local IP address
			o CHECKSUM.UDP:
			Pass 1 primitive / event: 'DISABLE_CHECKSUM'.
			Parameters: 0 when no checksum is used at sender, 1 for checksum
			at sender (default).
			o CHECKSUM_REQUIRED.UDP:
			Pass 1 primitive / event: 'REQUIRE_CHECKSUM'.
			Parameter: 0 when checksum is required at receiver, 1 to allow
			zero checksum at receiver (default).
			o SET_CHECKSUM_COVERAGE.UDP-Lite:
			Pass 1 primitive / event: 'SET_CHECKSUM_COVERAGE'.
			Parameters: Coverage length at sender (default maximum coverage)
			o SET_MIN_CHECKSUM_COVERAGE.UDP-Lite:
			Pass 1 primitive / event: 'SET_MIN_COVERAGE'.
			Parameter: Coverage length at receiver (default minimum coverage)
			o SET_DF.UDP(-Lite):
			Pass 1 primitive event: 'SET_DF'.
			Parameter: 0 when DF is not set (default), 1 when DF is set.
			o SET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):
			Pass 1 primitive / event: 'SET_TTL' and 'SET_IPV6_UNICAST_HOPS'
			Parameters: IPv4 TTL value or IPv6 Hop Count value
			Comments: This allows an application to change the IPv4 TTL of
			IPv6 Hop count value for outgoing UDP(-Lite) datagrams.
			o GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):
			Pass 1 primitive / event: 'GET_TTL' and 'GET_IPV6_UNICAST_HOPS'
			Returns: IPv4 TTL value or IPv6 Hop Count value
			Comments: This allows an application to read the the IPv4 TTL of
			IPv6 Hop count value from a received UDP(-Lite) datagram.
			o SET_ECN.UDP(-Lite):
			Pass 1 primitive / event: 'SET_ECN'
			Parameters: ECN value
			Comments: This allows a UDP(-Lite) application to set the ECN
			codepoint field for outgoing UDP(-Lite) datagrams.
			o GET_ECN.UDP(-Lite):
			Pass 1 primitive / event: 'GET_ECN'
			Parameters: ECN value
			Comments: This allows a UDP(-Lite) application to read the ECN
			codepoint field from a received UDP(-Lite) datagram.
			o SET_IP_OPTIONS.UDP(-Lite):
			Pass 1 primitive / event: 'SET_IP_OPTIONS'
			Parameters: options
			Comments: This allows a UDP(-Lite) application to set IP Options
			for outgoing UDP(-Lite) datagrams. These options can at least be
			the Source Route, Record Route, and Time Stamp option.
			o GET_IP_OPTIONS.UDP(-Lite):
			Pass 1 primitive / event: 'GET_IP_OPTIONS'
			Returns: options
			Comments: This allows a UDP(-Lite) application to receive any IP
			options that are contained in a received UDP(-Lite) datagram.
			o AUTHENTICATION_NOTIFICATION-EVENT.SCTP:
			Pass 1 primitive / event: 'AUTHENTICATION notification'
			Returns: information regarding key management.
	TERMINATION:		TERMINATION:
	Gracefully or forcefully closing a connection, or being informed		Gracefully or forcefully closing a connection, or being informed
	about this event happening.		about this event happening.
	o CLOSE.TCP:		o CLOSE.TCP:
	Pass 1 primitive / event: 'close'		Pass 1 primitive / event: 'close'
	Comments: this terminates the sending side of a connection after		Comments: this terminates the sending side of a connection after
	reliably delivering all remaining data.		reliably delivering all remaining data.
	o CLOSE.SCTP:		o CLOSE.SCTP:
	Pass 1 primitive / event: 'Shutdown'		Pass 1 primitive / event: 'Shutdown'
	Comments: this terminates a connection after reliably delivering		Comments: this terminates a connection after reliably delivering
	all remaining data.		all remaining data.
			o CLOSE.UDP(-Lite):
			Pass 1 primitive event: 'CLOSE'
			Comments: No further UDP(-Lite) datagrams are sent/received on
			this connection.
	o ABORT.TCP:		o ABORT.TCP:
	Pass 1 primitive / event: 'abort'		Pass 1 primitive / event: 'abort'
	Comments: this terminates a connection without delivering		Comments: this terminates a connection without delivering
	remaining data and sends an error message to the other side.		remaining data and sends an error message to the other side.
	o ABORT.SCTP:		o ABORT.SCTP:
	Pass 1 primitive / event: 'abort'		Pass 1 primitive / event: 'abort'
	Parameters: abort reason to be given to the peer (optional)		Parameters: abort reason to be given to the peer (optional)
	Comments: this terminates a connection without delivering		Comments: this terminates a connection without delivering
	remaining data and sends an error message to the other side.		remaining data and sends an error message to the other side.
	skipping to change at page 19, line 20 ¶		skipping to change at page 23, line 23 ¶
	o CLOSE-EVENT.SCTP:		o CLOSE-EVENT.SCTP:
	Pass 1 primitive / event: 'SHUTDOWN COMPLETE' event		Pass 1 primitive / event: 'SHUTDOWN COMPLETE' event
	Comments: the application is informed that		Comments: the application is informed that
	CONNECTION.TERMINATION.CLOSE.SCTP was successfully completed.		CONNECTION.TERMINATION.CLOSE.SCTP was successfully completed.
	4.2. DATA Transfer Related Primitives		4.2. DATA Transfer Related Primitives
	All primitives in this section refer to an existing connection, i.e.		All primitives in this section refer to an existing connection, i.e.
	a connection that was either established or made available for		a connection that was either established or made available for
	receiving data. In addition to the listed parameters, all sending		receiving data (although this is optional for the primitives of UDP(-
	primitives contain a reference to a data block and all receiving		Lite)). In addition to the listed parameters, all sending primitives
	primitives contain a reference to available buffer space for the		contain a reference to a data block and all receiving primitives
	data.		contain a reference to available buffer space for the data.
	o SEND.TCP:		o SEND.TCP:
	Pass 1 primitive / event: 'send'		Pass 1 primitive / event: 'send'
	Parameters: timeout (optional)		Parameters: timeout (optional)
	Comments: this gives TCP a data block for reliable transmission to		Comments: this gives TCP a data block for reliable transmission to
	the TCP on the other side of the connection. The timeout can be		the TCP on the other side of the connection. The timeout can be
	configured with this call whenever data are sent (see also		configured with this call whenever data are sent (see also
	CONNECTION.MAINTENANCE.CHANGE-TIMEOUT.TCP).		CONNECTION.MAINTENANCE.CHANGE-TIMEOUT.TCP).
	o SEND.SCTP:		o SEND.SCTP:
	Pass 1 primitive / event: 'Send'		Pass 1 primitive / event: 'Send'
	Parameters: stream number; context (optional); life time		Parameters: stream number; context (optional); socket (optional);
	(optional); socket (optional); unordered flag (optional); no-		unordered flag (optional); no-bundle flag (optional); payload
	bundle flag (optional); payload protocol-id (optional)		protocol-id (optional); pr-policy (optional) pr-value (optional);
	Comments: this gives SCTP a data block for reliable transmission		sack-immediately flag (optional); key-id (optional)
	to the SCTP on the other side of the connection (SCTP		Comments: this gives SCTP a data block for transmission to the
	association). The 'stream number' denotes the stream to be used.		SCTP on the other side of the connection (SCTP association). The
	The 'context' number can later be used to refer to the correct		'stream number' denotes the stream to be used. The 'context'
	message when an error is reported. The 'life time' specifies a		number can later be used to refer to the correct message when an
	time after which this data block will not be sent. The 'socket'		error is reported. The 'socket' can be used to state which path
	can be used to state which path should be preferred, if there are		should be preferred, if there are multiple paths available (see
	multiple paths available (see also		also CONNECTION.MAINTENANCE.SETPRIMARY.SCTP). The data block can
	CONNECTION.MAINTENANCE.SETPRIMARY.SCTP). The data block can be		be delivered out-of-order if the 'unordered flag' is set. The
	delivered out-of-order if the 'unordered flag' is set. The 'no-		'no-bundle flag' can be set to indicate a preference to avoid
	bundle flag' can be set to indicate a preference to avoid
	bundling. The 'payload protocol-id' is a number that will, if		bundling. The 'payload protocol-id' is a number that will, if
	provided, be handed over to the receiving application.		provided, be handed over to the receiving application. Using pr-
			policy and pr-value the level of reliability can be controlled.
			The sack-immediately flag can be used to indicate that the peer
			should not delay the sending of a SACK corresponding to the
			provided user message. If specified, the provided key-id is used
			for authenticating the user message.
			o SEND.UDP(-Lite):
			Pass 1 primitive / event: 'SEND'
			Parameters: IP Address and Port Number of the destination endpoint
			(optional if connected).
			Comments: This provides a message for unreliable transmission
			using UDP(-Lite) to the specified transport address. IP address
			and Port may be omitted for connected UDP(-Lite) sockets. All
			CONNECTION.MAINTENANCE.SET_*.UDP(-Lite) primitives apply per
			message sent.
	o RECEIVE.TCP:		o RECEIVE.TCP:
	Pass 1 primitive / event: 'receive'.		Pass 1 primitive / event: 'receive'.
	o RECEIVE.SCTP:		o RECEIVE.SCTP:
	Pass 1 primitive / event: 'DATA ARRIVE' notification, followed by		Pass 1 primitive / event: 'DATA ARRIVE' notification, followed by
	'Receive'		'Receive'
	Parameters: stream number (optional)		Parameters: stream number (optional)
	Returns: stream sequence number (optional), partial flag		Returns: stream sequence number (optional), partial flag
	(optional)		(optional)
	Comments: if the 'stream number' is provided, the call to receive		Comments: if the 'stream number' is provided, the call to receive
	only receives data on one particular stream. If a partial message		only receives data on one particular stream. If a partial message
	arrives, this is indicated by the 'partial flag', and then the		arrives, this is indicated by the 'partial flag', and then the
	'stream sequence number' must be provided such that an application		'stream sequence number' must be provided such that an application
	can restore the correct order of data blocks that comprise an		can restore the correct order of data blocks that comprise an
	entire message.		entire message. Additionally, a delivery number lets the
			application detect reordering.
			o RECEIVE.UDP(-Lite):
			Pass 1 primitive / event: 'RECEIVE',
			Parameters: Buffer for received datagram.
			Comments: All CONNECTION.MAINTENANCE.GET_*.UDP(-Lite) primitives
			apply per message received.
	o SENDFAILURE-EVENT.SCTP:		o SENDFAILURE-EVENT.SCTP:
	Pass 1 primitive / event: 'SEND FAILURE' notification, optionally		Pass 1 primitive / event: 'SEND FAILURE' notification, optionally
	followed by 'Receive Unsent Message' or 'Receive Unacknowledged		followed by 'Receive Unsent Message' or 'Receive Unacknowledged
	Message'		Message'
	Returns: cause code; context; unsent or unacknowledged message		Returns: cause code; context; unsent or unacknowledged message
	(optional)		(optional)
	Comments: 'cause code' indicates the reason of the failure, and		Comments: 'cause code' indicates the reason of the failure, and
	'context' is the context number if such a number has been provided		'context' is the context number if such a number has been provided
	in DATA.SEND.SCTP, for later use with 'Receive Unsent Message' or		in DATA.SEND.SCTP, for later use with 'Receive Unsent Message' or
	'Receive Unacknowledged Message', respectively. These primitives		'Receive Unacknowledged Message', respectively. These primitives
	can be used to retrieve the complete unsent or unacknowledged		can be used to retrieve the complete unsent or unacknowledged
	message if desired.		message if desired.
			o SEND_FAILURE.UDP(-Lite):
			Pass 1 primitive / event: 'SEND'
			Comment: This may be used to probe for the effective PMTU when
			using in combination with the 'MAINTENANCE.SET_DF' primitive.
	5. Pass 3		5. Pass 3
	This section presents the superset of all transport service features		This section presents the superset of all transport service features
	in all protocols that were discussed in the preceding sections, based		in all protocols that were discussed in the preceding sections, based
	on the list of primitives in pass 2 but also on text in pass 1 to		on the list of primitives in pass 2 but also on text in pass 1 to
	include features that can be configured in one protocol and are		include features that can be configured in one protocol and are
	static properties in another. Again, some minor details are omitted		static properties in another (congestion control, for example).
	for the sake of generalization -- e.g., TCP may provide various		Again, some minor details are omitted for the sake of generalization
	different IP options, but only source route is mandatory to		-- e.g., TCP may provide various different IP options, but only
	implement, and this detail is not visible in the Pass 3 feature		source route is mandatory to implement, and this detail is not
	"Specify IP Options".		visible in the Pass 3 feature "Specify IP Options".
	[AUTHOR'S NOTE: the list here looks pretty similar to the list in
	pass 2 for now. This will change as more protocols are added. For
	example, when we add UDP, we will find that UDP does not do
	congestion control, which is relevant to the application using it.
	This will have to be reflected in pass 1 and pass 2, only for UDP.
	In pass 3, we can then derive "no congestion control" as a transport
	service feature of UDP; however, since it would be strange to call
	the lack of congestion control a feature, the natural outcome is then
	to list "congestion control" as a feature of TCP and SCTP.]
	5.1. CONNECTION Related Transport Service Features		5.1. CONNECTION Related Transport Service Features
	ESTABLISHMENT:		ESTABLISHMENT:
	Active creation of a connection from one transport endpoint to one or		Active creation of a connection from one transport endpoint to one or
	more transport endpoints.		more transport endpoints.
	o Connect		o Connect
	Protocols: TCP, SCTP		Protocols: TCP, SCTP, UDP(-Lite)
	o Specify IP Options		o Specify which IP Options must always be used
	Protocols: TCP		Protocols: TCP
	o Request multiple streams		o Request multiple streams
	Protocols: SCTP		Protocols: SCTP
	o Obtain multiple sockets		o Obtain multiple sockets
	Protocols: SCTP		Protocols: SCTP
	o Disable MPTCP		o Disable MPTCP
	Protocols: MPTCP/TCP		Protocols: MPTCP
			o Specify which chunk types must always be authenticated
			Protocols: SCTP
			Comments: DATA, ACK etc. are different 'chunks' in SCTP; one or
			more chunks may be included in a single packet.
			o Indicate an Adaptation Layer (via an adaptation code point)
			Protocols: SCTP
	AVAILABILITY:		AVAILABILITY:
	Preparing to receive incoming connection requests.		Preparing to receive incoming connection requests.
	o Listen, 1 specified local interface		o Listen, 1 specified local interface
	Protocols: TCP, SCTP		Protocols: TCP, SCTP, UDP(-Lite)
	o Listen, N specified local interfaces		o Listen, N specified local interfaces
	Protocols: SCTP		Protocols: SCTP, UDP(-Lite)
	o Listen, all local interfaces		o Listen, all local interfaces
	Protocols: TCP, SCTP		Protocols: TCP, SCTP, UDP(-Lite)
	o Obtain requested number of streams		o Obtain requested number of streams
	Protocols: SCTP		Protocols: SCTP
			o Specify which IP Options must always be used
			Protocols: TCP
			o Disable MPTCP
			Protocols: MPTCP
			o Specify which chunk types must always be authenticated
			Protocols: SCTP
			Comments: DATA, ACK etc. are different 'chunks' in SCTP; one or
			more chunks may be included in a single packet.
			o Indicate an Adaptation Layer (via an adaptation code point)
			Protocols: SCTP
	MAINTENANCE:		MAINTENANCE:
	Adjustments made to an open connection, or notifications about it.		Adjustments made to an open connection, or notifications about it.
	NOTE: all features except "set primary path" in this category apply		NOTE: all features except "set primary path" in this category apply
	to one out of multiple possible paths (identified via sockets) in		to one out of multiple possible paths (identified via sockets) in
	SCTP, whereas TCP uses only one path (one socket).		SCTP, whereas TCP uses only one path (one socket).
	o Change timeout for aborting connection (using retransmit limit or		o Change timeout for aborting connection (using retransmit limit or
	time value)		time value)
	Protocols: TCP, SCTP		Protocols: TCP, SCTP
	skipping to change at page 23, line 16 ¶		skipping to change at page 27, line 20 ¶
	Protocols: TCP, SCTP		Protocols: TCP, SCTP
	Comments: This is not specified in [RFC4960] but in [RFC6458].		Comments: This is not specified in [RFC4960] but in [RFC6458].
	o Request an immediate heartbeat, returning success/failure		o Request an immediate heartbeat, returning success/failure
	Protocols: SCTP		Protocols: SCTP
	o Set protocol parameters		o Set protocol parameters
	Protocols: SCTP		Protocols: SCTP
	SCTP parameters: RTO.Initial; RTO.Min; RTO.Max; Max.Burst;		SCTP parameters: RTO.Initial; RTO.Min; RTO.Max; Max.Burst;
	RTO.Alpha; RTO.Beta; Valid.Cookie.Life; Association.Max.Retrans;		RTO.Alpha; RTO.Beta; Valid.Cookie.Life; Association.Max.Retrans;
	Path.Max.Retrans; Max.Init.Retransmits; HB.interval; HB.Max.Burst		Path.Max.Retrans; Max.Init.Retransmits; HB.interval; HB.Max.Burst;
	Comments: in future versions of this document, it might make sense		PotentiallyFailed.Max.Retrans; Primary.Switchover.Max.Retrans;
	to split out some of these parameters -- e.g., if a different		Remote.UDPEncapsPort
	protocol provides means to adjust the RTO calculation there could		Comments: as transport layer features from other protocols are
	be a common feature for them called "adjust RTO calculation".		added, it might make sense to separate out some of these
			parameters -- e.g., if a different protocol provides means to
			adjust the RTO calculation there could be a common feature for
			them called "adjust RTO calculation".
	o Notification of Excessive Retransmissions (early warning below		o Notification of Excessive Retransmissions (early warning below
	abortion threshold)		abortion threshold)
	Protocols: TCP		Protocols: TCP
	o Notification of ICMP error message arrival		o Notification of ICMP error message arrival
	Protocols: TCP		Protocols: TCP, UDP(-Lite)
	o Status (query or notification)		o Obtain status (query or notification)
	Protocols: SCTP, MPTCP		Protocols: SCTP, MPTCP
	SCTP parameters: association connection state; socket list; socket		SCTP parameters: association connection state; socket list; socket
	reachability states; current receiver window size; current		reachability states; current receiver window size; current
	congestion window sizes; number of unacknowledged DATA chunks;		congestion window sizes; number of unacknowledged DATA chunks;
	number of DATA chunks pending receipt; primary path; most recent		number of DATA chunks pending receipt; primary path; most recent
	SRTT on primary path; RTO on primary path; SRTT and RTO on other		SRTT on primary path; RTO on primary path; SRTT and RTO on other
	destination addresses; socket becoming active / inactive		destination addresses; socket becoming active / inactive
	MPTCP parameters: subflow-list (identified by source-IP; source-		MPTCP parameters: subflow-list (identified by source-IP; source-
	Port; destination-IP; destination-Port)		Port; destination-IP; destination-Port)
			o Change authentication parameters
			Protocols: SCTP
			o Obtain authentication information
			Protocols: SCTP
	o Set primary path		o Set primary path
	Protocols: SCTP		Protocols: SCTP
	o Change DSCP		o Reset Stream
	Protocols: TCP		Protocols: SCTP
	Comments: This is described to be changeable for SCTP too in
	[RFC6458].		o Notification of Stream Reset
			Protocols: STCP
			o Reset Association
			Protocols: SCTP
			o Notification of Association Reset
			Protocols: STCP
			o Add Streams
			Protocols: SCTP
			o Notification of Added Stream
			Protocols: STCP
			o Set peer primary path
			Protocols: SCTP
			o Specify DSCP field
			Protocols: TCP, SCTP, UDP(-Lite)
	o Add subflow		o Add subflow
	Protocols: MPTCP		Protocols: MPTCP
	MPTCP Parameters: source-IP; source-Port; destination-IP;		MPTCP Parameters: source-IP; source-Port; destination-IP;
	destination-Port		destination-Port
	o Remove subflow		o Remove subflow
	Protocols: MPTCP		Protocols: MPTCP
	MPTCP Parameters: source-IP; source-Port; destination-IP;		MPTCP Parameters: source-IP; source-Port; destination-IP;
	destination-Port		destination-Port
			o Add local address
			Protocols: SCTP
			o Remove local address
			Protocols: SCTP
			o Disable checksum when sending
			Protocols: UDP
			o Disable checksum requirement when receiving
			Protocols: UDP
			o Specify checksum coverage used by the sender
			Protocols: UDP-Lite
			o Specify minimum checksum coverage required by receiver
			Protocols: UDP-Lite
			o Specify DF field
			Protocols: UDP(-Lite)
			o Specify TTL/Hop count field
			Protocols: UDP(-Lite)
			o Obtain TTL/Hop count field
			Protocols: UDP(-Lite)
			o Specify ECN field
			Protocols: UDP(-Lite)
			o Obtain ECN field
			Protocols: UDP(-Lite)
			o Specify IP Options
			Protocols: UDP(-Lite)
			o Obtain IP Options
			Protocols: UDP(-Lite)
	TERMINATION:		TERMINATION:
	Gracefully or forcefully closing a connection, or being informed		Gracefully or forcefully closing a connection, or being informed
	about this event happening.		about this event happening.
	o Close after reliably delivering all remaining data, causing an		o Close after reliably delivering all remaining data, causing an
	event informing the application on the other side		event informing the application on the other side
	Protocols: TCP, SCTP		Protocols: TCP, SCTP
	Comments: A TCP endpoint locally only closes the connection for		Comments: A TCP endpoint locally only closes the connection for
	sending; it may still receive data afterwards.		sending; it may still receive data afterwards.
	skipping to change at page 25, line 21 ¶		skipping to change at page 30, line 23 ¶
	All features in this section refer to an existing connection, i.e. a		All features in this section refer to an existing connection, i.e. a
	connection that was either established or made available for		connection that was either established or made available for
	receiving data. Reliable data transfer entails delay -- e.g. for the		receiving data. Reliable data transfer entails delay -- e.g. for the
	sender to wait until it can transmit data, or due to retransmission		sender to wait until it can transmit data, or due to retransmission
	in case of packet loss.		in case of packet loss.
	5.2.1. Sending Data		5.2.1. Sending Data
	All features in this section are provided by DATA.SEND from pass 2.		All features in this section are provided by DATA.SEND from pass 2.
	DATA.SEND is given a data block from the application, which we here		DATA.SEND is given a data block from the application, which we here
	call a "message".		call a "message" if the beginning and end of the data block can be
			identified at the receiver, and "data" otherwise.
	o Reliably transfer data		o Reliably transfer data, with congestion control
	Protocols: TCP, SCTP		Protocols: TCP
	o Message identification		o Reliably transfer a message, with congestion control
	Protocols: SCTP		Protocols: SCTP
	o Choice of stream		o Unreliably transfer a message, with congestion control
	Protocols: SCTP		Protocols: SCTP
	o Choice of path (destination address)		o Unreliably transfer a message, without congestion control
			Protocols: UDP(-Lite)
			o Configurable Message Reliability
	Protocols: SCTP		Protocols: SCTP
	o Message lifetime		o Choice of stream
			Protocols: SCTP
			o Choice of path (destination address)
	Protocols: SCTP		Protocols: SCTP
	o Choice between unordered (potentially faster) or ordered delivery		o Choice between unordered (potentially faster) or ordered delivery
	of messages		of messages
	Protocols: SCTP		Protocols: SCTP
	o Request not to bundle messages		o Request not to bundle messages
	Protocols: SCTP		Protocols: SCTP
	o Specifying a "payload protocol-id" (handed over as such by the		o Specifying a "payload protocol-id" (handed over as such by the
	receiver)		receiver)
	Protocols: SCTP		Protocols: SCTP
			o Specifying a key id to be used to authenticate a message
			Protocols: SCTP
			o Request not to delay the acknowledgement (SACK) of a message
			Protocols: SCTP
	5.2.2. Receiving Data		5.2.2. Receiving Data
	All features in this section are provided by DATA.RECEIVE from pass		All features in this section are provided by DATA.RECEIVE from pass
	2. DATA.RECEIVE fills a buffer provided to the application, with		2. DATA.RECEIVE fills a buffer provided by the application, with
	what we here call a "message".		what we here call a "message" if the beginning and end of the data
			block can be identified at the receiver, and "data" otherwise.
	o Receive data		o Receive data
	Protocols: TCP, SCTP		Protocols: TCP
			o Receive a message
			Protocols: SCTP, UDP(-Lite)
	o Choice of stream to receive from		o Choice of stream to receive from
	Protocols: SCTP		Protocols: SCTP
	o Message identification
	Protocols: SCTP
	Comments: In SCTP, this is optionally achieved with a "stream
	sequence number". The stream sequence number is always provided
	in case of partial message arrival.
	o Information about partial message arrival		o Information about partial message arrival
	Protocols: SCTP		Protocols: SCTP
	Comments: In SCTP, partial messages are combined with a stream		Comments: In SCTP, partial messages are combined with a stream
	sequence number so that the application can restore the correct		sequence number so that the application can restore the correct
	order of data blocks an entire message consists of.		order of data blocks an entire message consists of.
			o Obtain a message delivery number
			Protocols: SCTP
			Comments: This number can let applications detect and, if desired,
			correct reordering.
	5.2.3. Errors		5.2.3. Errors
	This section describes sending failures that are associated with a		This section describes sending failures that are associated with a
	specific call to DATA.SEND from pass 2.		specific call to DATA.SEND from pass 2.
	o Notification of unsent messages		o Notification of unsent messages
	Protocols: SCTP		Protocols: SCTP, UDP(-Lite)
	o Notification of unacknowledged messages		o Notification of unacknowledged messages
	Protocols: SCTP		Protocols: SCTP
	6. Acknowledgements		6. Acknowledgements
	The authors would like to thank (in alphabetical order) Bob Briscoe,		The authors would like to thank (in alphabetical order) Bob Briscoe,
	David Hayes, Gorry Fairhurst, Karen Nielsen and Joe Touch for		Gorry Fairhurst, David Hayes, Tom Jones, Karen Nielsen and Joe Touch
	providing valuable feedback on this document. Special thanks goes		for providing valuable feedback on this document. We especially
	also to Christoph Paasch for providing input related to Multipath		thank to Christoph Paasch for providing input related to Multipath
	TCP. This work has received funding from the European Union's		TCP. This work has received funding from the European Union's
	Horizon 2020 research and innovation programme under grant agreement		Horizon 2020 research and innovation programme under grant agreement
	No. 644334 (NEAT). The views expressed are solely those of the		No. 644334 (NEAT). The views expressed are solely those of the
	author(s).		author(s).
	7. IANA Considerations		7. IANA Considerations
	XX RFC ED - PLEASE REMOVE THIS SECTION XXX		XX RFC ED - PLEASE REMOVE THIS SECTION XXX
	This memo includes no request to IANA.		This memo includes no request to IANA.
	8. Security Considerations		8. Security Considerations
	Security will be considered in future versions of this document.		Security will be considered in future versions of this document.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
			[I-D.ietf-tsvwg-rfc5405bis]
			Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
			Guidelines", draft-ietf-tsvwg-rfc5405bis-07 (work in
			progress), November 2015.
	[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,		[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
	RFC 793, DOI 10.17487/RFC0793, September 1981,		RFC 793, DOI 10.17487/RFC0793, September 1981,
	<http://www.rfc-editor.org/info/rfc793>.		<http://www.rfc-editor.org/info/rfc793>.
	[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -		[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
	Communication Layers", STD 3, RFC 1122,		Communication Layers", STD 3, RFC 1122, DOI 10.17487/
	DOI 10.17487/RFC1122, October 1989,		RFC1122, October 1989,
	<http://www.rfc-editor.org/info/rfc1122>.		<http://www.rfc-editor.org/info/rfc1122>.
	[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",		[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
	RFC 4960, DOI 10.17487/RFC4960, September 2007,		RFC 4960, DOI 10.17487/RFC4960, September 2007,
	<http://www.rfc-editor.org/info/rfc4960>.		<http://www.rfc-editor.org/info/rfc4960>.
	[RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option",		[RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option",
	RFC 5482, DOI 10.17487/RFC5482, March 2009,		RFC 5482, DOI 10.17487/RFC5482, March 2009,
	<http://www.rfc-editor.org/info/rfc5482>.		<http://www.rfc-editor.org/info/rfc5482>.
	9.2. Informative References		9.2. Informative References
	[FA15] Fairhurst, Ed., G., Trammell, Ed., B., and M. Kuehlewind,		[FA16] Fairhurst, Ed., G., Trammell, Ed., B., and M. Kuehlewind,
	Ed., "Services provided by IETF transport protocols and		Ed., "Services provided by IETF transport protocols and
	congestion control mechanisms", Internet-draft draft-		congestion control mechanisms",
	fairhurst-taps-transports-08.txt, December 2015.		draft-ietf-taps-transports-12.txt (work in progress),
			October 2016.
			[FJ16] Fairhurst, G. and T. Jones, "Features of the User Datagram
			Protocol (UDP) and Lightweight UDP (UDP-Lite) Transport
			Protocols", draft-fairhurst-taps-transports-usage-udp-03
			(work in progress), October 2016.
	[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol		[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol
	Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May		Specification", STD 8, RFC 854, DOI 10.17487/RFC0854,
	1983, <http://www.rfc-editor.org/info/rfc854>.		May 1983, <http://www.rfc-editor.org/info/rfc854>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
	DOI 10.17487/RFC2119, March 1997,		RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition		[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
	of Explicit Congestion Notification (ECN) to IP",		of Explicit Congestion Notification (ECN) to IP",
	RFC 3168, DOI 10.17487/RFC3168, September 2001,		RFC 3168, DOI 10.17487/RFC3168, September 2001,
	<http://www.rfc-editor.org/info/rfc3168>.		<http://www.rfc-editor.org/info/rfc3168>.
	[RFC3260] Grossman, D., "New Terminology and Clarifications for		[RFC3260] Grossman, D., "New Terminology and Clarifications for
	Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002,		Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002,
	<http://www.rfc-editor.org/info/rfc3260>.		<http://www.rfc-editor.org/info/rfc3260>.
			[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
			Conrad, "Stream Control Transmission Protocol (SCTP)
			Partial Reliability Extension", RFC 3758, DOI 10.17487/
			RFC3758, May 2004,
			<http://www.rfc-editor.org/info/rfc3758>.
	[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed.,		[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed.,
	and G. Fairhurst, Ed., "The Lightweight User Datagram		and G. Fairhurst, Ed., "The Lightweight User Datagram
	Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July		Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828,
	2004, <http://www.rfc-editor.org/info/rfc3828>.		July 2004, <http://www.rfc-editor.org/info/rfc3828>.
			[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
			"Authenticated Chunks for the Stream Control Transmission
			Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895,
			August 2007, <http://www.rfc-editor.org/info/rfc4895>.
			[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
			Kozuka, "Stream Control Transmission Protocol (SCTP)
			Dynamic Address Reconfiguration", RFC 5061, DOI 10.17487/
			RFC5061, September 2007,
			<http://www.rfc-editor.org/info/rfc5061>.
	[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461,		[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461,
	DOI 10.17487/RFC5461, February 2009,		DOI 10.17487/RFC5461, February 2009,
	<http://www.rfc-editor.org/info/rfc5461>.		<http://www.rfc-editor.org/info/rfc5461>.
	[RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the		[RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the
	TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093,		TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093,
	January 2011, <http://www.rfc-editor.org/info/rfc6093>.		January 2011, <http://www.rfc-editor.org/info/rfc6093>.
	[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J.		[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
	Iyengar, "Architectural Guidelines for Multipath TCP		Iyengar, "Architectural Guidelines for Multipath TCP
	Development", RFC 6182, DOI 10.17487/RFC6182, March 2011,		Development", RFC 6182, DOI 10.17487/RFC6182, March 2011,
	<http://www.rfc-editor.org/info/rfc6182>.		<http://www.rfc-editor.org/info/rfc6182>.
	[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.		[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
	Yasevich, "Sockets API Extensions for the Stream Control		Yasevich, "Sockets API Extensions for the Stream Control
	Transmission Protocol (SCTP)", RFC 6458,		Transmission Protocol (SCTP)", RFC 6458, DOI 10.17487/
	DOI 10.17487/RFC6458, December 2011,		RFC6458, December 2011,
	<http://www.rfc-editor.org/info/rfc6458>.		<http://www.rfc-editor.org/info/rfc6458>.
			[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control
			Transmission Protocol (SCTP) Stream Reconfiguration",
			RFC 6525, DOI 10.17487/RFC6525, February 2012,
			<http://www.rfc-editor.org/info/rfc6525>.
	[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,		[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
	"TCP Extensions for Multipath Operation with Multiple		"TCP Extensions for Multipath Operation with Multiple
	Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,		Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
	<http://www.rfc-editor.org/info/rfc6824>.		<http://www.rfc-editor.org/info/rfc6824>.
	[RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application		[RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application
	Interface Considerations", RFC 6897, DOI 10.17487/RFC6897,		Interface Considerations", RFC 6897, DOI 10.17487/RFC6897,
	March 2013, <http://www.rfc-editor.org/info/rfc6897>.		March 2013, <http://www.rfc-editor.org/info/rfc6897>.
			[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
			Control Transmission Protocol (SCTP) Packets for End-Host
			to End-Host Communication", RFC 6951, DOI 10.17487/
			RFC6951, May 2013,
			<http://www.rfc-editor.org/info/rfc6951>.
			[RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK-
			IMMEDIATELY Extension for the Stream Control Transmission
			Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013,
			<http://www.rfc-editor.org/info/rfc7053>.
	[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A.		[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A.
	Zimmermann, "A Roadmap for Transmission Control Protocol		Zimmermann, "A Roadmap for Transmission Control Protocol
	(TCP) Specification Documents", RFC 7414,		(TCP) Specification Documents", RFC 7414, DOI 10.17487/
	DOI 10.17487/RFC7414, February 2015,		RFC7414, February 2015,
	<http://www.rfc-editor.org/info/rfc7414>.		<http://www.rfc-editor.org/info/rfc7414>.
			[RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,
			"Additional Policies for the Partially Reliable Stream
			Control Transmission Protocol Extension", RFC 7496,
			DOI 10.17487/RFC7496, April 2015,
			<http://www.rfc-editor.org/info/rfc7496>.
			[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services
			(Diffserv) and Real-Time Communication", RFC 7657,
			DOI 10.17487/RFC7657, November 2015,
			<http://www.rfc-editor.org/info/rfc7657>.
			[RFC7829] Nishida, Y., Natarajan, P., Caro, A., Amer, P., and K.
			Nielsen, "SCTP-PF: A Quick Failover Algorithm for the
			Stream Control Transmission Protocol", RFC 7829,
			DOI 10.17487/RFC7829, April 2016,
			<http://www.rfc-editor.org/info/rfc7829>.
	Appendix A. Overview of RFCs used as input for pass 1		Appendix A. Overview of RFCs used as input for pass 1
	TCP: [RFC0793], [RFC1122], [RFC5482]		TCP: [RFC0793], [RFC1122], [RFC5482]
	MPTCP: [RFC6182], [RFC6824], [RFC6897]		MPTCP: [RFC6182], [RFC6824], [RFC6897]
	SCTP: [RFC4960], planned: [RFC6458]		SCTP: RFCs without a socket API specification: [RFC3758], [RFC4895],
			[RFC4960], [RFC5061]. RFCs that include a socket API
			specification: [RFC6458], [RFC6525], [RFC6951], [RFC7053],
			[RFC7496] [RFC7829].
			UDP(-Lite): See [FJ16]
	Appendix B. How to contribute		Appendix B. How to contribute
	This document is only concerned with transport service features that		This document is only concerned with transport service features that
	are explicitly exposed to applications via primitives. It also		are explicitly exposed to applications via primitives. It also
	strictly follows RFC text: if a feature is truly relevant for an		strictly follows RFC text: if a feature is truly relevant for an
	application, the RFCs better say so and in some way describe how to		application, the RFCs better say so and in some way describe how to
	use and configure it. Thus, the approach to follow for contributing		use and configure it. Thus, the approach to follow for contributing
	to this document is to identify the right RFCs, then analyze and		to this document is to identify the right RFCs, then analyze and
	process their text.		process their text.
	skipping to change at page 30, line 34 ¶		skipping to change at page 36, line 47 ¶
	parts from the relevant RFCs, then adjust terminology to match the		parts from the relevant RFCs, then adjust terminology to match the
	terminology in Section 1 and adjust (shorten!) phrasing to match the		terminology in Section 1 and adjust (shorten!) phrasing to match the
	general style of the document. Try to formulate everything as a		general style of the document. Try to formulate everything as a
	primitive description to make the primitive description as complete		primitive description to make the primitive description as complete
	as possible (e.g., the "SEND.TCP" primitive in pass 2 is explicitly		as possible (e.g., the "SEND.TCP" primitive in pass 2 is explicitly
	described as reliably transferring data); if there is text that is		described as reliably transferring data); if there is text that is
	relevant for the primitives presented in this pass but still does not		relevant for the primitives presented in this pass but still does not
	fit directly under any primitive, use it as an introduction for your		fit directly under any primitive, use it as an introduction for your
	subsection. However, do note that document length is a concern and		subsection. However, do note that document length is a concern and
	all the protocols and their services / features are already described		all the protocols and their services / features are already described
	in [FA15].		in [FA16].
	Pass 2: The main goal of this pass is unification of primitives. As		Pass 2: The main goal of this pass is unification of primitives. As
	input, use your own text from Pass 1, no exterior sources. If you		input, use your own text from Pass 1, no exterior sources. If you
	find that something is missing there, fix the text in Pass 1. The		find that something is missing there, fix the text in Pass 1. The
	list in pass 2 is not done by protocol ("first protocol X, here are		list in pass 2 is not done by protocol ("first protocol X, here are
	all the primitives; then protocol Y, here are all the primitives,		all the primitives; then protocol Y, here are all the primitives,
	..") but by primitive ("primitive A, implemented this way in protocol		..") but by primitive ("primitive A, implemented this way in protocol
	X, this way in protocol Y, ..."). We want as many similar pass 2		X, this way in protocol Y, ..."). We want as many similar pass 2
	primitives as possible. This can be achieved, for instance, by not		primitives as possible. This can be achieved, for instance, by not
	always maintaining a 1:1 mapping between pass 1 and pass 2		always maintaining a 1:1 mapping between pass 1 and pass 2
	skipping to change at page 31, line 38 ¶		skipping to change at page 37, line 49 ¶
	Appendix C. Revision information		Appendix C. Revision information
	XXX RFC-Ed please remove this section prior to publication.		XXX RFC-Ed please remove this section prior to publication.
	-00 (from draft-welzl-taps-transports): this now covers TCP based on		-00 (from draft-welzl-taps-transports): this now covers TCP based on
	all TCP RFCs (this means: if you know of something in any TCP RFC		all TCP RFCs (this means: if you know of something in any TCP RFC
	that you think should be addressed, please speak up!) as well as		that you think should be addressed, please speak up!) as well as
	SCTP, exclusively based on [RFC4960]. We decided to also incorporate		SCTP, exclusively based on [RFC4960]. We decided to also incorporate
	[RFC6458] for SCTP, but this hasn't happened yet. Terminology made		[RFC6458] for SCTP, but this hasn't happened yet. Terminology made
	in line with [FA15]. Addressed comments by Karen Nielsen and Gorry		in line with [FA16]. Addressed comments by Karen Nielsen and Gorry
	Fairhurst; various other fixes. Appendices (TCP overview and how-to-		Fairhurst; various other fixes. Appendices (TCP overview and how-to-
	contribute) added.		contribute) added.
	-01: this now also covers MPTCP based on [RFC6182], [RFC6824] and		-01: this now also covers MPTCP based on [RFC6182], [RFC6824] and
	[RFC6897].		[RFC6897].
			-02: included UDP, UDP-Lite, and all extensions of SCTPs. This
			includes fixing the [RFC6458] omission from -00.
			TODO: security considerations (see review in ML); the "how to
			contribute" section (which, at some point, should be updated to
			reflect how the document WAS created, not how it SHOULD BE created)
			still says "Experimental RFCs are excluded". This is wrong, and
			accordingly, Experimental RFCs must also be considered - thus, TFO
			(are there more Experimental ones for TCP?). Also, include LEDBAT.
			SCTP: DSCP and SCTP_NODELAY (equivalent to Nagle) are missing in pass
			1 and 2. Are we missing more (DF, TTL, ..)? What about e.g.
			"notification of ICMP error message arrival"? Also consider
			draft-ietf-tsvwg-sctp-ndata.
	Authors' Addresses		Authors' Addresses
	Michael Welzl		Michael Welzl
	University of Oslo		University of Oslo
	PO Box 1080 Blindern		PO Box 1080 Blindern
	Oslo N-0316		Oslo, N-0316
	Norway		Norway
	Phone: +47 22 85 24 20		Phone: +47 22 85 24 20
	Email: michawe@ifi.uio.no		Email: michawe@ifi.uio.no
	Michael Tuexen		Michael Tuexen
	Muenster University of Applied Sciences		Muenster University of Applied Sciences
	Stegerwaldstrasse 39		Stegerwaldstrasse 39
	Steinfurt 48565		Steinfurt 48565
	Germany		Germany
	skipping to change at page 32, line 23 ¶		skipping to change at page 39, line 4 ¶
	Phone: +47 22 85 24 20		Phone: +47 22 85 24 20
	Email: michawe@ifi.uio.no		Email: michawe@ifi.uio.no
	Michael Tuexen		Michael Tuexen
	Muenster University of Applied Sciences		Muenster University of Applied Sciences
	Stegerwaldstrasse 39		Stegerwaldstrasse 39
	Steinfurt 48565		Steinfurt 48565
	Germany		Germany
	Email: tuexen@fh-muenster.de		Email: tuexen@fh-muenster.de
	Naeem Khademi		Naeem Khademi
	University of Oslo		University of Oslo
	PO Box 1080 Blindern		PO Box 1080 Blindern
	Oslo N-0316		Oslo, N-0316
	Norway		Norway
	Email: naeemk@ifi.uio.no		Email: naeemk@ifi.uio.no
End of changes. 90 change blocks.
	174 lines changed or deleted		619 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/