idnits 2.17.1 draft-ietf-taps-transports-06.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 248: '... [EDITOR'S NOTE: add URGENT and PUSH flag (note [RFC6093] says SHOULD...' RFC 2119 keyword, line 823: '...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 (July 06, 2015) is 3218 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0791' is defined on line 1527, but no explicit reference was found in the text == Unused Reference: 'RFC3390' is defined on line 1572, but no explicit reference was found in the text == Unused Reference: 'RFC5348' is defined on line 1643, but no explicit reference was found in the text == Unused Reference: 'RFC5925' is defined on line 1674, but no explicit reference was found in the text == Unused Reference: 'RFC5681' is defined on line 1677, but no explicit reference was found in the text == Unused Reference: 'RFC6298' is defined on line 1695, but no explicit reference was found in the text == Unused Reference: 'RFC6691' is defined on line 1713, 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-05 == 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 (~~), 11 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: January 7, 2016 M. Kuehlewind, Ed. 6 ETH Zurich 7 July 06, 2015 9 Services provided by IETF transport protocols and congestion control 10 mechanisms 11 draft-ietf-taps-transports-06 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 14, 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 . . . . . . . . . . . . . . . . 8 63 3.2.2. Interface Description . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . 24 90 3.9.3. Transport Protocol Components . . . . . . . . . . . . 24 91 3.10. Hypertext Transport Protocol (HTTP) over TCP as a 92 pseudotransport . . . . . . . . . . . . . . . . . . . . . 25 93 3.10.1. Protocol Description . . . . . . . . . . . . . . . . 25 94 3.10.2. Interface Description . . . . . . . . . . . . . . . 26 95 3.10.3. Transport Protocol Components . . . . . . . . . . . 27 96 3.11. WebSockets . . . . . . . . . . . . . . . . . . . . . . . 27 97 3.11.1. Protocol Description . . . . . . . . . . . . . . . . 27 98 3.11.2. Interface Description . . . . . . . . . . . . . . . 27 99 3.11.3. Transport Protocol Components . . . . . . . . . . . 28 100 4. Transport Service Features . . . . . . . . . . . . . . . . . 28 101 4.1. Complete Protocol Feature Matrix . . . . . . . . . . . . 30 102 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 103 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 104 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 105 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 106 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 107 9.1. Normative References . . . . . . . . . . . . . . . . . . 33 108 9.2. Informative References . . . . . . . . . . . . . . . . . 33 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 111 1. Introduction 113 Most Internet applications make use of the Transport Services 114 provided by TCP (a reliable, in-order stream protocol) or UDP (an 115 unreliable datagram protocol). We use the term "Transport Service" 116 to mean the end-to-end service provided to an application by the 117 transport layer. That service can only be provided correctly if 118 information about the intended usage is supplied from the 119 application. The application may determine this information at 120 design time, compile time, or run time, and may include guidance on 121 whether a feature is required, a preference by the application, or 122 something in between. Examples of features of Transport Services are 123 reliable delivery, ordered delivery, content privacy to in-path 124 devices, integrity protection, and minimal latency. 126 The IETF has defined a wide variety of transport protocols beyond TCP 127 and UDP, including SCTP, DCCP, MP-TCP, and UDP-Lite. Transport 128 services may be provided directly by these transport protocols, or 129 layered on top of them using protocols such as WebSockets (which runs 130 over TCP), RTP (over TCP or UDP) or WebRTC data channels (which run 131 over SCTP over DTLS over UDP or TCP). Services built on top of UDP 132 or UDP-Lite typically also need to specify additional mechanisms, 133 including a congestion control mechanism (such as a windowed 134 congestion control, TFRC or LEDBAT congestion control mechanism). 135 This extends the set of available Transport Services beyond those 136 provided to applications by TCP and UDP. 138 Transport protocols can also be differentiated by the features of the 139 services they provide: for instance, SCTP offers a message-based 140 service providing full or partial reliability and allowing to 141 minimize the head of line blocking due to the support of unordered 142 and unordered message delivery within multiple streams, UDP-Lite 143 provides partial integrity protection, and LEDBAT can provide low- 144 priority "scavenger" communication. 146 2. Terminology 148 The following terms are defined throughout this document, and in 149 subsequent documents produced by TAPS describing the composition and 150 decomposition of transport services. 152 [EDITOR'S NOTE: we may want to add definitions for the different 153 kinds of interfaces that are important here.] 155 Transport Service Feature: a specific end-to-end feature that a 156 transport service provides to its clients. Examples include 157 confidentiality, reliable delivery, ordered delivery, message- 158 versus-stream orientation, etc. 160 Transport Service: a set of transport service features, without an 161 association to any given framing protocol, which provides a 162 complete service to an application. 164 Transport Protocol: an implementation that provides one or more 165 different transport services using a specific framing and header 166 format on the wire. 168 Transport Protocol Component: an implementation of a transport 169 service feature within a protocol. 171 Transport Service Instance: an arrangement of transport protocols 172 with a selected set of features and configuration parameters that 173 implements a single transport service, e.g. a protocol stack (RTP 174 over UDP). 176 Application: an entity that uses the transport layer for end-to-end 177 delivery data across the network (this may also be an upper layer 178 protocol or tunnel encapsulation). 180 3. Existing Transport Protocols 182 This section provides a list of known IETF transport protocol and 183 transport protocol frameworks. 185 [EDITOR'S NOTE: Contributions to the subsections below are welcome] 187 3.1. Transport Control Protocol (TCP) 189 TCP is an IETF standards track transport protocol. [RFC0793] 190 introduces TCP as follows: "The Transmission Control Protocol (TCP) 191 is intended for use as a highly reliable host-to-host protocol 192 between hosts in packet-switched computer communication networks, and 193 in interconnected systems of such networks." Since its introduction, 194 TCP has become the default connection-oriented, stream-based 195 transport protocol in the Internet. It is widely implemented by 196 endpoints and widely used by common applications. 198 3.1.1. Protocol Description 200 TCP is a connection-oriented protocol, providing a three way 201 handshake to allow a client and server to set up a connection, and 202 mechanisms for orderly completion and immediate teardown of a 203 connection. TCP is defined by a family of RFCs [RFC4614]. 205 TCP provides multiplexing to multiple sockets on each host using port 206 numbers. An active TCP session is identified by its four-tuple of 207 local and remote IP addresses and local port and remote port numbers. 208 The destination port during connection setup has a different role as 209 it is often used to indicate the requested service. 211 TCP partitions a continuous stream of bytes into segments, sized to 212 fit in IP packets. ICMP-based PathMTU discovery [RFC1191][RFC1981] 213 as well as Packetization Layer Path MTU Discovery (PMTUD) [RFC4821] 214 are supported. 216 Each byte in the stream is identified by a sequence number. The 217 sequence number is used to order segments on receipt, to identify 218 segments in acknowledgments, and to detect unacknowledged segments 219 for retransmission. This is the basis of TCP's reliable, ordered 220 delivery of data in a stream. TCP Selective Acknowledgment [RFC2018] 221 extends this mechanism by making it possible to identify missing 222 segments more precisely, reducing spurious retransmission. 224 Receiver flow control is provided by a sliding window: limiting the 225 amount of unacknowledged data that can be outstanding at a given 226 time. The window scale option [RFC7323] allows a receiver to use 227 windows greater than 64KB. 229 All TCP senders provide Congestion Control: This uses a separate 230 window, where each time congestion is detected, this congestion 231 window is reduced. A receiver detects congestion using one of three 232 mechanisms: A retransmission timer, detection of loss (interpreted as 233 a congestion signal), or Explicit Congestion Notification (ECN) 234 [RFC3168] to provide early signaling (see 235 [I-D.ietf-aqm-ecn-benefits]) 237 A TCP protocol instance can be extended [RFC4614] and tuned. Some 238 features are sender-side only, requiring no negotiation with the 239 receiver; some are receiver-side only, some are explicitly negotiated 240 during connection setup. 242 By default, TCP segment partitioning uses Nagle's algorithm [RFC0896] 243 to buffer data at the sender into large segments, potentially 244 incurring sender-side buffering delay; this algorithm can be disabled 245 by the sender to transmit more immediately, e.g. to enable smoother 246 interactive sessions. 248 [EDITOR'S NOTE: add URGENT and PUSH flag (note [RFC6093] says SHOULD 249 NOT use due to the range of TCP implementations that process TCP 250 urgent indications differently.) ] 252 A checksum provides an Integrity Check and is mandatory across the 253 entire packet. The TCP checksum does not support partial corruption 254 protection as in DCCP/UDP-Lite). This check protects from 255 misdelivery of data corrupted data, but is relatively weak, and 256 applications that require end to end integrity of data are 257 recommended to include a stronger integrity check of their payload 258 data. 260 A TCP service is unicast. 262 3.1.2. Interface description 264 A User/TCP Interface is defined in [RFC0793] providing six user 265 commands: Open, Send, Receive, Close, Status. This interface does 266 not describe configuration of TCP options or parameters beside use of 267 the PUSH and URGENT flags. 269 In API implementations derived from the BSD Sockets API, TCP sockets 270 are created using the "SOCK_STREAM" socket type. 272 The features used by a protocol instance may be set and tuned via 273 this API. 275 (more on the API goes here) 277 3.1.3. Transport Protocol Components 279 The transport protocol components provided by TCP (new version) are: 281 [EDITOR'S NOTE: discussion of how to map this to features and TAPS: 282 what does the higher layer need to decide? what can the transport 283 layer decide based on global settings? what must the transport layer 284 decide based on network characteristics?] 286 o Connection-oriented bidirectional communication using three-way 287 handshake connection setup with feature negotiation and an 288 explicit distinction between passive and active open: This implies 289 both unicast addressing and a guarantee of return routability. 291 o Single stream-oriented transmission: The stream abstraction atop 292 the datagram service provided by IP is implemented by dividing the 293 stream into segments. 295 o Limited control over segment transmission scheduling (Nagle's 296 algorithm): This allows for delay minimization in interactive 297 applications by preventing the transport to add additional delays 298 (by deactivating Nagle's algorithm). 300 o Port multiplexing, with application-to-port mapping during 301 connection setup: Note that in the presence of network address and 302 port translation (NAPT), TCP ports are in effect part of the 303 endpoint address for forwarding purposes. 305 o Full reliability using (S)ACK- and RTO-based loss detection and 306 retransmissions: Loss is sensed using duplicated ACKs ("fast 307 retransmit"), which places a lower bound on the delay inherent in 308 this approach to reliability. The retransmission timeout 309 determines the upper bound on the delay (expect if also 310 exponential back-off is performed). The use of selective 311 acknowlegdements further reduces the latency for retransmissions 312 if multiple packets are lost during one congestion event. 314 o Error detection based on a checksum covering the network and 315 transport headers as well as payload: Packets that are detected as 316 corrupted are dropped, relying on the reliability mechanism to 317 retransmit them. 319 o Window-based flow control, with receiver-side window management 320 and signaling of available window: Scaling the flow control window 321 beyond 64kB requires the use of an optional feature, which has 322 performance implications in environments where this option is not 323 supported; this can be the case either if the receiver does not 324 implement window scaling or if a network node on the path strips 325 the window scaling option. 327 o Window-based congestion control reacting to loss, delay, 328 retransmission timeout, or an explicit congestion signal (ECN): 329 Most commonly used is a loss signal from the reliability 330 component's retransmission mechanism. TCP reacts to a congestion 331 signal by reducing the size of the congestion window; 332 retransmission timeout is generally handled with a larger reaction 333 than other signals. 335 3.2. Multipath TCP (MPTCP) 337 Multipath TCP [RFC6824] is an extension for TCP to support multi- 338 homing. It is designed to be as transparent as possible to middle- 339 boxes. It does so by establishing regular TCP flows between a pair 340 of source/destination endpoints, and multiplexing the application's 341 stream over these flows. 343 3.2.1. Protocol Description 345 MPTCP uses TCP options for its control plane. They are used to 346 signal multipath capabilities, as well as to negotiate data sequence 347 numbers, and advertise other available IP addresses and establish new 348 sessions between pairs of endpoints. 350 3.2.2. Interface Description 352 By default, MPTCP exposes the same interface as TCP to the 353 application. [RFC6897] however describes a richer API for MPTCP- 354 aware applications. 356 This Basic API describes how an application can - enable or disable 357 MPTCP; - bind a socket to one or more selected local endpoints; - 358 query local and remote endpoint addresses; - get a unique connection 359 identifier (similar to an address-port pair for TCP). 361 The document also recommend the use of extensions defined for SCTP 362 [RFC6458] (see next section) to deal with multihoming. 364 [AUTHOR'S NOTE: research work, and some implementation, also suggest 365 that the scheduling algorithm, as well as the path manager, are 366 configurable options that should be exposed to higher layer. Should 367 this be discussed here?] 369 3.2.3. Transport Protocol Components 371 [AUTHOR'S NOTE: shouldn't it be "service feature"?] 373 As an extension to TCP, MPTCP provides mostly the same components. 374 By establishing multiple sessions between available endpoints, it can 375 additionally provide soft failover solutions should one of the paths 376 become unusable. In addition, by multiplexing one byte stream over 377 separate paths, it can achieve a higher throughput than TCP in 378 certain situations (note however that coupled congestion control 379 [RFC6356] might limit this benefit to maintain fairness to other 380 flows at the bottleneck). When aggregating capacity over multiple 381 paths, and depending on the way packets are scheduled on each TCP 382 subflow, an additional delay and higher jitter might be observed 383 observed before in-order delivery of data to the applications. 385 The transport protocol components provided by MPTCP in addition to 386 TCP therefore are: 388 o congestion control with load balancing over mutiple connections 390 o endpoint multiplexing of a single byte stream (higher throughput) 392 o resilience to network failure and/or handoverss 394 [AUTHOR'S NOTE: it is unclear whether MPTCP has to provide data 395 bundling.] [AUTHOR'S NOTE: AF muliplexing? sub-flows can be started 396 over IPv4 or IPv6 for the same session] 398 3.3. Stream Control Transmission Protocol (SCTP) 400 SCTP is a message oriented standards track transport protocol and the 401 base protocol is specified in [RFC4960]. It supports multi-homing to 402 handle path failures. An SCTP association has multiple 403 unidirectional streams in each direction and provides in-sequence 404 delivery of user messages only within each stream. This allows to 405 minimize head of line blocking. SCTP is extensible and the currently 406 defined extensions include mechanisms for dynamic re-configurations 407 of streams [RFC6525] and IP-addresses [RFC5061]. Furthermore, the 408 extension specified in [RFC3758] introduces the concept of partial 409 reliability for user messages. 411 SCTP was originally developed for transporting telephony signalling 412 messages and is deployed in telephony signalling networks, especially 413 in mobile telephony networks. Additionally, it is used in the WebRTC 414 framework for data channels and is therefore deployed in all WEB- 415 browsers supporting WebRTC. 417 3.3.1. Protocol Description 419 SCTP is a connection oriented protocol using a four way handshake to 420 establish an SCTP association and a three way message exchange to 421 gracefully shut it down. It uses the same port number concept as 422 DCCP, TCP, UDP, and UDP-Lite do and only supports unicast. 424 SCTP uses the 32-bit CRC32c for protecting SCTP packets against bit 425 errors. This is stronger than the 16-bit checksums used by TCP or 426 UDP. However, a partial checksum coverage as provided by DCCP or 427 UDP-Lite is not supported. 429 SCTP has been designed with extensibility in mind. Each SCTP packet 430 starts with a single common header containing the port numbers, a 431 verification tag and the CRC32c checksum. This common header is 432 followed by a sequence of chunks. Each chunk consists of a type 433 field, flags, a length field and a value. [RFC4960] defines how a 434 receiver processes chunks with an unknown chunk type. The support of 435 extensions can be negotiated during the SCTP handshake. 437 SCTP provides a message-oriented service. Multiple small user 438 messages can be bundled into a single SCTP packet to improve the 439 efficiency. For example, this bundling may be done by delaying user 440 messages at the sender side similar to the Nagle algorithm used by 441 TCP. User messages which would result in IP packets larger than the 442 MTU will be fragmented at the sender side and reassembled at the 443 receiver side. There is no protocol limit on the user message size. 444 ICMP-based path MTU discovery as specified for IPv4 in [RFC1191] and 445 for IPv6 in [RFC1981] as well as packetization layer path MTU 446 discovery as specified in [RFC4821] with probe packets using the 447 padding chunks defined the [RFC4820] are supported. 449 [RFC4960] specifies a TCP friendly congestion control to protect the 450 network against overload. SCTP also uses a sliding window flow 451 control to protect receivers against overflow. 453 Each SCTP association has between 1 and 65536 uni-directional streams 454 in each direction. The number of streams can be different in each 455 direction. Every user-message is sent on a particular stream. User 456 messages can be sent un-ordered or ordered upon request by the upper 457 layer. Un-ordered messages can be delivered as soon as they are 458 completely received. Only all ordered messages sent on the same 459 stream are delivered at the receiver in the same order as sent by the 460 sender. For user messages not requiring fragmentation, this 461 minimises head of line blocking. The base protocol defined in 462 [RFC4960] doesn't allow interleaving of user-messages, which results 463 in sending a large message on one stream can block the sending of 464 user messages on other streams. [I-D.ietf-tsvwg-sctp-ndata] 465 overcomes this limitation. Furthermore, [I-D.ietf-tsvwg-sctp-ndata] 466 specifies multiple algorithms for the sender side selection of which 467 streams to send data from supporting a variety of scheduling 468 algorithms including priority based ones. The stream re- 469 configuration extension defined in [RFC6525] allows to reset streams 470 during the lifetime of an association and to increase the number of 471 streams, if the number of streams negotiated in the SCTP handshake is 472 not sufficient. 474 According to [RFC4960], each user message sent is either delivered to 475 the receiver or, in case of excessive retransmissions, the 476 association is terminated in a non-graceful way, similar to the TCP 477 behaviour. In addition to this reliable transfer, the partial 478 reliability extension defined in [RFC3758] allows the sender to 479 abandon user messages. The application can specify the policy for 480 abandoning user messages. Examples for these policies include: 482 o Limiting the time a user message is dealt with by the sender. 484 o Limiting the number of retransmissions for each fragment of a user 485 message. If the number of retransmissions is limited to 0, one 486 gets a service similar to UDP. 488 o Abandoning messages of lower priority in case of a send buffer 489 shortage. 491 SCTP supports multi-homing. Each SCTP end-point uses a list of IP- 492 addresses and a single port number. These addresses can be any 493 mixture of IPv4 and IPv6 addresses. These addresses are negotiated 494 during the handshake and the address re-configuration extension 495 specified in [RFC5061] in combination with [RFC4895] can be used to 496 change these addresses in an authenticated way during the livetime of 497 an SCTP association. This allows for transport layer mobility. 498 Multiple addresses are used for improved resilience. If a remote 499 address becomes unreachable, the traffic is switched over to a 500 reachable one, if one exists. Each SCTP end-point supervises 501 continuously the reachability of all peer addresses using a heartbeat 502 mechanism. 504 For securing user messages, the use of TLS over SCTP has been 505 specified in [RFC3436]. However, this solution does not support all 506 services provided by SCTP (for example un-ordered delivery or partial 507 reliability), and therefore the use of DTLS over SCTP has been 508 specified in [RFC6083] to overcome these limitations. When using 509 DTLS over SCTP, the application can use almost all services provided 510 by SCTP. 512 [I-D.ietf-tsvwg-natsupp] defines a methods for end-hosts and 513 middleboxes to provide for NAT support for SCTP over IPv4. For 514 legacy NAT traversal, [RFC6951] defines the UDP encapsulation of 515 SCTP-packets. Alternatively, SCTP packets can be encapsulated in 516 DTLS packets as specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. The 517 latter encapsulation is used with in the WebRTC context. 519 Having a well defined API is also a feature provided by SCTP as 520 described in the next subsection. 522 3.3.2. Interface Description 524 [RFC4960] defines an abstract API for the base protocol. An 525 extension to the BSD Sockets API is defined in [RFC6458] and covers: 527 o the base protocol defined in [RFC4960]. 529 o the SCTP Partial Reliability extension defined in [RFC3758]. 531 o the SCTP Authentication extension defined in [RFC4895]. 533 o the SCTP Dynamic Address Reconfiguration extension defined in 534 [RFC5061]. 536 For the following SCTP protocol extensions the BSD Sockets API 537 extension is defined in the document specifying the protocol 538 extensions: 540 o the SCTP SACK-IMMEDIATELY extension defined in [RFC7053]. 542 o the SCTP Stream Reconfiguration extension defined in [RFC6525]. 544 o the UDP Encapsulation of SCTP packets extension defined in 545 [RFC6951]. 547 o the additional PR-SCTP policies defined in 548 [I-D.ietf-tsvwg-sctp-prpolicies]. 550 Future documents describing SCTP protocol extensions are expected to 551 describe the corresponding BSD Sockets API extension in a "Socket API 552 Considerations" section. 554 The SCTP socket API supports two kinds of sockets: 556 o one-to-one style sockets (by using the socket type "SOCK_STREAM"). 558 o one-to-many style socket (by using the socket type 559 "SOCK_SEQPACKET"). 561 One-to-one style sockets are similar to TCP sockets, there is a 1:1 562 relationship between the sockets and the SCTP associations (except 563 for listening sockets). One-to-many style SCTP sockets are similar 564 to unconnected UDP sockets as there is a 1:n relationship between the 565 sockets and the SCTP associations. 567 The SCTP stack can provide information to the applications about 568 state changes of the individual paths and the association whenever 569 they occur. These events are delivered similar to user messages but 570 are specifically marked as notifications. 572 A couple of new functions have been introduced to support the use of 573 multiple local and remote addresses. Additional SCTP-specific send 574 and receive calls have been defined to allow dealing with the SCTP 575 specific information without using ancillary data in the form of 576 additional cmsgs, which are also defined. These functions provide 577 support for detecting partial delivery of user messages and 578 notifications. 580 The SCTP socket API allows a fine-grained control of the protocol 581 behaviour through an extensive set of socket options. 583 The SCTP kernel implementations of FreeBSD, Linux and Solaris follow 584 mostly the specified extension to the BSD Sockets API for the base 585 protocol and the corresponding supported protocol extensions. 587 3.3.3. Transport Protocol Components 589 The transport protocol components provided by SCTP are: 591 o unicast 593 o connection setup with feature negotiation and application-to-port 594 mapping 596 o port multiplexing 598 o reliable or partially reliable delivery 600 o ordered and unordered delivery within a stream 602 o support for multiple concurrent streams 604 o support for stream scheduling prioritization 606 o flow control 608 o message-oriented delivery 610 o congestion control 612 o user message bundling 614 o user message fragmentation and reassembly 616 o strong error detection (CRC32C) 618 o transport layer multihoming for resilience 620 o transport layer mobility 622 [EDITOR'S NOTE: update this list.] 624 3.4. User Datagram Protocol (UDP) 626 The User Datagram Protocol (UDP) [RFC0768] [RFC2460] is an IETF 627 standards track transport protocol. It provides a uni-directional, 628 datagram protocol which preserves message boundaries. It provides 629 none of the following transport features: error correction, 630 congestion control, or flow control. It can be used to send 631 broadcast datagrams (IPv4) or multicast datagrams (IPv4 and IPv6), in 632 addition to unicast (and anycast) datagrams. IETF guidance on the 633 use of UDP is provided in[RFC5405]. UDP is widely implemented and 634 widely used by common applications, especially DNS. 636 3.4.1. Protocol Description 638 UDP is a connection-less protocol which maintains message boundaries, 639 with no connection setup or feature negotiation. The protocol uses 640 independent messages, ordinarily called datagrams. The lack of error 641 control and flow control implies messages may be damaged, re-ordered, 642 lost, or duplicated in transit. A receiving application unable to 643 run sufficiently fast or frequently may miss messages. The lack of 644 congestion handling implies UDP traffic may cause the loss of 645 messages from other protocols (e.g., TCP) when sharing the same 646 network paths. UDP traffic can also cause the loss of other UDP 647 traffic in the same or other flows for the same reasons. 649 Messages with bit errors are ordinarily detected by an invalid end- 650 to-end checksum and are discarded before being delivered to an 651 application. There are some exceptions to this general rule, 652 however. UDP-Lite (see [RFC3828], and below) provides the ability 653 for portions of the message contents to be exempt from checksum 654 coverage. It is also possible to create UDP datagrams with no 655 checksum, and while this is generally discouraged [RFC1122] 656 [RFC5405], certain special cases permit its use [RFC6935]. The 657 checksum support considerations for omitting the checksum are defined 658 in [RFC6936]. Note that due to the relatively weak form of checksum 659 used by UDP, applications that require end to end integrity of data 660 are recommended to include a stronger integrity check of their 661 payload data. 663 On transmission, UDP encapsulates each datagram into an IP packet, 664 which may in turn be fragmented by IP. Applications concerned with 665 fragmentation or that have other requirements such as receiver flow 666 control, congestion control, PathMTU discovery/PLPMTUD, support for 667 ECN, etc need to be provided by protocols other than UDP [RFC5405]. 669 3.4.2. Interface Description 671 [RFC0768] describes basic requirements for an API for UDP. Guidance 672 on use of common APIs is provided in [RFC5405]. 674 A UDP endpoint consists of a tuple of (IP address, port number). 675 Demultiplexing using multiple abstract endpoints (sockets) on the 676 same IP address are supported. The same socket may be used by a 677 single server to interact with multiple clients (note: this behavior 678 differs from TCP, which uses a pair of tuples to identify a 679 connection). Multiple server instances (processes) binding the same 680 socket can cooperate to service multiple clients- the socket 681 implementation arranges to not duplicate the same received unicast 682 message to multiple server processes. 684 Many operating systems also allow a UDP socket to be "connected", 685 i.e., to bind a UDP socket to a specific (remote) UDP endpoint. 686 Unlike TCP's connect primitive, for UDP, this is only a local 687 operation that serves to simplify the local send/receive functions 688 and to filter the traffic for the specified addresses and ports 689 [RFC5405]. 691 3.4.3. Transport Protocol Components 693 The transport protocol components provided by UDP are: 695 o unidirectional 697 o port multiplexing 699 o 2-tuple endpoints 701 o IPv4 broadcast, multicast and anycast 703 o IPv6 multicast and anycast 705 o IPv6 jumbograms 707 o message-oriented delivery 709 o error detection (checksum) 711 o checksum optional 713 3.5. Lightweight User Datagram Protocol (UDP-Lite) 715 The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] is an 716 IETF standards track transport protocol. UDP-Lite provides a 717 bidirectional set of logical unicast or multicast message streams 718 over a datagram protocol. IETF guidance on the use of UDP-Lite is 719 provided in [RFC5405]. 721 3.5.1. Protocol Description 722 UDP-Lite is a connection-less datagram protocol, with no connection 723 setup or feature negotiation. The protocol use messages, rather than 724 a byte-stream. Each stream of messages is independently managed, 725 therefore retransmission does not hold back data sent using other 726 logical streams. 728 It provides multiplexing to multiple sockets on each host using port 729 numbers. An active UDP-Lite session is identified by its four-tuple 730 of local and remote IP addresses and local port and remote port 731 numbers. 733 UDP-Lite fragments packets into IP packets, constrained by the 734 maximum size of IP packet. 736 UDP-Lite changes the semantics of the UDP "payload length" field to 737 that of a "checksum coverage length" field. Otherwise, UDP-Lite is 738 semantically identical to UDP. Applications using UDP-Lite therefore 739 can not make assumptions regarding the correctness of the data 740 received in the insensitive part of the UDP-Lite payload. 742 As for UDP, mechanisms for receiver flow control, congestion control, 743 PMTU or PLPMTU discovery, support for ECN, etc need to be provided by 744 upper layer protocols [RFC5405]. 746 Examples of use include a class of applications that can derive 747 benefit from having partially-damaged payloads delivered, rather than 748 discarded. One use is to support error tolerate payload corruption 749 when used over paths that include error-prone links, another 750 application is when header integrity checks are required, but payload 751 integrity is provided by some other mechanism (e.g. [RFC6936]. 753 A UDP-Lite service may support IPv4 broadcast, multicast, anycast and 754 unicast. 756 3.5.2. Interface Description 758 There is no current API specified in the RFC Series, but guidance on 759 use of common APIs is provided in [RFC5405]. 761 The interface of UDP-Lite differs from that of UDP by the addition of 762 a single (socket) option that communicates a checksum coverage length 763 value: at the sender, this specifies the intended checksum coverage, 764 with the remaining unprotected part of the payload called the "error- 765 insensitive part". The checksum coverage may also be made visible to 766 the application via the UDP-Lite MIB module [RFC5097]. 768 3.5.3. Transport Protocol Components 769 The transport protocol components provided by UDP-Lite are: 771 o unicast 773 o IPv4 broadcast, multicast and anycast 775 o port multiplexing 777 o non-reliable, non-ordered delivery 779 o message-oriented delivery 781 o partial integrity protection 783 3.6. Datagram Congestion Control Protocol (DCCP) 785 Datagram Congestion Control Protocol (DCCP) [RFC4340] is an IETF 786 standards track bidirectional transport protocol that provides 787 unicast connections of congestion-controlled unreliable messages. 789 [EDITOR'S NOTE: Gorry Fairhurst signed up as a contributor for this 790 section.] 792 The DCCP Problem Statement describes the goals that DCCP sought to 793 address [RFC4336]. It is suitable for applications that transfer 794 fairly large amounts of data and that can benefit from control over 795 the trade off between timeliness and reliability [RFC4336]. 797 It offers low overhead, and many characteristics common to UDP, but 798 can avoid "Re-inventing the wheel" each time a new multimedia 799 application emerges. Specifically it includes core functions 800 (feature negotiation, path state management, RTT calculation, PMTUD, 801 etc): This allows applications to use a compatible method defining 802 how they send packets and where suitable to choose common algorithms 803 to manage their functions. Examples of suitable applications include 804 interactive applications, streaming media or on-line games [RFC4336]. 806 3.6.1. Protocol Description 808 DCCP is a connection-oriented datagram protocol, providing a three 809 way handshake to allow a client and server to set up a connection, 810 and mechanisms for orderly completion and immediate teardown of a 811 connection. The protocol is defined by a family of RFCs. 813 It provides multiplexing to multiple sockets on each host using port 814 numbers. An active DCCP session is identified by its four-tuple of 815 local and remote IP addresses and local port and remote port numbers. 816 At connection setup, DCCP also exchanges the the service code 818 [RFC5595] mechanism to allow transport instantiations to indicate the 819 service treatment that is expected from the network. 821 The protocol segments data into messages, typically sized to fit in 822 IP packets, but which may be fragmented providing they are less than 823 the A DCCP interface MAY allow applications to request fragmentation 824 for packets larger than PMTU, but not larger than the maximum packet 825 size allowed by the current congestion control mechanism (CCMPS) 826 [RFC4340]. 828 Each message is identified by a sequence number. The sequence number 829 is used to identify segments in acknowledgments, to detect 830 unacknowledged segments, to measure RTT, etc. The protocol may 831 support ordered or unordered delivery of data, and does not itself 832 provide retransmission. There is a Data Checksum option, which 833 contains a strong CRC, lets endpoints detect application data 834 corruption. It also supports reduced checksum coverage, a partial 835 integrity mechanisms similar to UDP-lIte. 837 Receiver flow control is supported: limiting the amount of 838 unacknowledged data that can be outstanding at a given time. 840 A DCCP protocol instance can be extended [RFC4340] and tuned. Some 841 features are sender-side only, requiring no negotiation with the 842 receiver; some are receiver-side only, some are explicitly negotiated 843 during connection setup. 845 DCCP supports negotiation of the congestion control profile, to 846 provide Plug and Play congestion control mechanisms. examples of 847 specified profiles include [RFC4341] [RFC4342] [RFC5662]. All IETF- 848 defined methods provide Congestion Control. 850 DCCP use a Connect packet to start a session, and permits half- 851 connections that allow each client to choose features it wishes to 852 support. Simultaneous open [RFC5596], as in TCP, can enable 853 interoperability in the presence of middleboxes. The Connect packet 854 includes a Service Code field [RFC5595] designed to allow middle 855 boxes and endpoints to identify the characteristics required by a 856 session. A lightweight UDP-based encapsulation (DCCP-UDP) has been 857 defined [RFC6773] that permits DCCP to be used over paths where it is 858 not natively supported. Support in NAPT/NATs is defined in [RFC4340] 859 and [RFC5595]. 861 Upper layer protocols specified on top of DCCP include: DTLS 862 [RFC5595], RTP [RFC5672], ICE/SDP [RFC6773]. 864 A DCCP service is unicast. 866 A common packet format has allowed tools to evolve that can read and 867 interpret DCCP packets (e.g. Wireshark). 869 3.6.2. Interface Description 871 API characteristics include: - Datagram transmission. - Notification 872 of the current maximum packet size. - Send and reception of zero- 873 length payloads. - Set the Slow Receiver flow control at a receiver. 874 - Detect a Slow receiver at the sender. 876 There is no current API specified in the RFC Series. 878 3.6.3. Transport Protocol Components 880 The transport protocol components provided by DCCP are: 882 o unicast 884 o connection setup with feature negotiation and application-to-port 885 mapping 887 o Service Codes 889 o port multiplexing 891 o non-reliable, ordered delivery 893 o flow control (slow receiver function) 895 o drop notification 897 o timestamps 899 o message-oriented delivery 901 o partial integrity protection 903 3.7. Realtime Transport Protocol (RTP) 905 RTP provides an end-to-end network transport service, suitable for 906 applications transmitting real-time data, such as audio, video or 907 data, over multicast or unicast network services, including TCP, UDP, 908 UDP-Lite, DCCP. 910 [EDITOR'S NOTE: Varun Singh signed up as contributor for this 911 section. Given the complexity of RTP, suggest to have an abbreviated 912 section here contrasting RTP with other transports, and focusing on 913 those features that are RTP-unique.] 915 3.8. NACK-Oriented Reliable Multicast (NORM) 917 NORM is an IETF standards track protocol specified in [RFC5740]. The 918 protocol was designed to support reliable bulk data dissemination to 919 receiver groups using IP Multicast but also provides for point-to- 920 point unicast operation. Its support for bulk data dissemination 921 includes discrete file or computer memory-based "objects" as well as 922 byte- and message-streaming. NORM is designed to incorporate packet 923 erasure coding as an inherent part of its selective ARQ in response 924 to receiver negative acknowledgements. The packet erasure coding can 925 also be proactively applied for forward protection from packet loss. 926 NORM transmissions are governed by TCP-friendly congestion control. 927 NORM's reliability, congestion control, and flow control mechanism 928 are distinct components and can be separately controlled to meet 929 different application needs. 931 3.8.1. Protocol Description 933 [EDITOR'S NOTE: needs to be more clear about the application of FEC 934 and packet erasure coding; expand ARQ.] 936 The NORM protocol is encapsulated in UDP datagrams and thus provides 937 multiplexing for multiple sockets on hosts using port numbers. For 938 purposes of loosely coordinated IP Multicast, NORM is not strictly 939 connection-oriented although per-sender state is maintained by 940 receivers for protocol operation. [RFC5740] does not specify a 941 handshake protocol for connection establishment and separate session 942 initiation can be used to coordinate port numbers. However, in-band 943 "client-server" style connection establishment can be accomplished 944 with the NORM congestion control signaling messages using port 945 binding techniques like those for TCP client-server connections. 947 NORM supports bulk "objects" such as file or in-memory content but 948 also can treat a stream of data as a logical bulk object for purposes 949 of packet erasure coding. In the case of stream transport, NORM can 950 support either byte streams or message streams where application- 951 defined message boundary information is carried in the NORM protocol 952 messages. This allows the receiver(s) to join/re-join and recover 953 message boundaries mid-stream as needed. Application content is 954 carried and identified by the NORM protocol with encoding symbol 955 identifiers depending upon the Forward Error Correction (FEC) Scheme 956 [RFC3452] configured. NORM uses NACK-based selective ARQ to reliably 957 deliver the application content to the receiver(s). NORM proactively 958 measures round-trip timing information to scale ARQ timers 959 appropriately and to support congestion control. For multicast 960 operation, timer-based feedback suppression is uses to achieve group 961 size scaling with low feedback traffic levels. The feedback 962 suppression is not applied for unicast operation. 964 NORM uses rate-based congestion control based upon the TCP-Friendly 965 Rate Control (TFRC) [RFC4324] principles that are also used in DCCP 966 [RFC4340]. NORM uses control messages to measure RTT and collect 967 congestion event (e..g, loss event, ECN event, etc) information from 968 the receiver(s) to support dynamic rate control adjustment. The TCP- 969 Friendly Multicast Congestion Control (TFMCC) [RFC4654] used provides 970 some extra features to support multicast but is functionally 971 equivalent to TFRC in the unicast case. 973 NORM's reliability mechanism is decoupled from congestion control. 974 This allows alternative arrangements of transport services to be 975 invoked. For example, fixed-rate reliable delivery can be supported 976 or unreliable (but optionally "better than best effort" via packet 977 erasure coding) delivery with rate-control per TFRC can be achieved. 978 Additionally, alternative congestion control techniques may be 979 applied. For example, TFRC rate control with congestion event 980 detection based on ECN for links with high packet loss (e.g., 981 wireless) has been implemented and demonstrated with NORM. 983 While NORM is NACK-based for reliability transfer, it also supports a 984 positive acknowledgment (ACK) mechanism that can be used for receiver 985 flow control. Again, since this mechanism is decoupled from the 986 reliability and congestion control, applications that have different 987 needs in this aspect can use the protocol differently. One example 988 is the use of NORM for quasi-reliable delivery where timely delivery 989 of newer content may be favored over completely reliable delivery of 990 older content within buffering and RTT constraints. 992 3.8.2. Interface Description 994 The NORM specification does not describe a specific application 995 programming interface (API) to control protocol operation. A freely- 996 available, open source reference implementation of NORM is available 997 at https://www.nrl.navy.mil/itd/ncs/products/norm, and a documented 998 API is provided for this implementation. While a sockets-like API is 999 not currently documented, the existing API supports the necessary 1000 functions for that to be implemented. 1002 3.8.3. Transport Protocol Components 1004 The transport protocol components provided by NORM are: 1006 o unicast 1008 o multicast 1010 o port multiplexing (UDP ports) 1011 o reliable delivery 1013 o unordered delivery of in-memory data or file bulk content objects 1015 o error detection (UDP checksum) 1017 o segmentation 1019 o stream-oriented delivery in a single stream 1021 o object-oriented delivery of discrete data or file items 1023 o data bundling (Nagle's algorithm) 1025 o flow control (timer-based and/or ack-based) 1027 o congestion control 1029 o packet erasure coding (both proactively and as part of ARQ) 1031 3.9. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a 1032 pseudotransport 1034 Transport Layer Security (TLS) and Datagram TLS (DTLS) are IETF 1035 protocols that provide several security-related features to 1036 applications. TLS is designed to run on top of a reliable streaming 1037 transport protocol (usually TCP), while DTLS is designed to run on 1038 top of a best-effort datagram protocol (usually UDP). At the time of 1039 writing, the current version of TLS is 1.2; it is defined in 1040 [RFC5246]. DTLS provides nearly identical functionality to 1041 applications; it is defined in [RFC6347] and its current version is 1042 also 1.2. The TLS protocol evolved from the Secure Sockets Layer 1043 (SSL) protocols developed in the mid 90s to support protection of 1044 HTTP traffic. 1046 While older versions of TLS and DTLS are still in use, they provide 1047 weaker security guarantees. [RFC7457] outlines important attacks on 1048 TLS and DTLS. [RFC7525] is a Best Current Practices (BCP) document 1049 that describes secure configurations for TLS and DTLS to counter 1050 these attacks. The recommendations are applicable for the vast 1051 majority of use cases. 1053 [NOTE: The Logjam authors (weakdh.org) give (inconclusive) evidence 1054 that one of the recommendations of [RFC7525], namely the use of 1055 DHE-1024 as a fallback, may not be sufficient in all cases to counter 1056 an attacker with the resources of a nation-state. It is unclear at 1057 this time if the RFC is going to be updated as a result, or whether 1058 there will be an RFC7525bis.] 1060 3.9.1. Protocol Description 1062 Both TLS and DTLS provide the same security features and can thus be 1063 discussed together. The features they provide are: 1065 o Confidentiality 1067 o Data integrity 1069 o Peer authentication (optional) 1071 o Perfect forward secrecy (optional) 1073 The authentication of the peer entity can be omitted; a common web 1074 use case is where the server is authenticated and the client is not. 1075 TLS also provides a completely anonymous operation mode in which 1076 neither peer's identity is authenticated. It is important to note 1077 that TLS itself does not specify how a peering entity's identity 1078 should be interpreted. For example, in the common use case of 1079 authentication by means of an X.509 certificate, it is the 1080 application's decision whether the certificate of the peering entity 1081 is acceptable for authorization decisions. Perfect forward secrecy, 1082 if enabled and supported by the selected algorithms, ensures that 1083 traffic encrypted and captured during a session at time t0 cannot be 1084 later decrypted at time t1 (t1 > t0), even if the long-term secrets 1085 of the communicating peers are later compromised. 1087 As DTLS is generally used over an unreliable datagram transport such 1088 as TCP, applications will need to tolerate loss, re-ordered, or 1089 duplicated datagrams. Like TLS, DTLS conveys application data in a 1090 sequence of independent records. However, because records are mapped 1091 to unreliable datagrams, there are several features unique to DTLS 1092 that are not applicable to TLS: 1094 o Record replay detection (optional) 1096 o Record size negotiation (estimates of PMTU and record size 1097 expansion factor) 1099 o Coveyance of IP don't fragment (DF) bit settings by application 1101 o An anti-DoS stateless cookie mechanism (optional) 1103 Generally, DTLS follows the TLS design as closely as possible. To 1104 operate over datagrams, DTLS includes a sequence number and limited 1105 forms of retransmission and fragmentation for its internal 1106 operations. The sequence number may be used for detecting replayed 1107 information, according to the windowing procedure described in 1108 Section 4.1.2.6 of [RFC6347]. Note also that DTLS bans the use of 1109 stream ciphers, which are essentially incompatible when operating on 1110 independent encrypted records. 1112 3.9.2. Interface Description 1114 TLS is commonly invoked using an API provided by packages such as 1115 OpenSSL, wolfSSL, or GnuTLS. Using such APIs entails the 1116 manipulation of several important abstractions, which fall into the 1117 following categories: long-term keys and algorithms, session state, 1118 and communications/connections. There may also be special APIs 1119 required to deal with time and/or random numbers, both of which are 1120 needed by a variety of encryption algorithms and protocols. 1122 Considerable care is required in the use of TLS APIs in order to 1123 create a secure application. The programmer should have at least a 1124 basic understanding of encryption and digital signature algorithms 1125 and their strengths, public key infrastructure (including X.509 1126 certificates and certificate revocation), and the sockets API. See 1127 [RFC7525] and [RFC7457], as mentioned above. 1129 As an example, in the case of OpenSSL, the primary abstractions are 1130 the library itself and method (protocol), session, context, cipher 1131 and connection. After initializing the library and setting the 1132 method, a cipher suite is chosen and used to configure a context 1133 object. Session objects may then be minted according to the 1134 parameters present in a context object and associated with individual 1135 connections. Depending on how precisely the programmer wishes to 1136 select different algorithmic or protocol options, various levels of 1137 details may be required. 1139 3.9.3. Transport Protocol Components 1141 Both TLS and DTLS employ a layered architecture. The lower layer is 1142 commonly called the record protocol. It is responsible for 1143 fragmenting messages, applying message authentication codes (MACs), 1144 encrypting data, and invoking transmission from the underlying 1145 transport protocol. DTLS augments the TLS record protocol with 1146 sequence numbers used for ordering and replay detection. 1148 Several protocols are layered on top of the record protocol. These 1149 include the handshake, alert, and change cipher spec protocols. 1150 There is also the data protocol, used to carry application traffic. 1151 The handshake protocol is used to establish cryptographic and 1152 compression parameters when a connection is first set up. In DTLS, 1153 this protocol also has a basic fragmentation and retransmission 1154 capability and a cookie-like mechanism to resist DoS attacks. (TLS 1155 compression is not recommended at present). The alert protocol is 1156 used to inform the peer of various conditions, most of which are 1157 terminal for the connection. The change cipher spec protocol is used 1158 to synchronize changes in cryptographic parameters for each peer. 1160 3.10. Hypertext Transport Protocol (HTTP) over TCP as a pseudotransport 1162 Hypertext Transfer Protocol (HTTP) is an application-level protocol 1163 widely used on the Internet. Version 1.1 of the protocol is 1164 specified in [RFC7230] [RFC7231] [RFC7232] [RFC7233] [RFC7234] 1165 [RFC7235], and version 2 in [RFC7540]. Furthermore, HTTP is used as 1166 a substrate for other application-layer protocols. There are various 1167 reasons for this practice listed in [RFC3205]; these include being a 1168 well-known and well-understood protocol, reusability of existing 1169 servers and client libraries, easy use of existing security 1170 mechanisms such as HTTP digest authentication [RFC2617] and TLS 1171 [RFC5246], the ability of HTTP to traverse firewalls which makes it 1172 work with a lot of infrastructure, and cases where a application 1173 server often needs to support HTTP anyway. 1175 Depending on application's needs, the use of HTTP as a substrate 1176 protocol may add complexity and overhead in comparison to a special- 1177 purpose protocol (e.g. HTTP headers, suitability of the HTTP security 1178 model etc.). [RFC3205] address this issues and provides some 1179 guidelines and concerns about the use of HTTP standard port 80 and 1180 443, the use of HTTP URL scheme and interaction with existing 1181 firewalls, proxies and NATs. 1183 Though not strictly bound to TCP, HTTP is almost exclusively run over 1184 TCP, and therefore inherits its properties when used in this way. 1186 3.10.1. Protocol Description 1188 Hypertext Transfer Protocol (HTTP) is a request/response protocol. A 1189 client sends a request containing a request method, URI and protocol 1190 version followed by a MIME-like message (see [RFC7231] for the 1191 differences between an HTTP object and a MIME message), containing 1192 information about the client and request modifiers. The message can 1193 contain a message body carrying application data as well. The server 1194 responds with a status or error code followed by a MIME-like message 1195 containing information about the server and information about carried 1196 data and it can include a message body. It is possible to specify a 1197 data format for the message body using MIME media types [RFC2045]. 1198 Furthermore, the protocol has numerous additional features; features 1199 relevant to pseudotransport are described below. 1201 Content negotiation, specified in [RFC7231], is a mechanism provided 1202 by HTTP for selecting a representation on a requested resource. The 1203 client and server negotiate acceptable data formats, charsets, data 1204 encoding (e.g. data can be transferred compressed, gzip), etc. HTTP 1205 can accommodate exchange of messages as well as data streaming (using 1206 chunked transfer encoding [RFC7230]). It is also possible to request 1207 a part of a resource using range requests specified in [RFC7233]. 1208 The protocol provides powerful cache control signalling defined in 1209 [RFC7234]. 1211 HTTP 1.1's and HTTP 2.0's persistent connections can be use to 1212 perform multiple request-response transactions during the life-time 1213 of a single HTTP connection. Moreover, HTTP 2.0 connections can 1214 multiplex many request/response pairs in parallel on a single 1215 connection. This reduces connection establishment overhead and the 1216 effect of TCP slow-start on each transaction, important for HTTP's 1217 primary use case. 1219 It is possible to combine HTTP with security mechanisms, like TLS 1220 (denoted by HTTPS), which adds protocol properties provided by such a 1221 mechanism (e.g. authentication, encryption, etc.). TLS's 1222 Application-Layer Protocol Negotiation (ALPN) extension [RFC7301] can 1223 be used for HTTP version negotiation within TLS handshake which 1224 eliminates addition round-trip. Arbitrary cookie strings, included 1225 as part of the MIME headers, are often used as bearer tokens in HTTP. 1227 Application layer protocols using HTTP as substrate may use existing 1228 method and data formats, or specify new methods and data formats. 1229 Furthermore some protocols may not fit a request/response paradigm 1230 and instead rely on HTTP to send messages (e.g. [RFC6546]). Because 1231 HTTP is working in many restricted infrastructures, it is also used 1232 to tunnel other application-layer protocols. 1234 3.10.2. Interface Description 1236 There are many HTTP libraries available exposing different APIs. The 1237 APIs provide a way to specify a request by providing a URI, a method, 1238 request modifiers and optionally a request body. For the response, 1239 callbacks can be registered that will be invoked when the response is 1240 received. If TLS is used, API expose a registration of callbacks in 1241 case a server requests client authentication and when certificate 1242 verification is needed. 1244 World Wide Web Consortium (W3C) standardized the XMLHttpRequest API 1245 [XHR], an API that can be use for sending HTTP/HTTPS requests and 1246 receiving server responses. Besides XML data format, request and 1247 response data format can also be JSON, HTML and plain text. 1248 Specifically JavaScript and XMLHttpRequest are a ubiquitous 1249 programming model for websites, and more general applications, where 1250 native code is less attractive. 1252 Representational State Transfer (REST) [REST] is another example how 1253 applications can use HTTP as transport protocol. REST is an 1254 architecture style for building application on the Internet. It uses 1255 HTTP as a communication protocol. 1257 3.10.3. Transport Protocol Components 1259 The transport protocol components provided by HTTP, when used as a 1260 pseudotransport, are: 1262 o unicast 1264 o reliable delivery 1266 o ordered delivery 1268 o message and stream-oriented 1270 o object range request 1272 o message content type negotiation 1274 o congestion control 1276 HTTPS (HTTP over TLS) additionally provides the following components: 1278 o authentication (of one or both ends of a connection) 1280 o confidentiality 1282 o integrity protection 1284 3.11. WebSockets 1286 [RFC6455] 1288 [EDITOR'S NOTE: Salvatore Loreto will contribute text for this 1289 section.] 1291 3.11.1. Protocol Description 1293 3.11.2. Interface Description 1294 3.11.3. Transport Protocol Components 1296 4. Transport Service Features 1298 [EDITOR'S NOTE: This section is still work-in-progress. This list is 1299 probably not complete and/or too detailed.] 1301 The transport protocol components analyzed in this document which can 1302 be used as a basis for defining common transport service features, 1303 normalized and separated into categories, are as follows: 1305 o Control Functions 1307 * Addressing 1309 + unicast 1311 + broadcast (IPv4 only) 1313 + multicast 1315 + anycast 1317 + something on ports and NAT 1319 * Multihoming support 1321 + multihoming for resilience 1323 + multihoming for mobility 1325 - specify handover latency? 1327 + multihoming for load-balancing 1329 - specify interleaving delay? 1331 * Multiplexing 1333 + application to port mapping 1335 + single vs. multiple streaming 1337 o Delivery 1339 * reliability 1341 + reliable delivery 1342 + partially reliable delivery 1344 - packet erasure coding 1346 + unreliable delivery 1348 - drop notification 1350 - Integrity protection 1352 o checksum for error detection 1354 o partial checksum protection 1356 o checksum optional 1358 * ordering 1360 + ordered delivery 1362 + unordered delivery 1364 - unordered delivery of in-memory data 1366 * type/framing 1368 + stream-oriented delivery 1370 + message-oriented delivery 1372 + object-oriented delivery of discrete data or file items 1374 - object content type negotiation 1376 + range-based partical object transmission 1378 + file bulk content objects 1380 o Transmission control 1382 * rate control 1384 + timer-based 1386 + ACK-based 1388 * congestion control 1389 * flow control 1391 * segmentation 1393 * data/message bundling (Nagle's algorithm) 1395 * stream scheduling prioritization 1397 o Security 1399 * authentication of one end of a connection 1401 * authentication of both ends of a connection 1403 * confidentiality 1405 * cryptographic integrity protection 1407 The next revision of this document will define transport service 1408 features based upon this list. 1410 [EDITOR'S NOTE: this section will drawn from the candidate features 1411 provided by protocol components in the previous section - please 1412 discuss on taps@ietf.org list] 1414 4.1. Complete Protocol Feature Matrix 1416 [EDITOR'S NOTE: Dave Thaler has signed up as a contributor for this 1417 section. Michael Welzl also has a beginning of a matrix which could 1418 be useful here.] 1420 [EDITOR'S NOTE: The below is a strawman proposal below by Gorry 1421 Fairhurst for initial discussion] 1423 The table below summarises protocol mechanisms that have been 1424 standardised. It does not make an assessment on whether specific 1425 implementations are fully compliant to these specifications. 1427 +-----------------+---------+---------+---------+---------+---------+ 1428 | Mechanism | UDP | UDP-L | DCCP | SCTP | TCP | 1429 +-----------------+---------+---------+---------+---------+---------+ 1430 | Unicast | Yes | Yes | Yes | Yes | Yes | 1431 | | | | | | | 1432 | Mcast/IPv4Bcast | Yes(2) | Yes | No | No | No | 1433 | | | | | | | 1434 | Port Mux | Yes | Yes | Yes | Yes | Yes | 1435 | | | | | | | 1436 | Mode | Dgram | Dgram | Dgram | Dgram | Stream | 1437 | | | | | | | 1438 | Connected | No | No | Yes | Yes | Yes | 1439 | | | | | | | 1440 | Data bundling | No | No | No | Yes | Yes | 1441 | | | | | | | 1442 | Feature Nego | No | No | Yes | Yes | Yes | 1443 | | | | | | | 1444 | Options | No | No | Support | Support | Support | 1445 | | | | | | | 1446 | Data priority | * | * | * | Yes | No | 1447 | | | | | | | 1448 | Data bundling | No | No | No | Yes | Yes | 1449 | | | | | | | 1450 | Reliability | None | None | None | Select | Full | 1451 | | | | | | | 1452 | Ordered deliv | No | No | No | Stream | Yes | 1453 | | | | | | | 1454 | Corruption Tol. | No | Support | Support | No | No | 1455 | | | | | | | 1456 | Flow Control | No | No | Support | Yes | Yes | 1457 | | | | | | | 1458 | PMTU/PLPMTU | (1) | (1) | Yes | Yes | Yes | 1459 | | | | | | | 1460 | Cong Control | (1) | (1) | Yes | Yes | Yes | 1461 | | | | | | | 1462 | ECN Support | (1) | (1) | Yes | TBD | Yes | 1463 | | | | | | | 1464 | NAT support | Limited | Limited | Support | TBD | Support | 1465 | | | | | | | 1466 | Security | DTLS | DTLS | DTLS | DTLS | TLS, AO | 1467 | | | | | | | 1468 | UDP encaps | N/A | None | Yes | Yes | None | 1469 | | | | | | | 1470 | RTP support | Support | Support | Support | ? | Support | 1471 +-----------------+---------+---------+---------+---------+---------+ 1473 Note (1): this feature requires support in an upper layer protocol. 1475 Note (2): this feature requires support in an upper layer protocol 1476 when used with IPv6. 1478 5. IANA Considerations 1480 This document has no considerations for IANA. 1482 6. Security Considerations 1483 This document surveys existing transport protocols and protocols 1484 providing transport-like services. Confidentiality, integrity, and 1485 authenticity are among the features provided by those services. This 1486 document does not specify any new components or mechanisms for 1487 providing these features. Each RFC listed in this document discusses 1488 the security considerations of the specification it contains. 1490 7. Contributors 1492 [Editor's Note: turn this into a real contributors section with 1493 addresses once we figure out how to trick the toolchain into doing 1494 so] 1496 o Section 3.2 on MPTCP was contributed by Simone Ferlin-Oliviera 1497 (ferlin@simula.no) and Olivier Mehani 1498 (olivier.mehani@nicta.com.au) 1500 o Section 3.4 on UDP was contributed by Kevin Fall (kfall@kfall.com) 1502 o Section 3.3 on SCTP was contributed by Michael Tuexen (tuexen@fh- 1503 muenster.de) 1505 o Section 3.8 on NORM was contributed by Brian Adamson 1506 (brian.adamson@nrl.navy.mil) 1508 o Section 3.9 on MPTCP was contributed by Ralph Holz 1509 (ralph.holz@nicta.com.au) and Olivier Mehani 1510 (olivier.mehani@nicta.com.au) 1512 o Section 3.10 on HTTP was contributed by Dragana Damjanovic 1513 (ddamjanovic@mozilla.com) 1515 8. Acknowledgments 1517 Thanks to Karen Nielsen, Joe Touch, and Michael Welzl for the 1518 comments, feedback, and discussion. This work is partially supported 1519 by the European Commission under grant agreement FP7-ICT-318627 1520 mPlane; support does not imply endorsement. 1522 [EDITOR'S NOTE: add H2020-NEAT ack]. 1524 9. References 1525 9.1. Normative References 1527 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1528 1981. 1530 9.2. Informative References 1532 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1533 August 1980. 1535 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1536 793, September 1981. 1538 [RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", 1539 RFC 896, January 1984. 1541 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1542 Communication Layers", STD 3, RFC 1122, October 1989. 1544 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1545 November 1990. 1547 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 1548 for IP version 6", RFC 1981, August 1996. 1550 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 1551 Selective Acknowledgment Options", RFC 2018, October 1996. 1553 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1554 Extensions (MIME) Part One: Format of Internet Message 1555 Bodies", RFC 2045, November 1996. 1557 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1558 (IPv6) Specification", RFC 2460, December 1998. 1560 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1561 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1562 Authentication: Basic and Digest Access Authentication", 1563 RFC 2617, June 1999. 1565 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1566 of Explicit Congestion Notification (ECN) to IP", RFC 1567 3168, September 2001. 1569 [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, 1570 RFC 3205, February 2002. 1572 [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's 1573 Initial Window", RFC 3390, October 2002. 1575 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 1576 Layer Security over Stream Control Transmission Protocol", 1577 RFC 3436, December 2002. 1579 [RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 1580 M., and J. Crowcroft, "Forward Error Correction (FEC) 1581 Building Block", RFC 3452, December 2002. 1583 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 1584 Conrad, "Stream Control Transmission Protocol (SCTP) 1585 Partial Reliability Extension", RFC 3758, May 2004. 1587 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 1588 G. Fairhurst, "The Lightweight User Datagram Protocol 1589 (UDP-Lite)", RFC 3828, July 2004. 1591 [RFC4324] Royer, D., Babics, G., and S. Mansour, "Calendar Access 1592 Protocol (CAP)", RFC 4324, December 2005. 1594 [RFC4336] Floyd, S., Handley, M., and E. Kohler, "Problem Statement 1595 for the Datagram Congestion Control Protocol (DCCP)", RFC 1596 4336, March 2006. 1598 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1599 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1601 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 1602 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 1603 Congestion Control", RFC 4341, March 2006. 1605 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 1606 Datagram Congestion Control Protocol (DCCP) Congestion 1607 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 1608 March 2006. 1610 [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap 1611 for Transmission Control Protocol (TCP) Specification 1612 Documents", RFC 4614, September 2006. 1614 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast 1615 Congestion Control (TFMCC): Protocol Specification", RFC 1616 4654, August 2006. 1618 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 1619 Parameter for the Stream Control Transmission Protocol 1620 (SCTP)", RFC 4820, March 2007. 1622 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1623 Discovery", RFC 4821, March 2007. 1625 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 1626 "Authenticated Chunks for the Stream Control Transmission 1627 Protocol (SCTP)", RFC 4895, August 2007. 1629 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 1630 4960, September 2007. 1632 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 1633 Kozuka, "Stream Control Transmission Protocol (SCTP) 1634 Dynamic Address Reconfiguration", RFC 5061, September 1635 2007. 1637 [RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite 1638 protocol", RFC 5097, January 2008. 1640 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1641 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1643 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 1644 Friendly Rate Control (TFRC): Protocol Specification", RFC 1645 5348, September 2008. 1647 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1648 for Application Designers", BCP 145, RFC 5405, November 1649 2008. 1651 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 1652 (DCCP) Service Codes", RFC 5595, September 2009. 1654 [RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol 1655 (DCCP) Simultaneous-Open Technique to Facilitate NAT/ 1656 Middlebox Traversal", RFC 5596, September 2009. 1658 [RFC5662] Shepler, S., Eisler, M., and D. Noveck, "Network File 1659 System (NFS) Version 4 Minor Version 1 External Data 1660 Representation Standard (XDR) Description", RFC 5662, 1661 January 2010. 1663 [RFC5672] Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM) 1664 Signatures -- Update", RFC 5672, August 2009. 1666 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 1667 "NACK-Oriented Reliable Multicast (NORM) Transport 1668 Protocol", RFC 5740, November 2009. 1670 [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A 1671 Datagram Congestion Control Protocol UDP Encapsulation for 1672 NAT Traversal", RFC 6773, November 2012. 1674 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1675 Authentication Option", RFC 5925, June 2010. 1677 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 1678 Control", RFC 5681, September 2009. 1680 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 1681 Transport Layer Security (DTLS) for Stream Control 1682 Transmission Protocol (SCTP)", RFC 6083, January 2011. 1684 [RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the 1685 TCP Urgent Mechanism", RFC 6093, January 2011. 1687 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 1688 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 1689 6525, February 2012. 1691 [RFC6546] Trammell, B., "Transport of Real-time Inter-network 1692 Defense (RID) Messages over HTTP/TLS", RFC 6546, April 1693 2012. 1695 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 1696 "Computing TCP's Retransmission Timer", RFC 6298, June 1697 2011. 1699 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1700 Security Version 1.2", RFC 6347, January 2012. 1702 [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled 1703 Congestion Control for Multipath Transport Protocols", RFC 1704 6356, October 2011. 1706 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 1707 6455, December 2011. 1709 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 1710 Yasevich, "Sockets API Extensions for the Stream Control 1711 Transmission Protocol (SCTP)", RFC 6458, December 2011. 1713 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 1714 RFC 6691, July 2012. 1716 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1717 "TCP Extensions for Multipath Operation with Multiple 1718 Addresses", RFC 6824, January 2013. 1720 [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application 1721 Interface Considerations", RFC 6897, March 2013. 1723 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 1724 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 1726 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1727 for the Use of IPv6 UDP Datagrams with Zero Checksums", 1728 RFC 6936, April 2013. 1730 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 1731 Control Transmission Protocol (SCTP) Packets for End-Host 1732 to End-Host Communication", RFC 6951, May 2013. 1734 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 1735 IMMEDIATELY Extension for the Stream Control Transmission 1736 Protocol", RFC 7053, November 2013. 1738 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1739 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 1740 2014. 1742 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1743 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 1745 [RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1746 (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. 1748 [RFC7233] Fielding, R., Lafon, Y., and J. Reschke, "Hypertext 1749 Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, 1750 June 2014. 1752 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 1753 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 1754 2014. 1756 [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1757 (HTTP/1.1): Authentication", RFC 7235, June 2014. 1759 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1760 "Transport Layer Security (TLS) Application-Layer Protocol 1761 Negotiation Extension", RFC 7301, July 2014. 1763 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 1764 Scheffenegger, "TCP Extensions for High Performance", RFC 1765 7323, September 2014. 1767 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1768 Known Attacks on Transport Layer Security (TLS) and 1769 Datagram TLS (DTLS)", RFC 7457, February 2015. 1771 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1772 "Recommendations for Secure Use of Transport Layer 1773 Security (TLS) and Datagram Transport Layer Security 1774 (DTLS)", BCP 195, RFC 7525, May 2015. 1776 [RFC7540] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 1777 Protocol Version 2 (HTTP/2)", RFC 7540, May 2015. 1779 [I-D.ietf-aqm-ecn-benefits] 1780 Fairhurst, G. and M. Welzl, "The Benefits of using 1781 Explicit Congestion Notification (ECN)", draft-ietf-aqm- 1782 ecn-benefits-05 (work in progress), June 2015. 1784 [I-D.ietf-tsvwg-sctp-dtls-encaps] 1785 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 1786 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 1787 dtls-encaps-09 (work in progress), January 2015. 1789 [I-D.ietf-tsvwg-sctp-prpolicies] 1790 Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, 1791 "Additional Policies for the Partial Reliability Extension 1792 of the Stream Control Transmission Protocol", draft-ietf- 1793 tsvwg-sctp-prpolicies-07 (work in progress), February 1794 2015. 1796 [I-D.ietf-tsvwg-sctp-ndata] 1797 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 1798 "Stream Schedulers and User Message Interleaving for the 1799 Stream Control Transmission Protocol", draft-ietf-tsvwg- 1800 sctp-ndata-03 (work in progress), March 2015. 1802 [I-D.ietf-tsvwg-natsupp] 1803 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 1804 Transmission Protocol (SCTP) Network Address Translation 1805 Support", draft-ietf-tsvwg-natsupp-07 (work in progress), 1806 February 2015. 1808 [XHR] van Kesteren, A., Aubourg, J., Song, J., and H. Steen, 1809 "XMLHttpRequest working draft 1810 (http://www.w3.org/TR/XMLHttpRequest/)", 2000. 1812 [REST] Fielding, R., "Architectural Styles and the Design of 1813 Network-based Software Architectures, Ph. D. (UC Irvune), 1814 Chapter 5: Representational State Transfer", 2000. 1816 Authors' Addresses 1818 Godred Fairhurst (editor) 1819 University of Aberdeen 1820 School of Engineering, Fraser Noble Building 1821 Aberdeen AB24 3UE 1823 Email: gorry@erg.abdn.ac.uk 1825 Brian Trammell (editor) 1826 ETH Zurich 1827 Gloriastrasse 35 1828 8092 Zurich 1829 Switzerland 1831 Email: ietf@trammell.ch 1833 Mirja Kuehlewind (editor) 1834 ETH Zurich 1835 Gloriastrasse 35 1836 8092 Zurich 1837 Switzerland 1839 Email: mirja.kuehlewind@tik.ee.ethz.ch