idnits 2.17.1 draft-ietf-taps-transports-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 28, 2016) is 3010 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6546' is defined on line 2294, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-aqm-ecn-benefits' is defined on line 2438, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tsvwg-sctp-failover' is defined on line 2459, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 896 (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 1716 (Obsoleted by RFC 1812) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 3205 (Obsoleted by RFC 9205) -- Obsolete informational reference (is this intentional?): RFC 3450 (Obsoleted by RFC 5775) -- Obsolete informational reference (is this intentional?): RFC 3452 (Obsoleted by RFC 5052, RFC 5445) -- Obsolete informational reference (is this intentional?): RFC 3926 (Obsoleted by RFC 6726) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5672 (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 6093 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) -- Obsolete informational reference (is this intentional?): RFC 7053 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7232 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7233 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7234 (Obsoleted by RFC 9111) -- Obsolete informational reference (is this intentional?): RFC 7235 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-19) exists of draft-ietf-tsvwg-rfc5405bis-07 == Outdated reference: A later version (-13) exists of draft-ietf-tsvwg-sctp-ndata-04 == Outdated reference: A later version (-16) exists of draft-ietf-tsvwg-sctp-failover-14 == Outdated reference: A later version (-23) exists of draft-ietf-tsvwg-natsupp-08 == Outdated reference: A later version (-07) exists of draft-ietf-tcpm-cubic-00 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 27 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Fairhurst, Ed. 3 Internet-Draft University of Aberdeen 4 Intended status: Informational B. Trammell, Ed. 5 Expires: July 31, 2016 M. Kuehlewind, Ed. 6 ETH Zurich 7 January 28, 2016 9 Services provided by IETF transport protocols and congestion control 10 mechanisms 11 draft-ietf-taps-transports-09 13 Abstract 15 This document describes, surveys, classifies and compares the 16 protocol mechanisms provided by existing IETF protocols, as 17 background for determining a common set of transport services. It 18 examines the Transmission Control Protocol (TCP), Multipath TCP, the 19 Stream Control Transmission Protocol (SCTP), the User Datagram 20 Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol 21 (DCCP), the Internet Control Message Protocol (ICMP), the Realtime 22 Transport Protocol (RTP), File Delivery over Unidirectional 23 Transport/Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC), 24 and NACK-Oriented Reliable Multicast (NORM), Transport Layer Security 25 (TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol 26 (HTTP) when used as a pseudotransport. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on July 31, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Overview of Transport Features . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Existing Transport Protocols . . . . . . . . . . . . . . . . 5 66 3.1. Transport Control Protocol (TCP) . . . . . . . . . . . . 6 67 3.1.1. Protocol Description . . . . . . . . . . . . . . . . 6 68 3.1.2. Interface description . . . . . . . . . . . . . . . . 8 69 3.1.3. Transport Features . . . . . . . . . . . . . . . . . 8 70 3.2. Multipath TCP (MPTCP) . . . . . . . . . . . . . . . . . . 9 71 3.2.1. Protocol Description . . . . . . . . . . . . . . . . 9 72 3.2.2. Interface Description . . . . . . . . . . . . . . . . 9 73 3.2.3. Transport features . . . . . . . . . . . . . . . . . 10 74 3.3. Stream Control Transmission Protocol (SCTP) . . . . . . . 10 75 3.3.1. Protocol Description . . . . . . . . . . . . . . . . 11 76 3.3.2. Interface Description . . . . . . . . . . . . . . . . 13 77 3.3.3. Transport Features . . . . . . . . . . . . . . . . . 15 78 3.4. User Datagram Protocol (UDP) . . . . . . . . . . . . . . 16 79 3.4.1. Protocol Description . . . . . . . . . . . . . . . . 16 80 3.4.2. Interface Description . . . . . . . . . . . . . . . . 17 81 3.4.3. Transport Features . . . . . . . . . . . . . . . . . 17 82 3.5. Lightweight User Datagram Protocol (UDP-Lite) . . . . . . 18 83 3.5.1. Protocol Description . . . . . . . . . . . . . . . . 18 84 3.5.2. Interface Description . . . . . . . . . . . . . . . . 19 85 3.5.3. Transport Features . . . . . . . . . . . . . . . . . 19 86 3.6. Datagram Congestion Control Protocol (DCCP) . . . . . . . 19 87 3.6.1. Protocol Description . . . . . . . . . . . . . . . . 20 88 3.6.2. Interface Description . . . . . . . . . . . . . . . . 21 89 3.6.3. Transport Features . . . . . . . . . . . . . . . . . 21 90 3.7. Internet Control Message Protocol (ICMP) . . . . . . . . 22 91 3.7.1. Protocol Description . . . . . . . . . . . . . . . . 22 92 3.7.2. Interface Description . . . . . . . . . . . . . . . . 23 93 3.7.3. Transport Features . . . . . . . . . . . . . . . . . 23 94 3.8. Realtime Transport Protocol (RTP) . . . . . . . . . . . . 23 95 3.8.1. Protocol Description . . . . . . . . . . . . . . . . 24 96 3.8.2. Interface Description . . . . . . . . . . . . . . . . 25 97 3.8.3. Transport Features . . . . . . . . . . . . . . . . . 25 98 3.9. File Delivery over Unidirectional Transport/Asynchronous 99 Layered Coding Reliable Multicast (FLUTE/ALC) . . . . . . 25 100 3.9.1. Protocol Description . . . . . . . . . . . . . . . . 26 101 3.9.2. Interface Description . . . . . . . . . . . . . . . . 28 102 3.9.3. Transport Features . . . . . . . . . . . . . . . . . 28 103 3.10. NACK-Oriented Reliable Multicast (NORM) . . . . . . . . . 29 104 3.10.1. Protocol Description . . . . . . . . . . . . . . . . 29 105 3.10.2. Interface Description . . . . . . . . . . . . . . . 30 106 3.10.3. Transport Features . . . . . . . . . . . . . . . . . 30 107 3.11. Transport Layer Security (TLS) and Datagram TLS (DTLS) as 108 a pseudotransport . . . . . . . . . . . . . . . . . . . . 31 109 3.11.1. Protocol Description . . . . . . . . . . . . . . . . 31 110 3.11.2. Interface Description . . . . . . . . . . . . . . . 32 111 3.11.3. Transport Features . . . . . . . . . . . . . . . . . 33 112 3.12. Hypertext Transport Protocol (HTTP) over TCP as a 113 pseudotransport . . . . . . . . . . . . . . . . . . . . . 34 114 3.12.1. Protocol Description . . . . . . . . . . . . . . . . 35 115 3.12.2. Interface Description . . . . . . . . . . . . . . . 35 116 3.12.3. Transport features . . . . . . . . . . . . . . . . . 36 117 4. Congestion Control . . . . . . . . . . . . . . . . . . . . . 37 118 5. Transport Features . . . . . . . . . . . . . . . . . . . . . 38 119 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 120 7. Security Considerations . . . . . . . . . . . . . . . . . . . 42 121 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42 122 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 123 10. Informative References . . . . . . . . . . . . . . . . . . . 43 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 126 1. Introduction 128 Internet applications make use of the Services provided by a 129 Transport protocol, such as TCP (a reliable, in-order stream 130 protocol) or UDP (an unreliable datagram protocol). We use the term 131 "Transport Service" to mean the end-to-end service provided to an 132 application by the transport layer. That service can only be 133 provided correctly if information about the intended usage is 134 supplied from the application. The application may determine this 135 information at design time, compile time, or run time, and may 136 include guidance on whether a feature is required, a preference by 137 the application, or something in between. Examples of features of 138 Transport Services are reliable delivery, ordered delivery, content 139 privacy to in-path devices, and integrity protection. 141 The IETF has defined a wide variety of transport protocols beyond TCP 142 and UDP, including SCTP, DCCP, MPTCP, and UDP-Lite. Transport 143 services may be provided directly by these transport protocols, or 144 layered on top of them using protocols such as WebSockets (which runs 145 over TCP), RTP (over TCP or UDP) or WebRTC data channels (which run 146 over SCTP over DTLS over UDP or TCP). Services built on top of UDP 147 or UDP-Lite typically also need to specify additional mechanisms, 148 including a congestion control mechanism (such as NewReno, TFRC or 149 LEDBAT). This extends the set of available Transport Services beyond 150 those provided to applications by TCP and UDP. 152 1.1. Overview of Transport Features 154 Transport protocols can be differentiated by the features of the 155 services they provide. 157 Some of these provided features are closely related to basic control 158 function that a protocol needs to work over a network path, such as 159 addressing. The number of participants in a given association also 160 determines its applicability: if a connection is between endpoints 161 (unicast), to one of multiple endpoints (anycast), and/or 162 simultaneously to multiple endpoints (multicast). Unicast protocols 163 usually support bidirectional communication, while multicast is 164 generally unidirectional. Another feature is whether a transport 165 requires a control exchange across the network at setup (e.g., TCP), 166 or whether it connection-less (e.g., UDP). 168 For the delivery of the packets itself, reliability and integrity 169 protection, ordering, and framing are basic features. However, these 170 features are implemented with different levels of assurance in 171 different protocols. As an example, a transport service may provide 172 full reliability, providing detection of loss and retransmission 173 (e.g., TCP). SCTP offers a message-based service that can provide 174 full or partial reliability, and allows the protocol to minimize the 175 head of line blocking due to the support of ordered and unordered 176 message delivery within multiple streams. UDP-Lite and DCCP can 177 provide partial integrity protection to enable corruption tolerance. 179 Usually a protocol has been designed to support one specific type of 180 delivery/framing: data either needs to be divided into transmission 181 units based on network packets (datagram service), a data stream is 182 segmented and re-combined across multiple packets (stream service), 183 or whole objects such as files are handled accordingly. This 184 decision strongly influences the interface that is provided to the 185 upper layer. 187 In addition, transport protocols offer a certain support on 188 transmission control. For example, a transport service can provide 189 flow control to allow a receiver to regulate the transmission rate of 190 a sender. Further a transport service can provide congestion control 191 (see Section 4). As an example TCP and SCTP provide congestion 192 control for use in the Internet, whereas UDP leaves this function to 193 the upper layer protocol that uses UDP. 195 Security features are often provided independent of the transport 196 protocol, via Transport Layer Security (TLS, see {{transport-layer- 197 security-tls-and- datagram-tls-dtls-as-a-pseudotransport}}) or by the 198 application layer protocol itself. The security properties TLS 199 provides to the application (such as confidentiality, integrity, and 200 authenticity) are also features of the transport layer, even though 201 they are often presently implemented in a separate protocol. 203 2. Terminology 205 The following terms are used throughout this document, and in 206 subsequent documents produced by TAPS that describe the composition 207 and decomposition of transport services. 209 Transport Service Feature: a specific end-to-end feature that the 210 transport layer provides to an application. Examples include 211 confidentiality, reliable delivery, ordered delivery, message- 212 versus-stream orientation, etc. 214 Transport Service: a set of Transport Features, without an 215 association to any given framing protocol, which provides a 216 complete service to an application. 218 Transport Protocol: an implementation that provides one or more 219 different transport services using a specific framing and header 220 format on the wire. 222 Transport Service Instance: an arrangement of transport protocols 223 with a selected set of features and configuration parameters that 224 implements a single transport service, e.g., a protocol stack (RTP 225 over UDP). 227 Application: an entity that uses the transport layer for end-to-end 228 delivery data across the network (this may also be an upper layer 229 protocol or tunnel encapsulation). 231 3. Existing Transport Protocols 233 This section provides a list of known IETF transport protocols and 234 transport protocol frameworks. It does not make an assessment about 235 whether specific implementations of protocols are fully compliant to 236 current IETF specifications. 238 3.1. Transport Control Protocol (TCP) 240 TCP is an IETF standards track transport protocol. [RFC0793] 241 introduces TCP as follows: "The Transmission Control Protocol (TCP) 242 is intended for use as a highly reliable host-to-host protocol 243 between hosts in packet-switched computer communication networks, and 244 in interconnected systems of such networks." Since its introduction, 245 TCP has become the default connection- oriented, stream-based 246 transport protocol in the Internet. It is widely implemented by 247 endpoints and widely used by common applications. 249 3.1.1. Protocol Description 251 TCP is a connection-oriented protocol, providing a three way 252 handshake to allow a client and server to set up a connection and 253 negotiate features, and mechanisms for orderly completion and 254 immediate teardown of a connection. TCP is defined by a family of 255 RFCs [RFC7414]. 257 TCP provides multiplexing to multiple sockets on each host using port 258 numbers. A similar approach is adopted by other IETF-defined 259 transports. An active TCP session is identified by its four-tuple of 260 local and remote IP addresses and local port and remote port numbers. 261 The destination port during connection setup is often used to 262 indicate the requested service. 264 TCP partitions a continuous stream of bytes into segments, sized to 265 fit in IP packets based on a negotiated maximum segment size and 266 further constrained by the effective MTU from PMTUD. ICMP-based Path 267 MTU discovery [RFC1191][RFC1981] as well as Packetization Layer Path 268 MTU Discovery (PMTUD) [RFC4821] have been defined by the IETF. 270 Each byte in the stream is identified by a sequence number. The 271 sequence number is used to order segments on receipt, to identify 272 segments in acknowledgments, and to detect unacknowledged segments 273 for retransmission. This is the basis of the reliable, ordered 274 delivery of data in a TCP stream. TCP Selective Acknowledgment 275 (SACK) [RFC2018] extends this mechanism by making it possible to 276 provide earlier identification of which segments are missing, 277 allowing faster retransmission. SACK-based methods (e.g. DSACK) can 278 also result in less spurious retransmission. 280 Receiver flow control is provided by a sliding window: limiting the 281 amount of unacknowledged data that can be outstanding at a given 282 time. The window scale option [RFC7323] allows a receiver to use 283 windows greater than 64KB. 285 All TCP senders provide congestion control, such as described in 286 [RFC5681]. TCP's congestion control mechanism is tied to a sliding 287 window as well [RFC5681]. Examples for different kind of congestion 288 control schemes are given in Section 4. The sending window at a 289 given point in time is the minimum of the receiver window and the 290 congestion window. The congestion window is increased in the absence 291 of congestion and, respectively, decreased if congestion is detected. 292 Often loss is implicitly handled as a congestion indication which is 293 detected in TCP (also as input for retransmission handling) based on 294 two mechanisms: A retransmission timer with exponential back-up or 295 the reception of three acknowledgment for the same segment, so called 296 duplicated ACKs (Fast retransmit). In addition, Explicit Congestion 297 Notification (ECN) [RFC3168] can be used in TCP, if supported by both 298 endpoints, that allows a network node to signal congestion without 299 inducing loss. Alternatively, a delay-based congestion control 300 scheme can be used in TCP that reacts to changes in delay as an early 301 indication of congestion as also further described in Section 4. 303 TCP protocol instances can be extended [RFC7414] and tuned. Some 304 features are sender-side only, requiring no negotiation with the 305 receiver; some are receiver-side only, some are explicitly negotiated 306 during connection setup. 308 TCP may buffer data, e.g., to optimize processing or capacity usage. 309 TCP can therefore provides mechanisms to control this, including an 310 optional "PUSH" function [RFC0793] that explicitly requests the 311 transport service not to delay data. By default, TCP segment 312 partitioning uses Nagle's algorithm [RFC0896] to buffer data at the 313 sender into large segments, potentially incurring sender-side 314 buffering delay; this algorithm can be disabled by the sender to 315 transmit more immediately, e.g., to reduce latency for interactive 316 sessions. 318 TCP provides an "urgent data" function for limited out-of-order 319 delivery of the data. This function is deprecated [RFC6093]. 321 A mandatory checksum provides a basic integrity check against 322 misdelivery and data corruption over the entire packet. Applications 323 that require end to end integrity of data are recommended to include 324 a stronger integrity check of their payload data. The TCP checksum 325 does not support partial payload protection (as in DCCP/UDP-Lite). 327 TCP supports only unicast connections. 329 3.1.2. Interface description 331 A User/TCP Interface is defined in [RFC0793] providing six user 332 commands: Open, Send, Receive, Close, Status. This interface does 333 not describe configuration of TCP options or parameters beside use of 334 the PUSH and URGENT flags. 336 [RFC1122] describes extensions of the TCP/application layer interface 337 for: 339 o reporting soft errors such as reception of ICMP error messages, 340 extensive retransmission or urgent pointer advance, 342 o providing a possibility to specify the Differentiated Services 343 Code Point (DSCP) [RFC3260] (formerly, the Type-of-Service, TOS) 344 for segments, 346 o providing a flush call to empty the TCP send queue, and 348 o multihoming support. 350 In API implementations derived from the BSD Sockets API, TCP sockets 351 are created using the "SOCK_STREAM" socket type as described in the 352 IEEE Portable Operating System Interface (POSIX) Base Specifications 353 [POSIX]. The features used by a protocol instance may be set and 354 tuned via this API. There are currently no documents in the RFC 355 Series that describe this interface. 357 3.1.3. Transport Features 359 The transport features provided by TCP are: 361 o connection-oriented transport with feature negotiation and 362 application-to-port mapping (implemented using SYN segments and 363 the TCP option field to negotiate features), 365 o unicast transport (though anycast TCP is implemented, at risk of 366 instability due to rerouting), 368 o port multiplexing, 370 o uni- or bidirectional communication, 372 o stream-oriented delivery in a single stream, 374 o fully reliable delivery (implemented using ACKs sent from the 375 receiver to confirm delivery), 377 o error detection (implemented using a segment checksum to verify 378 delivery to the correct endpoint and integrity of the data and 379 options), 381 o segmentation, 383 o data bundling (optional; uses Nagle's algorithm to coalesce data 384 sent within the same RTT into full-sized segments), 386 o flow control (implemented using a window-based mechanism where the 387 receiver advertises the window that it is willing to buffer), 389 o congestion control (usually implemented using a window-based 390 mechanism and four algorithm for different phases of the 391 transmission: slow start, congestion avoidance, fast retransmit, 392 and fast recovery [RFC5681]). 394 3.2. Multipath TCP (MPTCP) 396 Multipath TCP [RFC6824] is an extension for TCP to support multi- 397 homing for resilience, mobility and load-balancing. It is designed 398 to be as transparent as possible to middleboxes. It does so by 399 establishing regular TCP flows between a pair of source/destination 400 endpoints, and multiplexing the application's stream over these 401 flows. Sub-flows can be started over IPv4 or IPv6 for the same 402 session. 404 3.2.1. Protocol Description 406 MPTCP uses TCP options for its control plane. They are used to 407 signal multipath capabilities, as well as to negotiate data sequence 408 numbers, and advertise other available IP addresses and establish new 409 sessions between pairs of endpoints. 411 By multiplexing one byte stream over separate paths, MPTCP can 412 achieve a higher throughput than TCP in certain situations. However, 413 if coupled congestion control [RFC6356] is used, it might limit this 414 benefit to maintain fairness to other flows at the bottleneck. When 415 aggregating capacity over multiple paths, and depending on the way 416 packets are scheduled on each TCP subflow, additional delay and 417 higher jitter might be observed observed before in-order delivery of 418 data to the applications. 420 3.2.2. Interface Description 422 By default, MPTCP exposes the same interface as TCP to the 423 application. [RFC6897] however describes a richer API for MPTCP- 424 aware applications. 426 This Basic API describes how an application can: 428 o enable or disable MPTCP. 430 o bind a socket to one or more selected local endpoints. 432 o query local and remote endpoint addresses. 434 o get a unique connection identifier (similar to an address-port 435 pair for TCP). 437 The document also recommends the use of extensions defined for SCTP 438 [RFC6458] (see next section) to support multihoming for resilience 439 and mobility. 441 3.2.3. Transport features 443 As an extension to TCP, MPTCP provides mostly the same features. By 444 establishing multiple sessions between available endpoints, it can 445 additionally provide soft failover solutions should one of the paths 446 become unusable. 448 The transport features provided by MPTCP in addition to TCP therefore 449 are: 451 o multihoming for load-balancing, with endpoint multiplexing of a 452 single byte stream, using either coupled congestion control or for 453 throughput maximization, 455 o address family multiplexing (using IPv4 and IPv6 for the same 456 session), 458 o resilience to network failure and/or handover. 460 3.3. Stream Control Transmission Protocol (SCTP) 462 SCTP is a message-oriented IETF standards track transport protocol. 463 The base protocol is specified in [RFC4960]. It supports multi- 464 homing and path failover to provide resilience to path failures. An 465 SCTP association has multiple streams in each direction, providing 466 in-sequence delivery of user messages within each stream. This 467 allows it to minimize head of line blocking. SCTP supports multiple 468 stream scheduling schemes controlling stream multiplexing, including 469 priority and fair weighting schemes. 471 SCTP was originally developed for transporting telephony signaling 472 messages and is deployed in telephony signaling networks, especially 473 in mobile telephony networks. It can also be used for other 474 services, for example, in the WebRTC framework for data channels. 476 3.3.1. Protocol Description 478 SCTP is a connection-oriented protocol using a four way handshake to 479 establish an SCTP association, and a three way message exchange to 480 gracefully shut it down. It uses the same port number concept as 481 DCCP, TCP, UDP, and UDP-Lite. SCTP only supports unicast. 483 SCTP uses the 32-bit CRC32c for protecting SCTP packets against bit 484 errors and misdelivery of packets to an unintended endpoint. This is 485 stronger than the 16-bit checksums used by TCP or UDP. However, 486 partial payload checksum coverage as provided by DCCP or UDP-Lite is 487 not supported. 489 SCTP has been designed with extensibility in mind. A common header 490 is followed by a sequence of chunks. [RFC4960] defines how a 491 receiver processes chunks with an unknown chunk type. The support of 492 extensions can be negotiated during the SCTP handshake. Currently 493 defined extensions include mechanisms for dynamic re-configuration of 494 streams [RFC6525] and IP addresses [RFC5061]. Furthermore, the 495 extension specified in [RFC3758] introduces the concept of partial 496 reliability for user messages. 498 SCTP provides a message-oriented service. Multiple small user 499 messages can be bundled into a single SCTP packet to improve 500 efficiency. For example, this bundling may be done by delaying user 501 messages at the sender, similar to Nagle's algorithm used by TCP. 502 User messages which would result in IP packets larger than the MTU 503 will be fragmented at the sender and reassembled at the receiver. 504 There is no protocol limit on the user message size. For MTU 505 discovery the same mechanism than for TCP can be used 506 [RFC1981][RFC4821], as well as utilizing probe packets with padding 507 chunks, as defined in [RFC4820]. 509 [RFC4960] specifies TCP-friendly congestion control to protect the 510 network against overload. SCTP also uses sliding window flow control 511 to protect receivers against overflow. Similar to TCP, SCTP also 512 supports delaying acknowledgments. [RFC7053] provides a way for the 513 sender of user messages to request the immediate sending of the 514 corresponding acknowledgments. 516 Each SCTP association has between 1 and 65536 uni-directional streams 517 in each direction. The number of streams can be different in each 518 direction. Every user message is sent on a particular stream. User 519 messages can be sent un-ordered, or ordered upon request by the upper 520 layer. Un-ordered messages can be delivered as soon as they are 521 completely received. Ordered messages sent on the same stream are 522 delivered at the receiver in the same order as sent by the sender. 523 For user messages not requiring fragmentation, this minimizes head of 524 line blocking. 526 The base protocol defined in [RFC4960] does not allow interleaving of 527 user- messages. Large messages on one stream can therefore block the 528 sending of user messages on other streams. 529 [I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation. This draft 530 also specifies multiple algorithms for the sender side selection of 531 which streams to send data from, supporting a variety of scheduling 532 algorithms including priority based methods. The stream re- 533 configuration extension defined in [RFC6525] allows streams to be 534 reset during the lifetime of an association and to increase the 535 number of streams, if the number of streams negotiated in the SCTP 536 handshake becomes insufficient. 538 Each user message sent is either delivered to the receiver or, in 539 case of excessive retransmissions, the association is terminated in a 540 non-graceful way [RFC4960], similar to TCP behavior. In addition to 541 this reliable transfer, the partial reliability extension [RFC3758] 542 allows a sender to abandon user messages. The application can 543 specify the policy for abandoning user messages. 545 SCTP supports multi-homing. Each SCTP endpoint uses a list of IP- 546 addresses and a single port number. These addresses can be any 547 mixture of IPv4 and IPv6 addresses. These addresses are negotiated 548 during the handshake and the address re-configuration extension 549 specified in [RFC5061] in combination with [RFC4895] can be used to 550 change these addresses in an authenticated way during the lifetime of 551 an SCTP association. This allows for transport layer mobility. 552 Multiple addresses are used for improved resilience. If a remote 553 address becomes unreachable, the traffic is switched over to a 554 reachable one, if one exists. 556 For securing user messages, the use of TLS over SCTP has been 557 specified in [RFC3436]. However, this solution does not support all 558 services provided by SCTP, such as un-ordered delivery or partial 559 reliability. Therefore, the use of DTLS over SCTP has been specified 560 in [RFC6083] to overcome these limitations. When using DTLS over 561 SCTP, the application can use almost all services provided by SCTP. 563 [I-D.ietf-tsvwg-natsupp] defines methods for endpoints and 564 middleboxes to provide NAT traversal for SCTP over IPv4. For legacy 565 NAT traversal, [RFC6951] defines the UDP encapsulation of SCTP- 566 packets. Alternatively, SCTP packets can be encapsulated in DTLS 567 packets as specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. The 568 latter encapsulation is used within the WebRTC context. 570 SCTP has a well-defined API, described in the next subsection. 572 3.3.2. Interface Description 574 [RFC4960] defines an abstract API for the base protocol. This API 575 describes the following functions callable by the upper layer of 576 SCTP: Initialize, Associate, Send, Receive, Receive Unsent Message, 577 Receive Unacknowledged Message, Shutdown, Abort, SetPrimary, Status, 578 Change Heartbeat, Request Heartbeat, Get SRTT Report, Set Failure 579 Threshold, Set Protocol Parameters, and Destroy. The following 580 notifications are provided by the SCTP stack to the upper layer: 581 COMMUNICATION UP, DATA ARRIVE, SHUTDOWN COMPLETE, COMMUNICATION LOST, 582 COMMUNICATION ERROR, RESTART, SEND FAILURE, NETWORK STATUS CHANGE. 584 An extension to the BSD Sockets API is defined in [RFC6458] and 585 covers: 587 o the base protocol defined in [RFC4960]. The API allows control 588 over local addresses and port numbers and the primary path. 589 Furthermore the application has fine control about parameters like 590 retransmission thresholds, the path supervision parameters, the 591 delayed acknowledgment timeout, and the fragmentation point. The 592 API provides a mechanism to allow the SCTP stack to notify the 593 application about events if the application has requested them. 594 These notifications provide information about status changes of 595 the association and each of the peer addresses. In case of send 596 failures, including drop of messages sent unreliably, the 597 application can also be notified and user messages can be returned 598 to the application. When sending user messages, the stream id, a 599 payload protocol identifier, an indication whether ordered 600 delivery is requested or not. These parameters can also be 601 provided on message reception. Additionally a context can be 602 provided when sending, which can be use in case of send failures. 603 The sending of arbitrary large user messages is supported. 605 o the SCTP Partial Reliability extension defined in [RFC3758] to 606 specify for a user message the PR-SCTP policy and the policy 607 specific parameter. Examples of these policies defined in 608 [RFC3758] and [RFC7496] are: 610 * Limiting the time a user message is dealt with by the sender. 612 * Limiting the number of retransmissions for each fragment of a 613 user message. If the number of retransmissions is limited to 614 0, one gets a service similar to UDP. 616 * Abandoning messages of lower priority in case of a send buffer 617 shortage. 619 o the SCTP Authentication extension defined in [RFC4895] allowing to 620 manage the shared keys, the HMAC to use, set the chunk types which 621 are only accepted in an authenticated way, and get the list of 622 chunks which are accepted by the local and remote end point in an 623 authenticated way. 625 o the SCTP Dynamic Address Reconfiguration extension defined in 626 [RFC5061]. It allows to manually add and delete local addresses 627 for SCTP associations and the enabling of automatic address 628 addition and deletion. Furthermore the peer can be given a hint 629 for choosing its primary path. 631 For the following SCTP protocol extensions the BSD Sockets API 632 extension is defined in the document specifying the protocol 633 extensions: 635 o the SCTP Stream Reconfiguration extension defined in [RFC6525]. 636 The API allows to trigger the reset operation for incoming and 637 outgoing streams and the whole association. It provides also a 638 way to notify the association about the corresponding events. 639 Furthermore the application can increase the number of streams. 641 o the UDP Encapsulation of SCTP packets extension defined in 642 [RFC6951]. The API allows the management of the remote UDP 643 encapsulation port. 645 o the SCTP SACK-IMMEDIATELY extension defined in [RFC7053]. The API 646 allows the sender of a user message to request the receiver to 647 send the corresponding acknowledgment immediately. 649 o the additional PR-SCTP policies defined in [RFC7496]. The API 650 allows to enable/disable the PR-SCTP extension, choose the PR-SCTP 651 policies defined in the document and provide statistical 652 information about abandoned messages. 654 Future documents describing SCTP protocol extensions are expected to 655 describe the corresponding BSD Sockets API extension in a "Socket API 656 Considerations" section. 658 The SCTP socket API supports two kinds of sockets: 660 o one-to-one style sockets (by using the socket type "SOCK_STREAM"). 662 o one-to-many style socket (by using the socket type 663 "SOCK_SEQPACKET"). 665 One-to-one style sockets are similar to TCP sockets, there is a 1:1 666 relationship between the sockets and the SCTP associations (except 667 for listening sockets). One-to-many style SCTP sockets are similar 668 to unconnected UDP sockets, where there is a 1:n relationship between 669 the sockets and the SCTP associations. 671 The SCTP stack can provide information to the applications about 672 state changes of the individual paths and the association whenever 673 they occur. These events are delivered similar to user messages but 674 are specifically marked as notifications. 676 New functions have been introduced to support the use of multiple 677 local and remote addresses. Additional SCTP-specific send and 678 receive calls have been defined to permit SCTP-specific information 679 to be sent without using ancillary data in the form of additional 680 cmsgs. These functions provide support for detecting partial 681 delivery of user messages and notifications. 683 The SCTP socket API allows a fine-grained control of the protocol 684 behavior through an extensive set of socket options. 686 The SCTP kernel implementations of FreeBSD, Linux and Solaris follow 687 mostly the specified extension to the BSD Sockets API for the base 688 protocol and the corresponding supported protocol extensions. 690 3.3.3. Transport Features 692 The transport features provided by SCTP are: 694 o connection-oriented transport with feature negotiation and 695 application-to-port mapping, 697 o unicast transport, 699 o port multiplexing, 701 o uni- or bidirectional communication, 703 o message-oriented delivery with durable message framing supporting 704 multiple concurrent streams, 706 o fully reliable, partially reliable, or unreliable delivery (based 707 on user specified policy to handle abandoned user messages) with 708 drop notification, 710 o ordered and unordered delivery within a stream, 712 o support for stream scheduling prioritization, 714 o segmentation, 715 o user message bundling, 717 o flow control using a window-based mechanism, 719 o congestion control using methods similar to TCP, 721 o strong error detection (CRC32c), 723 o transport layer multihoming for resilience and mobility. 725 3.4. User Datagram Protocol (UDP) 727 The User Datagram Protocol (UDP) [RFC0768] [RFC2460] is an IETF 728 standards track transport protocol. It provides a unidirectional 729 datagram protocol that preserves message boundaries. It provides no 730 error correction, congestion control, or flow control. It can be 731 used to send broadcast datagrams (IPv4) or multicast datagrams (IPv4 732 and IPv6), in addition to unicast and anycast datagrams. IETF 733 guidance on the use of UDP is provided in 734 [I-D.ietf-tsvwg-rfc5405bis]. UDP is widely implemented and widely 735 used by common applications, including DNS. 737 3.4.1. Protocol Description 739 UDP is a connection-less protocol that maintains message boundaries, 740 with no connection setup or feature negotiation. The protocol uses 741 independent messages, ordinarily called datagrams. It provides 742 detection of payload errors and misdelivery of packets to an 743 unintended endpoint, either of which result in discard of received 744 datagrams, with no indication to the user of the service. 746 It is possible to create IPv4 UDP datagrams with no checksum, and 747 while this is generally discouraged [RFC1122] 748 [I-D.ietf-tsvwg-rfc5405bis], certain special cases permit this use. 749 These datagrams rely on the IPv4 header checksum to protect from 750 misdelivery to an unintended endpoint. IPv6 does not permit UDP 751 datagrams with no checksum, although in certain cases this rule may 752 be relaxed [RFC6935]. 754 UDP does not provide reliability and does not provide retransmission. 755 This implies messages may be re-ordered, lost, or duplicated in 756 transit. Note that due to the relatively weak form of checksum used 757 by UDP, applications that require end to end integrity of data are 758 recommended to include a stronger integrity check of their payload 759 data. 761 Because UDP provides no flow control, a receiving application that is 762 unable to run sufficiently fast, or frequently, may miss messages. 764 The lack of congestion handling implies UDP traffic may experience 765 loss when using an overloaded path, and may cause the loss of 766 messages from other protocols (e.g., TCP) when sharing the same 767 network path. 769 On transmission, UDP encapsulates each datagram into a single IP 770 packet or several IP packet fragments. This allows a datagram to be 771 larger than the effective path MTU. Fragments are reassembled before 772 delivery to the UDP receiver, making this transparent to the user of 773 the transport service. When the jumbograms are supported, larger 774 messages may be sent without performing fragmentation. 776 Applications that need to provide fragmentation or that have other 777 requirements such as receiver flow control, congestion control, 778 PathMTU discovery/PLPMTUD, support for ECN, etc. need these to be 779 provided by protocols operating over UDP [I-D.ietf-tsvwg-rfc5405bis]. 781 3.4.2. Interface Description 783 [RFC0768] describes basic requirements for an API for UDP. Guidance 784 on use of common APIs is provided in [I-D.ietf-tsvwg-rfc5405bis]. 786 A UDP endpoint consists of a tuple of (IP address, port number). De- 787 multiplexing using multiple abstract endpoints (sockets) on the same 788 IP address is supported. The same socket may be used by a single 789 server to interact with multiple clients (note: this behavior differs 790 from TCP, which uses a pair of tuples to identify a connection). 791 Multiple server instances (processes) that bind to the same socket 792 can cooperate to service multiple clients. The socket implementation 793 arranges to not duplicate the same received unicast message to 794 multiple server processes. 796 Many operating systems also allow a UDP socket to be "connected", 797 i.e., to bind a UDP socket to a specific (remote) UDP endpoint. 798 Unlike TCP's connect primitive, for UDP, this is only a local 799 operation that serves to simplify the local send/receive functions 800 and to filter the traffic for the specified addresses and ports 801 [I-D.ietf-tsvwg-rfc5405bis]. 803 3.4.3. Transport Features 805 The transport features provided by UDP are: 807 o unicast, multicast, anycast, or IPv4 broadcast transport, 809 o port multiplexing (where a receiving port can be configured to 810 receive datagrams from multiple senders), 812 o message-oriented delivery, 814 o uni- or bidirectional communication where the transmissions in 815 each direction are independent, 817 o non-reliable delivery, 819 o unordered delivery, 821 o error detection (implemented using a segment checksum to verify 822 delivery to the correct endpoint and integrity of the data; 823 optional for IPv4 and optional under specific conditions for IPv6 824 where all or none of the payload data is protected), 826 3.5. Lightweight User Datagram Protocol (UDP-Lite) 828 The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] is an 829 IETF standards track transport protocol. It provides a 830 unidirectional, datagram protocol that preserves message boundaries. 831 IETF guidance on the use of UDP- Lite is provided in 832 [I-D.ietf-tsvwg-rfc5405bis]. A UDP-Lite service may support IPv4 833 broadcast, multicast, anycast and unicast, and IPv6 multicast, 834 anycast and unicast. 836 Examples of use include a class of applications that can derive 837 benefit from having partially-damaged payloads delivered, rather than 838 discarded. One use is to support error tolerate payload corruption 839 when used over paths that include error-prone links, another 840 application is when header integrity checks are required, but payload 841 integrity is provided by some other mechanism (e.g., [RFC6936]). 843 3.5.1. Protocol Description 845 Like UDP, UDP-Lite is a connection-less datagram protocol, with no 846 connection setup or feature negotiation. It changes the semantics of 847 the UDP "payload length" field to that of a "checksum coverage 848 length" field, and is identified by a different IP protocol/next- 849 header value. The "checksum coverage length" field specifies the 850 intended checksum coverage, with the remaining unprotected part of 851 the payload called the "error-insensitive part". Applications using 852 UDP-Lite therefore cannot make assumptions regarding the correctness 853 of the data received in the insensitive part of the UDP-Lite payload. 855 Otherwise, UDP-Lite is semantically identical to UDP. In the same 856 way as for UDP, mechanisms for receiver flow control, congestion 857 control, PMTU or PLPMTU discovery, support for ECN, etc. needs to be 858 provided by upper layer protocols [I-D.ietf-tsvwg-rfc5405bis]. 860 3.5.2. Interface Description 862 There is no API currently specified in the RFC Series, but guidance 863 on use of common APIs is provided in [I-D.ietf-tsvwg-rfc5405bis]. 865 The interface of UDP-Lite differs from that of UDP by the addition of 866 a single (socket) option that communicates a checksum coverage length 867 value. The checksum coverage may also be made visible to the 868 application via the UDP-Lite MIB module [RFC5097]. 870 3.5.3. Transport Features 872 The transport features provided by UDP-Lite are: 874 o unicast, multicast, anycast, or IPv4 broadcast transport (as for 875 UDP), 877 o port multiplexing (as for UDP), 879 o message-oriented delivery (as for UDP), 881 o Uni- or bidirectional communication where the transmissions in 882 each direction are independent (as for UDP), 884 o non-reliable delivery (as for UDP), 886 o non-ordered delivery (as for UDP), 888 o partial or full payload error detection (where the checksum 889 coverage field indicates the size of the payload data covered by 890 the checksum). 892 3.6. Datagram Congestion Control Protocol (DCCP) 894 Datagram Congestion Control Protocol (DCCP) [RFC4340] is an IETF 895 standards track bidirectional transport protocol that provides 896 unicast connections of congestion-controlled messages without 897 providing reliability. 899 The DCCP Problem Statement describes the goals that DCCP sought to 900 address [RFC4336]: It is suitable for applications that transfer 901 fairly large amounts of data and that can benefit from control over 902 the trade off between timeliness and reliability [RFC4336]. 904 DCCP offers low overhead, and many characteristics common to UDP, but 905 can avoid "re-inventing the wheel" each time a new multimedia 906 application emerges. Specifically it includes core transport 907 functions (feature negotiation, path state management, RTT 908 calculation, PMTUD, etc.): DCCP applications select how they send 909 packets and, where suitable, choose common algorithms to manage their 910 functions. Examples of applications that can benefit from such 911 transport services include interactive applications, streaming media, 912 or on-line games [RFC4336]. 914 3.6.1. Protocol Description 916 DCCP is a connection-oriented datagram protocol, providing a three- 917 way handshake to allow a client and server to set up a connection, 918 and mechanisms for orderly completion and immediate teardown of a 919 connection. 921 A DCCP protocol instance can be extended [RFC4340] and tuned using 922 additional features. Some features are sender-side only, requiring 923 no negotiation with the receiver; some are receiver-side only; and 924 some are explicitly negotiated during connection setup. 926 DCCP uses a Connect packet to initiate a session, and permits each 927 endpoint to choose the features it wishes to support. Simultaneous 928 open [RFC5596], as in TCP, can enable interoperability in the 929 presence of middleboxes. The Connect packet includes a Service Code 930 [RFC5595] that identifies the application or protocol using DCCP, 931 providing middleboxes with information about the intended use of a 932 connection. 934 DCCP service is unicast-only. 936 It provides multiplexing to multiple sockets at each endpoint using 937 port numbers. An active DCCP session is identified by its four-tuple 938 of local and remote IP addresses and local port and remote port 939 numbers. 941 The protocol segments data into messages, typically sized to fit in 942 IP packets, but which may be fragmented providing they are smaller 943 than the maximum packet size. A DCCP interface allows applications 944 to request fragmentation for packets larger than PMTU, but not larger 945 than the maximum packet size allowed by the current congestion 946 control mechanism (CCMPS) [RFC4340]. 948 Each message is identified by a sequence number. The sequence number 949 is used to identify segments in acknowledgments, to detect 950 unacknowledged segments, to measure RTT, etc. The protocol may 951 support unordered delivery of data, and does not itself provide 952 retransmission. DCCP supports reduced checksum coverage, a partial 953 payload protection mechanism similar to UDP-Lite. There is also a 954 Data Checksum option, which when enabled, contains a strong CRC, to 955 enable endpoints to detect application data corruption. 957 Receiver flow control is supported, which limits the amount of 958 unacknowledged data that can be outstanding at a given time. 960 DCCP supports negotiation of the congestion control profile between 961 endpoints, to provide plug-and-play congestion control mechanisms. 962 Examples of specified profiles include "TCP-like" [RFC4341], "TCP- 963 friendly" [RFC4342], and "TCP-friendly for small packets" [RFC5622]. 964 Additional mechanisms are recorded in an IANA registry. 966 A lightweight UDP-based encapsulation (DCCP-UDP) has been defined 967 [RFC6773] that permits DCCP to be used over paths where DCCP is not 968 natively supported. Support for DCCP in NAPT/NATs is defined in 969 [RFC4340] and [RFC5595]. Upper layer protocols specified on top of 970 DCCP include DTLS [RFC5595], RTP [RFC5672], ICE/SDP [RFC6773]. 972 3.6.2. Interface Description 974 Functions expected for a DCCP API include: Open, Close and Management 975 of the progress a DCCP connection. The Open function provides 976 feature negotiation, selection of an appropriate CCID for congestion 977 control and other parameters associated with the DCCP connection. A 978 function allows an application to send DCCP datagrams, including 979 setting the required checksum coverage, and any required options. 980 (DCCP permits sending datagrams with a zero-length payload.) A 981 function allows reception of data, including indicating if the data 982 was used or dropped. Functions can also make the status of a 983 connection visible to an application, including detection of the 984 maximum packet size and the ability to perform flow control by 985 detecting a slow receiver at the sender. 987 There is no API currently specified in the RFC Series. 989 3.6.3. Transport Features 991 The transport features provided by DCCP are: 993 o unicast transport, 995 o connection-oriented communication with feature negotiation and 996 application-to-port mapping, 998 o signaling of application class for middlebox support (implemented 999 using Service Codes), 1001 o port multiplexing, 1003 o uni-or bidirectional communication, 1004 o message-oriented delivery, 1006 o unreliable delivery with drop notification, 1008 o unordered delivery, 1010 o flow control (implemented using the slow receiver function) 1012 o partial and full payload error detection (with optional strong 1013 integrity check). 1015 3.7. Internet Control Message Protocol (ICMP) 1017 The Internet Control Message Protocol (ICMP) [RFC0792] for IPv4 and 1018 ICMP for IPv6 [RFC4433] are IETF standards track protocols. It is a 1019 connection-less unidirectional protocol that delivers individual 1020 messages, without error correction, congestion control, or flow 1021 control. Messages may be sent as unicast, IPv4 broadcast or 1022 multicast datagrams (IPv4 and IPv6), in addition to anycast 1023 datagrams. 1025 Transport Protocols and upper layer protocols can use received ICMP 1026 messages to help them take appropriate decisions when network or 1027 endpoint errors are reported. For example, to implement, ICMP-based 1028 Path MTU discovery [RFC1191][RFC1981] or assist in Packetization 1029 Layer Path MTU Discovery (PMTUD) [RFC4821]. Such reactions to 1030 received messages need to protect from off-path data injection 1031 [I-D.ietf-tsvwg-rfc5405bis], to avoid an application receiving 1032 packets created by an unauthorized third party. An application 1033 therefore needs to ensure that all messages are appropriately 1034 validated, by checking the payload of the messages to ensure these 1035 are received in response to actually transmitted traffic (e.g., a 1036 reported error condition that corresponds to a UDP datagram or TCP 1037 segment was actually sent by the application). This requires context 1038 [RFC6056], such as local state about communication instances to each 1039 destination (e.g., in the TCP, DCCP, or SCTP protocols). This state 1040 is not always maintained by UDP-based applications 1041 [I-D.ietf-tsvwg-rfc5405bis]. 1043 3.7.1. Protocol Description 1045 ICMP is a connection-less unidirectional protocol, It delivers 1046 independent messages, called datagrams. Each message is required to 1047 carry a checksum as an integrity check and to protect from mis- 1048 delivery to an unintended endpoint. 1050 ICMP messages typically relay diagnostic information from an endpoint 1051 [RFC1122] or network device [RFC1716] addressed to the sender of a 1052 flow. This usually contains the network protocol header of a packet 1053 that encountered a reported issue. Some formats of messages can also 1054 carry other payload data. Each message carries an integrity check 1055 calculated in the same way as for UDP, this checksum is not optional. 1057 The RFC series defines additional IPv6 message formats to support a 1058 range of uses. In the case of IPv6 the protocol incorporates 1059 neighbor discovery [RFC2461] [RFC3971]} (provided by ARP for IPv4) 1060 and the Multicast Listener Discovery (MLD) [RFC2710] group management 1061 functions (provided by IGMP for IPv4). 1063 Reliable transmission can not be assumed. A receiving application 1064 that is unable to run sufficiently fast, or frequently, may miss 1065 messages since there is no flow or congestion control. In addition 1066 some network devices rate-limit ICMP messages. 1068 3.7.2. Interface Description 1070 ICMP processing is integrated in many connection-oriented transports, 1071 but like other functions needs to be provided by an upper-layer 1072 protocol when using UDP and UDP-Lite. 1074 On some stacks, a bound socket also allows a UDP application to be 1075 notified when ICMP error messages are received for its transmissions 1076 [I-D.ietf-tsvwg-rfc5405bis]. 1078 Any response to ICMP error messages ought to be robust to temporary 1079 routing failures (sometimes called "soft errors"), e.g., transient 1080 ICMP "unreachable" messages ought to not normally cause a 1081 communication abort [RFC5461] [I-D.ietf-tsvwg-rfc5405bis]. 1083 3.7.3. Transport Features 1085 ICMP does not provide any transport service directly to applications. 1086 Used together with other transport protocols, it provides 1087 transmission of control, error, and measurement data between 1088 endpoints, or from devices along the path to one endpoint. 1090 3.8. Realtime Transport Protocol (RTP) 1092 RTP provides an end-to-end network transport service, suitable for 1093 applications transmitting real-time data, such as audio, video or 1094 data, over multicast or unicast transport services, including TCP, 1095 UDP, UDP-Lite, DCCP, TLS and DTLS. 1097 3.8.1. Protocol Description 1099 The RTP standard [RFC3550] defines a pair of protocols, RTP and the 1100 RTP control protocol, RTCP. The transport does not provide 1101 connection setup, instead relying on out-of-band techniques or 1102 associated control protocols to setup, negotiate parameters or tear 1103 down a session. 1105 An RTP sender encapsulates audio/video data into RTP packets to 1106 transport media streams. The RFC-series specifies RTP payload 1107 formats that allow packets to carry a wide range of media, and 1108 specifies a wide range of multiplexing, error control and other 1109 support mechanisms. 1111 If a frame of media data is large, it will be fragmented into several 1112 RTP packets. Likewise, several small frames may be bundled into a 1113 single RTP packet. 1115 An RTP receiver collects RTP packets from the network, validates them 1116 for correctness, and sends them to the media decoder input-queue. 1117 Missing packet detection is performed by the channel decoder. The 1118 play-out buffer is ordered by time stamp and is used to reorder 1119 packets. Damaged frames may be repaired before the media payloads 1120 are decompressed to display or store the data. Some uses of RTP are 1121 able to exploit the partial payload protection features offered by 1122 DCCP and UDP-Lite. 1124 RTCP is a control protocol that works alongside an RTP flow. Both 1125 the RTP sender and receiver will send RTCP report packets. This is 1126 used to periodically send control information and report performance. 1127 Based on received RTCP feedback, an RTP sender can adjust the 1128 transmission, e.g., perform rate adaptation at the application layer 1129 in the case of congestion. 1131 An RTCP receiver report (RTCP RR) is returned to the sender 1132 periodically to report key parameters (e.g, the fraction of packets 1133 lost in the last reporting interval, the cumulative number of packets 1134 lost, the highest sequence number received, and the inter-arrival 1135 jitter). The RTCP RR packets also contain timing information that 1136 allows the sender to estimate the network round trip time (RTT) to 1137 the receivers. 1139 The interval between reports sent from each receiver tends to be on 1140 the order of a few seconds on average, although this varies with the 1141 session rate, and sub-second reporting intervals are possible for 1142 high rate sessions. The interval is randomized to avoid 1143 synchronization of reports from multiple receivers. 1145 3.8.2. Interface Description 1147 There is no standard application programming interface defined for 1148 RTP or RTCP. Implementations are typically tightly integrated with a 1149 particular application, and closely follow the principles of 1150 application level framing and integrated layer processing [ClarkArch] 1151 in media processing [RFC2736], error recovery and concealment, rate 1152 adaptation, and security [RFC7202]. Accordingly, RTP implementations 1153 tend to be targeted at particular application domains (e.g., voice- 1154 over-IP, IPTV, or video conferencing), with a feature set optimized 1155 for that domain, rather than being general purpose implementations of 1156 the protocol. 1158 3.8.3. Transport Features 1160 The transport features provided by RTP are: 1162 o unicast, multicast or IPv4 broadcast (provided by lower layer 1163 protocol), 1165 o port multiplexing (provided by lower layer protocol), 1167 o uni- or bidirectional communication (provided by lower layer 1168 protocol), 1170 o message-oriented delivery with support for media types and other 1171 extensions, 1173 o reliable delivery when using erasure coding or unreliable delivery 1174 with drop notification (if supported by lower layer protocol), 1176 o connection setup with feature negotiation (using associated 1177 protocols) and application-to-port mapping (provided by lower 1178 layer protocol), 1180 o segmentation, 1182 o performance metric reporting (using associated protocols). 1184 3.9. File Delivery over Unidirectional Transport/Asynchronous Layered 1185 Coding Reliable Multicast (FLUTE/ALC) 1187 FLUTE/ALC is an IETF standards track protocol specified in [RFC6726] 1188 and [RFC5775]. It provides object-oriented delivery of discrete data 1189 or files. Asynchronous Layer Coding (ALC) provides an underlying 1190 reliable transport service and FLUTE a file-oriented specialization 1191 of the ALC service (e.g., to carry associated metadata). The 1192 [RFC6726] and [RFC5775] protocols are non-backward-compatible updates 1193 of the [RFC3926] and [RFC3450] experimental protocols; these 1194 experimental protocols are currently largely deployed in the 3GPP 1195 Multimedia Broadcast and Multicast Services (MBMS) (see [MBMS], 1196 section 7) and similar contexts (e.g., the Japanese ISDB-Tmm 1197 standard). 1199 The FLUTE/ALC protocol has been designed to support massively 1200 scalable reliable bulk data dissemination to receiver groups of 1201 arbitrary size using IP Multicast over any type of delivery network, 1202 including unidirectional networks (e.g., broadcast wireless 1203 channels). However, the FLUTE/ALC protocol also supports point-to- 1204 point unicast transmissions. 1206 FLUTE/ALC bulk data dissemination has been designed for discrete file 1207 or memory-based "objects". Although FLUTE/ALC is not well adapted to 1208 byte- and message-streaming, there is an exception: FLUTE/ALC is used 1209 to carry 3GPP Dynamic Adaptive Streaming over HTTP (DASH) when 1210 scalability is a requirement (see [MBMS], section 5.6). 1212 FLUTE/ALC's reliability, delivery mode, congestion control, and flow/ 1213 rate control mechanisms can be separately controlled to meet 1214 different application needs. Section 4.1 of 1215 [I-D.ietf-tsvwg-rfc5405bis] describes multicast congestion control 1216 requirements for UDP. 1218 3.9.1. Protocol Description 1220 The FLUTE/ALC protocol works on top of UDP (though it could work on 1221 top of any datagram delivery transport protocol), without requiring 1222 any connectivity from receivers to the sender. Purely unidirectional 1223 networks are therefore supported by FLUTE/ALC. This guarantees 1224 scalability to an unlimited number of receivers in a session, since 1225 the sender behaves exactly the same regardless of the number of 1226 receivers. 1228 FLUTE/ALC supports the transfer of bulk objects such as file or in- 1229 memory content, using either a push or an on-demand mode. in push 1230 mode, content is sent once to the receivers, while in on-demand mode, 1231 content is sent continuously during periods of time that can greatly 1232 exceed the average time required to download the session objects (see 1233 [RFC5651], section 4.2). 1235 This enables receivers to join a session asynchronously, at their own 1236 discretion, receive the content and leave the session. In this case, 1237 data content is typically sent continuously, in loops (also known as 1238 "carousels"). FLUTE/ALC also supports the transfer of an object 1239 stream, with loose real-time constraints. This is particularly 1240 useful to carry 3GPP DASH when scalability is a requirement and 1241 unicast transmissions over HTTP cannot be used ([MBMS], section 5.6). 1242 In this case, packets are sent in sequence using push mode. FLUTE/ 1243 ALC is not well adapted to byte- and message-streaming and other 1244 solutions could be preferred (e.g., FECFRAME [RFC6363] with real-time 1245 flows). 1247 The FLUTE file delivery instantiation of ALC provides a metadata 1248 delivery service. Each object of the FLUTE/ALC session is described 1249 in a dedicated entry of a File Delivery Table (FDT), using an XML 1250 format (see [RFC6726], section 3.2). This metadata can include, but 1251 is not restricted to, a URI attribute (to identify and locate the 1252 object), a media type attribute, a size attribute, an encoding 1253 attribute, or a message digest attribute. Since the set of objects 1254 sent within a session can be dynamic, with new objects being added 1255 and old ones removed, several instances of the FDT can be sent and a 1256 mechanism is provided to identify a new FDT Instance. 1258 Error detection and verification of the protocol control information 1259 relies on the on the underlying transport (e.g., UDP checksum). 1261 To provide robustness against packet loss and improve the efficiency 1262 of the on-demand mode, FLUTE/ALC relies on packet erasure coding (AL- 1263 FEC). AL-FEC encoding is proactive (since there is no feedback and 1264 therefore no (N)ACK-based retransmission) and ALC packets containing 1265 repair data are sent along with ALC packets containing source data. 1266 Several FEC Schemes have been standardized; FLUTE/ALC does not 1267 mandate the use of any particular one. Several strategies concerning 1268 the transmission order of ALC source and repair packets are possible, 1269 in particular in on-demand mode where it can deeply impact the 1270 service provided (e.g., to favor the recovery of objects in sequence, 1271 or at the other extreme, to favor the recovery of all objects in 1272 parallel), and FLUTE/ALC does not mandate nor recommend the use of 1273 any particular one. 1275 A FLUTE/ALC session is composed of one or more channels, associated 1276 to different destination unicast and/or multicast IP addresses. ALC 1277 packets are sent in those channels at a certain transmission rate, 1278 with a rate that often differs depending on the channel. FLUTE/ALC 1279 does not mandate nor recommend any strategy to select which ALC 1280 packet to send on which channel. FLUTE/ALC can use a multiple rate 1281 congestion control building block (e.g., WEBRC) to provide congestion 1282 control that is feedback free, where receivers adjust their reception 1283 rates individually by joining and leaving channels associated with 1284 the session. To that purpose, the ALC header provides a specific 1285 field to carry congestion control specific information. However 1286 FLUTE/ALC does not mandate the use of a particular congestion control 1287 mechanism although WEBRC is mandatory to support for the Internet 1288 ([RFC6726], section 1.1.4). FLUTE/ALC is often used over a network 1289 path with pre-provisioned capacity [I-D.ietf-tsvwg-rfc5405bis] where 1290 there are no flows competing for capacity. In this case, a sender- 1291 based rate control mechanism and a single channel is sufficient. 1293 [RFC6584] provides per-packet authentication, integrity, and anti- 1294 replay protection in the context of the ALC and NORM protocols. 1295 Several mechanisms are proposed that seamlessly integrate into these 1296 protocols using the ALC and NORM header extension mechanisms. 1298 3.9.2. Interface Description 1300 The FLUTE/ALC specification does not describe a specific application 1301 programming interface (API) to control protocol operation. 1303 Open source reference implementations of FLUTE/ALC are available at 1304 http://planete-bcast.inrialpes.fr/ (no longer maintained) and 1305 http://mad.cs.tut.fi/ (no longer maintained), and these 1306 implementations specify and document their own APIs. Commercial 1307 versions are also available, some derived from the above 1308 implementations, with their own API. 1310 3.9.3. Transport Features 1312 The transport features provided by FLUTE/ALC are: 1314 o unicast, multicast, anycast or IPv4 broadcast transmission, 1316 o object-oriented delivery of discrete data or files and associated 1317 metadata, 1319 o fully reliable or partially reliable delivery (of file or in- 1320 memory objects), using proactive packet erasure coding (AL-FEC) to 1321 recover from packet erasures, 1323 o ordered or unordered delivery (of file or in-memory objects), 1325 o error detection (based on the UDP checksum), 1327 o per-packet authentication, 1329 o per-packet integrity, 1331 o per-packet replay protection, 1333 o congestion control for layered flows (e.g., with WEBRC). 1335 3.10. NACK-Oriented Reliable Multicast (NORM) 1337 NORM is an IETF standards track protocol specified in [RFC5740]. It 1338 provides object-oriented delivery of discrete data or files. 1340 The protocol was designed to support reliable bulk data dissemination 1341 to receiver groups using IP Multicast but also provides for point-to- 1342 point unicast operation. Support for bulk data dissemination 1343 includes discrete file or computer memory-based "objects" as well as 1344 byte- and message-streaming. 1346 NORM can incorporate packet erasure coding as a part of its selective 1347 ARQ in response to negative acknowledgments from the receiver. The 1348 packet erasure coding can also be proactively applied for forward 1349 protection from packet loss. NORM transmissions are governed by the 1350 TCP-friendly congestion control. The reliability, congestion control 1351 and flow control mechanisms can be separately controlled to meet 1352 different application needs. 1354 3.10.1. Protocol Description 1356 The NORM protocol is encapsulated in UDP datagrams and thus provides 1357 multiplexing for multiple sockets on hosts using port numbers. For 1358 loosely coordinated IP Multicast, NORM is not strictly connection- 1359 oriented although per-sender state is maintained by receivers for 1360 protocol operation. [RFC5740] does not specify a handshake protocol 1361 for connection establishment. Separate session initiation can be 1362 used to coordinate port numbers. However, in-band "client-server" 1363 style connection establishment can be accomplished with the NORM 1364 congestion control signaling messages using port binding techniques 1365 like those for TCP client-server connections. 1367 NORM supports bulk "objects" such as file or in-memory content but 1368 also can treat a stream of data as a logical bulk object for purposes 1369 of packet erasure coding. In the case of stream transport, NORM can 1370 support either byte streams or message streams where application- 1371 defined message boundary information is carried in the NORM protocol 1372 messages. This allows the receiver(s) to join/re-join and recover 1373 message boundaries mid-stream as needed. Application content is 1374 carried and identified by the NORM protocol with encoding symbol 1375 identifiers depending upon the Forward Error Correction (FEC) Scheme 1376 [RFC3452] configured. NORM uses NACK-based selective ARQ to reliably 1377 deliver the application content to the receiver(s). NORM proactively 1378 measures round-trip timing information to scale ARQ timers 1379 appropriately and to support congestion control. For multicast 1380 operation, timer-based feedback suppression is uses to achieve group 1381 size scaling with low feedback traffic levels. The feedback 1382 suppression is not applied for unicast operation. 1384 NORM uses rate-based congestion control based upon the TCP-Friendly 1385 Rate Control (TFRC) [RFC4324] principles that are also used in DCCP 1386 [RFC4340]. NORM uses control messages to measure RTT and collect 1387 congestion event information (e.g., reflecting a loss event or ECN 1388 event) from the receiver(s) to support dynamic adjustment or the 1389 rate. The TCP-Friendly Multicast Congestion Control (TFMCC) 1390 [RFC4654] provides extra features to support multicast, but is 1391 functionally equivalent to TFRC for unicast. 1393 Error detection and verification of the protocol control information 1394 relies on the on the underlying transport(e.g., UDP checksum). 1396 The reliability mechanism is decoupled from congestion control. This 1397 allows invocation of alternative arrangements of transport services. 1398 For example, to support, fixed-rate reliable delivery or unreliable 1399 delivery (that may optionally be "better than best effort" via packet 1400 erasure coding) using TFRC. Alternative congestion control 1401 techniques may be applied. For example, TFRC rate control with 1402 congestion event detection based on ECN. 1404 While NORM provides NACK-based reliability, it also supports a 1405 positive acknowledgment (ACK) mechanism that can be used for receiver 1406 flow control. This mechanism is decoupled from the reliability and 1407 congestion control, supporting applications with different needs. 1408 One example is use of NORM for quasi-reliable delivery, where timely 1409 delivery of newer content may be favored over completely reliable 1410 delivery of older content within buffering and RTT constraints. 1412 3.10.2. Interface Description 1414 The NORM specification does not describe a specific application 1415 programming interface (API) to control protocol operation. A freely- 1416 available, open source reference implementation of NORM is available 1417 at https://www.nrl.navy.mil/itd/ncs/products/norm, and a documented 1418 API is provided for this implementation. While a sockets-like API is 1419 not currently documented, the existing API supports the necessary 1420 functions for that to be implemented. 1422 3.10.3. Transport Features 1424 The transport features provided by NORM are: 1426 o unicast or multicast transport, 1428 o unidirectional communication, 1430 o stream-oriented delivery in a single stream or object-oriented 1431 delivery of in-memory data or file bulk content objects, 1433 o fully reliable (NACK-based) or partially reliable (using erasure 1434 coding both proactively and as part of ARQ) delivery, 1436 o unordered delivery, 1438 o error detection (relies on UDP checksum), 1440 o segmentation, 1442 o data bundling (using Nagle's algorithm), 1444 o flow control (timer-based and/or ack-based), 1446 o congestion control (also supporting fixed rate reliable or 1447 unreliable delivery). 1449 3.11. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a 1450 pseudotransport 1452 Transport Layer Security (TLS) [RFC5246]} and Datagram TLS (DTLS) 1453 [RFC6347]} are IETF protocols that provide several security-related 1454 features to applications. TLS is designed to run on top of a 1455 reliable streaming transport protocol (usually TCP), while DTLS is 1456 designed to run on top of a best-effort datagram protocol (UDP or 1457 DCCP [RFC5238]). At the time of writing, the current version of TLS 1458 is 1.2; which is defined in [RFC5246]. DTLS provides nearly 1459 identical functionality to applications; it is defined in [RFC6347] 1460 and its current version is also 1.2. The TLS protocol evolved from 1461 the Secure Sockets Layer (SSL) protocols developed in the mid-1990s 1462 to support protection of HTTP traffic. 1464 While older versions of TLS and DTLS are still in use, they provide 1465 weaker security guarantees. [RFC7457] outlines important attacks on 1466 TLS and DTLS. [RFC7525] is a Best Current Practices (BCP) document 1467 that describes secure configurations for TLS and DTLS to counter 1468 these attacks. The recommendations are applicable for the vast 1469 majority of use cases. 1471 3.11.1. Protocol Description 1473 Both TLS and DTLS provide the same security features and can thus be 1474 discussed together. The features they provide are: 1476 o Confidentiality 1478 o Data integrity 1480 o Peer authentication (optional) 1481 o Perfect forward secrecy (optional) 1483 The authentication of the peer entity can be omitted; a common web 1484 use case is where the server is authenticated and the client is not. 1485 TLS also provides a completely anonymous operation mode in which 1486 neither peer's identity is authenticated. It is important to note 1487 that TLS itself does not specify how a peering entity's identity 1488 should be interpreted. For example, in the common use case of 1489 authentication by means of an X.509 certificate, it is the 1490 application's decision whether the certificate of the peering entity 1491 is acceptable for authorization decisions. 1493 Perfect forward secrecy, if enabled and supported by the selected 1494 algorithms, ensures that traffic encrypted and captured during a 1495 session at time t0 cannot be later decrypted at time t1 (t1 > t0), 1496 even if the long-term secrets of the communicating peers are later 1497 compromised. 1499 As DTLS is generally used over an unreliable datagram transport such 1500 as UDP, applications will need to tolerate lost, re-ordered, or 1501 duplicated datagrams. Like TLS, DTLS conveys application data in a 1502 sequence of independent records. However, because records are mapped 1503 to unreliable datagrams, there are several features unique to DTLS 1504 that are not applicable to TLS: 1506 o Record replay detection (optional). 1508 o Record size negotiation (estimates of PMTU and record size 1509 expansion factor). 1511 o Coveyance of IP don't fragment (DF) bit settings by application. 1513 o An anti-DoS stateless cookie mechanism (optional). 1515 Generally, DTLS follows the TLS design as closely as possible. To 1516 operate over datagrams, DTLS includes a sequence number and limited 1517 forms of retransmission and fragmentation for its internal 1518 operations. The sequence number may be used for detecting replayed 1519 information, according to the windowing procedure described in 1520 Section 4.1.2.6 of [RFC6347]. DTLS forbids the use of stream 1521 ciphers, which are essentially incompatible when operating on 1522 independent encrypted records. 1524 3.11.2. Interface Description 1526 TLS is commonly invoked using an API provided by packages such as 1527 OpenSSL, wolfSSL, or GnuTLS. Using such APIs entails the 1528 manipulation of several important abstractions, which fall into the 1529 following categories: long-term keys and algorithms, session state, 1530 and communications/connections. There may also be special APIs 1531 required to deal with time and/or random numbers, both of which are 1532 needed by a variety of encryption algorithms and protocols. 1534 Considerable care is required in the use of TLS APIs to ensure 1535 creation of a secure application. The programmer should have at 1536 least a basic understanding of encryption and digital signature 1537 algorithms and their strengths, public key infrastructure (including 1538 X.509 certificates and certificate revocation), and the sockets API. 1539 See [RFC7525] and [RFC7457], as mentioned above. 1541 As an example, in the case of OpenSSL, the primary abstractions are 1542 the library itself and method (protocol), session, context, cipher 1543 and connection. After initializing the library and setting the 1544 method, a cipher suite is chosen and used to configure a context 1545 object. Session objects may then be minted according to the 1546 parameters present in a context object and associated with individual 1547 connections. Depending on how precisely the programmer wishes to 1548 select different algorithmic or protocol options, various levels of 1549 details may be required. 1551 3.11.3. Transport Features 1553 Both TLS and DTLS employ a layered architecture. The lower layer is 1554 commonly called the record protocol. It is responsible for: 1556 o message fragmentation, 1558 o authentication and integrity via message authentication codes 1559 (MAC), 1561 o data encryption, 1563 o scheduling transmission using the underlying transport protocol. 1565 DTLS augments the TLS record protocol with: 1567 o ordering and replay protection, implemented using sequence 1568 numbers. 1570 Several protocols are layered on top of the record protocol. These 1571 include the handshake, alert, and change cipher spec protocols. 1572 There is also the data protocol, used to carry application traffic. 1573 The handshake protocol is used to establish cryptographic and 1574 compression parameters when a connection is first set up. In DTLS, 1575 this protocol also has a basic fragmentation and retransmission 1576 capability and a cookie-like mechanism to resist DoS attacks. (TLS 1577 compression is not recommended at present). The alert protocol is 1578 used to inform the peer of various conditions, most of which are 1579 terminal for the connection. The change cipher spec protocol is used 1580 to synchronize changes in cryptographic parameters for each peer. 1582 The data protocol, when used with an appropriate cipher, provides: 1584 o authentication of one end or both ends of a connection, 1586 o confidentiality, 1588 o cryptographic integrity protection. 1590 Both TLS and DTLS are unicast-only. 1592 3.12. Hypertext Transport Protocol (HTTP) over TCP as a pseudotransport 1594 The Hypertext Transfer Protocol (HTTP) is an application-level 1595 protocol widely used on the Internet. It provides object-oriented 1596 delivery of discrete data or files. Version 1.1 of the protocol is 1597 specified in [RFC7230] [RFC7231] [RFC7232] [RFC7233] [RFC7234] 1598 [RFC7235], and version 2 in [RFC7540]. HTTP is usually transported 1599 over TCP using port 80 and 443, although it can be used with other 1600 transports. When used over TCP it inherits its properties. 1602 Application layer protocols may use HTTP as a substrate with an 1603 existing method and data formats, or specify new methods and data 1604 formats. There are various reasons for this practice listed in 1605 [RFC3205]; these include being a well-known and well-understood 1606 protocol, reusability of existing servers and client libraries, easy 1607 use of existing security mechanisms such as HTTP digest 1608 authentication [RFC2617] and TLS [RFC5246], the ability of HTTP to 1609 traverse firewalls makes it work over many types of infrastructure, 1610 and in cases where an application server often needs to support HTTP 1611 anyway. 1613 Depending on application need, the use of HTTP as a substrate 1614 protocol may add complexity and overhead in comparison to a special- 1615 purpose protocol (e.g., HTTP headers, suitability of the HTTP 1616 security model, etc.). [RFC3205] addresses this issue and provides 1617 some guidelines and identifies concerns about the use of HTTP 1618 standard port 80 and 443, the use of HTTP URL scheme and interaction 1619 with existing firewalls, proxies and NATs. 1621 Representational State Transfer (REST) [REST] is another example of 1622 how applications can use HTTP as transport protocol. REST is an 1623 architecture style that may be used to build applications using HTTP 1624 as a communication protocol. 1626 3.12.1. Protocol Description 1628 Hypertext Transfer Protocol (HTTP) is a request/response protocol. A 1629 client sends a request containing a request method, URI and protocol 1630 version followed by a MIME-like message (see [RFC7231] for the 1631 differences between an HTTP object and a MIME message), containing 1632 information about the client and request modifiers. The message can 1633 also contain a message body carrying application data. The server 1634 responds with a status or error code followed by a MIME-like message 1635 containing information about the server and information about the 1636 data. This may include a message body. It is possible to specify a 1637 data format for the message body using MIME media types [RFC2045]. 1638 The protocol has additional features, some relevant to pseudo- 1639 transport are described below. 1641 Content negotiation, specified in [RFC7231], is a mechanism provided 1642 by HTTP to allow selection of a representation for a requested 1643 resource. The client and server negotiate acceptable data formats, 1644 character sets, data encoding (e.g., data can be transferred 1645 compressed using gzip). HTTP can accommodate exchange of messages as 1646 well as data streaming (using chunked transfer encoding [RFC7230]). 1647 It is also possible to request a part of a resource using an object 1648 range request [RFC7233]. The protocol provides powerful cache 1649 control signaling defined in [RFC7234]. 1651 The persistent connections of HTTP 1.1 and HTTP 2.0 allow multiple 1652 request- response transactions (streams) during the life-time of a 1653 single HTTP connection. HTTP 2.0 connections can multiplex many 1654 request/response pairs in parallel on a single transport connection. 1655 This reduces overhead during connection establishment and mitigates 1656 transport layer slow-start that would have otherwise been incurred 1657 for each transaction. Both are important to reduce latency for 1658 HTTP's primary use case. 1660 HTTP can be combined with security mechanisms, such as TLS (denoted 1661 by HTTPS). This adds protocol properties provided by such a 1662 mechanism (e.g., authentication, encryption). The TLS Application- 1663 Layer Protocol Negotiation (ALPN) extension [RFC7301] can be used to 1664 negotiate the HTTP version within the TLS handshake, eliminating the 1665 latency incurred by additional round-trip exchanges. Arbitrary 1666 cookie strings, included as part of the MIME headers, are often used 1667 as bearer tokens in HTTP. 1669 3.12.2. Interface Description 1671 There are many HTTP libraries available exposing different APIs. The 1672 APIs provide a way to specify a request by providing a URI, a method, 1673 request modifiers and optionally a request body. For the response, 1674 callbacks can be registered that will be invoked when the response is 1675 received. If TLS is used, the API exposes a registration of 1676 callbacks for a server that requests client authentication and when 1677 certificate verification is needed. 1679 The World Wide Web Consortium (W3C) has standardized the 1680 XMLHttpRequest API [XHR]. This API can be used for sending HTTP/ 1681 HTTPS requests and receiving server responses. Besides the XML data 1682 format, the request and response data format can also be JSON, HTML, 1683 and plain text. JavaScript and XMLHttpRequest are ubiquitous 1684 programming models for websites, and more general applications, where 1685 native code is less attractive. 1687 3.12.3. Transport features 1689 The transport features provided by HTTP, when used as a pseudo- 1690 transport, are: 1692 o unicast transport (provided by the lower layer protocol, usually 1693 TCP), 1695 o uni- or bidirectional communication, 1697 o transfer of objects in multiple streams with object content type 1698 negotiation, supporting partial transmission of object ranges, 1700 o ordered delivery (provided by the lower layer protocol, usually 1701 TCP), 1703 o fully reliable delivery (provided by the lower layer protocol, 1704 usually TCP), 1706 o flow control (provided by the lower layer protocol, usually TCP). 1708 o congestion control (provided by the lower layer protocol, usually 1709 TCP). 1711 HTTPS (HTTP over TLS) additionally provides the following features 1712 (as provided by TLS): 1714 o authentication (of one or both ends of a connection), 1716 o confidentiality, 1718 o integrity protection. 1720 4. Congestion Control 1722 Congestion control is critical to the stable operation of the 1723 Internet. A variety of mechanisms are used to provide the congestion 1724 control needed by many Internet transport protocols. Congestion is 1725 detected based on sensing of network conditions, whether through 1726 explicit or implicit feedback. The congestion control mechanisms 1727 that can be applied by different transport protocols are largely 1728 orthogonal to the choice of transport protocol. This section 1729 provides an overview of the congestion control mechanisms available 1730 to the protocols described in Section 3. 1732 Many protocols use a separate window to determine the maximum sending 1733 rate that is allowed by the congestion control. The used congestion 1734 control mechanism will increase the congestion window if feedback is 1735 received that indicates that the currently used network path is not 1736 congested, and will reduce the window otherwise. Window-based 1737 mechanisms often increase their window slowing over multiple RTTs, 1738 while decreasing strongly when the first indication of congestion is 1739 received. One example are Additive Increase Multiplicative Decrease 1740 (AIMD) schemes, where the window is increased by a certain number of 1741 packets/bytes for each data segment that has been successfully 1742 transmitted, while the window is multiplicatively decrease on the 1743 occurrence of a congestion event. This can lead to a rather 1744 unstable, oscillating sending rate, but will resolve a congestion 1745 situation quickly. TCP New Reno [RFC5681] which is one of the 1746 initial proposed schemes for TCP as well as TCP Cubic 1747 [I-D.ietf-tcpm-cubic] which is the default mechanism for TCP in Linux 1748 are two examples for window-based AIMD schemes. This approach is 1749 also used by DCCP CCID-2 for datagram congestion control. 1751 Some classes of applications prefer to use a transport service that 1752 allows sending at a more stable rate, that is slowly varied in 1753 response to congestion. Rate-based methods offer this type of 1754 congestion control and have been defined based on the loss ratio and 1755 observed round trip time, such as TFRC [RFC5348] and TFRC-SP 1756 [RFC4828]. These methods utilize a throughput equation to determine 1757 the maximum acceptable rate. Such methods are used with DCCP CCID-3 1758 [RFC4342] and CCID-4 [RFC5622], WEBRC [RFC3738], and other 1759 applications. 1761 Another class of applications prefer a transport service that yields 1762 to other (higher-priority) traffic, such as interactive 1763 transmissions. While most traffic in the Internet uses loss-based 1764 congestion control and therefore need to fill the network buffers (to 1765 a certain level if Active Queue Management (AQM) is used), low- 1766 priority congestion control methods often react to changes in delay 1767 as an earlier indication of congestion. This approach tends to 1768 induce less loss than a loss-based method but does generally not 1769 compete well with loss-based traffic across shared bottleneck links. 1770 Therefore, methods such as LEDBAT [RFC6824], are deployed in the 1771 Internet for scavenger traffic that aim to only utilize otherwise 1772 unused capacity. 1774 5. Transport Features 1776 The tables below summarize some key features to illustrate the range 1777 of functions provided across the IETF-specified transports. Figure 1 1778 considers transports that may be directly layered over the network, 1779 and Figure 2 considers transports layered over another transport 1780 service. Features that are permitted, but not required, are marked 1781 as "Poss" indicating that it is possible for the transport service to 1782 offer this feature. 1784 +---------------+------+------+------+------+------+------+------+ 1785 | Feature | TCP | MPTCP| SCTP | UDP | UDP-L|DCCP |ICMP | 1786 +---------------+------+------+------+------+------+------+------+ 1787 | Datagram | No | No | Yes | Yes | Yes | Yes | Yes | 1788 +---------------+------+------+------+------+------+------+------+ 1789 | Conn. Oriented| Yes | Yes | Yes | No | No | Yes | No | 1790 +---------------+------+------+------+------+------+------+------+ 1791 | Reliability | Yes | Yes | Yes | No | No | No | No | 1792 +---------------+------+------+------+------+------+------+------+ 1793 | Partial Rel. | No | No | Poss | N/A | N/A | Yes | N/A | 1794 +---------------+------+------+------+------+------+------+------+ 1795 | Corupt. Tol | No | No | No | No | Yes | Yes | No | 1796 +---------------+------+------+------+------+------+------+------+ 1797 | Cong.Control | Yes | Yes | Yes | No | No | Yes | No | 1798 +---------------+------+------+------+------+------+------+------+ 1799 | Endpoint | 1 | >=1 | >=1 | 1 | 1 | 1 | 1 | 1800 +---------------+------+------+------+------+------+------+------+ 1801 | Multicast Cap.| No | No | No | Yes | Yes | No | No | 1802 +---------------+------+------+------+------+------+------+------+ 1804 Figure 1: Summary comparison: Transport protocols 1806 +---------------+------+------+------+------+------+ 1807 | Feature | RTP | FLUTE| NORM |(D)TLS| HTTP | 1808 +---------------+------+------+------+------+------+ 1809 | Datagram | Yes | No | Both | Both | No | 1810 +---------------+------+------+------+------+------+ 1811 | Conn. Oriented| No | Yes | Yes | Yes | Yes | 1812 +---------------+------+------+------+------+------+ 1813 | Reliability | No | Yes | Poss | Poss | Yes | 1814 +---------------+------+------+------+------+------+ 1815 | Partial R | Poss | No | Poss | No | No | 1816 +---------------+------+------+------+------+------+ 1817 | Corupt. Tol | Poss | No | No | No | No | 1818 +---------------+------+------+------+------+------+ 1819 | Cong.Control | Poss | Poss | Poss | N/A | N/A | 1820 +---------------+------+------+------+------+------+ 1821 | Endpoint | >=1 | >=1 | >=1 | 1 | 1 | 1822 +---------------+------+------+------+------+------+ 1823 | Multicast Cap.| Yes | Yes | Yes | No | No | 1824 +---------------+------+------+------+------+------+ 1826 Figure 2: Upper layer transports and frameworks 1828 The transport protocol features described in this document could be 1829 used as a basis for defining common transport features: 1831 o Control Functions 1833 * Addressing 1835 + unicast (TCP, MPTCP, SCTP, UDP, UDP-Lite, DCCP, ICMP, RTP, 1836 TLS, HTTP) 1838 + multicast (UDP, UDP-Lite, DCCP, ICMP, RTP, FLUTE/ALC, NORM). 1839 Note that, as TLS and DTLS are unicast-only, there is no 1840 widely deployed mechanism for supporting the features in the 1841 Security section below when using multicast addressing. 1843 + IPv4 broadcast (UDP, UDP-Lite, ICMP) 1845 + anycast (UDP, UDP-Lite). Connection-oriented protocols such 1846 as TCP and DCCP have also been deployed using anycast 1847 addressing, with the risk that routing changes may cause 1848 connection failure. 1850 * Association type 1851 + connection-oriented (TCP, MPTCP, SCTP, DCCP, RTP, NORM, TLS, 1852 HTTP) 1854 + connectionless (UDP, UDP-Lite, FLUTE/ALC) 1856 * Multihoming support 1858 + resilience and mobility (MPTCP, SCTP) 1860 + load-balancing (MPTCP) 1862 + address family multiplexing (MPTCP, SCTP) 1864 * Middlebox cooperation 1866 + application-class signaling to middleboxes (DCCP) 1868 + error condition signaling from middleboxes and routers to 1869 endpoints (ICMP) 1871 * Signaling 1873 + control information and error signaling (ICMP) 1875 + performance metric reporting (RTP) 1877 o Delivery 1879 * Reliability 1881 + fully reliable delivery (TCP, MPTCP, SCTP, FLUTE/ALC, NORM, 1882 TLS, HTTP) 1884 + partially reliable delivery (SCTP, NORM) 1886 - using packet erasure coding (FLUTE/ALC, NORM, RTP) 1888 - with specified policy for dropped messages (SCTP) 1890 + unreliable delivery (SCTP, UDP, UDP-Lite, DCCP, RTP) 1892 - with drop notification to sender (RTP, SCTP, DCCP) 1894 + error detection 1896 - checksum for error detection (TCP, MPTCP, SCTP, UDP, UDP- 1897 Lite, DCCP, ICMP, FLUTE/ALC, NORM, TLS, DTLS) 1899 - partial payload checksum protection (UDP-Lite, DCCP). 1900 Some uses of RTP can exploit partial payload checksum 1901 protection feature to provide a corruption tolerant 1902 transport service. 1904 - checksum optional (UDP). Possible with IPv4 and in 1905 certain cases with IPv6. 1907 * Ordering 1909 + ordered delivery (TCP, MPTCP, SCTP, RTP, FLUTE, TLS, HTTP) 1911 + unordered delivery permitted (SCTP, UDP, UDP-Lite, DCCP, 1912 RTP, NORM) 1914 * Type/framing 1916 + stream-oriented delivery (TCP, MPTCP, SCTP, TLS, HTTP) 1918 - with multiple streams per association (SCTP, HTTP2) 1920 + message-oriented delivery (SCTP, UDP, UDP-Lite, DCCP, RTP, 1921 DTLS) 1923 + object-oriented delivery of discrete data or files and 1924 associated metadata (FLUTE/ALC, NORM, HTTP) 1926 - with partial delivery of object ranges (HTTP) 1928 * Directionality 1930 + unidirectional (TCP, SCTP, UDP, UDP-Lite DCCP, RTP, FLUTE/ 1931 ALC, NORM) 1933 + bidirectional (TCP, MPTCP, SCTP, HTTP, TLS) 1935 o Transmission control 1937 * flow control (TCP, MPTCP, SCTP, DCCP, RTP, TLS, HTTP) 1939 * congestion control (TCP, MPTCP, SCTP, DCCP, RTP, FLUTE/ALC, 1940 NORM). Congestion control can also provided by the transport 1941 supporting an upper later transport (e.g., RTP,HTTP, TLS). 1943 * segmentation (TCP, MPTCP, SCTP, RTP, FLUTE/ALC, NORM, TLS, 1944 HTTP) 1946 * data/message bundling (TCP, MPTCP, SCTP, TLS, HTTP) 1947 * stream scheduling prioritization (SCTP, HTTP2) 1949 * endpoint multiplexing (MPTCP) 1951 o Security 1953 * authentication of one end of a connection (FLUTE/ALC, TLS, 1954 DTLS) 1956 * authentication of both ends of a connection (TLS, DTLS) 1958 * confidentiality (TLS, DTLS) 1960 * cryptographic integrity protection (TLS, DTLS) 1962 * replay protection (FLUTE/ALC, DTLS) 1964 6. IANA Considerations 1966 This document has no considerations for IANA. 1968 7. Security Considerations 1970 This document surveys existing transport protocols and protocols 1971 providing transport-like services. Confidentiality, integrity, and 1972 authenticity are among the features provided by those services. This 1973 document does not specify any new features or mechanisms for 1974 providing these features. Each RFC referenced by this document 1975 discusses the security considerations of the specification it 1976 contains. 1978 8. Contributors 1980 In addition to the editors, this document is the work of Brian 1981 Adamson, Dragana Damjanovic, Kevin Fall, Simone Ferlin-Oliviera, 1982 Ralph Holz, Olivier Mehani, Karen Nielsen, Colin Perkins, Vincent 1983 Roca, and Michael Tuexen. 1985 o Section 3.2 on MPTCP was contributed by Simone Ferlin-Oliviera 1986 (ferlin@simula.no) and Olivier Mehani 1987 (olivier.mehani@nicta.com.au) 1989 o Section 3.4 on UDP was contributed by Kevin Fall (kfall@kfall.com) 1991 o Section 3.3 on SCTP was contributed by Michael Tuexen (tuexen@fh- 1992 muenster.de) and Karen Nielsen (karen.nielsen@tieto.com) 1994 o Section 3.8 on RTP contains contributions from Colin Perkins 1995 (csp@csperkins.org) 1997 o Section 3.9 on FLUTE/ALC was contributed by Vincent Roca 1998 (vincent.roca@inria.fr) 2000 o Section 3.10 on NORM was contributed by Brian Adamson 2001 (brian.adamson@nrl.navy.mil) 2003 o Section 3.11 on TLS and DTLS was contributed by Ralph Holz 2004 (ralph.holz@nicta.com.au) and Olivier Mehani 2005 (olivier.mehani@nicta.com.au) 2007 o Section 3.12 on HTTP was contributed by Dragana Damjanovic 2008 (ddamjanovic@mozilla.com) 2010 9. Acknowledgments 2012 Thanks to Joe Touch, Michael Welzl, and the TAPS Working Group for 2013 the comments, feedback, and discussion. This work is supported by 2014 the European Commission under grant agreement No. 318627 mPlane and 2015 from the Horizon 2020 research and innovation program under grant 2016 agreements No. 644334 (NEAT) and No. 688421 (MAMI). This support 2017 does not imply endorsement. 2019 10. Informative References 2021 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2022 DOI 10.17487/RFC0768, August 1980, 2023 . 2025 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2026 RFC 792, DOI 10.17487/RFC0792, September 1981, 2027 . 2029 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2030 RFC 793, DOI 10.17487/RFC0793, September 1981, 2031 . 2033 [RFC0896] Nagle, J., "Congestion Control in IP/TCP Internetworks", 2034 RFC 896, DOI 10.17487/RFC0896, January 1984, 2035 . 2037 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2038 Communication Layers", STD 3, RFC 1122, 2039 DOI 10.17487/RFC1122, October 1989, 2040 . 2042 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2043 DOI 10.17487/RFC1191, November 1990, 2044 . 2046 [RFC1716] Almquist, P. and F. Kastenholz, "Towards Requirements for 2047 IP Routers", RFC 1716, DOI 10.17487/RFC1716, November 2048 1994, . 2050 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 2051 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 2052 1996, . 2054 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 2055 Selective Acknowledgment Options", RFC 2018, 2056 DOI 10.17487/RFC2018, October 1996, 2057 . 2059 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2060 Extensions (MIME) Part One: Format of Internet Message 2061 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 2062 . 2064 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2065 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2066 December 1998, . 2068 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 2069 Discovery for IP Version 6 (IPv6)", RFC 2461, 2070 DOI 10.17487/RFC2461, December 1998, 2071 . 2073 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 2074 Leach, P., Luotonen, A., and L. Stewart, "HTTP 2075 Authentication: Basic and Digest Access Authentication", 2076 RFC 2617, DOI 10.17487/RFC2617, June 1999, 2077 . 2079 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 2080 Listener Discovery (MLD) for IPv6", RFC 2710, 2081 DOI 10.17487/RFC2710, October 1999, 2082 . 2084 [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP 2085 Payload Format Specifications", BCP 36, RFC 2736, 2086 DOI 10.17487/RFC2736, December 1999, 2087 . 2089 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2090 of Explicit Congestion Notification (ECN) to IP", 2091 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2092 . 2094 [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, 2095 RFC 3205, DOI 10.17487/RFC3205, February 2002, 2096 . 2098 [RFC3260] Grossman, D., "New Terminology and Clarifications for 2099 Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, 2100 . 2102 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 2103 Layer Security over Stream Control Transmission Protocol", 2104 RFC 3436, DOI 10.17487/RFC3436, December 2002, 2105 . 2107 [RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. 2108 Crowcroft, "Asynchronous Layered Coding (ALC) Protocol 2109 Instantiation", RFC 3450, DOI 10.17487/RFC3450, December 2110 2002, . 2112 [RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 2113 M., and J. Crowcroft, "Forward Error Correction (FEC) 2114 Building Block", RFC 3452, DOI 10.17487/RFC3452, December 2115 2002, . 2117 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2118 Jacobson, "RTP: A Transport Protocol for Real-Time 2119 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2120 July 2003, . 2122 [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate 2123 Control (WEBRC) Building Block", RFC 3738, 2124 DOI 10.17487/RFC3738, April 2004, 2125 . 2127 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 2128 Conrad, "Stream Control Transmission Protocol (SCTP) 2129 Partial Reliability Extension", RFC 3758, 2130 DOI 10.17487/RFC3758, May 2004, 2131 . 2133 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., 2134 and G. Fairhurst, Ed., "The Lightweight User Datagram 2135 Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 2136 2004, . 2138 [RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, 2139 "FLUTE - File Delivery over Unidirectional Transport", 2140 RFC 3926, DOI 10.17487/RFC3926, October 2004, 2141 . 2143 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2144 "SEcure Neighbor Discovery (SEND)", RFC 3971, 2145 DOI 10.17487/RFC3971, March 2005, 2146 . 2148 [RFC4324] Royer, D., Babics, G., and S. Mansour, "Calendar Access 2149 Protocol (CAP)", RFC 4324, DOI 10.17487/RFC4324, December 2150 2005, . 2152 [RFC4336] Floyd, S., Handley, M., and E. Kohler, "Problem Statement 2153 for the Datagram Congestion Control Protocol (DCCP)", 2154 RFC 4336, DOI 10.17487/RFC4336, March 2006, 2155 . 2157 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2158 Congestion Control Protocol (DCCP)", RFC 4340, 2159 DOI 10.17487/RFC4340, March 2006, 2160 . 2162 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 2163 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 2164 Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 2165 2006, . 2167 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 2168 Datagram Congestion Control Protocol (DCCP) Congestion 2169 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 2170 DOI 10.17487/RFC4342, March 2006, 2171 . 2173 [RFC4433] Kulkarni, M., Patel, A., and K. Leung, "Mobile IPv4 2174 Dynamic Home Agent (HA) Assignment", RFC 4433, 2175 DOI 10.17487/RFC4433, March 2006, 2176 . 2178 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast 2179 Congestion Control (TFMCC): Protocol Specification", 2180 RFC 4654, DOI 10.17487/RFC4654, August 2006, 2181 . 2183 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 2184 Parameter for the Stream Control Transmission Protocol 2185 (SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007, 2186 . 2188 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2189 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 2190 . 2192 [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control 2193 (TFRC): The Small-Packet (SP) Variant", RFC 4828, 2194 DOI 10.17487/RFC4828, April 2007, 2195 . 2197 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 2198 "Authenticated Chunks for the Stream Control Transmission 2199 Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 2200 2007, . 2202 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2203 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2204 . 2206 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 2207 Kozuka, "Stream Control Transmission Protocol (SCTP) 2208 Dynamic Address Reconfiguration", RFC 5061, 2209 DOI 10.17487/RFC5061, September 2007, 2210 . 2212 [RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite 2213 protocol", RFC 5097, DOI 10.17487/RFC5097, January 2008, 2214 . 2216 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2217 (TLS) Protocol Version 1.2", RFC 5246, 2218 DOI 10.17487/RFC5246, August 2008, 2219 . 2221 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 2222 the Datagram Congestion Control Protocol (DCCP)", 2223 RFC 5238, DOI 10.17487/RFC5238, May 2008, 2224 . 2226 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 2227 Friendly Rate Control (TFRC): Protocol Specification", 2228 RFC 5348, DOI 10.17487/RFC5348, September 2008, 2229 . 2231 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 2232 DOI 10.17487/RFC5461, February 2009, 2233 . 2235 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 2236 (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, 2237 September 2009, . 2239 [RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol 2240 (DCCP) Simultaneous-Open Technique to Facilitate NAT/ 2241 Middlebox Traversal", RFC 5596, DOI 10.17487/RFC5596, 2242 September 2009, . 2244 [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 2245 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate 2246 Control for Small Packets (TFRC-SP)", RFC 5622, 2247 DOI 10.17487/RFC5622, August 2009, 2248 . 2250 [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding 2251 Transport (LCT) Building Block", RFC 5651, 2252 DOI 10.17487/RFC5651, October 2009, 2253 . 2255 [RFC5672] Crocker, D., Ed., "RFC 4871 DomainKeys Identified Mail 2256 (DKIM) Signatures -- Update", RFC 5672, 2257 DOI 10.17487/RFC5672, August 2009, 2258 . 2260 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 2261 "NACK-Oriented Reliable Multicast (NORM) Transport 2262 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 2263 . 2265 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 2266 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 2267 DOI 10.17487/RFC5775, April 2010, 2268 . 2270 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 2271 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 2272 . 2274 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 2275 Protocol Port Randomization", BCP 156, RFC 6056, 2276 DOI 10.17487/RFC6056, January 2011, 2277 . 2279 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 2280 Transport Layer Security (DTLS) for Stream Control 2281 Transmission Protocol (SCTP)", RFC 6083, 2282 DOI 10.17487/RFC6083, January 2011, 2283 . 2285 [RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the 2286 TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, 2287 January 2011, . 2289 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 2290 Transmission Protocol (SCTP) Stream Reconfiguration", 2291 RFC 6525, DOI 10.17487/RFC6525, February 2012, 2292 . 2294 [RFC6546] Trammell, B., "Transport of Real-time Inter-network 2295 Defense (RID) Messages over HTTP/TLS", RFC 6546, 2296 DOI 10.17487/RFC6546, April 2012, 2297 . 2299 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2300 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2301 January 2012, . 2303 [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled 2304 Congestion Control for Multipath Transport Protocols", 2305 RFC 6356, DOI 10.17487/RFC6356, October 2011, 2306 . 2308 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 2309 Correction (FEC) Framework", RFC 6363, 2310 DOI 10.17487/RFC6363, October 2011, 2311 . 2313 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 2314 Yasevich, "Sockets API Extensions for the Stream Control 2315 Transmission Protocol (SCTP)", RFC 6458, 2316 DOI 10.17487/RFC6458, December 2011, 2317 . 2319 [RFC6584] Roca, V., "Simple Authentication Schemes for the 2320 Asynchronous Layered Coding (ALC) and NACK-Oriented 2321 Reliable Multicast (NORM) Protocols", RFC 6584, 2322 DOI 10.17487/RFC6584, April 2012, 2323 . 2325 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 2326 "FLUTE - File Delivery over Unidirectional Transport", 2327 RFC 6726, DOI 10.17487/RFC6726, November 2012, 2328 . 2330 [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A 2331 Datagram Congestion Control Protocol UDP Encapsulation for 2332 NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November 2333 2012, . 2335 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 2336 "TCP Extensions for Multipath Operation with Multiple 2337 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 2338 . 2340 [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application 2341 Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, 2342 March 2013, . 2344 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 2345 UDP Checksums for Tunneled Packets", RFC 6935, 2346 DOI 10.17487/RFC6935, April 2013, 2347 . 2349 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 2350 for the Use of IPv6 UDP Datagrams with Zero Checksums", 2351 RFC 6936, DOI 10.17487/RFC6936, April 2013, 2352 . 2354 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 2355 Control Transmission Protocol (SCTP) Packets for End-Host 2356 to End-Host Communication", RFC 6951, 2357 DOI 10.17487/RFC6951, May 2013, 2358 . 2360 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 2361 IMMEDIATELY Extension for the Stream Control Transmission 2362 Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, 2363 . 2365 [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP 2366 Framework: Why RTP Does Not Mandate a Single Media 2367 Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2368 2014, . 2370 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2371 Protocol (HTTP/1.1): Message Syntax and Routing", 2372 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2373 . 2375 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2376 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2377 DOI 10.17487/RFC7231, June 2014, 2378 . 2380 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2381 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 2382 DOI 10.17487/RFC7232, June 2014, 2383 . 2385 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 2386 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 2387 RFC 7233, DOI 10.17487/RFC7233, June 2014, 2388 . 2390 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 2391 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 2392 RFC 7234, DOI 10.17487/RFC7234, June 2014, 2393 . 2395 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2396 Protocol (HTTP/1.1): Authentication", RFC 7235, 2397 DOI 10.17487/RFC7235, June 2014, 2398 . 2400 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 2401 "Transport Layer Security (TLS) Application-Layer Protocol 2402 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 2403 July 2014, . 2405 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 2406 Scheffenegger, Ed., "TCP Extensions for High Performance", 2407 RFC 7323, DOI 10.17487/RFC7323, September 2014, 2408 . 2410 [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. 2411 Zimmermann, "A Roadmap for Transmission Control Protocol 2412 (TCP) Specification Documents", RFC 7414, 2413 DOI 10.17487/RFC7414, February 2015, 2414 . 2416 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 2417 Known Attacks on Transport Layer Security (TLS) and 2418 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 2419 February 2015, . 2421 [RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, 2422 "Additional Policies for the Partially Reliable Stream 2423 Control Transmission Protocol Extension", RFC 7496, 2424 DOI 10.17487/RFC7496, April 2015, 2425 . 2427 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2428 "Recommendations for Secure Use of Transport Layer 2429 Security (TLS) and Datagram Transport Layer Security 2430 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2431 2015, . 2433 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 2434 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 2435 DOI 10.17487/RFC7540, May 2015, 2436 . 2438 [I-D.ietf-aqm-ecn-benefits] 2439 Fairhurst, G. and M. Welzl, "The Benefits of using 2440 Explicit Congestion Notification (ECN)", draft-ietf-aqm- 2441 ecn-benefits-08 (work in progress), November 2015. 2443 [I-D.ietf-tsvwg-rfc5405bis] 2444 Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2445 Guidelines", draft-ietf-tsvwg-rfc5405bis-07 (work in 2446 progress), November 2015. 2448 [I-D.ietf-tsvwg-sctp-dtls-encaps] 2449 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 2450 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 2451 dtls-encaps-09 (work in progress), January 2015. 2453 [I-D.ietf-tsvwg-sctp-ndata] 2454 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 2455 "Stream Schedulers and User Message Interleaving for the 2456 Stream Control Transmission Protocol", draft-ietf-tsvwg- 2457 sctp-ndata-04 (work in progress), July 2015. 2459 [I-D.ietf-tsvwg-sctp-failover] 2460 Nishida, Y., Natarajan, P., Caro, A., Amer, P., and K. 2461 Nielsen, "SCTP-PF: Quick Failover Algorithm in SCTP", 2462 draft-ietf-tsvwg-sctp-failover-14 (work in progress), 2463 December 2015. 2465 [I-D.ietf-tsvwg-natsupp] 2466 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 2467 Transmission Protocol (SCTP) Network Address Translation 2468 Support", draft-ietf-tsvwg-natsupp-08 (work in progress), 2469 July 2015. 2471 [I-D.ietf-tcpm-cubic] 2472 Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and 2473 R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", 2474 draft-ietf-tcpm-cubic-00 (work in progress), June 2015. 2476 [XHR] van Kesteren, A., Aubourg, J., Song, J., and H. Steen, 2477 "XMLHttpRequest working draft 2478 (http://www.w3.org/TR/XMLHttpRequest/)", 2000. 2480 [REST] Fielding, R., "Architectural Styles and the Design of 2481 Network-based Software Architectures, Ph. D. (UC Irvine), 2482 Chapter 5: Representational State Transfer", 2000. 2484 [POSIX] 1-2008, IEEE., "IEEE Standard for Information Technology 2485 -- Portable Operating System Interface (POSIX) Base 2486 Specifications, Issue 7", n.d.. 2488 [MBMS] 3GPP TSG WS S4, ., "3GPP TS 26.346: Multimedia Broadcast/ 2489 Multicast Service (MBMS); Protocols and codecs, release 13 2490 (http://www.3gpp.org/DynaReport/26346.htm).", 2015. 2492 [ClarkArch] 2493 Clark, D. and D. Tennenhouse, "Architectural 2494 Considerations for a New Generation of Protocols (Proc. 2495 ACM SIGCOMM)", 1990. 2497 Authors' Addresses 2499 Godred Fairhurst (editor) 2500 University of Aberdeen 2501 School of Engineering, Fraser Noble Building 2502 Aberdeen AB24 3UE 2504 Email: gorry@erg.abdn.ac.uk 2505 Brian Trammell (editor) 2506 ETH Zurich 2507 Gloriastrasse 35 2508 8092 Zurich 2509 Switzerland 2511 Email: ietf@trammell.ch 2513 Mirja Kuehlewind (editor) 2514 ETH Zurich 2515 Gloriastrasse 35 2516 8092 Zurich 2517 Switzerland 2519 Email: mirja.kuehlewind@tik.ee.ethz.ch