idnits 2.17.1 draft-ietf-taps-transports-03.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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. 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 192: '... [EDITOR'S NOTE: add URGENT and PUSH flag (note [RFC6093] says SHOULD...' RFC 2119 keyword, line 680: '...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 (February 27, 2015) is 3346 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0791' is defined on line 911, but no explicit reference was found in the text == Unused Reference: 'RFC3390' is defined on line 947, but no explicit reference was found in the text == Unused Reference: 'RFC5348' is defined on line 1007, but no explicit reference was found in the text == Unused Reference: 'RFC5925' is defined on line 1034, but no explicit reference was found in the text == Unused Reference: 'RFC5681' is defined on line 1037, but no explicit reference was found in the text == Unused Reference: 'RFC6298' is defined on line 1051, but no explicit reference was found in the text == Unused Reference: 'RFC6691' is defined on line 1072, 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 3205 (Obsoleted by RFC 9205) -- 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) == 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-02 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 16 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: August 31, 2015 M. Kuehlewind, Ed. 6 ETH Zurich 7 February 27, 2015 9 Services provided by IETF transport protocols and congestion control 10 mechanisms 11 draft-ietf-taps-transports-03 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 August 31, 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 1. Introduction 54 Most Internet applications make use of the Transport Services 55 provided by TCP (a reliable, in-order stream protocol) or UDP (an 56 unreliable datagram protocol). We use the term "Transport Service" 57 to mean the end-to-end service provided to an application by the 58 transport layer. That service can only be provided correctly if 59 information about the intended usage is supplied from the 60 application. The application may determine this information at 61 design time, compile time, or run time, and may include guidance on 62 whether a feature is required, a preference by the application, or 63 something in between. Examples of features of Transport Services are 64 reliable delivery, ordered delivery, content privacy to in-path 65 devices, integrity protection, and minimal latency. 67 The IETF has defined a wide variety of transport protocols beyond TCP 68 and UDP, including TCP, SCTP, DCCP, MP-TCP, and UDP-Lite. Transport 69 services may be provided directly by these transport protocols, or 70 layered on top of them using protocols such as WebSockets (which runs 71 over TCP) or RTP (over TCP or UDP). Services built on top of UDP or 72 UDP-Lite typically also need to specify additional mechanisms, 73 including a congestion control mechanism (such as a windowed 74 congestion control, TFRC or LEDBAT congestion control mechanism). 75 This extends the set of available Transport Services beyond those 76 provided to applications by TCP and UDP. 78 Transport protocols can also be differentiated by the features of the 79 services they provide: for instance, SCTP offers a message-based 80 service that does not suffer head-of-line blocking when used with 81 multiple stream, because it can accept blocks of data out of order, 82 UDP-Lite provides partial integrity protection, and LEDBAT can 83 provide low-priority "scavenger" communication. 85 2. Terminology 87 The following terms are defined throughout this document, and in 88 subsequent documents produced by TAPS describing the composition and 89 decomposition of transport services. 91 [NOTE: The terminology below was presented at the TAPS WG meeting in 92 Honolulu. While the factoring of the terminology seems 93 uncontroversial, there may be some entities which still require names 94 (e.g. information about the interface between the transport and lower 95 layers which could lead to the availability or unavailability of 96 certain transport protocol features). Comments are welcome via the 97 TAPS mailing list.] 99 Transport Service Feature: a specific end-to-end feature that a 100 transport service provides to its clients. Examples include 101 confidentiality, reliable delivery, ordered delivery, message- 102 versus-stream orientation, etc. 104 Transport Service: a set of transport service features, without an 105 association to any given framing protocol, which provides a 106 complete service to an application. 108 Transport Protocol: an implementation that provides one or more 109 different transport services using a specific framing and header 110 format on the wire. 112 Transport Protocol Component: an implementation of a transport 113 service feature within a protocol. 115 Transport Service Instance: an arrangement of transport protocols 116 with a selected set of features and configuration parameters that 117 implements a single transport service, e.g. a protocol stack (RTP 118 over UDP). 120 Application: an entity that uses the transport layer for end-to-end 121 delivery data across the network (this may also be an upper layer 122 protocol or tunnel encapsulation). 124 3. Existing Transport Protocols 126 This section provides a list of known IETF transport protocol and 127 transport protocol frameworks. 129 [EDITOR'S NOTE: Contributions to the subsections below are welcome] 131 3.1. Transport Control Protocol (TCP) 133 TCP is an IETF standards track transport protocol. [RFC0793] 134 introduces TCP as follows: "The Transmission Control Protocol (TCP) 135 is intended for use as a highly reliable host-to-host protocol 136 between hosts in packet-switched computer communication networks, and 137 in interconnected systems of such networks." Since its introduction, 138 TCP has become the default connection-oriented, stream-based 139 transport protocol in the Internet. It is widely implemented by 140 endpoints and widely used by common applications. 142 3.1.1. Protocol Description 144 TCP is a connection-oriented protocol, providing a three way 145 handshake to allow a client and server to set up a connection, and 146 mechanisms for orderly completion and immediate teardown of a 147 connection. TCP is defined by a family of RFCs [RFC4614]. 149 TCP provides multiplexing to multiple sockets on each host using port 150 numbers. An active TCP session is identified by its four-tuple of 151 local and remote IP addresses and local port and remote port numbers. 152 The destination port during connection setup has a different role as 153 it is often used to indicate the requested service. 155 TCP partitions a continuous stream of bytes into segments, sized to 156 fit in IP packets. ICMP-based PathMTU discovery [RFC1191][RFC1981] 157 as well as Packetization Layer Path MTU Discovery (PMTUD) [RFC4821] 158 are supported. 160 Each byte in the stream is identified by a sequence number. The 161 sequence number is used to order segments on receipt, to identify 162 segments in acknowledgments, and to detect unacknowledged segments 163 for retransmission. This is the basis of TCP's reliable, ordered 164 delivery of data in a stream. TCP Selective Acknowledgment [RFC2018] 165 extends this mechanism by making it possible to identify missing 166 segments more precisely, reducing spurious retransmission. 168 Receiver flow control is provided by a sliding window: limiting the 169 amount of unacknowledged data that can be outstanding at a given 170 time. The window scale option [RFC7323] allows a receiver to use 171 windows greater than 64KB. 173 All TCP senders provide Congestion Control: This uses a separate 174 window, where each time congestion is detected, this congestion 175 window is reduced. A receiver detects congestion using one of three 176 mechanisms: A retransmission timer, detection of loss (interpreted as 177 a congestion signal), or Explicit Congestion Notification (ECN) 178 [RFC3168] to provide early signaling (see 179 [I-D.ietf-aqm-ecn-benefits]) 181 A TCP protocol instance can be extended [RFC4614] and tuned. Some 182 features are sender-side only, requiring no negotiation with the 183 receiver; some are receiver-side only, some are explicitly negotiated 184 during connection setup. 186 By default, TCP segment partitioning uses Nagle's algorithm [RFC0896] 187 to buffer data at the sender into large segments, potentially 188 incurring sender-side buffering delay; this algorithm can be disabled 189 by the sender to transmit more immediately, e.g. to enable smoother 190 interactive sessions. 192 [EDITOR'S NOTE: add URGENT and PUSH flag (note [RFC6093] says SHOULD 193 NOT use due to the range of TCP implementations that process TCP 194 urgent indications differently.) ] 196 A checksum provides an Integrity Check and is mandatory across the 197 entire packet. The TCP checksum does not support partial corruption 198 protection as in DCCP/UDP-Lite). This check protects from 199 misdelivery of data corrupted data, but is relatively weak, and 200 applications that require end to end integrity of data are 201 recommended to include a stronger integrity check of their payload 202 data. 204 A TCP service is unicast. 206 3.1.2. Interface description 208 A User/TCP Interface is defined in [RFC0793] providing six user 209 commands: Open, Send, Receive, Close, Status. This interface does 210 not describe configuration of TCP options or parameters beside use of 211 the PUSH and URGENT flags. 213 In API implementations derived from the BSD Sockets API, TCP sockets 214 are created using the "SOCK_STREAM" socket type. 216 The features used by a protocol instance may be set and tuned via 217 this API. 219 (more on the API goes here) 221 3.1.3. Transport Protocol Components 223 The transport protocol components provided by TCP are: 225 o unicast 227 o connection setup with feature negotiation and application-to-port 228 mapping 230 o port multiplexing 232 o reliable delivery 234 o ordered delivery for each byte stream 236 o error detection (checksum) 237 o segmentation 239 o stream-oriented delivery in a single stream 241 o data bundling (Nagle's algorithm) 243 o flow control 245 o congestion control 247 [EDITOR'S NOTE: discussion of how to map this to features and TAPS: 248 what does the higher layer need to decide? what can the transport 249 layer decide based on global settings? what must the transport layer 250 decide based on network characteristics?] 252 3.2. Multipath TCP (MP-TCP) 254 [EDITOR'S NOTE: a few sentences describing Multipath TCP [RFC6824] go 255 here. Note that this adds transport-layer multihoming to the 256 components TCP provides] 258 3.3. Stream Control Transmission Protocol (SCTP) 260 SCTP is a message oriented standards track transport protocol and the 261 base protocol is specified in [RFC4960]. It supports multi-homing to 262 handle path failures. An SCTP association has multiple 263 unidirectional streams in each direction and provides in-sequence 264 delivery of user messages only within each stream. This allows to 265 minimize head of line blocking. SCTP is extensible and the currently 266 defined extensions include mechanisms for dynamic re-configurations 267 of streams [RFC6525] and IP-addresses [RFC5061]. Furthermore, the 268 extension specified in [RFC3758] introduces the concept of partial 269 reliability for user messages. 271 SCTP was originally developed for transporting telephony signalling 272 messages and is deployed in telephony signalling networks, especially 273 in mobile telephony networks. Additionally, it is used in the WebRTC 274 framework for data channels and is therefore deployed in all WEB- 275 browsers supporting WebRTC. 277 [EDITOR'S NOTE: Michael Tuexen and Karen Nielsen signed up as 278 contributors for these sections.] 280 3.3.1. Protocol Description 282 SCTP is a connection oriented protocol using a four way handshake to 283 establish an SCTP association and a three way message exchange to 284 gracefully shut it down. It uses the same port number concept as 285 DCCP, TCP, UDP, and UDP-Lite do and only supports unicast. 287 SCTP uses the 32-bit CRC32c for protecting SCTP packets against bit 288 errors. This is stronger than the 16-bit checksums used by TCP or 289 UDP. However, a partial checksum coverage as provided by DCCP or 290 UDP-Lite is not supported. 292 SCTP has been designed with extensibility in mind. Each SCTP packet 293 starts with a single common header containing the port numbers, a 294 verification tag and the CRC32c checksum. This common header is 295 followed by a sequence of chunks. Each chunk consists of a type 296 field, flags, a length field and a value. [RFC4960] defines how a 297 receiver processes chunks with an unknown chunk type. The support of 298 extensions can be negotiated during the SCTP handshake. 300 SCTP provides a message-oriented service. Multiple small user 301 messages can be bundled into a single SCTP packet to improve the 302 efficiency. User messages which would result in IP packets larger 303 than the MTU will be fragmented at the sender side and reassembled at 304 the receiver side. There is no protocol limit on the user message 305 size. [RFC4821] defines a method to perform packetization layer path 306 MTU discovery with probe packets using the padding chunks defined the 307 [RFC4820]. 309 [RFC4960] specifies a TCP friendly congestion control to protect the 310 network against overload. SCTP also uses a sliding window flow 311 control to protect receivers against overflow. 313 Each SCTP association has between 1 and 65536 uni-directional streams 314 in each direction. The number of streams can be different in each 315 direction. Every user-message is sent on a particular stream. User 316 messages can be sent ordered or un-ordered upon request by the upper 317 layer. Only all ordered messages sent on the same stream are 318 delivered at the receiver in the same order as sent by the sender. 319 For user messages not requiring fragmentation, this minimises head of 320 line blocking. The base protocol defined in [RFC4960] doesn't allow 321 interleaving of user-messages, which results in sending a large 322 message on one stream can block the sending of user messages on other 323 streams. [I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation and 324 also allows to specify a scheduler for the sender side streams 325 selection. The stream re-configuration extension defined in 326 [RFC6525] allows to reset streams during the lifetime of an 327 association and to increase the number of streams, if the number of 328 streams negotiated in the SCTP handshake is not sufficient. 330 According to [RFC4960], each user message sent is either delivered to 331 the receiver or, in case of excessive retransmissions, the 332 association is terminated in a non-graceful way, similar to the TCP 333 behaviour. In addition to this reliable transfer, the partial 334 reliability extension defined in [RFC3758] allows the sender to 335 abandon user messages. The application can specify the policy for 336 abandoning user messages. Examples for these policies include: 338 o Limiting the time a user message is dealt with by the sender. 340 o Limiting the number of retransmissions for each fragment of a user 341 message. 343 o Abandoning messages of lower priority in case of a send buffer 344 shortage. 346 SCTP supports multi-homing. Each SCTP end-point uses a list of IP- 347 addresses and a single port number. These addresses can be any 348 mixture of IPv4 and IPv6 addresses. These addresses are negotiated 349 during the handshake and the address re-configuration extension 350 specified in [RFC5061] can be used to change these addresses during 351 the livetime of an SCTP association. This allows for transport layer 352 mobility. Multiple addresses are used for improved resilience. If a 353 remote address becomes unreachable, the traffic is switched over to a 354 reachable one, if one exists. Each SCTP end-point supervises 355 continuously the reachability of all peer addresses using a heartbeat 356 mechanism. 358 For securing user messages, the use of TLS over SCTP has been 359 specified in [RFC3436]. However, this solution does not support all 360 services provided by SCTP (for example un-ordered delivery or partial 361 reliability), and therefore the use of DTLS over SCTP has been 362 specified in [RFC6083] to overcome these limitations. When using 363 DTLS over SCTP, the application can use almost all services provided 364 by SCTP. 366 For legacy NAT traversal, [RFC6951] defines the UDP encapsulation of 367 SCTP-packets. Alternatively, SCTP packets can be encapsulated in 368 DTLS packets as specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. The 369 latter encapsulation is used with in the WebRTC context. 371 Having a well defined API is also a feature provided by SCTP as 372 described in the next subsection. 374 3.3.2. Interface Description 376 [RFC4960] defines an abstract API for the base protocol. An 377 extension to the BSD Sockets API is defined in [RFC6458] and covers: 379 o the base protocol defined in [RFC4960]. 381 o the SCTP Partial Reliability extension defined in [RFC3758]. 383 o the SCTP Authentication extension defined in [RFC4895]. 385 o the SCTP Dynamic Address Reconfiguration extension defined in 386 [RFC5061]. 388 For the following SCTP protocol extensions the BSD Sockets API 389 extension is defined in the document specifying the protocol 390 extensions: 392 o the SCTP SACK-IMMEDIATELY extension defined in [RFC7053]. 394 o the SCTP Stream Reconfiguration extension defined in [RFC6525]. 396 o the UDP Encapsulation of SCTP packets extension defined in 397 [RFC6951]. 399 o the additional PR-SCTP policies defined in 400 [I-D.ietf-tsvwg-sctp-prpolicies]. 402 Future documents describing SCTP protocol extensions are expected to 403 describe the corresponding BSD Sockets API extension in a "Socket API 404 Considerations" section. 406 The SCTP socket API supports two kinds of sockets: 408 o one-to-one style sockets (by using the socket type "SOCK_STREAM"). 410 o one-to-many style socket (by using the socket type 411 "SOCK_SEQPACKET"). 413 One-to-one style sockets are similar to TCP sockets, there is a 1:1 414 relationship between the sockets and the SCTP associations (except 415 for listening sockets). One-to-many style SCTP sockets are similar 416 to unconnected UDP sockets as there is a 1:n relationship between the 417 sockets and the SCTP associations. 419 The SCTP stack can provide information to the applications about 420 state changes of the individual paths and the association whenever 421 they occur. These events are delivered similar to user messages but 422 are specifically marked as notifications. 424 A couple of new functions have been introduced to support the use of 425 multiple local and remote addresses. Additional SCTP-specific send 426 and receive calls have been defined to allow dealing with the SCTP 427 specific information without using ancillary data in the form of 428 additional cmsgs, which are also defined. These functions provide 429 support for detecting partial delivery of user messages and 430 notifications. 432 The SCTP socket API allows a fine-grained control of the protocol 433 behaviour through an extensive set of socket options. 435 The SCTP kernel implementations of FreeBSD, Linux and Solaris follow 436 mostly the specified extension to the BSD Sockets API for the base 437 protocol and the corresponding supported protocol extensions. 439 3.3.3. Transport Protocol Components 441 The transport protocol components provided by SCTP are: 443 o unicast 445 o connection setup with feature negotiation and application-to-port 446 mapping 448 o port multiplexing 450 o reliable or partially reliable delivery 452 o ordered and unordered delivery within a stream 454 o support for multiple prioritised streams 456 o flow control (slow receiver function) 458 o message-oriented delivery 460 o congestion control 462 o application PDU bundling 464 o application PDU fragmentation and reassembly 466 o integrity check 468 o transport layer multihoming for resilience 470 o transport layer mobility 472 [EDITOR'S NOTE: update this list.] 474 3.4. User Datagram Protocol (UDP) 476 The User Datagram Protocol (UDP) [RFC0768] [RFC2460] is an IETF 477 standards track transport protocol. It provides a uni-directional, 478 datagram protocol which preserves message boundaries. It provides 479 none of the following transport features: error correction, 480 congestion control, or flow control. It can be used to send 481 broadcast datagrams (IPv4) or multicast datagrams (IPv4 and IPv6), in 482 addition to unicast (and anycast) datagrams. IETF guidance on the 483 use of UDP is provided in[RFC5405]. UDP is widely implemented and 484 widely used by common applications, especially DNS. 486 [EDITOR'S NOTE: Kevin Fall signed up as a contributor for this 487 section.] 489 3.4.1. Protocol Description 491 UDP is a connection-less protocol which maintains message boundaries, 492 with no connection setup or feature negotiation. The protocol uses 493 independent messages, ordinarily called datagrams. The lack of error 494 control and flow control implies messages may be damaged, re-ordered, 495 lost, or duplicated in transit. A receiving application unable to 496 run sufficiently fast or frequently may miss messages. The lack of 497 congestion handling implies UDP traffic may cause the loss of 498 messages from other protocols (e.g., TCP) when sharing the same 499 network paths. UDP traffic can also cause the loss of other UDP 500 traffic in the same or other flows for the same reasons. 502 Messages with bit errors are ordinarily detected by an invalid end- 503 to-end checksum and are discarded before being delivered to an 504 application. There are some exceptions to this general rule, 505 however. UDP-Lite (see [RFC3828], and below) provides the ability 506 for portions of the message contents to be exempt from checksum 507 coverage. It is also possible to create UDP datagrams with no 508 checksum, and while this is generally discouraged [RFC1122] 509 [RFC5405], certain special cases permit its use [RFC6935]. The 510 checksum support considerations for omitting the checksum are defined 511 in [RFC6936]. Note that due to the relatively weak form of checksum 512 used by UDP, applications that require end to end integrity of data 513 are recommended to include a stronger integrity check of their 514 payload data. 516 On transmission, UDP encapsulates each datagram into an IP packet, 517 which may in turn be fragmented by IP. Applications concerned with 518 fragmentation or that have other requirements such as receiver flow 519 control, congestion control, PathMTU discovery/PLPMTUD, support for 520 ECN, etc need to be provided by protocols other than UDP [RFC5405]. 522 3.4.2. Interface Description 524 [RFC0768] describes basic requirements for an API for UDP. Guidance 525 on use of common APIs is provided in [RFC5405]. 527 A UDP endpoint consists of a tuple of (IP address, port number). 528 Demultiplexing using multiple abstract endpoints (sockets) on the 529 same IP address are supported. The same socket may be used by a 530 single server to interact with multiple clients (note: this behavior 531 differs from TCP, which uses a pair of tuples to identify a 532 connection). Multiple server instances (processes) binding the same 533 socket can cooperate to service multiple clients- the socket 534 implementation arranges to not duplicate the same received unicast 535 message to multiple server processes. 537 Many operating systems also allow a UDP socket to be "connected", 538 i.e., to bind a UDP socket to a specific (remote) UDP endpoint. 539 Unlike TCP's connect primitive, for UDP, this is only a local 540 operation that serves to simplify the local send/receive functions 541 and to filter the traffic for the specified addresses and ports 542 [RFC5405]. 544 3.4.3. Transport Protocol Components 546 The transport protocol components provided by UDP are: 548 o unidirectional 550 o port multiplexing 552 o 2-tuple endpoints 554 o IPv4 broadcast, multicast and anycast 556 o IPv6 multicast and anycast 558 o IPv6 jumbograms 560 o message-oriented delivery 562 o error detection (checksum) 564 o checksum optional 566 3.5. Lightweight User Datagram Protocol (UDP-Lite) 568 The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] is an 569 IETF standards track transport protocol. UDP-Lite provides a 570 bidirectional set of logical unicast or multicast message streams 571 over a datagram protocol. IETF guidance on the use of UDP-Lite is 572 provided in [RFC5405]. 574 [EDITOR'S NOTE: Gorry Fairhurst signed up as a contributor for this 575 section.] 577 3.5.1. Protocol Description 579 UDP-Lite is a connection-less datagram protocol, with no connection 580 setup or feature negotiation. The protocol use messages, rather than 581 a byte-stream. Each stream of messages is independently managed, 582 therefore retransmission does not hold back data sent using other 583 logical streams. 585 It provides multiplexing to multiple sockets on each host using port 586 numbers. An active UDP-Lite session is identified by its four-tuple 587 of local and remote IP addresses and local port and remote port 588 numbers. 590 UDP-Lite fragments packets into IP packets, constrained by the 591 maximum size of IP packet. 593 UDP-Lite changes the semantics of the UDP "payload length" field to 594 that of a "checksum coverage length" field. Otherwise, UDP-Lite is 595 semantically identical to UDP. Applications using UDP-Lite therefore 596 can not make assumptions regarding the correctness of the data 597 received in the insensitive part of the UDP-Lite payload. 599 As for UDP, mechanisms for receiver flow control, congestion control, 600 PMTU or PLPMTU discovery, support for ECN, etc need to be provided by 601 upper layer protocols [RFC5405]. 603 Examples of use include a class of applications that can derive 604 benefit from having partially-damaged payloads delivered, rather than 605 discarded. One use is to support error tolerate payload corruption 606 when used over paths that include error-prone links, another 607 application is when header integrity checks are required, but payload 608 integrity is provided by some other mechanism (e.g. [RFC6936]. 610 A UDP-Lite service may support IPv4 broadcast, multicast, anycast and 611 unicast. 613 3.5.2. Interface Description 615 There is no current API specified in the RFC Series, but guidance on 616 use of common APIs is provided in [RFC5405]. 618 The interface of UDP-Lite differs from that of UDP by the addition of 619 a single (socket) option that communicates a checksum coverage length 620 value: at the sender, this specifies the intended checksum coverage, 621 with the remaining unprotected part of the payload called the "error- 622 insensitive part". The checksum coverage may also be made visible to 623 the application via the UDP-Lite MIB module [RFC5097]. 625 3.5.3. Transport Protocol Components 627 The transport protocol components provided by UDP-Lite are: 629 o unicast 631 o IPv4 broadcast, multicast and anycast 633 o port multiplexing 635 o non-reliable, non-ordered delivery 637 o message-oriented delivery 639 o partial integrity protection 641 3.6. Datagram Congestion Control Protocol (DCCP) 643 Datagram Congestion Control Protocol (DCCP) [RFC4340] is an IETF 644 standards track bidirectional transport protocol that provides 645 unicast connections of congestion-controlled unreliable messages. 647 [EDITOR'S NOTE: Gorry Fairhurst signed up as a contributor for this 648 section.] 650 The DCCP Problem Statement describes the goals that DCCP sought to 651 address [RFC4336]. It is suitable for applications that transfer 652 fairly large amounts of data and that can benefit from control over 653 the trade off between timeliness and reliability [RFC4336]. 655 It offers low overhead, and many characteristics common to UDP, but 656 can avoid "Re-inventing the wheel" each time a new multimedia 657 application emerges. Specifically it includes core functions 658 (feature negotiation, path state management, RTT calculation, PMTUD, 659 etc): This allows applications to use a compatible method defining 660 how they send packets and where suitable to choose common algorithms 661 to manage their functions. Examples of suitable applications include 662 interactive applications, streaming media or on-line games [RFC4336]. 664 3.6.1. Protocol Description 666 DCCP is a connection-oriented datagram protocol, providing a three 667 way handshake to allow a client and server to set up a connection, 668 and mechanisms for orderly completion and immediate teardown of a 669 connection. The protocol is defined by a family of RFCs. 671 It provides multiplexing to multiple sockets on each host using port 672 numbers. An active DCCP session is identified by its four-tuple of 673 local and remote IP addresses and local port and remote port numbers. 674 At connection setup, DCCP also exchanges the the service code 675 [RFC5595] mechanism to allow transport instantiations to indicate the 676 service treatment that is expected from the network. 678 The protocol segments data into messages, typically sized to fit in 679 IP packets, but which may be fragmented providing they are less than 680 the A DCCP interface MAY allow applications to request fragmentation 681 for packets larger than PMTU, but not larger than the maximum packet 682 size allowed by the current congestion control mechanism (CCMPS) 683 [RFC4340]. 685 Each message is identified by a sequence number. The sequence number 686 is used to identify segments in acknowledgments, to detect 687 unacknowledged segments, to measure RTT, etc. The protocol may 688 support ordered or unordered delivery of data, and does not itself 689 provide retransmission. There is a Data Checksum option, which 690 contains a strong CRC, lets endpoints detect application data 691 corruption. It also supports reduced checksum coverage, a partial 692 integrity mechanisms similar to UDP-lIte. 694 Receiver flow control is supported: limiting the amount of 695 unacknowledged data that can be outstanding at a given time. 697 A DCCP protocol instance can be extended [RFC4340] and tuned. Some 698 features are sender-side only, requiring no negotiation with the 699 receiver; some are receiver-side only, some are explicitly negotiated 700 during connection setup. 702 DCCP supports negotiation of the congestion control profile, to 703 provide Plug and Play congestion control mechanisms. examples of 704 specified profiles include [RFC4341] [RFC4342] [RFC5662]. All IETF- 705 defined methods provide Congestion Control. 707 DCCP use a Connect packet to start a session, and permits half- 708 connections that allow each client to choose features it wishes to 709 support. Simultaneous open [RFC5596], as in TCP, can enable 710 interoperability in the presence of middleboxes. The Connect packet 711 includes a Service Code field [RFC5595] designed to allow middle 712 boxes and endpoints to identify the characteristics required by a 713 session. A lightweight UDP-based encapsulation (DCCP-UDP) has been 714 defined [RFC6773] that permits DCCP to be used over paths where it is 715 not natively supported. Support in NAPT/NATs is defined in [RFC4340] 716 and [RFC5595]. 718 Upper layer protocols specified on top of DCCP include: DTLS 719 [RFC5595], RTP [RFC5672], ICE/SDP [RFC6773]. 721 A DCCP service is unicast. 723 A common packet format has allowed tools to evolve that can read and 724 interpret DCCP packets (e.g. Wireshark). 726 3.6.2. Interface Description 728 API characteristics include: - Datagram transmission. - Notification 729 of the current maximum packet size. - Send and reception of zero- 730 length payloads. - Set the Slow Receiver flow control at a receiver. 731 - Detect a Slow receiver at the sender. 733 There is no current API specified in the RFC Series. 735 3.6.3. Transport Protocol Components 737 The transport protocol components provided by DCCP are: 739 o unicast 741 o connection setup with feature negotiation and application-to-port 742 mapping 744 o Service Codes 746 o port multiplexing 748 o non-reliable, ordered delivery 750 o flow control (slow receiver function) 752 o drop notification 754 o timestamps 756 o message-oriented delivery 757 o partial integrity protection 759 3.7. Realtime Transport Protocol (RTP) 761 RTP provides an end-to-end network transport service, suitable for 762 applications transmitting real-time data, such as audio, video or 763 data, over multicast or unicast network services, including TCP, UDP, 764 UDP-Lite, DCCP. 766 [EDITOR'S NOTE: Varun Singh signed up as contributor for this 767 section.] 769 3.8. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a 771 pseudo transport 773 [NOTE: A few words on TLS [RFC5246] and DTLS [RFC6347] here, and how 774 they get used by other protocols to meet security goals as an add-on 775 interlayer above transport.] 777 3.8.1. Protocol Description 779 3.8.2. Interface Description 781 3.8.3. Transport Protocol Components 783 3.9. Hypertext Transport Protocol (HTTP) as a pseudotransport 785 [RFC3205] 787 [EDITOR'S NOTE: No identified contributor for this section yet.] 789 3.9.1. Protocol Description 791 3.9.2. Interface Description 793 3.9.3. Transport Protocol Components 795 3.10. WebSockets 797 [RFC6455] 799 [EDITOR'S NOTE: No identified contributor for this section yet.] 801 3.10.1. Protocol Description 803 3.10.2. Interface Description 805 3.10.3. Transport Protocol Components 807 4. Transport Service Features 809 [EDITOR'S NOTE: this section will drawn from the candidate features 810 provided by protocol components in the previous section - please 811 discuss on taps@ietf.org list] 813 4.1. Complete Protocol Feature Matrix 815 [EDITOR'S NOTE: Dave Thaler has signed up as a contributor for this 816 section. Michael Welzl also has a beginning of a matrix which could 817 be useful here.] 819 [EDITOR'S NOTE: The below is a strawman proposal below by Gorry 820 Fairhurst for initial discussion] 822 The table below summarises protocol mechanisms that have been 823 standardised. It does not make an assessment on whether specific 824 implementations are fully compliant to these specifications. 826 +-----------------+---------+---------+---------+---------+---------+ 827 | Mechanism | UDP | UDP-L | DCCP | SCTP | TCP | 828 +-----------------+---------+---------+---------+---------+---------+ 829 | Unicast | Yes | Yes | Yes | Yes | Yes | 830 | | | | | | | 831 | Mcast/IPv4Bcast | Yes(2) | Yes | No | No | No | 832 | | | | | | | 833 | Port Mux | Yes | Yes | Yes | Yes | Yes | 834 | | | | | | | 835 | Mode | Dgram | Dgram | Dgram | Dgram | Stream | 836 | | | | | | | 837 | Connected | No | No | Yes | Yes | Yes | 838 | | | | | | | 839 | Data bundling | No | No | No | Yes | Yes | 840 | | | | | | | 841 | Feature Nego | No | No | Yes | Yes | Yes | 842 | | | | | | | 843 | Options | No | No | Support | Support | Support | 844 | | | | | | | 845 | Data priority | * | * | * | Yes | No | 846 | | | | | | | 847 | Data bundling | No | No | No | Yes | Yes | 848 | | | | | | | 849 | Reliability | None | None | None | Select | Full | 850 | | | | | | | 851 | Ordered deliv | No | No | No | Stream | Yes | 852 | | | | | | | 853 | Corruption Tol. | No | Support | Support | No | No | 854 | | | | | | | 855 | Flow Control | No | No | Support | Yes | Yes | 856 | | | | | | | 857 | PMTU/PLPMTU | (1) | (1) | Yes | Yes | Yes | 858 | | | | | | | 859 | Cong Control | (1) | (1) | Yes | Yes | Yes | 860 | | | | | | | 861 | ECN Support | (1) | (1) | Yes | TBD | Yes | 862 | | | | | | | 863 | NAT support | Limited | Limited | Support | TBD | Support | 864 | | | | | | | 865 | Security | DTLS | DTLS | DTLS | DTLS | TLS, AO | 866 | | | | | | | 867 | UDP encaps | N/A | None | Yes | Yes | None | 868 | | | | | | | 869 | RTP support | Support | Support | Support | ? | Support | 870 +-----------------+---------+---------+---------+---------+---------+ 872 Note (1): this feature requires support in an upper layer protocol. 874 Note (2): this feature requires support in an upper layer protocol 875 when used with IPv6. 877 5. IANA Considerations 879 This document has no considerations for IANA. 881 6. Security Considerations 883 This document surveys existing transport protocols and protocols 884 providing transport-like services. Confidentiality, integrity, and 885 authenticity are among the features provided by those services. This 886 document does not specify any new components or mechanisms for 887 providing these features. Each RFC listed in this document discusses 888 the security considerations of the specification it contains. 890 7. Contributors 892 [Editor's Note: turn this into a real contributors section with 893 addresses once we figure out how to trick the toolchain into doing 894 so] 896 o Section 3.4 on UDP was contributed by Kevin Fall (kfall@kfall.com) 898 o Section 3.3 on SCTP was contributed by Michael Tuexen (tuexen@fh- 899 muenster.de) 901 8. Acknowledgments 903 This work is partially supported by the European Commission under 904 grant agreement FP7-ICT-318627 mPlane; support does not imply 905 endorsement. 907 9. References 909 9.1. Normative References 911 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 912 1981. 914 9.2. Informative References 916 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 917 August 1980. 919 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 920 793, September 1981. 922 [RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", 923 RFC 896, January 1984. 925 [RFC1122] Braden, R., "Requirements for Internet Hosts - 926 Communication Layers", STD 3, RFC 1122, October 1989. 928 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 929 November 1990. 931 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 932 for IP version 6", RFC 1981, August 1996. 934 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 935 Selective Acknowledgment Options", RFC 2018, October 1996. 937 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 938 (IPv6) Specification", RFC 2460, December 1998. 940 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 941 of Explicit Congestion Notification (ECN) to IP", RFC 942 3168, September 2001. 944 [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, 945 RFC 3205, February 2002. 947 [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's 948 Initial Window", RFC 3390, October 2002. 950 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 951 Layer Security over Stream Control Transmission Protocol", 952 RFC 3436, December 2002. 954 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 955 Conrad, "Stream Control Transmission Protocol (SCTP) 956 Partial Reliability Extension", RFC 3758, May 2004. 958 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 959 G. Fairhurst, "The Lightweight User Datagram Protocol 960 (UDP-Lite)", RFC 3828, July 2004. 962 [RFC4336] Floyd, S., Handley, M., and E. Kohler, "Problem Statement 963 for the Datagram Congestion Control Protocol (DCCP)", RFC 964 4336, March 2006. 966 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 967 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 969 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 970 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 971 Congestion Control", RFC 4341, March 2006. 973 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 974 Datagram Congestion Control Protocol (DCCP) Congestion 975 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 976 March 2006. 978 [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap 979 for Transmission Control Protocol (TCP) Specification 980 Documents", RFC 4614, September 2006. 982 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 983 Parameter for the Stream Control Transmission Protocol 984 (SCTP)", RFC 4820, March 2007. 986 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 987 Discovery", RFC 4821, March 2007. 989 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 990 "Authenticated Chunks for the Stream Control Transmission 991 Protocol (SCTP)", RFC 4895, August 2007. 993 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 994 4960, September 2007. 996 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 997 Kozuka, "Stream Control Transmission Protocol (SCTP) 998 Dynamic Address Reconfiguration", RFC 5061, September 999 2007. 1001 [RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite 1002 protocol", RFC 5097, January 2008. 1004 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1005 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1007 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 1008 Friendly Rate Control (TFRC): Protocol Specification", RFC 1009 5348, September 2008. 1011 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1012 for Application Designers", BCP 145, RFC 5405, November 1013 2008. 1015 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 1016 (DCCP) Service Codes", RFC 5595, September 2009. 1018 [RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol 1019 (DCCP) Simultaneous-Open Technique to Facilitate NAT/ 1020 Middlebox Traversal", RFC 5596, September 2009. 1022 [RFC5662] Shepler, S., Eisler, M., and D. Noveck, "Network File 1023 System (NFS) Version 4 Minor Version 1 External Data 1024 Representation Standard (XDR) Description", RFC 5662, 1025 January 2010. 1027 [RFC5672] Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM) 1028 Signatures -- Update", RFC 5672, August 2009. 1030 [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A 1031 Datagram Congestion Control Protocol UDP Encapsulation for 1032 NAT Traversal", RFC 6773, November 2012. 1034 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1035 Authentication Option", RFC 5925, June 2010. 1037 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 1038 Control", RFC 5681, September 2009. 1040 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 1041 Transport Layer Security (DTLS) for Stream Control 1042 Transmission Protocol (SCTP)", RFC 6083, January 2011. 1044 [RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the 1045 TCP Urgent Mechanism", RFC 6093, January 2011. 1047 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 1048 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 1049 6525, February 2012. 1051 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 1052 "Computing TCP's Retransmission Timer", RFC 6298, June 1053 2011. 1055 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 1056 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 1058 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1059 for the Use of IPv6 UDP Datagrams with Zero Checksums", 1060 RFC 6936, April 2013. 1062 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 1063 6455, December 2011. 1065 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1066 Security Version 1.2", RFC 6347, January 2012. 1068 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 1069 Yasevich, "Sockets API Extensions for the Stream Control 1070 Transmission Protocol (SCTP)", RFC 6458, December 2011. 1072 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 1073 RFC 6691, July 2012. 1075 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1076 "TCP Extensions for Multipath Operation with Multiple 1077 Addresses", RFC 6824, January 2013. 1079 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 1080 Control Transmission Protocol (SCTP) Packets for End-Host 1081 to End-Host Communication", RFC 6951, May 2013. 1083 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 1084 IMMEDIATELY Extension for the Stream Control Transmission 1085 Protocol", RFC 7053, November 2013. 1087 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 1088 Scheffenegger, "TCP Extensions for High Performance", RFC 1089 7323, September 2014. 1091 [I-D.ietf-aqm-ecn-benefits] 1092 Welzl, M. and G. Fairhurst, "The Benefits and Pitfalls of 1093 using Explicit Congestion Notification (ECN)", draft-ietf- 1094 aqm-ecn-benefits-00 (work in progress), October 2014. 1096 [I-D.ietf-tsvwg-sctp-dtls-encaps] 1097 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 1098 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 1099 dtls-encaps-09 (work in progress), January 2015. 1101 [I-D.ietf-tsvwg-sctp-prpolicies] 1102 Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, 1103 "Additional Policies for the Partial Reliability Extension 1104 of the Stream Control Transmission Protocol", draft-ietf- 1105 tsvwg-sctp-prpolicies-07 (work in progress), February 1106 2015. 1108 [I-D.ietf-tsvwg-sctp-ndata] 1109 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 1110 "Stream Schedulers and a New Data Chunk for the Stream 1111 Control Transmission Protocol", draft-ietf-tsvwg-sctp- 1112 ndata-02 (work in progress), January 2015. 1114 Authors' Addresses 1116 Godred Fairhurst (editor) 1117 University of Aberdeen 1118 School of Engineering, Fraser Noble Building 1119 Aberdeen AB24 3UE 1121 Email: gorry@erg.abdn.ac.uk 1123 Brian Trammell (editor) 1124 ETH Zurich 1125 Gloriastrasse 35 1126 8092 Zurich 1127 Switzerland 1129 Email: ietf@trammell.ch 1131 Mirja Kuehlewind (editor) 1132 ETH Zurich 1133 Gloriastrasse 35 1134 8092 Zurich 1135 Switzerland 1137 Email: mirja.kuehlewind@tik.ee.ethz.ch