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