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