idnits 2.17.1 draft-ietf-taps-transports-05.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 247: '... [EDITOR'S NOTE: add URGENT and PUSH flag (note [RFC6093] says SHOULD...' RFC 2119 keyword, line 809: '...A DCCP interface MAY allow application...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 09, 2015) is 3237 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0791' is defined on line 1461, but no explicit reference was found in the text == Unused Reference: 'RFC3390' is defined on line 1506, but no explicit reference was found in the text == Unused Reference: 'RFC5348' is defined on line 1577, but no explicit reference was found in the text == Unused Reference: 'RFC5925' is defined on line 1608, but no explicit reference was found in the text == Unused Reference: 'RFC5681' is defined on line 1611, but no explicit reference was found in the text == Unused Reference: 'RFC6298' is defined on line 1629, but no explicit reference was found in the text == Unused Reference: 'RFC6347' is defined on line 1633, but no explicit reference was found in the text == Unused Reference: 'RFC6691' is defined on line 1647, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 896 (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 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 3452 (Obsoleted by RFC 5052, RFC 5445) -- 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 5405 (Obsoleted by RFC 8085) -- 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 6691 (Obsoleted by RFC 9293) -- 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 (-08) exists of draft-ietf-aqm-ecn-benefits-00 == Outdated reference: A later version (-13) exists of draft-ietf-tsvwg-sctp-ndata-03 == Outdated reference: A later version (-23) exists of draft-ietf-tsvwg-natsupp-07 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 26 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Fairhurst, Ed. 3 Internet-Draft University of Aberdeen 4 Intended status: Informational B. Trammell, Ed. 5 Expires: December 11, 2015 M. Kuehlewind, Ed. 6 ETH Zurich 7 June 09, 2015 9 Services provided by IETF transport protocols and congestion control 10 mechanisms 11 draft-ietf-taps-transports-05 13 Abstract 15 This document describes services provided by existing IETF protocols 16 and congestion control mechanisms. It is designed to help 17 application and network stack programmers and to inform the work of 18 the IETF TAPS Working Group. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 11, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Existing Transport Protocols . . . . . . . . . . . . . . . . 4 57 3.1. Transport Control Protocol (TCP) . . . . . . . . . . . . 4 58 3.1.1. Protocol Description . . . . . . . . . . . . . . . . 5 59 3.1.2. Interface description . . . . . . . . . . . . . . . . 6 60 3.1.3. Transport Protocol Components . . . . . . . . . . . . 6 61 3.2. Multipath TCP (MPTCP) . . . . . . . . . . . . . . . . . . 7 62 3.2.1. Protocol Description . . . . . . . . . . . . . . . . 7 63 3.2.2. Interface Description . . . . . . . . . . . . . . . . 7 64 3.2.3. Transport Protocol Components . . . . . . . . . . . . 8 65 3.3. Stream Control Transmission Protocol (SCTP) . . . . . . . 9 66 3.3.1. Protocol Description . . . . . . . . . . . . . . . . 9 67 3.3.2. Interface Description . . . . . . . . . . . . . . . . 11 68 3.3.3. Transport Protocol Components . . . . . . . . . . . . 13 69 3.4. User Datagram Protocol (UDP) . . . . . . . . . . . . . . 13 70 3.4.1. Protocol Description . . . . . . . . . . . . . . . . 14 71 3.4.2. Interface Description . . . . . . . . . . . . . . . . 14 72 3.4.3. Transport Protocol Components . . . . . . . . . . . . 15 73 3.5. Lightweight User Datagram Protocol (UDP-Lite) . . . . . . 15 74 3.5.1. Protocol Description . . . . . . . . . . . . . . . . 15 75 3.5.2. Interface Description . . . . . . . . . . . . . . . . 16 76 3.5.3. Transport Protocol Components . . . . . . . . . . . . 16 77 3.6. Datagram Congestion Control Protocol (DCCP) . . . . . . . 17 78 3.6.1. Protocol Description . . . . . . . . . . . . . . . . 17 79 3.6.2. Interface Description . . . . . . . . . . . . . . . . 19 80 3.6.3. Transport Protocol Components . . . . . . . . . . . . 19 81 3.7. Realtime Transport Protocol (RTP) . . . . . . . . . . . . 19 82 3.8. NACK-Oriented Reliable Multicast (NORM) . . . . . . . . . 20 83 3.8.1. Protocol Description . . . . . . . . . . . . . . . . 20 84 3.8.2. Interface Description . . . . . . . . . . . . . . . . 21 85 3.8.3. Transport Protocol Components . . . . . . . . . . . . 21 86 3.9. Transport Layer Security (TLS) and Datagram TLS (DTLS) as 87 a pseudotransport . . . . . . . . . . . . . . . . . . . . 22 88 3.9.1. Protocol Description . . . . . . . . . . . . . . . . 23 89 3.9.2. Interface Description . . . . . . . . . . . . . . . . 23 90 3.10. Hypertext Transport Protocol (HTTP) over TCP as a 91 pseudotransport . . . . . . . . . . . . . . . . . . . . . 24 92 3.10.1. Protocol Description . . . . . . . . . . . . . . . . 25 93 3.10.2. Interface Description . . . . . . . . . . . . . . . 26 94 3.10.3. Transport Protocol Components . . . . . . . . . . . 26 95 3.11. WebSockets . . . . . . . . . . . . . . . . . . . . . . . 27 96 3.11.1. Protocol Description . . . . . . . . . . . . . . . . 27 97 3.11.2. Interface Description . . . . . . . . . . . . . . . 27 98 3.11.3. Transport Protocol Components . . . . . . . . . . . 27 99 4. Transport Service Features . . . . . . . . . . . . . . . . . 27 100 4.1. Complete Protocol Feature Matrix . . . . . . . . . . . . 29 101 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 102 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 103 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 104 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 105 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 106 9.1. Normative References . . . . . . . . . . . . . . . . . . 32 107 9.2. Informative References . . . . . . . . . . . . . . . . . 32 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 110 1. Introduction 112 Most Internet applications make use of the Transport Services 113 provided by TCP (a reliable, in-order stream protocol) or UDP (an 114 unreliable datagram protocol). We use the term "Transport Service" 115 to mean the end-to-end service provided to an application by the 116 transport layer. That service can only be provided correctly if 117 information about the intended usage is supplied from the 118 application. The application may determine this information at 119 design time, compile time, or run time, and may include guidance on 120 whether a feature is required, a preference by the application, or 121 something in between. Examples of features of Transport Services are 122 reliable delivery, ordered delivery, content privacy to in-path 123 devices, integrity protection, and minimal latency. 125 The IETF has defined a wide variety of transport protocols beyond TCP 126 and UDP, including SCTP, DCCP, MP-TCP, and UDP-Lite. Transport 127 services may be provided directly by these transport protocols, or 128 layered on top of them using protocols such as WebSockets (which runs 129 over TCP), RTP (over TCP or UDP) or WebRTC data channels (which run 130 over SCTP over DTLS over UDP or TCP). Services built on top of UDP 131 or UDP-Lite typically also need to specify additional mechanisms, 132 including a congestion control mechanism (such as a windowed 133 congestion control, TFRC or LEDBAT congestion control mechanism). 134 This extends the set of available Transport Services beyond those 135 provided to applications by TCP and UDP. 137 Transport protocols can also be differentiated by the features of the 138 services they provide: for instance, SCTP offers a message-based 139 service providing full or partial reliability and allowing to 140 minimize the head of line blocking due to the support of unordered 141 and unordered message delivery within multiple streams, UDP-Lite 142 provides partial integrity protection, and LEDBAT can provide low- 143 priority "scavenger" communication. 145 2. Terminology 147 The following terms are defined throughout this document, and in 148 subsequent documents produced by TAPS describing the composition and 149 decomposition of transport services. 151 [EDITOR'S NOTE: we may want to add definitions for the different 152 kinds of interfaces that are important here.] 154 Transport Service Feature: a specific end-to-end feature that a 155 transport service provides to its clients. Examples include 156 confidentiality, reliable delivery, ordered delivery, message- 157 versus-stream orientation, etc. 159 Transport Service: a set of transport service features, without an 160 association to any given framing protocol, which provides a 161 complete service to an application. 163 Transport Protocol: an implementation that provides one or more 164 different transport services using a specific framing and header 165 format on the wire. 167 Transport Protocol Component: an implementation of a transport 168 service feature within a protocol. 170 Transport Service Instance: an arrangement of transport protocols 171 with a selected set of features and configuration parameters that 172 implements a single transport service, e.g. a protocol stack (RTP 173 over UDP). 175 Application: an entity that uses the transport layer for end-to-end 176 delivery data across the network (this may also be an upper layer 177 protocol or tunnel encapsulation). 179 3. Existing Transport Protocols 181 This section provides a list of known IETF transport protocol and 182 transport protocol frameworks. 184 [EDITOR'S NOTE: Contributions to the subsections below are welcome] 186 3.1. Transport Control Protocol (TCP) 188 TCP is an IETF standards track transport protocol. [RFC0793] 189 introduces TCP as follows: "The Transmission Control Protocol (TCP) 190 is intended for use as a highly reliable host-to-host protocol 191 between hosts in packet-switched computer communication networks, and 192 in interconnected systems of such networks." Since its introduction, 193 TCP has become the default connection-oriented, stream-based 194 transport protocol in the Internet. It is widely implemented by 195 endpoints and widely used by common applications. 197 3.1.1. Protocol Description 199 TCP is a connection-oriented protocol, providing a three way 200 handshake to allow a client and server to set up a connection, and 201 mechanisms for orderly completion and immediate teardown of a 202 connection. TCP is defined by a family of RFCs [RFC4614]. 204 TCP provides multiplexing to multiple sockets on each host using port 205 numbers. An active TCP session is identified by its four-tuple of 206 local and remote IP addresses and local port and remote port numbers. 207 The destination port during connection setup has a different role as 208 it is often used to indicate the requested service. 210 TCP partitions a continuous stream of bytes into segments, sized to 211 fit in IP packets. ICMP-based PathMTU discovery [RFC1191][RFC1981] 212 as well as Packetization Layer Path MTU Discovery (PMTUD) [RFC4821] 213 are supported. 215 Each byte in the stream is identified by a sequence number. The 216 sequence number is used to order segments on receipt, to identify 217 segments in acknowledgments, and to detect unacknowledged segments 218 for retransmission. This is the basis of TCP's reliable, ordered 219 delivery of data in a stream. TCP Selective Acknowledgment [RFC2018] 220 extends this mechanism by making it possible to identify missing 221 segments more precisely, reducing spurious retransmission. 223 Receiver flow control is provided by a sliding window: limiting the 224 amount of unacknowledged data that can be outstanding at a given 225 time. The window scale option [RFC7323] allows a receiver to use 226 windows greater than 64KB. 228 All TCP senders provide Congestion Control: This uses a separate 229 window, where each time congestion is detected, this congestion 230 window is reduced. A receiver detects congestion using one of three 231 mechanisms: A retransmission timer, detection of loss (interpreted as 232 a congestion signal), or Explicit Congestion Notification (ECN) 233 [RFC3168] to provide early signaling (see 234 [I-D.ietf-aqm-ecn-benefits]) 236 A TCP protocol instance can be extended [RFC4614] and tuned. Some 237 features are sender-side only, requiring no negotiation with the 238 receiver; some are receiver-side only, some are explicitly negotiated 239 during connection setup. 241 By default, TCP segment partitioning uses Nagle's algorithm [RFC0896] 242 to buffer data at the sender into large segments, potentially 243 incurring sender-side buffering delay; this algorithm can be disabled 244 by the sender to transmit more immediately, e.g. to enable smoother 245 interactive sessions. 247 [EDITOR'S NOTE: add URGENT and PUSH flag (note [RFC6093] says SHOULD 248 NOT use due to the range of TCP implementations that process TCP 249 urgent indications differently.) ] 251 A checksum provides an Integrity Check and is mandatory across the 252 entire packet. The TCP checksum does not support partial corruption 253 protection as in DCCP/UDP-Lite). This check protects from 254 misdelivery of data corrupted data, but is relatively weak, and 255 applications that require end to end integrity of data are 256 recommended to include a stronger integrity check of their payload 257 data. 259 A TCP service is unicast. 261 3.1.2. Interface description 263 A User/TCP Interface is defined in [RFC0793] providing six user 264 commands: Open, Send, Receive, Close, Status. This interface does 265 not describe configuration of TCP options or parameters beside use of 266 the PUSH and URGENT flags. 268 In API implementations derived from the BSD Sockets API, TCP sockets 269 are created using the "SOCK_STREAM" socket type. 271 The features used by a protocol instance may be set and tuned via 272 this API. 274 (more on the API goes here) 276 3.1.3. Transport Protocol Components 278 The transport protocol components provided by TCP are: 280 o unicast 282 o connection setup with feature negotiation and application-to-port 283 mapping 285 o port multiplexing 287 o reliable delivery 288 o error detection (checksum) 290 o segmentation 292 o stream-oriented delivery in a single stream 294 o data bundling (Nagle's algorithm) 296 o flow control 298 o congestion control 300 [EDITOR'S NOTE: discussion of how to map this to features and TAPS: 301 what does the higher layer need to decide? what can the transport 302 layer decide based on global settings? what must the transport layer 303 decide based on network characteristics?] 305 3.2. Multipath TCP (MPTCP) 307 Multipath TCP [RFC6824] is an extension for TCP to support multi- 308 homing. It is designed to be as transparent as possible to middle- 309 boxes. It does so by establishing regular TCP flows between a pair 310 of source/destination endpoints, and multiplexing the application's 311 stream over these flows. 313 3.2.1. Protocol Description 315 MPTCP uses TCP options for its control plane. They are used to 316 signal multipath capabilities, as well as to negotiate data sequence 317 numbers, and advertise other available IP addresses and establish new 318 sessions between pairs of endpoints. 320 3.2.2. Interface Description 322 By default, MPTCP exposes the same interface as TCP to the 323 application. [RFC6897] however describes a richer API for MPTCP- 324 aware applications. 326 This Basic API describes how an application can - enable or disable 327 MPTCP; - bind a socket to one or more selected local endpoints; - 328 query local and remote endpoint addresses; - get a unique connection 329 identifier (similar to an address-port pair for TCP). 331 The document also recommend the use of extensions defined for SCTP 332 [RFC6458] (see next section) to deal with multihoming. 334 [AUTHOR'S NOTE: research work, and some implementation, also suggest 335 that the scheduling algorithm, as well as the path manager, are 336 configurable options that should be exposed to higher layer. Should 337 this be discussed here?] 339 3.2.3. Transport Protocol Components 341 [AUTHOR'S NOTE: shouldn't it be "service feature"?] 343 As an extension to TCP, MPTCP provides mostly the same components. 344 By establishing multiple sessions between available endpoints, it can 345 additionally provide soft failover solutions should one of the paths 346 become unusable. In addition, by multiplexing one byte stream over 347 separate paths, it can achieve a higher throughput than TCP in 348 certain situations (note however that coupled congestion control 349 [RFC6356] might limit this benefit to maintain fairness to other 350 flows at the bottleneck). When aggregating capacity over multiple 351 paths, and depending on the way packets are scheduled on each TCP 352 subflow, an additional delay and higher jitter might be observed 353 observed before in-order delivery of data to the applications. 355 The transport protocol components provided by MPTCP therefore are: 357 o unicast 359 o connection setup with feature negotiation and application-to-port 360 mapping 362 o port multiplexing 364 o reliable delivery 366 o error detection (checksum) 368 o segmentation 370 o stream-oriented delivery in a single stream 372 o flow control 374 o congestion control 376 o endpoint multiplexing of a single byte stream (higher throughput) 378 o resilience to network failure and/or handovers 380 [AUTHOR'S NOTE: it is unclear whether MPTCP has to provide data 381 bundling.] [AUTHOR'S NOTE: AF muliplexing? sub-flows can be started 382 over IPv4 or IPv6 for the same session] 384 3.3. Stream Control Transmission Protocol (SCTP) 386 SCTP is a message oriented standards track transport protocol and the 387 base protocol is specified in [RFC4960]. It supports multi-homing to 388 handle path failures. An SCTP association has multiple 389 unidirectional streams in each direction and provides in-sequence 390 delivery of user messages only within each stream. This allows to 391 minimize head of line blocking. SCTP is extensible and the currently 392 defined extensions include mechanisms for dynamic re-configurations 393 of streams [RFC6525] and IP-addresses [RFC5061]. Furthermore, the 394 extension specified in [RFC3758] introduces the concept of partial 395 reliability for user messages. 397 SCTP was originally developed for transporting telephony signalling 398 messages and is deployed in telephony signalling networks, especially 399 in mobile telephony networks. Additionally, it is used in the WebRTC 400 framework for data channels and is therefore deployed in all WEB- 401 browsers supporting WebRTC. 403 3.3.1. Protocol Description 405 SCTP is a connection oriented protocol using a four way handshake to 406 establish an SCTP association and a three way message exchange to 407 gracefully shut it down. It uses the same port number concept as 408 DCCP, TCP, UDP, and UDP-Lite do and only supports unicast. 410 SCTP uses the 32-bit CRC32c for protecting SCTP packets against bit 411 errors. This is stronger than the 16-bit checksums used by TCP or 412 UDP. However, a partial checksum coverage as provided by DCCP or 413 UDP-Lite is not supported. 415 SCTP has been designed with extensibility in mind. Each SCTP packet 416 starts with a single common header containing the port numbers, a 417 verification tag and the CRC32c checksum. This common header is 418 followed by a sequence of chunks. Each chunk consists of a type 419 field, flags, a length field and a value. [RFC4960] defines how a 420 receiver processes chunks with an unknown chunk type. The support of 421 extensions can be negotiated during the SCTP handshake. 423 SCTP provides a message-oriented service. Multiple small user 424 messages can be bundled into a single SCTP packet to improve the 425 efficiency. For example, this bundling may be done by delaying user 426 messages at the sender side similar to the Nagle algorithm used by 427 TCP. User messages which would result in IP packets larger than the 428 MTU will be fragmented at the sender side and reassembled at the 429 receiver side. There is no protocol limit on the user message size. 430 ICMP-based path MTU discovery as specified for IPv4 in [RFC1191] and 431 for IPv6 in [RFC1981] as well as packetization layer path MTU 432 discovery as specified in [RFC4821] with probe packets using the 433 padding chunks defined the [RFC4820] are supported. 435 [RFC4960] specifies a TCP friendly congestion control to protect the 436 network against overload. SCTP also uses a sliding window flow 437 control to protect receivers against overflow. 439 Each SCTP association has between 1 and 65536 uni-directional streams 440 in each direction. The number of streams can be different in each 441 direction. Every user-message is sent on a particular stream. User 442 messages can be sent un-ordered or ordered upon request by the upper 443 layer. Un-ordered messages can be delivered as soon as they are 444 completely received. Only all ordered messages sent on the same 445 stream are delivered at the receiver in the same order as sent by the 446 sender. For user messages not requiring fragmentation, this 447 minimises head of line blocking. The base protocol defined in 448 [RFC4960] doesn't allow interleaving of user-messages, which results 449 in sending a large message on one stream can block the sending of 450 user messages on other streams. [I-D.ietf-tsvwg-sctp-ndata] 451 overcomes this limitation. Furthermore, [I-D.ietf-tsvwg-sctp-ndata] 452 specifies multiple algorithms for the sender side selection of which 453 streams to send data from supporting a variety of scheduling 454 algorithms including priority based ones. The stream re- 455 configuration extension defined in [RFC6525] allows to reset streams 456 during the lifetime of an association and to increase the number of 457 streams, if the number of streams negotiated in the SCTP handshake is 458 not sufficient. 460 According to [RFC4960], each user message sent is either delivered to 461 the receiver or, in case of excessive retransmissions, the 462 association is terminated in a non-graceful way, similar to the TCP 463 behaviour. In addition to this reliable transfer, the partial 464 reliability extension defined in [RFC3758] allows the sender to 465 abandon user messages. The application can specify the policy for 466 abandoning user messages. Examples for these policies include: 468 o Limiting the time a user message is dealt with by the sender. 470 o Limiting the number of retransmissions for each fragment of a user 471 message. If the number of retransmissions is limited to 0, one 472 gets a service similar to UDP. 474 o Abandoning messages of lower priority in case of a send buffer 475 shortage. 477 SCTP supports multi-homing. Each SCTP end-point uses a list of IP- 478 addresses and a single port number. These addresses can be any 479 mixture of IPv4 and IPv6 addresses. These addresses are negotiated 480 during the handshake and the address re-configuration extension 481 specified in [RFC5061] in combination with [RFC4895] can be used to 482 change these addresses in an authenticated way during the livetime of 483 an SCTP association. This allows for transport layer mobility. 484 Multiple addresses are used for improved resilience. If a remote 485 address becomes unreachable, the traffic is switched over to a 486 reachable one, if one exists. Each SCTP end-point supervises 487 continuously the reachability of all peer addresses using a heartbeat 488 mechanism. 490 For securing user messages, the use of TLS over SCTP has been 491 specified in [RFC3436]. However, this solution does not support all 492 services provided by SCTP (for example un-ordered delivery or partial 493 reliability), and therefore the use of DTLS over SCTP has been 494 specified in [RFC6083] to overcome these limitations. When using 495 DTLS over SCTP, the application can use almost all services provided 496 by SCTP. 498 [I-D.ietf-tsvwg-natsupp] defines a methods for end-hosts and 499 middleboxes to provide for NAT support for SCTP over IPv4. For 500 legacy NAT traversal, [RFC6951] defines the UDP encapsulation of 501 SCTP-packets. Alternatively, SCTP packets can be encapsulated in 502 DTLS packets as specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. The 503 latter encapsulation is used with in the WebRTC context. 505 Having a well defined API is also a feature provided by SCTP as 506 described in the next subsection. 508 3.3.2. Interface Description 510 [RFC4960] defines an abstract API for the base protocol. An 511 extension to the BSD Sockets API is defined in [RFC6458] and covers: 513 o the base protocol defined in [RFC4960]. 515 o the SCTP Partial Reliability extension defined in [RFC3758]. 517 o the SCTP Authentication extension defined in [RFC4895]. 519 o the SCTP Dynamic Address Reconfiguration extension defined in 520 [RFC5061]. 522 For the following SCTP protocol extensions the BSD Sockets API 523 extension is defined in the document specifying the protocol 524 extensions: 526 o the SCTP SACK-IMMEDIATELY extension defined in [RFC7053]. 528 o the SCTP Stream Reconfiguration extension defined in [RFC6525]. 530 o the UDP Encapsulation of SCTP packets extension defined in 531 [RFC6951]. 533 o the additional PR-SCTP policies defined in 534 [I-D.ietf-tsvwg-sctp-prpolicies]. 536 Future documents describing SCTP protocol extensions are expected to 537 describe the corresponding BSD Sockets API extension in a "Socket API 538 Considerations" section. 540 The SCTP socket API supports two kinds of sockets: 542 o one-to-one style sockets (by using the socket type "SOCK_STREAM"). 544 o one-to-many style socket (by using the socket type 545 "SOCK_SEQPACKET"). 547 One-to-one style sockets are similar to TCP sockets, there is a 1:1 548 relationship between the sockets and the SCTP associations (except 549 for listening sockets). One-to-many style SCTP sockets are similar 550 to unconnected UDP sockets as there is a 1:n relationship between the 551 sockets and the SCTP associations. 553 The SCTP stack can provide information to the applications about 554 state changes of the individual paths and the association whenever 555 they occur. These events are delivered similar to user messages but 556 are specifically marked as notifications. 558 A couple of new functions have been introduced to support the use of 559 multiple local and remote addresses. Additional SCTP-specific send 560 and receive calls have been defined to allow dealing with the SCTP 561 specific information without using ancillary data in the form of 562 additional cmsgs, which are also defined. These functions provide 563 support for detecting partial delivery of user messages and 564 notifications. 566 The SCTP socket API allows a fine-grained control of the protocol 567 behaviour through an extensive set of socket options. 569 The SCTP kernel implementations of FreeBSD, Linux and Solaris follow 570 mostly the specified extension to the BSD Sockets API for the base 571 protocol and the corresponding supported protocol extensions. 573 3.3.3. Transport Protocol Components 575 The transport protocol components provided by SCTP are: 577 o unicast 579 o connection setup with feature negotiation and application-to-port 580 mapping 582 o port multiplexing 584 o reliable or partially reliable delivery 586 o ordered and unordered delivery within a stream 588 o support for multiple concurrent streams 590 o support for stream scheduling prioritization 592 o flow control 594 o message-oriented delivery 596 o congestion control 598 o user message bundling 600 o user message fragmentation and reassembly 602 o strong error detection (CRC32C) 604 o transport layer multihoming for resilience 606 o transport layer mobility 608 [EDITOR'S NOTE: update this list.] 610 3.4. User Datagram Protocol (UDP) 612 The User Datagram Protocol (UDP) [RFC0768] [RFC2460] is an IETF 613 standards track transport protocol. It provides a uni-directional, 614 datagram protocol which preserves message boundaries. It provides 615 none of the following transport features: error correction, 616 congestion control, or flow control. It can be used to send 617 broadcast datagrams (IPv4) or multicast datagrams (IPv4 and IPv6), in 618 addition to unicast (and anycast) datagrams. IETF guidance on the 619 use of UDP is provided in[RFC5405]. UDP is widely implemented and 620 widely used by common applications, especially DNS. 622 3.4.1. Protocol Description 624 UDP is a connection-less protocol which maintains message boundaries, 625 with no connection setup or feature negotiation. The protocol uses 626 independent messages, ordinarily called datagrams. The lack of error 627 control and flow control implies messages may be damaged, re-ordered, 628 lost, or duplicated in transit. A receiving application unable to 629 run sufficiently fast or frequently may miss messages. The lack of 630 congestion handling implies UDP traffic may cause the loss of 631 messages from other protocols (e.g., TCP) when sharing the same 632 network paths. UDP traffic can also cause the loss of other UDP 633 traffic in the same or other flows for the same reasons. 635 Messages with bit errors are ordinarily detected by an invalid end- 636 to-end checksum and are discarded before being delivered to an 637 application. There are some exceptions to this general rule, 638 however. UDP-Lite (see [RFC3828], and below) provides the ability 639 for portions of the message contents to be exempt from checksum 640 coverage. It is also possible to create UDP datagrams with no 641 checksum, and while this is generally discouraged [RFC1122] 642 [RFC5405], certain special cases permit its use [RFC6935]. The 643 checksum support considerations for omitting the checksum are defined 644 in [RFC6936]. Note that due to the relatively weak form of checksum 645 used by UDP, applications that require end to end integrity of data 646 are recommended to include a stronger integrity check of their 647 payload data. 649 On transmission, UDP encapsulates each datagram into an IP packet, 650 which may in turn be fragmented by IP. Applications concerned with 651 fragmentation or that have other requirements such as receiver flow 652 control, congestion control, PathMTU discovery/PLPMTUD, support for 653 ECN, etc need to be provided by protocols other than UDP [RFC5405]. 655 3.4.2. Interface Description 657 [RFC0768] describes basic requirements for an API for UDP. Guidance 658 on use of common APIs is provided in [RFC5405]. 660 A UDP endpoint consists of a tuple of (IP address, port number). 661 Demultiplexing using multiple abstract endpoints (sockets) on the 662 same IP address are supported. The same socket may be used by a 663 single server to interact with multiple clients (note: this behavior 664 differs from TCP, which uses a pair of tuples to identify a 665 connection). Multiple server instances (processes) binding the same 666 socket can cooperate to service multiple clients- the socket 667 implementation arranges to not duplicate the same received unicast 668 message to multiple server processes. 670 Many operating systems also allow a UDP socket to be "connected", 671 i.e., to bind a UDP socket to a specific (remote) UDP endpoint. 672 Unlike TCP's connect primitive, for UDP, this is only a local 673 operation that serves to simplify the local send/receive functions 674 and to filter the traffic for the specified addresses and ports 675 [RFC5405]. 677 3.4.3. Transport Protocol Components 679 The transport protocol components provided by UDP are: 681 o unidirectional 683 o port multiplexing 685 o 2-tuple endpoints 687 o IPv4 broadcast, multicast and anycast 689 o IPv6 multicast and anycast 691 o IPv6 jumbograms 693 o message-oriented delivery 695 o error detection (checksum) 697 o checksum optional 699 3.5. Lightweight User Datagram Protocol (UDP-Lite) 701 The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] is an 702 IETF standards track transport protocol. UDP-Lite provides a 703 bidirectional set of logical unicast or multicast message streams 704 over a datagram protocol. IETF guidance on the use of UDP-Lite is 705 provided in [RFC5405]. 707 3.5.1. Protocol Description 709 UDP-Lite is a connection-less datagram protocol, with no connection 710 setup or feature negotiation. The protocol use messages, rather than 711 a byte-stream. Each stream of messages is independently managed, 712 therefore retransmission does not hold back data sent using other 713 logical streams. 715 It provides multiplexing to multiple sockets on each host using port 716 numbers. An active UDP-Lite session is identified by its four-tuple 717 of local and remote IP addresses and local port and remote port 718 numbers. 720 UDP-Lite fragments packets into IP packets, constrained by the 721 maximum size of IP packet. 723 UDP-Lite changes the semantics of the UDP "payload length" field to 724 that of a "checksum coverage length" field. Otherwise, UDP-Lite is 725 semantically identical to UDP. Applications using UDP-Lite therefore 726 can not make assumptions regarding the correctness of the data 727 received in the insensitive part of the UDP-Lite payload. 729 As for UDP, mechanisms for receiver flow control, congestion control, 730 PMTU or PLPMTU discovery, support for ECN, etc need to be provided by 731 upper layer protocols [RFC5405]. 733 Examples of use include a class of applications that can derive 734 benefit from having partially-damaged payloads delivered, rather than 735 discarded. One use is to support error tolerate payload corruption 736 when used over paths that include error-prone links, another 737 application is when header integrity checks are required, but payload 738 integrity is provided by some other mechanism (e.g. [RFC6936]. 740 A UDP-Lite service may support IPv4 broadcast, multicast, anycast and 741 unicast. 743 3.5.2. Interface Description 745 There is no current API specified in the RFC Series, but guidance on 746 use of common APIs is provided in [RFC5405]. 748 The interface of UDP-Lite differs from that of UDP by the addition of 749 a single (socket) option that communicates a checksum coverage length 750 value: at the sender, this specifies the intended checksum coverage, 751 with the remaining unprotected part of the payload called the "error- 752 insensitive part". The checksum coverage may also be made visible to 753 the application via the UDP-Lite MIB module [RFC5097]. 755 3.5.3. Transport Protocol Components 757 The transport protocol components provided by UDP-Lite are: 759 o unicast 761 o IPv4 broadcast, multicast and anycast 763 o port multiplexing 764 o non-reliable, non-ordered delivery 766 o message-oriented delivery 768 o partial integrity protection 770 3.6. Datagram Congestion Control Protocol (DCCP) 772 Datagram Congestion Control Protocol (DCCP) [RFC4340] is an IETF 773 standards track bidirectional transport protocol that provides 774 unicast connections of congestion-controlled unreliable messages. 776 [EDITOR'S NOTE: Gorry Fairhurst signed up as a contributor for this 777 section.] 779 The DCCP Problem Statement describes the goals that DCCP sought to 780 address [RFC4336]. It is suitable for applications that transfer 781 fairly large amounts of data and that can benefit from control over 782 the trade off between timeliness and reliability [RFC4336]. 784 It offers low overhead, and many characteristics common to UDP, but 785 can avoid "Re-inventing the wheel" each time a new multimedia 786 application emerges. Specifically it includes core functions 787 (feature negotiation, path state management, RTT calculation, PMTUD, 788 etc): This allows applications to use a compatible method defining 789 how they send packets and where suitable to choose common algorithms 790 to manage their functions. Examples of suitable applications include 791 interactive applications, streaming media or on-line games [RFC4336]. 793 3.6.1. Protocol Description 795 DCCP is a connection-oriented datagram protocol, providing a three 796 way handshake to allow a client and server to set up a connection, 797 and mechanisms for orderly completion and immediate teardown of a 798 connection. The protocol is defined by a family of RFCs. 800 It provides multiplexing to multiple sockets on each host using port 801 numbers. An active DCCP session is identified by its four-tuple of 802 local and remote IP addresses and local port and remote port numbers. 803 At connection setup, DCCP also exchanges the the service code 804 [RFC5595] mechanism to allow transport instantiations to indicate the 805 service treatment that is expected from the network. 807 The protocol segments data into messages, typically sized to fit in 808 IP packets, but which may be fragmented providing they are less than 809 the A DCCP interface MAY allow applications to request fragmentation 810 for packets larger than PMTU, but not larger than the maximum packet 811 size allowed by the current congestion control mechanism (CCMPS) 812 [RFC4340]. 814 Each message is identified by a sequence number. The sequence number 815 is used to identify segments in acknowledgments, to detect 816 unacknowledged segments, to measure RTT, etc. The protocol may 817 support ordered or unordered delivery of data, and does not itself 818 provide retransmission. There is a Data Checksum option, which 819 contains a strong CRC, lets endpoints detect application data 820 corruption. It also supports reduced checksum coverage, a partial 821 integrity mechanisms similar to UDP-lIte. 823 Receiver flow control is supported: limiting the amount of 824 unacknowledged data that can be outstanding at a given time. 826 A DCCP protocol instance can be extended [RFC4340] and tuned. Some 827 features are sender-side only, requiring no negotiation with the 828 receiver; some are receiver-side only, some are explicitly negotiated 829 during connection setup. 831 DCCP supports negotiation of the congestion control profile, to 832 provide Plug and Play congestion control mechanisms. examples of 833 specified profiles include [RFC4341] [RFC4342] [RFC5662]. All IETF- 834 defined methods provide Congestion Control. 836 DCCP use a Connect packet to start a session, and permits half- 837 connections that allow each client to choose features it wishes to 838 support. Simultaneous open [RFC5596], as in TCP, can enable 839 interoperability in the presence of middleboxes. The Connect packet 840 includes a Service Code field [RFC5595] designed to allow middle 841 boxes and endpoints to identify the characteristics required by a 842 session. A lightweight UDP-based encapsulation (DCCP-UDP) has been 843 defined [RFC6773] that permits DCCP to be used over paths where it is 844 not natively supported. Support in NAPT/NATs is defined in [RFC4340] 845 and [RFC5595]. 847 Upper layer protocols specified on top of DCCP include: DTLS 848 [RFC5595], RTP [RFC5672], ICE/SDP [RFC6773]. 850 A DCCP service is unicast. 852 A common packet format has allowed tools to evolve that can read and 853 interpret DCCP packets (e.g. Wireshark). 855 3.6.2. Interface Description 857 API characteristics include: - Datagram transmission. - Notification 858 of the current maximum packet size. - Send and reception of zero- 859 length payloads. - Set the Slow Receiver flow control at a receiver. 860 - Detect a Slow receiver at the sender. 862 There is no current API specified in the RFC Series. 864 3.6.3. Transport Protocol Components 866 The transport protocol components provided by DCCP are: 868 o unicast 870 o connection setup with feature negotiation and application-to-port 871 mapping 873 o Service Codes 875 o port multiplexing 877 o non-reliable, ordered delivery 879 o flow control (slow receiver function) 881 o drop notification 883 o timestamps 885 o message-oriented delivery 887 o partial integrity protection 889 3.7. Realtime Transport Protocol (RTP) 891 RTP provides an end-to-end network transport service, suitable for 892 applications transmitting real-time data, such as audio, video or 893 data, over multicast or unicast network services, including TCP, UDP, 894 UDP-Lite, DCCP. 896 [EDITOR'S NOTE: Varun Singh signed up as contributor for this 897 section. Given the complexity of RTP, suggest to have an abbreviated 898 section here contrasting RTP with other transports, and focusing on 899 those features that are RTP-unique.] 901 3.8. NACK-Oriented Reliable Multicast (NORM) 903 NORM is an IETF standards track protocol specified in [RFC5740]. The 904 protocol was designed to support reliable bulk data dissemination to 905 receiver groups using IP Multicast but also provides for point-to- 906 point unicast operation. Its support for bulk data dissemination 907 includes discrete file or computer memory-based "objects" as well as 908 byte- and message-streaming. NORM is designed to incorporate packet 909 erasure coding as an inherent part of its selective ARQ in response 910 to receiver negative acknowledgements. The packet erasure coding can 911 also be proactively applied for forward protection from packet loss. 912 NORM transmissions are governed by TCP-friendly congestion control. 913 NORM's reliability, congestion control, and flow control mechanism 914 are distinct components and can be separately controlled to meet 915 different application needs. 917 3.8.1. Protocol Description 919 [EDITOR'S NOTE: needs to be more clear about the application of FEC 920 and packet erasure coding; expand ARQ.] 922 The NORM protocol is encapsulated in UDP datagrams and thus provides 923 multiplexing for multiple sockets on hosts using port numbers. For 924 purposes of loosely coordinated IP Multicast, NORM is not strictly 925 connection-oriented although per-sender state is maintained by 926 receivers for protocol operation. [RFC5740] does not specify a 927 handshake protocol for connection establishment and separate session 928 initiation can be used to coordinate port numbers. However, in-band 929 "client-server" style connection establishment can be accomplished 930 with the NORM congestion control signaling messages using port 931 binding techniques like those for TCP client-server connections. 933 NORM supports bulk "objects" such as file or in-memory content but 934 also can treat a stream of data as a logical bulk object for purposes 935 of packet erasure coding. In the case of stream transport, NORM can 936 support either byte streams or message streams where application- 937 defined message boundary information is carried in the NORM protocol 938 messages. This allows the receiver(s) to join/re-join and recover 939 message boundaries mid-stream as needed. Application content is 940 carried and identified by the NORM protocol with encoding symbol 941 identifiers depending upon the Forward Error Correction (FEC) Scheme 942 [RFC3452] configured. NORM uses NACK-based selective ARQ to reliably 943 deliver the application content to the receiver(s). NORM proactively 944 measures round-trip timing information to scale ARQ timers 945 appropriately and to support congestion control. For multicast 946 operation, timer-based feedback suppression is uses to achieve group 947 size scaling with low feedback traffic levels. The feedback 948 suppression is not applied for unicast operation. 950 NORM uses rate-based congestion control based upon the TCP-Friendly 951 Rate Control (TFRC) [RFC4324] principles that are also used in DCCP 952 [RFC4340]. NORM uses control messages to measure RTT and collect 953 congestion event (e..g, loss event, ECN event, etc) information from 954 the receiver(s) to support dynamic rate control adjustment. The TCP- 955 Friendly Multicast Congestion Control (TFMCC) [RFC4654] used provides 956 some extra features to support multicast but is functionally 957 equivalent to TFRC in the unicast case. 959 NORM's reliability mechanism is decoupled from congestion control. 960 This allows alternative arrangements of transport services to be 961 invoked. For example, fixed-rate reliable delivery can be supported 962 or unreliable (but optionally "better than best effort" via packet 963 erasure coding) delivery with rate-control per TFRC can be achieved. 964 Additionally, alternative congestion control techniques may be 965 applied. For example, TFRC rate control with congestion event 966 detection based on ECN for links with high packet loss (e.g., 967 wireless) has been implemented and demonstrated with NORM. 969 While NORM is NACK-based for reliability transfer, it also supports a 970 positive acknowledgment (ACK) mechanism that can be used for receiver 971 flow control. Again, since this mechanism is decoupled from the 972 reliability and congestion control, applications that have different 973 needs in this aspect can use the protocol differently. One example 974 is the use of NORM for quasi-reliable delivery where timely delivery 975 of newer content may be favored over completely reliable delivery of 976 older content within buffering and RTT constraints. 978 3.8.2. Interface Description 980 The NORM specification does not describe a specific application 981 programming interface (API) to control protocol operation. A freely- 982 available, open source reference implementation of NORM is available 983 at https://www.nrl.navy.mil/itd/ncs/products/norm, and a documented 984 API is provided for this implementation. While a sockets-like API is 985 not currently documented, the existing API supports the necessary 986 functions for that to be implemented. 988 3.8.3. Transport Protocol Components 990 The transport protocol components provided by NORM are: 992 o unicast 994 o multicast 996 o port multiplexing (UDP ports) 997 o reliable delivery 999 o unordered delivery of in-memory data or file bulk content objects 1001 o error detection (UDP checksum) 1003 o segmentation 1005 o stream-oriented delivery in a single stream 1007 o object-oriented delivery of discrete data or file items 1009 o data bundling (Nagle's algorithm) 1011 o flow control (timer-based and/or ack-based) 1013 o congestion control 1015 o packet erasure coding (both proactively and as part of ARQ) 1017 3.9. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a 1018 pseudotransport 1020 Transport Layer Security (TLS) and Datagram TLS are IETF protocols 1021 that provide several security-related features to applications. TLS 1022 is designed to run on top of TCP, DTLS is designed to run on top of 1023 UDP. At the time of writing, the current version of TLS is 1.2; it 1024 is defined in [RFC5246]. DTLS provides nearly identical 1025 functionality; it is defined in {RFC6347}} and also at version 1.2. 1027 While older versions of TLS and DTLS are still in use, they provide 1028 weaker security guarantees. [RFC7457] outlines important attacks on 1029 TLS and DTLS. [RFC7525] is a Best Current Practices (BCP) document 1030 that describes secure configurations for TLS and DTLS to counter 1031 these attacks. The recommendations are applicable for the vast 1032 majority of use cases. 1034 [NOTE: The Logjam authors (weakdh.org) give (inconclusive) evidence 1035 that one of the recommendations of [RFC7525], namely use to DHE-1024 1036 as a fallback, may not be sufficient in all cases to counter an 1037 attacker with the resources of a nation-state. It is unclear at this 1038 time if the RFC is going to be updated as a result or whether there 1039 will be an RFC7525bis.] 1041 3.9.1. Protocol Description 1043 Both TLS and DTLS provide the same security features and can thus be 1044 discussed together. The features they provide are: 1046 o Confidentiality 1048 o Data integrity 1050 o Data authenticity 1052 o Optionally authentication of the peer entity 1054 [Note: Both TLS and DTLS provide replay protection, although it is 1055 optional in DTLS. The TLS RFC discusses this only in the security 1056 considerations and thus views it as a feature that is implicit in the 1057 ones listed above. DTLS mentions it as an explicit feature.] 1059 The authentication of the peer entity can be omitted, although this 1060 is a rare use case. In many use cases (e.g. the Web), authentication 1061 is not mutual, however (e.g. only the Web server is authenticated, 1062 but not the client). It is important to note that TLS itself does 1063 not specify how a peering entity is to be authenticated. This is 1064 part of the application logic; i.e. the authentication decision rests 1065 with the application. As an example, in the common use case of 1066 authentication by means of an X.509 certificate, it is the 1067 application's decision whether the certificate of the peering entity 1068 is acceptable for the purposes of the application or whether the 1069 handshake should be aborted. 1071 As DTLS is used over the unreliable UDP transport, it needs to add 1072 three features to provide the same security guarantees as TLS: * 1073 Message fragmentation * Message reordering * Message loss 1075 As a result, DTLS provides features that UDP lacks. 1077 [EDITOR'S NOTE: Need to describe how this is achieved?] 1079 3.9.2. Interface Description 1081 TLS is commonly used with a socket-like interface, although details 1082 can vary between implementations. This is particularly true for the 1083 choice which cryptographic algorithms to use, see below. 1085 [TODO: DTLS interface] 1086 Both TLS and DTLS allow to employ a multitude of cipher suites for 1087 encryption, hashing and applying message integrity. It is no easy 1088 task to choose safe settings here. [RFC7525] provides guidance. 1090 [TODO: list the RFCs?] [TODO: more detail?] ### Transport Protocol 1091 Components 1093 Both TLS and DTLS employ a layered architecture. The lower layer is 1094 commonly called the record protocol. It is responsible for 1095 fragmenting messages, applying message authentication codes (MACs), 1096 encrypting data, and sending it via the underlying transport 1097 protocol. Several essential protocols run on top of the record 1098 protocol in order to carry out the handshake and establish a secure 1099 session. 1101 [EDITOR'S NOTE: TLS can also compress, but this has been found to be 1102 a security weakness. It is not described here.] 1104 3.10. Hypertext Transport Protocol (HTTP) over TCP as a pseudotransport 1106 Hypertext Transfer Protocol (HTTP) is an application-level protocol 1107 widely used on the Internet. Version 1.1 of the protocol is 1108 specified in [RFC7230] [RFC7231] [RFC7232] [RFC7233] [RFC7234] 1109 [RFC7235], and version 2 in [RFC7540]. Furthermore, HTTP is used as 1110 a substrate for other application-layer protocols. There are various 1111 reasons for this practice listed in [RFC3205]; these include being a 1112 well-known and well-understood protocol, reusability of existing 1113 servers and client libraries, easy use of existing security 1114 mechanisms such as HTTP digest authentication [RFC2617] and TLS 1115 [RFC5246], the ability of HTTP to traverse firewalls which makes it 1116 work with a lot of infrastructure, and cases where a application 1117 server often needs to support HTTP anyway. 1119 Depending on application's needs, the use of HTTP as a substrate 1120 protocol may add complexity and overhead in comparison to a special- 1121 purpose protocol (e.g. HTTP headers, suitability of the HTTP 1122 security model etc.). [RFC3205] address this issues and provides 1123 some guidelines and concerns about the use of HTTP standard port 80 1124 and 443, the use of HTTP URL scheme and interaction with existing 1125 firewalls, proxies and NATs. 1127 Though not strictly bound to TCP, HTTP is almost exclusively run over 1128 TCP, and therefore inherits its properties when used in this way. 1130 3.10.1. Protocol Description 1132 Hypertext Transfer Protocol (HTTP) is a request/response protocol. A 1133 client sends a request containing a request method, URI and protocol 1134 version followed by a MIME-like message (see [RFC7231] for the 1135 differences between an HTTP object and a MIME message), containing 1136 information about the client and request modifiers. The message can 1137 contain a message body carrying application data as well. The server 1138 responds with a status or error code followed by a MIME-like message 1139 containing information about the server and information about carried 1140 data and it can include a message body. It is possible to specify a 1141 data format for the message body using MIME media types [RFC2045]. 1142 Furthermore, the protocol has numerous additional features; features 1143 relevant to pseudotransport are described below. 1145 Content negotiation, specified in [RFC7231], is a mechanism provided 1146 by HTTP for selecting a representation on a requested resource. The 1147 client and server negotiate acceptable data formats, charsets, data 1148 encoding (e.g. data can be transferred compressed, gzip), etc. HTTP 1149 can accommodate exchange of messages as well as data streaming (using 1150 chunked transfer encoding [RFC7230]). It is also possible to request 1151 a part of a resource using range requests specified in [RFC7233]. 1152 The protocol provides powerful cache control signalling defined in 1153 [RFC7234]. 1155 HTTP 1.1's and HTTP 2.0's persistent connections can be use to 1156 perform multiple request-response transactions during the life-time 1157 of a single HTTP connection. Moreover, HTTP 2.0 connections can 1158 multiplex many request/response pairs in parallel on a single 1159 connection. This reduces connection establishment overhead and the 1160 effect of TCP slow-start on each transaction, important for HTTP's 1161 primary use case. 1163 It is possible to combine HTTP with security mechanisms, like TLS 1164 (denoted by HTTPS), which adds protocol properties provided by such a 1165 mechanism (e.g. authentication, encryption, etc.). TLS's 1166 Application-Layer Protocol Negotiation (ALPN) extension [RFC7301] can 1167 be used for HTTP version negotiation within TLS handshake which 1168 eliminates addition round-trip. Arbitrary cookie strings, included 1169 as part of the MIME headers, are often used as bearer tokens in HTTP. 1171 Application layer protocols using HTTP as substrate may use existing 1172 method and data formats, or specify new methods and data formats. 1173 Furthermore some protocols may not fit a request/response paradigm 1174 and instead rely on HTTP to send messages (e.g. [RFC6546]). Because 1175 HTTP is working in many restricted infrastructures, it is also used 1176 to tunnel other application-layer protocols. 1178 3.10.2. Interface Description 1180 There are many HTTP libraries available exposing different APIs. The 1181 APIs provide a way to specify a request by providing a URI, a method, 1182 request modifiers and optionally a request body. For the response, 1183 callbacks can be registered that will be invoked when the response is 1184 received. If TLS is used, API expose a registration of callbacks in 1185 case a server requests client authentication and when certificate 1186 verification is needed. 1188 World Wide Web Consortium (W3C) standardized the XMLHttpRequest API 1189 [XHR], an API that can be use for sending HTTP/HTTPS requests and 1190 receiving server responses. Besides XML data format, request and 1191 response data format can also be JSON, HTML and plain text. 1192 Specifically JavaScript and XMLHttpRequest are a ubiquitous 1193 programming model for websites, and more general applications, where 1194 native code is less attractive. 1196 Representational State Transfer (REST) [REST] is another example how 1197 applications can use HTTP as transport protocol. REST is an 1198 architecture style for building application on the Internet. It uses 1199 HTTP as a communication protocol. 1201 3.10.3. Transport Protocol Components 1203 The transport protocol components provided by HTTP, when used as a 1204 pseudotransport, are: 1206 o unicast 1208 o reliable delivery 1210 o ordered delivery 1212 o message and stream-oriented 1214 o object range request 1216 o message content type negotiation 1218 o congestion control 1220 HTTPS (HTTP over TLS) additionally provides the following components: 1222 o authentication (of one or both ends of a connection) 1224 o confidentiality 1225 o integrity protection 1227 3.11. WebSockets 1229 [RFC6455] 1231 [EDITOR'S NOTE: Salvatore Loreto will contribute text for this 1232 section.] 1234 3.11.1. Protocol Description 1236 3.11.2. Interface Description 1238 3.11.3. Transport Protocol Components 1240 4. Transport Service Features 1242 The transport protocol components analyzed in this document which can 1243 be used as a basis for defining common transport service features, 1244 normalized and separated into categories, are as follows: 1246 o Destination selection 1248 * unicast 1250 * broadcast (IPv4 only) 1252 * multicast 1254 * anycast 1256 * transport layer multihoming for resilience 1258 * transport layer mobility 1260 * port multiplexing 1262 * service codes 1264 o Connection setup 1266 * connection setup with feature negotiation and application-to- 1267 port mapping 1269 o Delivery 1271 * reliable delivery 1272 * partially reliable delivery 1274 * unreliable delivery 1276 * packet erasure coding 1278 * ordered delivery 1280 * unordered delivery 1282 * stream-oriented delivery 1284 * message-oriented delivery 1286 * message fragmentation 1288 * object-oriented delivery of discrete data or file items 1290 * unordered delivery of in-memory data or file bulk content 1291 objects 1293 * object range request 1295 * object content type negotiation 1297 * single streaming 1299 * multiple streaming 1301 * stream scheduling prioritization 1303 * segmentation 1305 * data bundling (Nagle's algorithm) 1307 * message bundling 1309 o Transmission control 1311 * timer-based rate control 1313 * ack-based flow control 1315 * drop notification 1317 * packet erasure coding 1319 * congestion control 1321 o Integrity protection 1323 * checksum for error detection 1325 * partial checksum protection 1327 * checksum optional 1329 * cryptographic integrity protection 1331 o Security 1333 * authentication of one end of a connection 1335 * authentication of both ends of a connection 1337 * confidentiality 1339 The next revision of this document will define transport service 1340 features based upon this list. 1342 [EDITOR'S NOTE: this section will drawn from the candidate features 1343 provided by protocol components in the previous section - please 1344 discuss on taps@ietf.org list] 1346 4.1. Complete Protocol Feature Matrix 1348 [EDITOR'S NOTE: Dave Thaler has signed up as a contributor for this 1349 section. Michael Welzl also has a beginning of a matrix which could 1350 be useful here.] 1352 [EDITOR'S NOTE: The below is a strawman proposal below by Gorry 1353 Fairhurst for initial discussion] 1355 The table below summarises protocol mechanisms that have been 1356 standardised. It does not make an assessment on whether specific 1357 implementations are fully compliant to these specifications. 1359 +-----------------+---------+---------+---------+---------+---------+ 1360 | Mechanism | UDP | UDP-L | DCCP | SCTP | TCP | 1361 +-----------------+---------+---------+---------+---------+---------+ 1362 | Unicast | Yes | Yes | Yes | Yes | Yes | 1363 | | | | | | | 1364 | Mcast/IPv4Bcast | Yes(2) | Yes | No | No | No | 1365 | | | | | | | 1366 | Port Mux | Yes | Yes | Yes | Yes | Yes | 1367 | | | | | | | 1368 | Mode | Dgram | Dgram | Dgram | Dgram | Stream | 1369 | | | | | | | 1370 | Connected | No | No | Yes | Yes | Yes | 1371 | | | | | | | 1372 | Data bundling | No | No | No | Yes | Yes | 1373 | | | | | | | 1374 | Feature Nego | No | No | Yes | Yes | Yes | 1375 | | | | | | | 1376 | Options | No | No | Support | Support | Support | 1377 | | | | | | | 1378 | Data priority | * | * | * | Yes | No | 1379 | | | | | | | 1380 | Data bundling | No | No | No | Yes | Yes | 1381 | | | | | | | 1382 | Reliability | None | None | None | Select | Full | 1383 | | | | | | | 1384 | Ordered deliv | No | No | No | Stream | Yes | 1385 | | | | | | | 1386 | Corruption Tol. | No | Support | Support | No | No | 1387 | | | | | | | 1388 | Flow Control | No | No | Support | Yes | Yes | 1389 | | | | | | | 1390 | PMTU/PLPMTU | (1) | (1) | Yes | Yes | Yes | 1391 | | | | | | | 1392 | Cong Control | (1) | (1) | Yes | Yes | Yes | 1393 | | | | | | | 1394 | ECN Support | (1) | (1) | Yes | TBD | Yes | 1395 | | | | | | | 1396 | NAT support | Limited | Limited | Support | TBD | Support | 1397 | | | | | | | 1398 | Security | DTLS | DTLS | DTLS | DTLS | TLS, AO | 1399 | | | | | | | 1400 | UDP encaps | N/A | None | Yes | Yes | None | 1401 | | | | | | | 1402 | RTP support | Support | Support | Support | ? | Support | 1403 +-----------------+---------+---------+---------+---------+---------+ 1405 Note (1): this feature requires support in an upper layer protocol. 1407 Note (2): this feature requires support in an upper layer protocol 1408 when used with IPv6. 1410 5. IANA Considerations 1412 This document has no considerations for IANA. 1414 6. Security Considerations 1416 This document surveys existing transport protocols and protocols 1417 providing transport-like services. Confidentiality, integrity, and 1418 authenticity are among the features provided by those services. This 1419 document does not specify any new components or mechanisms for 1420 providing these features. Each RFC listed in this document discusses 1421 the security considerations of the specification it contains. 1423 7. Contributors 1425 [Editor's Note: turn this into a real contributors section with 1426 addresses once we figure out how to trick the toolchain into doing 1427 so] 1429 o Section 3.2 on MPTCP was contributed by Simone Ferlin-Oliviera 1430 (ferlin@simula.no) and Olivier Mehani 1431 (olivier.mehani@nicta.com.au) 1433 o Section 3.4 on UDP was contributed by Kevin Fall (kfall@kfall.com) 1435 o Section 3.3 on SCTP was contributed by Michael Tuexen (tuexen@fh- 1436 muenster.de) 1438 o Section 3.8 on NORM was contributed by Brian Adamson 1439 (brian.adamson@nrl.navy.mil) 1441 o Section 3.9 on MPTCP was contributed by Ralph Holz 1442 (ralph.holz@nicta.com.au) and Olivier Mehani 1443 (olivier.mehani@nicta.com.au) 1445 o Section 3.10 on HTTP was contributed by Dragana Damjanovic 1446 (ddamjanovic@mozilla.com) 1448 8. Acknowledgments 1450 Thanks to Karen Nielsen, Joe Touch, and Michael Welzl for the 1451 comments, feedback, and discussion. This work is partially supported 1452 by the European Commission under grant agreement FP7-ICT-318627 1453 mPlane; support does not imply endorsement. 1455 [EDITOR'S NOTE: add H2020-NEAT ack]. 1457 9. References 1459 9.1. Normative References 1461 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1462 1981. 1464 9.2. Informative References 1466 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1467 August 1980. 1469 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1470 793, September 1981. 1472 [RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", 1473 RFC 896, January 1984. 1475 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1476 Communication Layers", STD 3, RFC 1122, October 1989. 1478 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1479 November 1990. 1481 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 1482 for IP version 6", RFC 1981, August 1996. 1484 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 1485 Selective Acknowledgment Options", RFC 2018, October 1996. 1487 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1488 Extensions (MIME) Part One: Format of Internet Message 1489 Bodies", RFC 2045, November 1996. 1491 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1492 (IPv6) Specification", RFC 2460, December 1998. 1494 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1495 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1496 Authentication: Basic and Digest Access Authentication", 1497 RFC 2617, June 1999. 1499 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1500 of Explicit Congestion Notification (ECN) to IP", RFC 1501 3168, September 2001. 1503 [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, 1504 RFC 3205, February 2002. 1506 [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's 1507 Initial Window", RFC 3390, October 2002. 1509 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 1510 Layer Security over Stream Control Transmission Protocol", 1511 RFC 3436, December 2002. 1513 [RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 1514 M., and J. Crowcroft, "Forward Error Correction (FEC) 1515 Building Block", RFC 3452, December 2002. 1517 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 1518 Conrad, "Stream Control Transmission Protocol (SCTP) 1519 Partial Reliability Extension", RFC 3758, May 2004. 1521 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 1522 G. Fairhurst, "The Lightweight User Datagram Protocol 1523 (UDP-Lite)", RFC 3828, July 2004. 1525 [RFC4324] Royer, D., Babics, G., and S. Mansour, "Calendar Access 1526 Protocol (CAP)", RFC 4324, December 2005. 1528 [RFC4336] Floyd, S., Handley, M., and E. Kohler, "Problem Statement 1529 for the Datagram Congestion Control Protocol (DCCP)", RFC 1530 4336, March 2006. 1532 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1533 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1535 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 1536 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 1537 Congestion Control", RFC 4341, March 2006. 1539 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 1540 Datagram Congestion Control Protocol (DCCP) Congestion 1541 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 1542 March 2006. 1544 [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap 1545 for Transmission Control Protocol (TCP) Specification 1546 Documents", RFC 4614, September 2006. 1548 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast 1549 Congestion Control (TFMCC): Protocol Specification", RFC 1550 4654, August 2006. 1552 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 1553 Parameter for the Stream Control Transmission Protocol 1554 (SCTP)", RFC 4820, March 2007. 1556 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1557 Discovery", RFC 4821, March 2007. 1559 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 1560 "Authenticated Chunks for the Stream Control Transmission 1561 Protocol (SCTP)", RFC 4895, August 2007. 1563 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 1564 4960, September 2007. 1566 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 1567 Kozuka, "Stream Control Transmission Protocol (SCTP) 1568 Dynamic Address Reconfiguration", RFC 5061, September 1569 2007. 1571 [RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite 1572 protocol", RFC 5097, January 2008. 1574 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1575 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1577 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 1578 Friendly Rate Control (TFRC): Protocol Specification", RFC 1579 5348, September 2008. 1581 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1582 for Application Designers", BCP 145, RFC 5405, November 1583 2008. 1585 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 1586 (DCCP) Service Codes", RFC 5595, September 2009. 1588 [RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol 1589 (DCCP) Simultaneous-Open Technique to Facilitate NAT/ 1590 Middlebox Traversal", RFC 5596, September 2009. 1592 [RFC5662] Shepler, S., Eisler, M., and D. Noveck, "Network File 1593 System (NFS) Version 4 Minor Version 1 External Data 1594 Representation Standard (XDR) Description", RFC 5662, 1595 January 2010. 1597 [RFC5672] Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM) 1598 Signatures -- Update", RFC 5672, August 2009. 1600 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 1601 "NACK-Oriented Reliable Multicast (NORM) Transport 1602 Protocol", RFC 5740, November 2009. 1604 [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A 1605 Datagram Congestion Control Protocol UDP Encapsulation for 1606 NAT Traversal", RFC 6773, November 2012. 1608 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1609 Authentication Option", RFC 5925, June 2010. 1611 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 1612 Control", RFC 5681, September 2009. 1614 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 1615 Transport Layer Security (DTLS) for Stream Control 1616 Transmission Protocol (SCTP)", RFC 6083, January 2011. 1618 [RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the 1619 TCP Urgent Mechanism", RFC 6093, January 2011. 1621 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 1622 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 1623 6525, February 2012. 1625 [RFC6546] Trammell, B., "Transport of Real-time Inter-network 1626 Defense (RID) Messages over HTTP/TLS", RFC 6546, April 1627 2012. 1629 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 1630 "Computing TCP's Retransmission Timer", RFC 6298, June 1631 2011. 1633 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1634 Security Version 1.2", RFC 6347, January 2012. 1636 [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled 1637 Congestion Control for Multipath Transport Protocols", RFC 1638 6356, October 2011. 1640 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 1641 6455, December 2011. 1643 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 1644 Yasevich, "Sockets API Extensions for the Stream Control 1645 Transmission Protocol (SCTP)", RFC 6458, December 2011. 1647 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 1648 RFC 6691, July 2012. 1650 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1651 "TCP Extensions for Multipath Operation with Multiple 1652 Addresses", RFC 6824, January 2013. 1654 [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application 1655 Interface Considerations", RFC 6897, March 2013. 1657 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 1658 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 1660 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1661 for the Use of IPv6 UDP Datagrams with Zero Checksums", 1662 RFC 6936, April 2013. 1664 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 1665 Control Transmission Protocol (SCTP) Packets for End-Host 1666 to End-Host Communication", RFC 6951, May 2013. 1668 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 1669 IMMEDIATELY Extension for the Stream Control Transmission 1670 Protocol", RFC 7053, November 2013. 1672 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1673 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 1674 2014. 1676 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1677 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 1679 [RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1680 (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. 1682 [RFC7233] Fielding, R., Lafon, Y., and J. Reschke, "Hypertext 1683 Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, 1684 June 2014. 1686 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 1687 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 1688 2014. 1690 [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1691 (HTTP/1.1): Authentication", RFC 7235, June 2014. 1693 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1694 "Transport Layer Security (TLS) Application-Layer Protocol 1695 Negotiation Extension", RFC 7301, July 2014. 1697 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 1698 Scheffenegger, "TCP Extensions for High Performance", RFC 1699 7323, September 2014. 1701 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1702 Known Attacks on Transport Layer Security (TLS) and 1703 Datagram TLS (DTLS)", RFC 7457, February 2015. 1705 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1706 "Recommendations for Secure Use of Transport Layer 1707 Security (TLS) and Datagram Transport Layer Security 1708 (DTLS)", BCP 195, RFC 7525, May 2015. 1710 [RFC7540] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 1711 Protocol Version 2 (HTTP/2)", RFC 7540, May 2015. 1713 [I-D.ietf-aqm-ecn-benefits] 1714 Welzl, M. and G. Fairhurst, "The Benefits and Pitfalls of 1715 using Explicit Congestion Notification (ECN)", draft-ietf- 1716 aqm-ecn-benefits-00 (work in progress), October 2014. 1718 [I-D.ietf-tsvwg-sctp-dtls-encaps] 1719 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 1720 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 1721 dtls-encaps-09 (work in progress), January 2015. 1723 [I-D.ietf-tsvwg-sctp-prpolicies] 1724 Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, 1725 "Additional Policies for the Partial Reliability Extension 1726 of the Stream Control Transmission Protocol", draft-ietf- 1727 tsvwg-sctp-prpolicies-07 (work in progress), February 1728 2015. 1730 [I-D.ietf-tsvwg-sctp-ndata] 1731 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 1732 "Stream Schedulers and User Message Interleaving for the 1733 Stream Control Transmission Protocol", draft-ietf-tsvwg- 1734 sctp-ndata-03 (work in progress), March 2015. 1736 [I-D.ietf-tsvwg-natsupp] 1737 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 1738 Transmission Protocol (SCTP) Network Address Translation 1739 Support", draft-ietf-tsvwg-natsupp-07 (work in progress), 1740 February 2015. 1742 [XHR] van Kesteren, A., Aubourg, J., Song, J., and H. Steen, 1743 "XMLHttpRequest working draft 1744 (http://www.w3.org/TR/XMLHttpRequest/)", 2000. 1746 [REST] Fielding, R., "Architectural Styles and the Design of 1747 Network-based Software Architectures, Ph. D. (UC Irvune), 1748 Chapter 5: Representational State Transfer", 2000. 1750 Authors' Addresses 1752 Godred Fairhurst (editor) 1753 University of Aberdeen 1754 School of Engineering, Fraser Noble Building 1755 Aberdeen AB24 3UE 1757 Email: gorry@erg.abdn.ac.uk 1759 Brian Trammell (editor) 1760 ETH Zurich 1761 Gloriastrasse 35 1762 8092 Zurich 1763 Switzerland 1765 Email: ietf@trammell.ch 1767 Mirja Kuehlewind (editor) 1768 ETH Zurich 1769 Gloriastrasse 35 1770 8092 Zurich 1771 Switzerland 1773 Email: mirja.kuehlewind@tik.ee.ethz.ch