RFC 8303

On the Usage of Transport Features Provided by IETF Transport Protocols

📅 published February 2018, from ietf

RFC 8303: On the Usage of Transport Features Provided by IETF Transport Protocols ✨

okay bestie, header tea 🫖. This is RFC 8303, published in February 2018 by the IETF (Internet Engineering Task Force). It's an Informational doc, so it's not a Standards Track spec, just published for info 🧚. The authors are M. Welzl (University of Oslo), M. Tuexen (Muenster Univ. of Appl. Sciences), and N. Khademi (University of Oslo). It's ISSN 2070-1721, and its header has no Obsoletes or Updates lines, so it doesn't list any older RFCs it replaces or changes 💅.

Abstract 📝

so this doc walks through how TCP, MPTCP, SCTP, UDP, and UDP-Lite expose their services to apps, and how an app can configure and use the features that make up those services 💖. It also looks at the service that the Low Extra Delay Background Transport (LEDBAT) congestion control mechanism provides. The result is a set of transport abstractions that can be exported in a transport services (TAPS) API 🦋.

Status of This Memo 🎀

this is not an Internet Standards Track spec, it's published purely for informational purposes 🧚.

it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every doc the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 for the deets 🙈.

for the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8303 🔗.

Copyright Notice 🌸

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. please read these carefully, because they spell out your rights and restrictions for this doc 📜.

code components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🌈.

Table of Contents 🗺️

1. Introduction ....................................................3
2. Terminology .....................................................5
3. Pass 1 ..........................................................6
   3.1. Primitives Provided by TCP .................................6
        3.1.1. Excluded Primitives or Parameters ...................9
   3.2. Primitives Provided by MPTCP ..............................10
   3.3. Primitives Provided by SCTP ...............................11
        3.3.1. Excluded Primitives or Parameters ..................18
   3.4. Primitives Provided by UDP and UDP-Lite ...................18
   3.5. The Service of LEDBAT .....................................19
4. Pass 2 .........................................................20
   4.1. CONNECTION-Related Primitives .............................21
   4.2. DATA-Transfer-Related Primitives ..........................38
5. Pass 3 .........................................................41
   5.1. CONNECTION-Related Transport Features .....................41
   5.2. DATA-Transfer-Related Transport Features ..................47
        5.2.1. Sending Data .......................................47
        5.2.2. Receiving Data .....................................48
        5.2.3. Errors .............................................49
6. IANA Considerations ............................................49
7. Security Considerations ........................................49
8. References .....................................................50
   8.1. Normative References ......................................50
   8.2. Informative References ....................................52
Appendix A. Overview of RFCs Used as Input for Pass 1 .............54
Appendix B. How This Document Was Developed .......................54
Acknowledgements ..................................................56
Authors' Addresses ................................................56

1. Introduction ✨

okay so this spec describes how transport protocols offer transport services, so apps aren't directly tied to one specific protocol anymore 🦋. breaking that strict connection can cut the effort for an app programmer, and you still get more transport flexibility, because the complexity gets pushed down into an underlying transport services (TAPS) system 💅.

this design process started with a survey of the services that IETF transport protocols and congestion control mechanisms provide [RFC8095]. this doc and [RFC8304] add an in-depth look at the defined interactions between apps and these unicast transport protocols: Transmission Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP), and Lightweight User Datagram Protocol (UDP-Lite) 🔥. we also define a primitive to enable/disable and configure the Low Extra Delay Background Transport (LEDBAT) unicast congestion control mechanism. for UDP and UDP-Lite, the first step of the protocol analysis (a discussion of relevant RFC text) is documented in [RFC8304] 📚.

this snapshot in time of the IETF transport protocols is published as an RFC to document the analysis by the authors and the TAPS Working Group. it generates a set of transport abstractions that can be exported in a TAPS API 📸. it's the basis for the minimal set of transport services that end systems supporting TAPS should implement [TAPS-MINSET] 🎀.

the list of primitives, events, and transport features in this doc is strictly based on the parts of protocol specs that describe what the protocol provides to an app using it, and how the app interacts with it 🧚. transport protocols provide communication between processes running on network endpoints. that means they allow multiplexing of communication between the same IP addresses, and this multiplexing is done with port numbers. so port multiplexing is always assumed to be provided, and this doc doesn't discuss it 🌸.

parts of a protocol that are explicitly stated as optional to implement aren't covered. interactions between the app and a transport protocol that aren't directly related to how the protocol operates aren't covered either 🙈. for example, there are various ways for an app to use socket options to say it wants certain notifications [RFC6458]. but for the purpose of identifying primitives, events, and transport features, being able to turn notifications on or off is irrelevant 💅. same vibe with "one-to-many style sockets" [RFC6458]: they only change the app programming style, not how the underlying protocol works, so they're not discussed here 💖. the same goes for getting back the unchanged value of a parameter the app already set (e.g., via "get" in get/set operations [RFC6458]) 🫶.

the doc presents a three-pass process to arrive at a list of transport features 🍓. in the first pass (pass 1), the relevant RFC text is discussed per protocol. in the second pass (pass 2), that discussion is used to derive a list of primitives and events that are uniformly categorized across protocols. here, the goal is to present primitives or events, or, where text describing them doesn't exist yet, to construct them in a slightly generalized form to highlight similarities. this happens by renaming a protocol's primitives or events, or by not forcing a strict 1:1 mapping between the primitives or events in the protocol spec and the ones in the list 👑. finally, the third pass (pass 3) presents transport features based on pass 2, and identifies which protocols implement them 🔥.

in the list from the second pass, some transport features are missing, because they're implicit in some protocols. they only become explicit when we look at the superset of all transport features offered by all protocols 🌈. for example, TCP always carries out congestion control, so we have to consider it together with a protocol like UDP (which has no congestion control) before congestion control can count as a transport feature 💀. the complete list of transport features across all protocols is therefore only available after pass 3 ✨.

some protocols are connection oriented. these often use an initial call to a specific primitive to open a connection before communication can progress, and they require communication to be explicitly terminated by making another call to a primitive (usually called 'Close') 💜. a "connection" is the common state that some transport primitives refer to, e.g., to adjust general configuration settings 🦋. so connection establishment, maintenance, and termination are used to categorize transport primitives of connection-oriented transport protocols in pass 2 and pass 3 🎀. for this purpose, UDP is assumed to be used with "connected" sockets, i.e., sockets bound to a specific pair of addresses and ports [RFC8304] 🧚.

2. Terminology 💅

okay bestie, before we get into the juicy stuff we need to agree on what the words mean 🫶 these are the definitions the rest of the doc leans on, so no skipping!

Transport Feature 🦋: a specific end-to-end feature that the transport layer gives an application. Examples are confidentiality, reliable delivery, ordered delivery, message-versus-stream orientation, etc. ✨
Transport Service 🌸: a set of transport features, without being tied to any particular framing protocol, that gives an application a complete service 👑
Transport Protocol 🎀: an implementation that provides one or more transport services using a specific framing and header format on the wire 💜
Transport Protocol Component 🧚: an implementation of a transport feature inside a protocol 🍓
Transport Service Instance 🌈: an arrangement of transport protocols with a selected set of features and configuration parameters that implements a single transport service. Think of a protocol stack, like RTP over UDP. It's giving layers 😭
Application 💖: an entity that uses the transport layer for end-to-end delivery of data across the network. This can also be an upper-layer protocol or a tunnel encapsulation, which is so cool 🙈
Endpoint ⭐: an entity that talks to one or more other endpoints using a transport protocol 🫶
Connection 🔥: shared state of two or more endpoints that persists across the messages sent between them. Main character energy for state 💅
Primitive ✨: a function call used to communicate locally between an application and a transport endpoint. A primitive is related to one or more transport features 🦋
Event 🌸: a primitive that is invoked by a transport endpoint. So the endpoint is the one calling the shots here 👑
Parameter 🎀: a value passed between an application and a transport protocol by a primitive 🍓
Socket 💜: the combination of a destination IP address and a destination port number 🌈
Transport Address 🧚: the combination of an IP address, a transport protocol, and the port number used by that transport protocol. Lowkey the full address package 🫶

3. Pass 1 🌸

okay so this first pass is basically a highlight reel 🎬 it summarizes the relevant bits of the RFCs that describe the protocols, and it focuses on what each transport protocol gives the application and how it gets used. Where they exist, it also pulls in the abstract API descriptions ✨

one thing to know: when we talk about primitives, events, and parameters, we make the capitalization uniform so everything reads nicely 💖 no cap, it's about readability, not changing what anything means 🙈

3.1. Primitives Provided by TCP

Okay bestie, this is the big list of everything TCP hands to apps 💖 It starts with the original 1981 pitch, which says "The Transmission Control Protocol (TCP) is intended for use as a highly reliable host-to-host protocol between hosts in packet-switched computer communication networks, and in interconnected systems of such networks." ✨

Then [RFC0793] goes on to list a bunch of transport primitives in its Section 3.8, which is where the app-facing side lives 🧚 We also assume the operating system has a way for TCP to tap the app on the shoulder asynchronously. Those taps are called 'events' here, so keep that in mind 👀 Let's get into it.

Open: This one is either active or passive, and it's how you start a connection or listen for incoming ones 🚪 Every other primitive is tied to one specific connection, and that connection is assumed to already be opened. An active open call takes a socket. A passive open call with a socket waits for one particular connection, but if you leave the socket unspecified, it'll accept any incoming connection 🌈 A fully specified passive call can later become active by calling 'Send' 💅

You can also set a timeout. If the data hasn't been successfully delivered to the destination by then, TCP aborts the connection, and if you don't set one, a default timeout value gets used ⏰ The abort procedure exists to stop excessive retransmissions, and the app can control the threshold that decides when to abort. That threshold can be measured in time units or as a count of retransmissions [RFC1122]. So yes, the timeout can also be specified as a count of retransmissions 🍓

Also optional, for multihomed hosts, is the local IP address [RFC1122]. If you don't give one, a default gets picked for active opens. A passive open will wait for incoming connection requests to all local addresses, then stick with the local IP address where the request actually showed up 🦋 The 'options' parameter lets the app specify IP options like Source Route, Record Route, or Timestamp [RFC1122]. The text doesn't say which segments of a connection those options should apply to, but probably all of them, since that's also how the Source Route IP option spec reads (Section 4.2.3.8 of [RFC1122]) 🤔 Source Route is the only non-optional IP option in this parameter, and it lets an app specify a source route when it actively opens a TCP connection 💜

Master Key Tuples (MKTs) for authentication can optionally be configured when calling 'Open' (Section 7.1 of [RFC5925]) 🔐 When authentication is in use, complete TCP segments get authenticated, including the TCP IPv4 pseudoheader, the TCP header, and the TCP data 🫶

TCP Fast Open (TFO) [RFC7413] is so cute. It lets apps hand over a message from the active open side to the passive open side together with the first establishment packet (the SYN) 🚀 That's useful for apps that are sensitive to TCP's connection setup delay. [RFC7413] says "TCP implementations MUST NOT use TFO by default, but only use TFO if requested explicitly by the application on a per-service-port basis." The TFO message can't be bigger than TCP's maximum segment size, minus whatever options are used in the SYN 📏 On the active open side, it's recommended to change or replace the connect() call so it supports a user data buffer argument [RFC7413]. On the passive open side, the app has to turn on reception of Fast Open requests, for example with a new TCP_FASTOPEN setsockopt() socket option before listen() 🛠️ And the receiving app has to be ready for duplicates of the TFO message, because the first data written to a socket can get delivered more than once to the app on the remote host 🙈

Send: This is the primitive an app uses to hand the local TCP endpoint some bytes that TCP should reliably send to the other side 📨 The 'urgent' flag, when set, says the data in this send call is urgent, and that urgency should be shown to the receiving process if it hasn't yet consumed all the non-urgent data that came before it 🚨 An optional timeout parameter can be given to update the connection's timeout (see 'Open') ⏳ There are also optional parameters for indicating the preferred outgoing MKT (current_key) and/or the preferred incoming MKT (rnext_key) of a connection (Section 7.1 of [RFC5925]) 🔑

Receive: This one allocates a receiving buffer for a given number of bytes 📥 It returns the number of received bytes that were put in the buffer, once those bytes have actually been received and written into it by TCP. The app learns about urgent data through an 'urgent' flag. If it's on, there is urgent data. If it's off, either there is no urgent data or this 'Receive' call has already returned all of it 🫧 The app is also told about the current_key and rnext_key info carried in a recently received segment, through an optional parameter (Section 7.1 of [RFC5925]) 🗝️

Close: This one closes one side of a connection. It basically means "I have no more data to send," but it does NOT mean "I will not receive any more," because the other side might still have data to send 👋 It reliably delivers any data already given to TCP, and if that delivery fails, 'Close' turns into 'abort' 💀

Abort: This one makes all pending 'Send' and 'Receive' calls get aborted. A TCP "RESET" message is sent to the TCP endpoint on the other side of the connection [RFC0793] 🥀

Close Event: TCP uses this to tell the app that the app on the other side has called 'Close'. That way the local app can also issue a 'Close' and end the connection gracefully 🤝 See [RFC0793], Section 3.5.

Abort Event: When TCP aborts a connection after receiving a "RESET" from the peer, it "advises the user and goes to the CLOSED state." 🚫 See [RFC0793], Section 3.4.

User Timeout Event: This fires when the user timeout (Section 3.9 of [RFC0793]) expires, which is the timeout you can set under 'Open' in this section ⌛ All queues get flushed, and the app is told the connection had to be aborted because of the user timeout 😭

Error_Report event: This one tells the app about "soft errors" that can be safely ignored [RFC5461] 🌸 That includes the arrival of an ICMP error message, or excessive retransmissions that hit a threshold below the point where the connection gets aborted. See Section 4.2.4.1 of [RFC1122] ✨

Type-of-Service: Section 4.2.4.2 of the requirements for Internet hosts [RFC1122] says "The application layer MUST be able to specify the Type-of-Service (TOS) for segments that are sent on a connection." 💅 The app should be able to change the TOS during the connection's lifetime, and the TOS value should get passed to the IP layer unchanged. The TOS field has since been redefined, though 🔄 The Differentiated Services (Diffserv) model [RFC2475] [RFC3260] replaces that field in the IP header. It uses the six most significant bits to carry the Differentiated Services Code Point (DSCP) field [RFC2474] 🌈

Nagle: The Nagle algorithm delays sending data for a bit so there's a better chance of sending a full-sized segment (Section 4.2.3.4 of [RFC1122]) 🧁 An app can disable the Nagle algorithm for an individual connection.

User Timeout Option: The User Timeout Option (UTO) [RFC5482] lets one end of a TCP connection advertise its current user timeout value, so the other end can adapt its own user timeout to match 🦋 On top of the configurable user timeout value (see 'Send'), there are three per-connection state variables an app can adjust to control how the UTO works. adv_uto is the UTO value advertised to the remote TCP peer (default: the system-wide default user timeout). enabled (default false) is a boolean flag that controls whether the UTO option is turned on for a connection, and it applies to both sending and receiving. changeable is a boolean flag (default true) that controls whether the user timeout may be changed based on a UTO option received from the other end of the connection. changeable becomes false when an app explicitly sets the user timeout (see 'Send') 🔒

Set/Get Authentication Parameters: The preferred outgoing MKT (current_key) and/or the preferred incoming MKT (rnext_key) of a connection can be configured 🔐 Info about current_key and rnext_key carried in a recently received segment can be retrieved (Section 7.1 of [RFC5925]) 💜

3.1.1. Excluded Primitives or Parameters

The 'Open' primitive can take optional precedence or security/compartment information [RFC0793], but we left that out because it's mostly irrelevant today [RFC7414] 🙅‍♀️

We also left out 'Status' 🥱 The initial TCP spec calls this primitive "implementation dependent" and says it "could be excluded without adverse effect" [RFC0793]. It also describes a data block with specific information, but says not all of that information may always be available. [RFC5925] says 'Status' "SHOULD be augmented to allow the MKTs of a current or pending connection to be read (for confirmation)". But that same info is also available through 'Receive', which, following [RFC5925], "MUST be augmented" with that functionality 🧠

The 'Send' primitive has an optional 'push' flag which, if set, requires data to be promptly transmitted to the receiver without delay [RFC0793]. The 'Receive' primitive described in can (under some conditions) yield the status of the 'push' flag. Because "push" functionality is optional to implement for both the 'Send' and 'Receive' primitives [RFC1122], we didn't include it here 🫠 The requirements for Internet hosts [RFC1122] also bring keep-alives into TCP, but those are optional to implement, so they're not considered here either. That same document also says "some TCP implementations have included a FLUSH call," which means this call is optional too, so it's not considered here 🌷

3.2. Primitives Provided by MPTCP ✨

okay so MPTCP is basically TCP's glow-up 💖 it lets a single data stream use multiple paths at once 🦋 the way it works is it makes different so-called TCP subflows for each of the interfaces and then schedules the traffic across those subflows. the service it gives is described like this in [RFC6182]:

Multipath TCP MUST follow the same service model as TCP [RFC0793]: in-order, reliable, and byte-oriented delivery. Furthermore, a Multipath TCP connection SHOULD provide the application with no worse throughput or resilience than it would expect from running a single TCP connection over any one of its available paths.

there are also some constraints on the API that MPTCP shows, as stated in [RFC6182] 👀

A multipath-capable equivalent of TCP MUST retain some level of backward compatibility with existing TCP APIs, so that existing applications can use the newer transport merely by upgrading the operating systems of the end hosts.

so honestly the primitives MPTCP gives you are equivalent to the ones TCP gives you 💅 BUT the MPTCP RFCs [RFC6824] and [RFC6897] clarify some parts of TCP's primitives for MPTCP and add some extensions for better control over MPTCP's subflows. here's the list of those clarifications and extensions from the RFCs I just mentioned, lowkey my favorite part 🎀

Open: "An application should be able to request to turn on or turn off the usage of MPTCP" [RFC6897]. this functionality can be provided through a socket option called tcp_multipath_enable. also, MPTCP must be disabled in case the application is binding to a specific address [RFC6897] 🙈

Send/Receive: sending and receiving data doesn't need any changes to the application when MPTCP is being used [RFC6824] 🫶 the MPTCP layer takes one input data stream from an application and splits it into one or more subflows, with enough control information that it can be reassembled and delivered reliably and in order to the receiving application.

the Urgent Pointer is special in MPTCP [RFC6824], which states: "a TCP subflow MUST NOT use the Urgent Pointer to interrupt an existing mapping." no cap, this one is a whole vibe 💀

Address and Subflow Management: MPTCP uses different addresses and lets a host announce these addresses as part of the protocol 🌸 the MPTCP API Considerations RFC [RFC6897] says "An application should be able to restrict MPTCP to binding to a given set of addresses", so applications can limit the set of addresses MPTCP uses ✨ it also says "An application should be able to obtain information on the pairs of addresses used by the MPTCP subflows." iconic, honestly 👑

3.3. Primitives Provided by SCTP 🧚

TCP has a bunch of limitations that SCTP removes (Section 1.1 of [RFC4960]) 🍓 three of those removed limitations turn directly into transport features an application using SCTP can actually see: 1) it preserves message delimiters; 2) it doesn't provide in-order or reliable delivery unless the application wants that; 3) multihoming is supported. in SCTP, connections are called "associations", and they can be between not just two endpoints (like in TCP) but multiple addresses at each endpoint 🦋

Section 10 of the SCTP base protocol specification [RFC4960] covers the interaction with the application, which SCTP calls the "Upper-Layer Protocol (ULP)" 💜 it's assumed the Operating System provides a way for SCTP to asynchronously signal the application, and the primitives representing those signals are called 'events' in this section. we describe the relevant primitives here ✨ on top of the abstract API in Section 10 of [RFC4960], there's an extension to the sockets API described in [RFC6458]. it covers the base protocol [RFC4960] and some of its extensions [RFC3758] [RFC4895] [RFC5061]. for other protocol extensions [RFC6525] [RFC6951] [RFC7053] [RFC7496] [RFC7829] [RFC8260], the matching sockets API extensions are specified in those protocol specs themselves. all the functionality exposed to the ULP through these APIs is considered here 🫶

the abstract API has a 'SetProtocolParameters' primitive that lets elements of a parameter list [RFC4960] get adjusted. it's stated that SCTP implementations "may allow ULP to customize some of these protocol parameters", which basically means none of the elements in this parameter list are mandatory to make the ULP configurable 🙈 so we only consider the parameters in the abstract API that are also covered in one of the other RFCs listed above, which leads us to exclude 'RTO.Alpha', 'RTO.Beta', and 'HB.Max.Burst'. for clarity, we also replace 'SetProtocolParameters' itself with primitives that adjust parameters or groups of parameters that fit together 💅

Initialize: Initialize creates a local SCTP instance that it binds to a set of local addresses (and, if provided, a local port number) [RFC4960]. Initialize only needs to be called once per set of local addresses 🎀 a number of per-association initialization parameters can be used when an association is created but before it's connected (via the primitive 'Associate' below): the maximum number of inbound streams the application is prepared to support, the maximum number of attempts to be made when sending the INIT (the first message of association establishment), and the maximum retransmission timeout (RTO) value to use when attempting an INIT [RFC6458]. right before connecting, an application can also enable UDP encapsulation by configuring the remote UDP encapsulation port number [RFC6951] 🦋

Associate: this creates an association (the SCTP version of a connection) that connects the local SCTP instance and a remote SCTP instance 💖 to identify the remote endpoint, it can be given one or multiple sockets (using "connectx") (Section 9.9 of [RFC6458]). most primitives are tied to a specific association, which is assumed to have been created first. Associate can return a list of destination transport addresses so multiple paths can be used later 🌈 one of the returned sockets gets selected by the local endpoint as the default primary path for sending SCTP packets to this peer, but the application can change that choice using the list of destination addresses. Associate is also given the number of outgoing streams to request, and optionally returns the number of negotiated outgoing streams. an optional 32-bit adaptation layer indication can be provided [RFC5061]. if authenticated chunks are used, the chunk types required to be sent authenticated by the peer can be provided [RFC4895]. an 'SCTP_Cant_Str_Assoc' notification is used to tell the application that creating an association failed [RFC6458] 😭 an application could use sendto() or sendmsg() to implicitly set up an association, handing over a message that SCTP might send during the association setup phase [RFC6458]. note that this is different from TCP's TFO mechanism: the message would arrive only once, after at least one RTT, because it's sent together with the third message exchanged during association setup, the COOKIE-ECHO chunk ✨

Send: this sends a message of a certain length in bytes over an association 🍓 a number can be provided so the right message can be referred to later when reporting an error, and a stream id is provided to specify which stream inside the association to use (we treat this as a mandatory parameter here for simplicity: if it's not provided, the stream id defaults to 0). a condition to abandon the message can be specified, like limiting the number of retransmissions or the lifetime of the user message, which lets you control the partial reliability extension [RFC3758] [RFC7496] 👑 an optional maximum lifetime can say how long after which the message should be discarded rather than sent. a choice of preferred path can be made by providing a socket. this one is advisory, meaning it's not guaranteed 🫶 the message can also be delivered out-of-order if the 'unordered' flag is set. an advisory flag says the peer should not delay the acknowledgement of the user message provided [RFC7053] 🙈 another advisory flag shows 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 tells the peer what type of payload protocol data it is. if authenticated chunks are used, the key identifier for authenticating DATA chunks can be provided [RFC4895] 💅

Receive: messages are received from an association, and optionally from a stream within it, with their size returned 🦋 the application gets notified that data is available via a 'Data Arrive' notification. if the sender included a payload protocol-id, that value comes back too. if the received message is only a partial delivery of a whole message, a 'partial' flag will say so, and in that case the stream id and a stream sequence number are handed to the application 🌸

Shutdown: this primitive gracefully closes an association, reliably delivering any data already handed over to SCTP 🎀 a parameter lets the application control whether further receive operations, send operations, or both are disabled when the call is issued. a return code tells you whether the procedure succeeded or failed ✨

Abort: this ungracefully closes an association by discarding any locally queued data and informing the peer that the association was aborted 💀 optionally, the application can provide an abort reason to pass to the peer. a return code tells you whether this procedure succeeded or failed 😭

Change Heartbeat / Request Heartbeat: this lets the application enable or disable heartbeats, optionally specify a heartbeat frequency, or request a single heartbeat in one function call 💖 it comes with a notification about whether transmitting the HEARTBEAT chunk to the destination succeeded or failed 🧚

Configure Max. Retransmissions of an Association: the parameter 'Association.Max.Retrans' [RFC4960] (called "sasoc_maxrxt" in the SCTP sockets API extensions [RFC6458]) lets you configure how many unsuccessful retransmissions it takes before an entire association is considered failed. that should invoke a 'Communication Lost' notification 🌈

Set Primary: this lets you set a new primary default path for an association by providing a socket. optionally, a default source address to be used in IP datagrams can be provided too 👑

Change Local Address / Set Peer Primary: this lets an endpoint add or remove local addresses to and from an association 🫶 on top of that, the peer can be given a hint about which address to use as the primary address [RFC5061] 🍓

Configure Path Switchover: okay bestie, this one is giving main character energy 💅 The abstract API has a primitive called 'Set Failure Threshold' [RFC4960]. It configures 'Path.Max.Retrans', which decides after how many retransmissions a transport address counts as unreachable. If there are more transport addresses in an association, hitting that limit kicks off a path switchover 🔥 An extension called "SCTP-PF" adds the idea of "Potentially Failed (PF)" paths to this method [RFC7829]. When a path is in PF state, SCTP doesn't totally give up sending on it, but it'll prefer other active paths if they're available ✨ Entering PF state happens once a configured maximum number of retransmissions is exceeded. So for every path using this mechanism there are two error thresholds you can configure: one to decide that a path is in PF state, and one to decide that the transport address is unreachable 🫶

Set/Get Authentication Parameters: this lets an endpoint add or remove key material to and from an association 🔐 The chunk types being authenticated can also be queried [RFC4895].

Add/Reset Streams, Reset Association: this lets an endpoint add streams to an existing association or reset them one by one 🌸 The association itself can also be reset [RFC6525].

Status: the 'Status' primitive returns a data block with info about a specified association 📊 It's a whole list, so hold on: an association connection state; a destination transport address list; destination transport address reachability states; current local and peer receiver window sizes; current local congestion window sizes; number of unacknowledged DATA chunks; number of DATA chunks pending receipt; a primary path; the most recent Smoothed Round-Trip Time (SRTT) on a primary path; RTO on a primary path; SRTT and RTO on other destination addresses [RFC4960]; and an MTU per path [RFC6458]. Iconic 🍓

Enable/Disable Interleaving: this allows the negotiation of user message interleaving support for future associations to be turned on or off 🦋 For existing associations, you can query whether user message interleaving support was negotiated on a particular association [RFC8260].

Set Stream Scheduler: this lets you pick a stream scheduler per association, with a choice of: First-Come, First-Served; Round-Robin; Round-Robin per Packet; Priority-Based; Fair Bandwidth; and Weighted Fair Queuing [RFC8260]. So many options, bestie 🧚

Configure Stream Scheduler: this lets you change a per-stream parameter for the schedulers: a priority value for the Priority-Based scheduler and a weight for the Weighted Fair Queuing scheduler ⭐

Enable/Disable NoDelay: this turns any Nagle-like algorithm for an association on or off [RFC6458] 🌈

Configure Send Buffer Size: this controls how much data SCTP may have waiting in internal buffers to be sent or retransmitted [RFC6458] 📦

Configure Receive Buffer Size: this sets the receive buffer size in octets, which controls the receiver window for an association [RFC6458] 🎀

Configure Message Fragmentation: if a user message causes an SCTP packet to exceed the maximum fragmentation size (the application can provide this, and otherwise it's the Path MTU (PMTU) size), then SCTP fragments the message 💖 Disabling message fragmentation produces an error instead of fragmenting the message [RFC6458].

Configure Path MTU Discovery: Path MTU Discovery (PMTUD) can be enabled or disabled per peer address of an association (Section 8.1.12 of [RFC6458]) 🔍 When it's enabled, you can get the current Path MTU value. When it's disabled, the application controls which Path MTU gets used 🧠

Configure Delayed SACK Timer: you can adjust the time before sending a SACK, turn off delaying SACKs, and configure how many packets must be received before a SACK goes out without waiting for the delay timer to expire [RFC6458] ⏰

Set Cookie Life Value: the cookie life value can be adjusted (Section 8.1.2 of [RFC6458]) 🍪 'Valid.Cookie.Life' is also one of the parameters that can potentially be adjusted with 'SetProtocolParameters' [RFC4960].

Set Maximum Burst: the maximum burst of packets that a particular association can emit (default 4, and values above 4 are optional to implement) can be adjusted (Section 8.1.2 of [RFC6458]) 💨 'Max.Burst' is also one of the parameters that can potentially be adjusted with 'SetProtocolParameters' [RFC4960].

Configure RTO Calculation: the abstract API has these adjustable parameters: 'RTO.Initial'; 'RTO.Min'; 'RTO.Max'; 'RTO.Alpha'; and 'RTO.Beta' 🧮 Only the initial, minimum and maximum RTOs are also described as configurable in the SCTP sockets API extensions [RFC6458].

Set DSCP Value: the DSCP value can be set per peer address of an association (Section 8.1.12 of [RFC6458]) 🏷️

Set IPv6 Flow Label: the flow label field can be set per peer address of an association (Section 8.1.12 of [RFC6458]) 🌊

Set Partial Delivery Point: this lets you specify the size of a message at which partial delivery gets invoked. Setting it lower means partial deliveries happen more often [RFC6458] 📬

Communication Up Notification: when a lost communication to an endpoint is restored, or when SCTP becomes ready to send or receive user messages, this notification tells the application process about the affected association 📣 It also says what kind of event happened, gives the complete set of sockets of the peer, the maximum number of allowed streams, and the inbound stream count (the number of streams the peer endpoint has requested). If both endpoints support interleaving, this info is included in the notification too 💜

Restart Notification: when SCTP detects that the peer has restarted, this notification gets passed up to the upper layer [RFC6458] 🔄

Data Arrive Notification: when a message is ready to be retrieved via the 'Receive' primitive, the application gets told about it with this notification 📨

Send Failure Notification / Receive Unsent Message / Receive Unacknowledged Message: when a message can't be delivered via an association, the sender can be informed about it and learn whether the message was just not acknowledged or (for example, if its lifetime expired) never even sent 😭 This can also tell the sender that part of the message was delivered successfully.

Network Status Change Notification: this tells the application when a socket becomes active or inactive [RFC4960], or "Potentially Failed" [RFC7829] 🚦

Communication Lost Notification: when SCTP loses communication to an endpoint (for example via heartbeats or excessive retransmission) or detects an abort, this notification tells the application process about the affected association and the type of event (failure OR termination in response to a shutdown or abort request) 💀

Shutdown Complete Notification: when SCTP completes the shutdown procedures, this notification is passed up to the upper layer, telling it about the affected association 🌙

Authentication Notification: when SCTP wants to tell the upper layer about the key management for authenticated chunks [RFC4895], this notification gets passed up 🗝️

Adaptation Layer Indication Notification: when SCTP completes association setup and the peer provided an adaptation layer indication, that gets passed to the upper layer [RFC5061] [RFC6458] 🧩

Stream Reset Notification: when SCTP completes the procedure for resetting streams [RFC6525], this notification is passed up, telling the upper layer the result 🔁

Association Reset Notification: when SCTP completes the association reset procedure [RFC6525], this notification is passed up, telling the upper layer the result 🔁

Stream Change Notification: when SCTP completes the procedure used to increase the number of streams [RFC6525], this notification is passed up, telling the upper layer the result 📈

Sender Dry Notification: when SCTP has no more user data to send or retransmit on a particular association, this notification is passed up to the upper layer [RFC6458] 🏜️

Partial Delivery Aborted Notification: when a receiver has started receiving parts of a user message but then the delivery is aborted, this notification is passed up to the upper layer (Section 6.1.7 of [RFC6458]) 🚫

3.3.1. Excluded Primitives or Parameters 🙈

The 'Receive' primitive can return certain extra information, but that's optional to implement, so it isn't considered here. With a 'Communication Lost' notification, some more information may optionally be passed to the application (for example, identification to retrieve unsent and unacknowledged data). SCTP "can invoke" a 'Communication Error' notification and "may send" a 'Restart' notification, which makes these two notifications optional to implement 🤷‍♀️ The list under 'Status' includes "etc.", which means more info could be provided. The primitive 'Get SRTT Report' returns information that's already included in what 'Status' provides, so it isn't discussed. The 'Destroy SCTP Instance' API function was excluded: it erases the SCTP instance that 'Initialize' created, but it isn't a primitive as defined in this document because it doesn't relate to a transport feature. The 'Shutdown' event tells an application that the peer has sent a SHUTDOWN, so no further data should be sent on this socket (Section 6.1 of [RFC6458]). However, if an application tried to send data on the socket anyway, it would get an error message, so this event is classified as "just affecting the application programming style, not how the underlying protocol operates" and isn't included here 💅

3.4. Primitives Provided by UDP and UDP-Lite 🦋

The set of pass 1 primitives for UDP and UDP-Lite is documented in [RFC8304] 🌸

3.5. The Service of LEDBAT 🦋

okay bestie, so LEDBAT's service is described like this 💅

LEDBAT is built for background bulk-transfer apps, so it's supposed to be no more aggressive than standard TCP congestion control (as specified in RFC 5681), and it has to yield when other flows are competing. That way it doesn't mess with the network performance of the flows it's sharing the road with [RFC6817] 🚗💨

LEDBAT has no primitives, because LEDBAT is not a transport protocol 🙈 According to its spec [RFC6817]:

LEDBAT can be used as part of a transport protocol or as part of an application, as long as the data transmission mechanisms are capable of carrying timestamps and acknowledging data frequently. LEDBAT can be used with TCP, Stream Control Transmission Protocol (SCTP), and Datagram Congestion Control Protocol (DCCP), with appropriate extensions where necessary; and it can be used with proprietary application protocols, such as those built on top of UDP for peer-to-peer (P2P) applications.

At the time of writing, the appropriate extensions for TCP, SCTP, or DCCP do not exist 😭

There are a bunch of configurable parameters in the LEDBAT spec, and they're giving main character energy 👑

TARGET is the queuing delay target that LEDBAT tries to operate at. It must be set to 100 ms or less ⏱️
allowed_increase should be 1, and it must be greater than 0. It limits how fast LEDBAT ramps up its rate 📈
gain: according to [RFC6817], it "MUST be set to 1 or less" so it doesn't ramp up faster than TCP Reno 🐢. It decides how quickly the sender responds to changes in queueing delay. Implementations may split gain into two parameters, one for increase and a possibly bigger one for decrease. We call those Gain_Inc and Gain_Dec here 🧁
Base_History is the size of the list of measured base delays. According to [RFC6817], it "SHOULD be 10" 📝
This list can be filtered using a Filter function. The spec doesn't prescribe it [RFC6817], and it yields a list of size Current_Filter 🧹
The initial and minimum congestion windows, Init_CWND and Min_CWND, should both be 2 🪟

Now, which of these should an application control? It's a whole spectrum 🌈 On one end, the app exposes nothing at all. On the other end, the app gets to tune everything that the spec doesn't lock down with a "MUST." Function implementations aren't offered as a parameter to any of the transport protocols we're talking about, so we don't count the Filter function as a parameter 🙅‍♀️ But so we don't accidentally box in future implementations, we treat every other parameter above as tunable, and they should be exposed ✨

4. Pass 2 ✨

Pass 2 sorts the primitives from pass 1 by whether they're about a connection or about data transmission 🗂️ Each primitive follows the naming pattern CATEGORY.[SUBCATEGORY].PRIMITIVENAME.PROTOCOL. The CATEGORY can be CONNECTION or DATA. Inside CONNECTION you can look at ESTABLISHMENT, AVAILABILITY, MAINTENANCE, and TERMINATION subcategories. DATA doesn't have any SUBCATEGORY. The PROTOCOL name UDP(-Lite) is used when the primitives are the same for UDP and UDP-Lite, and TCP covers both TCP and MPTCP 💖

"Connection" is the general, protocol-independent concept we use for stuff like TCP connections (identified by a unique pair of IP addresses and TCP port numbers), SCTP associations (identified by multiple IP address and port number pairs), and UDP and UDP-Lite connections (identified by a unique socket pair) 🔗

Some minor details get left out to keep things generic. For example, SCTP's 'Close' [RFC4960] returns success or failure and lets the app control whether receive or send operations (or both) get disabled [RFC6458]. TCP doesn't describe this the same way [RFC0793], but these details don't matter for the primitives in either protocol. To stay generic, you can assume both receive and send operations get disabled in both cases 🤷‍♀️

The TCP 'Send' and 'Receive' primitives have an 'urgent' parameter. It controls the mechanism needed to build the "synch signal" that telnet uses [RFC0854]. But [RFC6093] says "new applications SHOULD NOT employ the TCP urgent mechanism." Since pass 2 is meant to be the basis for future systems, we're leaving out the "urgent" mechanism 🚫 This also covers the 'Urgent Pointer Advance' notification in 'Error_Report' (Section 4.2.4.1 of [RFC1122]) 🙅‍♀️

LEDBAT is a congestion control mechanism, not a protocol, so the spec doesn't say when to enable, disable, or configure it 🤔 For example, you could pick it once when a connection gets established, or when you're listening for incoming connections. In those cases it would go under CONNECTION.ESTABLISHMENT or CONNECTION.AVAILABILITY, respectively. To avoid boxing in future implementations, we put it under CONNECTION.MAINTENANCE, and every parameter described in the spec [RFC6817] is made configurable 🎀

ESTABLISHMENT:

This is the active creation of a connection from one transport endpoint to one or more transport endpoints. The UDP and UDP-Lite interfaces let you use the API in both connection-oriented and connection-less ways [RFC8085] 🌸

CONNECT.TCP:

Pass 1 primitive/event: 'Open' (active) or 'Open' (passive) with socket, followed by 'Send'

Parameters: 1 local IP address (optional); 1 destination transport address (for active open; else the socket and the local IP address of the succeeding incoming connection request will be maintained); timeout (optional); options (optional); MKT configuration (optional); and user message (optional)

Comments: if the local IP address isn't provided, a default choice gets made automatically. The timeout can also be a retransmission count. The options are IP options to be used on all segments of the connection. At least the Source Route option is mandatory for TCP to provide. 'MKT configuration' refers to the ability to configure MKTs for authentication. The user message may be sent to the peer app as soon as the TCP SYN packet is received. To get the lower latency this gives as part of the experimental TFO mechanism, its length must be at most the TCP's maximum segment size (minus the TCP options used in the SYN) ⚡ The message may also be delivered more than once to the app on the remote host 👀

CONNECT.SCTP:

Pass 1 primitive/event: 'Initialize', followed by 'Enable/Disable Interleaving' (optional), followed by 'Associate'

Parameters: list of local SCTP port number / IP address pairs ('Initialize'); one or several sockets (identifying the peer); outbound stream count; maximum allowed inbound stream count; adaptation layer indication (optional); chunk types required to be authenticated (optional); request interleaving on/off; maximum number of INIT attempts (optional); maximum init. RTO for INIT (optional); user message (optional); and remote UDP port number (optional)

Returns: socket list or failure

Comments: 'Initialize' needs to be called only once per list of local SCTP port number / IP address pairs. One socket gets chosen automatically, and you can change it later in MAINTENANCE 🔄 The user message may be sent to the peer app as soon as the packet with the COOKIE-ECHO chunk arrives. To get the lower latency this provides, its length must be limited so it fits into the packet containing the COOKIE-ECHO chunk 🍓 If a remote UDP port number is provided, SCTP packets get encapsulated in UDP 📦

CONNECT.MPTCP:

This is similar to CONNECT.TCP, except for one extra boolean parameter that lets you enable or disable MPTCP for a particular connection or socket (default: enabled) 🧚

CONNECT.UDP(-Lite):

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); and 1 destination port (default (OS chooses) or specified).

Comments: this associates a transport address and creates a UDP(-Lite) socket connection. You can call it again with a new transport address to make a new connection. The CONNECT function lets an app receive errors from messages sent to a transport address 🫶

AVAILABILITY:

This is getting ready to receive incoming connection requests 👂

LISTEN.TCP:

Pass 1 primitive/event: 'Open' (passive)

Parameters: 1 local IP address (optional); 1 socket (optional); timeout (optional); buffer to receive a user message (optional); and MKT configuration (optional)

Comments: if the socket and/or local IP address is provided, this waits for incoming connections from only and/or to only the provided address. Otherwise it waits for incoming connections without those constraints. ESTABLISHMENT can be done later with 'Send'. If you provide a buffer to receive a user message, a user message can come in from a TFO-enabled sender before the TCP connection handshake is finished. This message may arrive multiple times. 'MKT configuration' refers to the ability to configure MKTs for authentication 🎟️

LISTEN.SCTP:

Pass 1 primitive/event: 'Initialize', followed by the 'Communication Up' or 'Restart' notification and possibly the 'Adaptation Layer' notification

Parameters: list of local SCTP port number / IP address pairs (initialize)

Returns: socket list; outbound stream count; inbound stream count; adaptation layer indication; chunks required to be authenticated; and interleaving supported on both sides yes/no

Comments: 'Initialize' needs to be called only once per list of local SCTP port number / IP address pairs. 'Communication Up' can also follow a 'Communication Lost' notification, which means the lost communication has been restored 💪 If the peer has provided an adaptation layer indication, an 'Adaptation Layer' notification gets issued ✅

LISTEN.MPTCP:

This is similar to LISTEN.TCP, except for one extra boolean parameter that lets you enable or disable MPTCP for a particular connection or socket (default: enabled) 🌈

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); and destination port (default (OS chooses) or specified)

Comments: the 'Receive' function registers the app to listen for incoming UDP(-Lite) datagrams at an endpoint 📬

MAINTENANCE:

Okay so the vibe here is "the app is in control of the connection, and the connection is listening," and I am obsessed 🫶 These are out-of-band messages to the protocol that can show up any time after a connection is established and before it's terminated, with one exception: CHANGE_TIMEOUT.TCP can only be issued for an open connection when DATA.SEND.TCP is called 🙈 Sometimes these can also be issued during ESTABLISHMENT or AVAILABILITY, before the connection is even opened. For example, CHANGE_TIMEOUT.TCP can be done with TCP's 'Open' primitive ✨ For UDP and UDP-Lite, these functions can set something per connection, but they can also be changed per datagram 🦋

CHANGE_TIMEOUT.TCP 💖
- Pass 1 primitive/event: 'Open' or 'Send', combined with unspecified control of per-connection state variables
- Parameters: timeout value (optional); adv_uto (optional); boolean uto_enabled (optional, default false); and boolean changeable (optional, default true)
- Comments: when you're sending data, the app can adjust the connection's timeout value, which is the time after which the connection gets aborted if the data can't be delivered 😭 If uto_enabled is true, the timeout value (or adv_uto, if it's provided) gets advertised so the TCP on the other side can adapt its own user timeout. uto_enabled decides whether the UTO option is turned on for a connection, and this applies to both sending and receiving. changeable decides whether the user timeout is allowed to change based on a UTO option received from the other end. It flips to false when the timeout value gets used 💅
CHANGE_TIMEOUT.SCTP 🦋
- Pass 1 primitive/event: 'Change Heartbeat' combined with 'Configure Max. Retransmissions of an Association'
- Parameters: 'Change Heartbeat': heartbeat frequency and 'Configure Max. Retransmissions of an Association': Association.Max.Retrans
- Comments: 'Change Heartbeat' can turn heartbeats on or off in SCTP, and it can also change how often they happen 🌸 The Association.Max.Retrans parameter defines how many unsuccessful transmissions of any packets (heartbeats included) it takes before the association is terminated. So these two primitives and parameters together can give SCTP associations a similar vibe to what CHANGE_TIMEOUT.TCP does for TCP connections 🧚
DISABLE_NAGLE.TCP 🙈
- Pass 1 primitive/event: not specified
- Parameters: one boolean value
- Comments: the Nagle algorithm delays data transmission to increase the chance of sending a full-sized segment. An application must be able to disable this algorithm for a connection 🎀
DISABLE_NAGLE.SCTP 💅
- Pass 1 primitive/event: 'Enable/Disable NoDelay'
- Parameters: one boolean value
- Comments: Nagle-like algorithms delay data transmission to increase the chance of sending a full-sized packet ✨
REQUEST_HEARTBEAT.SCTP 💜
- Pass 1 primitive/event: 'Request Heartbeat'
- Parameters: socket
- Returns: success or failure
- Comments: this requests an immediate heartbeat on a path and returns success or failure 🫶
ADD_PATH.MPTCP 🌈
- Pass 1 primitive/event: not specified
- Parameters: local IP address and optionally the local port number
- Comments: the application specifies the local IP address and port number that must be used for a new subflow 🦋
ADD_PATH.SCTP 🧚
- Pass 1 primitive/event: 'Change Local Address / Set Peer Primary'
- Parameters: local IP address
REM_PATH.MPTCP 🍓
- Pass 1 primitive/event: not specified
- Parameters: local IP address; local port number; remote IP address; and remote port number
- Comments: the application removes the subflow specified by the IP/port-pair. The MPTCP implementation must trigger a removal of the subflow that belongs to this IP/port-pair 😭
REM_PATH.SCTP 🌸
- Pass 1 primitive/event: 'Change Local Address / Set Peer Primary'
- Parameters: local IP address
SET_PRIMARY.SCTP 👑
- Pass 1 primitive/event: 'Set Primary'
- Parameters: socket
- Returns: result of attempting this operation
- Comments: this updates the current primary address to be used, based on the set of available sockets of the association 💖
SET_PEER_PRIMARY.SCTP 🫶
- Pass 1 primitive/event: 'Change Local Address / Set Peer Primary'
- Parameters: local IP address
- Comments: this is only advisory for the peer 🙈
CONFIG_SWITCHOVER.SCTP 🔥
- Pass 1 primitive/event: 'Configure Path Switchover'
- Parameters: primary max retrans (number of retransmissions after which a path is considered inactive) and PF max retrans (number of retransmissions after which a path is considered to be "Potentially Failed", and others will be preferably used) (optional)
STATUS.SCTP 🎀
- Pass 1 primitive/event: 'Status', 'Enable/Disable Interleaving', and 'Network Status Change' notification
- Returns: data block with information about a specified association, containing: association connection state; destination transport address list; destination transport address reachability states; current local and peer receiver window sizes; current local congestion window sizes; number of unacknowledged DATA chunks; number of DATA chunks pending receipt; primary path; most recent SRTT on primary path; RTO on primary path; SRTT and RTO on other destination addresses; MTU per path; and interleaving supported yes/no
- Comments: the 'Network Status Change' notification tells the application when a socket becomes active or inactive. This only changes the programming style, since the same information is also available via 'Status' 🧚
STATUS.MPTCP 🌈
- Pass 1 primitive/event: not specified
- 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 number, while the second is the remote IP and port number 💅
SET_DSCP.TCP 🍓
- Pass 1 primitive/event: not specified
- Parameters: DSCP value
- Comments: this lets an application change the DSCP value for outgoing segments ✨
SET_DSCP.SCTP 🦋
- Pass 1 primitive/event: 'Set DSCP value'
- Parameters: DSCP value
- Comments: this lets an application change the DSCP value for outgoing packets on a path 💜
SET_DSCP.UDP(-Lite) 🌸
- Pass 1 primitive/event: 'Set_DSCP'
- Parameter: DSCP value
- Comments: this lets an application change the DSCP value for outgoing UDP(-Lite) datagrams. [RFC7657] and [RFC8085] provide current guidance on using this value with UDP 📚
ERROR.TCP 😭
- Pass 1 primitive/event: 'Error_Report'
- Returns: reason (encoding not specified) and subreason (encoding not specified)
- Comments: these are soft errors that many applications can ignore without harm, so an application should be able to disable these notifications. The reported conditions include at least: ICMP error message arrived and excessive retransmissions 🙈
ERROR.UDP(-Lite) 💀
- Pass 1 primitive/event: 'Error_Report'
- Returns: Error report
- Comments: this returns soft errors that many applications may ignore without harm. An application must connect to be able to receive these notifications 👑
SET_AUTH.TCP 🔐
- Pass 1 primitive/event: not specified
- Parameters: current_key and rnext_key
- Comments: current_key and rnext_key are the preferred outgoing MKT and the preferred incoming MKT, respectively, for a segment that is sent on the connection 🎀
SET_AUTH.SCTP 🫶
- Pass 1 primitive/event: 'Set/Get Authentication Parameters'
- Parameters: key_id; key; and hmac_id
GET_AUTH.TCP 🌈
- Pass 1 primitive/event: not specified
- Parameters: current_key and rnext_key
- Comments: current_key and rnext_key are the preferred outgoing MKT and the preferred incoming MKT, respectively, that were carried on a recently received segment 💖
GET_AUTH.SCTP 🧚
- Pass 1 primitive/event: 'Set/Get Authentication Parameters'
- Parameters: key_id and chunk_list
RESET_STREAM.SCTP 🍓
- Pass 1 primitive/event: 'Add/Reset Streams, Reset Association'
- Parameters: sid and direction
RESET_STREAM-EVENT.SCTP 🦋
- Pass 1 primitive/event: 'Stream Reset' notification
- Parameters: information about the result of RESET_STREAM.SCTP
- Comments: this is issued when the procedure for resetting streams has completed ✨
RESET_ASSOC.SCTP 🌸
- Pass 1 primitive/event: 'Add/Reset Streams, Reset Association'
- Parameters: information related to the extension, as defined in [RFC3260]
RESET_ASSOC-EVENT.SCTP 💜
- Pass 1 primitive/event: 'Association Reset' notification
- Parameters: information about the result of RESET_ASSOC.SCTP
- Comments: this is issued when the procedure for resetting an association has completed 🫶
ADD_STREAM.SCTP 👑
- Pass 1 primitive/event: 'Add/Reset Streams, Reset Association'
- Parameters: number of outgoing and incoming streams to be added
ADD_STREAM-EVENT.SCTP 🌈
- Pass 1 primitive/event: 'Stream Change' notification
- Parameters: information about the result of ADD_STREAM.SCTP
- Comments: this is issued when the procedure for adding a stream has completed 🎀
SET_STREAM_SCHEDULER.SCTP 💖
- Pass 1 primitive/event: 'Set Stream Scheduler'
- Parameters: scheduler identifier
- Comments: the choice of First-Come, First-Served; Round-Robin; Round-Robin per Packet; Priority-Based; Fair Bandwidth; and Weighted Fair Queuing 🧚
CONFIGURE_STREAM_SCHEDULER.SCTP 🔥
- Pass 1 primitive/event: 'Configure Stream Scheduler'
- Parameters: priority
- Comments: the priority value only applies when Priority-Based or Weighted Fair Queuing scheduling is chosen with SET_STREAM_SCHEDULER.SCTP. The meaning of the parameter differs between these two schedulers, but in both cases it realizes some form of prioritization regarding how bandwidth is divided among streams 👑
SET_FLOWLABEL.SCTP 🦋
- Pass 1 primitive/event: 'Set IPv6 Flow Label'
- Parameters: flow label
- Comments: this lets an application change the IPv6 header's flow label field for outgoing packets on a path 🌸
AUTHENTICATION_NOTIFICATION-EVENT.SCTP 💜
- Pass 1 primitive/event: 'Authentication' notification
- Returns: information regarding key management
CONFIG_SEND_BUFFER.SCTP 🍓
- Pass 1 primitive/event: 'Configure Send Buffer Size'
- Parameters: size value in octets
CONFIG_RECEIVE_BUFFER.SCTP 🧚
- Pass 1 primitive/event: 'Configure Receive Buffer Size'
- Parameters: size value in octets
- Comments: this controls the receiver window 🫶
CONFIG_FRAGMENTATION.SCTP 💖
- Pass 1 primitive/event: 'Configure Message Fragmentation'
- Parameters: one boolean value (enable/disable) and maximum fragmentation size (optional; default: PMTU)
- Comments: if fragmentation is enabled, messages that exceed the maximum fragmentation size will be fragmented. If fragmentation is disabled, trying to send a message that exceeds the maximum fragmentation size will produce an error 😭
CONFIG_PMTUD.SCTP 🌈
- Pass 1 primitive/event: 'Configure Path MTU Discovery'
- Parameters: one boolean value (PMTUD on/off) and PMTU value (optional)
- Returns: PMTU value

Okay so this one returns a meaningful PMTU value when PMTUD is enabled (the boolean is true) 💖, and you can set the PMTU value yourself if PMTUD is disabled (the boolean is false) ✨.

CONFIG_DELAYED_SACK.SCTP 🦋
- Pass 1 primitive/event: 'Configure Delayed SACK Timer'
- Parameters: one boolean (delayed SACK on/off), a timer value (optional), and the number of packets to wait for (default 2)
- Comments: with delayed SACK on, SCTP sends a SACK after the provided number of packets arrive or when the timer expires, whichever happens first 🌸
CONFIG_RTO.SCTP 🎀
- Pass 1 primitive/event: 'Configure RTO Calculation'
- Parameters: init (optional), min (optional), and max (optional)
- Comments: this adjusts the initial, minimum, and maximum RTO values 💅
SET_COOKIE_LIFE.SCTP 🍓
- Pass 1 primitive/event: 'Set Cookie Life Value'
- Parameters: cookie life value
SET_MAX_BURST.SCTP 🔥
- Pass 1 primitive/event: 'Set Maximum Burst'
- Parameters: max burst value
- Comments: not all implementations allow values above the default of 4 🙈
SET_PARTIAL_DELIVERY_POINT.SCTP 🧚
- Pass 1 primitive/event: 'Set Partial Delivery Point'
- Parameters: partial delivery point (integer)
- Comments: this parameter has to be smaller or equal to the socket receive buffer size 👑
SET_CHECKSUM_ENABLED.UDP 💜
- Pass 1 primitive/event: 'Checksum_Enabled'
- Parameters: 0 when a zero checksum is used at the sender, 1 for a checksum at the sender (default)
SET_CHECKSUM_REQUIRED.UDP 🌈
- Pass 1 primitive/event: 'Require_Checksum'
- Parameter: 0 to allow a zero checksum, 1 when a non-zero checksum is required (default) at the receiver
SET_CHECKSUM_COVERAGE.UDP-Lite ⭐
- Pass 1 primitive/event: 'Set_Checksum_Coverage'
- Parameters: coverage length at sender (default maximum coverage)
SET_MIN_CHECKSUM_COVERAGE.UDP-Lite 🦋
- Pass 1 primitive/event: 'Set_Min_Coverage'
- Parameter: coverage length at receiver (default minimum coverage)
SET_DF.UDP(-Lite) 🌸
- Pass 1 primitive event: 'Set_DF'
- Parameter: 0 when DF is not set (default) in the IPv4 header, 1 when DF is set
GET_MMS_S.UDP(-Lite) 💖
- Pass 1 primitive event: 'Get_MM_S'
- Comments: this retrieves the maximum transport-message size that may be sent using a non-fragmented IP packet from the configured interface ✨
GET_MMS_R.UDP(-Lite) 🎀
- Pass 1 primitive event: 'Get_MMS_R'
- Comments: this retrieves the maximum transport-message size that may be received from the configured interface 💅
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 lets an application change the IPv4 TTL or IPv6 Hop Count value for outgoing UDP(-Lite) datagrams 🔥
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 lets an application read the IPv4 TTL or IPv6 Hop Count value from a received UDP(-Lite) datagram 🧚
SET_ECN.UDP(-Lite) 👑
- Pass 1 primitive/event: 'Set_ECN'
- Parameters: ECN value
- Comments: this lets a UDP(-Lite) application set the Explicit Congestion Notification (ECN) code point field for outgoing UDP(-Lite) datagrams. It defaults to sending '00' 💜
GET_ECN.UDP(-Lite) 🌈
- Pass 1 primitive/event: 'Get_ECN'
- Parameters: ECN value
- Comments: this lets a UDP(-Lite) application read the ECN code point field from a received UDP(-Lite) datagram ⭐
SET_IP_OPTIONS.UDP(-Lite) 🦋
- Pass 1 primitive/event: 'Set_IP_Options'
- Parameters: options
- Comments: this lets a UDP(-Lite) application set IP options for outgoing UDP(-Lite) datagrams. These options can at least be the Source Route, Record Route, and Timestamp option 🌸
GET_IP_OPTIONS.UDP(-Lite) 💖
- Pass 1 primitive/event: 'Get_IP_Options'
- Returns: options
- Comments: this lets a UDP(-Lite) application receive any IP options contained in a received UDP(-Lite) datagram ✨
CONFIGURE.LEDBAT 🎀
- Pass 1 primitive/event: N/A
- Parameters: enable (boolean); target; allowed_increase; gain_inc; gain_dec; base_history; current_filter; init_cwnd; and min_cwnd
- Comments: enable is a newly invented parameter that turns the whole LEDBAT service on or off 💅

TERMINATION:

Gracefully or forcefully closing a connection, or being told that this event has happened 🫶

CLOSE.TCP 🍓
- Pass 1 primitive/event: 'Close'
- Comments: this terminates the sending side of a connection after reliably delivering all remaining data 🔥
CLOSE.SCTP 🙈
- Pass 1 primitive/event: 'Shutdown'
- Comments: this terminates a connection after reliably delivering all remaining data 🧚
ABORT.TCP 👑
- Pass 1 primitive/event: 'Abort'
- Comments: this terminates a connection without delivering remaining data and sends an error message to the other side 💜
ABORT.SCTP 🌈
- Pass 1 primitive/event: 'Abort'
- Parameters: abort reason to be given to the peer (optional)
- Comments: this terminates a connection without delivering remaining data and sends an error message to the other side ⭐
ABORT.UDP(-Lite) 🦋
- Pass 1 primitive event: 'Close'
- Comments: this terminates a connection without delivering remaining data. No further UDP(-Lite) datagrams are sent or received for this transport service instance 💀
TIMEOUT.TCP 🌸
- Pass 1 primitive/event: 'User Timeout' event
- Comments: the application is informed that the connection is aborted. This event runs when the timeout set in CONNECTION.ESTABLISHMENT.CONNECT.TCP expires (possibly adjusted in CONNECTION.MAINTENANCE.CHANGE_TIMEOUT.TCP) ⏰
TIMEOUT.SCTP 💖
- Pass 1 primitive/event: 'Communication Lost' event
- Comments: the application is informed that the connection is aborted. This event runs when the timeout that should be enabled by default (see the beginning of Section 8.3 in [RFC4960]) expires, and it was possibly adjusted in CONNECTION.MAINTENANCE.CHANGE_TIMEOOUT.SCTP ✨
ABORT-EVENT.TCP 🎀
- Pass 1 primitive/event: not specified
ABORT-EVENT.SCTP 💅
- Pass 1 primitive/event: 'Communication Lost' event
- Returns: abort reason from the peer (if available)
- Comments: the application is informed that the other side has aborted the connection using CONNECTION.TERMINATION.ABORT.SCTP 🍓
CLOSE-EVENT.TCP 🔥
- Pass 1 primitive/event: not specified
CLOSE-EVENT.SCTP 🙈
- Pass 1 primitive/event: 'Shutdown Complete' event
- Comments: the application is informed that CONNECTION.TERMINATION.CLOSE.SCTP was successfully completed 🧚

Okay bestie, this whole section is about primitives that work on a connection that already exists 💅 That means one that was either fully set up or at least made available for receiving data. (Heads up: for UDP(-Lite), that second part is optional, so it's giving flexible energy 🦋.) Every sending primitive also carries a reference to a data block, and every receiving primitive carries a reference to available buffer space for the data, on top of the parameters listed below. And get this: CONNECT.TCP and LISTEN.TCP, from the ESTABLISHMENT and AVAILABILITY categories, can already carry data (an optional user message) before the connection is fully established 🤯

SEND.TCP:
- Pass 1 primitive/event: 'Send'
- Parameters: timeout (optional); current_key (optional); and rnext_key (optional)
- Comments: this hands TCP a data block to send reliably to the TCP on the other side of the connection 💖 You can set the timeout with this call too (see also CONNECTION.MAINTENANCE.CHANGE_TIMEOUT.TCP). current_key and rnext_key are authentication parameters you can configure here (see also CONNECTION.MAINTENANCE.SET_AUTH.TCP).
SEND.SCTP:
- Pass 1 primitive/event: 'Send'
- Parameters: stream number; context (optional); socket (optional); unordered flag (optional); no-bundle flag (optional); payload protocol-id (optional); pr-policy (optional) pr-value (optional); sack-immediately flag (optional); and key-id (optional)
- Comments: this gives SCTP a data block to transmit to the SCTP on the other side of the connection (the SCTP association) 🧚 The stream number says which stream to use. The context number can be used later to point at the right message when an error gets reported. The socket can say which path to prefer, if there are multiple paths available (see also CONNECTION.MAINTENANCE.SETPRIMARY.SCTP). The data block can be delivered out of order if the unordered flag is set. Setting the no-bundle flag signals a preference to avoid bundling. The payload protocol-id is a number that, if provided, gets handed over to the receiving application. With pr-policy and pr-value, you control the level of reliability. The sack-immediately flag can indicate that the peer should not delay sending a SACK for the provided user message. If specified, the key-id is used to authenticate the user message 🔐
SEND.UDP(-Lite):
- Pass 1 primitive/event: 'Send'
- Parameters: IP address and port number of the destination endpoint (optional if connected)
- Comments: this sends a message for unreliable transmission using UDP(-Lite) to the specified transport address 🌸 The IP address and port number can be left out for connected UDP(-Lite) sockets. All CONNECTION.MAINTENANCE.SET_*.UDP(-Lite) primitives apply per message sent.
RECEIVE.TCP:
- Pass 1 primitive/event: 'Receive'
- Parameters: current_key (optional) and rnext_key (optional)
- Comments: current_key and rnext_key are authentication parameters that you can read with this call (see also CONNECTION.MAINTENANCE.GET_AUTH.TCP) 👀
RECEIVE.SCTP:
- Pass 1 primitive/event: 'Data Arrive' notification, followed by 'Receive'
- Parameters: stream number (optional)
- Returns: stream sequence number (optional) and partial flag (optional)
- Comments: if you provide a stream number, the receive call only picks up data from that one particular stream. If a partial message arrives, the partial flag tells you so, and then the stream sequence number must be provided so an application can restore the correct order of the data blocks that make up an entire message 🧩
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 💌
SENDFAILURE-EVENT.SCTP:
- Pass 1 primitive/event: 'Send Failure' notification, optionally followed by 'Receive Unsent Message' or 'Receive Unacknowledged Message'
- Returns: cause code; context; and unsent or unacknowledged message (optional)
- Comments: the cause code indicates the reason for the failure, and the context is the context number if one was provided in DATA.SEND.SCTP, for later use with 'Receive Unsent Message' or 'Receive Unacknowledged Message', respectively 🙈 These primitives can be used to retrieve the unsent or unacknowledged message (or part of the message, in case a part was delivered) if you want it.
SEND_FAILURE.UDP(-Lite):
- Pass 1 primitive/event: 'Send'
- Comments: this may be used to probe for the effective PMTU when used in combination with the MAINTENANCE.SET_DF primitive 🔍
SENDER_DRY-EVENT.SCTP:
- Pass 1 primitive/event: 'Sender Dry' notification
- Comments: this tells the application that the stack has no more user data to send 🏁
PARTIAL_DELIVERY_ABORTED-EVENT.SCTP:
- Pass 1 primitive/event: 'Partial Delivery Aborted' notification
- Comments: this tells the receiver of a partial message that further delivery of the message has been aborted 💔

5. Pass 3 🌈

This section presents the superset of all transport features in all the protocols discussed in the preceding sections. It's built from the pass 2 list of primitives, but also from the pass 1 text, so it includes transport features that can be configured in one protocol and are static properties in another (congestion control, for example). Again, some minor details are left out for the sake of generalization, e.g., TCP may provide various different IP options, but only source route is mandatory to implement, and this detail isn't visible in the pass 3 transport feature "Specify IP options" 🧠 As before, "UDP(-Lite)" represents both UDP and UDP-Lite, and "TCP" refers to both TCP and MPTCP 🫶

Okay bestie, this is where the connection drama happens 💅 We're splitting it into four vibes: ESTABLISHMENT, AVAILABILITY, MAINTENANCE, and TERMINATION.

ESTABLISHMENT 🎀 Actively making a connection, going from one transport endpoint to one or more transport endpoints 💖

Connect Protocols: TCP, SCTP, and UDP(-Lite)
Specify which IP options must always be used Protocols: TCP and UDP(-Lite)
Request multiple streams Protocols: SCTP
Limit the number of inbound streams Protocols: SCTP
Specify number of attempts and/or timeout for the first establishment message Protocols: TCP and SCTP
Obtain multiple sockets Protocols: SCTP
Disable MPTCP Protocols: MPTCP
Configure authentication Protocols: TCP and SCTP Comments: with TCP, this lets you configure MKTs 🔐. In SCTP, it lets you pick which chunk types must always get authenticated. DATA, ACK, and so on are all different 'chunks' in SCTP, and one or more chunks can ride along in a single packet 📦
Indicate an Adaptation Layer (via an adaptation code point) Protocols: SCTP
Request to negotiate interleaving of user messages Protocols: SCTP
Hand over a message to reliably transfer (possibly multiple times) before connection establishment Protocols: TCP
Hand over a message to reliably transfer during connection establishment Protocols: SCTP
Enable UDP encapsulation with a specified remote UDP port number Protocols: SCTP

AVAILABILITY 🌸 Getting ready to receive incoming connection requests 👂

Listen, 1 specified local interface Protocols: TCP, SCTP, and UDP(-Lite)
Listen, N specified local interfaces Protocols: SCTP
Listen, all local interfaces Protocols: TCP, SCTP, and UDP(-Lite)
Obtain requested number of streams Protocols: SCTP
Limit the number of inbound streams Protocols: SCTP
Specify which IP options must always be used Protocols: TCP and UDP(-Lite)
Disable MPTCP Protocols: MPTCP
Configure authentication Protocols: TCP and SCTP Comments: with TCP, this lets you configure MKTs 🔐. In SCTP, it lets you pick which chunk types must always get authenticated. DATA, ACK, and so on are all different 'chunks' in SCTP, and one or more chunks can ride along in a single packet 📦
Indicate an Adaptation Layer (via an adaptation code point) Protocols: SCTP

MAINTENANCE 🧚 Tweaking an open connection, or getting told about things happening to it 👀

Change timeout for aborting connection (using retransmit limit or time value) Protocols: TCP and SCTP
Suggest timeout to the peer Protocols: TCP
Disable Nagle algorithm Protocols: TCP and SCTP
Request an immediate heartbeat, returning success/failure Protocols: SCTP
Notification of excessive retransmissions (early warning below abortion threshold) Protocols: TCP
Add path Protocols: MPTCP and SCTP MPTCP Parameters: source-IP; source-Port; destination-IP; and destination-Port SCTP Parameters: local IP address
Remove path Protocols: MPTCP and SCTP MPTCP Parameters: source-IP; source-Port; destination-IP; and destination-Port SCTP Parameters: local IP address
Set primary path Protocols: SCTP
Suggest primary path to the peer Protocols: SCTP
Configure Path Switchover Protocols: SCTP
Obtain status (query or notification) Protocols: SCTP and MPTCP SCTP parameters: association connection state; destination transport address list; destination transport address reachability states; current local and peer receiver window sizes; current local congestion window sizes; number of unacknowledged DATA chunks; number of DATA chunks pending receipt; primary path; most recent SRTT on primary path; RTO on primary path; SRTT and RTO on other destination addresses; MTU per path; and interleaving supported yes/no MPTCP parameters: subflow-list (identified by source-IP; source-Port; destination-IP; and destination-Port)
Specify DSCP field Protocols: TCP, SCTP, and UDP(-Lite)
Notification of ICMP error message arrival Protocols: TCP and UDP(-Lite)
Change authentication parameters Protocols: TCP and SCTP
Obtain authentication information Protocols: TCP and SCTP
Reset Stream Protocols: SCTP
Notification of Stream Reset Protocols: STCP
Reset Association Protocols: SCTP
Notification of Association Reset Protocols: STCP
Add Streams Protocols: SCTP
Notification of Added Stream Protocols: STCP
Choose a scheduler to operate between streams of an association Protocols: SCTP
Configure priority or weight for a scheduler Protocols: SCTP
Specify IPv6 flow label field Protocols: SCTP
Configure send buffer size Protocols: SCTP
Configure receive buffer (and rwnd) size Protocols: SCTP
Configure message fragmentation Protocols: SCTP
Configure PMTUD Protocols: SCTP
Configure delayed SACK timer Protocols: SCTP
Set Cookie life value Protocols: SCTP
Set maximum burst Protocols: SCTP
Configure size where messages are broken up for partial delivery Protocols: SCTP
Disable checksum when sending Protocols: UDP
Disable checksum requirement when receiving Protocols: UDP
Specify checksum coverage used by the sender Protocols: UDP-Lite
Specify minimum checksum coverage required by receiver Protocols: UDP-Lite
Specify DF field Protocols: UDP(-Lite)
Get max. transport-message size that may be sent using a non-fragmented IP packet from the configured interface Protocols: UDP(-Lite)
Get max. transport-message size that may be received from the configured interface Protocols: UDP(-Lite)
Specify TTL/Hop Count field Protocols: UDP(-Lite)
Obtain TTL/Hop Count field Protocols: UDP(-Lite)
Specify ECN field Protocols: UDP(-Lite)
Obtain ECN field Protocols: UDP(-Lite)
Specify IP options Protocols: UDP(-Lite)
Obtain IP options Protocols: UDP(-Lite)
Enable and configure "Low Extra Delay Background Transfer" Protocols: A protocol implementing the LEDBAT congestion control mechanism

TERMINATION 📭 Closing a connection gracefully or forcefully, or finding out that it's been closed 😭

Close after reliably delivering all remaining data, causing an event informing the application on the other side Protocols: TCP and SCTP Comments: a TCP endpoint only closes its own sending side, so it can still receive data afterwards 👂
Abort without delivering remaining data, causing an event that informs the application on the other side Protocols: TCP and SCTP Comments: in SCTP, the application on the aborting side can optionally give a reason, and the application on the other side can receive it 🎁
Abort without delivering remaining data, not causing an event that informs the application on the other side Protocols: UDP(-Lite)
Timeout event when data could not be delivered for too long Protocols: TCP and SCTP Comments: the timeout is configured with CONNECTION.MAINTENANCE "Change timeout for aborting connection (using retransmit limit or time value)".

All the features in this section are about an existing connection, meaning one that was either established or made available for receiving data 🫶 Heads up: TCP lets you send data (a single optional user message, which might arrive more than once) before the connection is fully established, so that's a whole thing. Reliable data transfer comes with delay, like when the sender waits until it's allowed to send, or when retransmission kicks in because a packet got lost 🐢

5.2.1. Sending Data 🚀

All the features in this section are provided by DATA.SEND from pass 2. DATA.SEND gets a data block from the application. We call it a "message" if the receiver can figure out where the beginning and end of the data block are, and "data" if it can't 📦

Reliably transfer data, with congestion control Protocols: TCP
Reliably transfer a message, with congestion control Protocols: SCTP
Unreliably transfer a message, with congestion control Protocols: SCTP
Unreliably transfer a message, without congestion control Protocols: UDP(-Lite)
Configurable Message Reliability Protocols: SCTP
Choice of stream Protocols: SCTP
Choice of path (destination address) Protocols: SCTP
Ordered message delivery (potentially slower than unordered) Protocols: SCTP
Unordered message delivery (potentially faster than ordered) Protocols: SCTP and UDP(-Lite)
Request not to bundle messages Protocols: SCTP
Specifying a 'payload protocol-id' (handed over as such by the receiver) Protocols: SCTP
Specifying a key identifier to be used to authenticate a message Protocols: SCTP
Request not to delay the acknowledgement (SACK) of a message Protocols: SCTP

5.2.2. Receiving Data 📬

All the features in this section are provided by DATA.RECEIVE from pass 2. DATA.RECEIVE fills a buffer the application hands over, with what we call a "message" if the receiver can find the beginning and end of the data block, and "data" if it can't 🫧

Receive data (with no message delimiting) Protocols: TCP
Receive a message Protocols: SCTP and UDP(-Lite)
Choice of stream to receive from Protocols: SCTP
Information about partial message arrival Protocols: SCTP Comments: in SCTP, partial messages get a stream sequence number, so the application can put the data blocks of a whole message back in the right order 🧩

5.2.3. Errors 🚨

This section covers sending failures that are tied to one specific call to DATA.SEND from pass 2 😤

Notification of an unsent (part of a) message Protocols: SCTP and UDP(-Lite)
Notification of an unacknowledged (part of a) message Protocols: SCTP
Notification that the stack has no more user data to send Protocols: SCTP
Notification to a receiver that a partial message delivery has been aborted Protocols: SCTP

6. IANA Considerations ✨

Good news: this document doesn't need any IANA actions 🌈

7. Security Considerations 🔐

Security is SO important, so we're being extra serious here 😭 Authentication, confidentiality protection, and integrity protection are all called out as transport features in [RFC8095]. The catch is that these are usually provided by a protocol or layer sitting on top of the transport protocol, and none of the transport protocols covered in this document gives you these features on its own. That's why they aren't considered in this document, with one exception: the native authentication capabilities of TCP and SCTP, where the security considerations in [RFC5925] and [RFC4895] apply 💜

Security considerations for the use of UDP and UDP-Lite are in the referenced RFCs. Security guidance for application usage is in the UDP Guidelines [RFC8085] 🛡️

8. References 📚

8.1. Normative References

okay bestie, these are the normative refs, the ones you actually need to have read before the spec makes full sense 📚🫶 they're basically the foundation pieces 💅

[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[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, <https://www.rfc-editor.org/info/rfc3758>.
[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, <https://www.rfc-editor.org/info/rfc4895>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[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, <https://www.rfc-editor.org/info/rfc5061>.
[RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", RFC 5482, DOI 10.17487/RFC5482, March 2009, <https://www.rfc-editor.org/info/rfc5482>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, <https://www.rfc-editor.org/info/rfc6182>.
[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, DOI 10.17487/RFC6458, December 2011, <https://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, <https://www.rfc-editor.org/info/rfc6525>.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <https://www.rfc-editor.org/info/rfc6817>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, <https://www.rfc-editor.org/info/rfc6824>.
[RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, March 2013, <https://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, <https://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, <https://www.rfc-editor.org/info/rfc7053>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.
[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, <https://www.rfc-editor.org/info/rfc7496>.
[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, <https://www.rfc-editor.org/info/rfc7829>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol", RFC 8260, DOI 10.17487/RFC8260, November 2017, <https://www.rfc-editor.org/info/rfc8260>.
[RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018, <https://www.rfc-editor.org/info/rfc8304>.

8.2. Informative References

these ones are the extra reading 🌸 helpful for the vibes and background, but the spec doesn't lean on them the same way 🦋

[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 1983, <https://www.rfc-editor.org/info/rfc854>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, <https://www.rfc-editor.org/info/rfc3260>.
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, DOI 10.17487/RFC5461, February 2009, <https://www.rfc-editor.org/info/rfc5461>.
[RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, January 2011, <https://www.rfc-editor.org/info/rfc6093>.
[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. Zimmermann, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 7414, DOI 10.17487/RFC7414, February 2015, <https://www.rfc-editor.org/info/rfc7414>.
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, <https://www.rfc-editor.org/info/rfc7657>.
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, Ed., "Services Provided by IETF Transport Protocols and Congestion Control Mechanisms", RFC 8095, DOI 10.17487/RFC8095, March 2017, <https://www.rfc-editor.org/info/rfc8095>.
[TAPS-MINSET] Welzl, M. and S. Gjessing, "A Minimal Set of Transport Services for TAPS Systems", Work in Progress, draft-ietf-taps-minset-01, February 2018.

Appendix A. Overview of RFCs Used as Input for Pass 1

this is the cheat sheet of which RFCs fed into each protocol family 🧚✨ it's giving organized 💅

TCP: [RFC0793], [RFC1122], [RFC5482], [RFC5925], and [RFC7413].
MPTCP: [RFC6182], [RFC6824], and [RFC6897].
SCTP: RFCs without a sockets API specification: [RFC3758], [RFC4895], [RFC4960], and [RFC5061].
SCTP: RFCs that include a sockets API specification: [RFC6458], [RFC6525], [RFC6951], [RFC7053], [RFC7496], and [RFC7829].
UDP(-Lite): See [RFC8304].
LEDBAT: [RFC6817].

Appendix B. How This Document Was Developed 🎀

Okay so this section is the behind-the-scenes tea on how the doc got made 🫶 It was handed to contributors as guidance, and it's giving future-update energy, so whoever comes next can use it too ✨

This document is only concerned with transport features that are explicitly exposed to applications via primitives 💅 It also strictly follows RFC text, which is so important. If a transport feature is truly relevant for an application, the RFCs should say so, and they should describe how to use and configure it. So the approach was to find the right RFCs, then analyze and process their text 🧚

Primitives that "MAY" be implemented by a transport protocol were excluded 🙈 To get included, the minimum requirement level for a primitive to be implemented by a protocol was "SHOULD" 💜 Where style requirement levels as described in [RFC2119] aren't used, primitives got excluded when they're described alongside statements like, e.g., "some implementations also provide" or "an implementation may also" 💀 Excluded primitives or parameters got a brief description in their own dedicated subsection.

Pass 1: This began by identifying text that talks about primitives 🔍 An API specification, abstract or not, obviously describes primitives, but we are not only interested in API specifications. The text describing the 'Send' primitive in the API specified in [RFC0793], for instance, doesn't say that data transfer is reliable. TCP's reliability is clear, though, from this text in Section 1 of [RFC0793] 👑

   The Transmission Control Protocol (TCP) is intended for use as a
   highly reliable host-to-host protocol between hosts in packet-
   switched computer communication networks, and in interconnected
   systems of such networks.

Some text for the pass 1 subsections was developed by copying and pasting all the relevant text parts from the relevant RFCs, then adjusting the terminology to match that in Section 2 and shortening the phrasing to match the general style of the document 📝 An effort was made to formulate everything as a primitive description, so the primitive descriptions became as complete as possible. For example, the 'SEND.TCP' primitive in pass 2 is explicitly described as reliably transferring data 🦋 Text that's relevant for the primitives in this pass but doesn't fit directly under any primitive was used in a subsection's introduction ✨

Pass 2: The main goal of this pass is unification of primitives 🌈 As input, only text from pass 1 was used (no exterior sources). The list in pass 2 isn't arranged by protocol (i.e., "first protocol X, here are all the primitives; then protocol Y, here are all the primitives, ..."). It's arranged by primitive (i.e., "primitive A, implemented this way in protocol X, this way in protocol Y, ..."). The goal was to get as many similar pass 2 primitives as possible. For instance, this was sometimes achieved by not always keeping a 1:1 mapping between pass 1 and pass 2 primitives, renaming primitives, and so on. For every new primitive, the already-existing primitives were considered so everything could be as coherent as possible 💖

For each primitive, the following style was used:

   o  PRIMITIVENAME.PROTOCOL:
      Pass 1 primitive/event:
      Parameters:
      Returns:
      Comments:

The entries "Parameters", "Returns", and "Comments" were skipped when a primitive had no parameters, no described return value, or no comments that seemed necessary, respectively 🙃 Optional parameters are followed by "(optional)". When known, default values were provided 🍓

Pass 3: The main point of this pass is to identify transport features that are the result of static properties of protocols, for which all protocols have to be listed together 🧠 This is then the final list of all available transport features 🎉 It was primarily based on text from pass 2, with additional input from pass 1 (but no external sources).

Acknowledgements ✨

The authors wanna thank (in alphabetical order) Bob Briscoe, Spencer Dawkins, Aaron Falk, David Hayes, Karen Nielsen, Tommy Pauly, Joe Touch, and Brian Trammell for giving such valuable feedback on this doc 🫶 Special shoutout to Christoph Paasch for input related to Multipath TCP, and to Gorry Fairhurst and Tom Jones for input related to UDP(-Lite) 🌸 This work got funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No. 644334 (NEAT) 💜

Authors' Addresses 🦋

   Michael Welzl
   University of Oslo
   PO Box 1080 Blindern
   Oslo  N-0316
   Norway

   Email: michawe@ifi.uio.no


   Michael Tuexen
   Muenster University of Applied Sciences
   Stegerwaldstrasse 39
   Steinfurt  48565
   Germany

   Email: tuexen@fh-muenster.de


   Naeem Khademi
   University of Oslo
   PO Box 1080 Blindern
   Oslo  N-0316
   Norway

   Email: naeemk@ifi.uio.no

📦 where this page comes from

ietf: rfc8303 2018-02
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms