idnits 2.17.1 draft-ietf-taps-transports-13.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 05, 2016) is 2699 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 8, 2017 M. Kuehlewind, Ed. 6 ETH Zurich 7 December 05, 2016 9 Services provided by IETF transport protocols and congestion control 10 mechanisms 11 draft-ietf-taps-transports-13 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 8, 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 RESET control message may be used to close a TCP session [RFC0793]. 336 A mandatory checksum provides a basic integrity check against 337 misdelivery and data corruption over the entire packet. Applications 338 that require end to end integrity of data are recommended to include 339 a stronger integrity check of their payload data. The TCP checksum 340 [RFC1071] [RFC2460] does not support partial payload protection (as 341 in DCCP/UDP-Lite). 343 TCP supports only unicast connections. 345 3.1.2. Interface description 347 A User/TCP Interface is defined in [RFC0793] providing six user 348 commands: Open, Send, Receive, Close, Status. This interface does 349 not describe configuration of TCP options or parameters beside use of 350 the PUSH and URGENT flags. 352 [RFC1122] describes extensions of the TCP/application layer interface 353 for: 355 o reporting soft errors such as reception of ICMP error messages, 356 extensive retransmission or urgent pointer advance, 358 o providing a possibility to specify the Differentiated Services 359 Code Point (DSCP) [RFC3260] (formerly, the Type-of-Service, TOS) 360 for segments, 362 o providing a flush call to empty the TCP send queue, and 364 o multihoming support. 366 In API implementations derived from the BSD Sockets API, TCP sockets 367 are created using the "SOCK_STREAM" socket type as described in the 368 IEEE Portable Operating System Interface (POSIX) Base Specifications 369 [POSIX]. The features used by a protocol instance may be set and 370 tuned via this API. There are currently no documents in the RFC 371 Series that describe this interface. 373 3.1.3. Transport Features 375 The transport features provided by TCP are: 377 o connection-oriented transport with feature negotiation and 378 application-to-port mapping (implemented using SYN segments and 379 the TCP option field to negotiate features), 381 o unicast transport (though anycast TCP is implemented, at risk of 382 instability due to rerouting), 384 o port multiplexing, 386 o uni- or bidirectional communication, 388 o stream-oriented delivery in a single stream, 390 o fully reliable delivery (implemented using ACKs sent from the 391 receiver to confirm delivery), 393 o error detection (implemented using a segment checksum to verify 394 delivery to the correct endpoint and integrity of the data and 395 options), 397 o segmentation, 399 o data bundling (optional; uses Nagle's algorithm to coalesce data 400 sent within the same RTT into full-sized segments), 402 o flow control (implemented using a window-based mechanism where the 403 receiver advertises the window that it is willing to buffer), 405 o congestion control (usually implemented using a window-based 406 mechanism and four algorithms for different phases of the 407 transmission: slow start, congestion avoidance, fast retransmit, 408 and fast recovery [RFC5681]). 410 3.2. Multipath TCP (MPTCP) 412 Multipath TCP [RFC6824] is an extension for TCP to support multi- 413 homing for resilience, mobility and load-balancing. It is designed 414 to be as indistinguishable to middleboxes from non-multipath TCP as 415 possible. It does so by establishing regular TCP flows between a 416 pair of source/destination endpoints, and multiplexing the 417 application's stream over these flows. Sub- flows can be started 418 over IPv4 or IPv6 for the same session. 420 3.2.1. Protocol Description 422 MPTCP uses TCP options for its control plane. They are used to 423 signal multipath capabilities, as well as to negotiate data sequence 424 numbers, and advertise other available IP addresses and establish new 425 sessions between pairs of endpoints. 427 By multiplexing one byte stream over separate paths, MPTCP can 428 achieve a higher throughput than TCP in certain situations. However, 429 if coupled congestion control [RFC6356] is used, it might limit this 430 benefit to maintain fairness to other flows at the bottleneck. When 431 aggregating capacity over multiple paths, and depending on the way 432 packets are scheduled on each TCP subflow, additional delay and 433 higher jitter might be observed observed before in-order delivery of 434 data to the applications. 436 3.2.2. Interface Description 438 By default, MPTCP exposes the same interface as TCP to the 439 application. [RFC6897] however describes a richer API for MPTCP- 440 aware applications. 442 This Basic API describes how an application can: 444 o enable or disable MPTCP. 446 o bind a socket to one or more selected local endpoints. 448 o query local and remote endpoint addresses. 450 o get a unique connection identifier (similar to an address-port 451 pair for TCP). 453 The document also recommends the use of extensions defined for SCTP 454 [RFC6458] (see next section) to support multihoming for resilience 455 and mobility. 457 3.2.3. Transport features 459 As an extension to TCP, MPTCP provides mostly the same features. By 460 establishing multiple sessions between available endpoints, it can 461 additionally provide soft failover solutions in the case that one of 462 the paths become unusable. 464 The transport features provided by MPTCP in addition to TCP therefore 465 are: 467 o multihoming for load-balancing, with endpoint multiplexing of a 468 single byte stream, using either coupled congestion control or for 469 throughput maximization, 471 o address family multiplexing (using IPv4 and IPv6 for the same 472 session), 474 o resilience to network failure and/or handover. 476 3.3. User Datagram Protocol (UDP) 478 The User Datagram Protocol (UDP) [RFC0768] [RFC2460] is an IETF 479 standards track transport protocol. It provides a unidirectional 480 datagram protocol that preserves message boundaries. It provides no 481 error correction, congestion control, or flow control. It can be 482 used to send broadcast datagrams (IPv4) or multicast datagrams (IPv4 483 and IPv6), in addition to unicast and anycast datagrams. IETF 484 guidance on the use of UDP is provided in 485 [I-D.ietf-tsvwg-rfc5405bis]. UDP is widely implemented and widely 486 used by common applications, including DNS. 488 3.3.1. Protocol Description 490 UDP is a connection-less protocol that maintains message boundaries, 491 with no connection setup or feature negotiation. The protocol uses 492 independent messages, ordinarily called datagrams. It provides 493 detection of payload errors and misdelivery of packets to an 494 unintended endpoint, either of which result in discard of received 495 datagrams, with no indication to the user of the service. 497 It is possible to create IPv4 UDP datagrams with no checksum, and 498 while this is generally discouraged [RFC1122] 499 [I-D.ietf-tsvwg-rfc5405bis], certain special cases permit this use. 500 These datagrams rely on the IPv4 header checksum to protect from 501 misdelivery to an unintended endpoint. IPv6 does not permit UDP 502 datagrams with no checksum, although in certain cases [RFC6936] this 503 rule may be relaxed [RFC6935]. 505 UDP does not provide reliability and does not provide retransmission. 506 Messages may be re-ordered, lost, or duplicated in transit. Note 507 that due to the relatively weak form of checksum used by UDP, 508 applications that require end to end integrity of data are 509 recommended to include a stronger integrity check of their payload 510 data. 512 Because UDP provides no flow control, a receiving application that is 513 unable to run sufficiently fast, or frequently, may miss messages. 514 The lack of congestion handling implies UDP traffic may experience 515 loss when using an overloaded path, and may cause the loss of 516 messages from other protocols (e.g., TCP) when sharing the same 517 network path. 519 On transmission, UDP encapsulates each datagram into a single IP 520 packet or several IP packet fragments. This allows a datagram to be 521 larger than the effective path MTU. Fragments are reassembled before 522 delivery to the UDP receiver, making this transparent to the user of 523 the transport service. When the jumbograms are supported, larger 524 messages may be sent without performing fragmentation. 526 UDP on its own does not provide support for segmentation, receiver 527 flow control, congestion control, PathMTU discovery/PLPMTUD, or ECN. 528 Applications that require these features need to provide them on 529 their own, or by using a protocol over UDP that provides them 530 [I-D.ietf-tsvwg-rfc5405bis]. 532 3.3.2. Interface Description 534 [RFC0768] describes basic requirements for an API for UDP. Guidance 535 on use of common APIs is provided in [I-D.ietf-tsvwg-rfc5405bis]. 537 A UDP endpoint consists of a tuple of (IP address, port number). De- 538 multiplexing using multiple abstract endpoints (sockets) on the same 539 IP address is supported. The same socket may be used by a single 540 server to interact with multiple clients (note: this behavior differs 541 from TCP, which uses a pair of tuples to identify a connection). 542 Multiple server instances (processes) that bind to the same socket 543 can cooperate to service multiple clients. The socket implementation 544 arranges to not duplicate the same received unicast message to 545 multiple server processes. 547 Many operating systems also allow a UDP socket to be "connected", 548 i.e., to bind a UDP socket to a specific (remote) UDP endpoint. 549 Unlike TCP's connect primitive, for UDP, this is only a local 550 operation that serves to simplify the local send/receive functions 551 and to filter the traffic for the specified addresses and ports 552 [I-D.ietf-tsvwg-rfc5405bis]. 554 3.3.3. Transport Features 556 The transport features provided by UDP are: 558 o unicast, multicast, anycast, or IPv4 broadcast transport, 560 o port multiplexing (where a receiving port can be configured to 561 receive datagrams from multiple senders), 563 o message-oriented delivery, 565 o uni- or bidirectional communication where the transmissions in 566 each direction are independent, 568 o non-reliable delivery, 570 o unordered delivery, 571 o error detection (implemented using a segment checksum to verify 572 delivery to the correct endpoint and integrity of the data; 573 optional for IPv4 and optional under specific conditions for IPv6 574 where all or none of the payload data is protected), 576 3.4. Lightweight User Datagram Protocol (UDP-Lite) 578 The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] is an 579 IETF standards track transport protocol. It provides a 580 unidirectional, datagram protocol that preserves message boundaries. 581 IETF guidance on the use of UDP- Lite is provided in 582 [I-D.ietf-tsvwg-rfc5405bis]. A UDP-Lite service may support IPv4 583 broadcast, multicast, anycast and unicast, and IPv6 multicast, 584 anycast and unicast. 586 Examples of use include a class of applications that can derive 587 benefit from having partially-damaged payloads delivered, rather than 588 discarded. One use is to provider header integrity checks but allow 589 delivery of corrupted payloads to error-tolerant applications, or 590 when payload integrity is provided by some other mechanism (see 591 [RFC6936]). 593 3.4.1. Protocol Description 595 Like UDP, UDP-Lite is a connection-less datagram protocol, with no 596 connection setup or feature negotiation. It changes the semantics of 597 the UDP "payload length" field to that of a "checksum coverage 598 length" field, and is identified by a different IP protocol/next- 599 header value. The "checksum coverage length" field specifies the 600 intended checksum coverage, with the remaining unprotected part of 601 the payload called the "error-insensitive part". Applications using 602 UDP-Lite therefore cannot make assumptions regarding the correctness 603 of the data received in the insensitive part of the UDP-Lite payload. 605 Otherwise, UDP-Lite is semantically identical to UDP. In the same 606 way as for UDP, mechanisms for receiver flow control, congestion 607 control, PMTU or PLPMTU discovery, support for ECN, etc. needs to be 608 provided by upper layer protocols [I-D.ietf-tsvwg-rfc5405bis]. 610 3.4.2. Interface Description 612 There is no API currently specified in the RFC Series, but guidance 613 on use of common APIs is provided in [I-D.ietf-tsvwg-rfc5405bis]. 615 The interface of UDP-Lite differs from that of UDP by the addition of 616 a single (socket) option that communicates a checksum coverage length 617 value. The checksum coverage may also be made visible to the 618 application via the UDP-Lite MIB module [RFC5097]. 620 3.4.3. Transport Features 622 The transport features provided by UDP-Lite are: 624 o unicast, multicast, anycast, or IPv4 broadcast transport (as for 625 UDP), 627 o port multiplexing (as for UDP), 629 o message-oriented delivery (as for UDP), 631 o Uni- or bidirectional communication where the transmissions in 632 each direction are independent (as for UDP), 634 o non-reliable delivery (as for UDP), 636 o non-ordered delivery (as for UDP), 638 o partial or full payload error detection (where the checksum 639 coverage field indicates the size of the payload data covered by 640 the checksum). 642 3.5. Stream Control Transmission Protocol (SCTP) 644 SCTP is a message-oriented IETF standards track transport protocol. 645 The base protocol is specified in [RFC4960]. It supports multi- 646 homing and path failover to provide resilience to path failures. An 647 SCTP association has multiple streams in each direction, providing 648 in-sequence delivery of user messages within each stream. This 649 allows it to minimize head of line blocking. SCTP supports multiple 650 stream scheduling schemes controlling stream multiplexing, including 651 priority and fair weighting schemes. 653 SCTP was originally developed for transporting telephony signaling 654 messages and is deployed in telephony signaling networks, especially 655 in mobile telephony networks. It can also be used for other 656 services, for example, in the WebRTC framework for data channels. 658 3.5.1. Protocol Description 660 SCTP is a connection-oriented protocol using a four way handshake to 661 establish an SCTP association, and a three way message exchange to 662 gracefully shut it down. It uses the same port number concept as 663 DCCP, TCP, UDP, and UDP-Lite. SCTP only supports unicast. 665 SCTP uses the 32-bit CRC32c for protecting SCTP packets against bit 666 errors and misdelivery of packets to an unintended endpoint. This is 667 stronger than the 16-bit checksums used by TCP or UDP. However, 668 partial payload checksum coverage as provided by DCCP or UDP-Lite is 669 not supported. 671 SCTP has been designed with extensibility in mind. A common header 672 is followed by a sequence of chunks. [RFC4960] defines how a 673 receiver processes chunks with an unknown chunk type. The support of 674 extensions can be negotiated during the SCTP handshake. Currently 675 defined extensions include mechanisms for dynamic re-configuration of 676 streams [RFC6525] and IP addresses [RFC5061]. Furthermore, the 677 extension specified in [RFC3758] introduces the concept of partial 678 reliability for user messages. 680 SCTP provides a message-oriented service. Multiple small user 681 messages can be bundled into a single SCTP packet to improve 682 efficiency. For example, this bundling may be done by delaying user 683 messages at the sender, similar to Nagle's algorithm used by TCP. 684 User messages which would result in IP packets larger than the MTU 685 will be fragmented at the sender and reassembled at the receiver. 686 There is no protocol limit on the user message size. For MTU 687 discovery the same mechanism than for TCP can be used 688 [RFC1981][RFC4821], as well as utilizing probe packets with padding 689 chunks, as defined in [RFC4820]. 691 [RFC4960] specifies TCP-friendly congestion control to protect the 692 network against overload. SCTP also uses sliding window flow control 693 to protect receivers against overflow. Similar to TCP, SCTP also 694 supports delaying acknowledgments. [RFC7053] provides a way for the 695 sender of user messages to request the immediate sending of the 696 corresponding acknowledgments. 698 Each SCTP association has between 1 and 65536 uni-directional streams 699 in each direction. The number of streams can be different in each 700 direction. Every user message is sent on a particular stream. User 701 messages can be sent un- ordered, or ordered upon request by the 702 upper layer. Un-ordered messages can be delivered as soon as they 703 are completely received. For user messages not requiring 704 fragmentation, this minimizes head of line blocking. On the other 705 hand, ordered messages sent on the same stream are delivered at the 706 receiver in the same order as sent by the sender. 708 The base protocol defined in [RFC4960] does not allow interleaving of 709 user- messages. Large messages on one stream can therefore block the 710 sending of user messages on other streams. 711 [I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation. This draft 712 also specifies multiple algorithms for the sender side selection of 713 which streams to send data from, supporting a variety of scheduling 714 algorithms including priority based methods. The stream re- 715 configuration extension defined in [RFC6525] allows streams to be 716 reset during the lifetime of an association and to increase the 717 number of streams, if the number of streams negotiated in the SCTP 718 handshake becomes insufficient. 720 Each user message sent is either delivered to the receiver or, in 721 case of excessive retransmissions, the association is terminated in a 722 non-graceful way [RFC4960], similar to TCP behavior. In addition to 723 this reliable transfer, the partial reliability extension [RFC3758] 724 allows a sender to abandon user messages. The application can 725 specify the policy for abandoning user messages. 727 SCTP supports multi-homing. Each SCTP endpoint uses a list of IP- 728 addresses and a single port number. These addresses can be any 729 mixture of IPv4 and IPv6 addresses. These addresses are negotiated 730 during the handshake and the address re-configuration extension 731 specified in [RFC5061] in combination with [RFC4895] can be used to 732 change these addresses in an authenticated way during the lifetime of 733 an SCTP association. This allows for transport layer mobility. 734 Multiple addresses are used for improved resilience. If a remote 735 address becomes unreachable, the traffic is switched over to a 736 reachable one, if one exists. 738 For securing user messages, the use of TLS over SCTP has been 739 specified in [RFC3436]. However, this solution does not support all 740 services provided by SCTP, such as un-ordered delivery or partial 741 reliability. Therefore, the use of DTLS over SCTP has been specified 742 in [RFC6083] to overcome these limitations. When using DTLS over 743 SCTP, the application can use almost all services provided by SCTP. 745 [I-D.ietf-tsvwg-natsupp] defines methods for endpoints and 746 middleboxes to provide NAT traversal for SCTP over IPv4. For legacy 747 NAT traversal, [RFC6951] defines the UDP encapsulation of SCTP- 748 packets. Alternatively, SCTP packets can be encapsulated in DTLS 749 packets as specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. The 750 latter encapsulation is used within the WebRTC 751 [I-D.ietf-rtcweb-transports] context. 753 SCTP has a well-defined API, described in the next subsection. 755 3.5.2. Interface Description 757 [RFC4960] defines an abstract API for the base protocol. This API 758 describes the following functions callable by the upper layer of 759 SCTP: Initialize, Associate, Send, Receive, Receive Unsent Message, 760 Receive Unacknowledged Message, Shutdown, Abort, SetPrimary, Status, 761 Change Heartbeat, Request Heartbeat, Get SRTT Report, Set Failure 762 Threshold, Set Protocol Parameters, and Destroy. The following 763 notifications are provided by the SCTP stack to the upper layer: 765 COMMUNICATION UP, DATA ARRIVE, SHUTDOWN COMPLETE, COMMUNICATION LOST, 766 COMMUNICATION ERROR, RESTART, SEND FAILURE, NETWORK STATUS CHANGE. 768 An extension to the BSD Sockets API is defined in [RFC6458] and 769 covers: 771 o the base protocol defined in [RFC4960]. The API allows control 772 over local addresses and port numbers and the primary path. 773 Furthermore the application has fine control about parameters like 774 retransmission thresholds, the path supervision parameters, the 775 delayed acknowledgment timeout, and the fragmentation point. The 776 API provides a mechanism to allow the SCTP stack to notify the 777 application about events if the application has requested them. 778 These notifications provide information about status changes of 779 the association and each of the peer addresses. In case of send 780 failures, including drop of messages sent unreliably, the 781 application can also be notified and user messages can be returned 782 to the application. When sending user messages, the stream id, a 783 payload protocol identifier, an indication whether ordered 784 delivery is requested or not. These parameters can also be 785 provided on message reception. Additionally a context can be 786 provided when sending, which can be use in case of send failures. 787 The sending of arbitrary large user messages is supported. 789 o the SCTP Partial Reliability extension defined in [RFC3758] to 790 specify for a user message the PR-SCTP policy and the policy 791 specific parameter. Examples of these policies defined in 792 [RFC3758] and [RFC7496] are: 794 o Limiting the time a user message is dealt with by the sender. 796 o Limiting the number of retransmissions for each fragment of a user 797 message. If the number of retransmissions is limited to 0, one 798 gets a service similar to UDP. 800 o Abandoning messages of lower priority in case of a send buffer 801 shortage. 803 o the SCTP Authentication extension defined in [RFC4895] allowing to 804 manage the shared keys, the HMAC to use, set the chunk types which 805 are only accepted in an authenticated way, and get the list of 806 chunks which are accepted by the local and remote end point in an 807 authenticated way. 809 o the SCTP Dynamic Address Reconfiguration extension defined in 810 [RFC5061]. It allows to manually add and delete local addresses 811 for SCTP associations and the enabling of automatic address 812 addition and deletion. Furthermore the peer can be given a hint 813 for choosing its primary path. 815 A BSD Sockets API extension has been defined in the documents that 816 specify the following SCTP protocol extensions: 818 o the SCTP Stream Reconfiguration extension defined in [RFC6525]. 819 The API allows to trigger the reset operation for incoming and 820 outgoing streams and the whole association. It provides also a 821 way to notify the association about the corresponding events. 822 Furthermore the application can increase the number of streams. 824 o the UDP Encapsulation of SCTP packets extension defined in 825 [RFC6951]. The API allows the management of the remote UDP 826 encapsulation port. 828 o the SCTP SACK-IMMEDIATELY extension defined in [RFC7053]. The API 829 allows the sender of a user message to request the receiver to 830 send the corresponding acknowledgment immediately. 832 o the additional PR-SCTP policies defined in [RFC7496]. The API 833 allows to enable/disable the PR-SCTP extension, choose the PR-SCTP 834 policies defined in the document and provide statistical 835 information about abandoned messages. 837 Future documents describing SCTP protocol extensions are expected to 838 describe the corresponding BSD Sockets API extension in a "Socket API 839 Considerations" section. 841 The SCTP socket API supports two kinds of sockets: 843 o one-to-one style sockets (by using the socket type "SOCK_STREAM"). 845 o one-to-many style socket (by using the socket type 846 "SOCK_SEQPACKET"). 848 One-to-one style sockets are similar to TCP sockets, there is a 1:1 849 relationship between the sockets and the SCTP associations (except 850 for listening sockets). One-to-many style SCTP sockets are similar 851 to unconnected UDP sockets, where there is a 1:n relationship between 852 the sockets and the SCTP associations. 854 The SCTP stack can provide information to the applications about 855 state changes of the individual paths and the association whenever 856 they occur. These events are delivered similar to user messages but 857 are specifically marked as notifications. 859 New functions have been introduced to support the use of multiple 860 local and remote addresses. Additional SCTP-specific send and 861 receive calls have been defined to permit SCTP-specific information 862 to be sent without using ancillary data in the form of additional 863 cmsgs. These functions provide support for detecting partial 864 delivery of user messages and notifications. 866 The SCTP socket API allows a fine-grained control of the protocol 867 behavior through an extensive set of socket options. 869 The SCTP kernel implementations of FreeBSD, Linux and Solaris follow 870 mostly the specified extension to the BSD Sockets API for the base 871 protocol and the corresponding supported protocol extensions. 873 3.5.3. Transport Features 875 The transport features provided by SCTP are: 877 o connection-oriented transport with feature negotiation and 878 application-to-port mapping, 880 o unicast transport, 882 o port multiplexing, 884 o uni- or bidirectional communication, 886 o message-oriented delivery with durable message framing supporting 887 multiple concurrent streams, 889 o fully reliable, partially reliable, or unreliable delivery (based 890 on user specified policy to handle abandoned user messages) with 891 drop notification, 893 o ordered and unordered delivery within a stream, 895 o support for stream scheduling prioritization, 897 o segmentation, 899 o user message bundling, 901 o flow control using a window-based mechanism, 903 o congestion control using methods similar to TCP, 905 o strong error detection (CRC32c), 906 o transport layer multihoming for resilience and mobility. 908 3.6. Datagram Congestion Control Protocol (DCCP) 910 Datagram Congestion Control Protocol (DCCP) [RFC4340] is an IETF 911 standards track bidirectional transport protocol that provides 912 unicast connections of congestion-controlled messages without 913 providing reliability. 915 The DCCP Problem Statement describes the goals that DCCP sought to 916 address [RFC4336]: It is suitable for applications that transfer 917 fairly large amounts of data and that can benefit from control over 918 the trade off between timeliness and reliability [RFC4336]. 920 DCCP offers low overhead, and many characteristics common to UDP, but 921 can avoid "re-inventing the wheel" each time a new multimedia 922 application emerges. Specifically it includes core transport 923 functions (feature negotiation, path state management, RTT 924 calculation, PMTUD, etc.): DCCP applications select how they send 925 packets and, where suitable, choose common algorithms to manage their 926 functions. Examples of applications that can benefit from such 927 transport services include interactive applications, streaming media, 928 or on-line games [RFC4336]. 930 3.6.1. Protocol Description 932 DCCP is a connection-oriented datagram protocol, providing a three- 933 way handshake to allow a client and server to set up a connection, 934 and mechanisms for orderly completion and immediate teardown of a 935 connection. 937 A DCCP protocol instance can be extended [RFC4340] and tuned using 938 additional features. Some features are sender-side only, requiring 939 no negotiation with the receiver; some are receiver-side only; and 940 some are explicitly negotiated during connection setup. 942 DCCP uses a Connect packet to initiate a session, and permits each 943 endpoint to choose the features it wishes to support. Simultaneous 944 open [RFC5596], as in TCP, can enable interoperability in the 945 presence of middleboxes. The Connect packet includes a Service Code 946 [RFC5595] that identifies the application or protocol using DCCP, 947 providing middleboxes with information about the intended use of a 948 connection. 950 The DCCP service is unicast-only. 952 It provides multiplexing to multiple sockets at each endpoint using 953 port numbers. An active DCCP session is identified by its four-tuple 954 of local and remote IP addresses and local port and remote port 955 numbers. 957 The protocol segments data into messages, typically sized to fit in 958 IP packets, but which may be fragmented providing they are smaller 959 than the maximum packet size. A DCCP interface allows applications 960 to request fragmentation for packets larger than PMTU, but not larger 961 than the maximum packet size allowed by the current congestion 962 control mechanism (CCMPS) [RFC4340]. 964 Each message is identified by a sequence number. The sequence number 965 is used to identify segments in acknowledgments, to detect 966 unacknowledged segments, to measure RTT, etc. The protocol may 967 support unordered delivery of data, and does not itself provide 968 retransmission. DCCP supports reduced checksum coverage, a partial 969 payload protection mechanism similar to UDP-Lite. There is also a 970 Data Checksum option, which when enabled, contains a strong CRC, to 971 enable endpoints to detect application data corruption. 973 Receiver flow control is supported, which limits the amount of 974 unacknowledged data that can be outstanding at a given time. 976 DCCP supports negotiation of the congestion control profile between 977 endpoints, to provide plug-and-play congestion control mechanisms. 978 Examples of specified profiles include "TCP-like" [RFC4341], "TCP- 979 friendly" [RFC4342], and "TCP-friendly for small packets" [RFC5622]. 980 Additional mechanisms are recorded in an IANA registry. 982 A lightweight UDP-based encapsulation (DCCP-UDP) has been defined 983 [RFC6773] that permits DCCP to be used over paths where DCCP is not 984 natively supported. Support for DCCP in NAPT/NATs is defined in 985 [RFC4340] and [RFC5595]. Upper layer protocols specified on top of 986 DCCP include DTLS [RFC5595], RTP [RFC5672], ICE/SDP [RFC6773]. 988 3.6.2. Interface Description 990 Functions expected for a DCCP API include: Open, Close and Management 991 of the progress a DCCP connection. The Open function provides 992 feature negotiation, selection of an appropriate CCID for congestion 993 control and other parameters associated with the DCCP connection. A 994 function allows an application to send DCCP datagrams, including 995 setting the required checksum coverage, and any required options. 996 (DCCP permits sending datagrams with a zero-length payload.) A 997 function allows reception of data, including indicating if the data 998 was used or dropped. Functions can also make the status of a 999 connection visible to an application, including detection of the 1000 maximum packet size and the ability to perform flow control by 1001 detecting a slow receiver at the sender. 1003 There is no API currently specified in the RFC Series. 1005 3.6.3. Transport Features 1007 The transport features provided by DCCP are: 1009 o unicast transport, 1011 o connection-oriented communication with feature negotiation and 1012 application-to-port mapping, 1014 o signaling of application class for middlebox support (implemented 1015 using Service Codes), 1017 o port multiplexing, 1019 o uni-or bidirectional communication, 1021 o message-oriented delivery, 1023 o unreliable delivery with drop notification, 1025 o unordered delivery, 1027 o flow control (implemented using the slow receiver function) 1029 o partial and full payload error detection (with optional strong 1030 integrity check). 1032 3.7. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a 1033 pseudotransport 1035 Transport Layer Security (TLS) [RFC5246] and Datagram TLS (DTLS) 1036 [RFC6347] are IETF protocols that provide several security-related 1037 features to applications. TLS is designed to run on top of a 1038 reliable streaming transport protocol (usually TCP), while DTLS is 1039 designed to run on top of a best-effort datagram protocol (UDP or 1040 DCCP [RFC5238]). At the time of writing, the current version of TLS 1041 is 1.2, defined in [RFC5246]; work on TLS version 1.3 1042 [I-D.ietf-tls-tls13] nearing completion. DTLS provides nearly 1043 identical functionality to applications; it is defined in [RFC6347] 1044 and its current version is also 1.2. The TLS protocol evolved from 1045 the Secure Sockets Layer (SSL) [RFC6101] protocols developed in the 1046 mid-1990s to support protection of HTTP traffic. 1048 While older versions of TLS and DTLS are still in use, they provide 1049 weaker security guarantees. [RFC7457] outlines important attacks on 1050 TLS and DTLS. [RFC7525] is a Best Current Practices (BCP) document 1051 that describes secure configurations for TLS and DTLS to counter 1052 these attacks. The recommendations are applicable for the vast 1053 majority of use cases. 1055 3.7.1. Protocol Description 1057 Both TLS and DTLS provide the same security features and can thus be 1058 discussed together. The features they provide are: 1060 o Confidentiality 1062 o Data integrity 1064 o Peer authentication (optional) 1066 o Perfect forward secrecy (optional) 1068 The authentication of the peer entity can be omitted; a common web 1069 use case is where the server is authenticated and the client is not. 1070 TLS also provides a completely anonymous operation mode in which 1071 neither peer's identity is authenticated. It is important to note 1072 that TLS itself does not specify how a peering entity's identity 1073 should be interpreted. For example, in the common use case of 1074 authentication by means of an X.509 certificate, it is the 1075 application's decision whether the certificate of the peering entity 1076 is acceptable for authorization decisions. 1078 Perfect forward secrecy, if enabled and supported by the selected 1079 algorithms, ensures that traffic encrypted and captured during a 1080 session at time t0 cannot be later decrypted at time t1 (t1 > t0), 1081 even if the long-term secrets of the communicating peers are later 1082 compromised. 1084 As DTLS is generally used over an unreliable datagram transport such 1085 as UDP, applications will need to tolerate lost, re-ordered, or 1086 duplicated datagrams. Like TLS, DTLS conveys application data in a 1087 sequence of independent records. However, because records are mapped 1088 to unreliable datagrams, there are several features unique to DTLS 1089 that are not applicable to TLS: 1091 o Record replay detection (optional). 1093 o Record size negotiation (estimates of PMTU and record size 1094 expansion factor). 1096 o Conveyance of IP don't fragment (DF) bit settings by application. 1098 o An anti-DoS stateless cookie mechanism (optional). 1100 Generally, DTLS follows the TLS design as closely as possible. To 1101 operate over datagrams, DTLS includes a sequence number and limited 1102 forms of retransmission and fragmentation for its internal 1103 operations. The sequence number may be used for detecting replayed 1104 information, according to the windowing procedure described in 1105 Section 4.1.2.6 of [RFC6347]. DTLS forbids the use of stream 1106 ciphers, which are essentially incompatible when operating on 1107 independent encrypted records. 1109 3.7.2. Interface Description 1111 TLS is commonly invoked using an API provided by packages such as 1112 OpenSSL, wolfSSL, or GnuTLS. Using such APIs entails the 1113 manipulation of several important abstractions, which fall into the 1114 following categories: long-term keys and algorithms, session state, 1115 and communications/connections. 1117 Considerable care is required in the use of TLS APIs to ensure 1118 creation of a secure application. The programmer should have at 1119 least a basic understanding of encryption and digital signature 1120 algorithms and their strengths, public key infrastructure (including 1121 X.509 certificates and certificate revocation), and the sockets API. 1122 See [RFC7525] and [RFC7457], as mentioned above. 1124 As an example, in the case of OpenSSL, the primary abstractions are 1125 the library itself and method (protocol), session, context, cipher 1126 and connection. After initializing the library and setting the 1127 method, a cipher suite is chosen and used to configure a context 1128 object. Session objects may then be minted according to the 1129 parameters present in a context object and associated with individual 1130 connections. Depending on how precisely the programmer wishes to 1131 select different algorithmic or protocol options, various levels of 1132 details may be required. 1134 3.7.3. Transport Features 1136 Both TLS and DTLS employ a layered architecture. The lower layer is 1137 commonly called the record protocol. It is responsible for: 1139 o message fragmentation, 1141 o authentication and integrity via message authentication codes 1142 (MAC), 1144 o data encryption, 1146 o scheduling transmission using the underlying transport protocol. 1148 DTLS augments the TLS record protocol with: 1150 o ordering and replay protection, implemented using sequence 1151 numbers. 1153 Several protocols are layered on top of the record protocol. These 1154 include the handshake, alert, and change cipher spec protocols. 1155 There is also the data protocol, used to carry application traffic. 1156 The handshake protocol is used to establish cryptographic and 1157 compression parameters when a connection is first set up. In DTLS, 1158 this protocol also has a basic fragmentation and retransmission 1159 capability and a cookie-like mechanism to resist DoS attacks. (TLS 1160 compression is not recommended at present). The alert protocol is 1161 used to inform the peer of various conditions, most of which are 1162 terminal for the connection. The change cipher spec protocol is used 1163 to synchronize changes in cryptographic parameters for each peer. 1165 The data protocol, when used with an appropriate cipher, provides: 1167 o authentication of one end or both ends of a connection, 1169 o confidentiality, 1171 o cryptographic integrity protection. 1173 Both TLS and DTLS are unicast-only. 1175 3.8. Realtime Transport Protocol (RTP) 1177 RTP provides an end-to-end network transport service, suitable for 1178 applications transmitting real-time data, such as audio, video or 1179 data, over multicast or unicast transport services, including TCP, 1180 UDP, UDP-Lite, DCCP, TLS and DTLS. 1182 3.8.1. Protocol Description 1184 The RTP standard [RFC3550] defines a pair of protocols, RTP and the 1185 RTP control protocol, RTCP. The transport does not provide 1186 connection setup, instead relying on out-of-band techniques or 1187 associated control protocols to setup, negotiate parameters or tear 1188 down a session. 1190 An RTP sender encapsulates audio/video data into RTP packets to 1191 transport media streams. The RFC-series specifies RTP payload 1192 formats that allow packets to carry a wide range of media, and 1193 specifies a wide range of multiplexing, error control and other 1194 support mechanisms. 1196 If a frame of media data is large, it will be fragmented into several 1197 RTP packets. Likewise, several small frames may be bundled into a 1198 single RTP packet. 1200 An RTP receiver collects RTP packets from the network, validates them 1201 for correctness, and sends them to the media decoder input-queue. 1202 Missing packet detection is performed by the channel decoder. The 1203 play-out buffer is ordered by time stamp and is used to reorder 1204 packets. Damaged frames may be repaired before the media payloads 1205 are decompressed to display or store the data. Some uses of RTP are 1206 able to exploit the partial payload protection features offered by 1207 DCCP and UDP-Lite. 1209 RTCP is a control protocol that works alongside an RTP flow. Both 1210 the RTP sender and receiver will send RTCP report packets. This is 1211 used to periodically send control information and report performance. 1212 Based on received RTCP feedback, an RTP sender can adjust the 1213 transmission, e.g., perform rate adaptation at the application layer 1214 in the case of congestion. 1216 An RTCP receiver report (RTCP RR) is returned to the sender 1217 periodically to report key parameters (e.g, the fraction of packets 1218 lost in the last reporting interval, the cumulative number of packets 1219 lost, the highest sequence number received, and the inter-arrival 1220 jitter). The RTCP RR packets also contain timing information that 1221 allows the sender to estimate the network round trip time (RTT) to 1222 the receivers. 1224 The interval between reports sent from each receiver tends to be on 1225 the order of a few seconds on average, although this varies with the 1226 session rate, and sub-second reporting intervals are possible for 1227 high rate sessions. The interval is randomized to avoid 1228 synchronization of reports from multiple receivers. 1230 3.8.2. Interface Description 1232 There is no standard application programming interface defined for 1233 RTP or RTCP. Implementations are typically tightly integrated with a 1234 particular application, and closely follow the principles of 1235 application level framing and integrated layer processing [ClarkArch] 1236 in media processing [RFC2736], error recovery and concealment, rate 1237 adaptation, and security [RFC7202]. Accordingly, RTP implementations 1238 tend to be targeted at particular application domains (e.g., voice- 1239 over-IP, IPTV, or video conferencing), with a feature set optimized 1240 for that domain, rather than being general purpose implementations of 1241 the protocol. 1243 3.8.3. Transport Features 1245 The transport features provided by RTP are: 1247 o unicast, multicast or IPv4 broadcast (provided by lower layer 1248 protocol), 1250 o port multiplexing (provided by lower layer protocol), 1252 o uni- or bidirectional communication (provided by lower layer 1253 protocol), 1255 o message-oriented delivery with support for media types and other 1256 extensions, 1258 o reliable delivery when using erasure coding or unreliable delivery 1259 with drop notification (if supported by lower layer protocol), 1261 o connection setup with feature negotiation (using associated 1262 protocols) and application-to-port mapping (provided by lower 1263 layer protocol), 1265 o segmentation, 1267 o performance metric reporting (using associated protocols). 1269 3.9. Hypertext Transport Protocol (HTTP) over TCP as a pseudotransport 1271 The Hypertext Transfer Protocol (HTTP) is an application-level 1272 protocol widely used on the Internet. It provides object-oriented 1273 delivery of discrete data or files. Version 1.1 of the protocol is 1274 specified in [RFC7230] [RFC7231] [RFC7232] [RFC7233] [RFC7234] 1275 [RFC7235], and version 2 in [RFC7540]. HTTP is usually transported 1276 over TCP using port 80 and 443, although it can be used with other 1277 transports. When used over TCP it inherits TCP's properties. 1279 Application layer protocols may use HTTP as a substrate with an 1280 existing method and data formats, or specify new methods and data 1281 formats. There are various reasons for this practice listed in 1282 [RFC3205]; these include being a well-known and well-understood 1283 protocol, reusability of existing servers and client libraries, easy 1284 use of existing security mechanisms such as HTTP digest 1285 authentication [RFC2617] and TLS [RFC5246], the ability of HTTP to 1286 traverse firewalls makes it work over many types of infrastructure, 1287 and in cases where an application server often needs to support HTTP 1288 anyway. 1290 Depending on application need, the use of HTTP as a substrate 1291 protocol may add complexity and overhead in comparison to a special- 1292 purpose protocol (e.g., HTTP headers, suitability of the HTTP 1293 security model, etc.). [RFC3205] addresses this issue and provides 1294 some guidelines and identifies concerns about the use of HTTP 1295 standard port 80 and 443, the use of HTTP URL scheme and interaction 1296 with existing firewalls, proxies and NATs. 1298 Representational State Transfer (REST) [REST] is another example of 1299 how applications can use HTTP as transport protocol. REST is an 1300 architecture style that may be used to build applications using HTTP 1301 as a communication protocol. 1303 3.9.1. Protocol Description 1305 Hypertext Transfer Protocol (HTTP) is a request/response protocol. A 1306 client sends a request containing a request method, URI and protocol 1307 version followed message whose design is inspired by MIME (see 1308 [RFC7231] for the differences between an HTTP object and a MIME 1309 message), containing information about the client and request 1310 modifiers. The message can also contain a message body carrying 1311 application data. The server responds with a status or error code 1312 followed by a message containing information about the server and 1313 information about the data. This may include a message body. It is 1314 possible to specify a data format for the message body using MIME 1315 media types [RFC2045]. The protocol has additional features, some 1316 relevant to pseudo-transport are described below. 1318 Content negotiation, specified in [RFC7231], is a mechanism provided 1319 by HTTP to allow selection of a representation for a requested 1320 resource. The client and server negotiate acceptable data formats, 1321 character sets, data encoding (e.g., data can be transferred 1322 compressed using gzip). HTTP can accommodate exchange of messages as 1323 well as data streaming (using chunked transfer encoding [RFC7230]). 1324 It is also possible to request a part of a resource using an object 1325 range request [RFC7233]. The protocol provides powerful cache 1326 control signaling defined in [RFC7234]. 1328 The persistent connections of HTTP 1.1 and HTTP 2.0 allow multiple 1329 request- response transactions (streams) during the life-time of a 1330 single HTTP connection. This reduces overhead during connection 1331 establishment and mitigates transport layer slow-start that would 1332 have otherwise been incurred for each transaction. HTTP 2.0 1333 connections can multiplex many request/response pairs in parallel on 1334 a single transport connection. Both are important to reduce latency 1335 for HTTP's primary use case. 1337 HTTP can be combined with security mechanisms, such as TLS (denoted 1338 by HTTPS). This adds protocol properties provided by such a 1339 mechanism (e.g., authentication, encryption). The TLS Application- 1340 Layer Protocol Negotiation (ALPN) extension [RFC7301] can be used to 1341 negotiate the HTTP version within the TLS handshake, eliminating the 1342 latency incurred by additional round-trip exchanges. Arbitrary 1343 cookie strings, included as part of the request headers, are often 1344 used as bearer tokens in HTTP. 1346 3.9.2. Interface Description 1348 There are many HTTP libraries available exposing different APIs. The 1349 APIs provide a way to specify a request by providing a URI, a method, 1350 request modifiers and optionally a request body. For the response, 1351 callbacks can be registered that will be invoked when the response is 1352 received. If HTTPS is used, the API exposes a registration of 1353 callbacks for a server that requests client authentication and when 1354 certificate verification is needed. 1356 The World Wide Web Consortium (W3C) has standardized the 1357 XMLHttpRequest API [XHR]. This API can be used for sending HTTP/ 1358 HTTPS requests and receiving server responses. Besides the XML data 1359 format, the request and response data format can also be JSON, HTML, 1360 and plain text. JavaScript and XMLHttpRequest are ubiquitous 1361 programming models for websites, and more general applications, where 1362 native code is less attractive. 1364 3.9.3. Transport features 1366 The transport features provided by HTTP, when used as a pseudo- 1367 transport, are: 1369 o unicast transport (provided by the lower layer protocol, usually 1370 TCP), 1372 o uni- or bidirectional communication, 1374 o transfer of objects in multiple streams with object content type 1375 negotiation, supporting partial transmission of object ranges, 1377 o ordered delivery (provided by the lower layer protocol, usually 1378 TCP), 1380 o fully reliable delivery (provided by the lower layer protocol, 1381 usually TCP), 1383 o flow control (provided by the lower layer protocol, usually TCP). 1385 o congestion control (provided by the lower layer protocol, usually 1386 TCP). 1388 HTTPS (HTTP over TLS) additionally provides the following features 1389 (as provided by TLS): 1391 o authentication (of one or both ends of a connection), 1393 o confidentiality, 1395 o integrity protection. 1397 3.10. File Delivery over Unidirectional Transport/Asynchronous Layered 1398 Coding Reliable Multicast (FLUTE/ALC) 1400 FLUTE/ALC is an IETF standards track protocol specified in [RFC6726] 1401 and [RFC5775]. It provides object-oriented delivery of discrete data 1402 or files. Asynchronous Layer Coding (ALC) provides an underlying 1403 reliable transport service and FLUTE a file-oriented specialization 1404 of the ALC service (e.g., to carry associated metadata). The 1405 [RFC6726] and [RFC5775] protocols are non-backward-compatible updates 1406 of the [RFC3926] and [RFC3450] experimental protocols; these 1407 experimental protocols are currently largely deployed in the 3GPP 1408 Multimedia Broadcast and Multicast Services (MBMS) (see [MBMS], 1409 section 7) and similar contexts (e.g., the Japanese ISDB-Tmm 1410 standard). 1412 The FLUTE/ALC protocol has been designed to support massively 1413 scalable reliable bulk data dissemination to receiver groups of 1414 arbitrary size using IP Multicast over any type of delivery network, 1415 including unidirectional networks (e.g., broadcast wireless 1416 channels). However, the FLUTE/ALC protocol also supports point-to- 1417 point unicast transmissions. 1419 FLUTE/ALC bulk data dissemination has been designed for discrete file 1420 or memory-based "objects". Although FLUTE/ALC is not well adapted to 1421 byte- and message-streaming, there is an exception: FLUTE/ALC is used 1422 to carry 3GPP Dynamic Adaptive Streaming over HTTP (DASH) when 1423 scalability is a requirement (see [MBMS], section 5.6). 1425 FLUTE/ALC's reliability, delivery mode, congestion control, and flow/ 1426 rate control mechanisms can be separately controlled to meet 1427 different application needs. Section 4.1 of 1428 [I-D.ietf-tsvwg-rfc5405bis] describes multicast congestion control 1429 requirements for UDP. 1431 3.10.1. Protocol Description 1433 The FLUTE/ALC protocol works on top of UDP (though it could work on 1434 top of any datagram delivery transport protocol), without requiring 1435 any connectivity from receivers to the sender. Purely unidirectional 1436 networks are therefore supported by FLUTE/ALC. This guarantees 1437 scalability to an unlimited number of receivers in a session, since 1438 the sender behaves exactly the same regardless of the number of 1439 receivers. 1441 FLUTE/ALC supports the transfer of bulk objects such as file or in- 1442 memory content, using either a push or an on-demand mode. in push 1443 mode, content is sent once to the receivers, while in on-demand mode, 1444 content is sent continuously during periods of time that can greatly 1445 exceed the average time required to download the session objects (see 1446 [RFC5651], section 4.2). 1448 This enables receivers to join a session asynchronously, at their own 1449 discretion, receive the content and leave the session. In this case, 1450 data content is typically sent continuously, in loops (also known as 1451 "carousels"). FLUTE/ALC also supports the transfer of an object 1452 stream, with loose real-time constraints. This is particularly 1453 useful to carry 3GPP DASH when scalability is a requirement and 1454 unicast transmissions over HTTP cannot be used ([MBMS], section 5.6). 1455 In this case, packets are sent in sequence using push mode. FLUTE/ 1456 ALC is not well adapted to byte- and message-streaming and other 1457 solutions could be preferred (e.g., FECFRAME [RFC6363] with real-time 1458 flows). 1460 The FLUTE file delivery instantiation of ALC provides a metadata 1461 delivery service. Each object of the FLUTE/ALC session is described 1462 in a dedicated entry of a File Delivery Table (FDT), using an XML 1463 format (see [RFC6726], section 3.2). This metadata can include, but 1464 is not restricted to, a URI attribute (to identify and locate the 1465 object), a media type attribute, a size attribute, an encoding 1466 attribute, or a message digest attribute. Since the set of objects 1467 sent within a session can be dynamic, with new objects being added 1468 and old ones removed, several instances of the FDT can be sent and a 1469 mechanism is provided to identify a new FDT Instance. 1471 Error detection and verification of the protocol control information 1472 relies on the on the underlying transport (e.g., UDP checksum). 1474 To provide robustness against packet loss and improve the efficiency 1475 of the on-demand mode, FLUTE/ALC relies on packet erasure coding (AL- 1476 FEC). AL-FEC encoding is proactive (since there is no feedback and 1477 therefore no (N)ACK-based retransmission) and ALC packets containing 1478 repair data are sent along with ALC packets containing source data. 1480 Several FEC Schemes have been standardized; FLUTE/ALC does not 1481 mandate the use of any particular one. Several strategies concerning 1482 the transmission order of ALC source and repair packets are possible, 1483 in particular in on-demand mode where it can deeply impact the 1484 service provided (e.g., to favor the recovery of objects in sequence, 1485 or at the other extreme, to favor the recovery of all objects in 1486 parallel), and FLUTE/ALC does not mandate nor recommend the use of 1487 any particular one. 1489 A FLUTE/ALC session is composed of one or more channels, associated 1490 to different destination unicast and/or multicast IP addresses. ALC 1491 packets are sent in those channels at a certain transmission rate, 1492 with a rate that often differs depending on the channel. FLUTE/ALC 1493 does not mandate nor recommend any strategy to select which ALC 1494 packet to send on which channel. FLUTE/ALC can use a multiple rate 1495 congestion control building block (e.g., WEBRC) to provide congestion 1496 control that is feedback free, where receivers adjust their reception 1497 rates individually by joining and leaving channels associated with 1498 the session. To that purpose, the ALC header provides a specific 1499 field to carry congestion control specific information. However 1500 FLUTE/ALC does not mandate the use of a particular congestion control 1501 mechanism although WEBRC is mandatory to support for the Internet 1502 ([RFC6726], section 1.1.4). FLUTE/ALC is often used over a network 1503 path with pre-provisioned capacity [I-D.ietf-tsvwg-rfc5405bis] where 1504 there are no flows competing for capacity. In this case, a sender- 1505 based rate control mechanism and a single channel is sufficient. 1507 [RFC6584] provides per-packet authentication, integrity, and anti- 1508 replay protection in the context of the ALC and NORM protocols. 1509 Several mechanisms are proposed that seamlessly integrate into these 1510 protocols using the ALC and NORM header extension mechanisms. 1512 3.10.2. Interface Description 1514 The FLUTE/ALC specification does not describe a specific application 1515 programming interface (API) to control protocol operation. Although 1516 open source and commercial implementations have specified APIs, there 1517 is no IETF- specified API for FLUTE/ALC. 1519 3.10.3. Transport Features 1521 The transport features provided by FLUTE/ALC are: 1523 o unicast, multicast, anycast or IPv4 broadcast transmission, 1525 o object-oriented delivery of discrete data or files and associated 1526 metadata, 1528 o fully reliable or partially reliable delivery (of file or in- 1529 memory objects), using proactive packet erasure coding (AL-FEC) to 1530 recover from packet erasures, 1532 o ordered or unordered delivery (of file or in-memory objects), 1534 o error detection (based on the UDP checksum), 1536 o per-packet authentication, 1538 o per-packet integrity, 1540 o per-packet replay protection, 1542 o congestion control for layered flows (e.g., with WEBRC). 1544 3.11. NACK-Oriented Reliable Multicast (NORM) 1546 NORM is an IETF standards track protocol specified in [RFC5740]. It 1547 provides object-oriented delivery of discrete data or files. 1549 The protocol was designed to support reliable bulk data dissemination 1550 to receiver groups using IP Multicast but also provides for point-to- 1551 point unicast operation. Support for bulk data dissemination 1552 includes discrete file or computer memory-based "objects" as well as 1553 byte- and message-streaming. 1555 NORM can incorporate packet erasure coding as a part of its selective 1556 ARQ in response to negative acknowledgments from the receiver. The 1557 packet erasure coding can also be proactively applied for forward 1558 protection from packet loss. NORM transmissions are governed by TCP- 1559 friendly multicast congestion control (TFMCC, [RFC4654]). The 1560 reliability, congestion control and flow control mechanisms can be 1561 separately controlled to meet different application needs. 1563 3.11.1. Protocol Description 1565 The NORM protocol is encapsulated in UDP datagrams and thus provides 1566 multiplexing for multiple sockets on hosts using port numbers. For 1567 loosely coordinated IP Multicast, NORM is not strictly connection- 1568 oriented although per-sender state is maintained by receivers for 1569 protocol operation. [RFC5740] does not specify a handshake protocol 1570 for connection establishment. Separate session initiation can be 1571 used to coordinate port numbers. However, in-band "client-server" 1572 style connection establishment can be accomplished with the NORM 1573 congestion control signaling messages using port binding techniques 1574 like those for TCP client-server connections. 1576 NORM supports bulk "objects" such as file or in-memory content but 1577 also can treat a stream of data as a logical bulk object for purposes 1578 of packet erasure coding. In the case of stream transport, NORM can 1579 support either byte streams or message streams where application- 1580 defined message boundary information is carried in the NORM protocol 1581 messages. This allows the receiver(s) to join/re-join and recover 1582 message boundaries mid-stream as needed. Application content is 1583 carried and identified by the NORM protocol with encoding symbol 1584 identifiers depending upon the Forward Error Correction (FEC) Scheme 1585 [RFC3452] configured. NORM uses NACK-based selective ARQ to reliably 1586 deliver the application content to the receiver(s). NORM proactively 1587 measures round-trip timing information to scale ARQ timers 1588 appropriately and to support congestion control. For multicast 1589 operation, timer-based feedback suppression is uses to achieve group 1590 size scaling with low feedback traffic levels. The feedback 1591 suppression is not applied for unicast operation. 1593 NORM uses rate-based congestion control based upon the TCP-Friendly 1594 Rate Control (TFRC) [RFC4324] principles that are also used in DCCP 1595 [RFC4340]. NORM uses control messages to measure RTT and collect 1596 congestion event information (e.g., reflecting a loss event or ECN 1597 event) from the receiver(s) to support dynamic adjustment or the 1598 rate. The TCP-Friendly Multicast Congestion Control (TFMCC) 1599 [RFC4654] provides extra features to support multicast, but is 1600 functionally equivalent to TFRC for unicast. 1602 Error detection and verification of the protocol control information 1603 relies on the on the underlying transport(e.g., UDP checksum). 1605 The reliability mechanism is decoupled from congestion control. This 1606 allows invocation of alternative arrangements of transport services. 1607 For example, to support, fixed-rate reliable delivery or unreliable 1608 delivery (that may optionally be "better than best effort" via packet 1609 erasure coding) using TFRC. Alternative congestion control 1610 techniques may be applied. For example, TFRC rate control with 1611 congestion event detection based on ECN. 1613 While NORM provides NACK-based reliability, it also supports a 1614 positive acknowledgment (ACK) mechanism that can be used for receiver 1615 flow control. This mechanism is decoupled from the reliability and 1616 congestion control, supporting applications with different needs. 1617 One example is use of NORM for quasi-reliable delivery, where timely 1618 delivery of newer content may be favored over completely reliable 1619 delivery of older content within buffering and RTT constraints. 1621 3.11.2. Interface Description 1623 The NORM specification does not describe a specific application 1624 programming interface (API) to control protocol operation. A freely- 1625 available, open source reference implementation of NORM is available 1626 at https://www.nrl.navy.mil/itd/ncs/products/norm, and a documented 1627 API is provided for this implementation. While a sockets-like API is 1628 not currently documented, the existing API supports the necessary 1629 functions for that to be implemented. 1631 3.11.3. Transport Features 1633 The transport features provided by NORM are: 1635 o unicast or multicast transport, 1637 o unidirectional communication, 1639 o stream-oriented delivery in a single stream or object-oriented 1640 delivery of in-memory data or file bulk content objects, 1642 o fully reliable (NACK-based) or partially reliable (using erasure 1643 coding both proactively and as part of ARQ) delivery, 1645 o unordered delivery, 1647 o error detection (relies on UDP checksum), 1649 o segmentation, 1651 o data bundling (using Nagle's algorithm), 1653 o flow control (timer-based and/or ack-based), 1655 o congestion control (also supporting fixed rate reliable or 1656 unreliable delivery). 1658 3.12. Internet Control Message Protocol (ICMP) 1660 The Internet Control Message Protocol (ICMP) [RFC0792] for IPv4 and 1661 ICMP for IPv6 [RFC4443] are IETF standards track protocols. It is a 1662 connection-less unidirectional protocol that delivers individual 1663 messages, without error correction, congestion control, or flow 1664 control. Messages may be sent as unicast, IPv4 broadcast or 1665 multicast datagrams (IPv4 and IPv6), in addition to anycast 1666 datagrams. 1668 While ICMP is not typically described as a transport protocol, it 1669 does position itself over the network layer, and the operation of 1670 other transport protocols can be closely linked to the functions 1671 provided by ICMP. 1673 Transport Protocols and upper layer protocols can use received ICMP 1674 messages to help them take appropriate decisions when network or 1675 endpoint errors are reported. For example, to implement, ICMP-based 1676 Path MTU discovery [RFC1191][RFC1981] or assist in Packetization 1677 Layer Path MTU Discovery (PMTUD) [RFC4821]. Such reactions to 1678 received messages need to protect from off-path data injection 1679 [I-D.ietf-tsvwg-rfc5405bis], to avoid an application receiving 1680 packets created by an unauthorized third party. An application 1681 therefore needs to ensure that all messages are appropriately 1682 validated, by checking the payload of the messages to ensure these 1683 are received in response to actually transmitted traffic (e.g., a 1684 reported error condition that corresponds to a UDP datagram or TCP 1685 segment was actually sent by the application). This requires context 1686 [RFC6056], such as local state about communication instances to each 1687 destination (e.g., in the TCP, DCCP, or SCTP protocols). This state 1688 is not always maintained by UDP-based applications 1689 [I-D.ietf-tsvwg-rfc5405bis]. 1691 3.12.1. Protocol Description 1693 ICMP is a connection-less unidirectional protocol, It delivers 1694 independent messages, called datagrams. Each message is required to 1695 carry a checksum as an integrity check and to protect from mis- 1696 delivery to an unintended endpoint. 1698 ICMP messages typically relay diagnostic information from an endpoint 1699 [RFC1122] or network device [RFC1812] addressed to the sender of a 1700 flow. This usually contains the network protocol header of a packet 1701 that encountered a reported issue. Some formats of messages can also 1702 carry other payload data. Each message carries an integrity check 1703 calculated in the same way as for UDP, this checksum is not optional. 1705 The RFC series defines additional IPv6 message formats to support a 1706 range of uses. In the case of IPv6 the protocol incorporates 1707 neighbor discovery [RFC2461] [RFC3971] (provided by ARP for IPv4) and 1708 the Multicast Listener Discovery (MLD) [RFC2710] group management 1709 functions (provided by IGMP for IPv4). 1711 Reliable transmission can not be assumed. A receiving application 1712 that is unable to run sufficiently fast, or frequently, may miss 1713 messages since there is no flow or congestion control. In addition 1714 some network devices rate-limit ICMP messages. 1716 3.12.2. Interface Description 1718 ICMP processing is integrated in many connection-oriented transports, 1719 but like other functions needs to be provided by an upper-layer 1720 protocol when using UDP and UDP-Lite. 1722 On some stacks, a bound socket also allows a UDP application to be 1723 notified when ICMP error messages are received for its transmissions 1724 [I-D.ietf-tsvwg-rfc5405bis]. 1726 Any response to ICMP error messages ought to be robust to temporary 1727 routing failures (sometimes called "soft errors"), e.g., transient 1728 ICMP "unreachable" messages ought to not normally cause a 1729 communication abort [RFC5461] [I-D.ietf-tsvwg-rfc5405bis]. 1731 3.12.3. Transport Features 1733 ICMP does not provide any transport service directly to applications. 1734 Used together with other transport protocols, it provides 1735 transmission of control, error, and measurement data between 1736 endpoints, or from devices along the path to one endpoint. 1738 4. Congestion Control 1740 Congestion control is critical to the stable operation of the 1741 Internet. A variety of mechanisms are used to provide the congestion 1742 control needed by many Internet transport protocols. Congestion is 1743 detected based on sensing of network conditions, whether through 1744 explicit or implicit feedback. The congestion control mechanisms 1745 that can be applied by different transport protocols are largely 1746 orthogonal to the choice of transport protocol. This section 1747 provides an overview of the congestion control mechanisms available 1748 to the protocols described in Section 3. 1750 Many protocols use a separate window to determine the maximum sending 1751 rate that is allowed by the congestion control. The used congestion 1752 control mechanism will increase the congestion window if feedback is 1753 received that indicates that the currently used network path is not 1754 congested, and will reduce the window otherwise. Window-based 1755 mechanisms often increase their window slowing over multiple RTTs, 1756 while decreasing strongly when the first indication of congestion is 1757 received. One example is an Additive Increase Multiplicative 1758 Decrease (AIMD) scheme, where the window is increased by a certain 1759 number of packets/bytes for each data segment that has been 1760 successfully transmitted, while the window decreases multiplicatively 1761 on the occurrence of a congestion event. This can lead to a rather 1762 unstable, oscillating sending rate, but will resolve a congestion 1763 situation quickly. TCP New Reno [RFC5681] which is one of the 1764 initial proposed schemes for TCP as well as TCP Cubic 1765 [I-D.ietf-tcpm-cubic] which is the default mechanism for TCP in Linux 1766 are two examples for window-based AIMD schemes. This approach is 1767 also used by DCCP CCID-2 for datagram congestion control. 1769 Some classes of applications prefer to use a transport service that 1770 allows sending at a more stable rate, that is slowly varied in 1771 response to congestion. Rate-based methods offer this type of 1772 congestion control and have been defined based on the loss ratio and 1773 observed round trip time, such as TFRC [RFC5348] and TFRC-SP 1774 [RFC4828]. These methods utilize a throughput equation to determine 1775 the maximum acceptable rate. Such methods are used with DCCP CCID-3 1776 [RFC4342] and CCID-4 [RFC5622], WEBRC [RFC3738], and other 1777 applications. 1779 Another class of applications prefer a transport service that yields 1780 to other (higher-priority) traffic, such as interactive 1781 transmissions. While most traffic in the Internet uses loss-based 1782 congestion control and therefore tends to fill the network buffers 1783 (to a certain level if Active Queue Management (AQM) is used), low- 1784 priority congestion control methods often react to changes in delay 1785 as an earlier indication of congestion. This approach tends to 1786 induce less loss than a loss-based method but does generally not 1787 compete well with loss-based traffic across shared bottleneck links. 1788 Therefore, methods such as LEDBAT [RFC6824], are deployed in the 1789 Internet for scavenger traffic that aim to only utilize otherwise 1790 unused capacity. 1792 5. Transport Features 1794 The transport protocol features described in this document can be 1795 used as a basis for defining common transport features, listed below 1796 with the protocols supporting them: 1798 o Control Functions 1800 * Addressing 1802 + unicast (TCP, MPTCP, UDP, UDP-Lite, SCTP, DCCP, TLS, RTP, 1803 HTTP, ICMP) 1805 + multicast (UDP, UDP-Lite, RTP, ICMP, FLUTE/ALC, NORM). Note 1806 that, as TLS and DTLS are unicast-only, there is no widely 1807 deployed mechanism for supporting the features in the 1808 Security section below when using multicast addressing. 1810 + IPv4 broadcast (UDP, UDP-Lite, ICMP) 1811 + anycast (UDP, UDP-Lite). Connection-oriented protocols such 1812 as TCP and DCCP have also been deployed using anycast 1813 addressing, with the risk that routing changes may cause 1814 connection failure. 1816 * Association type 1818 + connection-oriented (TCP, MPTCP, DCCP, SCTP, TLS, RTP, HTTP, 1819 NORM) 1821 + connectionless (UDP, UDP-Lite, FLUTE/ALC) 1823 * Multihoming support 1825 + resilience and mobility (MPTCP, SCTP) 1827 + load-balancing (MPTCP) 1829 + address family multiplexing (MPTCP, SCTP) 1831 * Middlebox cooperation 1833 + application-class signaling to middleboxes (DCCP) 1835 + error condition signaling from middleboxes and routers to 1836 endpoints (ICMP) 1838 * Signaling 1840 + control information and error signaling (ICMP) 1842 + application performance reporting (RTP) 1844 o Delivery 1846 * Reliability 1848 + fully reliable delivery (TCP, MPTCP, SCTP, TLS, HTTP, FLUTE/ 1849 ALC, NORM) 1851 + partially reliable delivery (SCTP, NORM) 1853 - using packet erasure coding (RTP, FLUTE/ALC, NORM) 1855 - with specified policy for dropped messages (SCTP) 1857 + unreliable delivery (SCTP, UDP, UDP-Lite, DCCP, RTP) 1858 - with drop notification to sender (SCTP, DCCP, RTP) 1860 + error detection 1862 - checksum for error detection (TCP, MPTCP, UDP, UDP-Lite, 1863 SCTP, DCCP, TLS, DTLS, FLUTE/ALC, NORM, ICMP) 1865 - partial payload checksum protection (UDP-Lite, DCCP). 1866 Some uses of RTP can exploit partial payload checksum 1867 protection feature to provide a corruption tolerant 1868 transport service. 1870 - checksum optional (UDP). Possible with IPv4 and in 1871 certain cases with IPv6. 1873 * Ordering 1875 + ordered delivery (TCP, MPTCP, SCTP, TLS, RTP, HTTP, FLUTE) 1877 + unordered delivery permitted (UDP, UDP-Lite, SCTP, DCCP, 1878 RTP, NORM) 1880 * Type/framing 1882 + stream-oriented delivery (TCP, MPTCP, SCTP, TLS, HTTP) 1884 - with multiple streams per association (SCTP, HTTP2) 1886 + message-oriented delivery (UDP, UDP-Lite, SCTP, DCCP, DTLS, 1887 RTP) 1889 + object-oriented delivery of discrete data or files and 1890 associated metadata (HTTP, FLUTE/ALC, NORM) 1892 - with partial delivery of object ranges (HTTP) 1894 * Directionality 1896 + unidirectional (UDP, UDP-Lite, DCCP, RTP, FLUTE/ALC, NORM) 1898 + bidirectional (TCP, MPTCP, SCTP, TLS, HTTP) 1900 o Transmission control 1902 * flow control (TCP, MPTCP, SCTP, DCCP, TLS, RTP, HTTP) 1903 * congestion control (TCP, MPTCP, SCTP, DCCP, RTP, FLUTE/ALC, 1904 NORM). Congestion control can also provided by the transport 1905 supporting an upper later transport (e.g., TLS, RTP, HTTP). 1907 * segmentation (TCP, MPTCP, SCTP, TLS, RTP, HTTP, FLUTE/ALC, 1908 NORM) 1910 * data/message bundling (TCP, MPTCP, SCTP, TLS, HTTP) 1912 * stream scheduling prioritization (SCTP, HTTP2) 1914 * endpoint multiplexing (MPTCP) 1916 o Security 1918 * authentication of one end of a connection (TLS, DTLS, FLUTE/ 1919 ALC) 1921 * authentication of both ends of a connection (TLS, DTLS) 1923 * confidentiality (TLS, DTLS) 1925 * cryptographic integrity protection (TLS, DTLS) 1927 * replay protection (TLS, DTLS, FLUTE/ALC) 1929 6. IANA Considerations 1931 This document has no considerations for IANA. 1933 7. Security Considerations 1935 This document surveys existing transport protocols and protocols 1936 providing transport-like services. Confidentiality, integrity, and 1937 authenticity are among the features provided by those services. This 1938 document does not specify any new features or mechanisms for 1939 providing these features. Each RFC referenced by this document 1940 discusses the security considerations of the specification it 1941 contains. 1943 8. Contributors 1945 In addition to the editors, this document is the work of Brian 1946 Adamson, Dragana Damjanovic, Kevin Fall, Simone Ferlin-Oliviera, 1947 Ralph Holz, Olivier Mehani, Karen Nielsen, Colin Perkins, Vincent 1948 Roca, and Michael Tuexen. 1950 o Section 3.2 on MPTCP was contributed by Simone Ferlin-Oliviera 1951 (ferlin@simula.no) and Olivier Mehani 1952 (olivier.mehani@nicta.com.au) 1954 o Section 3.3 on UDP was contributed by Kevin Fall (kfall@kfall.com) 1956 o Section 3.5 on SCTP was contributed by Michael Tuexen (tuexen@fh- 1957 muenster.de) and Karen Nielsen (karen.nielsen@tieto.com) 1959 o Section 3.7 on TLS and DTLS was contributed by Ralph Holz 1960 (ralph.holz@nicta.com.au) and Olivier Mehani 1961 (olivier.mehani@nicta.com.au) 1963 o Section 3.8 on RTP contains contributions from Colin Perkins 1964 (csp@csperkins.org) 1966 o Section 3.9 on HTTP was contributed by Dragana Damjanovic 1967 (ddamjanovic@mozilla.com) 1969 o Section 3.10 on FLUTE/ALC was contributed by Vincent Roca 1970 (vincent.roca@inria.fr) 1972 o Section 3.11 on NORM was contributed by Brian Adamson 1973 (brian.adamson@nrl.navy.mil) 1975 9. Acknowledgments 1977 Thanks to Joe Touch, Michael Welzl, Spencer Dawkins, and the TAPS 1978 Working Group for the comments, feedback, and discussion. This work 1979 is supported by the European Commission under grant agreement No. 1980 318627 mPlane and from the Horizon 2020 research and innovation 1981 program under grant agreements No. 644334 (NEAT) and No. 688421 1982 (MAMI). This support does not imply endorsement. 1984 10. Informative References 1986 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1987 DOI 10.17487/RFC0768, August 1980, 1988 . 1990 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1991 RFC 792, DOI 10.17487/RFC0792, September 1981, 1992 . 1994 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1995 RFC 793, DOI 10.17487/RFC0793, September 1981, 1996 . 1998 [RFC0896] Nagle, J., "Congestion Control in IP/TCP Internetworks", 1999 RFC 896, DOI 10.17487/RFC0896, January 1984, 2000 . 2002 [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the 2003 Internet checksum", RFC 1071, DOI 10.17487/RFC1071, 2004 September 1988, . 2006 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2007 Communication Layers", STD 3, RFC 1122, 2008 DOI 10.17487/RFC1122, October 1989, 2009 . 2011 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2012 DOI 10.17487/RFC1191, November 1990, 2013 . 2015 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 2016 RFC 1812, DOI 10.17487/RFC1812, June 1995, 2017 . 2019 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 2020 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 2021 1996, . 2023 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 2024 Selective Acknowledgment Options", RFC 2018, 2025 DOI 10.17487/RFC2018, October 1996, 2026 . 2028 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2029 Extensions (MIME) Part One: Format of Internet Message 2030 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 2031 . 2033 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2034 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2035 December 1998, . 2037 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 2038 Discovery for IP Version 6 (IPv6)", RFC 2461, 2039 DOI 10.17487/RFC2461, December 1998, 2040 . 2042 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 2043 Leach, P., Luotonen, A., and L. Stewart, "HTTP 2044 Authentication: Basic and Digest Access Authentication", 2045 RFC 2617, DOI 10.17487/RFC2617, June 1999, 2046 . 2048 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 2049 Listener Discovery (MLD) for IPv6", RFC 2710, 2050 DOI 10.17487/RFC2710, October 1999, 2051 . 2053 [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP 2054 Payload Format Specifications", BCP 36, RFC 2736, 2055 DOI 10.17487/RFC2736, December 1999, 2056 . 2058 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2059 of Explicit Congestion Notification (ECN) to IP", 2060 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2061 . 2063 [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, 2064 RFC 3205, DOI 10.17487/RFC3205, February 2002, 2065 . 2067 [RFC3260] Grossman, D., "New Terminology and Clarifications for 2068 Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, 2069 . 2071 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 2072 Layer Security over Stream Control Transmission Protocol", 2073 RFC 3436, DOI 10.17487/RFC3436, December 2002, 2074 . 2076 [RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. 2077 Crowcroft, "Asynchronous Layered Coding (ALC) Protocol 2078 Instantiation", RFC 3450, DOI 10.17487/RFC3450, December 2079 2002, . 2081 [RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 2082 M., and J. Crowcroft, "Forward Error Correction (FEC) 2083 Building Block", RFC 3452, DOI 10.17487/RFC3452, December 2084 2002, . 2086 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2087 Jacobson, "RTP: A Transport Protocol for Real-Time 2088 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2089 July 2003, . 2091 [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate 2092 Control (WEBRC) Building Block", RFC 3738, 2093 DOI 10.17487/RFC3738, April 2004, 2094 . 2096 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 2097 Conrad, "Stream Control Transmission Protocol (SCTP) 2098 Partial Reliability Extension", RFC 3758, 2099 DOI 10.17487/RFC3758, May 2004, 2100 . 2102 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., 2103 and G. Fairhurst, Ed., "The Lightweight User Datagram 2104 Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 2105 2004, . 2107 [RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, 2108 "FLUTE - File Delivery over Unidirectional Transport", 2109 RFC 3926, DOI 10.17487/RFC3926, October 2004, 2110 . 2112 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2113 "SEcure Neighbor Discovery (SEND)", RFC 3971, 2114 DOI 10.17487/RFC3971, March 2005, 2115 . 2117 [RFC4324] Royer, D., Babics, G., and S. Mansour, "Calendar Access 2118 Protocol (CAP)", RFC 4324, DOI 10.17487/RFC4324, December 2119 2005, . 2121 [RFC4336] Floyd, S., Handley, M., and E. Kohler, "Problem Statement 2122 for the Datagram Congestion Control Protocol (DCCP)", 2123 RFC 4336, DOI 10.17487/RFC4336, March 2006, 2124 . 2126 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2127 Congestion Control Protocol (DCCP)", RFC 4340, 2128 DOI 10.17487/RFC4340, March 2006, 2129 . 2131 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 2132 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 2133 Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 2134 2006, . 2136 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 2137 Datagram Congestion Control Protocol (DCCP) Congestion 2138 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 2139 DOI 10.17487/RFC4342, March 2006, 2140 . 2142 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2143 Control Message Protocol (ICMPv6) for the Internet 2144 Protocol Version 6 (IPv6) Specification", RFC 4443, 2145 DOI 10.17487/RFC4443, March 2006, 2146 . 2148 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast 2149 Congestion Control (TFMCC): Protocol Specification", 2150 RFC 4654, DOI 10.17487/RFC4654, August 2006, 2151 . 2153 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 2154 Parameter for the Stream Control Transmission Protocol 2155 (SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007, 2156 . 2158 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2159 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 2160 . 2162 [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control 2163 (TFRC): The Small-Packet (SP) Variant", RFC 4828, 2164 DOI 10.17487/RFC4828, April 2007, 2165 . 2167 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 2168 "Authenticated Chunks for the Stream Control Transmission 2169 Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 2170 2007, . 2172 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2173 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2174 . 2176 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 2177 Kozuka, "Stream Control Transmission Protocol (SCTP) 2178 Dynamic Address Reconfiguration", RFC 5061, 2179 DOI 10.17487/RFC5061, September 2007, 2180 . 2182 [RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite 2183 protocol", RFC 5097, DOI 10.17487/RFC5097, January 2008, 2184 . 2186 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2187 (TLS) Protocol Version 1.2", RFC 5246, 2188 DOI 10.17487/RFC5246, August 2008, 2189 . 2191 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 2192 the Datagram Congestion Control Protocol (DCCP)", 2193 RFC 5238, DOI 10.17487/RFC5238, May 2008, 2194 . 2196 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 2197 Friendly Rate Control (TFRC): Protocol Specification", 2198 RFC 5348, DOI 10.17487/RFC5348, September 2008, 2199 . 2201 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 2202 DOI 10.17487/RFC5461, February 2009, 2203 . 2205 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 2206 (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, 2207 September 2009, . 2209 [RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol 2210 (DCCP) Simultaneous-Open Technique to Facilitate NAT/ 2211 Middlebox Traversal", RFC 5596, DOI 10.17487/RFC5596, 2212 September 2009, . 2214 [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 2215 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate 2216 Control for Small Packets (TFRC-SP)", RFC 5622, 2217 DOI 10.17487/RFC5622, August 2009, 2218 . 2220 [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding 2221 Transport (LCT) Building Block", RFC 5651, 2222 DOI 10.17487/RFC5651, October 2009, 2223 . 2225 [RFC5672] Crocker, D., Ed., "RFC 4871 DomainKeys Identified Mail 2226 (DKIM) Signatures -- Update", RFC 5672, 2227 DOI 10.17487/RFC5672, August 2009, 2228 . 2230 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 2231 "NACK-Oriented Reliable Multicast (NORM) Transport 2232 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 2233 . 2235 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 2236 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 2237 DOI 10.17487/RFC5775, April 2010, 2238 . 2240 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 2241 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 2242 . 2244 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 2245 Protocol Port Randomization", BCP 156, RFC 6056, 2246 DOI 10.17487/RFC6056, January 2011, 2247 . 2249 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 2250 Transport Layer Security (DTLS) for Stream Control 2251 Transmission Protocol (SCTP)", RFC 6083, 2252 DOI 10.17487/RFC6083, January 2011, 2253 . 2255 [RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the 2256 TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, 2257 January 2011, . 2259 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 2260 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 2261 DOI 10.17487/RFC6101, August 2011, 2262 . 2264 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 2265 Transmission Protocol (SCTP) Stream Reconfiguration", 2266 RFC 6525, DOI 10.17487/RFC6525, February 2012, 2267 . 2269 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2270 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2271 January 2012, . 2273 [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled 2274 Congestion Control for Multipath Transport Protocols", 2275 RFC 6356, DOI 10.17487/RFC6356, October 2011, 2276 . 2278 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 2279 Correction (FEC) Framework", RFC 6363, 2280 DOI 10.17487/RFC6363, October 2011, 2281 . 2283 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 2284 Yasevich, "Sockets API Extensions for the Stream Control 2285 Transmission Protocol (SCTP)", RFC 6458, 2286 DOI 10.17487/RFC6458, December 2011, 2287 . 2289 [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The 2290 NewReno Modification to TCP's Fast Recovery Algorithm", 2291 RFC 6582, DOI 10.17487/RFC6582, April 2012, 2292 . 2294 [RFC6584] Roca, V., "Simple Authentication Schemes for the 2295 Asynchronous Layered Coding (ALC) and NACK-Oriented 2296 Reliable Multicast (NORM) Protocols", RFC 6584, 2297 DOI 10.17487/RFC6584, April 2012, 2298 . 2300 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 2301 "FLUTE - File Delivery over Unidirectional Transport", 2302 RFC 6726, DOI 10.17487/RFC6726, November 2012, 2303 . 2305 [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A 2306 Datagram Congestion Control Protocol UDP Encapsulation for 2307 NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November 2308 2012, . 2310 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 2311 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 2312 DOI 10.17487/RFC6817, December 2012, 2313 . 2315 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 2316 "TCP Extensions for Multipath Operation with Multiple 2317 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 2318 . 2320 [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application 2321 Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, 2322 March 2013, . 2324 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 2325 UDP Checksums for Tunneled Packets", RFC 6935, 2326 DOI 10.17487/RFC6935, April 2013, 2327 . 2329 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 2330 for the Use of IPv6 UDP Datagrams with Zero Checksums", 2331 RFC 6936, DOI 10.17487/RFC6936, April 2013, 2332 . 2334 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 2335 Control Transmission Protocol (SCTP) Packets for End-Host 2336 to End-Host Communication", RFC 6951, 2337 DOI 10.17487/RFC6951, May 2013, 2338 . 2340 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 2341 IMMEDIATELY Extension for the Stream Control Transmission 2342 Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, 2343 . 2345 [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP 2346 Framework: Why RTP Does Not Mandate a Single Media 2347 Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2348 2014, . 2350 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2351 Protocol (HTTP/1.1): Message Syntax and Routing", 2352 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2353 . 2355 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2356 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2357 DOI 10.17487/RFC7231, June 2014, 2358 . 2360 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2361 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 2362 DOI 10.17487/RFC7232, June 2014, 2363 . 2365 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 2366 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 2367 RFC 7233, DOI 10.17487/RFC7233, June 2014, 2368 . 2370 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 2371 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 2372 RFC 7234, DOI 10.17487/RFC7234, June 2014, 2373 . 2375 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2376 Protocol (HTTP/1.1): Authentication", RFC 7235, 2377 DOI 10.17487/RFC7235, June 2014, 2378 . 2380 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 2381 "Transport Layer Security (TLS) Application-Layer Protocol 2382 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 2383 July 2014, . 2385 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 2386 Scheffenegger, Ed., "TCP Extensions for High Performance", 2387 RFC 7323, DOI 10.17487/RFC7323, September 2014, 2388 . 2390 [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. 2391 Zimmermann, "A Roadmap for Transmission Control Protocol 2392 (TCP) Specification Documents", RFC 7414, 2393 DOI 10.17487/RFC7414, February 2015, 2394 . 2396 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 2397 Known Attacks on Transport Layer Security (TLS) and 2398 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 2399 February 2015, . 2401 [RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, 2402 "Additional Policies for the Partially Reliable Stream 2403 Control Transmission Protocol Extension", RFC 7496, 2404 DOI 10.17487/RFC7496, April 2015, 2405 . 2407 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2408 "Recommendations for Secure Use of Transport Layer 2409 Security (TLS) and Datagram Transport Layer Security 2410 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2411 2015, . 2413 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 2414 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 2415 DOI 10.17487/RFC7540, May 2015, 2416 . 2418 [I-D.ietf-tsvwg-rfc5405bis] 2419 Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2420 Guidelines", draft-ietf-tsvwg-rfc5405bis-16 (work in 2421 progress), July 2016. 2423 [I-D.ietf-tsvwg-sctp-dtls-encaps] 2424 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 2425 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 2426 dtls-encaps-09 (work in progress), January 2015. 2428 [I-D.ietf-tsvwg-sctp-ndata] 2429 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 2430 "Stream Schedulers and User Message Interleaving for the 2431 Stream Control Transmission Protocol", draft-ietf-tsvwg- 2432 sctp-ndata-07 (work in progress), July 2016. 2434 [I-D.ietf-tsvwg-natsupp] 2435 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 2436 Transmission Protocol (SCTP) Network Address Translation 2437 Support", draft-ietf-tsvwg-natsupp-09 (work in progress), 2438 May 2016. 2440 [I-D.ietf-tcpm-cubic] 2441 Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and 2442 R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", 2443 draft-ietf-tcpm-cubic-02 (work in progress), August 2016. 2445 [I-D.ietf-rtcweb-transports] 2446 Alvestrand, H., "Transports for WebRTC", draft-ietf- 2447 rtcweb-transports-15 (work in progress), August 2016. 2449 [I-D.ietf-tls-tls13] 2450 Rescorla, E., "The Transport Layer Security (TLS) Protocol 2451 Version 1.3", draft-ietf-tls-tls13-14 (work in progress), 2452 July 2016. 2454 [XHR] van Kesteren, A., Aubourg, J., Song, J., and H. Steen, 2455 "XMLHttpRequest working draft 2456 (http://www.w3.org/TR/XMLHttpRequest/)", 2000. 2458 [REST] Fielding, R., "Architectural Styles and the Design of 2459 Network-based Software Architectures, Ph. D. (UC Irvine), 2460 Chapter 5: Representational State Transfer", 2000. 2462 [POSIX] 1-2008, IEEE., "IEEE Standard for Information Technology 2463 -- Portable Operating System Interface (POSIX) Base 2464 Specifications, Issue 7", n.d.. 2466 [MBMS] 3GPP TSG WS S4, ., "3GPP TS 26.346: Multimedia Broadcast/ 2467 Multicast Service (MBMS); Protocols and codecs, release 13 2468 (http://www.3gpp.org/DynaReport/26346.htm).", 2015. 2470 [ClarkArch] 2471 Clark, D. and D. Tennenhouse, "Architectural 2472 Considerations for a New Generation of Protocols (Proc. 2473 ACM SIGCOMM)", 1990. 2475 Authors' Addresses 2477 Godred Fairhurst (editor) 2478 University of Aberdeen 2479 School of Engineering, Fraser Noble Building 2480 Aberdeen AB24 3UE 2482 Email: gorry@erg.abdn.ac.uk 2484 Brian Trammell (editor) 2485 ETH Zurich 2486 Gloriastrasse 35 2487 8092 Zurich 2488 Switzerland 2490 Email: ietf@trammell.ch 2492 Mirja Kuehlewind (editor) 2493 ETH Zurich 2494 Gloriastrasse 35 2495 8092 Zurich 2496 Switzerland 2498 Email: mirja.kuehlewind@tik.ee.ethz.ch