idnits 2.17.1 draft-ietf-taps-minset-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 27, 2018) is 2030 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SUBCATEGORY' is mentioned on line 1124, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-taps-transport-security-02 == Outdated reference: A later version (-26) exists of draft-ietf-taps-interface-01 -- Unexpected draft version: The latest known version of draft-tsvwg-le-phb is -00, but you're referring to -03. Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TAPS M. Welzl 3 Internet-Draft S. Gjessing 4 Intended status: Informational University of Oslo 5 Expires: March 31, 2019 September 27, 2018 7 A Minimal Set of Transport Services for End Systems 8 draft-ietf-taps-minset-11 10 Abstract 12 This draft recommends a minimal set of Transport Services offered by 13 end systems, and gives guidance on choosing among the available 14 mechanisms and protocols. It is based on the set of transport 15 features in RFC 8303. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 31, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Deriving the minimal set . . . . . . . . . . . . . . . . . . 5 54 4. The Reduced Set of Transport Features . . . . . . . . . . . . 6 55 4.1. CONNECTION Related Transport Features . . . . . . . . . . 7 56 4.2. DATA Transfer Related Transport Features . . . . . . . . 8 57 4.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 8 58 4.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 9 59 4.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . 9 60 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 5.1. Sending Messages, Receiving Bytes . . . . . . . . . . . . 10 62 5.2. Stream Schedulers Without Streams . . . . . . . . . . . . 11 63 5.3. Early Data Transmission . . . . . . . . . . . . . . . . . 11 64 5.4. Sender Running Dry . . . . . . . . . . . . . . . . . . . 12 65 5.5. Capacity Profile . . . . . . . . . . . . . . . . . . . . 13 66 5.6. Security . . . . . . . . . . . . . . . . . . . . . . . . 13 67 5.7. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 14 68 6. The Minimal Set of Transport Features . . . . . . . . . . . . 14 69 6.1. ESTABLISHMENT, AVAILABILITY and TERMINATION . . . . . . . 14 70 6.2. MAINTENANCE . . . . . . . . . . . . . . . . . . . . . . . 18 71 6.2.1. Connection groups . . . . . . . . . . . . . . . . . . 18 72 6.2.2. Individual connections . . . . . . . . . . . . . . . 20 73 6.3. DATA Transfer . . . . . . . . . . . . . . . . . . . . . . 20 74 6.3.1. Sending Data . . . . . . . . . . . . . . . . . . . . 20 75 6.3.2. Receiving Data . . . . . . . . . . . . . . . . . . . 21 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 81 10.2. Informative References . . . . . . . . . . . . . . . . . 23 82 Appendix A. The Superset of Transport Features . . . . . . . . . 25 83 A.1. CONNECTION Related Transport Features . . . . . . . . . . 26 84 A.2. DATA Transfer Related Transport Features . . . . . . . . 42 85 A.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 42 86 A.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 46 87 A.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . 47 88 Appendix B. Revision information . . . . . . . . . . . . . . . . 48 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 91 1. Introduction 93 Currently, the set of transport services that most applications use 94 is based on TCP and UDP (and protocols that are layered on top of 95 them); this limits the ability for the network stack to make use of 96 features of other transport protocols. For example, if a protocol 97 supports out-of-order message delivery but applications always assume 98 that the network provides an ordered bytestream, then the network 99 stack can not immediately deliver a message that arrives out-of- 100 order: doing so would break a fundamental assumption of the 101 application. The net result is unnecessary head-of-line blocking 102 delay. 104 By exposing the transport services of multiple transport protocols, a 105 transport system can make it possible for applications to use these 106 services without being statically bound to a specific transport 107 protocol. The first step towards the design of such a system was 108 taken by [RFC8095], which surveys a large number of transports, and 109 [RFC8303] as well as [RFC8304], which identify the specific transport 110 features that are exposed to applications by the protocols TCP, 111 MPTCP, UDP(-Lite) and SCTP as well as the LEDBAT congestion control 112 mechanism. LEDBAT was included as the only congestion control 113 mechanism in this list because the "low extra delay background 114 transport" service that it offers is significantly different from the 115 typical service provided by other congestion control mechanisms. 116 This memo is based on these documents and follows the same 117 terminology (also listed below). Because the considered transport 118 protocols conjointly cover a wide range of transport features, there 119 is reason to hope that the resulting set (and the reasoning that led 120 to it) will also apply to many aspects of other transport protocols 121 that may be in use today, or may be designed in the future. 123 By decoupling applications from transport protocols, a transport 124 system provides a different abstraction level than the Berkeley 125 sockets interface [POSIX]. As with high- vs. low-level programming 126 languages, a higher abstraction level allows more freedom for 127 automation below the interface, yet it takes some control away from 128 the application programmer. This is the design trade-off that a 129 transport system developer is facing, and this document provides 130 guidance on the design of this abstraction level. Some transport 131 features are currently rarely offered by APIs, yet they must be 132 offered or they can never be used. Other transport features are 133 offered by the APIs of the protocols covered here, but not exposing 134 them in an API would allow for more freedom to automate protocol 135 usage in a transport system. The minimal set presented here is an 136 effort to find a middle ground that can be recommended for transport 137 systems to implement, on the basis of the transport features 138 discussed in [RFC8303]. 140 Applications use a wide variety of APIs today. While this document 141 was created to ensure the API developed in the Transport Services 142 (TAPS) Working Group ([I-D.ietf-taps-interface]) includes the most 143 important transport features, the minimal set presented here must be 144 reflected in *all* network APIs in order for the underlying 145 functionality to become usable everywhere. For example, it does not 146 help an application that talks to a library which offers its own 147 communication interface if the underlying Berkeley Sockets API is 148 extended to offer "unordered message delivery", but the library only 149 exposes an ordered bytestream. Both the Berkeley Sockets API and the 150 library would have to expose the "unordered message delivery" 151 transport feature (alternatively, there may be ways for certain types 152 of libraries to use this transport feature without exposing it, based 153 on knowledge about the applications -- but this is not the general 154 case). Similarly, transport protocols such as SCTP offer multi- 155 streaming, which cannot be utilized, e.g., to prioritize messages 156 between streams, unless applications communicate the priorities and 157 the group of connections upon which these priorities should be 158 applied. In most situations, in the interest of being as flexible 159 and efficient as possible, the best choice will be for a library to 160 expose at least all of the transport features that are recommended as 161 a "minimal set" here. 163 This "minimal set" can be implemented "one-sided" over TCP. This 164 means that a sender-side transport system can talk to a standard TCP 165 receiver, and a receiver-side transport system can talk to a standard 166 TCP sender. If certain limitations are put in place, the "minimal 167 set" can also be implemented "one-sided" over UDP. While the 168 possibility of such "one-sided" implementation may help deployment, 169 it comes at the cost of limiting the set to services that can also be 170 provided by TCP (or, with further limitations, UDP). Thus, the 171 minimal set of transport features here is applicable for many, but 172 not all, applications: some application protocols have requirements 173 that are not met by this "minimal set". 175 Note that, throughout this document, protocols are meant to be used 176 natively. For example, when transport features of UDP, or 177 "implementation over" UDP is discussed, this refers to native usage 178 of UDP. 180 2. Terminology 182 Transport Feature: a specific end-to-end feature that the transport 183 layer provides to an application. Examples include 184 confidentiality, reliable delivery, ordered delivery, message- 185 versus-stream orientation, etc. 186 Transport Service: a set of Transport Features, without an 187 association to any given framing protocol, which provides a 188 complete service to an application. 189 Transport Protocol: an implementation that provides one or more 190 different transport services using a specific framing and header 191 format on the wire. 193 Application: an entity that uses a transport layer interface for 194 end-to-end delivery of data across the network (this may also be 195 an upper layer protocol or tunnel encapsulation). 196 Application-specific knowledge: knowledge that only applications 197 have. 198 End system: an entity that communicates with one or more other end 199 systems using a transport protocol. An end system provides a 200 transport layer interface to applications. 201 Connection: shared state of two or more end systems that persists 202 across messages that are transmitted between these end systems. 203 Connection Group: a set of connections which share the same 204 configuration (configuring one of them causes all other 205 connections in the same group to be configured in the same way). 206 We call connections that belong to a connection group "grouped", 207 while "ungrouped" connections are not a part of a connection 208 group. 209 Socket: the combination of a destination IP address and a 210 destination port number. 212 Moreover, throughout the document, the protocol name "UDP(-Lite)" is 213 used when discussing transport features that are equivalent for UDP 214 and UDP-Lite; similarly, the protocol name "TCP" refers to both TCP 215 and MPTCP. 217 3. Deriving the minimal set 219 We assume that applications have no specific requirements that need 220 knowledge about the network, e.g. regarding the choice of network 221 interface or the end-to-end path. Even with these assumptions, there 222 are certain requirements that are strictly kept by transport 223 protocols today, and these must also be kept by a transport system. 224 Some of these requirements relate to transport features that we call 225 "Functional". 227 Functional transport features provide functionality that cannot be 228 used without the application knowing about them, or else they violate 229 assumptions that might cause the application to fail. For example, 230 ordered message delivery is a functional transport feature: it cannot 231 be configured without the application knowing about it because the 232 application's assumption could be that messages always arrive in 233 order. Failure includes any change of the application behavior that 234 is not performance oriented, e.g. security. 236 "Change DSCP" and "Disable Nagle algorithm" are examples of transport 237 features that we call "Optimizing": if a transport system 238 autonomously decides to enable or disable them, an application will 239 not fail, but a transport system may be able to communicate more 240 efficiently if the application is in control of this optimizing 241 transport feature. These transport features require application- 242 specific knowledge (e.g., about delay/bandwidth requirements or the 243 length of future data blocks that are to be transmitted). 245 The transport features of IETF transport protocols that do not 246 require application-specific knowledge and could therefore be 247 utilized by a transport system on its own without involving the 248 application are called "Automatable". 250 We approach the construction of a minimal set of transport features 251 in the following way: 253 1. Categorization (Appendix A): the superset of transport features 254 from [RFC8303] is presented, and transport features are 255 categorized as Functional, Optimizing or Automatable for later 256 reduction. 257 2. Reduction (Section 4): a shorter list of transport features is 258 derived from the categorization in the first step. This removes 259 all transport features that do not require application-specific 260 knowledge or would result in semantically incorrect behavior if 261 they were implemented over TCP or UDP. 262 3. Discussion (Section 5): the resulting list shows a number of 263 peculiarities that are discussed, to provide a basis for 264 constructing the minimal set. 265 4. Construction (Section 6): Based on the reduced set and the 266 discussion of the transport features therein, a minimal set is 267 constructed. 269 Following [RFC8303] and retaining its terminology, we divide the 270 transport features into two main groups as follows: 272 1. CONNECTION related transport features 273 - ESTABLISHMENT 274 - AVAILABILITY 275 - MAINTENANCE 276 - TERMINATION 278 2. DATA Transfer related transport features 279 - Sending Data 280 - Receiving Data 281 - Errors 283 4. The Reduced Set of Transport Features 285 By hiding automatable transport features from the application, a 286 transport system can gain opportunities to automate the usage of 287 network-related functionality. This can facilitate using the 288 transport system for the application programmer and it allows for 289 optimizations that may not be possible for an application. For 290 instance, system-wide configurations regarding the usage of multiple 291 interfaces can better be exploited if the choice of the interface is 292 not entirely up to the application. Therefore, since they are not 293 strictly necessary to expose in a transport system, we do not include 294 automatable transport features in the reduced set of transport 295 features. This leaves us with only the transport features that are 296 either optimizing or functional. 298 A transport system should be able to communicate via TCP or UDP if 299 alternative transport protocols are found not to work. For many 300 transport features, this is possible -- often by simply not doing 301 anything when a specific request is made. For some transport 302 features, however, it was identified that direct usage of neither TCP 303 nor UDP is possible: in these cases, even not doing anything would 304 incur semantically incorrect behavior. Whenever an application would 305 make use of one of these transport features, this would eliminate the 306 possibility to use TCP or UDP. Thus, we only keep the functional and 307 optimizing transport features for which an implementation over either 308 TCP or UDP is possible in our reduced set. 310 The following list contains the transport features from Appendix A, 311 reduced using these rules. The "minimal set" derived in this 312 document is meant to be implementable "one-sided" over TCP, and, with 313 limitations, UDP. In the list, we therefore precede a transport 314 feature with "T:" if an implementation over TCP is possible, "U:" if 315 an implementation over UDP is possible, and "T,U:" if an 316 implementation over either TCP or UDP is possible. 318 4.1. CONNECTION Related Transport Features 320 ESTABLISHMENT: 322 o T,U: Connect 323 o T,U: Specify number of attempts and/or timeout for the first 324 establishment message 325 o T,U: Disable MPTCP 326 o T: Configure authentication 327 o T: Hand over a message to reliably transfer (possibly multiple 328 times) before connection establishment 329 o T: Hand over a message to reliably transfer during connection 330 establishment 332 AVAILABILITY: 334 o T,U: Listen 335 o T,U: Disable MPTCP 336 o T: Configure authentication 338 MAINTENANCE: 340 o T: Change timeout for aborting connection (using retransmit limit 341 or time value) 342 o T: Suggest timeout to the peer 343 o T,U: Disable Nagle algorithm 344 o T,U: Notification of Excessive Retransmissions (early warning 345 below abortion threshold) 346 o T,U: Specify DSCP field 347 o T,U: Notification of ICMP error message arrival 348 o T: Change authentication parameters 349 o T: Obtain authentication information 350 o T,U: Set Cookie life value 351 o T,U: Choose a scheduler to operate between streams of an 352 association 353 o T,U: Configure priority or weight for a scheduler 354 o T,U: Disable checksum when sending 355 o T,U: Disable checksum requirement when receiving 356 o T,U: Specify checksum coverage used by the sender 357 o T,U: Specify minimum checksum coverage required by receiver 358 o T,U: Specify DF field 359 o T,U: Get max. transport-message size that may be sent using a non- 360 fragmented IP packet from the configured interface 361 o T,U: Get max. transport-message size that may be received from the 362 configured interface 363 o T,U: Obtain ECN field 364 o T,U: Enable and configure a "Low Extra Delay Background Transfer" 366 TERMINATION: 368 o T: Close after reliably delivering all remaining data, causing an 369 event informing the application on the other side 370 o T: Abort without delivering remaining data, causing an event 371 informing the application on the other side 372 o T,U: Abort without delivering remaining data, not causing an event 373 informing the application on the other side 374 o T,U: Timeout event when data could not be delivered for too long 376 4.2. DATA Transfer Related Transport Features 378 4.2.1. Sending Data 380 o T: Reliably transfer data, with congestion control 381 o T: Reliably transfer a message, with congestion control 382 o T,U: Unreliably transfer a message 383 o T: Configurable Message Reliability 384 o T: Ordered message delivery (potentially slower than unordered) 385 o T,U: Unordered message delivery (potentially faster than ordered) 386 o T,U: Request not to bundle messages 387 o T: Specifying a key id to be used to authenticate a message 388 o T,U: Request not to delay the acknowledgement (SACK) of a message 390 4.2.2. Receiving Data 392 o T,U: Receive data (with no message delimiting) 393 o U: Receive a message 394 o T,U: Information about partial message arrival 396 4.2.3. Errors 398 This section describes sending failures that are associated with a 399 specific call to in the "Sending Data" category (Appendix A.2.1). 401 o T,U: Notification of send failures 402 o T,U: Notification that the stack has no more user data to send 403 o T,U: Notification to a receiver that a partial message delivery 404 has been aborted 406 5. Discussion 408 The reduced set in the previous section exhibits a number of 409 peculiarities, which we will discuss in the following. This section 410 focuses on TCP because, with the exception of one particular 411 transport feature ("Receive a message" -- we will discuss this in 412 Section 5.1), the list shows that UDP is strictly a subset of TCP. 413 We can first try to understand how to build a transport system that 414 can run over TCP, and then narrow down the result further to allow 415 that the system can always run over either TCP or UDP (which 416 effectively means removing everything related to reliability, 417 ordering, authentication and closing/aborting with a notification to 418 the peer). 420 Note that, because the functional transport features of UDP are -- 421 with the exception of "Receive a message" -- a subset of TCP, TCP can 422 be used as a replacement for UDP whenever an application does not 423 need message delimiting (e.g., because the application-layer protocol 424 already does it). This has been recognized by many applications that 425 already do this in practice, by trying to communicate with UDP at 426 first, and falling back to TCP in case of a connection failure. 428 5.1. Sending Messages, Receiving Bytes 430 For implementing a transport system over TCP, there are several 431 transport features related to sending, but only a single transport 432 feature related to receiving: "Receive data (with no message 433 delimiting)" (and, strangely, "information about partial message 434 arrival"). Notably, the transport feature "Receive a message" is 435 also the only non-automatable transport feature of UDP(-Lite) for 436 which no implementation over TCP is possible. 438 To support these TCP receiver semantics, we define an "Application- 439 Framed Bytestream" (AFra-Bytestream). AFra-Bytestreams allow senders 440 to operate on messages while minimizing changes to the TCP socket 441 API. In particular, nothing changes on the receiver side - data can 442 be accepted via a normal TCP socket. 444 In an AFra-Bytestream, the sending application can optionally inform 445 the transport about message boundaries and required properties per 446 message (configurable order and reliability, or embedding a request 447 not to delay the acknowledgement of a message). Whenever the sending 448 application specifies per-message properties that relax the notion of 449 reliable in-order delivery of bytes, it must assume that the 450 receiving application is 1) able to determine message boundaries, 451 provided that messages are always kept intact, and 2) able to accept 452 these relaxed per-message properties. Any signaling of such 453 information to the peer is up to an application-layer protocol and 454 considered out of scope of this document. 456 For example, if an application requests to transfer fixed-size 457 messages of 100 bytes with partial reliability, this needs the 458 receiving application to be prepared to accept data in chunks of 100 459 bytes. If, then, some of these 100-byte messages are missing (e.g., 460 if SCTP with Configurable Reliability is used), this is the expected 461 application behavior. With TCP, no messages would be missing, but 462 this is also correct for the application, and the possible 463 retransmission delay is acceptable within the best-effort service 464 model (see [RFC7305], Section 3.5). Still, the receiving application 465 would separate the byte stream into 100-byte chunks. 467 Note that this usage of messages does not require all messages to be 468 equal in size. Many application protocols use some form of Type- 469 Length-Value (TLV) encoding, e.g. by defining a header including 470 length fields; another alternative is the use of byte stuffing 471 methods such as COBS [COBS]. If an application needs message 472 numbers, e.g. to restore the correct sequence of messages, these must 473 also be encoded by the application itself, as the sequence number 474 related transport features of SCTP are not provided by the "minimum 475 set" (in the interest of enabling usage of TCP). 477 5.2. Stream Schedulers Without Streams 479 We have already stated that multi-streaming does not require 480 application-specific knowledge. Potential benefits or disadvantages 481 of, e.g., using two streams of an SCTP association versus using two 482 separate SCTP associations or TCP connections are related to 483 knowledge about the network and the particular transport protocol in 484 use, not the application. However, the transport features "Choose a 485 scheduler to operate between streams of an association" and 486 "Configure priority or weight for a scheduler" operate on streams. 487 Here, streams identify communication channels between which a 488 scheduler operates, and they can be assigned a priority. Moreover, 489 the transport features in the MAINTENANCE category all operate on 490 assocations in case of SCTP, i.e. they apply to all streams in that 491 assocation. 493 With only these semantics necessary to represent, the interface to a 494 transport system becomes easier if we assume that connections may be 495 not only a transport protocol's connection or association, but could 496 also be a stream of an existing SCTP association, for example. We 497 only need to allow for a way to define a possible grouping of 498 connections. Then, all MAINTENANCE transport features can be said to 499 operate on connection groups, not connections, and a scheduler 500 operates on the connections within a group. 502 To be compatible with multiple transport protocols and uniformly 503 allow access to both transport connections and streams of a multi- 504 streaming protocol, the semantics of opening and closing need to be 505 the most restrictive subset of all of the underlying options. For 506 example, TCP's support of half-closed connections can be seen as a 507 feature on top of the more restrictive "ABORT"; this feature cannot 508 be supported because not all protocols used by a transport system 509 (including streams of an association) support half-closed 510 connections. 512 5.3. Early Data Transmission 514 There are two transport features related to transferring a message 515 early: "Hand over a message to reliably transfer (possibly multiple 516 times) before connection establishment", which relates to TCP Fast 517 Open [RFC7413], and "Hand over a message to reliably transfer during 518 connection establishment", which relates to SCTP's ability to 519 transfer data together with the COOKIE-Echo chunk. Also without TCP 520 Fast Open, TCP can transfer data during the handshake, together with 521 the SYN packet -- however, the receiver of this data may not hand it 522 over to the application until the handshake has completed. Also, 523 different from TCP Fast Open, this data is not delimited as a message 524 by TCP (thus, not visible as a ``message''). This functionality is 525 commonly available in TCP and supported in several implementations, 526 even though the TCP specification does not explain how to provide it 527 to applications. 529 A transport system could differentiate between the cases of 530 transmitting data "before" (possibly multiple times) or "during" the 531 handshake. Alternatively, it could also assume that data that are 532 handed over early will be transmitted as early as possible, and 533 "before" the handshake would only be used for messages that are 534 explicitly marked as "idempotent" (i.e., it would be acceptable to 535 transfer them multiple times). 537 The amount of data that can successfully be transmitted before or 538 during the handshake depends on various factors: the transport 539 protocol, the use of header options, the choice of IPv4 and IPv6 and 540 the Path MTU. A transport system should therefore allow a sending 541 application to query the maximum amount of data it can possibly 542 transmit before (or, if exposed, during) connection establishment. 544 5.4. Sender Running Dry 546 The transport feature "Notification that the stack has no more user 547 data to send" relates to SCTP's "SENDER DRY" notification. Such 548 notifications can, in principle, be used to avoid having an 549 unnecessarily large send buffer, yet ensure that the transport sender 550 always has data available when it has an opportunity to transmit it. 551 This has been found to be very beneficial for some applications 552 [WWDC2015]. However, "SENDER DRY" truly means that the entire send 553 buffer (including both unsent and unacknowledged data) has emptied -- 554 i.e., when it notifies the sender, it is already too late, the 555 transport protocol already missed an opportunity to send data. Some 556 modern TCP implementations now include the unspecified 557 "TCP_NOTSENT_LOWAT" socket option that was proposed in [WWDC2015], 558 which limits the amount of unsent data that TCP can keep in the 559 socket buffer; this allows to specify at which buffer filling level 560 the socket becomes writable, rather than waiting for the buffer to 561 run empty. 563 SCTP allows to configure the sender-side buffer too: the automatable 564 Transport Feature "Configure send buffer size" provides this 565 functionality, but only for the complete buffer, which includes both 566 unsent and unacknowledged data. SCTP does not allow to control these 567 two sizes separately. It therefore makes sense for a transport 568 system to allow for uniform access to "TCP_NOTSENT_LOWAT" as well as 569 the "SENDER DRY" notification. 571 5.5. Capacity Profile 573 The transport features: 575 o Disable Nagle algorithm 576 o Enable and configure a "Low Extra Delay Background Transfer" 577 o Specify DSCP field 579 all relate to a QoS-like application need such as "low latency" or 580 "scavenger". In the interest of flexibility of a transport system, 581 they could therefore be offered in a uniform, more abstract way, 582 where a transport system could e.g. decide by itself how to use 583 combinations of LEDBAT-like congestion control and certain DSCP 584 values, and an application would only specify a general "capacity 585 profile" (a description of how it wants to use the available 586 capacity). A need for "lowest possible latency at the expense of 587 overhead" could then translate into automatically disabling the Nagle 588 algorithm. 590 In some cases, the Nagle algorithm is best controlled directly by the 591 application because it is not only related to a general profile but 592 also to knowledge about the size of future messages. For fine-grain 593 control over Nagle-like functionality, the "Request not to bundle 594 messages" is available. 596 5.6. Security 598 Both TCP and SCTP offer authentication. TCP authenticates complete 599 segments. SCTP allows to configure which of SCTP's chunk types must 600 always be authenticated -- if this is exposed as such, it creates an 601 undesirable dependency on the transport protocol. For compatibility 602 with TCP, a transport system should only allow to configure complete 603 transport layer packets, including headers, IP pseudo-header (if any) 604 and payload. 606 Security is discussed in a separate document 607 [I-D.ietf-taps-transport-security]. The minimal set presented in the 608 present document excludes all security related transport features 609 from Appendix A: "Configure authentication", "Change authentication 610 parameters", "Obtain authentication information" and "Set Cookie life 611 value" as well as "Specifying a key id to be used to authenticate a 612 message". It also excludes security transport features not listed in 613 Appendix A, including content privacy to in-path devices. 615 5.7. Packet Size 617 UDP(-Lite) has a transport feature called "Specify DF field". This 618 yields an error message in case of sending a message that exceeds the 619 Path MTU, which is necessary for a UDP-based application to be able 620 to implement Path MTU Discovery (a function that UDP-based 621 applications must do by themselves). The "Get max. transport-message 622 size that may be sent using a non-fragmented IP packet from the 623 configured interface" transport feature yields an upper limit for the 624 Path MTU (minus headers) and can therefore help to implement Path MTU 625 Discovery more efficiently. 627 6. The Minimal Set of Transport Features 629 Based on the categorization, reduction, and discussion in Section 3, 630 this section describes a minimal set of transport features that end 631 systems should offer. Any configuration based the described minimum 632 set of transport feature can always be realized over TCP but also 633 gives the transport system flexibility to choose another transport if 634 implemented. In the text of this section, "not UDP" is used to 635 indicate elements of the system that cannot be implemented over UDP. 636 Conversely, all elements of the system that are not marked with "not 637 UDP" can also be implemented over UDP. 639 The arguments laid out in Section 5 ("discussion") were used to make 640 the final representation of the minimal set as short, simple and 641 general as possible. There may be situations where these arguments 642 do not apply -- e.g., implementers may have specific reasons to 643 expose multi-streaming as a visible functionality to applications, or 644 the restrictive open / close semantics may be problematic under some 645 circumstances. In such cases, the representation in Section 4 646 ("reduction") should be considered. 648 As in Section 3, Section 4 and [RFC8303], we categorize the minimal 649 set of transport features as 1) CONNECTION related (ESTABLISHMENT, 650 AVAILABILITY, MAINTENANCE, TERMINATION) and 2) DATA Transfer related 651 (Sending Data, Receiving Data, Errors). Here, the focus is on 652 connections that the transport system offers as an abstraction to the 653 application, as opposed to connections of transport protocols that 654 the transport system uses. 656 6.1. ESTABLISHMENT, AVAILABILITY and TERMINATION 658 A connection must first be "created" to allow for some initial 659 configuration to be carried out before the transport system can 660 actively or passively establish communication with a remote end 661 system. As a configuration of the newly created connection, an 662 application can choose to disallow usage of MPTCP. Furthermore, all 663 configuration parameters in Section 6.2 can be used initially, 664 although some of them may only take effect when a connection has been 665 established with a chosen transport protocol. Configuring a 666 connection early helps a transport system make the right decisions. 667 For example, grouping information can influence the transport system 668 to implement a connection as a stream of a multi-streaming protocol's 669 existing association or not. 671 For ungrouped connections, early configuration is necessary because 672 it allows the transport system to know which protocols it should try 673 to use. In particular, a transport system that only makes a one-time 674 choice for a particular protocol must know early about strict 675 requirements that must be kept, or it can end up in a deadlock 676 situation (e.g., having chosen UDP and later be asked to support 677 reliable transfer). As an example description of how to correctly 678 handle these cases, we provide the following decision tree (this is 679 derived from Section 4.1 excluding authentication, as explained in 680 Section 9): 682 - Will it ever be necessary to offer any of the following? 683 * Reliably transfer data 684 * Notify the peer of closing/aborting 685 * Preserve data ordering 687 Yes: SCTP or TCP can be used. 688 - Is any of the following useful to the application? 689 * Choosing a scheduler to operate between connections 690 in a group, with the possibility to configure a priority 691 or weight per connection 692 * Configurable message reliability 693 * Unordered message delivery 694 * Request not to delay the acknowledgement (SACK) of a message 696 Yes: SCTP is preferred. 697 No: 698 - Is any of the following useful to the application? 699 * Hand over a message to reliably transfer (possibly 700 multiple times) before connection establishment 701 * Suggest timeout to the peer 702 * Notification of Excessive Retransmissions (early 703 warning below abortion threshold) 704 * Notification of ICMP error message arrival 706 Yes: TCP is preferred. 707 No: SCTP and TCP are equally preferable. 709 No: all protocols can be used. 710 - Is any of the following useful to the application? 711 * Specify checksum coverage used by the sender 712 * Specify minimum checksum coverage required by receiver 714 Yes: UDP-Lite is preferred. 715 No: UDP is preferred. 717 Note that this decision tree is not optimal for all cases. For 718 example, if an application wants to use "Specify checksum coverage 719 used by the sender", which is only offered by UDP-Lite, and 720 "Configure priority or weight for a scheduler", which is only offered 721 by SCTP, the above decision tree will always choose UDP-Lite, making 722 it impossible to use SCTP's schedulers with priorities between 723 grouped connections. Also, several other factors may influence the 724 decisions for or against a protocol -- e.g. penetration rates, the 725 ability to work through NATs, etc. We caution implementers to be 726 aware of the full set of trade-offs, for which we recommend 727 consulting the list in Section 4.1 when deciding how to initialize a 728 connection. 730 To summarize, the following parameters serve as input for the 731 transport system to help it choose and configure a suitable protocol: 733 o Reliability: a boolean that should be set to true when any of the 734 following will be useful to the application: reliably transfer 735 data; notify the peer of closing/aborting; preserve data ordering. 736 o Checksum coverage: a boolean to specify whether it will be useful 737 to the application to specify checksum coverage when sending or 738 receiving. 739 o Configure message priority: a boolean that should be set to true 740 when any of the following per-message configuration or 741 prioritization mechanisms will be useful to the application: 742 choosing a scheduler to operate between grouped connections, with 743 the possibility to configure a priority or weight per connection; 744 configurable message reliability; unordered message delivery; 745 requesting not to delay the acknowledgement (SACK) of a message. 746 o Early message timeout notifications: a boolean that should be set 747 to true when any of the following will be useful to the 748 application: hand over a message to reliably transfer (possibly 749 multiple times) before connection establishment; suggest timeout 750 to the peer; notification of excessive retransmissions (early 751 warning below abortion threshold); notification of ICMP error 752 message arrival. 754 Once a connection is created, it can be queried for the maximum 755 amount of data that an application can possibly expect to have 756 reliably transmitted before or during transport connection 757 establishment (with zero being a possible answer) (see 758 Section 6.2.1). An application can also give the connection a 759 message for reliable transmission before or during connection 760 establishment (not UDP); the transport system will then try to 761 transmit it as early as possible. An application can facilitate 762 sending a message particularly early by marking it as "idempotent" 763 (see Section 6.3.1); in this case, the receiving application must be 764 prepared to potentially receive multiple copies of the message 765 (because idempotent messages are reliably transferred, asking for 766 idempotence is not necessary for systems that support UDP). 768 After creation, a transport system can actively establish 769 communication with a peer, or it can passively listen for incoming 770 connection requests. Note that active establishment may or may not 771 trigger a notification on the listening side. It is possible that 772 the first notification on the listening side is the arrival of the 773 first data that the active side sends (a receiver-side transport 774 system could handle this by continuing to block a "Listen" call, 775 immediately followed by issuing "Receive", for example; callback- 776 based implementations could simply skip the equivalent of "Listen"). 777 This also means that the active opening side is assumed to be the 778 first side sending data. 780 A transport system can actively close a connection, i.e. terminate it 781 after reliably delivering all remaining data to the peer (if reliable 782 data delivery was requested earlier (not UDP)), in which case the 783 peer is notified that the connection is closed. Alternatively, a 784 connection can be aborted without delivering outstanding data to the 785 peer. In case reliable or partially reliable data delivery was 786 requested earlier (not UDP), the peer is notified that the connection 787 is aborted. A timeout can be configured to abort a connection when 788 data could not be delivered for too long (not UDP); however, timeout- 789 based abortion does not notify the peer application that the 790 connection has been aborted. Because half-closed connections are not 791 supported, when a host implementing a transport system receives a 792 notification that the peer is closing or aborting the connection (not 793 UDP), its peer may not be able to read outstanding data. This means 794 that unacknowledged data residing in a transport system's send buffer 795 may have to be dropped from that buffer upon arrival of a "close" or 796 "abort" notification from the peer. 798 6.2. MAINTENANCE 800 A transport system must offer means to group connections, but it 801 cannot guarantee truly grouping them using the transport protocols 802 that it uses (e.g., it cannot be guaranteed that connections become 803 multiplexed as streams on a single SCTP association when SCTP may not 804 be available). The transport system must therefore ensure that 805 group- versus non-group-configurations are handled correctly in some 806 way (e.g., by applying the configuration to all grouped connections 807 even when they are not multiplexed, or informing the application 808 about grouping success or failure). 810 As a general rule, any configuration described below should be 811 carried out as early as possible to aid the transport system's 812 decision making. 814 6.2.1. Connection groups 816 The following transport features and notifications (some directly 817 from Section 4, some new or changed, based on the discussion in 818 Section 5) automatically apply to all grouped connections: 820 (not UDP) Configure a timeout: this can be done with the following 821 parameters: 823 o A timeout value for aborting connections, in seconds 824 o A timeout value to be suggested to the peer (if possible), in 825 seconds 826 o The number of retransmissions after which the application should 827 be notifed of "Excessive Retransmissions" 829 Configure urgency: this can be done with the following parameters: 831 o A number to identify the type of scheduler that should be used to 832 operate between connections in the group (no guarantees given). 833 Schedulers are defined in [RFC8260]. 834 o A "capacity profile" number to identify how an application wants 835 to use its available capacity. Choices can be "lowest possible 836 latency at the expense of overhead" (which would disable any 837 Nagle-like algorithm), "scavenger", or values that help determine 838 the DSCP value for a connection (e.g. similar to table 1 in 839 [I-D.ietf-tsvwg-rtcweb-qos]). 840 o A buffer limit (in bytes); when the sender has less than the 841 provided limit of bytes in the buffer, the application may be 842 notified. Notifications are not guaranteed, and it is optional 843 for a transport system to support buffer limit values greater than 844 0. Note that this limit and its notification should operate 845 across the buffers of the whole transport system, i.e. also any 846 potential buffers that the transport system itself may use on top 847 of the transport's send buffer. 849 Following Section 5.7, these properties can be queried: 851 o The maximum message size that may be sent without fragmentation 852 via the configured interface. This is optional for a transport 853 system to offer, and may return an error ("not available"). It 854 can aid applications implementing Path MTU Discovery. 855 o The maximum transport message size that can be sent, in bytes. 856 Irrespective of fragmentation, there is a size limit for the 857 messages that can be handed over to SCTP or UDP(-Lite); because 858 the service provided by a transport system is independent of the 859 transport protocol, it must allow an application to query this 860 value -- the maximum size of a message in an Application-Framed- 861 Bytestream (see Section 5.1). This may also return an error when 862 data is not delimited ("not available"). 863 o The maximum transport message size that can be received from the 864 configured interface, in bytes (or "not available"). 865 o The maximum amount of data that can possibly be sent before or 866 during connection establishment, in bytes. 868 In addition to the already mentioned closing / aborting notifications 869 and possible send errors, the following notifications can occur: 871 o Excessive Retransmissions: the configured (or a default) number of 872 retransmissions has been reached, yielding this early warning 873 below an abortion threshold. 874 o ICMP Arrival (parameter: ICMP message): an ICMP packet carrying 875 the conveyed ICMP message has arrived. 876 o ECN Arrival (parameter: ECN value): a packet carrying the conveyed 877 ECN value has arrived. This can be useful for applications 878 implementing congestion control. 879 o Timeout (parameter: s seconds): data could not be delivered for s 880 seconds. 881 o Drain: the send buffer has either drained below the configured 882 buffer limit or it has become completely empty. This is a generic 883 notification that tries to enable uniform access to 884 "TCP_NOTSENT_LOWAT" as well as the "SENDER DRY" notification (as 885 discussed in Section 5.4 -- SCTP's "SENDER DRY" is a special case 886 where the threshold (for unsent data) is 0 and there is also no 887 more unacknowledged data in the send buffer). 889 6.2.2. Individual connections 891 Configure priority or weight for a scheduler, as described in 892 [RFC8260]. 894 Configure checksum usage: this can be done with the following 895 parameters, but there is no guarantee that any checksum limitations 896 will indeed be enforced (the default behavior is "full coverage, 897 checksum enabled"): 899 o A boolean to enable / disable usage of a checksum when sending 900 o The desired coverage (in bytes) of the checksum used when sending 901 o A boolean to enable / disable requiring a checksum when receiving 902 o The required minimum coverage (in bytes) of the checksum when 903 receiving 905 6.3. DATA Transfer 907 6.3.1. Sending Data 909 When sending a message, no guarantees are given about the 910 preservation of message boundaries to the peer; if message boundaries 911 are needed, the receiving application at the peer must know about 912 them beforehand (or the transport system cannot use TCP). Note that 913 an application should already be able to hand over data before the 914 transport system establishes a connection with a chosen transport 915 protocol. Regarding the message that is being handed over, the 916 following parameters can be used: 918 o Reliability: this parameter is used to convey a choice of: fully 919 reliable with congestion control (not UDP), unreliable without 920 congestion control, unreliable with congestion control (not UDP), 921 partially reliable with congestion control (see [RFC3758] and 922 [RFC7496] for details on how to specify partial reliability) (not 923 UDP). The latter two choices are optional for a transport system 924 to offer and may result in full reliability. Note that 925 applications sending unreliable data without congestion control 926 should themselves perform congestion control in accordance with 927 [RFC8085]. 928 o (not UDP) Ordered: this boolean parameter lets an application 929 choose between ordered message delivery (true) and possibly 930 unordered, potentially faster message delivery (false). 931 o Bundle: a boolean that expresses a preference for allowing to 932 bundle messages (true) or not (false). No guarantees are given. 933 o DelAck: a boolean that, if false, lets an application request that 934 the peer would not delay the acknowledgement for this message. 935 o Fragment: a boolean that expresses a preference for allowing to 936 fragment messages (true) or not (false), at the IP level. No 937 guarantees are given. 938 o (not UDP) Idempotent: a boolean that expresses whether a message 939 is idempotent (true) or not (false). Idempotent messages may 940 arrive multiple times at the receiver (but they will arrive at 941 least once). When data is idempotent it can be used by the 942 receiver immediately on a connection establishment attempt. Thus, 943 if data is handed over before the transport system establishes a 944 connection with a chosen transport protocol, stating that a 945 message is idempotent facilitates transmitting it to the peer 946 application particularly early. 948 An application can be notified of a failure to send a specific 949 message. There is no guarantee of such notifications, i.e. send 950 failures can also silently occur. 952 6.3.2. Receiving Data 954 A receiving application obtains an "Application-Framed Bytestream" 955 (AFra-Bytestream); this concept is further described in Section 5.1). 956 In line with TCP's receiver semantics, an AFra-Bytestream is just a 957 stream of bytes to the receiver. If message boundaries were 958 specified by the sender, a receiver-side transport system 959 implementing only the minimum set of transport services defined here 960 will still not inform the receiving application about them (this 961 limitation is only needed for transport systems that are implemented 962 to directly use TCP). 964 Different from TCP's semantics, if the sending application has 965 allowed that messages are not fully reliably transferred, or 966 delivered out of order, then such re-ordering or unreliability may be 967 reflected per message in the arriving data. Messages will always 968 stay intact - i.e. if an incomplete message is contained at the end 969 of the arriving data block, this message is guaranteed to continue in 970 the next arriving data block. 972 7. Acknowledgements 974 The authors would like to thank all the participants of the TAPS 975 Working Group and the NEAT and MAMI research projects for valuable 976 input to this document. We especially thank Michael Tuexen for help 977 with connection connection establishment/teardown, Gorry Fairhurst 978 for his suggestions regarding fragmentation and packet sizes, and 979 Spencer Dawkins for his extremely detailed and constructive review. 980 This work has received funding from the European Union's Horizon 2020 981 research and innovation programme under grant agreement No. 644334 982 (NEAT). 984 8. IANA Considerations 986 This memo includes no request to IANA. 988 9. Security Considerations 990 Authentication, confidentiality protection, and integrity protection 991 are identified as transport features by [RFC8095]. Often, these 992 features are provided by a protocol or layer on top of the transport 993 protocol; none of the full-featured standards-track transport 994 protocols in [RFC8303], which this document is based upon, provides 995 all of these transport features on its own. Therefore, they are not 996 considered in this document, with the exception of native 997 authentication capabilities of TCP and SCTP for which the security 998 considerations in [RFC5925] and [RFC4895] apply. The minimum 999 requirements for a secure transport system are discussed in a 1000 separate document (Section 5 on Security Features and Transport 1001 Dependencies of [I-D.ietf-taps-transport-security]). 1003 10. References 1005 10.1. Normative References 1007 [I-D.ietf-taps-transport-security] 1008 Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey 1009 of Transport Security Protocols", draft-ietf-taps- 1010 transport-security-02 (work in progress), June 2018. 1012 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 1013 Ed., "Services Provided by IETF Transport Protocols and 1014 Congestion Control Mechanisms", RFC 8095, 1015 DOI 10.17487/RFC8095, March 2017, 1016 . 1018 [RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of 1019 Transport Features Provided by IETF Transport Protocols", 1020 RFC 8303, DOI 10.17487/RFC8303, February 2018, 1021 . 1023 10.2. Informative References 1025 [COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte 1026 Stuffing", IEEE/ACM Transactions on Networking Vol. 7, No. 1027 2, April 1999. 1029 [I-D.ietf-taps-interface] 1030 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 1031 Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An 1032 Abstract Application Layer Interface to Transport 1033 Services", draft-ietf-taps-interface-01 (work in 1034 progress), July 2018. 1036 [I-D.ietf-tsvwg-rtcweb-qos] 1037 Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP 1038 Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- 1039 qos-18 (work in progress), August 2016. 1041 [LBE-draft] 1042 Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", 1043 Internet-draft draft-tsvwg-le-phb-03, February 2018. 1045 [POSIX] "IEEE Standard for Information Technology--Portable 1046 Operating System Interface (POSIX(R)) Base Specifications, 1047 Issue 7", IEEE Std 1003.1-2017 (Revision of IEEE Std 1048 1003.1-2008), January 2018, 1049 . 1052 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 1053 Conrad, "Stream Control Transmission Protocol (SCTP) 1054 Partial Reliability Extension", RFC 3758, 1055 DOI 10.17487/RFC3758, May 2004, 1056 . 1058 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 1059 "Authenticated Chunks for the Stream Control Transmission 1060 Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 1061 2007, . 1063 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1064 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 1065 . 1067 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1068 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1069 June 2010, . 1071 [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application 1072 Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, 1073 March 2013, . 1075 [RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet 1076 Technology Adoption and Transition (ITAT)", RFC 7305, 1077 DOI 10.17487/RFC7305, July 2014, 1078 . 1080 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1081 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1082 . 1084 [RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, 1085 "Additional Policies for the Partially Reliable Stream 1086 Control Transmission Protocol Extension", RFC 7496, 1087 DOI 10.17487/RFC7496, April 2015, 1088 . 1090 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1091 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1092 March 2017, . 1094 [RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 1095 "Stream Schedulers and User Message Interleaving for the 1096 Stream Control Transmission Protocol", RFC 8260, 1097 DOI 10.17487/RFC8260, November 2017, 1098 . 1100 [RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the 1101 User Datagram Protocol (UDP) and Lightweight UDP (UDP- 1102 Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018, 1103 . 1105 [SCTP-stream-1] 1106 Weinrank, F. and M. Tuexen, "Transparent Flow Mapping for 1107 NEAT", IFIP NETWORKING Workshop on Future of Internet 1108 Transport (FIT 2017), June 2017. 1110 [SCTP-stream-2] 1111 Welzl, M., Niederbacher, F., and S. Gjessing, "Beneficial 1112 Transparent Deployment of SCTP", IEEE GlobeCom 2011, 1113 December 2011. 1115 [WWDC2015] 1116 Lakhera, P. and S. Cheshire, "Your App and Next Generation 1117 Networks", Apple Worldwide Developers Conference 2015, San 1118 Francisco, USA, June 2015, 1119 . 1121 Appendix A. The Superset of Transport Features 1123 In this description, transport features are presented following the 1124 nomenclature "CATEGORY.[SUBCATEGORY].FEATURENAME.PROTOCOL", 1125 equivalent to "pass 2" in [RFC8303]. We also sketch how functional 1126 or optimizing transport features can be implemented by a transport 1127 system. The "minimal set" derived in this document is meant to be 1128 implementable "one-sided" over TCP, and, with limitations, UDP. 1129 Hence, for all transport features that are categorized as 1130 "functional" or "optimizing", and for which no matching TCP and/or 1131 UDP primitive exists in "pass 2" of [RFC8303], a brief discussion on 1132 how to implement them over TCP and/or UDP is included. 1134 We designate some transport features as "automatable" on the basis of 1135 a broader decision that affects multiple transport features: 1137 o Most transport features that are related to multi-streaming were 1138 designated as "automatable". This was done because the decision 1139 on whether to use multi-streaming or not does not depend on 1140 application-specific knowledge. This means that a connection that 1141 is exhibited to an application could be implemented by using a 1142 single stream of an SCTP association instead of mapping it to a 1143 complete SCTP association or TCP connection. This could be 1144 achieved by using more than one stream when an SCTP association is 1145 first established (CONNECT.SCTP parameter "outbound stream 1146 count"), maintaining an internal stream number, and using this 1147 stream number when sending data (SEND.SCTP parameter "stream 1148 number"). Closing or aborting a connection could then simply free 1149 the stream number for future use. This is discussed further in 1150 Section 5.2. 1151 o With the exception of "Disable MPTCP", all transport features that 1152 are related to using multiple paths or the choice of the network 1153 interface were designated as "automatable". For example, "Listen" 1154 could always listen on all available interfaces and "Connect" 1155 could use the default interface for the destination IP address. 1157 Finally, in three cases, transport features are aggregated and/or 1158 slightly changed from [RFC8303] in the description below. These 1159 transport features are marked as "CHANGED FROM RFC8303". These do 1160 not add any new functionality but just represent a simple refactoring 1161 step that helps to streamline the derivation process (e.g., by 1162 removing a choice of a parameter for the sake of applications that 1163 may not care about this choice). The corresponding transport 1164 features are automatable, and they are listed immediately below the 1165 "CHANGED FROM RFC8303" transport feature. 1167 A.1. CONNECTION Related Transport Features 1169 ESTABLISHMENT: 1171 o Connect 1172 Protocols: TCP, SCTP, UDP(-Lite) 1173 Functional because the notion of a connection is often reflected 1174 in applications as an expectation to be able to communicate after 1175 a "Connect" succeeded, with a communication sequence relating to 1176 this transport feature that is defined by the application 1177 protocol. 1178 Implementation: via CONNECT.TCP, CONNECT.SCTP or CONNECT.UDP(- 1179 Lite). 1181 o Specify which IP Options must always be used 1182 Protocols: TCP, UDP(-Lite) 1183 Automatable because IP Options relate to knowledge about the 1184 network, not the application. 1186 o Request multiple streams 1187 Protocols: SCTP 1188 Automatable because using multi-streaming does not require 1189 application-specific knowledge (example implementations of using 1190 multi-streaming without involving the application are described in 1191 [SCTP-stream-1] and [SCTP-stream-2]). 1192 Implementation: see Section 5.2. 1194 o Limit the number of inbound streams 1195 Protocols: SCTP 1196 Automatable because using multi-streaming does not require 1197 application-specific knowledge. 1198 Implementation: see Section 5.2. 1200 o Specify number of attempts and/or timeout for the first 1201 establishment message 1202 Protocols: TCP, SCTP 1203 Functional because this is closely related to potentially assumed 1204 reliable data delivery for data that is sent before or during 1205 connection establishment. 1206 Implementation: Using a parameter of CONNECT.TCP and CONNECT.SCTP. 1207 Implementation over UDP: Do nothing (this is irrelevant in case of 1208 UDP because there, reliable data delivery is not assumed). 1210 o Obtain multiple sockets 1211 Protocols: SCTP 1212 Automatable because the non-parallel usage of multiple paths to 1213 communicate between the same end hosts relates to knowledge about 1214 the network, not the application. 1216 o Disable MPTCP 1217 Protocols: MPTCP 1218 Optimizing because the parallel usage of multiple paths to 1219 communicate between the same end hosts can improve performance. 1220 Whether to use this feature depends on knowledge about the network 1221 as well as application-specific knowledge (see Section 3.1 of 1222 [RFC6897]). 1223 Implementation: via a boolean parameter in CONNECT.MPTCP. 1224 Implementation over TCP: Do nothing. 1225 Implementation over UDP: Do nothing. 1227 o Configure authentication 1228 Protocols: TCP, SCTP 1229 Functional because this has a direct influence on security. 1230 Implementation: via parameters in CONNECT.TCP and CONNECT.SCTP. 1231 With TCP, this allows to configure Master Key Tuples (MKTs) to 1232 authenticate complete segments (including the TCP IPv4 1233 pseudoheader, TCP header, and TCP data). With SCTP, this allows 1234 to specify which chunk types must always be authenticated. 1235 Authenticating only certain chunk types creates a reduced level of 1236 security that is not supported by TCP; to be compatible, this 1237 should therefore only allow to authenticate all chunk types. Key 1238 material must be provided in a way that is compatible with both 1239 [RFC4895] and [RFC5925]. 1240 Implementation over UDP: Not possible (UDP does not offer this 1241 functionality). 1243 o Indicate (and/or obtain upon completion) an Adaptation Layer via 1244 an adaptation code point 1245 Protocols: SCTP 1246 Functional because it allows to send extra data for the sake of 1247 identifying an adaptation layer, which by itself is application- 1248 specific. 1249 Implementation: via a parameter in CONNECT.SCTP. 1250 Implementation over TCP: not possible (TCP does not offer this 1251 functionality). 1252 Implementation over UDP: not possible (UDP does not offer this 1253 functionality). 1255 o Request to negotiate interleaving of user messages 1256 Protocols: SCTP 1257 Automatable because it requires using multiple streams, but 1258 requesting multiple streams in the CONNECTION.ESTABLISHMENT 1259 category is automatable. 1260 Implementation: controlled via a parameter in CONNECT.SCTP. One 1261 possible implementation is to always try to enable interleaving. 1263 o Hand over a message to reliably transfer (possibly multiple times) 1264 before connection establishment 1265 Protocols: TCP 1266 Functional because this is closely tied to properties of the data 1267 that an application sends or expects to receive. 1268 Implementation: via a parameter in CONNECT.TCP. 1269 Implementation over UDP: not possible (UDP does not provide 1270 reliability). 1272 o Hand over a message to reliably transfer during connection 1273 establishment 1274 Protocols: SCTP 1275 Functional because this can only work if the message is limited in 1276 size, making it closely tied to properties of the data that an 1277 application sends or expects to receive. 1278 Implementation: via a parameter in CONNECT.SCTP. 1280 Implementation over TCP: not possible (TCP does not allow 1281 identification of message boundaries because it provides a byte 1282 stream service) 1283 Implementation over UDP: not possible (UDP is unreliable). 1285 o Enable UDP encapsulation with a specified remote UDP port number 1286 Protocols: SCTP 1287 Automatable because UDP encapsulation relates to knowledge about 1288 the network, not the application. 1290 AVAILABILITY: 1292 o Listen 1293 Protocols: TCP, SCTP, UDP(-Lite) 1294 Functional because the notion of accepting connection requests is 1295 often reflected in applications as an expectation to be able to 1296 communicate after a "Listen" succeeded, with a communication 1297 sequence relating to this transport feature that is defined by the 1298 application protocol. 1299 CHANGED FROM RFC8303. This differs from the 3 automatable 1300 transport features below in that it leaves the choice of 1301 interfaces for listening open. 1302 Implementation: by listening on all interfaces via LISTEN.TCP (not 1303 providing a local IP address) or LISTEN.SCTP (providing SCTP port 1304 number / address pairs for all local IP addresses). LISTEN.UDP(- 1305 Lite) supports both methods. 1307 o Listen, 1 specified local interface 1308 Protocols: TCP, SCTP, UDP(-Lite) 1309 Automatable because decisions about local interfaces relate to 1310 knowledge about the network and the Operating System, not the 1311 application. 1313 o Listen, N specified local interfaces 1314 Protocols: SCTP 1315 Automatable because decisions about local interfaces relate to 1316 knowledge about the network and the Operating System, not the 1317 application. 1319 o Listen, all local interfaces 1320 Protocols: TCP, SCTP, UDP(-Lite) 1321 Automatable because decisions about local interfaces relate to 1322 knowledge about the network and the Operating System, not the 1323 application. 1325 o Specify which IP Options must always be used 1326 Protocols: TCP, UDP(-Lite) 1327 Automatable because IP Options relate to knowledge about the 1328 network, not the application. 1330 o Disable MPTCP 1331 Protocols: MPTCP 1332 Optimizing because the parallel usage of multiple paths to 1333 communicate between the same end hosts can improve performance. 1334 Whether to use this feature depends on knowledge about the network 1335 as well as application-specific knowledge (see Section 3.1 of 1336 [RFC6897]). 1337 Implementation: via a boolean parameter in LISTEN.MPTCP. 1338 Implementation over TCP: Do nothing. 1339 Implementation over UDP: Do nothing. 1341 o Configure authentication 1342 Protocols: TCP, SCTP 1343 Functional because this has a direct influence on security. 1344 Implementation: via parameters in LISTEN.TCP and LISTEN.SCTP. 1345 Implementation over TCP: With TCP, this allows to configure Master 1346 Key Tuples (MKTs) to authenticate complete segments (including the 1347 TCP IPv4 pseudoheader, TCP header, and TCP data). With SCTP, this 1348 allows to specify which chunk types must always be authenticated. 1349 Authenticating only certain chunk types creates a reduced level of 1350 security that is not supported by TCP; to be compatible, this 1351 should therefore only allow to authenticate all chunk types. Key 1352 material must be provided in a way that is compatible with both 1353 [RFC4895] and [RFC5925]. 1354 Implementation over UDP: not possible (UDP does not offer 1355 authentication). 1357 o Obtain requested number of streams 1358 Protocols: SCTP 1359 Automatable because using multi-streaming does not require 1360 application-specific knowledge. 1362 Implementation: see Section 5.2. 1364 o Limit the number of inbound streams 1365 Protocols: SCTP 1366 Automatable because using multi-streaming does not require 1367 application-specific knowledge. 1368 Implementation: see Section 5.2. 1370 o Indicate (and/or obtain upon completion) an Adaptation Layer via 1371 an adaptation code point 1372 Protocols: SCTP 1373 Functional because it allows to send extra data for the sake of 1374 identifying an adaptation layer, which by itself is application- 1375 specific. 1376 Implementation: via a parameter in LISTEN.SCTP. 1377 Implementation over TCP: not possible (TCP does not offer this 1378 functionality). 1379 Implementation over UDP: not possible (UDP does not offer this 1380 functionality). 1382 o Request to negotiate interleaving of user messages 1383 Protocols: SCTP 1384 Automatable because it requires using multiple streams, but 1385 requesting multiple streams in the CONNECTION.ESTABLISHMENT 1386 category is automatable. 1387 Implementation: via a parameter in LISTEN.SCTP. 1389 MAINTENANCE: 1391 o Change timeout for aborting connection (using retransmit limit or 1392 time value) 1393 Protocols: TCP, SCTP 1394 Functional because this is closely related to potentially assumed 1395 reliable data delivery. 1396 Implementation: via CHANGE_TIMEOUT.TCP or CHANGE_TIMEOUT.SCTP. 1397 Implementation over UDP: not possible (UDP is unreliable and there 1398 is no connection timeout). 1400 o Suggest timeout to the peer 1401 Protocols: TCP 1402 Functional because this is closely related to potentially assumed 1403 reliable data delivery. 1404 Implementation: via CHANGE_TIMEOUT.TCP. 1405 Implementation over UDP: not possible (UDP is unreliable and there 1406 is no connection timeout). 1408 o Disable Nagle algorithm 1409 Protocols: TCP, SCTP 1410 Optimizing because this decision depends on knowledge about the 1411 size of future data blocks and the delay between them. 1412 Implementation: via DISABLE_NAGLE.TCP and DISABLE_NAGLE.SCTP. 1413 Implementation over UDP: do nothing (UDP does not implement the 1414 Nagle algorithm). 1416 o Request an immediate heartbeat, returning success/failure 1417 Protocols: SCTP 1418 Automatable because this informs about network-specific knowledge. 1420 o Notification of Excessive Retransmissions (early warning below 1421 abortion threshold) 1422 Protocols: TCP 1423 Optimizing because it is an early warning to the application, 1424 informing it of an impending functional event. 1425 Implementation: via ERROR.TCP. 1426 Implementation over UDP: do nothing (there is no abortion 1427 threshold). 1429 o Add path 1430 Protocols: MPTCP, SCTP 1431 MPTCP Parameters: source-IP; source-Port; destination-IP; 1432 destination-Port 1433 SCTP Parameters: local IP address 1434 Automatable because the choice of paths to communicate between the 1435 same end hosts relates to knowledge about the network, not the 1436 application. 1438 o Remove path 1439 Protocols: MPTCP, SCTP 1440 MPTCP Parameters: source-IP; source-Port; destination-IP; 1441 destination-Port 1442 SCTP Parameters: local IP address 1443 Automatable because the choice of paths to communicate between the 1444 same end host relates to knowledge about the network, not the 1445 application. 1447 o Set primary path 1448 Protocols: SCTP 1449 Automatable because the choice of paths to communicate between the 1450 same end hosts relates to knowledge about the network, not the 1451 application. 1453 o Suggest primary path to the peer 1454 Protocols: SCTP 1455 Automatable because the choice of paths to communicate between the 1456 same end hosts relates to knowledge about the network, not the 1457 application. 1459 o Configure Path Switchover 1460 Protocols: SCTP 1461 Automatable because the choice of paths to communicate between the 1462 same end hosts relates to knowledge about the network, not the 1463 application. 1465 o Obtain status (query or notification) 1466 Protocols: SCTP, MPTCP 1467 SCTP parameters: association connection state; destination 1468 transport address list; destination transport address reachability 1469 states; current local and peer receiver window size; current local 1470 congestion window sizes; number of unacknowledged DATA chunks; 1471 number of DATA chunks pending receipt; primary path; most recent 1472 SRTT on primary path; RTO on primary path; SRTT and RTO on other 1473 destination addresses; MTU per path; interleaving supported yes/no 1474 MPTCP parameters: subflow-list (identified by source-IP; source- 1475 Port; destination-IP; destination-Port) 1476 Automatable because these parameters relate to knowledge about the 1477 network, not the application. 1479 o Specify DSCP field 1480 Protocols: TCP, SCTP, UDP(-Lite) 1481 Optimizing because choosing a suitable DSCP value requires 1482 application-specific knowledge. 1483 Implementation: via SET_DSCP.TCP / SET_DSCP.SCTP / SET_DSCP.UDP(- 1484 Lite) 1486 o Notification of ICMP error message arrival 1487 Protocols: TCP, UDP(-Lite) 1488 Optimizing because these messages can inform about success or 1489 failure of functional transport features (e.g., host unreachable 1490 relates to "Connect") 1491 Implementation: via ERROR.TCP or ERROR.UDP(-Lite). 1493 o Obtain information about interleaving support 1494 Protocols: SCTP 1495 Automatable because it requires using multiple streams, but 1496 requesting multiple streams in the CONNECTION.ESTABLISHMENT 1497 category is automatable. 1498 Implementation: via STATUS.SCTP. 1500 o Change authentication parameters 1501 Protocols: TCP, SCTP 1502 Functional because this has a direct influence on security. 1503 Implementation: via SET_AUTH.TCP and SET_AUTH.SCTP. 1504 Implementation over TCP: With SCTP, this allows to adjust key_id, 1505 key, and hmac_id. With TCP, this allows to change the preferred 1506 outgoing MKT (current_key) and the preferred incoming MKT 1507 (rnext_key), respectively, for a segment that is sent on the 1508 connection. Key material must be provided in a way that is 1509 compatible with both [RFC4895] and [RFC5925]. 1510 Implementation over UDP: not possible (UDP does not offer 1511 authentication). 1513 o Obtain authentication information 1514 Protocols: SCTP 1515 Functional because authentication decisions may have been made by 1516 the peer, and this has an influence on the necessary application- 1517 level measures to provide a certain level of security. 1518 Implementation: via GET_AUTH.SCTP. 1520 Implementation over TCP: With SCTP, this allows to obtain key_id 1521 and a chunk list. With TCP, this allows to obtain current_key and 1522 rnext_key from a previously received segment. Key material must 1523 be provided in a way that is compatible with both [RFC4895] and 1524 [RFC5925]. 1525 Implementation over UDP: not possible (UDP does not offer 1526 authentication). 1528 o Reset Stream 1529 Protocols: SCTP 1530 Automatable because using multi-streaming does not require 1531 application-specific knowledge. 1532 Implementation: see Section 5.2. 1534 o Notification of Stream Reset 1535 Protocols: STCP 1536 Automatable because using multi-streaming does not require 1537 application-specific knowledge. 1538 Implementation: see Section 5.2. 1540 o Reset Association 1541 Protocols: SCTP 1542 Automatable because deciding to reset an association does not 1543 require application-specific knowledge. 1544 Implementation: via RESET_ASSOC.SCTP. 1546 o Notification of Association Reset 1547 Protocols: STCP 1548 Automatable because this notification does not relate to 1549 application-specific knowledge. 1551 o Add Streams 1552 Protocols: SCTP 1553 Automatable because using multi-streaming does not require 1554 application-specific knowledge. 1555 Implementation: see Section 5.2. 1557 o Notification of Added Stream 1558 Protocols: STCP 1559 Automatable because using multi-streaming does not require 1560 application-specific knowledge. 1561 Implementation: see Section 5.2. 1563 o Choose a scheduler to operate between streams of an association 1564 Protocols: SCTP 1565 Optimizing because the scheduling decision requires application- 1566 specific knowledge. However, if a transport system would not use 1567 this, or wrongly configure it on its own, this would only affect 1568 the performance of data transfers; the outcome would still be 1569 correct within the "best effort" service model. 1570 Implementation: using SET_STREAM_SCHEDULER.SCTP. 1571 Implementation over TCP: do nothing (streams are not available in 1572 TCP, but no guarantee is given that this transport feature has any 1573 effect). 1574 Implementation over UDP: do nothing (streams are not available in 1575 UDP, but no guarantee is given that this transport feature has any 1576 effect). 1578 o Configure priority or weight for a scheduler 1579 Protocols: SCTP 1580 Optimizing because the priority or weight requires application- 1581 specific knowledge. However, if a transport system would not use 1582 this, or wrongly configure it on its own, this would only affect 1583 the performance of data transfers; the outcome would still be 1584 correct within the "best effort" service model. 1585 Implementation: using CONFIGURE_STREAM_SCHEDULER.SCTP. 1586 Implementation over TCP: do nothing (streams are not available in 1587 TCP, but no guarantee is given that this transport feature has any 1588 effect). 1589 Implementation over UDP: do nothing (streams are not available in 1590 UDP, but no guarantee is given that this transport feature has any 1591 effect). 1593 o Configure send buffer size 1594 Protocols: SCTP 1595 Automatable because this decision relates to knowledge about the 1596 network and the Operating System, not the application (see also 1597 the discussion in Section 5.4). 1599 o Configure receive buffer (and rwnd) size 1600 Protocols: SCTP 1601 Automatable because this decision relates to knowledge about the 1602 network and the Operating System, not the application. 1604 o Configure message fragmentation 1605 Protocols: SCTP 1606 Automatable because this relates to knowledge about the network 1607 and the Operating System, not the application. Note that this 1608 SCTP feature does not control IP-level fragmentation, but decides 1609 on fragmentation of messages by SCTP, in the end system. 1610 Implementation: by always enabling it with 1611 CONFIG_FRAGMENTATION.SCTP and auto-setting the fragmentation size 1612 based on network or Operating System conditions. 1614 o Configure PMTUD 1615 Protocols: SCTP 1616 Automatable because Path MTU Discovery relates to knowledge about 1617 the network, not the application. 1619 o Configure delayed SACK timer 1620 Protocols: SCTP 1621 Automatable because the receiver-side decision to delay sending 1622 SACKs relates to knowledge about the network, not the application 1623 (it can be relevant for a sending application to request not to 1624 delay the SACK of a message, but this is a different transport 1625 feature). 1627 o Set Cookie life value 1628 Protocols: SCTP 1629 Functional because it relates to security (possibly weakened by 1630 keeping a cookie very long) versus the time between connection 1631 establishment attempts. Knowledge about both issues can be 1632 application-specific. 1633 Implementation over TCP: the closest specified TCP functionality 1634 is the cookie in TCP Fast Open; for this, [RFC7413] states that 1635 the server "can expire the cookie at any time to enhance security" 1636 and section 4.1.2 describes an example implementation where 1637 updating the key on the server side causes the cookie to expire. 1638 Alternatively, for implementations that do not support TCP Fast 1639 Open, this transport feature could also affect the validity of SYN 1640 cookies (see Section 3.6 of [RFC4987]). 1641 Implementation over UDP: not possible (UDP does not offer this 1642 functionality). 1644 o Set maximum burst 1645 Protocols: SCTP 1646 Automatable because it relates to knowledge about the network, not 1647 the application. 1649 o Configure size where messages are broken up for partial delivery 1650 Protocols: SCTP 1651 Functional because this is closely tied to properties of the data 1652 that an application sends or expects to receive. 1653 Implementation over TCP: not possible (TCP does not offer 1654 identification of message boundaries). 1655 Implementation over UDP: not possible (UDP does not fragment 1656 messages). 1658 o Disable checksum when sending 1659 Protocols: UDP 1660 Functional because application-specific knowledge is necessary to 1661 decide whether it can be acceptable to lose data integrity with 1662 respect to random corruption. 1663 Implementation: via SET_CHECKSUM_ENABLED.UDP. 1664 Implementation over TCP: do nothing (TCP does not offer to disable 1665 the checksum, but transmitting data with an intact checksum will 1666 not yield a semantically wrong result). 1668 o Disable checksum requirement when receiving 1669 Protocols: UDP 1670 Functional because application-specific knowledge is necessary to 1671 decide whether it can be acceptable to lose data integrity with 1672 respect to random corruption. 1673 Implementation: via SET_CHECKSUM_REQUIRED.UDP. 1674 Implementation over TCP: do nothing (TCP does not offer to disable 1675 the checksum, but transmitting data with an intact checksum will 1676 not yield a semantically wrong result). 1678 o Specify checksum coverage used by the sender 1679 Protocols: UDP-Lite 1680 Functional because application-specific knowledge is necessary to 1681 decide for which parts of the data it can be acceptable to lose 1682 data integrity with respect to random corruption. 1683 Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite. 1684 Implementation over TCP: do nothing (TCP does not offer to limit 1685 the checksum length, but transmitting data with an intact checksum 1686 will not yield a semantically wrong result). 1687 Implementation over UDP: if checksum coverage is set to cover 1688 payload data, do nothing. Else, either do nothing (transmitting 1689 data with an intact checksum will not yield a semantically wrong 1690 result), or use the transport feature "Disable checksum when 1691 sending". 1693 o Specify minimum checksum coverage required by receiver 1694 Protocols: UDP-Lite 1695 Functional because application-specific knowledge is necessary to 1696 decide for which parts of the data it can be acceptable to lose 1697 data integrity with respect to random corruption. 1698 Implementation: via SET_MIN_CHECKSUM_COVERAGE.UDP-Lite. 1699 Implementation over TCP: do nothing (TCP does not offer to limit 1700 the checksum length, but transmitting data with an intact checksum 1701 will not yield a semantically wrong result). 1702 Implementation over UDP: if checksum coverage is set to cover 1703 payload data, do nothing. Else, either do nothing (transmitting 1704 data with an intact checksum will not yield a semantically wrong 1705 result), or use the transport feature "Disable checksum 1706 requirement when receiving". 1708 o Specify DF field 1709 Protocols: UDP(-Lite) 1710 Optimizing because the DF field can be used to carry out Path MTU 1711 Discovery, which can lead an application to choose message sizes 1712 that can be transmitted more efficiently. 1713 Implementation: via MAINTENANCE.SET_DF.UDP(-Lite) and 1714 SEND_FAILURE.UDP(-Lite). 1715 Implementation over TCP: do nothing (with TCP, the sending 1716 application is not in control of transport message sizes, making 1717 this functionality irrelevant). 1719 o Get max. transport-message size that may be sent using a non- 1720 fragmented IP packet from the configured interface 1721 Protocols: UDP(-Lite) 1722 Optimizing because this can lead an application to choose message 1723 sizes that can be transmitted more efficiently. 1725 Implementation over TCP: do nothing (this information is not 1726 available with TCP). 1728 o Get max. transport-message size that may be received from the 1729 configured interface 1730 Protocols: UDP(-Lite) 1731 Optimizing because this can, for example, influence an 1732 application's memory management. 1733 Implementation over TCP: do nothing (this information is not 1734 available with TCP). 1736 o Specify TTL/Hop count field 1737 Protocols: UDP(-Lite) 1738 Automatable because a transport system can use a large enough 1739 system default to avoid communication failures. Allowing an 1740 application to configure it differently can produce notifications 1741 of ICMP error message arrivals that yield information which only 1742 relates to knowledge about the network, not the application. 1744 o Obtain TTL/Hop count field 1745 Protocols: UDP(-Lite) 1746 Automatable because the TTL/Hop count field relates to knowledge 1747 about the network, not the application. 1749 o Specify ECN field 1750 Protocols: UDP(-Lite) 1751 Automatable because the ECN field relates to knowledge about the 1752 network, not the application. 1754 o Obtain ECN field 1755 Protocols: UDP(-Lite) 1756 Optimizing because this information can be used by an application 1757 to better carry out congestion control (this is relevant when 1758 choosing a data transmission transport service that does not 1759 already do congestion control). 1760 Implementation over TCP: do nothing (this information is not 1761 available with TCP). 1763 o Specify IP Options 1764 Protocols: UDP(-Lite) 1765 Automatable because IP Options relate to knowledge about the 1766 network, not the application. 1768 o Obtain IP Options 1769 Protocols: UDP(-Lite) 1770 Automatable because IP Options relate to knowledge about the 1771 network, not the application. 1773 o Enable and configure a "Low Extra Delay Background Transfer" 1774 Protocols: A protocol implementing the LEDBAT congestion control 1775 mechanism 1776 Optimizing because whether this feature is appropriate or not 1777 depends on application-specific knowledge. However, wrongly using 1778 this will only affect the speed of data transfers (albeit 1779 including other transfers that may compete with the transport 1780 system's transfer in the network), so it is still correct within 1781 the "best effort" service model. 1782 Implementation: via CONFIGURE.LEDBAT and/or SET_DSCP.TCP / 1783 SET_DSCP.SCTP / SET_DSCP.UDP(-Lite) [LBE-draft]. 1784 Implementation over TCP: do nothing (TCP does not support LEDBAT 1785 congestion control, but not implementing this functionality will 1786 not yield a semantically wrong behavior). 1787 Implementation over UDP: do nothing (UDP does not offer congestion 1788 control). 1790 TERMINATION: 1792 o Close after reliably delivering all remaining data, causing an 1793 event informing the application on the other side 1794 Protocols: TCP, SCTP 1795 Functional because the notion of a connection is often reflected 1796 in applications as an expectation to have all outstanding data 1797 delivered and no longer be able to communicate after a "Close" 1798 succeeded, with a communication sequence relating to this 1799 transport feature that is defined by the application protocol. 1800 Implementation: via CLOSE.TCP and CLOSE.SCTP. 1801 Implementation over UDP: not possible (UDP is unreliable and hence 1802 does not know when all remaining data is delivered; it does also 1803 not offer to cause an event related to closing at the peer). 1805 o Abort without delivering remaining data, causing an event 1806 informing the application on the other side 1807 Protocols: TCP, SCTP 1808 Functional because the notion of a connection is often reflected 1809 in applications as an expectation to potentially not have all 1810 outstanding data delivered and no longer be able to communicate 1811 after an "Abort" succeeded. On both sides of a connection, an 1812 application protocol may define a communication sequence relating 1813 to this transport feature. 1814 Implementation: via ABORT.TCP and ABORT.SCTP. 1815 Implementation over UDP: not possible (UDP does not offer to cause 1816 an event related to aborting at the peer). 1818 o Abort without delivering remaining data, not causing an event 1819 informing the application on the other side 1820 Protocols: UDP(-Lite) 1821 Functional because the notion of a connection is often reflected 1822 in applications as an expectation to potentially not have all 1823 outstanding data delivered and no longer be able to communicate 1824 after an "Abort" succeeded. On both sides of a connection, an 1825 application protocol may define a communication sequence relating 1826 to this transport feature. 1827 Implementation: via ABORT.UDP(-Lite). 1828 Implementation over TCP: stop using the connection, wait for a 1829 timeout. 1831 o Timeout event when data could not be delivered for too long 1832 Protocols: TCP, SCTP 1833 Functional because this notifies that potentially assumed reliable 1834 data delivery is no longer provided. 1835 Implementation: via TIMEOUT.TCP and TIMEOUT.SCTP. 1836 Implementation over UDP: do nothing (this event will not occur 1837 with UDP). 1839 A.2. DATA Transfer Related Transport Features 1841 A.2.1. Sending Data 1843 o Reliably transfer data, with congestion control 1844 Protocols: TCP, SCTP 1845 Functional because this is closely tied to properties of the data 1846 that an application sends or expects to receive. 1847 Implementation: via SEND.TCP and SEND.SCTP. 1848 Implementation over UDP: not possible (UDP is unreliable). 1850 o Reliably transfer a message, with congestion control 1851 Protocols: SCTP 1852 Functional because this is closely tied to properties of the data 1853 that an application sends or expects to receive. 1854 Implementation: via SEND.SCTP. 1855 Implementation over TCP: via SEND.TCP. With SEND.TCP, message 1856 boundaries will not be identifiable by the receiver, because TCP 1857 provides a byte stream service. 1858 Implementation over UDP: not possible (UDP is unreliable). 1860 o Unreliably transfer a message 1861 Protocols: SCTP, UDP(-Lite) 1862 Optimizing because only applications know about the time 1863 criticality of their communication, and reliably transfering a 1864 message is never incorrect for the receiver of a potentially 1865 unreliable data transfer, it is just slower. 1866 CHANGED FROM RFC8303. This differs from the 2 automatable 1867 transport features below in that it leaves the choice of 1868 congestion control open. 1869 Implementation: via SEND.SCTP or SEND.UDP(-Lite). 1870 Implementation over TCP: use SEND.TCP. With SEND.TCP, messages 1871 will be sent reliably, and message boundaries will not be 1872 identifiable by the receiver. 1874 o Unreliably transfer a message, with congestion control 1875 Protocols: SCTP 1876 Automatable because congestion control relates to knowledge about 1877 the network, not the application. 1879 o Unreliably transfer a message, without congestion control 1880 Protocols: UDP(-Lite) 1881 Automatable because congestion control relates to knowledge about 1882 the network, not the application. 1884 o Configurable Message Reliability 1885 Protocols: SCTP 1886 Optimizing because only applications know about the time 1887 criticality of their communication, and reliably transfering a 1888 message is never incorrect for the receiver of a potentially 1889 unreliable data transfer, it is just slower. 1890 Implementation: via SEND.SCTP. 1891 Implementation over TCP: By using SEND.TCP and ignoring this 1892 configuration: based on the assumption of the best-effort service 1893 model, unnecessarily delivering data does not violate application 1894 expectations. Moreover, it is not possible to associate the 1895 requested reliability to a "message" in TCP anyway. 1896 Implementation over UDP: not possible (UDP is unreliable). 1898 o Choice of stream 1899 Protocols: SCTP 1900 Automatable because it requires using multiple streams, but 1901 requesting multiple streams in the CONNECTION.ESTABLISHMENT 1902 category is automatable. Implementation: see Section 5.2. 1904 o Choice of path (destination address) 1905 Protocols: SCTP 1906 Automatable because it requires using multiple sockets, but 1907 obtaining multiple sockets in the CONNECTION.ESTABLISHMENT 1908 category is automatable. 1910 o Ordered message delivery (potentially slower than unordered) 1911 Protocols: SCTP 1912 Functional because this is closely tied to properties of the data 1913 that an application sends or expects to receive. 1914 Implementation: via SEND.SCTP. 1915 Implementation over TCP: By using SEND.TCP. With SEND.TCP, 1916 messages will not be identifiable by the receiver. 1917 Implementation over UDP: not possible (UDP does not offer any 1918 guarantees regarding ordering). 1920 o Unordered message delivery (potentially faster than ordered) 1921 Protocols: SCTP, UDP(-Lite) 1922 Functional because this is closely tied to properties of the data 1923 that an application sends or expects to receive. 1924 Implementation: via SEND.SCTP. 1926 Implementation over TCP: By using SEND.TCP and always sending data 1927 ordered: based on the assumption of the best-effort service model, 1928 ordered delivery may just be slower and does not violate 1929 application expectations. Moreover, it is not possible to 1930 associate the requested delivery order to a "message" in TCP 1931 anyway. 1933 o Request not to bundle messages 1934 Protocols: SCTP 1935 Optimizing because this decision depends on knowledge about the 1936 size of future data blocks and the delay between them. 1937 Implementation: via SEND.SCTP. 1938 Implementation over TCP: By using SEND.TCP and DISABLE_NAGLE.TCP 1939 to disable the Nagle algorithm when the request is made and enable 1940 it again when the request is no longer made. Note that this is 1941 not fully equivalent because it relates to the time of issuing the 1942 request rather than a specific message. 1943 Implementation over UDP: do nothing (UDP never bundles messages). 1945 o Specifying a "payload protocol-id" (handed over as such by the 1946 receiver) 1947 Protocols: SCTP 1948 Functional because it allows to send extra application data with 1949 every message, for the sake of identification of data, which by 1950 itself is application-specific. 1951 Implementation: SEND.SCTP. 1952 Implementation over TCP: not possible (this functionality is not 1953 available in TCP). 1954 Implementation over UDP: not possible (this functionality is not 1955 available in UDP). 1957 o Specifying a key id to be used to authenticate a message 1958 Protocols: SCTP 1959 Functional because this has a direct influence on security. 1960 Implementation: via a parameter in SEND.SCTP. 1961 Implementation over TCP: This could be emulated by using 1962 SET_AUTH.TCP before and after the message is sent. Note that this 1963 is not fully equivalent because it relates to the time of issuing 1964 the request rather than a specific message. 1965 Implementation over UDP: not possible (UDP does not offer 1966 authentication). 1968 o Request not to delay the acknowledgement (SACK) of a message 1969 Protocols: SCTP 1970 Optimizing because only an application knows for which message it 1971 wants to quickly be informed about success / failure of its 1972 delivery. 1973 Implementation over TCP: do nothing (TCP does not offer this 1974 functionality, but ignoring this request from the application will 1975 not yield a semantically wrong behavior). 1976 Implementation over UDP: do nothing (UDP does not offer this 1977 functionality, but ignoring this request from the application will 1978 not yield a semantically wrong behavior). 1980 A.2.2. Receiving Data 1982 o Receive data (with no message delimiting) 1983 Protocols: TCP 1984 Functional because a transport system must be able to send and 1985 receive data. 1986 Implementation: via RECEIVE.TCP. 1987 Implementation over UDP: do nothing (UDP only works on messages; 1988 these can be handed over, the application can still ignore the 1989 message boundaries). 1991 o Receive a message 1992 Protocols: SCTP, UDP(-Lite) 1993 Functional because this is closely tied to properties of the data 1994 that an application sends or expects to receive. 1995 Implementation: via RECEIVE.SCTP and RECEIVE.UDP(-Lite). 1996 Implementation over TCP: not possible (TCP does not support 1997 identification of message boundaries). 1999 o Choice of stream to receive from 2000 Protocols: SCTP 2001 Automatable because it requires using multiple streams, but 2002 requesting multiple streams in the CONNECTION.ESTABLISHMENT 2003 category is automatable. 2004 Implementation: see Section 5.2. 2006 o Information about partial message arrival 2007 Protocols: SCTP 2008 Functional because this is closely tied to properties of the data 2009 that an application sends or expects to receive. 2010 Implementation: via RECEIVE.SCTP. 2011 Implementation over TCP: do nothing (this information is not 2012 available with TCP). 2013 Implementation over UDP: do nothing (this information is not 2014 available with UDP). 2016 A.2.3. Errors 2018 This section describes sending failures that are associated with a 2019 specific call to in the "Sending Data" category (Appendix A.2.1). 2021 o Notification of send failures 2022 Protocols: SCTP, UDP(-Lite) 2023 Functional because this notifies that potentially assumed reliable 2024 data delivery is no longer provided. 2025 CHANGED FROM RFC8303. This differs from the 2 automatable 2026 transport features below in that it does not distinugish between 2027 unsent and unacknowledged messages. 2028 Implementation: via SENDFAILURE-EVENT.SCTP and SEND_FAILURE.UDP(- 2029 Lite). 2030 Implementation over TCP: do nothing (this notification is not 2031 available and will therefore not occur with TCP). 2033 o Notification of an unsent (part of a) message 2034 Protocols: SCTP, UDP(-Lite) 2035 Automatable because the distinction between unsent and 2036 unacknowledged does not relate to application-specific knowledge. 2038 o Notification of an unacknowledged (part of a) message 2039 Protocols: SCTP 2040 Automatable because the distinction between unsent and 2041 unacknowledged does not relate to application-specific knowledge. 2043 o Notification that the stack has no more user data to send 2044 Protocols: SCTP 2045 Optimizing because reacting to this notification requires the 2046 application to be involved, and ensuring that the stack does not 2047 run dry of data (for too long) can improve performance. 2048 Implementation over TCP: do nothing (see the discussion in 2049 Section 5.4). 2050 Implementation over UDP: do nothing (this notification is not 2051 available and will therefore not occur with UDP). 2053 o Notification to a receiver that a partial message delivery has 2054 been aborted 2055 Protocols: SCTP 2056 Functional because this is closely tied to properties of the data 2057 that an application sends or expects to receive. 2058 Implementation over TCP: do nothing (this notification is not 2059 available and will therefore not occur with TCP). 2060 Implementation over UDP: do nothing (this notification is not 2061 available and will therefore not occur with UDP). 2063 Appendix B. Revision information 2065 XXX RFC-Ed please remove this section prior to publication. 2067 -02: implementation suggestions added, discussion section added, 2068 terminology extended, DELETED category removed, various other fixes; 2069 list of Transport Features adjusted to -01 version of [RFC8303] 2070 except that MPTCP is not included. 2072 -03: updated to be consistent with -02 version of [RFC8303]. 2074 -04: updated to be consistent with -03 version of [RFC8303]. 2075 Reorganized document, rewrote intro and conclusion, and made a first 2076 stab at creating a real "minimal set". 2078 -05: updated to be consistent with -05 version of [RFC8303] (minor 2079 changes). Fixed a mistake regarding Cookie Life value. Exclusion of 2080 security related transport features (to be covered in a separate 2081 document). Reorganized the document (now begins with the minset, 2082 derivation is in the appendix). First stab at an abstract API for 2083 the minset. 2085 draft-ietf-taps-minset-00: updated to be consistent with -08 version 2086 of [RFC8303] ("obtain message delivery number" was removed, as this 2087 has also been removed in [RFC8303] because it was a mistake in 2088 RFC4960. This led to the removal of two more transport features that 2089 were only designated as functional because they affected "obtain 2090 message delivery number"). Fall-back to UDP incorporated (this was 2091 requested at IETF-99); this also affected the transport feature 2092 "Choice between unordered (potentially faster) or ordered delivery of 2093 messages" because this is a boolean which is always true for one 2094 fall-back protocol, and always false for the other one. This was 2095 therefore now divided into two features, one for ordered, one for 2096 unordered delivery. The word "reliably" was added to the transport 2097 features "Hand over a message to reliably transfer (possibly multiple 2098 times) before connection establishment" and "Hand over a message to 2099 reliably transfer during connection establishment" to make it clearer 2100 why this is not supported by UDP. Clarified that the "minset 2101 abstract interface" is not proposing a specific API for all TAPS 2102 systems to implement, but it is just a way to describe the minimum 2103 set. Author order changed. 2105 WG -01: "fall-back to" (TCP or UDP) replaced (mostly with 2106 "implementation over"). References to post-sockets removed (these 2107 were statments that assumed that post-sockets requires two-sided 2108 implementation). Replaced "flow" with "TAPS Connection" and "frame" 2109 with "message" to avoid introducing new terminology. Made sections 3 2110 and 4 in line with the categorization that is already used in the 2111 appendix and [RFC8303], and changed style of section 4 to be even 2112 shorter and less interface-like. Updated reference draft-ietf-tsvwg- 2113 sctp-ndata to RFC8260. 2115 WG -02: rephrased "the TAPS system" and "TAPS connection" etc. to 2116 more generally talk about transport after the intro (mostly replacing 2117 "TAPS system" with "transport system" and "TAPS connection" with 2118 "connection". Merged sections 3 and 4 to form a new section 3. 2120 WG -03: updated sentence referencing 2121 [I-D.ietf-taps-transport-security] to say that "the minimum security 2122 requirements for a taps system are discussed in a separate security 2123 document", wrote "example" in the paragraph introducing the decision 2124 tree. Removed reference draft-grinnemo-taps-he-03 and the sentence 2125 that referred to it. 2127 WG -04: addressed comments from Theresa Enghardt and Tommy Pauly. As 2128 part of that, removed "TAPS" as a term everywhere (abstract, intro, 2129 ..). 2131 WG -05: addressed comments from Spencer Dawkins. 2133 WG -06: Fixed nits. 2135 WG -07: Addressed Genart comments from Robert Sparks. 2137 WG -08: Addressed one more Genart comment from Robert Sparks. 2139 WG -09: Addressed comments from Mirja Kuehlewind, Alvaro Retana, Ben 2140 Campbell, Benjamin Kaduk and Eric Rescorla. 2142 WG -10: Addressed comments from Benjamin Kaduk and Eric Rescorla. 2144 WG -11: Addressed comments from Alissa Cooper. 2146 Authors' Addresses 2148 Michael Welzl 2149 University of Oslo 2150 PO Box 1080 Blindern 2151 Oslo N-0316 2152 Norway 2154 Phone: +47 22 85 24 20 2155 Email: michawe@ifi.uio.no 2157 Stein Gjessing 2158 University of Oslo 2159 PO Box 1080 Blindern 2160 Oslo N-0316 2161 Norway 2163 Phone: +47 22 85 24 44 2164 Email: steing@ifi.uio.no