RFC 8095

RFC 8095: Services Provided by IETF Transport Protocols and Congestion Control Mechanisms 🦋

okay bestie, this one is the RFC 8095 tea ☕ It's a March 2017 doc, and it's Informational, which means it's published for background and is not a standards-track spec 💅 The main authors are G. Fairhurst, Ed. (University of Aberdeen), B. Trammell, Ed. and M. Kuehlewind, Ed. (both ETH Zurich). Its ISSN is 2070-1721. The header has no Obsoletes or Updates entries, so it doesn't replace or patch any other RFC 🎀

---

Abstract

So this doc is basically a big survey 📚 It describes, surveys and classifies the protocol mechanisms in existing IETF protocols. The goal is to give background for figuring out a common set of transport services 🧚 It looks at TCP, Multipath TCP, SCTP, UDP, UDP-Lite, DCCP, ICMP, RTP, FLUTE/ALC for Reliable Multicast, NORM, TLS, DTLS, and HTTP when HTTP is used as a pseudotransport. And yes, the survey is meant to set up the transport service work in the TAPS working group 🌸

Status of This Memo

Status check 🔍 This document is not an Internet Standards Track specification. It's just here for information 🍓

It's a product of the IETF, so it does reflect IETF community consensus. It got public review and was approved for publication by the IESG. Not everything the IESG approves is a candidate for an Internet Standard, though. For that, check Section 2 of RFC 7841 🫶

For the current status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc8095 💜

Copyright Notice

legal but make it cute ⚖️ Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved 💖

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the publication date. Please read those carefully, because they spell out your rights and restrictions for this document 🙈 Any Code Components pulled out of this doc must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as the Simplified BSD License says 💀

Table of Contents

the ToC is a lot but it's the map 🗺️

   1. Introduction ....................................................4
      1.1. Overview of Transport Features .............................4
   2. Terminology .....................................................5
   3. Existing Transport Protocols ....................................6
      3.1. Transport Control Protocol (TCP) ...........................6
           3.1.1. Protocol Description ................................6
           3.1.2. Interface Description ...............................8
           3.1.3. Transport Features ..................................9
      3.2. Multipath TCP (MPTCP) .....................................10
           3.2.1. Protocol Description ...............................10
           3.2.2. Interface Description ..............................10
           3.2.3. Transport Features .................................11
      3.3. User Datagram Protocol (UDP) ..............................11
           3.3.1. Protocol Description ...............................11
           3.3.2. Interface Description ..............................12
           3.3.3. Transport Features .................................13
      3.4. Lightweight User Datagram Protocol (UDP-Lite) .............13
           3.4.1. Protocol Description ...............................13
           3.4.2. Interface Description ..............................14
           3.4.3. Transport Features .................................14
      3.5. Stream Control Transmission Protocol (SCTP) ...............14
           3.5.1. Protocol Description ...............................15
           3.5.2. Interface Description ..............................17
           3.5.3. Transport Features .................................19
      3.6. Datagram Congestion Control Protocol (DCCP) ...............20
           3.6.1. Protocol Description ...............................21
           3.6.2. Interface Description ..............................22
           3.6.3. Transport Features .................................22

      3.7. Transport Layer Security (TLS) and Datagram TLS
           (DTLS) as a Pseudotransport ...............................23
           3.7.1. Protocol Description ...............................23
           3.7.2. Interface Description ..............................24
           3.7.3. Transport Features .................................25
      3.8. Real-Time Transport Protocol (RTP) ........................26
           3.8.1. Protocol Description ...............................26
           3.8.2. Interface Description ..............................27
           3.8.3. Transport Features .................................27
      3.9. Hypertext Transport Protocol (HTTP) over TCP as a
           Pseudotransport ...........................................28
           3.9.1. Protocol Description ...............................28
           3.9.2. Interface Description ..............................29
           3.9.3. Transport Features .................................30
      3.10. File Delivery over Unidirectional Transport /
            Asynchronous Layered Coding (FLUTE/ALC) for
            Reliable Multicast .......................................31
           3.10.1. Protocol Description ..............................31
           3.10.2. Interface Description .............................33
           3.10.3. Transport Features ................................33
      3.11. NACK-Oriented Reliable Multicast (NORM) ..................34
           3.11.1. Protocol Description ..............................34
           3.11.2. Interface Description .............................35
           3.11.3. Transport Features ................................36
      3.12. Internet Control Message Protocol (ICMP) .................36
           3.12.1. Protocol Description ..............................37
           3.12.2. Interface Description .............................37
           3.12.3. Transport Features ................................38
   4. Congestion Control .............................................38
   5. Transport Features .............................................39
   6. IANA Considerations ............................................42
   7. Security Considerations ........................................42
   8. Informative References .........................................42
   Acknowledgments ...................................................53
   Contributors ......................................................53
   Authors' Addresses ................................................54

---

1. Introduction ✨

this is the big-picture intro bestie 🌈 Internet apps lean on a transport protocol to move their data. Think TCP, which is reliable and keeps things in order, or UDP, which is unreliable and just sends datagrams 📦 We use the phrase "transport service" to mean the end-to-end service the transport layer gives an application. A transport service only works properly if the app tells the stack what it intends to do 🎯 The app can work that out at design time, compile time, or run time. It can say a feature is required, express a preference, or land somewhere in between 💅 Features of transport services include reliable delivery, ordered delivery, content privacy from in-path devices, and integrity protection 🔐

The IETF has defined loads of transport protocols beyond TCP and UDP, like SCTP, DCCP, MPTCP, and UDP-Lite 🦋 Transport services can come straight from these protocols, or they can be layered on top of them. Examples are WebSockets (which runs over TCP), RTP (over TCP or UDP), and WebRTC data channels (which run over SCTP over DTLS over UDP or TCP) 🫧 Services built on UDP or UDP-Lite usually also need their own congestion control, such as NewReno [RFC6582], TCP-Friendly Rate Control (TFRC) [RFC5348], or Low Extra Delay Background Transport (LEDBAT) [RFC6817]. That's how they extend the set of transport services beyond what TCP and UDP offer apps 🚀

the vibe of the protocols in this doc 🌸 The protocols described here are a basis for defining the transport services that common protocols provide, as background for the TAPS working group 💜 They were picked to expose as many potential transport services as possible. They are not meant to be a complete survey or classification of every transport protocol out there, so don't read it that way 🙈

1.1. Overview of Transport Features 💖

Okay so, transport protocols are different from each other based on the features of the services they give you. Lowkey the whole vibe is in the features 🦋

Some of these features are closely tied to the basic control stuff a protocol needs in order to work over a network path, like addressing. The number of participants in an association also decides where a protocol fits. A connection can be between two endpoints (unicast), to one of several endpoints (anycast), or to several endpoints at the same time (multicast). Unicast protocols usually support two-way communication, while multicast is generally one-way 🌸 Another feature is whether the transport needs a control exchange across the network during setup (like TCP) or whether it's connectionless (like UDP).

For actually delivering packets, reliability and integrity protection, ordering, and framing are the basic features. These get implemented with different levels of assurance in different protocols, though, so it's not one-size-fits-all 💅 For example, a transport service might give you full reliability, with loss detection and retransmission (TCP does this). SCTP offers a message-based service that can provide full or partial reliability. It also helps cut down on head-of-line blocking, because it supports ordered and unordered message delivery across multiple streams 🧚 UDP-Lite and DCCP can provide partial integrity protection, which lets them tolerate corruption. Iconic 😭

Usually a protocol is designed for one specific type of delivery and framing. Either the data gets divided into transmission units based on network packets (the datagram service), or a data stream gets segmented and then recombined across multiple packets (the stream service). Whole objects, like files, get handled to match. This choice seriously shapes the interface the protocol gives the upper layer 👑

Transport protocols also offer some support for transmission control. For instance, a transport service can provide flow control, which lets a receiver regulate how fast a sender transmits 🫶 A transport service can also provide congestion control (see Section 4). TCP and SCTP both provide congestion control for use on the Internet, whereas UDP leaves that job to the upper-layer protocol that uses it. Not me UDP just chilling and handing it off 💀

Security features are often provided independently of the transport protocol, either through Transport Layer Security (TLS) (see Section 3.7) or by the application-layer protocol itself. The security properties TLS gives the application (things like confidentiality, integrity, and authenticity) are also features of the transport layer, even though they're usually implemented in a separate protocol today 🔥

2. Terminology ✨

These terms get used all throughout this document, and also in the later documents from the TAPS working group that describe how transport services are composed and decomposed 🎀

• Transport Feature: a specific end-to-end feature that the transport layer provides to an application. Examples include confidentiality, reliable delivery, ordered delivery, message-versus-stream orientation, etc.
• Transport Service: a set of transport features, without any association to a given framing protocol, that provides a complete service to an application.
• Transport Protocol: an implementation that provides one or more different transport services using a specific framing and header format on the wire.
• Application: an entity that uses the transport layer for end-to-end delivery of data across the network (this may also be an upper-layer protocol or tunnel encapsulation).

3. Existing Transport Protocols 🌈

This section gives a list of known IETF transport protocols and transport protocol frameworks. It doesn't assess whether specific implementations of protocols are fully compliant with current IETF specifications, so keep that in mind 🧐

3.1. Transport Control Protocol (TCP) 💜

TCP is an IETF Standards Track transport protocol. [RFC793] introduces TCP like this:

   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.

Since it came out, TCP has become the default connection-oriented, stream-based transport protocol on the Internet. It's widely implemented by endpoints and widely used by common applications, so it's basically the main character of transport protocols 👑✨

3.1.1. Protocol Description 🍓

TCP is a connection-oriented protocol. It uses a three-way handshake so a client and server can set up a connection and negotiate features. It also provides mechanisms for an orderly completion of a connection, as well as an immediate teardown [RFC793] [TCP-SPEC]. TCP is defined by a whole family of RFCs (see [RFC7414]), so it's not just one doc, it's a whole series 📚

TCP provides multiplexing to multiple sockets on each host, using port numbers. Other IETF-defined transports adopt a similar approach. An active TCP session is identified by its four-tuple: the local and remote IP addresses, plus the local and remote port numbers. The destination port used during connection setup is often what indicates the requested service 🌸

TCP splits a continuous stream of bytes into segments. These are sized to fit in IP packets, based on a negotiated maximum segment size, and they're further constrained by the effective Maximum Transmission Unit (MTU) from Path MTU Discovery (PMTUD). ICMP-based PMTUD [RFC1191] [RFC1981] and Packetization Layer PMTUD (PLPMTUD) [RFC4821] have both been defined by the IETF 🦋

Each byte in the stream is identified by a sequence number. The sequence number is used to order segments on receipt, to identify segments in acknowledgments, and to detect unacknowledged segments for retransmission. This is the basis of the reliable, ordered delivery of data in a TCP stream, and it's honestly so clever 🤯 TCP Selective Acknowledgment (SACK) [RFC2018] extends this mechanism by making it possible to identify missing segments earlier, which allows faster retransmission. SACK-based methods (for example, Duplicate Selective ACK) can also result in less spurious retransmission 🔥

Receiver flow control is provided by a sliding window, which limits how much unacknowledged data can be outstanding at any given time. The window scale option [RFC7323] lets a receiver use windows greater than 64 KB 💅

All TCP senders provide congestion control, such as the one described in [RFC5681]. TCP uses a sequence number with a sliding receiver window for flow control. The TCP congestion control mechanism also uses this same sequence number to manage a separate congestion window [RFC5681]. At any point in time, the sending window is the minimum of the receiver window and the congestion window. The congestion window grows when there's no congestion and shrinks when congestion is detected. Loss is often handled implicitly as a congestion indication. TCP detects it (which also feeds into retransmission handling) in two ways: a retransmission timer with exponential back-off, or the reception of three acknowledgments for the same segment, so-called "duplicated ACKs" (fast retransmit) 😭 Explicit Congestion Notification (ECN) [RFC3168] can also be used in TCP. If both endpoints support it, it lets a network node signal congestion without causing loss. Alternatively, TCP can use a delay-based congestion control scheme, which reacts to changes in delay as an early sign of congestion. This is further described in Section 4. Examples of different kinds of congestion control schemes are also provided in Section 4 🧚

TCP protocol instances can be extended (see [RFC7414]). Some protocol features may also be tuned to optimize for a specific deployment scenario. Some features are sender-side only and don't need any negotiation with the receiver. Some are receiver-side only. And some are explicitly negotiated during connection setup 🌈

TCP may buffer data, for example to optimize processing or capacity usage. So TCP provides mechanisms to control this, including an optional PUSH function [RFC793] that explicitly asks the transport service not to delay data. By default, TCP segment partitioning uses Nagle's algorithm [TCP-SPEC] to buffer data at the sender into large segments, which can add sender-side buffering delay. The sender can disable this algorithm to transmit more immediately, for example to reduce latency for interactive sessions ✨

TCP provides an "urgent data" function for limited out-of-order delivery of data. This function is deprecated [RFC6093] 🙈

A TCP Reset (RST) control message may be used to force a TCP endpoint to close a session [RFC793], which aborts the connection 💀

A mandatory checksum provides a basic integrity check against misdelivery and data corruption over the entire packet. Applications that need end-to-end integrity of their data are recommended to include a stronger integrity check over their payload data. The TCP checksum [RFC1071] [RFC2460] doesn't support partial payload protection (unlike DCCP and UDP-Lite) 🫶

TCP supports only unicast connections. Just one-to-one, no group chats 🎀

3.1.2. Interface Description 🌸

The User/TCP Interface defined in [RFC793] provides six user commands: Open, Send, Receive, Close, Status, and Abort. This interface doesn't describe configuring TCP options or parameters, apart from using the PUSH and URGENT flags 🧠

[RFC1122] describes extensions to the TCP/application-layer interface for:

• reporting soft errors, such as reception of ICMP error messages, extensive retransmission, or urgent pointer advance,
• providing a possibility to specify the Differentiated Services Code Point (DSCP) [RFC3260] (formerly, the Type-of-Service (TOS)) for segments,
• providing a flush call to empty the TCP send queue, and
• multihoming support.

In API implementations derived from the BSD Sockets API, TCP sockets are created using the SOCK_STREAM socket type, as described in the IEEE Portable Operating System Interface (POSIX) Base Specifications [POSIX]. The features used by a protocol instance may be set and tuned via this API. There are currently no documents in the RFC Series that describe this interface, which is a little sad honestly 🥺

3.1.3. Transport Features 🦋

The transport features provided by TCP are:

• connection-oriented transport with feature negotiation and application-to-port mapping (implemented using SYN segments and the TCP Option field to negotiate features),
• unicast transport (though anycast TCP is implemented, at risk of instability due to rerouting),
• port multiplexing,
• unidirectional or bidirectional communication,
• stream-oriented delivery in a single stream,
• fully reliable delivery (implemented using ACKs sent from the receiver to confirm delivery),
• error detection (implemented using a segment checksum to verify delivery to the correct endpoint and integrity of the data and options),
• segmentation,
• data bundling (optional; uses Nagle's algorithm to coalesce data sent within the same RTT into full-sized segments),
• flow control (implemented using a window-based mechanism where the receiver advertises the window that it is willing to buffer), and
• congestion control (usually implemented using a window-based mechanism and four algorithms for different phases of the transmission: slow start, congestion avoidance, fast retransmit, and fast recovery [RFC5681]).

That's the whole TCP glow-up, bestie 🌈💖 Next up, we keep going! ✨

3.2. Multipath TCP (MPTCP) 🦋

okay so Multipath TCP [RFC6824] is an extension for TCP that lets a connection use multiple paths at once 💖 It's for resilience, mobility, and load balancing, and it's giving "I want to fit in with the middleboxes." It's designed to look as indistinguishable as possible from regular non-multipath TCP to middleboxes 🙈 It does this by setting up regular TCP flows between a pair of source and destination endpoints, then spreading the application's stream across those flows. Sub-flows can be started over IPv4 or IPv6 for the same session, so it's literally both ✨

3.2.1. Protocol Description 💅

MPTCP uses TCP options for its control plane 🎀 Those options are how it signals multipath capabilities, negotiates data sequence numbers, advertises other available IP addresses, and sets up new sessions between pairs of endpoints. It's the whole group chat planning the trip through the options field 😭

By multiplexing one byte stream over separate paths, MPTCP can get a higher throughput than TCP in certain situations 🔥 Here's the catch, though: if coupled congestion control [RFC6356] is used, it might limit that benefit so it stays fair to other flows at the bottleneck. So no hogging the bottleneck, bestie 🫶 When you aggregate capacity over multiple paths, you might notice extra delay and higher jitter before data gets delivered to the applications in order. That depends on how packets are scheduled on each TCP subflow 🌈

3.2.2. Interface Description 🧚

By default, MPTCP shows the same interface as TCP to the application ✨ [RFC6897], however, describes a richer API for MPTCP-aware applications, so the fancy stuff is there if you want it 💜

This Basic API describes how an application can:

• enable or disable MPTCP.
• bind a socket to one or more selected local endpoints.
• query local and remote endpoint addresses.
• get a unique connection identifier (similar to an address-port pair for TCP).

The document also recommends the use of extensions defined for SCTP [RFC6458] (see Section 3.5) to support multihoming for resilience and mobility 🦋 SCTP is giving multihoming realness, so it's a whole vibe.

3.2.3. Transport Features 🌸

As an extension to TCP, MPTCP mostly provides the same features 💖 By setting up multiple sessions between available endpoints, it can also offer soft failover when one of the paths becomes unusable. Not a hard reset, just a graceful handoff 🫶

So the transport features MPTCP adds on top of TCP are:

• multihoming for load balancing, with endpoint multiplexing of a single byte stream, using either coupled congestion control or throughput maximization,
• address family multiplexing (using IPv4 and IPv6 for the same session), and
• resilience to network failure and/or handover.

---

3.3. User Datagram Protocol (UDP) 🍓

okay the User Datagram Protocol (UDP) [RFC768] [RFC2460] is an IETF Standards Track transport protocol 👑 It's a unidirectional datagram protocol that preserves message boundaries, but it gives you no error correction, no congestion control, and no flow control. Very minimalist, very "I don't need a babysitter" 💅 It can send broadcast datagrams (IPv4), multicast datagrams (IPv4 and IPv6), and of course unicast and anycast datagrams too. IETF guidance on using UDP lives in [RFC8085]. UDP is widely implemented and widely used by common applications, including DNS 🌈

3.3.1. Protocol Description 🎀

UDP is a connectionless protocol that maintains message boundaries 🦋 There's no connection setup and no feature negotiation, just vibes. It uses independent messages, usually called "datagrams". It detects payload errors and packets that were misdelivered to an unintended endpoint, and in both cases the received datagram gets discarded with no indication to the user of the service 😭 Ghosted, but make it protocol.

UDP can create IPv4 datagrams with no checksum 🙈 Generally that's discouraged [RFC1122] [RFC8085], but certain special cases allow it. Those datagrams rely on the IPv4 header checksum to protect against misdelivery to an unintended endpoint. IPv6 doesn't allow UDP datagrams with no checksum 💀 In certain cases [RFC6936], though, that rule may be relaxed [RFC6935], so it's not totally locked down.

UDP has no reliability and no retransmission 💔 Messages may be reordered, lost, or duplicated in transit. Also, because the UDP checksum is relatively weak, applications that need end-to-end integrity of their data are recommended to include a stronger integrity check on their payload data 🫶

Since UDP has no flow control, a receiving application that can't run fast enough, or often enough, may miss messages 🏃‍♀️ No congestion handling means UDP traffic may experience loss on an overloaded path, and it may cause loss of messages from other protocols (e.g., TCP) when it shares the same network path. Main character energy, but it can accidentally take everyone down with it 😬

When transmitting, UDP encapsulates each datagram into a single IP packet or several IP packet fragments 💖 That means a datagram can be larger than the effective path MTU. Fragments get reassembled before delivery to the UDP receiver, so the user of the transport service doesn't have to think about it ✨ When jumbograms are supported, larger messages may be sent without fragmentation.

UDP on its own doesn't support segmentation, receiver flow control, congestion control, PMTUD/PLPMTUD, or ECN 🙈 Apps that need those features have to provide them on their own, or use a protocol over UDP that provides them [RFC8085]. Build your own support squad 💅

3.3.2. Interface Description 🧚

[RFC768] describes basic requirements for a UDP API 🌸 Guidance on using common APIs is in [RFC8085].

A UDP endpoint is a tuple of (IP address, port number) 💜 De-multiplexing across multiple abstract endpoints (sockets) on the same IP address is supported. One server can use the same socket to talk to multiple clients. (Note: this is different from TCP, which uses a pair of tuples to identify a connection 👀) Multiple server instances (processes) that bind to the same socket can team up to serve multiple clients. The socket implementation makes sure the same received unicast message isn't duplicated to multiple server processes 🫶

Lots of operating systems also let a UDP socket be "connected", meaning you bind it to a specific (remote) UDP endpoint 🦋 Unlike TCP's connect primitive, for UDP this is only a local operation. It just simplifies the local send and receive functions and filters traffic for the specified addresses and ports [RFC8085]. Less drama, more simplicity 🍓

3.3.3. Transport Features 🌈

The transport features UDP provides are:

• unicast, multicast, anycast, or IPv4 broadcast transport,
• port multiplexing (where a receiving port can be configured to receive datagrams from multiple senders),
• message-oriented delivery,
• unidirectional or bidirectional communication where the transmissions in each direction are independent,
• non-reliable delivery,
• unordered delivery, and
• error detection (implemented using a segment checksum to verify delivery to the correct endpoint and integrity of the data; optional for IPv4 and optional under specific conditions for IPv6 where all or none of the payload data is protected).

---

3.4. Lightweight User Datagram Protocol (UDP-Lite) 🧚

okay so the Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] is an IETF Standards Track transport protocol 💖 It's unidirectional, a datagram protocol, and it preserves message boundaries. IETF guidance on using UDP-Lite is in [RFC8085]. A UDP-Lite service may support IPv4 broadcast, multicast, anycast, and unicast, plus IPv6 multicast, anycast, and unicast ✨

It's great for apps that would rather get a partially damaged payload than have it thrown away 🙌 One use is providing header integrity checks while still delivering corrupted payloads to error-tolerant applications, or to applications that handle payload integrity some other way (see [RFC6936]). Honestly iconic 👑

3.4.1. Protocol Description 🌸

Like UDP, UDP-Lite is a connectionless datagram protocol with no connection setup or feature negotiation 🦋 The difference is that it changes the semantics of the UDP Payload Length field into a Checksum Coverage Length field, and it's identified by a different IP protocol/next-header value. The Checksum Coverage Length field says how much checksum coverage is intended, and the rest of the unprotected payload is called the "error-insensitive part". So apps using UDP-Lite can't assume the data in the insensitive part is correct 🙈 Read the fine print, babe.

Other than that, UDP-Lite is semantically identical to UDP 💜 Same as with UDP, mechanisms for receiver flow control, congestion control, PMTU or PLPMTU discovery, support for ECN, and so on still need to come from upper-layer protocols [RFC8085] 🫶

3.4.2. Interface Description 🍓

There's no API currently specified in the RFC Series, but guidance on using common APIs is in [RFC8085] 🌈

The UDP-Lite interface differs from UDP's by adding a single (socket) option that communicates a checksum coverage length value 🎀 The checksum coverage may also be made visible to the application through the UDP-Lite MIB module [RFC5097]. Just one extra knob, very clean 💅

3.4.3. Transport Features ✨

The transport features UDP-Lite provides are:

• unicast, multicast, anycast, or IPv4 broadcast transport (same as for UDP),
• port multiplexing (same as for UDP),
• message-oriented delivery (same as for UDP),
• unidirectional or bidirectional communication where the transmissions in each direction are independent (same as for UDP),
• non-reliable delivery (same as for UDP),
• non-ordered delivery (same as for UDP), and
• partial or full payload error detection (where the Checksum Coverage field indicates the size of the payload data covered by the checksum).

---

3.5. Stream Control Transmission Protocol (SCTP) 💜

SCTP is a message-oriented IETF Standards Track transport protocol 🦋 The base protocol is specified in [RFC4960]. It supports multihoming and path failover for resilience to path failures, so it's built different 👑 An SCTP association has multiple streams in each direction, giving in-sequence delivery of user messages within each stream. That lets it minimize head-of-line blocking, which is so important for the vibe 🫶 SCTP supports multiple stream-scheduling schemes that control stream multiplexing, including priority and fair weighting schemes 🌸

SCTP was originally developed for carrying telephony signaling messages, and it's deployed in telephony signaling networks, especially in mobile telephony networks 📞 It can also be used for other services too, like data channels in the WebRTC framework 🌈

3.5.1. Protocol Description 💖

Okay bestie, SCTP is a connection-oriented protocol 🎀. It uses a four-way handshake to set up an SCTP association and a three-way message exchange to gracefully shut it down 🦋. It uses the same port number concept as DCCP, TCP, UDP, and UDP-Lite. SCTP only supports unicast 💅.

SCTP uses the 32-bit CRC32c to protect SCTP packets against bit errors and against packets being delivered to an unintended endpoint 🔥. This is stronger than the 16-bit checksums used by TCP or UDP 💪. However, partial payload checksum coverage, the kind DCCP or UDP-Lite provides, is not supported 🙈.

SCTP was designed with extensibility in mind ✨. A common header is followed by a sequence of chunks. [RFC4960] defines how a receiver processes chunks with an unknown chunk type. Support for extensions can be negotiated during the SCTP handshake. Right now the defined extensions include mechanisms for dynamic reconfiguration of streams [RFC6525] and IP addresses [RFC5061]. The extension specified in [RFC3758] also introduces the concept of partial reliability for user messages 🌈.

SCTP provides a message-oriented service 📦. Multiple small user messages can be bundled into a single SCTP packet to improve efficiency. For example, this bundling may be done by delaying user messages at the sender, kind of like Nagle's algorithm in TCP 🧚. User messages that would result in IP packets larger than the MTU will be fragmented at the sender and reassembled at the receiver. There is no protocol limit on the user message size 🌸. For MTU discovery, the same mechanism as for TCP can be used [RFC1981] [RFC4821], as well as probe packets with padding chunks, as defined in [RFC4820] 🔍.

[RFC4960] specifies TCP-friendly congestion control to protect the network against overload 🛡️. SCTP also uses sliding window flow control to protect receivers against overflow 🪟. Like TCP, SCTP supports delaying acknowledgments. [RFC7053] provides a way for the sender of user messages to ask for the corresponding acknowledgments to be sent immediately 🏃‍♀️.

Each SCTP association has between 1 and 65536 unidirectional streams in each direction 🌊. The number of streams can be different in each direction. Every user message is sent on a particular stream. User messages can be sent unordered or ordered, depending on what the upper layer asks for 💭. Unordered messages can be delivered as soon as they are completely received. For user messages that don't need fragmentation, this minimizes head-of-line blocking 🙌. Ordered messages sent on the same stream, on the other hand, are delivered at the receiver in the same order the sender sent them 📋.

The base protocol defined in [RFC4960] does not allow interleaving of user messages. That means large messages on one stream can block the sending of user messages on other streams 😭. [SCTP-NDATA] describes a method to overcome this limitation 🙌. This document also specifies multiple algorithms for the sender-side selection of which streams to send data from, supporting a variety of scheduling algorithms, including priority-based methods 📊. The stream reconfiguration extension defined in [RFC6525] lets streams be reset during the lifetime of an association, and lets the number of streams increase if the number negotiated in the SCTP handshake turns out to be insufficient 🎯.

Each user message sent is delivered to the receiver or, if there are excessive retransmissions, the association is terminated in a non-graceful way [RFC4960], similar to TCP behavior 💀. On top of this reliable transfer, the partial reliability extension [RFC3758] allows a sender to abandon user messages 🦋. The application can specify the policy for abandoning user messages 🍓.

SCTP supports multihoming 🏠. Each SCTP endpoint uses a list of IP addresses and a single port number. These addresses can be any mixture of IPv4 and IPv6 addresses 🌈. The addresses are negotiated during the handshake. The address reconfiguration extension specified in [RFC5061], in combination with [RFC4895], can change these addresses in an authenticated way during the lifetime of an SCTP association 🔐. This allows for transport-layer mobility 🚶‍♀️. Multiple addresses are used for improved resilience. If a remote address becomes unreachable, the traffic is switched over to a reachable one, if one exists 💖.

For securing user messages, the use of TLS over SCTP has been specified in [RFC3436]. However, this solution doesn't support all the services SCTP provides, such as unordered delivery or partial reliability 😤. That's why the use of DTLS over SCTP has been specified in [RFC6083], to overcome these limitations 🙌. When using DTLS over SCTP, the application can use almost all the services SCTP provides ✨.

[NAT-SUPP] defines methods for endpoints and middleboxes to provide NAT traversal for SCTP over IPv4 🧭. For legacy NAT traversal, [RFC6951] defines the UDP encapsulation of SCTP packets. Alternatively, SCTP packets can be encapsulated in DTLS packets, as specified in [SCTP-DTLS-ENCAPS]. The latter encapsulation is used within the WebRTC [WEBRTC-TRANS] context 🎥.

An SCTP ABORT chunk may be used to force an SCTP endpoint to close a session [RFC4960], aborting the connection 🛑.

SCTP has a well-defined API, which is described in the next subsection 📚.

3.5.2. Interface Description 🧩

[RFC4960] defines an abstract API for the base protocol 🎀. This API describes the following functions that the upper layer of SCTP can call: Initialize, Associate, Send, Receive, Receive Unsent Message, Receive Unacknowledged Message, Shutdown, Abort, SetPrimary, Status, Change Heartbeat, Request Heartbeat, Get SRTT Report, Set Failure Threshold, Set Protocol Parameters, and Destroy. The SCTP stack provides the following notifications to the upper layer: COMMUNICATION UP, DATA ARRIVE, SHUTDOWN COMPLETE, COMMUNICATION LOST, COMMUNICATION ERROR, RESTART, SEND FAILURE, and NETWORK STATUS CHANGE 🔔.

An extension to the BSD Sockets API is defined in [RFC6458] and covers the following 🧦:

• The base protocol defined in [RFC4960]. The API allows control over local addresses and port numbers, and over the primary path 🗺️. The application also gets fine control over parameters like retransmission thresholds, path supervision, the delayed acknowledgment timeout, and the fragmentation point 🎛️. The API provides a mechanism that lets the SCTP stack notify the application about events, if the application has requested them 🔔. These notifications give information about status changes of the association and of each of the peer addresses. In case of send failures, including drops of messages sent unreliably, the application can also be notified, and user messages can be returned to the application 📬. When sending user messages, the application can indicate a stream id, a payload protocol identifier, and whether ordered delivery is requested. These parameters can also be provided on message reception. A context can also be provided when sending, which can be used in case of send failures 🏷️. Sending arbitrarily large user messages is supported 🐘.
• The SCTP Partial Reliability extension defined in [RFC3758], which specifies for a user message the Partially Reliable SCTP (PR-SCTP) policy and the policy-specific parameter 🎈. Examples of these policies, defined in [RFC3758] and [RFC7496], are:
  • limiting the time a user message is dealt with by the sender ⏰.
  • limiting the number of retransmissions for each fragment of a user message. If the number of retransmissions is limited to 0, you get a service similar to UDP 🪶.
  • abandoning messages of lower priority in case of a send buffer shortage 🗑️.
• The SCTP Authentication extension defined in [RFC4895], which allows management of the shared keys. It also allows the HMAC to use and set the chunk types (which are only accepted in an authenticated way), and to get the list of chunks that the local and remote endpoints accept in an authenticated way 🔑.
• The SCTP Dynamic Address Reconfiguration extension defined in [RFC5061]. It allows manual addition and deletion of local addresses for SCTP associations, as well as enabling automatic address addition and deletion. The peer can also be given a hint for choosing its primary path 🧭.

A BSD Sockets API extension has been defined in the documents that specify the following SCTP extensions 💜:

• The SCTP Stream Reconfiguration extension defined in [RFC6525]. The API allows triggering the reset operation for incoming and outgoing streams and for the whole association. It also provides a way to notify the association about the corresponding events. The application can also increase the number of streams 🔄.
• The UDP Encapsulation of SCTP packets extension defined in [RFC6951]. The API allows management of the remote UDP encapsulation port 🎁.
• The SCTP SACK-IMMEDIATELY extension defined in [RFC7053]. The API allows the sender of a user message to ask the receiver to send the corresponding acknowledgment immediately ⚡.
• The additional PR-SCTP policies defined in [RFC7496]. The API allows enabling and disabling the PR-SCTP extension, choosing the PR-SCTP policies defined in that document, and providing statistical information about abandoned messages 📈.

Future documents describing SCTP extensions are expected to describe the corresponding BSD Sockets API extension in a "Socket API Considerations" section 📝.

The SCTP Socket API supports two kinds of sockets 🧦:

• One-to-one style sockets (using the socket type "SOCK_STREAM") 👯.
• One-to-many style sockets (using the socket type "SOCK_SEQPACKET") 🫂.

One-to-one style sockets are similar to TCP sockets: there is a 1:1 relationship between the sockets and the SCTP associations, except for listening sockets 💕. One-to-many style SCTP sockets are similar to unconnected UDP sockets, where there is a 1:n relationship between the sockets and the SCTP associations 🌀.

The SCTP stack can give applications information about state changes of the individual paths and the association, whenever they occur 📣. These events are delivered similarly to user messages, but they're specifically marked as notifications 🏷️.

New functions have been introduced to support the use of multiple local and remote addresses 🗺️. Additional SCTP-specific send and receive calls have also been defined, so SCTP-specific information can be sent without using ancillary data in the form of additional Control Message (cmsg) calls 🪄. These functions support detecting partial delivery of user messages and notifications 🔍.

The SCTP Socket API allows fine-grained control of the protocol behavior through an extensive set of socket options 🎛️.

The SCTP kernel implementations of FreeBSD, Linux, and Solaris mostly follow the specified extension to the BSD Sockets API for the base protocol and the corresponding supported protocol extensions 🌈🫶.

3.5.3. Transport Features ✨

okay bestie, SCTP's feature list is an absolute menu 💅 here's everything it brings to the table:

• connection-oriented transport with feature negotiation and application-to-port mapping 🎀
• unicast transport 🦋
• port multiplexing 🌸
• unidirectional or bidirectional communication 💜
• message-oriented delivery with durable message framing supporting multiple concurrent streams ✨
• fully reliable, partially reliable, or unreliable delivery (based on user-specified policy to handle abandoned user messages) with drop notification 🔥
• ordered and unordered delivery within a stream 🧚
• support for stream scheduling prioritization 👑
• segmentation 🍓
• user message bundling 🫶
• flow control using a window-based mechanism 🌈
• congestion control using methods similar to TCP 💅
• strong error detection (CRC32c) 😭
• transport-layer multihoming for resilience and mobility 💖

no cap, that's a LOT of main character energy 😭✨

---

3.6. Datagram Congestion Control Protocol (DCCP) 🦋

okay so DCCP is giving "UDP but make it responsible" 💅 It's the Datagram Congestion Control Protocol [RFC4340], an IETF Standards Track bidirectional transport protocol. It gives you unicast connections of congestion-controlled messages, but it does NOT do reliability. Not me saying "no reliability" like it's a flex 🙈

The DCCP Problem Statement [RFC4336] lays out the goals DCCP was trying to hit. It's best for apps that move fairly big chunks of data and want a say in the trade-off between timeliness and reliability [RFC4336] 🌸

DCCP is lowkey iconic because it has low overhead and a bunch of UDP-like vibes, but it doesn't make you reinvent the wheel every time a new multimedia app shows up 🛞✨ It bundles core transport stuff (feature negotiation, path state management, RTT calculation, PMTUD, etc.) so apps just pick how they send packets and, where it fits, grab common algorithms for their functions. Apps that can benefit include interactive stuff, streaming media, or on-line games [RFC4336] 🎮💜

3.6.1. Protocol Description 🎀

DCCP is a connection-oriented datagram protocol. It uses a three-way handshake so a client and server can set up a connection, and it has ways to do an orderly completion or an immediate teardown 🤝

A DCCP instance can be extended [RFC4340] and tuned with extra features 🔧 Some features are sender-side only (no negotiation with the receiver needed), some are receiver-side only, and some get explicitly negotiated during connection setup 💅

DCCP uses a Connect packet to start a session, and each endpoint picks the features it wants to support 🎀 Simultaneous open [RFC5596], like in TCP, can help interop when middleboxes are around 🧚 The Connect packet carries a Service Code [RFC5595] that says which app or protocol is using DCCP, so middleboxes know what the connection is for 👀

DCCP is unicast-only 🦋

It multiplexes across multiple sockets at each endpoint using port numbers 🌸 An active session is identified by its four-tuple: local and remote IP addresses plus local and remote port numbers 💖

The protocol chops data into messages that are usually sized to fit in IP packets, but they can get fragmented if they're smaller than the maximum packet size 🍓 A DCCP interface lets apps request fragmentation for packets bigger than the PMTU, but NOT bigger than the maximum packet size the current congestion control mechanism allows (Congestion Control Maximum Packet Size (CCMPS)) [RFC4340] ✨

Each message has a sequence number 🔢 It's used to identify segments in acknowledgments, detect unacknowledged segments, measure RTT, and more 💜 The protocol may support unordered delivery of data, and it does NOT provide retransmission itself 🙅‍♀️ DCCP supports reduced checksum coverage, a partial payload protection mechanism similar to UDP-Lite 🛡️ There's also a Data Checksum option; when it's enabled, it carries a strong Cyclic Redundancy Check (CRC) so endpoints can catch application data corruption 😭

Receiver flow control is supported, which limits how much unacknowledged data can be outstanding at any given time 🌈

A DCCP Reset packet may be used to force a DCCP endpoint to close a session [RFC4340], aborting the connection 💀

DCCP lets endpoints negotiate the congestion control profile, for plug-and-play congestion control 🔌 Specified profiles include "TCP-like" [RFC4341], "TCP-friendly" [RFC4342], and "TCP-friendly for small packets" [RFC5622] 💅 More mechanisms are recorded in an IANA registry (see <http://www.iana.org/assignments/dccp-parameters>) 📚

A lightweight UDP-based encapsulation (DCCP-UDP) has been defined [RFC6773] that lets DCCP run over paths where it isn't natively supported 🧚 Support for DCCP in NAPT/NATs is defined in [RFC4340] and [RFC5595] 🏠 Upper-layer protocols specified on top of DCCP include DTLS [RFC5238], RTP [RFC5762], and Interactive Connectivity Establishment / Session Description Protocol (ICE/SDP) [RFC6773] 🎬

3.6.2. Interface Description 🌸

Functions expected for a DCCP API include Open, Close, and management of the progress of a DCCP connection 📋 Open handles feature negotiation, picking an appropriate Congestion Control Identifier (CCID) for congestion control, and other connection parameters 🔑 There's a function to send DCCP datagrams, including setting the required checksum coverage and any required options 📨 (DCCP allows sending datagrams with a zero-length payload 🫧) Another function receives data, including whether the data was used or dropped 📥 Functions can also show an app the connection status, including the maximum packet size and the ability to do flow control by spotting a slow receiver at the sender 🚦

There is no API currently specified in the RFC Series 🙈

3.6.3. Transport Features 💅

The transport features DCCP provides are:

• unicast transport 🦋
• connection-oriented communication with feature negotiation and application-to-port mapping 🎀
• signaling of application class for middlebox support (implemented using Service Codes) 🧚
• port multiplexing 🌸
• unidirectional or bidirectional communication 💜
• message-oriented delivery 📦
• unreliable delivery with drop notification 🌈
• unordered delivery 🔀
• flow control (implemented using the slow receiver function) 🚦
• partial and full payload error detection (with optional strong integrity check) 🔥

---

3.7. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a Pseudotransport 🔐

Transport Layer Security (TLS) [RFC5246] and Datagram TLS (DTLS) [RFC6347] are IETF protocols that give apps a bunch of security features 🛡️ TLS is built to run on top of a reliable streaming transport (usually TCP), while DTLS runs on top of a best-effort datagram protocol (UDP or DCCP [RFC5238]) 💜 At the time of writing, the current TLS version is 1.2, defined in [RFC5246]; TLS 1.3 [TLS-1.3] was nearing completion 🎉 DTLS gives apps nearly identical functionality, is defined in [RFC6347], and its current version is also 1.2 ✨ TLS evolved from the Secure Sockets Layer (SSL) [RFC6101] protocols from the mid-1990s, which were built to protect HTTP traffic 🌐

Older versions of TLS and DTLS are still floating around, but they come with weaker security guarantees 😬 [RFC7457] outlines important attacks on TLS and DTLS 💀 [RFC7525] is a Best Current Practices (BCP) document describing secure configurations for TLS and DTLS that counter those attacks 🔒 Its recommendations are applicable for the vast majority of use cases 💅

⚠️ bestie, these security notes are NOT optional vibes. Old TLS and DTLS versions are weaker, so please check the BCP and the attack write-up before you ship anything 😭🔐

3.7.1. Protocol Description 🎀

TLS and DTLS provide the same security features, so we can talk about them together 🫶 They give you:

• Confidentiality 🤫
• Data integrity 🧱
• Peer authentication (optional) 🪪
• Perfect forward secrecy (optional) 🌙

The authentication of the peer entity can be omitted; a common web use case is where the server is authenticated and the client is not 🌐 TLS also has a completely anonymous operation mode where neither peer's identity is authenticated 🫥 It's important to note that TLS itself does NOT specify how a peer's identity should be interpreted 🙈 For example, with X.509 certificate authentication, it's the application's call whether the peer's certificate is acceptable for authorization decisions 🗝️

Perfect forward secrecy, if it's enabled and supported by the selected algorithms, makes sure that traffic encrypted and captured during a session at time t0 can't be decrypted later at time t1 (t1 > t0), even if the communicating peers' long-term secrets get compromised later 🌙✨

DTLS is generally used over an unreliable datagram transport like UDP, so apps will need to tolerate lost, reordered, or duplicated datagrams 🌪️ Like TLS, DTLS carries application data in a sequence of independent records 📦 But because records map to unreliable datagrams, DTLS has some features TLS doesn't:

• Record replay detection (optional) 🔁
• Record size negotiation (estimates of PMTU and record size expansion factor) 📏
• Conveyance of IP don't fragment (DF) bit settings by application 🚩
• An anti-DoS stateless cookie mechanism (optional) 🍪

DTLS follows the TLS design as closely as it can 💅 To work over datagrams, DTLS includes a sequence number and limited forms of retransmission and fragmentation for its internal operations 🧩 The sequence number may be used to detect replayed information, according to the windowing procedure in Section 4.1.2.6 of [RFC6347] 🪟 DTLS FORBIDS stream ciphers, which are basically incompatible with operating on independent encrypted records 🚫

3.7.2. Interface Description 🛠️

TLS is commonly invoked through an API from packages like OpenSSL, wolfSSL, or GnuTLS 📚 Using these APIs means handling a few important abstractions in these categories: long-term keys and algorithms, session state, and communications/connections 🔑

Considerable care is required when using TLS APIs to build a secure app 🧠 The programmer should have at least a basic understanding of encryption and digital signature algorithms and their strengths, public key infrastructure (including X.509 certificates and certificate revocation), and the Sockets API 🧦 See [RFC7525] and [RFC7457], as mentioned above 📖

As an example, with OpenSSL, the primary abstractions are the library itself, method (protocol), session, context, cipher, and connection 🧩 After initializing the library and setting the method, you choose a cipher suite and use it to configure a context object 🎛️ Session objects can then be minted according to the parameters in a context object and associated with individual connections 🤝 Depending on how precisely you want to pick different algorithmic or protocol options, you may need various levels of detail 🔍💅

3.7.3. Transport Features

Okay so both TLS and DTLS are built in layers, bestie 🎀 The bottom layer is usually called the "record protocol", and it's the one doing the heavy lifting ✨ It handles:

• message fragmentation 🧩
• authentication and integrity using message authentication codes (MACs) 🔐
• data encryption 🫶
• scheduling transmission over the underlying transport protocol 🚀

DTLS levels up the TLS record protocol with ordering and replay protection, done with sequence numbers. Main character energy 👑

A bunch of other protocols sit on top of the record protocol 🌸 That includes the handshake, alert, and change cipher spec protocols, plus the data protocol, which carries the actual application traffic 💅 The handshake protocol sets up the cryptographic and compression parameters when a connection first starts. In DTLS, it also has basic fragmentation and retransmission, plus a cookie-like mechanism to resist DoS attacks 🛡️ (TLS compression is not recommended at present, so don't go there rn 🙈) The alert protocol tells the peer about various conditions, and most of them are terminal for the connection 💀 The change cipher spec protocol is what keeps the cryptographic parameter changes in sync for each peer 🦋

When the data protocol is used with an appropriate cipher, it gives you:

• authentication of one end or both ends of a connection 🔑
• confidentiality 🤫
• cryptographic integrity protection 💜

Both TLS and DTLS are unicast-only 🎯

---

3.8. Real-Time Transport Protocol (RTP)

RTP is giving end-to-end network transport for real-time data like audio, video, or other data 🎀 It works over multicast or unicast transport services, including TCP, UDP, UDP-Lite, DCCP, TLS, and DTLS 🦋

3.8.1. Protocol Description

The RTP standard [RFC3550] defines a pair of protocols: RTP and the RTP Control Protocol (RTCP) 🌈 The transport doesn't set up the connection itself. Instead, it relies on out-of-band techniques or associated control protocols to set up, negotiate parameters, or tear down a session 🧚

An RTP sender wraps audio/video data into RTP packets so media streams can move 🎬 The RFC Series specifies RTP payload formats that let packets carry a wide range of media, and it also specifies a wide range of multiplexing, error control, and other support mechanisms ✨

If a frame of media is large, it gets fragmented into several RTP packets 🧩 And if you've got several small frames, they can be bundled into a single RTP packet 🍓

An RTP receiver collects RTP packets from the network, validates them for correctness, and sends them to the media decoder input queue 📥 Missing packet detection is done by the channel decoder 🔍 The playout buffer is ordered by time stamp and is used to reorder packets, so everything lines up nicely 💖 Damaged frames may be repaired before the media payloads are decompressed to display or store the data 🩹 Some uses of RTP can exploit the partial payload protection features offered by DCCP and UDP-Lite 🛡️

RTCP is a control protocol that works alongside an RTP flow 🫶 Both the RTP sender and receiver send RTCP report packets 📨 This is used to periodically send control information and report performance 📊

Based on received RTCP feedback, an RTP sender can adjust the transmission. For example, it can perform rate adaptation at the application layer when there's congestion 🚦

An RTCP receiver report (RTCP RR) is returned to the sender periodically to report key parameters, like the fraction of packets lost in the last reporting interval, the cumulative number of packets lost, the highest sequence number received, and the inter-arrival jitter 📈 RTCP RR packets also carry timing information that lets the sender estimate the network round-trip time (RTT) to the receivers ⏱️

The interval between reports from each receiver tends to be on the order of a few seconds on average 🕰️ That varies with the session rate, and sub-second reporting intervals are possible for high-rate sessions ⚡ The interval is randomized so reports from multiple receivers don't all sync up 🎲

3.8.2. Interface Description

There is no standard API defined for RTP or RTCP 🙃 Implementations are usually tightly integrated with a particular application and closely follow the principles of application-level framing and integrated layer processing [ClarkArch] in media processing [RFC2736], error recovery and concealment, rate adaptation, and security [RFC7202] 💅 So RTP implementations tend to target particular application domains, like voice-over-IP, IPTV, or video conferencing, with a feature set optimized for that domain, rather than being general-purpose implementations of the protocol 🎧

3.8.3. Transport Features

The transport features provided by RTP are:

• unicast, multicast, or IPv4 broadcast (provided by the lower-layer protocol) 📡
• port multiplexing (provided by the lower-layer protocol) 🔀
• unidirectional or bidirectional communication (provided by the lower-layer protocol) ↔️
• message-oriented delivery with support for media types and other extensions 📦
• reliable delivery when using erasure coding, or unreliable delivery with drop notification (if supported by the lower-layer protocol) 🪂
• connection setup with feature negotiation (using associated protocols) and application-to-port mapping (provided by the lower-layer protocol) 🗺️
• segmentation 🍰
• performance metric reporting (using associated protocols) 📊

---

3.9. Hypertext Transport Protocol (HTTP) over TCP as a Pseudotransport

HTTP is an application-level protocol that's widely used on the Internet 🌐 It gives you object-oriented delivery of discrete data or files 🗂️ Version 1.1 is specified in [RFC7230] [RFC7231] [RFC7232] [RFC7233] [RFC7234] [RFC7235], and version 2 is specified in [RFC7540] 📚 HTTP is usually transported over TCP using ports 80 and 443, though it can be used with other transports too 🔌 When it's used over TCP, it inherits TCP's properties 🫶

Application-layer protocols may use HTTP as a substrate with an existing method and data formats, or they can specify new methods and data formats 🧃 There are various reasons for this, listed in [RFC3205]. These include being a well-known and well-understood protocol, reusability of existing servers and client libraries, easy use of existing security mechanisms such as HTTP digest authentication [RFC7235] and TLS [RFC5246], and the ability of HTTP to traverse firewalls. That lets it work over many types of infrastructure, including cases where an application server often needs to support HTTP anyway 🧱

Depending on the application's needs, using HTTP as a substrate protocol may add complexity and overhead compared to a special-purpose protocol (for example, HTTP headers, or how well the HTTP security model fits, etc.) 🤔 [RFC3205] addresses this issue, provides some guidelines, and identifies concerns about using HTTP standard ports 80 and 443, using the HTTP URL scheme, and interacting with existing firewalls, proxies, and NATs 🚧

Representational State Transfer (REST) [REST] is another example of how applications can use HTTP as a transport protocol 🌷 REST is an architecture style that may be used to build applications using HTTP as a communication protocol 🏗️

3.9.1. Protocol Description

HTTP is a request/response protocol 🔁 A client sends a request containing a request method, URI, and protocol version, followed by a message whose design is inspired by MIME (see [RFC7231] for the differences between an HTTP object and a MIME message). That message contains information about the client and request modifiers 📝 It can also contain a message body carrying application data 🎁 The server responds with a status or error code, followed by a message containing information about the server and information about the data 📬 This may include a message body too 💌 You can specify a data format for the message body using MIME media types [RFC2045] 🏷️ The protocol has more features, and some relevant to pseudotransport are described below 👀

Content negotiation, specified in [RFC7231], is the mechanism HTTP gives you to select a representation for a requested resource 🎨 The client and server negotiate acceptable data formats, character sets, and data encoding (for example, data can be transferred compressed using gzip) 🗜️ HTTP can handle exchanging messages as well as data streaming (using chunked transfer encoding [RFC7230]) 🌊 You can also request just part of a resource using an object range request [RFC7233] ✂️ And the protocol has powerful cache control signaling defined in [RFC7234] 🧠

The persistent connections in HTTP 1.1 and HTTP 2.0 allow multiple request/response transactions (streams) during the lifetime of a single HTTP connection 🧵 This reduces overhead during connection establishment and mitigates the transport-layer slow-start that would otherwise happen for each transaction 🏎️ HTTP 2.0 connections can multiplex many request/response pairs in parallel on a single transport connection 🧑‍🤝‍🧑 Both are important for reducing latency in HTTP's primary use case 💨

HTTP can be combined with security mechanisms, such as TLS (denoted by HTTPS) 🔒 That adds the protocol properties the mechanism provides, like authentication and encryption 🕵️‍♀️ The TLS Application-Layer Protocol Negotiation (ALPN) extension [RFC7301] can be used to negotiate the HTTP version within the TLS handshake, which skips the latency of extra round-trip exchanges 🤝 Arbitrary cookie strings, included as part of the request headers, are often used as bearer tokens in HTTP 🍪

3.9.2. Interface Description

There are many HTTP libraries available, each exposing different APIs 📚 The APIs let you specify a request by providing a URI, a method, request modifiers, and, optionally, a request body 📮 For the response, you can register callbacks that get invoked when the response is received 📲 If HTTPS is used, the API exposes a registration of callbacks for when a server requests client authentication and when certificate verification is needed 🔐

The World Wide Web Consortium (W3C) has standardized the XMLHttpRequest API [XHR] 🌍 This API can be used for sending HTTP/HTTPS requests and receiving server responses 📤 Besides the XML data format, the request and response data format can also be JSON, HTML, and plain text 🧾 JavaScript and XMLHttpRequest are ubiquitous programming models for websites and more general applications where native code is less attractive 💻✨

3.9.3. Transport Features ✨

okay so when HTTP is working as a pseudotransport, here's the full feature list 💅

• unicast transport (provided by the lower-layer protocol, usually TCP) 💖
• unidirectional or bidirectional communication 🦋
• transfer of objects in multiple streams with object content type negotiation, supporting partial transmission of object ranges 🎀
• ordered delivery (provided by the lower-layer protocol, usually TCP) 📦
• fully reliable delivery (provided by the lower-layer protocol, usually TCP) 🫶
• flow control (provided by the lower-layer protocol, usually TCP), and 🌊
• congestion control (provided by the lower-layer protocol, usually TCP). 👑

HTTPS (HTTP over TLS) gets some extra glow-up features too, and these come from TLS 🔐✨

• authentication (of one or both ends of a connection) 🙌
• confidentiality, and 🤫
• integrity protection. 🛡️

3.10. File Delivery over Unidirectional Transport / Asynchronous Layered Coding (FLUTE/ALC) for Reliable Multicast 🌈

FLUTE/ALC is an IETF Standards Track protocol, specified in [RFC6726] and [RFC5775]. It's all about object-oriented delivery of discrete data or files 📁 Asynchronous Layer Coding (ALC) gives you an underlying reliable transport service, and FLUTE is the file-oriented specialization of the ALC service (for example, it can carry associated metadata). [RFC6726] and [RFC5775] are non-backward-compatible updates of [RFC3926] and [RFC3450], which are Experimental protocols. These Experimental protocols are currently super deployed in the 3GPP Multimedia Broadcast / Multicast Service (MBMS) (see [MBMS], Section 7) and similar contexts, like the Japanese ISDB-Tmm standard 🇯🇵💜

The FLUTE/ALC protocol was designed to support massively scalable reliable bulk data dissemination to receiver groups of arbitrary size, using IP Multicast over any type of delivery network. That includes unidirectional networks, like broadcast wireless channels 📡 It also supports point-to-point unicast transmissions, so it's not a one-trick pony 🐴✨

FLUTE/ALC bulk data dissemination was designed for discrete file or memory-based "objects" 🗂️ Now, FLUTE/ALC isn't really well adapted to byte and message streaming, BUT there's one exception 👀 FLUTE/ALC is used to carry 3GPP Dynamic Adaptive Streaming over HTTP (DASH) when scalability is a requirement (see [MBMS], Section 5.6). Iconic plot twist 🎬

FLUTE/ALC's reliability, delivery mode, congestion control, and flow/rate control mechanisms can all be controlled separately to meet different application needs 🎛️ Section 4.1 of [RFC8085] describes multicast congestion control requirements for UDP, so go check that out if you're curious 🤓

3.10.1. Protocol Description

The FLUTE/ALC protocol works on top of UDP (though it could work on top of any datagram delivery transport protocol), and it doesn't require any connectivity from receivers to the sender 🙈 That means purely unidirectional networks are supported by FLUTE/ALC. This gives you scalability to an unlimited number of receivers in a session, because the sender behaves exactly the same no matter how many receivers there are. Not me being impressed 😭🔥

FLUTE/ALC supports transferring bulk objects, like file or in-memory content, using either a push or an on-demand mode 📤 In push mode, content is sent once to the receivers. In on-demand mode, content is sent continuously during periods of time that can greatly exceed the average time required to download the session objects (see [RFC5651], Section 4.2). It's giving long-running broadcast energy ⏳

This lets receivers join a session asynchronously, whenever they want, receive the content, and leave the session. In that case, data content is typically sent continuously, in loops (also known as "carousels") 🎠 FLUTE/ALC also supports transferring an object stream with loose real-time constraints. This is especially useful for carrying 3GPP DASH when scalability is a requirement and unicast transmissions over HTTP can't be used ([MBMS], Section 5.6). In this case, packets are sent in sequence using push mode. Again, FLUTE/ALC isn't really well adapted to byte and message streaming, so other solutions could be preferred (for example, FECFRAME [RFC6363] with real-time flows) 💅

The FLUTE file delivery instantiation of ALC provides a metadata delivery service 🗃️ Each object of the FLUTE/ALC session is described in a dedicated entry of a File Delivery Table (FDT), using an XML format (see [RFC6726], Section 3.2). This metadata can include, but isn't restricted to, a URI attribute (to identify and locate the object), a media type attribute, a size attribute, an encoding attribute, or a message digest attribute. Since the set of objects sent within a session can be dynamic (new objects get added and old ones get removed), several instances of the FDT can be sent. A mechanism is provided to identify a new FDT instance, so nobody gets lost 🧭

Error detection and verification of the protocol control information relies on the underlying transport (for example, the UDP checksum) ✅

To provide robustness against packet loss and improve the efficiency of the on-demand mode, FLUTE/ALC relies on packet erasure coding (Application-Layer Forward Error Correction (AL-FEC)) 🧩 AL-FEC encoding is proactive, since there's no feedback and therefore no (N)ACK-based retransmission. ALC packets containing repair data are sent along with ALC packets containing source data. Several FEC Schemes have been standardized, but FLUTE/ALC doesn't mandate the use of any particular one 🙅‍♀️ There are several strategies for the transmission order of ALC source and repair packets. This can deeply impact the service provided, especially in on-demand mode (for example, favoring the recovery of objects in sequence or, at the other extreme, favoring the recovery of all objects in parallel). FLUTE/ALC doesn't mandate nor recommend any particular one of these 🤷‍♀️

A FLUTE/ALC session is made up of one or more channels, associated with different destination unicast and/or multicast IP addresses. ALC packets are sent in those channels at a certain transmission rate, and that rate often differs depending on the channel 📻 FLUTE/ALC doesn't mandate nor recommend any strategy for selecting which ALC packet goes on which channel. FLUTE/ALC can use a multiple rate congestion control building block (for example, Wave and Equation Based Rate Control (WEBRC)) to provide feedback-free congestion control. Here, receivers adjust their reception rates individually by joining and leaving channels associated with the session 🏃‍♀️ For that purpose, the ALC header provides a specific field to carry congestion-control-specific information. However, FLUTE/ALC doesn't mandate the use of a particular congestion control mechanism, although WEBRC is mandatory to support for the Internet ([RFC6726], Section 1.1.4). FLUTE/ALC is often used over a network path with pre-provisioned capacity [RFC8085], where there are no flows competing for capacity. In that case, a sender-based rate control mechanism and a single channel are sufficient 🌸

[RFC6584] provides per-packet authentication, integrity, and anti-replay protection in the context of the ALC and NORM protocols 🔒 Several mechanisms are proposed that integrate seamlessly into these protocols using the ALC and NORM header extension mechanisms 🧁

3.10.2. Interface Description

The FLUTE/ALC specification doesn't describe a specific API to control protocol operation. Open source and commercial implementations have specified APIs, but there's no IETF-specified API for FLUTE/ALC 🤷‍♀️

3.10.3. Transport Features

The transport features provided by FLUTE/ALC are:

• unicast, multicast, anycast, or IPv4 broadcast transmission, 📡
• object-oriented delivery of discrete data or files and associated metadata, 🗂️
• fully reliable or partially reliable delivery (of file or in-memory objects), using proactive packet erasure coding (AL-FEC) to recover from packet erasures, 🩹
• ordered or unordered delivery (of file or in-memory objects), 🔀
• error detection (based on the UDP checksum), ✅
• per-packet authentication, 🔑
• per-packet integrity, 🛡️
• per-packet replay protection, and 🚫
• congestion control for layered flows (for example, with WEBRC). 🌊

3.11. NACK-Oriented Reliable Multicast (NORM) 💫

NORM is an IETF Standards Track protocol, specified in [RFC5740]. It provides object-oriented delivery of discrete data or files 📦

The protocol was designed to support reliable bulk data dissemination to receiver groups using IP Multicast, and it also provides for point-to-point unicast operation 🎯 Bulk data dissemination support includes discrete file or computer memory-based "objects", as well as byte and message streaming 🌊

NORM can incorporate packet erasure coding as part of its selective Automatic Repeat reQuest (ARQ), in response to negative acknowledgments from the receiver. The packet erasure coding can also be applied proactively for forward protection from packet loss 🛡️ NORM transmissions are governed by TCP-Friendly Multicast Congestion Control (TFMCC) [RFC4654]. The reliability, congestion control, and flow control mechanisms can be separately controlled to meet different application needs. Mix and match, bestie 🎀

3.11.1. Protocol Description ✨

okay so NORM rides on top of UDP datagrams 🦋, which means you get port numbers and multiplexing for multiple sockets on a host, no cap. For loosely coordinated IP Multicast, NORM isn't strictly connection-oriented 🙈, but receivers still keep per-sender state so the protocol can actually run. [RFC5740] doesn't have a handshake for connection establishment. You can do separate session initiation to coordinate port numbers, OR you can do in-band "client-server" style connection establishment with the NORM congestion control signaling messages, using port binding techniques like the ones for TCP client-server connections 💅.

NORM handles bulk "objects" like file or in-memory content, but it can also treat a stream of data as a logical bulk object for packet erasure coding 🧚. With stream transport, NORM can do byte streams or message streams, where application-defined message boundary info gets carried in the NORM protocol messages. That lets receivers join or rejoin and recover message boundaries mid-stream 🌸. Application content is carried and identified with encoding symbol identifiers, depending on the Forward Error Correction (FEC) Scheme [RFC5052] you've configured. NORM uses NACK-based selective ARQ to reliably deliver the application content to receivers 🔥. It proactively measures round-trip timing info to scale ARQ timers appropriately and to support congestion control ⏱️. For multicast operation, timer-based feedback suppression is used to get group size scaling with low feedback traffic levels 💜. The feedback suppression is not applied for unicast operation.

NORM uses rate-based congestion control based on the TCP-Friendly Rate Control (TFRC) [RFC5348] principles that DCCP [RFC4340] also uses 🎀. Control messages measure RTT and collect congestion event info (like a loss event or an ECN event) from the receivers, so the rate can get dynamically adjusted ✨. TCP-Friendly Multicast Congestion Control (TFMCC) [RFC4654] has extra features for multicast, but it's functionally equivalent to TFRC for unicast 👑.

Error detection and verification of the protocol control information relies on the underlying transport (e.g., UDP checksum) 🫶.

The reliability mechanism is decoupled from congestion control 🦋. This lets you invoke alternative arrangements of transport services, for example fixed-rate reliable delivery, or unreliable delivery (that may optionally be "better than best effort" via packet erasure coding) using TFRC 🌈. Alternative congestion control techniques can be applied too, like TFRC with congestion event detection based on ECN 💖.

While NORM gives you NACK-based reliability, it also supports a positive acknowledgment (ACK) mechanism that can be used for receiver flow control 🍓. This mechanism is decoupled from the reliability and congestion control, so it supports applications with different needs. One example is using NORM for quasi-reliable delivery, where timely delivery of newer content may be favored over completely reliable delivery of older content, within buffering and RTT constraints 🙈✨.

---

3.11.2. Interface Description 🎀

The NORM specification does not describe a specific API to control protocol operation 🤷‍♀️. There's a freely available, open-source reference implementation of NORM at <https://www.nrl.navy.mil/itd/ncs/products/norm>, and a documented API is provided for that implementation. A sockets-like API isn't currently documented, but the existing API supports the functions needed for one to be implemented 🌸.

3.11.3. Transport Features 💅

The transport features provided by NORM are:

• unicast or multicast transport,
• unidirectional communication,
• stream-oriented delivery in a single stream or object-oriented delivery of in-memory data or file bulk content objects,
• fully reliable (NACK-based) or partially reliable (using erasure coding both proactively and as part of ARQ) delivery,
• unordered delivery,
• error detection (relies on UDP checksum),
• segmentation,
• data bundling (using Nagle's algorithm),
• flow control (timer-based and/or ACK-based), and
• congestion control (also supporting fixed-rate reliable or unreliable delivery).

---

3.12. Internet Control Message Protocol (ICMP) 💌

The Internet Control Message Protocol (ICMP) [RFC792] for IPv4 and ICMP for IPv6 [RFC4443] are IETF Standards Track protocols 🌟. It's a connectionless unidirectional protocol that delivers individual messages, without error correction, congestion control, or flow control 🙃. Messages may be sent as unicast, IPv4 broadcast, or multicast datagrams (IPv4 and IPv6), in addition to anycast datagrams 🦋.

While ICMP isn't typically described as a transport protocol, it does position itself over the network layer, and the operation of other transport protocols can be closely linked to the functions ICMP provides 🧚.

Transport protocols and upper-layer protocols can use received ICMP messages to help them make appropriate decisions when network or endpoint errors are reported 🚨. For example, that's how you implement ICMP-based Path MTU Discovery (PMTUD) [RFC1191] [RFC1981], or assist in Packetization Layer PMTUD (PLPMTUD) [RFC4821] 💜. Such reactions to received messages need to protect from off-path data injection [RFC8085], so an application doesn't end up receiving packets created by an unauthorized third party 😭. This is seriously important, bestie 🔒. An application therefore needs to make sure that all messages are appropriately validated, by checking the payload of the messages to confirm they were received in response to actually transmitted traffic (e.g., a reported error condition that corresponds to a UDP datagram or TCP segment was actually sent by the application) 🕵️‍♀️. This requires context [RFC6056], such as local state about communication instances to each destination (e.g., in TCP, DCCP, or SCTP). That state is not always maintained by UDP-based applications [RFC8085] 💀.

3.12.1. Protocol Description 🌸

ICMP is a connectionless unidirectional protocol 🦋. It delivers independent messages, called "datagrams". Each message is required to carry a checksum as an integrity check and to protect from misdelivery to an unintended endpoint 🔐.

ICMP messages typically relay diagnostic information from an endpoint [RFC1122] or network device [RFC1812], addressed to the sender of a flow 🍓. This usually contains the network protocol header of a packet that encountered a reported issue. Some formats of messages can also carry other payload data. Each message carries an integrity check calculated in the same way as for UDP, and this checksum is not optional 🫶.

The RFC Series defines additional IPv6 message formats to support a range of uses ✨. In the case of IPv6, the protocol incorporates neighbor discovery [RFC4861] [RFC3971] (provided by ARP for IPv4) and Multicast Listener Discovery (MLD) [RFC2710] group management functions (provided by IGMP for IPv4) 🌈.

Reliable transmission cannot be assumed! A receiving application that is unable to run sufficiently fast, or frequently, may miss messages since there is no flow or congestion control. On top of that, some network devices rate-limit ICMP messages 🙈.

3.12.2. Interface Description 🎀

ICMP processing is integrated in many connection-oriented transports, but like other functions, it needs to be provided by an upper-layer protocol when using UDP and UDP-Lite 💅.

On some stacks, a bound socket also allows a UDP application to be notified when ICMP error messages are received for its transmissions [RFC8085] 👑.

Any response to ICMP error messages ought to be robust to temporary routing failures (sometimes called "soft errors"). For example, transient ICMP "unreachable" messages ought to not normally cause a communication abort [RFC5461] [RFC8085] 🦋.

3.12.3. Transport Features 🧚

ICMP doesn't provide any transport service directly to applications 🙃. Used together with other transport protocols, it provides transmission of control, error, and measurement data between endpoints, or from devices along the path to one endpoint 💖.

---

4. Congestion Control ✨

Congestion control is critical to the stable operation of the Internet 🚦. A variety of mechanisms are used to provide the congestion control needed by many Internet transport protocols. Congestion is detected based on sensing of network conditions, whether through explicit or implicit feedback 👀. The congestion control mechanisms that different transport protocols can apply are largely orthogonal to the choice of transport protocol, so this section gives an overview of the congestion control mechanisms available to the protocols described in Section 3 🌟.

Many protocols use a separate window to determine the maximum sending rate that is allowed by the congestion control 🪟. The congestion control mechanism in use will increase the congestion window if feedback indicates that the currently used network path is not congested, and will reduce the window otherwise. Window-based mechanisms often increase their window slowly over multiple RTTs, while decreasing strongly when the first indication of congestion is received 📉. One example is Additive Increase Multiplicative Decrease (AIMD), where the window is increased by a certain number of packets/bytes for each data segment that has been successfully transmitted, while the window decreases multiplicatively on the occurrence of a congestion event 🎢. This can lead to a rather unstable, oscillating sending rate, but it resolves a congestion situation quickly 💫. Examples of window-based AIMD schemes include TCP NewReno [RFC5681], TCP Cubic [CUBIC] (the default mechanism for TCP in Linux), and CCID 2 specified for DCCP [RFC4341] 🐧.

Some classes of applications prefer a transport service that allows sending at a more stable rate, one that is slowly varied in response to congestion 🥰. Rate-based methods offer this type of congestion control, and have been defined based on the loss ratio and observed round-trip time, such as TFRC [RFC5348] and TFRC-SP [RFC4828] 🌷. These methods utilize a throughput equation to determine the maximum acceptable rate. Such methods are used with DCCP CCID 3 [RFC4342], CCID 4 [RFC5622], WEBRC [RFC3738], and other applications 💜.

Another class of applications prefers a transport service that yields to other (higher-priority) traffic, such as interactive transmissions 🫠. While most traffic on the Internet uses loss-based congestion control and therefore tends to fill the network buffers (to a certain level if Active Queue Management (AQM) is used), low-priority congestion control methods often react to changes in delay as an earlier indication of congestion 🕰️. This approach tends to induce less loss than a loss-based method, but it does generally not compete well with loss-based traffic across shared bottleneck links 😬. Therefore, methods such as LEDBAT [RFC6817] are deployed in the Internet for scavenger traffic that aims to only utilize otherwise unused capacity 🧹✨.

5. Transport Features ✨

okay so this section is basically the ultimate transport protocol cheat sheet 💅 The features described in this document can be used as a basis for defining common transport features, and they're sorted below by the protocols that support each one 🦋

• Control Functions 🎀
  • Addressing
    • unicast (TCP, MPTCP, UDP, UDP-Lite, SCTP, DCCP, TLS, RTP, HTTP, ICMP)
    • multicast (UDP, UDP-Lite, RTP, ICMP, FLUTE/ALC, NORM). ngl this one has a catch: TLS and DTLS are unicast-only, so there's no widely deployed mechanism for the Security features (listed further down) when you're using multicast addressing 🙈
    • IPv4 broadcast (UDP, UDP-Lite, ICMP)
    • anycast (UDP, UDP-Lite). Connection-oriented protocols like TCP and DCCP have also been deployed with anycast addressing, but routing changes may cause connection failure, so it's a little risky 💀
  • Association type
    • connection-oriented (TCP, MPTCP, DCCP, SCTP, TLS, RTP, HTTP, NORM) 💜
    • connectionless (UDP, UDP-Lite, FLUTE/ALC) 🌸
  • Multihoming support
    • resilience and mobility (MPTCP, SCTP) 🧚
    • load balancing (MPTCP) ⭐
    • address family multiplexing (MPTCP, SCTP) 🌈
  • Middlebox cooperation
    • application-class signaling to middleboxes (DCCP)
    • error condition signaling from middleboxes and routers to endpoints (ICMP) 🚨
  • Signaling
    • control information and error signaling (ICMP)
    • application performance reporting (RTP) 📊
• Delivery 🍓
  • Reliability
    • fully reliable delivery (TCP, MPTCP, SCTP, TLS, HTTP, FLUTE/ALC, NORM) 🫶
    • partially reliable delivery (SCTP, NORM)
      • using packet erasure coding (RTP, FLUTE/ALC, NORM)
      • with specified policy for dropped messages (SCTP)
    • unreliable delivery (SCTP, UDP, UDP-Lite, DCCP, RTP)
      • with drop notification to sender (SCTP, DCCP, RTP)
    • error detection
      • checksum for error detection (TCP, MPTCP, UDP, UDP-Lite, SCTP, DCCP, TLS, DTLS, FLUTE/ALC, NORM, ICMP) ✅
      • partial payload checksum protection (UDP-Lite, DCCP). Some uses of RTP can exploit partial payload checksum protection feature to provide a corruption-tolerant transport service. this is so clever, bestie 🧠
      • checksum optional (UDP). Possible with IPv4 and, in certain cases, with IPv6. 🤷‍♀️
  • Ordering
    • ordered delivery (TCP, MPTCP, SCTP, TLS, RTP, HTTP, FLUTE) 📦
    • unordered delivery permitted (UDP, UDP-Lite, SCTP, DCCP, RTP, NORM) 🌀
  • Type/framing
    • stream-oriented delivery (TCP, MPTCP, SCTP, TLS, HTTP)
      • with multiple streams per association (SCTP, HTTP2)
    • message-oriented delivery (UDP, UDP-Lite, SCTP, DCCP, DTLS, RTP) 💌
    • object-oriented delivery of discrete data or files and associated metadata (HTTP, FLUTE/ALC, NORM) 🗂️
      • with partial delivery of object ranges (HTTP)
  • Directionality
    • unidirectional (UDP, UDP-Lite, DCCP, RTP, FLUTE/ALC, NORM) ➡️
    • bidirectional (TCP, MPTCP, SCTP, TLS, HTTP) ↔️
• Transmission control 🎛️
  • flow control (TCP, MPTCP, SCTP, DCCP, TLS, RTP, HTTP)
  • congestion control (TCP, MPTCP, SCTP, DCCP, RTP, FLUTE/ALC, NORM). Congestion control can also be provided by the transport supporting an upper-layer transport (e.g., TLS, RTP, HTTP). the layers really be looking out for each other 🫶
  • segmentation (TCP, MPTCP, SCTP, TLS, RTP, HTTP, FLUTE/ALC, NORM)
  • data/message bundling (TCP, MPTCP, SCTP, TLS, HTTP)
  • stream scheduling prioritization (SCTP, HTTP2) 👑
  • endpoint multiplexing (MPTCP)
• Security 🔐
  • authentication of one end of a connection (TLS, DTLS, FLUTE/ALC)
  • authentication of both ends of a connection (TLS, DTLS)
  • confidentiality (TLS, DTLS)
  • cryptographic integrity protection (TLS, DTLS)
  • replay protection (TLS, DTLS, FLUTE/ALC)

---

6. IANA Considerations 🌷

This document does not require any IANA actions. no registry drama here, bestie 💖

7. Security Considerations 🛡️

okay, this section is so important, so pay attention 😭 This document surveys existing transport protocols and protocols providing transport-like services. Confidentiality, integrity, and authenticity are among the features provided by those services. This document does not specify any new features or mechanisms for providing these features. So nothing new is being invented here, it's a survey. Each RFC referenced by this document discusses the security considerations of the specification it contains, so if you're building something on top of any of these, go read the security section of that specific RFC. Seriously, do not skip it 🔥

8. Informative References 📚

[ClarkArch] Clark, D. and D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols", Proceedings of ACM SIGCOMM, DOI 10.1145/99517.99553, 1990.

[CUBIC] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", Work in Progress, draft-ietf-tcpm-cubic-04, February 2017.

[MBMS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs", 3GPP TS 26.346, 2015, <http://www.3gpp.org/DynaReport/26346.htm>.

[NAT-SUPP] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control Transmission Protocol (SCTP) Network Address Translation Support", Work in Progress, draft-ietf-tsvwg-natsupp-09, May 2016.

[POSIX] IEEE, "Standard for Information Technology -- Portable Operating System Interface (POSIX(R)) Base Specifications, Issue 7", IEEE 1003.1, DOI 10.1109/ieeestd.2016.7582338, <http://ieeexplore.ieee.org/document/7582338/>.

[REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures, Chapter 5: Representational State Transfer", Ph.D. Dissertation, University of California, Irvine, 2000.

[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.

[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <http://www.rfc-editor.org/info/rfc792>.

[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.

[RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the Internet checksum", RFC 1071, DOI 10.17487/RFC1071, September 1988, <http://www.rfc-editor.org/info/rfc1071>.

[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>.

[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <http://www.rfc-editor.org/info/rfc1191>.

[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, <http://www.rfc-editor.org/info/rfc1812>.

[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996, <http://www.rfc-editor.org/info/rfc1981>.

[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996, <http://www.rfc-editor.org/info/rfc2018>.

[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <http://www.rfc-editor.org/info/rfc2045>.

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.

[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, DOI 10.17487/RFC2710, October 1999, <http://www.rfc-editor.org/info/rfc2710>.

[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP Payload Format Specifications", BCP 36, RFC 2736, DOI 10.17487/RFC2736, December 1999, <http://www.rfc-editor.org/info/rfc2736>.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <http://www.rfc-editor.org/info/rfc3168>.

[RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, DOI 10.17487/RFC3205, February 2002, <http://www.rfc-editor.org/info/rfc3205>.

[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, <http://www.rfc-editor.org/info/rfc3260>.

[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, DOI 10.17487/RFC3436, December 2002, <http://www.rfc-editor.org/info/rfc3436>.

[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, DOI 10.17487/RFC3450, December 2002, <http://www.rfc-editor.org/info/rfc3450>.

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.

[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, DOI 10.17487/RFC3738, April 2004, <http://www.rfc-editor.org/info/rfc3738>.

[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, DOI 10.17487/RFC3758, May 2004, <http://www.rfc-editor.org/info/rfc3758>.

[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., and G. Fairhurst, Ed., "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 2004, <http://www.rfc-editor.org/info/rfc3828>.

[RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, "FLUTE - File Delivery over Unidirectional Transport", RFC 3926, DOI 10.17487/RFC3926, October 2004, <http://www.rfc-editor.org/info/rfc3926>.

[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, <http://www.rfc-editor.org/info/rfc3971>.

[RFC4336] Floyd, S., Handley, M., and E. Kohler, "Problem Statement for the Datagram Congestion Control Protocol (DCCP)", RFC 4336, DOI 10.17487/RFC4336, March 2006, <http://www.rfc-editor.org/info/rfc4336>.

• [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <http://www.rfc-editor.org/info/rfc4340>.
• [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 2006, <http://www.rfc-editor.org/info/rfc4341>.
• [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, DOI 10.17487/RFC4342, March 2006, <http://www.rfc-editor.org/info/rfc4342>.
• [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, DOI 10.17487/RFC4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>.
• [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification", RFC 4654, DOI 10.17487/RFC4654, August 2006, <http://www.rfc-editor.org/info/rfc4654>.
• [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007, <http://www.rfc-editor.org/info/rfc4820>.
• [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <http://www.rfc-editor.org/info/rfc4821>.
• [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant", RFC 4828, DOI 10.17487/RFC4828, April 2007, <http://www.rfc-editor.org/info/rfc4828>.
• [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
• [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 2007, <http://www.rfc-editor.org/info/rfc4895>.
• [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <http://www.rfc-editor.org/info/rfc4960>.
• [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, DOI 10.17487/RFC5052, August 2007, <http://www.rfc-editor.org/info/rfc5052>.
• [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, DOI 10.17487/RFC5061, September 2007, <http://www.rfc-editor.org/info/rfc5061>.
• [RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite protocol", RFC 5097, DOI 10.17487/RFC5097, January 2008, <http://www.rfc-editor.org/info/rfc5097>.
• [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", RFC 5238, DOI 10.17487/RFC5238, May 2008, <http://www.rfc-editor.org/info/rfc5238>.
• [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
• [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, <http://www.rfc-editor.org/info/rfc5348>.
• [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, DOI 10.17487/RFC5461, February 2009, <http://www.rfc-editor.org/info/rfc5461>.
• [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, September 2009, <http://www.rfc-editor.org/info/rfc5595>.
• [RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal", RFC 5596, DOI 10.17487/RFC5596, September 2009, <http://www.rfc-editor.org/info/rfc5596>.
• [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)", RFC 5622, DOI 10.17487/RFC5622, August 2009, <http://www.rfc-editor.org/info/rfc5622>.
• [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding Transport (LCT) Building Block", RFC 5651, DOI 10.17487/RFC5651, October 2009, <http://www.rfc-editor.org/info/rfc5651>.
• [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <http://www.rfc-editor.org/info/rfc5681>.
• [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, <http://www.rfc-editor.org/info/rfc5740>.
• [RFC5762] Perkins, C., "RTP and the Datagram Congestion Control Protocol (DCCP)", RFC 5762, DOI 10.17487/RFC5762, April 2010, <http://www.rfc-editor.org/info/rfc5762>.
• [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, DOI 10.17487/RFC5775, April 2010, <http://www.rfc-editor.org/info/rfc5775>.
• [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011, <http://www.rfc-editor.org/info/rfc6056>.
• [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, DOI 10.17487/RFC6083, January 2011, <http://www.rfc-editor.org/info/rfc6083>.
• [RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, January 2011, <http://www.rfc-editor.org/info/rfc6093>.
• [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, DOI 10.17487/RFC6101, August 2011, <http://www.rfc-editor.org/info/rfc6101>.
• [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
• [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, DOI 10.17487/RFC6356, October 2011, <http://www.rfc-editor.org/info/rfc6356>.
• [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, DOI 10.17487/RFC6363, October 2011, <http://www.rfc-editor.org/info/rfc6363>.
• [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, <http://www.rfc-editor.org/info/rfc6458>.
• [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, DOI 10.17487/RFC6525, February 2012, <http://www.rfc-editor.org/info/rfc6525>.
• [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 6582, DOI 10.17487/RFC6582, April 2012, <http://www.rfc-editor.org/info/rfc6582>.
• [RFC6584] Roca, V., "Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols", RFC 6584, DOI 10.17487/RFC6584, April 2012, <http://www.rfc-editor.org/info/rfc6584>.
• [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, "FLUTE - File Delivery over Unidirectional Transport", RFC 6726, DOI 10.17487/RFC6726, November 2012, <http://www.rfc-editor.org/info/rfc6726>.
• [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November 2012, <http://www.rfc-editor.org/info/rfc6773>.
• [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <http://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, <http://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, <http://www.rfc-editor.org/info/rfc6897>.
• [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013, <http://www.rfc-editor.org/info/rfc6935>.
• [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, <http://www.rfc-editor.org/info/rfc6936>.
• [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, DOI 10.17487/RFC6951, May 2013, <http://www.rfc-editor.org/info/rfc6951>.
• [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, <http://www.rfc-editor.org/info/rfc7053>.
• [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014, <http://www.rfc-editor.org/info/rfc7202>.
• [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.

[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.

[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>.

[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014, <http://www.rfc-editor.org/info/rfc7233>.

[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <http://www.rfc-editor.org/info/rfc7234>.

[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.

[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <http://www.rfc-editor.org/info/rfc7301>.

[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, <http://www.rfc-editor.org/info/rfc7323>.

[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, <http://www.rfc-editor.org/info/rfc7414>.

[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, February 2015, <http://www.rfc-editor.org/info/rfc7457>.

[RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, "Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension", RFC 7496, DOI 10.17487/RFC7496, April 2015, <http://www.rfc-editor.org/info/rfc7496>.

[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.

[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <http://www.rfc-editor.org/info/rfc7540>.

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <http://www.rfc-editor.org/info/rfc8085>.

[SCTP-DTLS-ENCAPS] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Encapsulation of SCTP Packets", Work in Progress, draft-ietf-tsvwg-sctp-dtls-encaps-09, January 2015.

[SCTP-NDATA] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol", Work in Progress, draft-ietf-tsvwg-sctp-ndata-08, October 2016.

[TCP-SPEC] Eddy, W., Ed., "Transmission Control Protocol Specification", Work in Progress, draft-ietf-tcpm-rfc793bis-04, December 2016.

[TLS-1.3] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Work in Progress, draft-ietf-tls-tls13-18, October 2016.

[WEBRTC-TRANS] Alvestrand, H., "Transports for WebRTC", Work in Progress, draft-ietf-rtcweb-transports-17, October 2016.

[XHR] van Kesteren, A., Aubourg, J., Song, J., and H. Steen, "XMLHttpRequest Level 1", World Wide Web Consortium NOTE-XMLHttpRequest-20161006, October 2016, <http://www.w3.org/TR/XMLHttpRequest/>.

---

Acknowledgments 🙏✨

Big thank-yous to Joe Touch, Michael Welzl, Spencer Dawkins, and the TAPS working group for the comments, feedback, and discussion 🫶. This work is supported by the European Commission under grant agreement No. 318627 mPlane and from the Horizon 2020 research and innovation program under grant agreements No. 644334 (NEAT) and No. 688421 (MAMI). This support does not imply endorsement.

Contributors 💖

In addition to the editors, this document is the work of Brian Adamson, Dragana Damjanovic, Kevin Fall, Simone Ferlin-Oliviera, Ralph Holz, Olivier Mehani, Karen Nielsen, Colin Perkins, Vincent Roca, and Michael Tuexen. The whole squad 👑

• Section 3.2 on MPTCP was contributed by Simone Ferlin-Oliviera (ferlin@simula.no) and Olivier Mehani (olivier.mehani@nicta.com.au).
• Section 3.3 on UDP was contributed by Kevin Fall (kfall@kfall.com).
• Section 3.5 on SCTP was contributed by Michael Tuexen (tuexen@fh-muenster.de) and Karen Nielsen (karen.nielsen@tieto.com).
• Section 3.7 on TLS and DTLS was contributed by Ralph Holz (ralph.holz@nicta.com.au) and Olivier Mehani (olivier.mehani@nicta.com.au).
• Section 3.8 on RTP contains contributions from Colin Perkins (csp@csperkins.org).
• Section 3.9 on HTTP was contributed by Dragana Damjanovic (ddamjanovic@mozilla.com).
• Section 3.10 on FLUTE/ALC was contributed by Vincent Roca (vincent.roca@inria.fr).
• Section 3.11 on NORM was contributed by Brian Adamson (brian.adamson@nrl.navy.mil).

---

Authors' Addresses 🦋

Here are the editors, the brilliant minds behind the whole thing 💅

Godred Fairhurst (editor)
University of Aberdeen
School of Engineering, Fraser Noble Building
Aberdeen AB24 3UE

Email: gorry@erg.abdn.ac.uk


Brian Trammell (editor)
ETH Zurich
Gloriastrasse 35
8092 Zurich
Switzerland

Email: ietf@trammell.ch


Mirja Kuehlewind (editor)
ETH Zurich
Gloriastrasse 35
8092 Zurich
Switzerland

Email: mirja.kuehlewind@tik.ee.ethz.ch

That's the whole RFC, bestie 🌈🎀✨