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