idnits 2.17.1 draft-ietf-taps-transports-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 08, 2015) is 3063 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 4614 (Obsoleted by RFC 7414) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5672 (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 6093 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) -- Obsolete informational reference (is this intentional?): RFC 7053 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7232 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7233 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7234 (Obsoleted by RFC 9111) -- Obsolete informational reference (is this intentional?): RFC 7235 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-19) exists of draft-ietf-tsvwg-rfc5405bis-07 == Outdated reference: A later version (-08) exists of draft-ietf-aqm-ecn-benefits-07 == Outdated reference: A later version (-13) exists of draft-ietf-tsvwg-sctp-ndata-04 == Outdated reference: A later version (-16) exists of draft-ietf-tsvwg-sctp-failover-13 == Outdated reference: A later version (-23) exists of draft-ietf-tsvwg-natsupp-08 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 28 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Fairhurst, Ed. 3 Internet-Draft University of Aberdeen 4 Intended status: Informational B. Trammell, Ed. 5 Expires: June 10, 2016 M. Kuehlewind, Ed. 6 ETH Zurich 7 December 08, 2015 9 Services provided by IETF transport protocols and congestion control 10 mechanisms 11 draft-ietf-taps-transports-08 13 Abstract 15 This document describes transport services provided by existing IETF 16 protocols. It is designed to help application and network stack 17 programmers and to inform the work of the IETF TAPS Working Group. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 10, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Transport Service Features . . . . . . . . . . . . . . . . . 4 56 3.1. Congestion Control . . . . . . . . . . . . . . . . . . . 5 57 4. Existing Transport Protocols . . . . . . . . . . . . . . . . 6 58 4.1. Transport Control Protocol (TCP) . . . . . . . . . . . . 6 59 4.1.1. Protocol Description . . . . . . . . . . . . . . . . 6 60 4.1.2. Interface description . . . . . . . . . . . . . . . . 8 61 4.1.3. Transport Features . . . . . . . . . . . . . . . . . 8 62 4.2. Multipath TCP (MPTCP) . . . . . . . . . . . . . . . . . . 9 63 4.2.1. Protocol Description . . . . . . . . . . . . . . . . 9 64 4.2.2. Interface Description . . . . . . . . . . . . . . . . 9 65 4.2.3. Transport features . . . . . . . . . . . . . . . . . 10 66 4.3. Stream Control Transmission Protocol (SCTP) . . . . . . . 10 67 4.3.1. Protocol Description . . . . . . . . . . . . . . . . 11 68 4.3.2. Interface Description . . . . . . . . . . . . . . . . 13 69 4.3.3. Transport Features . . . . . . . . . . . . . . . . . 15 70 4.4. User Datagram Protocol (UDP) . . . . . . . . . . . . . . 16 71 4.4.1. Protocol Description . . . . . . . . . . . . . . . . 16 72 4.4.2. Interface Description . . . . . . . . . . . . . . . . 17 73 4.4.3. Transport Features . . . . . . . . . . . . . . . . . 18 74 4.5. Lightweight User Datagram Protocol (UDP-Lite) . . . . . . 18 75 4.5.1. Protocol Description . . . . . . . . . . . . . . . . 18 76 4.5.2. Interface Description . . . . . . . . . . . . . . . . 19 77 4.5.3. Transport Features . . . . . . . . . . . . . . . . . 19 78 4.6. Datagram Congestion Control Protocol (DCCP) . . . . . . . 20 79 4.6.1. Protocol Description . . . . . . . . . . . . . . . . 20 80 4.6.2. Interface Description . . . . . . . . . . . . . . . . 21 81 4.6.3. Transport Features . . . . . . . . . . . . . . . . . 22 82 4.7. Internet Control Message Protocol (ICMP) . . . . . . . . 22 83 4.7.1. Protocol Description . . . . . . . . . . . . . . . . 23 84 4.7.2. Interface Description . . . . . . . . . . . . . . . . 24 85 4.7.3. Transport Features . . . . . . . . . . . . . . . . . 24 86 4.8. Realtime Transport Protocol (RTP) . . . . . . . . . . . . 24 87 4.8.1. Protocol Description . . . . . . . . . . . . . . . . 24 88 4.8.2. Interface Description . . . . . . . . . . . . . . . . 25 89 4.8.3. Transport Features . . . . . . . . . . . . . . . . . 26 90 4.9. File Delivery over Unidirectional Transport/Asynchronous 91 Layered Coding Reliable Multicast (FLUTE/ALC) . . . . . . 26 92 4.9.1. Protocol Description . . . . . . . . . . . . . . . . 27 93 4.9.2. Interface Description . . . . . . . . . . . . . . . . 29 94 4.9.3. Transport Features . . . . . . . . . . . . . . . . . 29 95 4.10. NACK-Oriented Reliable Multicast (NORM) . . . . . . . . . 30 96 4.10.1. Protocol Description . . . . . . . . . . . . . . . . 30 97 4.10.2. Interface Description . . . . . . . . . . . . . . . 31 98 4.10.3. Transport Features . . . . . . . . . . . . . . . . . 31 99 4.11. Transport Layer Security (TLS) and Datagram TLS (DTLS) as 100 a pseudotransport . . . . . . . . . . . . . . . . . . . . 32 101 4.11.1. Protocol Description . . . . . . . . . . . . . . . . 32 102 4.11.2. Interface Description . . . . . . . . . . . . . . . 33 103 4.11.3. Transport Features . . . . . . . . . . . . . . . . . 34 104 4.12. Hypertext Transport Protocol (HTTP) over TCP as a 105 pseudotransport . . . . . . . . . . . . . . . . . . . . . 35 106 4.12.1. Protocol Description . . . . . . . . . . . . . . . . 35 107 4.12.2. Interface Description . . . . . . . . . . . . . . . 36 108 4.12.3. Transport features . . . . . . . . . . . . . . . . . 37 109 5. Transport Service Features . . . . . . . . . . . . . . . . . 37 110 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 111 7. Security Considerations . . . . . . . . . . . . . . . . . . . 41 112 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41 113 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 114 10. Informative References . . . . . . . . . . . . . . . . . . . 42 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 117 1. Introduction 119 Internet applications make use of the Services provided by a 120 Transport protocol, such as TCP (a reliable, in-order stream 121 protocol) or UDP (an unreliable datagram protocol). We use the term 122 "Transport Service" to mean the end-to-end service provided to an 123 application by the transport layer. That service can only be 124 provided correctly if information about the intended usage is 125 supplied from the application. The application may determine this 126 information at design time, compile time, or run time, and may 127 include guidance on whether a feature is required, a preference by 128 the application, or something in between. Examples of features of 129 Transport Services are reliable delivery, ordered delivery, content 130 privacy to in-path devices, and integrity protection. 132 The IETF has defined a wide variety of transport protocols beyond TCP 133 and UDP, including SCTP, DCCP, MP-TCP, and UDP-Lite. Transport 134 services may be provided directly by these transport protocols, or 135 layered on top of them using protocols such as WebSockets (which runs 136 over TCP), RTP (over TCP or UDP) or WebRTC data channels (which run 137 over SCTP over DTLS over UDP or TCP). Services built on top of UDP 138 or UDP-Lite typically also need to specify additional mechanisms, 139 including a congestion control mechanism (such as NewReno, TFRC or 140 LEDBAT). This extends the set of available Transport Services beyond 141 those provided to applications by TCP and UDP. 143 2. Terminology 145 The following terms are defined throughout this document, and in 146 subsequent documents produced by TAPS describing the composition and 147 decomposition of transport services. 149 Transport Service Feature: a specific end-to-end feature that a 150 transport service provides to its clients. Examples include 151 confidentiality, reliable delivery, ordered delivery, message- 152 versus-stream orientation, etc. 154 Transport Service: a set of transport service features, without an 155 association to any given framing protocol, which provides a 156 complete service to an application. 158 Transport Protocol: an implementation that provides one or more 159 different transport services using a specific framing and header 160 format on the wire. 162 Transport Protocol Component: an implementation of a transport 163 service feature within a protocol. 165 Transport Service Instance: an arrangement of transport protocols 166 with a selected set of features and configuration parameters that 167 implements a single transport service, e.g., a protocol stack (RTP 168 over UDP). 170 Application: an entity that uses the transport layer for end-to-end 171 delivery data across the network (this may also be an upper layer 172 protocol or tunnel encapsulation). 174 3. Transport Service Features 176 Transport protocols can be differentiated by the features of the 177 services they provide. 179 One fundamental feature is whether a transport offers a service that 180 divides the data into transmission units based on network packets 181 (known as a Datagram service), or whether it combines and segments 182 data across multiple packets (e.g., the Stream service provided by 183 TCP). 185 Another fundamental feature is whether a transport requires a control 186 exchange across the network at setup (e.g., TCP), or whether it 187 connection-less (e.g., UDP). 189 A transport service can also offer reliability, for instance, SCTP 190 offers a message-based service providing full or partial reliability 191 and allowing to minimize the head of line blocking due to the support 192 of unordered and unordered message delivery within multiple streams, 193 UDP-Lite and DCCP provide partial integrity protection. 195 A transport service can provide congestion control (see Section 3.1). 196 TCP and SCTP provide congestion control for use in the Internet, 197 whereas UDP leaves this function to the upper layer protocol that 198 uses UDP. DCCP offers a range of congestion control approaches and 199 LEDBAT can support low-priority "scavenger" communication, intending 200 to defer use of capacity to other Internet flows sharing a congested 201 bottleneck. 203 Transport services may be unidirectional or bidirectional, to a 204 single a single endpoint, to one of multiple endpoints, or multicast 205 simultaneously to multiple endpoints. 207 The service offered by transport protocols and frameworks can also be 208 differentiated in many other ways. 210 3.1. Congestion Control 212 Congestion control is critical to the stable operation of the 213 Internet, applications and other protocols that choose to use a 214 datagram protocol (e.g., UDP or UDP-Lite) need to employ mechanisms 215 to prevent congestion collapse and to establish some degree of 216 fairness with concurrent traffic. 218 A variety of techniques are used to provide congestion control in the 219 Internet. Each technique requires that the protocol provide a method 220 for deriving the metric the congestion control algorithm uses to 221 detect congestion and the property of a packet it uses to determine 222 when to send. Given these relatively wide constraints, the 223 congestion control techniques that can be applied by different 224 transport protocols are largely orthogonal to the choice of transport 225 protocols themselves. This section provides an overview of the 226 congestion control techniques available to the protocols described in 227 Section 4. 229 Most commonly deployed congestion control mechanisms use one of three 230 mechanisms to detect congestion: 232 o detection of loss, which is interpreted as a congestion signal; 234 o Explicit Congestion Notification (ECN) [RFC3168] to provide 235 explicit signaling of congestion without inducing loss (see 236 [I-D.ietf-aqm-ecn-benefits]); and/or 238 o a retransmission timer with exponential back-off. 240 Protocols such as SCTP and TCP [RFC5681] that use sliding-window- 241 based receiver flow control commonly use a separate congestion window 242 for congestion control. Each time congestion is detected, this 243 separate congestion window is reduced. Data in flight is capped to 244 the minimum of the two windows. This approach is also used by DCCP 245 CCID-2 for datagram congestion control. 247 Rate-based methods have also been defined based on the loss ratio and 248 observed round trip time, such as TFRC [RFC5348] and TFRC-SP 249 [RFC4828]. These methods utlise a throughput equation to determine 250 the maximum acceptable rate. Such methods are used with DCCP CCID-3 251 [RFC4342] and CCID-4 [RFC5622], WEBRC [RFC3738], and other 252 applications. 254 In addition, a congestion control mechanism may react to changes in 255 delay as an indication for congestion. Delay-based congestion 256 detection methods tend to induce less loss than loss-based methods, 257 and therefore generally do not compete well with them across shared 258 bottleneck links. However, such methods, such as LEDBAT [RFC6824], 259 are are deployed in the Internet for scavenger traffic, which will 260 use unused capacity but readily yield to presumably interactive or 261 otherwise higher-priority, loss-based congestion-controlled traffic. 263 4. Existing Transport Protocols 265 This section provides a list of known IETF transport protocols and 266 transport protocol frameworks. It does not make an assessment about 267 whether specific implementations of protocols are fully compliant to 268 current IETF specifications. 270 4.1. Transport Control Protocol (TCP) 272 TCP is an IETF standards track transport protocol. [RFC0793] 273 introduces TCP as follows: "The Transmission Control Protocol (TCP) 274 is intended for use as a highly reliable host-to-host protocol 275 between hosts in packet-switched computer communication networks, and 276 in interconnected systems of such networks." Since its introduction, 277 TCP has become the default connection- oriented, stream-based 278 transport protocol in the Internet. It is widely implemented by 279 endpoints and widely used by common applications. 281 4.1.1. Protocol Description 283 TCP is a connection-oriented protocol, providing a three way 284 handshake to allow a client and server to set up a connection and 285 negotiate features, and mechanisms for orderly completion and 286 immediate teardown of a connection. TCP is defined by a family of 287 RFCs [RFC4614]. 289 TCP provides multiplexing to multiple sockets on each host using port 290 numbers. A similar approach is adopted by other IETF-defined 291 transports. An active TCP session is identified by its four-tuple of 292 local and remote IP addresses and local port and remote port numbers. 293 The destination port during connection setup is often used to 294 indicate the requested service. 296 TCP partitions a continuous stream of bytes into segments, sized to 297 fit in IP packets. ICMP-based Path MTU discovery [RFC1191][RFC1981] 298 as well as Packetization Layer Path MTU Discovery (PMTUD) [RFC4821] 299 have been defined by the IETF. 301 Each byte in the stream is identified by a sequence number. The 302 sequence number is used to order segments on receipt, to identify 303 segments in acknowledgments, and to detect unacknowledged segments 304 for retransmission. This is the basis of the reliable, ordered 305 delivery of data in a TCP stream. TCP Selective Acknowledgment 306 [RFC2018] extends this mechanism by making it possible to identify 307 missing segments more precisely, reducing spurious retransmission. 309 Receiver flow control is provided by a sliding window: limiting the 310 amount of unacknowledged data that can be outstanding at a given 311 time. The window scale option [RFC7323] allows a receiver to use 312 windows greater than 64KB. 314 TCP provides congestion control [RFC5681], described further in 315 Section 3.1 below. 317 TCP protocol instances can be extended [RFC4614] and tuned. Some 318 features are sender-side only, requiring no negotiation with the 319 receiver; some are receiver-side only, some are explicitly negotiated 320 during connection setup. 322 By default, TCP segment partitioning uses Nagle's algorithm [RFC0896] 323 to buffer data at the sender into large segments, potentially 324 incurring sender-side buffering delay; this algorithm can be disabled 325 by the sender to transmit more immediately, e.g., to reduce latency 326 for interactive sessions. 328 TCP provides an "urgent data" function for limited out-of-order 329 delivery of the data. This function is deprecated [RFC6093]. 331 A mandatory checksum provides a basic integrity check against 332 misdelivery and data corruption over the entire packet. Applications 333 that require end to end integrity of data are recommended to include 334 a stronger integrity check of their payload data. The TCP checksum 335 does not support partial corruption protection (as in DCCP/UDP-Lite). 337 TCP supports only unicast connections. 339 4.1.2. Interface description 341 A User/TCP Interface is defined in [RFC0793] providing six user 342 commands: Open, Send, Receive, Close, Status. This interface does 343 not describe configuration of TCP options or parameters beside use of 344 the PUSH and URGENT flags. 346 [RFC1122] describes extensions of the TCP/application layer interface 347 for: 349 o reporting soft errors such as reception of ICMP error messages, 350 extensive retransmission or urgent pointer advance, 352 o providing a possibility to specify the Differentiated Services 353 Code Point (DSCP) (formerly, the Type-of-Service, TOS) for 354 segments, 356 o providing a flush call to empty the TCP send queue, and 358 o multihoming support. 360 In API implementations derived from the BSD Sockets API, TCP sockets 361 are created using the "SOCK_STREAM" socket type as described in the 362 IEEE Portable Operating System Interface (POSIX) Base Specifications 363 [POSIX]. The features used by a protocol instance may be set and 364 tuned via this API. There are current no documents in the RFC Series 365 that describe this interface. 367 4.1.3. Transport Features 369 The transport features provided by TCP are: 371 o unicast transport 373 o connection setup with feature negotiation and application-to-port 374 mapping, implemented using SYN segments and the TCP option field 375 to negotiate features. 377 o port multiplexing: each TCP session is uniquely identified by a 378 combination of the ports and IP address fields. 380 o Uni-or bidirectional communication. 382 o stream-oriented delivery in a single stream. 384 o fully reliable delivery, implemented using ACKs sent from the 385 receiver to confirm delivery. 387 o error detection: a segment checksum verifies delivery to the 388 correct endpoint and integrity of the data and options. 390 o segmentation: packets are fragmented to a negotiated maximum 391 segment size, further constrained by the effective MTU from PMTUD. 393 o data bundling, an optional mechanism that uses Nagle's algorithm 394 to coalesce data sent within the same RTT into full-sized 395 segments. 397 o flow control using a window-based mechanism, where the receiver 398 advertises the window that it is willing to buffer. 400 o congestion control: a window-based method that uses Additive 401 Increase Multiplicative Decrease (AIMD) to control the sending 402 rate and to conservatively choose a rate after congestion is 403 detected. 405 4.2. Multipath TCP (MPTCP) 407 Multipath TCP [RFC6824] is an extension for TCP to support multi- 408 homing. It is designed to be as transparent as possible to middle- 409 boxes. It does so by establishing regular TCP flows between a pair 410 of source/destination endpoints, and multiplexing the application's 411 stream over these flows. 413 4.2.1. Protocol Description 415 MPTCP uses TCP options for its control plane. They are used to 416 signal multipath capabilities, as well as to negotiate data sequence 417 numbers, and advertise other available IP addresses and establish new 418 sessions between pairs of endpoints. 420 4.2.2. Interface Description 422 By default, MPTCP exposes the same interface as TCP to the 423 application. [RFC6897] however describes a richer API for MPTCP- 424 aware applications. 426 This Basic API describes how an application can: 428 o enable or disable MPTCP. 430 o bind a socket to one or more selected local endpoints. 432 o query local and remote endpoint addresses. 434 o get a unique connection identifier (similar to an address-port 435 pair for TCP). 437 The document also recommends the use of extensions defined for SCTP 438 [RFC6458] (see next section) to support multihoming. 440 4.2.3. Transport features 442 As an extension to TCP, MPTCP provides mostly the same features. By 443 establishing multiple sessions between available endpoints, it can 444 additionally provide soft failover solutions should one of the paths 445 become unusable. In addition, by multiplexing one byte stream over 446 separate paths, it can achieve a higher throughput than TCP in 447 certain situations. Note, however, that coupled congestion control 448 [RFC6356] might limit this benefit to maintain fairness to other 449 flows at the bottleneck. When aggregating capacity over multiple 450 paths, and depending on the way packets are scheduled on each TCP 451 subflow, an additional delay and higher jitter might be observed 452 observed before in-order delivery of data to the applications. 454 The transport features provided by MPTCP in addition to TCP therefore 455 are: 457 o congestion control with load balancing over multiple connections. 459 o endpoint multiplexing of a single byte stream (higher throughput). 461 o address family multiplexing: sub-flows can be started over IPv4 or 462 IPv6 for the same session. 464 o resilience to network failure and/or handover. 466 4.3. Stream Control Transmission Protocol (SCTP) 468 SCTP is a message-oriented IETF standards track transport protocol. 469 The base protocol is specified in [RFC4960]. It supports multi- 470 homing and path failover to provide resilience to path failures. An 471 SCTP association has multiple streams in each direction, providing 472 in-sequence delivery of user messages within each stream. This 473 allows it to minimize head of line blocking. SCTP supports multiple 474 stream scheduling schemes controlling stream multiplexing, including 475 priority and fair weighting schemes. 477 SCTP is extensible. Currently defined extensions include mechanisms 478 for dynamic re-configuration of streams [RFC6525] and IP addresses 480 [RFC5061]. Furthermore, the extension specified in [RFC3758] 481 introduces the concept of partial reliability for user messages. 483 SCTP was originally developed for transporting telephony signalling 484 messages and is deployed in telephony signalling networks, especially 485 in mobile telephony networks. It can also be used for other 486 services, for example in the WebRTC framework for data channels. It 487 is therefore deployed in all Web browsers supporting WebRTC. 489 4.3.1. Protocol Description 491 SCTP is a connection-oriented protocol using a four way handshake to 492 establish an SCTP association, and a three way message exchange to 493 gracefully shut it down. It uses the same port number concept as 494 DCCP, TCP, UDP, and UDP-Lite. SCTP only supports unicast. 496 SCTP uses the 32-bit CRC32c for protecting SCTP packets against bit 497 errors and misdelivery of packets to an unintended endpoint. This is 498 stronger than the 16-bit checksums used by TCP or UDP. However, 499 partial checksum coverage as provided by DCCP or UDP-Lite is not 500 supported. 502 SCTP has been designed with extensibility in mind. Each SCTP packet 503 starts with a single common header containing the port numbers, a 504 verification tag and the CRC32c checksum. This common header is 505 followed by a sequence of chunks. Each chunk consists of a type 506 field, flags, a length field and a value. [RFC4960] defines how a 507 receiver processes chunks with an unknown chunk type. The support of 508 extensions can be negotiated during the SCTP handshake. 510 SCTP provides a message-oriented service. Multiple small user 511 messages can be bundled into a single SCTP packet to improve 512 efficiency. For example, this bundling may be done by delaying user 513 messages at the sender, similar to Nagle's algorithm used by TCP. 514 User messages which would result in IP packets larger than the MTU 515 will be fragmented at the sender and reassembled at the receiver. 516 There is no protocol limit on the user message size. ICMP-based path 517 MTU discovery as specified for IPv4 in [RFC1191] and for IPv6 in 518 [RFC1981] as well as packetization layer path MTU discovery as 519 specified in [RFC4821] with probe packets using the padding chunks 520 defined in [RFC4820] are supported. 522 [RFC4960] specifies TCP-friendly congestion control to protect the 523 network against overload; see Section 3.1 for more. SCTP also uses 524 sliding window flow control to protect receivers against overflow. 525 Similar to TCP, SCTP also supports delaying acknowledgments. 526 [RFC7053] provides a way for the sender of user messages to request 527 the immediate sending of the corresponding acknowledgments. 529 Each SCTP association has between 1 and 65536 uni-directional streams 530 in each direction. The number of streams can be different in each 531 direction. Every user message is sent on a particular stream. User 532 messages can be sent un- ordered, or ordered upon request by the 533 upper layer. Un-ordered messages can be delivered as soon as they 534 are completely received. Ordered messages sent on the same stream 535 are delivered at the receiver in the same order as sent by the 536 sender. For user messages not requiring fragmentation, this 537 minimizes head of line blocking. 539 The base protocol defined in [RFC4960] does not allow interleaving of 540 user- messages. Large messages on one stream can therefore block the 541 sending of user messages on other streams. 542 [I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation. This draft 543 also specifies multiple algorithms for the sender side selection of 544 which streams to send data from, supporting a variety of scheduling 545 algorithms including priority based methods. The stream re- 546 configuration extension defined in [RFC6525] allows streams to be 547 reset during the lifetime of an association and to increase the 548 number of streams, if the number of streams negotiated in the SCTP 549 handshake becomes insufficient. 551 Each user message sent is either delivered to the receiver or, in 552 case of excessive retransmissions, the association is terminated in a 553 non-graceful way [RFC4960], similar to TCP behaviour. In addition to 554 this reliable transfer, the partial reliability extension [RFC3758] 555 allows a sender to abandon user messages. The application can 556 specify the policy for abandoning user messages. Examples of these 557 policies defined in [RFC3758] and [RFC7496] are: 559 o Limiting the time a user message is dealt with by the sender. 561 o Limiting the number of retransmissions for each fragment of a user 562 message. If the number of retransmissions is limited to 0, one 563 gets a service similar to UDP. 565 o Abandoning messages of lower priority in case of a send buffer 566 shortage. 568 SCTP supports multi-homing. Each SCTP endpoint uses a list of IP- 569 addresses and a single port number. These addresses can be any 570 mixture of IPv4 and IPv6 addresses. These addresses are negotiated 571 during the handshake and the address re-configuration extension 572 specified in [RFC5061] in combination with [RFC4895] can be used to 573 change these addresses in an authenticated way during the livetime of 574 an SCTP association. This allows for transport layer mobility. 575 Multiple addresses are used for improved resilience. If a remote 576 address becomes unreachable, the traffic is switched over to a 577 reachable one, if one exists. [I-D.ietf-tsvwg-sctp-failover] 578 specifies a quicker failover operation reducing the latency of the 579 failover. 581 For securing user messages, the use of TLS over SCTP has been 582 specified in [RFC3436]. However, this solution does not support all 583 services provided by SCTP, such as un-ordered delivery or partial 584 reliability. Therefore, the use of DTLS over SCTP has been specified 585 in [RFC6083] to overcome these limitations. When using DTLS over 586 SCTP, the application can use almost all services provided by SCTP. 588 [I-D.ietf-tsvwg-natsupp] defines methods for endpoints and 589 middleboxes to provide support NAT for SCTP over IPv4. For legacy 590 NAT traversal, [RFC6951] defines the UDP encapsulation of SCTP- 591 packets. Alternatively, SCTP packets can be encapsulated in DTLS 592 packets as specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. The 593 latter encapsulation is used within the WebRTC context. 595 SCTP has a well-defined API, described in the next subsection. 597 4.3.2. Interface Description 599 [RFC4960] defines an abstract API for the base protocol. This API 600 describes the following functions callable by the upper layer of 601 SCTP: Initialize, Associate, Send, Receive, Receive Unsent Message, 602 Receive Unacknowledged Message, Shutdown, Abort, SetPrimary, Status, 603 Change Heartbeat, Request Heartbeat, Get SRTT Report, Set Failure 604 Threshold, Set Protocol Parameters, and Destroy. The following 605 notifications are provided by the SCTP stack to the upper layer: 606 COMMUNICATION UP, DATA ARRIVE, SHUTDOWN COMPLETE, COMMUNICATION LOST, 607 COMMUNICATION ERROR, RESTART, SEND FAILURE, NETWORK STATUS CHANGE. 609 An extension to the BSD Sockets API is defined in [RFC6458] and 610 covers: 612 o the base protocol defined in [RFC4960]. The API allows control 613 over local addresses and port numbers and the primary path. 614 Furthermore the application has fine control about parameters like 615 retransmission thresholds, the path supervision parameters, the 616 delayed acknowledgment timeout, and the fragmentation point. The 617 API provides a mechanism to allow the SCTP stack to notify the 618 application about event if the application has requested them. 619 These notifications provide Information about status changes of 620 the association and each of the peer addresses. In case of send 621 failures, including drop of messages sent unreliably, the 622 application can also be notified and user messages can be returned 623 to the application. When sending user messages, the stream id, a 624 payload protocol identifier, an indication whether ordered 625 delivery is requested or not. These parameters can also be 626 provided on message reception. Additionally a context can be 627 provided when sending, which can be use in case of send failures. 628 The sending of arbitrary large user messages is supported. 630 o the SCTP Partial Reliability extension defined in [RFC3758] to 631 specify for a user message the PR-SCTP policy and the policy 632 specific parameter. 634 o the SCTP Authentication extension defined in [RFC4895] allowing to 635 manage the shared keys, the HMAC to use, set the chunk types which 636 are only accepted in an authenticated way, and get the list of 637 chunks which are accepted by the local and remote end point in an 638 authenticated way. 640 o the SCTP Dynamic Address Reconfiguration extension defined in 641 [RFC5061]. It allows to manually add and delete local addresses 642 for SCTP associations and the enabling of automatic address 643 addition and deletion. Furthermore the peer can be given a hint 644 for choosing its primary path. 646 For the following SCTP protocol extensions the BSD Sockets API 647 extension is defined in the document specifying the protocol 648 extensions: 650 o the SCTP Stream Reconfiguration extension defined in [RFC6525]. 651 The API allows to trigger the reset operation for incoming and 652 outgoing streams and the whole association. It provides also a 653 way to notify the association about the corresponding events. 654 Furthermore the application can increase the number of streams. 656 o the UDP Encapsulation of SCTP packets extension defined in 657 [RFC6951]. The API allows the management of the remote UDP 658 encapsulation port. 660 o the SCTP SACK-IMMEDIATELY extension defined in [RFC7053]. The API 661 allows the sender of a user message to request the receiver to 662 send the corresponding acknowledgment immediately. 664 o the additional PR-SCTP policies defined in [RFC7496]. The API 665 allows to enable/disable the PR-SCTP extension, choose the PR-SCTP 666 policies defined in the document and provide statistical 667 information about abandoned messages. 669 Future documents describing SCTP protocol extensions are expected to 670 describe the corresponding BSD Sockets API extension in a "Socket API 671 Considerations" section. 673 The SCTP socket API supports two kinds of sockets: 675 o one-to-one style sockets (by using the socket type "SOCK_STREAM"). 677 o one-to-many style socket (by using the socket type 678 "SOCK_SEQPACKET"). 680 One-to-one style sockets are similar to TCP sockets, there is a 1:1 681 relationship between the sockets and the SCTP associations (except 682 for listening sockets). One-to-many style SCTP sockets are similar 683 to unconnected UDP sockets, where there is a 1:n relationship between 684 the sockets and the SCTP associations. 686 The SCTP stack can provide information to the applications about 687 state changes of the individual paths and the association whenever 688 they occur. These events are delivered similar to user messages but 689 are specifically marked as notifications. 691 New functions have been introduced to support the use of multiple 692 local and remote addresses. Additional SCTP-specific send and 693 receive calls have been defined to permit SCTP-specific information 694 to be sent without using ancillary data in the form of additional 695 cmsgs. These functions provide support for detecting partial 696 delivery of user messages and notifications. 698 The SCTP socket API allows a fine-grained control of the protocol 699 behaviour through an extensive set of socket options. 701 The SCTP kernel implementations of FreeBSD, Linux and Solaris follow 702 mostly the specified extension to the BSD Sockets API for the base 703 protocol and the corresponding supported protocol extensions. 705 4.3.3. Transport Features 707 The transport features provided by SCTP are: 709 o unicast. 711 o connection setup with feature negotiation and application-to-port 712 mapping. 714 o port multiplexing. 716 o Uni-or bidirectional communication. 718 o message-oriented delivery supporting multiple concurrent streams. 720 o fully reliable, partially reliable, or unreliable delivery. 722 o ordered and unordered delivery within a stream. 724 o user message fragmentation and reassembly. 726 o support for stream scheduling prioritization. 728 o user message bundling. 730 o flow control using a window-based mechanism. 732 o congestion control using methods similar to TCP. 734 o strong error/misdelivery detection (CRC32c). 736 o transport layer multihoming for resilience. 738 o transport layer mobility. 740 o resilience to network failure and/or handover. 742 4.4. User Datagram Protocol (UDP) 744 The User Datagram Protocol (UDP) [RFC0768] [RFC2460] is an IETF 745 standards track transport protocol. It provides a unidirectional 746 datagram protocol that preserves message boundaries. It provides no 747 error correction,congestion control, or flow control. It can be used 748 to send broadcast datagrams (IPv4) or multicast datagrams (IPv4 and 749 IPv6), in addition to unicast and anycast datagrams. IETF guidance 750 on the use of UDP is provided in {{I-D.ietf-tsvwg- rfc5405bis}}. UDP 751 is widely implemented and widely used by common applications, 752 including DNS. 754 4.4.1. Protocol Description 756 UDP is a connection-less protocol that maintains message boundaries, 757 with no connection setup or feature negotiation. The protocol uses 758 independent messages, ordinarily called datagrams. Each stream of 759 messages is independently managed, therefore retransmission does not 760 hold back data sent using other logical streams. It provides 761 detection of payload errors and misdelivery of packets to an 762 unintended endpoint, either of which result in discard of received 763 datagrams, with no indication to the user of the service. 765 It is possible to create IPv4 UDP datagrams with no checksum, and 766 while this is generally discouraged [RFC1122] 767 [I-D.ietf-tsvwg-rfc5405bis], certain special cases permit this use. 768 These datagrams rely on the IPv4 header checksum to protect from 769 misdelivery to an unintended endpoint. IPv6 does not by permit UDP 770 datagrams with no checksum, although in certain cases this rule may 771 be relaxed [RFC6935]. The checksum support considerations for 772 omitting the checksum are defined in [RFC6936]. 774 UDP does not provide reliability and does not provide retransmission. 775 This implies messages may be re-ordered, lost, or duplicated in 776 transit. Note that due to the relatively weak form of checksum used 777 by UDP, applications that require end to end integrity of data are 778 recommended to include a stronger integrity check of their payload 779 data. 781 Because UDP provides no flow control, a receiving application that is 782 unable to run sufficiently fast, or frequently, may miss messages. 783 The lack of congestion handling implies UDP traffic may experience 784 loss when using an overloaded path, and may cause the loss of 785 messages from other protocols (e.g., TCP) when sharing the same 786 network path. 788 On transmission, UDP encapsulates each datagram into an IP packet, 789 which may in turn be fragmented by IP. Fragments are reassembled 790 before delivery to the UDP receiver. 792 Applications that need to provide fragmentation or that have other 793 requirements such as receiver flow control, congestion control, 794 PathMTU discovery/PLPMTUD, support for ECN, etc need these to be 795 provided by protocols operating over UDP [I-D.ietf-tsvwg-rfc5405bis]. 797 4.4.2. Interface Description 799 [RFC0768] describes basic requirements for an API for UDP. Guidance 800 on use of common APIs is provided in [I-D.ietf-tsvwg-rfc5405bis]. 802 A UDP endpoint consists of a tuple of (IP address, port number). 803 Demultiplexing using multiple abstract endpoints (sockets) on the 804 same IP address are supported. The same socket may be used by a 805 single server to interact with multiple clients (note: this behavior 806 differs from TCP, which uses a pair of tuples to identify a 807 connection). Multiple server instances (processes) that bind the 808 same socket can cooperate to service multiple clients- the socket 809 implementation arranges to not duplicate the same received unicast 810 message to multiple server processes. 812 Many operating systems also allow a UDP socket to be "connected", 813 i.e., to bind a UDP socket to a specific (remote) UDP endpoint. 814 Unlike TCP's connect primitive, for UDP, this is only a local 815 operation that serves to simplify the local send/receive functions 816 and to filter the traffic for the specified addresses and ports 817 [I-D.ietf-tsvwg-rfc5405bis]. 819 4.4.3. Transport Features 821 The transport features provided by UDP are: 823 o unicast. 825 o multicast, anycast, or IPv4 broadcast. 827 o port multiplexing. A receiving port can be configured to receive 828 datagrams from multiple senders. 830 o message-oriented delivery. 832 o Uni-or bidirectional communication. Transmission in each 833 direction is independent. 835 o non-reliable delivery. 837 o non-ordered delivery. 839 o error detection: a segment checksum verifies delivery to the 840 correct endpoint and integrity of the data. This checksum is 841 optional for IPv4, and optional under specific conditions for IPv6 842 where all or none of the payload data is protected. 844 o IPv6 jumbograms. 846 4.5. Lightweight User Datagram Protocol (UDP-Lite) 848 The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] is an 849 IETF standards track transport protocol. It provides a 850 unidirectional, datagram protocol that preserves message boundaries. 851 IETF guidance on the use of UDP- Lite is provided in 852 [I-D.ietf-tsvwg-rfc5405bis]. 854 4.5.1. Protocol Description 856 Like UDP, UDP-Lite is a connection-less datagram protocol, with no 857 connection setup or feature negotiation. It changes the semantics of 858 the UDP "payload length" field to that of a "checksum coverage 859 length" field, and is identified by a different IP protocol/next- 860 header value. Otherwise, UDP-Lite is semantically identical to UDP. 861 Applications using UDP-Lite therefore cannot make assumptions 862 regarding the correctness of the data received in the insensitive 863 part of the UDP-Lite payload. 865 In the same way as for UDP, mechanisms for receiver flow control, 866 congestion control, PMTU or PLPMTU discovery, support for ECN, etc 867 need to be provided by upper layer protocols 868 [I-D.ietf-tsvwg-rfc5405bis]. 870 Examples of use include a class of applications that can derive 871 benefit from having partially-damaged payloads delivered, rather than 872 discarded. One use is to support error tolerate payload corruption 873 when used over paths that include error-prone links, another 874 application is when header integrity checks are required, but payload 875 integrity is provided by some other mechanism (e.g., [RFC6936]). 877 A UDP-Lite service may support IPv4 broadcast, multicast, anycast and 878 unicast, and IPv6 multicast, anycast and unicast. 880 4.5.2. Interface Description 882 There is no API currently specified in the RFC Series, but guidance 883 on use of common APIs is provided in [I-D.ietf-tsvwg-rfc5405bis]. 885 The interface of UDP-Lite differs from that of UDP by the addition of 886 a single (socket) option that communicates a checksum coverage length 887 value: at the sender, this specifies the intended checksum coverage, 888 with the remaining unprotected part of the payload called the "error- 889 insensitive part". The checksum coverage may also be made visible to 890 the application via the UDP-Lite MIB module [RFC5097]. 892 4.5.3. Transport Features 894 The transport features provided by UDP-Lite are: 896 o unicast. 898 o multicast, anycast, or IPv4 broadcast. 900 o port multiplexing (as for UDP). 902 o message-oriented delivery (as for UDP). 904 o Uni-or bidirectional communication. Transmission in each 905 direction is independent. 907 o non-reliable delivery (as for UDP). 909 o non-ordered delivery (as for UDP). 911 o misdelivery detection (the checksum always provides protection 912 from misdelivery). 914 o partial or full integrity protection. The checksum coverage field 915 indicates the size of the payload data covered by the checksum. 917 4.6. Datagram Congestion Control Protocol (DCCP) 919 Datagram Congestion Control Protocol (DCCP) [RFC4340] is an IETF 920 standards track bidirectional transport protocol that provides 921 unicast connections of congestion-controlled messages without 922 providing reliability. 924 The DCCP Problem Statement describes the goals that DCCP sought to 925 address [RFC4336]. It is suitable for applications that transfer 926 fairly large amounts of data and that can benefit from control over 927 the trade off between timeliness and reliability [RFC4336]. 929 DCCP offers low overhead, and many characteristics common to UDP, but 930 can avoid "re-inventing the wheel" each time a new multimedia 931 application emerges. Specifically it includes core functions 932 (feature negotiation, path state management, RTT calculation, PMTUD, 933 etc): This allows applications to use a compatible method defining 934 how they send packets and where suitable to choose common algorithms 935 to manage their functions. Examples of suitable applications include 936 interactive applications, streaming media or on-line games [RFC4336]. 938 4.6.1. Protocol Description 940 DCCP is a connection-oriented datagram protocol, providing a three- 941 way handshake to allow a client and server to set up a connection, 942 and mechanisms for orderly completion and immediate teardown of a 943 connection. The protocol is defined by a family of RFCs. 945 It provides multiplexing to multiple sockets at each endpoint using 946 port numbers. An active DCCP session is identified by its four-tuple 947 of local and remote IP addresses and local port and remote port 948 numbers. At connection setup, DCCP also exchanges the service code 949 [RFC5595], a mechanism that allows transport instantiations to 950 indicate the service treatment that is expected from the network. 952 The protocol segments data into messages, typically sized to fit in 953 IP packets, but which may be fragmented providing they are less than 954 the maximum packet size. A DCCP interface allows applications to 955 request fragmentation for packets larger than PMTU, but not larger 956 than the maximum packet size allowed by the current congestion 957 control mechanism (CCMPS) [RFC4340]. 959 Each message is identified by a sequence number. The sequence number 960 is used to identify segments in acknowledgments, to detect 961 unacknowledged segments, to measure RTT, etc. The protocol may 962 support ordered or unordered delivery of data, and does not itself 963 provide retransmission. DCCP supports reduced checksum coverage, a 964 partial integrity mechanism similar to UDP-Lite. There is also a 965 Data Checksum option that when enabled, contains a strong CRC, to 966 enable endpoints to detect application data corruption - similar to 967 SCTP. 969 Receiver flow control is supported, which limits the amount of 970 unacknowledged data that can be outstanding at a given time. 972 A DCCP protocol instance can be extended [RFC4340] and tuned using 973 additional features. Some features are sender-side only, requiring 974 no negotiation with the receiver; some are receiver-side only; and 975 some are explicitly negotiated during connection setup. 977 DCCP service is unicast-only. 979 It supports negotiation of the congestion control profile, to provide 980 plug- and-play congestion control mechanisms. Examples of specified 981 profiles include "TCP-like" [RFC4341], "TCP-friendly" [RFC4342], and 982 "TCP-friendly for small packets" [RFC5622]. Additional mechanisms 983 are recorded in an IANA registry. 985 DCCP uses a Connect packet to initiate a session, and permits half- 986 connections that allow each client to choose the features it wishes 987 to support. Simultaneous open [RFC5596], as in TCP, can enable 988 interoperability in the presence of middleboxes. The Connect packet 989 includes a Service Code field [RFC5595] designed to allow middleboxes 990 and endpoints to identify the characteristics required by a session. 992 A lightweight UDP-based encapsulation (DCCP-UDP) has been defined 993 [RFC6773] that permits DCCP to be used over paths where DCCP is not 994 natively supported. Support in NAPT/NATs is defined in [RFC4340] and 995 [RFC5595]. 997 Upper layer protocols specified on top of DCCP include DTLS 998 [RFC5595], RTP [RFC5672], ICE/SDP [RFC6773]. 1000 A common packet format has allowed tools to evolve that can read and 1001 interpret DCCP packets (e.g., Wireshark). 1003 4.6.2. Interface Description 1005 API characteristics include: - Datagram transmission. - Notification 1006 of the current maximum packet size. - Send and reception of zero- 1007 length payloads. - Slow Receiver flow control at a receiver. - 1008 ability to detect a slow receiver at the sender. 1010 There is no API currently specified in the RFC Series. 1012 4.6.3. Transport Features 1014 The transport features provided by DCCP are: 1016 o unicast transport. 1018 o connection setup with feature negotiation and application-to-port 1019 mapping. 1021 o Service Codes. Identifies the upper layer service to the endpoint 1022 and network. 1024 o port multiplexing. 1026 o Uni-or bidirectional communication. 1028 o message-oriented delivery. 1030 o non-reliable delivery. 1032 o ordered delivery. 1034 o flow control. The slow receiver function allows a receiver to 1035 control the rate of the sender. 1037 o drop notification. Allows a receiver to notify which datagrams 1038 were not delivered to the peer upper layer protocol. 1040 o timestamps. 1042 o partial and full integrity protection (with optional strong 1043 integrity check). 1045 4.7. Internet Control Message Protocol (ICMP) 1047 The Internet Control Message Protocol (ICMP) [RFC0792] for IPv4 and 1048 [RFC4433] for IPv6 are IETF standards track protocols. 1050 ICMP is a connection-less unidirectional protocol that delivers 1051 individual messages, without error correction, congestion control, or 1052 flow control. Messages may be sent as unicast, IPv4 broadcast or 1053 multicast datagrams (IPv4 and IPv6), in addition to anycast 1054 datagrams. 1056 4.7.1. Protocol Description 1058 ICMP is a connection-less unidirectional protocol that delivers 1059 individual messages. The protocol uses independent messages, 1060 ordinarily called datagrams. Each message is required to carry a 1061 checksum as an integrity check and to protect from misdelivery to an 1062 unintended endpoint. 1064 ICMP messages typically relay diagnostic information from an endpoint 1065 [RFC1122] or network device [RFC1716] addressed to the sender of a 1066 flow. This usually contains the network protocol header of a packet 1067 that encountered a reported issue. Some formats of messages can also 1068 carry other payload data. Each message carries an integrity check 1069 calculated in the same way as for UDP, this checksum is not optional. 1071 The RFC series defines additional IPv6 message formats to support a 1072 range of uses. In the case of IPv6 the protocol incorporates 1073 neighbor discovery [RFC2461] [RFC3971]} (provided by ARP for IPv4) 1074 and the Multicast Listener Discovery (MLD) [RFC2710] group management 1075 functions (provided by IGMP for IPv4). 1077 Reliable transmission can not be assumed. A receiving application 1078 that is unable to run sufficiently fast, or frequently, may miss 1079 messages since there is no flow or congestion control. In addition 1080 some network devices rate-limit ICMP messages. 1082 Transport Protocols and upper layer protocols can use received ICMP 1083 messages to help them take appropriate decisions when network or 1084 endpoint errors are reported. For example to implement, ICMP-based 1085 Path MTU discovery [RFC1191][RFC1981] or assist in Packetization 1086 Layer Path MTU Discovery (PMTUD) [RFC4821]. Such reactions to 1087 received messages need to protects from off-path data injection 1088 [I-D.ietf-tsvwg-rfc5405bis], avoiding an application receiving 1089 packets that were created by an unauthorized third party. An 1090 application therefore needs to ensure that all messages are 1091 appropriately validated, by checking the payload of the messages to 1092 ensure these are received in response to actually transmitted traffic 1093 (e.g., a reported error condition that corresponds to a UDP datagram 1094 or TCP segment was actually sent by the application). This requires 1095 context [RFC6056], such as local state about communication instances 1096 to each destination (e.g., in the TCP, DCCP, or SCTP protocols). 1097 This state is not always maintained by UDP-based applications 1098 [I-D.ietf-tsvwg-rfc5405bis]. 1100 Any response to ICMP error messages ought to be robust to temporary 1101 routing failures (sometimes called "soft errors"), e.g., transient 1102 ICMP "unreachable" messages ought to not normally cause a 1103 communication abort [RFC5461] [I-D.ietf-tsvwg-rfc5405bis]. 1105 4.7.2. Interface Description 1107 ICMP processing is integrated into many connection-oriented 1108 transports, but like other functions needs to be provided by an 1109 upper-layer protocol when using UDP and UDP-Lite. On some stacks, a 1110 bound socket also allows a UDP application to be notified when ICMP 1111 error messages are received for its transmissions 1112 [I-D.ietf-tsvwg-rfc5405bis]. 1114 4.7.3. Transport Features 1116 The transport features provided by ICMP are: 1118 o unidirectional. 1120 o multicast, anycast and IP4 broadcast. 1122 o message-oriented delivery. 1124 o non-reliable delivery. 1126 o non-ordered delivery. 1128 o error and misdelivery detection (checksum). 1130 4.8. Realtime Transport Protocol (RTP) 1132 RTP provides an end-to-end network transport service, suitable for 1133 applications transmitting real-time data, such as audio, video or 1134 data, over multicast or unicast network services, including TCP, UDP, 1135 UDP-Lite, or DCCP. 1137 4.8.1. Protocol Description 1139 The RTP standard [RFC3550] defines a pair of protocols, RTP and the 1140 Real Time Control Protocol, RTCP. The transport does not provide 1141 connection setup, instead relying on out-of-band techniques or 1142 associated control protocols to setup, negotiate parameters or tear 1143 down a session. 1145 An RTP sender encapsulates audio/video data into RTP packets to 1146 transport media streams. The RFC-series specifies RTP media formats 1147 allow packets to carry a wide range of media, and specifies a wide 1148 range of multiplexing, error control and other support mechanisms. 1150 If a frame of media data is large, it will be fragmented into several 1151 RTP packets. Likewise, several small frames may be bundled into a 1152 single RTP packet. RTP may run over a congestion-controlled or non- 1153 congestion-controlled transport protocol. 1155 An RTP receiver collects RTP packets from network, validates them for 1156 correctness, and sends them to the media decoder input-queue. 1157 Missing packet detection is performed by the channel decoder. The 1158 play-out buffer is ordered by time stamp and is used to reorder 1159 packets. Damaged frames may be repaired before the media payloads 1160 are decompressed to display or store the data. 1162 RTCP is a control protocol that works alongside a RTP flow. Both the 1163 RTP sender and receiver can send RTCP report packets. This is used 1164 to periodically send control information and report performance. 1165 Based on received RTCP feedback, an RTP sender can adjust the 1166 transmission, e.g., perform rate adaptation at the application layer 1167 in the case of congestion. 1169 An RTCP receiver report (RTCP RR) is returned to the sender 1170 periodically to report key parameters (e.g, the fraction of packets 1171 lost in the last reporting interval, the cumulative number of packets 1172 lost, the highest sequence number received, and the inter-arrival 1173 jitter). The RTCP RR packets also contain timing information that 1174 allows the sender to estimate the network round trip time (RTT) to 1175 the receivers. 1177 The interval between reports sent from each receiver tends to be on 1178 the order of a few seconds on average, although this varies with the 1179 session rate, and sub-second reporting intervals are possible for 1180 high rate sessions. The interval is randomized to avoid 1181 synchronization of reports from multiple receivers. 1183 4.8.2. Interface Description 1185 There is no standard application programming interface defined for 1186 RTP or RTCP. Implementations are typically tightly integrated with a 1187 particular application, and closely follow the principles of 1188 application level framing and integrated layer processing [ClarkArch] 1189 in media processing [RFC2736], error recovery and concealment, rate 1190 adaptation, and security [RFC7202]. Accordingly, RTP implementations 1191 tend to be targeted at particular application domains (e.g., voice- 1192 over-IP, IPTV, or video conferencing), with a feature set optimised 1193 for that domain, rather than being general purpose implementations of 1194 the protocol. 1196 4.8.3. Transport Features 1198 The transport features provided by RTP are: 1200 o unicast transport. 1202 o multicast, anycast or IPv4 broadcast. 1204 o port multiplexing. 1206 o Uni-or bidirectional communication. 1208 o message-oriented delivery. 1210 o associated protocols for connection setup with feature negotiation 1211 and application-to-port mapping. 1213 o support for media types and other extensions. 1215 o a range of reliability functions, including the possibility of 1216 using packet erasure coding. 1218 o segmentation and aggregation. 1220 o performance reporting. 1222 o drop notification. 1224 o timestamps. 1226 4.9. File Delivery over Unidirectional Transport/Asynchronous Layered 1227 Coding Reliable Multicast (FLUTE/ALC) 1229 FLUTE/ALC is an IETF standards track protocol specified in [RFC6726] 1230 and [RFC5775]. Asynchronous Layer Coding (ALC) provides an 1231 underlying reliable transport service and FLUTE a file-oriented 1232 specialization of the ALC service (e.g., to carry associated 1233 metadata). The [RFC6726] and [RFC5775] protocols are non-backward- 1234 compatible updates of the [RFC3926] and [RFC3450] experimental 1235 protocols; these experimental protocols are currently largely 1236 deployed in the 3GPP Multimedia Broadcast and Multicast Services 1237 (MBMS) (see [MBMS], section 7) and similar contexts (e.g., the 1238 Japanese ISDB-Tmm standard). 1240 The FLUTE/ALC protocol has been designed to support massively 1241 scalable reliable bulk data dissemination to receiver groups of 1242 arbitrary size using IP Multicast over any type of delivery network, 1243 including unidirectional networks (e.g., broadcast wireless 1244 channels). However, the FLUTE/ALC protocol also supports point-to- 1245 point unicast transmissions. 1247 FLUTE/ALC bulk data dissemination has been designed for discrete file 1248 or memory-based "objects". Transmissions happen either in push mode, 1249 where content is sent once, or in on-demand mode, where content is 1250 continuously sent during periods of time that can largely exceed the 1251 average time required to download the session objects (see [RFC5651], 1252 section 4.2). 1254 Although FLUTE/ALC is not well adapted to byte- and message- 1255 streaming, there is an exception: FLUTE/ALC is used to carry 3GPP 1256 Dynamic Adaptive Streaming over HTTP (DASH) when scalability is a 1257 requirement (see [MBMS], section 5.6). In that case, each Audio/ 1258 Video segment is transmitted as a distinct FLUTE/ALC object in push 1259 mode. FLUTE/ALC uses packet erasure coding (also known as 1260 Application-Level Forward Erasure Correction, or AL-FEC) in a 1261 proactive way. The goal of using AL-FEC is both to increase the 1262 robustness in front of packet erasures and to improve the efficiency 1263 of the on-demand service. FLUTE/ALC transmissions can be governed by 1264 a congestion control mechanism such as the "Wave and Equation Based 1265 Rate Control" (WEBRC) [RFC3738] when FLUTE/ALC is used in a layered 1266 transmission manner, with several session channels over which ALC 1267 packets are sent. However many FLUTE/ALC deployments target pre- 1268 provisioned networks and involve only Constant Bit Rate (CBR) 1269 channels with no competing flows, for which a sender-based rate 1270 control mechanism is sufficient. In any case, FLUTE/ALC's 1271 reliability, delivery mode, congestion control, and flow/rate control 1272 mechanisms are distinct components that can be separately controlled 1273 to meet different application needs. Section 4.1 of 1274 [I-D.ietf-tsvwg-rfc5405bis] describes multicast congestion control 1275 requirements for UDP. 1277 4.9.1. Protocol Description 1279 The FLUTE/ALC protocol works on top of UDP (though it could work on 1280 top of any datagram delivery transport protocol), without requiring 1281 any connectivity from receivers to the sender. Purely unidirectional 1282 networks are therefore supported by FLUTE/ALC. This guarantees 1283 scalability to an unlimited number of receivers in a session, since 1284 the sender behaves exactly the same regardless of the number of 1285 receivers. 1287 FLUTE/ALC supports the transfer of bulk objects such as file or in- 1288 memory content, using either a push or an on-demand mode. in push 1289 mode, content is sent once to the receivers, while in on-demand mode, 1290 content is sent continuously during periods of time that can greatly 1291 exceed the average time required to download the session objects. 1293 This enables receivers to join a session asynchronously, at their own 1294 discretion, receive the content and leave the session. In this case, 1295 data content is typically sent continuously, in loops (also known as 1296 "carousels"). FLUTE/ALC also supports the transfer of an object 1297 stream, with loose real-time constraints. This is particularly 1298 useful to carry 3GPP DASH when scalability is a requirement and 1299 unicast transmissions over HTTP cannot be used ([MBMS], section 5.6). 1300 In this case, packets are sent in sequence using push mode. FLUTE/ 1301 ALC is not well adapted to byte- and message-streaming and other 1302 solutions could be preferred (e.g., FECFRAME [RFC6363] with real-time 1303 flows). 1305 The FLUTE file delivery instantiation of ALC provides a metadata 1306 delivery service. Each object of the FLUTE/ALC session is described 1307 in a dedicated entry of a File Delivery Table (FDT), using an XML 1308 format (see [RFC6726], section 3.2). This metadata can include, but 1309 is not restricted to, a URI attribute (to identify and locate the 1310 object), a media type attribute, a size attribute, an encoding 1311 attribute, or a message digest attribute. Since the set of objects 1312 sent within a session can be dynamic, with new objects being added 1313 and old ones removed, several instances of the FDT can be sent and a 1314 mechanism is provided to identify a new FDT Instance. 1316 To provide robustness against packet loss and improve the efficiency 1317 of the on-demand mode, FLUTE/ALC relies on packet erasure coding (AL- 1318 FEC). AL-FEC encoding is proactive (since there is no feedback and 1319 therefore no (N)ACK-based retransmission) and ALC packets containing 1320 repair data are sent along with ALC packets containing source data. 1321 Several FEC Schemes have been standardized; FLUTE/ALC does not 1322 mandate the use of any particular one. Several strategies concerning 1323 the transmission order of ALC source and repair packets are possible, 1324 in particular in on-demand mode where it can deeply impact the 1325 service provided (e.g., to favor the recovery of objects in sequence, 1326 or at the other extreme, to favor the recovery of all objects in 1327 parallel), and FLUTE/ALC does not mandate nor recommend the use of 1328 any particular one. 1330 A FLUTE/ALC session is composed of one or more channels, associated 1331 to different destination unicast and/or multicast IP addresses. ALC 1332 packets are sent in those channels at a certain transmission rate, 1333 with a rate that often differs depending on the channel. FLUTE/ALC 1334 does not mandate nor recommend any strategy to select which ALC 1335 packet to send on which channel. FLUTE/ALC can use a multiple rate 1336 congestion control building block (e.g., WEBRC) to provide congestion 1337 control that is feedback free, where receivers adjust their reception 1338 rates individually by joining and leaving channels associated with 1339 the session. To that purpose, the ALC header provides a specific 1340 field to carry congestion control specific information. However 1341 FLUTE/ALC does not mandate the use of a particular congestion control 1342 mechanism although WEBRC is mandatory to support for the Internet 1343 ([RFC6726], section 1.1.4). FLUTE/ALC is often used over a network 1344 path with pre-provisioned capacity [I-D.ietf-tsvwg-rfc5405bis] where 1345 there are no flows competing for capacity. In this case, a sender- 1346 based rate control mechanism and a single channel is sufficient. 1348 [RFC6584] provides per-packet authentication, integrity, and anti- 1349 replay protection in the context of the ALC and NORM protocols. 1350 Several mechanisms are proposed that seamlessly integrate into these 1351 protocols using the ALC and NORM header extension mechanisms. 1353 4.9.2. Interface Description 1355 The FLUTE/ALC specification does not describe a specific application 1356 programming interface (API) to control protocol operation. 1357 Open source reference implementations of FLUTE/ALC are available at 1358 http://planete-bcast.inrialpes.fr/ (no longer maintained) and 1359 http://mad.cs.tut.fi/ (no longer maintained), and these 1360 implementations specify and document their own APIs. Commercial 1361 versions are also available, some derived from the above 1362 implementations, with their own API. 1364 4.9.3. Transport Features 1366 The transport features provided by FLUTE/ALC are: 1368 o unicast 1370 o multicast, anycast or IPv4 broadcast. 1372 o per-object dynamic meta-data delivery. 1374 o push delivery or on-demand delivery service. 1376 o fully reliable or partially reliable delivery (of file or in- 1377 memory objects). 1379 o ordered or unordered delivery (of file or in-memory objects). 1381 o per-packet authentication, integrity, and anti-replay services. 1383 o proactive packet erasure coding (AL-FEC) to recover from packet 1384 erasures and improve the on-demand delivery service, 1386 o error detection (through UDP). 1388 o congestion control for layered flows (e.g., with WEBRC). 1390 4.10. NACK-Oriented Reliable Multicast (NORM) 1392 NORM is an IETF standards track protocol specified in [RFC5740]. The 1393 protocol was designed to support reliable bulk data dissemination to 1394 receiver groups using IP Multicast but also provides for point-to- 1395 point unicast operation. Support for bulk data dissemination 1396 includes discrete file or computer memory-based "objects" as well as 1397 byte- and message-streaming. NORM is designed to incorporate packet 1398 erasure coding as an inherent part of its selective ARQ in response 1399 to receiver negative acknowledgments. The packet erasure coding can 1400 also be proactively applied for forward protection from packet loss. 1401 NORM transmissions are governed by the TCP-friendly congestion 1402 control. NORM's reliability, congestion control, and flow control 1403 mechanism are distinct components and can be separately controlled to 1404 meet different application needs. 1406 4.10.1. Protocol Description 1408 The NORM protocol is encapsulated in UDP datagrams and thus provides 1409 multiplexing for multiple sockets on hosts using port numbers. For 1410 loosely coordinated IP Multicast, NORM is not strictly connection- 1411 oriented although per-sender state is maintained by receivers for 1412 protocol operation. [RFC5740] does not specify a handshake protocol 1413 for connection establishment and separate session initiation can be 1414 used to coordinate port numbers. However, in-band "client-server" 1415 style connection establishment can be accomplished with the NORM 1416 congestion control signaling messages using port binding techniques 1417 like those for TCP client-server connections. 1419 NORM supports bulk "objects" such as file or in-memory content but 1420 also can treat a stream of data as a logical bulk object for purposes 1421 of packet erasure coding. In the case of stream transport, NORM can 1422 support either byte streams or message streams where application- 1423 defined message boundary information is carried in the NORM protocol 1424 messages. This allows the receiver(s) to join/re- join and recover 1425 message boundaries mid-stream as needed. Application content is 1426 carried and identified by the NORM protocol with encoding symbol 1427 identifiers depending upon the Forward Error Correction (FEC) Scheme 1428 [RFC3452] configured. NORM uses NACK-based selective ARQ to reliably 1429 deliver the application content to the receiver(s). NORM proactively 1430 measures round- trip timing information to scale ARQ timers 1431 appropriately and to support congestion control. For multicast 1432 operation, timer-based feedback suppression is uses to achieve group 1433 size scaling with low feedback traffic levels. The feedback 1434 suppression is not applied for unicast operation. 1436 NORM uses rate-based congestion control based upon the TCP-Friendly 1437 Rate Control (TFRC) [RFC4324] principles that are also used in DCCP 1439 [RFC4340]. NORM uses control messages to measure RTT and collect 1440 congestion event (e..g, loss event, ECN event, etc) information from 1441 the receiver(s) to support dynamic rate control adjustment. The TCP- 1442 Friendly Multicast Congestion Control (TFMCC) [RFC4654] used provides 1443 some extra features to support multicast but is functionally 1444 equivalent to TFRC in the unicast case. 1446 NORM's reliability mechanism is decoupled from congestion control. 1447 This allows alternative arrangements of transport services to be 1448 invoked. For example, fixed-rate reliable delivery can be supported 1449 or unreliable (but optionally "better than best effort" via packet 1450 erasure coding) delivery with rate- control per TFRC can be achieved. 1451 Additionally, alternative congestion control techniques may be 1452 applied. For example, TFRC rate control with congestion event 1453 detection based on ECN for links with high packet loss (e.g., 1454 wireless) has been implemented and demonstrated with NORM. 1456 While NORM is NACK-based for reliability transfer, it also supports a 1457 positive acknowledgment (ACK) mechanism that can be used for receiver 1458 flow control. Again, since this mechanism is decoupled from the 1459 reliability and congestion control, applications that have different 1460 needs in this aspect can use the protocol differently. One example 1461 is the use of NORM for quasi-reliable delivery where timely delivery 1462 of newer content may be favored over completely reliable delivery of 1463 older content within buffering and RTT constraints. 1465 4.10.2. Interface Description 1467 The NORM specification does not describe a specific application 1468 programming interface (API) to control protocol operation. A freely- 1469 available, open source reference implementation of NORM is available 1470 at https://www.nrl.navy.mil/itd/ncs/products/norm, and a documented 1471 API is provided for this implementation. While a sockets-like API is 1472 not currently documented, the existing API supports the necessary 1473 functions for that to be implemented. 1475 4.10.3. Transport Features 1477 The transport features provided by NORM are: 1479 o unicast or multicast transport. 1481 o stream-oriented delivery in a single stream. 1483 o object-oriented delivery of discrete data or file items. 1485 o reliable delivery. 1487 o unordered unidirectional delivery (of in-memory data or file bulk 1488 content objects). 1490 o error detection (UDP checksum). 1492 o segmentation. 1494 o data bundling (Nagle's algorithm). 1496 o flow control (timer-based and/or ack-based). 1498 o congestion control. 1500 o packet erasure coding (both proactively and as part of ARQ). 1502 4.11. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a 1503 pseudotransport 1505 Transport Layer Security (TLS) and Datagram TLS (DTLS) are IETF 1506 protocols that provide several security-related features to 1507 applications. TLS is designed to run on top of a reliable streaming 1508 transport protocol (usually TCP), while DTLS is designed to run on 1509 top of a best-effort datagram protocol (UDP or DCCP [RFC5238]). At 1510 the time of writing, the current version of TLS is 1.2; which is 1511 defined in [RFC5246]. DTLS provides nearly identical functionality 1512 to applications; it is defined in [RFC6347] and its current version 1513 is also 1.2. The TLS protocol evolved from the Secure Sockets Layer 1514 (SSL) protocols developed in the mid 90s to support protection of 1515 HTTP traffic. 1517 While older versions of TLS and DTLS are still in use, they provide 1518 weaker security guarantees. [RFC7457] outlines important attacks on 1519 TLS and DTLS. [RFC7525] is a Best Current Practices (BCP) document 1520 that describes secure configurations for TLS and DTLS to counter 1521 these attacks. The recommendations are applicable for the vast 1522 majority of use cases. 1524 4.11.1. Protocol Description 1526 Both TLS and DTLS provide the same security features and can thus be 1527 discussed together. The features they provide are: 1529 o Confidentiality 1531 o Data integrity 1533 o Peer authentication (optional) 1534 o Perfect forward secrecy (optional) 1536 The authentication of the peer entity can be omitted; a common web 1537 use case is where the server is authenticated and the client is not. 1538 TLS also provides a completely anonymous operation mode in which 1539 neither peer's identity is authenticated. It is important to note 1540 that TLS itself does not specify how a peering entity's identity 1541 should be interpreted. For example, in the common use case of 1542 authentication by means of an X.509 certificate, it is the 1543 application's decision whether the certificate of the peering entity 1544 is acceptable for authorization decisions. Perfect forward secrecy, 1545 if enabled and supported by the selected algorithms, ensures that 1546 traffic encrypted and captured during a session at time t0 cannot be 1547 later decrypted at time t1 (t1 > t0), even if the long-term secrets 1548 of the communicating peers are later compromised. 1550 As DTLS is generally used over an unreliable datagram transport such 1551 as UDP, applications will need to tolerate lost, re-ordered, or 1552 duplicated datagrams. Like TLS, DTLS conveys application data in a 1553 sequence of independent records. However, because records are mapped 1554 to unreliable datagrams, there are several features unique to DTLS 1555 that are not applicable to TLS: 1557 o Record replay detection (optional). 1559 o Record size negotiation (estimates of PMTU and record size 1560 expansion factor). 1562 o Coveyance of IP don't fragment (DF) bit settings by application. 1564 o An anti-DoS stateless cookie mechanism (optional). 1566 Generally, DTLS follows the TLS design as closely as possible. To 1567 operate over datagrams, DTLS includes a sequence number and limited 1568 forms of retransmission and fragmentation for its internal 1569 operations. The sequence number may be used for detecting replayed 1570 information, according to the windowing procedure described in 1571 Section 4.1.2.6 of [RFC6347]. DTLS forbids the use of stream 1572 ciphers, which are essentially incompatible when operating on 1573 independent encrypted records. 1575 4.11.2. Interface Description 1577 TLS is commonly invoked using an API provided by packages such as 1578 OpenSSL, wolfSSL, or GnuTLS. Using such APIs entails the 1579 manipulation of several important abstractions, which fall into the 1580 following categories: long-term keys and algorithms, session state, 1581 and communications/connections. There may also be special APIs 1582 required to deal with time and/or random numbers, both of which are 1583 needed by a variety of encryption algorithms and protocols. 1585 Considerable care is required in the use of TLS APIs to ensure 1586 creation of a secure application. The programmer should have at 1587 least a basic understanding of encryption and digital signature 1588 algorithms and their strengths, public key infrastructure (including 1589 X.509 certificates and certificate revocation), and the sockets API. 1590 See [RFC7525] and [RFC7457], as mentioned above. 1592 As an example, in the case of OpenSSL, the primary abstractions are 1593 the library itself and method (protocol), session, context, cipher 1594 and connection. After initializing the library and setting the 1595 method, a cipher suite is chosen and used to configure a context 1596 object. Session objects may then be minted according to the 1597 parameters present in a context object and associated with individual 1598 connections. Depending on how precisely the programmer wishes to 1599 select different algorithmic or protocol options, various levels of 1600 details may be required. 1602 4.11.3. Transport Features 1604 Both TLS and DTLS employ a layered architecture. The lower layer is 1605 commonly called the record protocol. It is responsible for: 1607 o message fragmentation. 1609 o authentication and integrity via message authentication codes 1610 (MAC). 1612 o data encryption. 1614 o scheduling transmission using the underlying transport protocol. 1616 DTLS augments the TLS record protocol with: 1618 o ordering and replay protection, implemented using sequence 1619 numbers. 1621 Several protocols are layered on top of the record protocol. These 1622 include the handshake, alert, and change cipher spec protocols. 1623 There is also the data protocol, used to carry application traffic. 1624 The handshake protocol is used to establish cryptographic and 1625 compression parameters when a connection is first set up. In DTLS, 1626 this protocol also has a basic fragmentation and retransmission 1627 capability and a cookie-like mechanism to resist DoS attacks. (TLS 1628 compression is not recommended at present). The alert protocol is 1629 used to inform the peer of various conditions, most of which are 1630 terminal for the connection. The change cipher spec protocol is used 1631 to synchronize changes in cryptographic parameters for each peer. 1633 The data protocol, when used with an appropriate cipher, provides: 1635 o authentication of one end or both ends of a connection. 1637 o confidentiality. 1639 o cryptographic integrity protection. 1641 4.12. Hypertext Transport Protocol (HTTP) over TCP as a pseudotransport 1643 The Hypertext Transfer Protocol (HTTP) is an application-level 1644 protocol widely used on the Internet. Version 1.1 of the protocol is 1645 specified in [RFC7230] [RFC7231] [RFC7232] [RFC7233] [RFC7234] 1646 [RFC7235], and version 2 in [RFC7540]. HTTP is usually transported 1647 over TCP using port 80 and 443, although it can be used with other 1648 transports. When used over TCP it inherits its properties. 1650 HTTP is used as a substrate for other application-layer protocols. 1651 There are various reasons for this practice listed in [RFC3205]; 1652 these include being a well-known and well-understood protocol, 1653 reusability of existing servers and client libraries, easy use of 1654 existing security mechanisms such as HTTP digest authentication 1655 [RFC2617] and TLS [RFC5246], the ability of HTTP to traverse 1656 firewalls makes it work over many types of infrastructure, and in 1657 cases where a application server often needs to support HTTP anyway. 1659 Depending on application need, the use of HTTP as a substrate 1660 protocol may add complexity and overhead in comparison to a special- 1661 purpose protocol (e.g., HTTP headers, suitability of the HTTP 1662 security model, etc.). [RFC3205] addresses this issue and provides 1663 some guidelines and concerns about the use of HTTP standard port 80 1664 and 443, the use of HTTP URL scheme and interaction with existing 1665 firewalls, proxies and NATs. 1667 4.12.1. Protocol Description 1669 Hypertext Transfer Protocol (HTTP) is a request/response protocol. A 1670 client sends a request containing a request method, URI and protocol 1671 version followed by a MIME-like message (see [RFC7231] for the 1672 differences between an HTTP object and a MIME message), containing 1673 information about the client and request modifiers. The message can 1674 contain a message body carrying application data as well. The server 1675 responds with a status or error code followed by a MIME-like message 1676 containing information about the server and information about carried 1677 data and it can include a message body. It is possible to specify a 1678 data format for the message body using MIME media types [RFC2045]. 1679 Furthermore, the protocol has numerous additional features; features 1680 relevant to pseudotransport are described below. 1682 Content negotiation, specified in [RFC7231], is a mechanism provided 1683 by HTTP for selecting a representation on a requested resource. The 1684 client and server negotiate acceptable data formats, charsets, data 1685 encoding (e.g., data can be transferred compressed using gzip), etc. 1686 HTTP can accommodate exchange of messages as well as data streaming 1687 (using chunked transfer encoding [RFC7230]). It is also possible to 1688 request a part of a resource using range requests specified in 1689 [RFC7233]. The protocol provides powerful cache control signalling 1690 defined in [RFC7234]. 1692 HTTP 1.1's and HTTP 2.0's persistent connections can be use to 1693 perform multiple request-response transactions during the life-time 1694 of a single HTTP connection. Moreover, HTTP 2.0 connections can 1695 multiplex many request/response pairs in parallel on a single 1696 transport connection. This reduces connection establishment overhead 1697 and the effect of the transport layer slow-start on each transaction, 1698 important in reducing latency for HTTP's primary use case. 1700 It is possible to combine HTTP with security mechanisms, like TLS 1701 (denoted by HTTPS), which adds protocol properties provided by such a 1702 mechanism (e.g., authentication, encryption). The TLS Application- 1703 Layer Protocol Negotiation (ALPN) extension [RFC7301] can be used for 1704 HTTP version negotiation within the TLS handshake, which eliminates 1705 the latency of addition round-trips. Arbitrary cookie strings, 1706 included as part of the MIME headers, are often used as bearer tokens 1707 in HTTP. 1709 Application layer protocols using HTTP as substrate may use an 1710 existing method and data formats, or specify new methods and data 1711 formats. Furthermore some protocols may not fit a request/response 1712 paradigm and instead rely on HTTP to send messages (e.g., [RFC6546]). 1713 Because HTTP works in many restricted infrastructures, it is also 1714 used to tunnel other application-layer protocols. 1716 4.12.2. Interface Description 1718 There are many HTTP libraries available exposing different APIs. The 1719 APIs provide a way to specify a request by providing a URI, a method, 1720 request modifiers and optionally a request body. For the response, 1721 callbacks can be registered that will be invoked when the response is 1722 received. If TLS is used, API expose a registration of callbacks in 1723 case a server requests client authentication and when certificate 1724 verification is needed. 1726 World Wide Web Consortium (W3C) standardized the XMLHttpRequest API 1727 [XHR], an API that can be use for sending HTTP/HTTPS requests and 1728 receiving server responses. Besides XML data format, request and 1729 response data format can also be JSON, HTML and plain text. 1730 Specifically JavaScript and XMLHttpRequest are a ubiquitous 1731 programming model for websites, and more general applications, where 1732 native code is less attractive. 1734 Representational State Transfer (REST) [REST] is another example how 1735 applications can use HTTP as transport protocol. REST is an 1736 architecture style for building application on the Internet. It uses 1737 HTTP as a communication protocol. 1739 4.12.3. Transport features 1741 The transport features provided by HTTP, when used as a 1742 pseudotransport, are: 1744 o unicast. 1746 o message and stream-oriented transfer. 1748 o bi- or unidirectional transmission. 1750 o ordered delivery. 1752 o fully reliable delivery. 1754 o object range request. 1756 o message content type negotiation. 1758 o flow control. 1760 HTTPS (HTTP over TLS) additionally provides the following components: 1762 o authentication (of one or both ends of a connection). 1764 o confidentiality. 1766 o integrity protection. 1768 5. Transport Service Features 1770 The tables below summarize some key features to illustrate the range 1771 of functions provided across the IETF-specified transports. Figure 1 1772 considers transports that may be directly layered over the network, 1773 and Figure 2 considers transports layered over another transport 1774 service. 1776 +---------------+------+------+------+------+------+------+------+ 1777 | Feature | TCP | MPTCP| SCTP | UDP | UDP-L|DCCP |ICMP | 1778 +---------------+------+------+------+------+------+------+------+ 1779 | Datagram | No | No | Yes | Yes | Yes | Yes | Yes | 1780 +---------------+------+------+------+------+------+------+------+ 1781 | Conn. Oriented| Yes | Yes | Yes | No | No | Yes | No | 1782 +---------------+------+------+------+------+------+------+------+ 1783 | Reliability | Yes | Yes | Yes | No | No | No | No | 1784 +---------------+------+------+------+------+------+------+------+ 1785 | Partial Rel. | No | No | Pos | N/A | N/A | Yes | N/A | 1786 +---------------+------+------+------+------+------+------+------+ 1787 | Corupt. Tol | No | No | No | No | Yes | Yes | No | 1788 +---------------+------+------+------+------+------+------+------+ 1789 | Cong.Control | Yes | Yes | Yes | No | No | Yes | No | 1790 +---------------+------+------+------+------+------+------+------+ 1791 | Endpoint | 1 | >=1 | >=1 | 1 | 1 | 1 | 1 | 1792 +---------------+------+------+------+------+------+------+------+ 1793 | Multicast Cap.| No | No | No | Yes | Yes | No | No | 1794 +---------------+------+------+------+------+------+------+------+ 1796 Figure 1: Summary comparison: Transport protocols 1798 +---------------+------+------+------+------+------+ 1799 | Feature | RTP | FLUTE| NORM |(D)TLS| HTTP | 1800 +---------------+------+------+------+------+------+ 1801 | Datagram | Yes | No | Both | Both | No | 1802 +---------------+------+------+------+------+------+ 1803 | Conn. Oriented| No | Yes | Yes | Yes | Yes | 1804 +---------------+------+------+------+------+------+ 1805 | Reliability | No | Yes | Pos | Pos | Yes | 1806 +---------------+------+------+------+------+------+ 1807 | Partial R | Pos | No | Pos | No | No | 1808 +---------------+------+------+------+------+------+ 1809 | Corupt. Tol | Poss | No | No | No | No | 1810 +---------------+------+------+------+------+------+ 1811 | Cong.Control | Poss | Poss | Poss | N/A | N/A | 1812 +---------------+------+------+------+------+------+ 1813 | Endpoint | >=1 | >=1 | >=1 | 1 | 1 | 1814 +---------------+------+------+------+------+------+ 1815 | Multicast Cap.| Yes | Yes | Yes | No | No | 1816 +---------------+------+------+------+------+------+ 1818 Figure 2: Upper layer transports and frameworks 1820 The transport protocol components analyzed in this document that can 1821 be used as a basis for defining common transport service features, 1822 normalized and separated into categories, are as follows: 1824 o Control Functions 1826 * Addressing 1828 + unicast (TCP, MPTCP, SCTP, UDP, UDP-Lite, DCCP, TLS, HTTP) 1830 + multicast (UDP, UDP-Lite, DCCP, FLUTE/ALC, NORM) 1832 + IPv4 broadcast (UDP, UDP-Lite, DCCP) 1834 + anycast (UDP, UDP-Lite, DCCP). Connection-oriented 1835 protocols such as TCP can be and are used with anycast 1836 routing, with the risk that routing changes may cause 1837 connection failure. 1839 * Multihoming support 1841 + multihoming for resilience (MPTCP, SCTP) 1843 + multihoming for mobility (MPTCP, SCTP) 1845 + multihoming for load-balancing (MPTCP) 1847 * Application to port mapping (TCP, MPTCP, SCTP, UDP, UDP-Lite, 1848 DCCP, FLUTE/ALC, NORM, TLS, HTTP) 1850 + with commonly deployed support in NAPT (TCP, MPTCP, UDP, 1851 TLS, HTTP) 1853 o Delivery 1855 * reliability 1857 + fully reliable delivery (TCP, MPTCP, SCTP, FLUTE/ALC, NORM, 1858 TLS, HTTP) 1860 + partially reliable delivery (SCTP, NORM) 1862 - using packet erasure coding (NORM, FLUTE, RTP) 1864 + unreliable delivery (SCTP, UDP, UDP-Lite, DCCP) 1866 - with drop notification (SCTP, DCCP) 1868 + Integrity protection 1870 - checksum for error detection (TCP, MPTCP, SCTP, UDP, UDP- 1871 Lite, DCCP, FLUTE/ALC, NORM, TLS, HTTP) 1873 - partial payload checksum protection (UDP-Lite, DCCP) 1875 - checksum optional (UDP) 1877 * ordering 1879 + ordered delivery (TCP, MPTCP, SCTP, TLS, HTTP) 1881 + unordered delivery (SCTP, UDP, UDP-Lite, DCCP, NORM) 1883 * type/framing 1885 + stream-oriented delivery (TCP, MPTCP, SCTP, TLS) 1887 - with multiple streams per association (SCTP) 1889 + message-oriented delivery (SCTP, UDP, UDP-Lite, DCCP, DTLS) 1891 + object-oriented delivery of discrete data or file items 1892 (FLUTE/ALC, NORM, HTTP) 1894 o Transmission control 1896 * flow control (TCP, MPTCP, SCTP, DCCP, TLS, HTTP) 1898 * congestion control (TCP, MPTCP, SCTP, DCCP, FLUTE/ALC, NORM, 1899 TLS, HTTP) 1901 * segmentation (TCP, MPTCP, SCTP, FLUTE/ALC, NORM, TLS, HTTP) 1903 * data/message bundling (TCP, MPTCP, SCTP, TLS, HTTP) 1905 * stream scheduling prioritization (SCTP) 1907 o Security (may be used in combination with other transports) 1909 * authentication of one end of a connection (TLS) 1911 * authentication of both ends of a connection (TLS) 1913 * confidentiality (TLS) 1915 * cryptographic integrity protection (TLS) 1917 6. IANA Considerations 1919 This document has no considerations for IANA. 1921 7. Security Considerations 1923 This document surveys existing transport protocols and protocols 1924 providing transport-like services. Confidentiality, integrity, and 1925 authenticity are among the features provided by those services. This 1926 document does not specify any new components or mechanisms for 1927 providing these features. Each RFC listed in this document discusses 1928 the security considerations of the specification it contains. 1930 8. Contributors 1932 In addition to the editors, this document is the work of Brian 1933 Adamson, Dragana Damjanovic, Kevin Fall, Simone Ferlin-Oliviera, 1934 Ralph Holz, Olivier Mehani, Karen Nielsen, Colin Perkins, Vincent 1935 Roca, and Michael Tuexen. 1937 o Section 4.2 on MPTCP was contributed by Simone Ferlin-Oliviera 1938 (ferlin@simula.no) and Olivier Mehani 1939 (olivier.mehani@nicta.com.au) 1941 o Section 4.4 on UDP was contributed by Kevin Fall (kfall@kfall.com) 1943 o Section 4.3 on SCTP was contributed by Michael Tuexen (tuexen@fh- 1944 muenster.de) and Karen Nielsen (karen.nielsen@tieto.com) 1946 o Section 4.8 on RTP contains contributions from Colin Perlins 1947 (csp@csperkins.org) 1949 o Section 4.9 on FLUTE/ALC was contributed by Vincent Roca 1950 (vincent.roca@inria.fr) 1952 o Section 4.10 on NORM was contributed by Brian Adamson 1953 (brian.adamson@nrl.navy.mil) 1955 o Section 4.11 on TLS and DTLS was contributed by Ralph Holz 1956 (ralph.holz@nicta.com.au) and Olivier Mehani 1957 (olivier.mehani@nicta.com.au) 1959 o Section 4.12 on HTTP was contributed by Dragana Damjanovic 1960 (ddamjanovic@mozilla.com) 1962 9. Acknowledgments 1964 Thanks to Joe Touch, Michael Welzl, and the TAPS Working Group for 1965 the comments, feedback, and discussion. This work is partially 1966 supported by the European Commission under grant agreements 1967 FP7-ICT-318627 mPlane and from the Horizon 2020 research and 1968 innovation program under grant agreement No. 644334 (NEAT); support 1969 does not imply endorsement. 1971 10. Informative References 1973 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1974 DOI 10.17487/RFC0768, August 1980, 1975 . 1977 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1978 RFC 792, DOI 10.17487/RFC0792, September 1981, 1979 . 1981 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1982 RFC 793, DOI 10.17487/RFC0793, September 1981, 1983 . 1985 [RFC0896] Nagle, J., "Congestion Control in IP/TCP Internetworks", 1986 RFC 896, DOI 10.17487/RFC0896, January 1984, 1987 . 1989 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1990 Communication Layers", STD 3, RFC 1122, 1991 DOI 10.17487/RFC1122, October 1989, 1992 . 1994 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1995 DOI 10.17487/RFC1191, November 1990, 1996 . 1998 [RFC1716] Almquist, P. and F. Kastenholz, "Towards Requirements for 1999 IP Routers", RFC 1716, DOI 10.17487/RFC1716, November 2000 1994, . 2002 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 2003 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 2004 1996, . 2006 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 2007 Selective Acknowledgment Options", RFC 2018, 2008 DOI 10.17487/RFC2018, October 1996, 2009 . 2011 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2012 Extensions (MIME) Part One: Format of Internet Message 2013 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 2014 . 2016 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2017 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2018 December 1998, . 2020 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 2021 Discovery for IP Version 6 (IPv6)", RFC 2461, 2022 DOI 10.17487/RFC2461, December 1998, 2023 . 2025 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 2026 Leach, P., Luotonen, A., and L. Stewart, "HTTP 2027 Authentication: Basic and Digest Access Authentication", 2028 RFC 2617, DOI 10.17487/RFC2617, June 1999, 2029 . 2031 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 2032 Listener Discovery (MLD) for IPv6", RFC 2710, 2033 DOI 10.17487/RFC2710, October 1999, 2034 . 2036 [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP 2037 Payload Format Specifications", BCP 36, RFC 2736, 2038 DOI 10.17487/RFC2736, December 1999, 2039 . 2041 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2042 of Explicit Congestion Notification (ECN) to IP", 2043 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2044 . 2046 [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, 2047 RFC 3205, DOI 10.17487/RFC3205, February 2002, 2048 . 2050 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 2051 Layer Security over Stream Control Transmission Protocol", 2052 RFC 3436, DOI 10.17487/RFC3436, December 2002, 2053 . 2055 [RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. 2056 Crowcroft, "Asynchronous Layered Coding (ALC) Protocol 2057 Instantiation", RFC 3450, DOI 10.17487/RFC3450, December 2058 2002, . 2060 [RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 2061 M., and J. Crowcroft, "Forward Error Correction (FEC) 2062 Building Block", RFC 3452, DOI 10.17487/RFC3452, December 2063 2002, . 2065 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2066 Jacobson, "RTP: A Transport Protocol for Real-Time 2067 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2068 July 2003, . 2070 [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate 2071 Control (WEBRC) Building Block", RFC 3738, 2072 DOI 10.17487/RFC3738, April 2004, 2073 . 2075 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 2076 Conrad, "Stream Control Transmission Protocol (SCTP) 2077 Partial Reliability Extension", RFC 3758, 2078 DOI 10.17487/RFC3758, May 2004, 2079 . 2081 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., 2082 and G. Fairhurst, Ed., "The Lightweight User Datagram 2083 Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 2084 2004, . 2086 [RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, 2087 "FLUTE - File Delivery over Unidirectional Transport", 2088 RFC 3926, DOI 10.17487/RFC3926, October 2004, 2089 . 2091 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2092 "SEcure Neighbor Discovery (SEND)", RFC 3971, 2093 DOI 10.17487/RFC3971, March 2005, 2094 . 2096 [RFC4324] Royer, D., Babics, G., and S. Mansour, "Calendar Access 2097 Protocol (CAP)", RFC 4324, DOI 10.17487/RFC4324, December 2098 2005, . 2100 [RFC4336] Floyd, S., Handley, M., and E. Kohler, "Problem Statement 2101 for the Datagram Congestion Control Protocol (DCCP)", 2102 RFC 4336, DOI 10.17487/RFC4336, March 2006, 2103 . 2105 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2106 Congestion Control Protocol (DCCP)", RFC 4340, 2107 DOI 10.17487/RFC4340, March 2006, 2108 . 2110 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 2111 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 2112 Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 2113 2006, . 2115 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 2116 Datagram Congestion Control Protocol (DCCP) Congestion 2117 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 2118 DOI 10.17487/RFC4342, March 2006, 2119 . 2121 [RFC4433] Kulkarni, M., Patel, A., and K. Leung, "Mobile IPv4 2122 Dynamic Home Agent (HA) Assignment", RFC 4433, 2123 DOI 10.17487/RFC4433, March 2006, 2124 . 2126 [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap 2127 for Transmission Control Protocol (TCP) Specification 2128 Documents", RFC 4614, DOI 10.17487/RFC4614, September 2129 2006, . 2131 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast 2132 Congestion Control (TFMCC): Protocol Specification", 2133 RFC 4654, DOI 10.17487/RFC4654, August 2006, 2134 . 2136 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 2137 Parameter for the Stream Control Transmission Protocol 2138 (SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007, 2139 . 2141 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2142 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 2143 . 2145 [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control 2146 (TFRC): The Small-Packet (SP) Variant", RFC 4828, 2147 DOI 10.17487/RFC4828, April 2007, 2148 . 2150 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 2151 "Authenticated Chunks for the Stream Control Transmission 2152 Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 2153 2007, . 2155 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2156 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2157 . 2159 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 2160 Kozuka, "Stream Control Transmission Protocol (SCTP) 2161 Dynamic Address Reconfiguration", RFC 5061, 2162 DOI 10.17487/RFC5061, September 2007, 2163 . 2165 [RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite 2166 protocol", RFC 5097, DOI 10.17487/RFC5097, January 2008, 2167 . 2169 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2170 (TLS) Protocol Version 1.2", RFC 5246, 2171 DOI 10.17487/RFC5246, August 2008, 2172 . 2174 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 2175 the Datagram Congestion Control Protocol (DCCP)", 2176 RFC 5238, DOI 10.17487/RFC5238, May 2008, 2177 . 2179 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 2180 Friendly Rate Control (TFRC): Protocol Specification", 2181 RFC 5348, DOI 10.17487/RFC5348, September 2008, 2182 . 2184 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 2185 DOI 10.17487/RFC5461, February 2009, 2186 . 2188 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 2189 (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, 2190 September 2009, . 2192 [RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol 2193 (DCCP) Simultaneous-Open Technique to Facilitate NAT/ 2194 Middlebox Traversal", RFC 5596, DOI 10.17487/RFC5596, 2195 September 2009, . 2197 [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 2198 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate 2199 Control for Small Packets (TFRC-SP)", RFC 5622, 2200 DOI 10.17487/RFC5622, August 2009, 2201 . 2203 [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding 2204 Transport (LCT) Building Block", RFC 5651, 2205 DOI 10.17487/RFC5651, October 2009, 2206 . 2208 [RFC5672] Crocker, D., Ed., "RFC 4871 DomainKeys Identified Mail 2209 (DKIM) Signatures -- Update", RFC 5672, 2210 DOI 10.17487/RFC5672, August 2009, 2211 . 2213 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 2214 "NACK-Oriented Reliable Multicast (NORM) Transport 2215 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 2216 . 2218 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 2219 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 2220 DOI 10.17487/RFC5775, April 2010, 2221 . 2223 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 2224 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 2225 . 2227 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 2228 Protocol Port Randomization", BCP 156, RFC 6056, 2229 DOI 10.17487/RFC6056, January 2011, 2230 . 2232 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 2233 Transport Layer Security (DTLS) for Stream Control 2234 Transmission Protocol (SCTP)", RFC 6083, 2235 DOI 10.17487/RFC6083, January 2011, 2236 . 2238 [RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the 2239 TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, 2240 January 2011, . 2242 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 2243 Transmission Protocol (SCTP) Stream Reconfiguration", 2244 RFC 6525, DOI 10.17487/RFC6525, February 2012, 2245 . 2247 [RFC6546] Trammell, B., "Transport of Real-time Inter-network 2248 Defense (RID) Messages over HTTP/TLS", RFC 6546, 2249 DOI 10.17487/RFC6546, April 2012, 2250 . 2252 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2253 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2254 January 2012, . 2256 [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled 2257 Congestion Control for Multipath Transport Protocols", 2258 RFC 6356, DOI 10.17487/RFC6356, October 2011, 2259 . 2261 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 2262 Correction (FEC) Framework", RFC 6363, 2263 DOI 10.17487/RFC6363, October 2011, 2264 . 2266 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 2267 Yasevich, "Sockets API Extensions for the Stream Control 2268 Transmission Protocol (SCTP)", RFC 6458, 2269 DOI 10.17487/RFC6458, December 2011, 2270 . 2272 [RFC6584] Roca, V., "Simple Authentication Schemes for the 2273 Asynchronous Layered Coding (ALC) and NACK-Oriented 2274 Reliable Multicast (NORM) Protocols", RFC 6584, 2275 DOI 10.17487/RFC6584, April 2012, 2276 . 2278 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 2279 "FLUTE - File Delivery over Unidirectional Transport", 2280 RFC 6726, DOI 10.17487/RFC6726, November 2012, 2281 . 2283 [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A 2284 Datagram Congestion Control Protocol UDP Encapsulation for 2285 NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November 2286 2012, . 2288 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 2289 "TCP Extensions for Multipath Operation with Multiple 2290 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 2291 . 2293 [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application 2294 Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, 2295 March 2013, . 2297 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 2298 UDP Checksums for Tunneled Packets", RFC 6935, 2299 DOI 10.17487/RFC6935, April 2013, 2300 . 2302 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 2303 for the Use of IPv6 UDP Datagrams with Zero Checksums", 2304 RFC 6936, DOI 10.17487/RFC6936, April 2013, 2305 . 2307 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 2308 Control Transmission Protocol (SCTP) Packets for End-Host 2309 to End-Host Communication", RFC 6951, 2310 DOI 10.17487/RFC6951, May 2013, 2311 . 2313 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 2314 IMMEDIATELY Extension for the Stream Control Transmission 2315 Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, 2316 . 2318 [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP 2319 Framework: Why RTP Does Not Mandate a Single Media 2320 Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2321 2014, . 2323 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2324 Protocol (HTTP/1.1): Message Syntax and Routing", 2325 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2326 . 2328 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2329 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2330 DOI 10.17487/RFC7231, June 2014, 2331 . 2333 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2334 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 2335 DOI 10.17487/RFC7232, June 2014, 2336 . 2338 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 2339 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 2340 RFC 7233, DOI 10.17487/RFC7233, June 2014, 2341 . 2343 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 2344 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 2345 RFC 7234, DOI 10.17487/RFC7234, June 2014, 2346 . 2348 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2349 Protocol (HTTP/1.1): Authentication", RFC 7235, 2350 DOI 10.17487/RFC7235, June 2014, 2351 . 2353 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 2354 "Transport Layer Security (TLS) Application-Layer Protocol 2355 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 2356 July 2014, . 2358 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 2359 Scheffenegger, Ed., "TCP Extensions for High Performance", 2360 RFC 7323, DOI 10.17487/RFC7323, September 2014, 2361 . 2363 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 2364 Known Attacks on Transport Layer Security (TLS) and 2365 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 2366 February 2015, . 2368 [RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, 2369 "Additional Policies for the Partially Reliable Stream 2370 Control Transmission Protocol Extension", RFC 7496, 2371 DOI 10.17487/RFC7496, April 2015, 2372 . 2374 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2375 "Recommendations for Secure Use of Transport Layer 2376 Security (TLS) and Datagram Transport Layer Security 2377 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2378 2015, . 2380 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 2381 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 2382 DOI 10.17487/RFC7540, May 2015, 2383 . 2385 [I-D.ietf-tsvwg-rfc5405bis] 2386 Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2387 Guidelines", draft-ietf-tsvwg-rfc5405bis-07 (work in 2388 progress), November 2015. 2390 [I-D.ietf-aqm-ecn-benefits] 2391 Fairhurst, G. and M. Welzl, "The Benefits of using 2392 Explicit Congestion Notification (ECN)", draft-ietf-aqm- 2393 ecn-benefits-07 (work in progress), November 2015. 2395 [I-D.ietf-tsvwg-sctp-dtls-encaps] 2396 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 2397 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 2398 dtls-encaps-09 (work in progress), January 2015. 2400 [I-D.ietf-tsvwg-sctp-ndata] 2401 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 2402 "Stream Schedulers and User Message Interleaving for the 2403 Stream Control Transmission Protocol", draft-ietf-tsvwg- 2404 sctp-ndata-04 (work in progress), July 2015. 2406 [I-D.ietf-tsvwg-sctp-failover] 2407 Nishida, Y., Natarajan, P., Caro, A., Amer, P., and K. 2408 Nielsen, "SCTP-PF: Quick Failover Algorithm in SCTP", 2409 draft-ietf-tsvwg-sctp-failover-13 (work in progress), 2410 September 2015. 2412 [I-D.ietf-tsvwg-natsupp] 2413 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 2414 Transmission Protocol (SCTP) Network Address Translation 2415 Support", draft-ietf-tsvwg-natsupp-08 (work in progress), 2416 July 2015. 2418 [XHR] van Kesteren, A., Aubourg, J., Song, J., and H. Steen, 2419 "XMLHttpRequest working draft 2420 (http://www.w3.org/TR/XMLHttpRequest/)", 2000. 2422 [REST] Fielding, R., "Architectural Styles and the Design of 2423 Network-based Software Architectures, Ph. D. (UC Irvine), 2424 Chapter 5: Representational State Transfer", 2000. 2426 [POSIX] 1-2008, IEEE., "IEEE Standard for Information Technology 2427 -- Portable Operating System Interface (POSIX) Base 2428 Specifications, Issue 7", n.d.. 2430 [MBMS] 3GPP TSG WS S4, ., "3GPP TS 26.346: Multimedia Broadcast/ 2431 Multicast Service (MBMS); Protocols and codecs, release 13 2432 (http://www.3gpp.org/DynaReport/26346.htm).", 2015. 2434 [ClarkArch] 2435 Clark, D. and D. Tennenhouse, "Architectural 2436 Considerations for a New Generation of Protocols (Proc. 2437 ACM SIGCOMM)", 1990. 2439 Authors' Addresses 2441 Godred Fairhurst (editor) 2442 University of Aberdeen 2443 School of Engineering, Fraser Noble Building 2444 Aberdeen AB24 3UE 2446 Email: gorry@erg.abdn.ac.uk 2448 Brian Trammell (editor) 2449 ETH Zurich 2450 Gloriastrasse 35 2451 8092 Zurich 2452 Switzerland 2454 Email: ietf@trammell.ch 2456 Mirja Kuehlewind (editor) 2457 ETH Zurich 2458 Gloriastrasse 35 2459 8092 Zurich 2460 Switzerland 2462 Email: mirja.kuehlewind@tik.ee.ethz.ch