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