idnits 2.17.1 draft-ietf-taps-minset-10.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 18, 2018) is 2047 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SUBCATEGORY' is mentioned on line 1114, 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 22, 2019 September 18, 2018 7 A Minimal Set of Transport Services for End Systems 8 draft-ietf-taps-minset-10 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 22, 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 . . . . . . . . . . . . . . . . . . . . . . . 49 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,U: Disable MPTCP 324 o T: Configure authentication 325 o T: Hand over a message to reliably transfer (possibly multiple 326 times) before connection establishment 327 o T: Hand over a message to reliably transfer during connection 328 establishment 330 AVAILABILITY: 332 o T,U: Listen 333 o T,U: Disable MPTCP 334 o T: Configure authentication 336 MAINTENANCE: 338 o T: Change timeout for aborting connection (using retransmit limit 339 or time value) 340 o T: Suggest timeout to the peer 341 o T,U: Disable Nagle algorithm 342 o T,U: Notification of Excessive Retransmissions (early warning 343 below abortion threshold) 344 o T,U: Specify DSCP field 345 o T,U: Notification of ICMP error message arrival 346 o T: Change authentication parameters 347 o T: Obtain authentication information 348 o T,U: Set Cookie life value 349 o T,U: Choose a scheduler to operate between streams of an 350 association 351 o T,U: Configure priority or weight for a scheduler 352 o T,U: Disable checksum when sending 353 o T,U: Disable checksum requirement when receiving 354 o T,U: Specify checksum coverage used by the sender 355 o T,U: Specify minimum checksum coverage required by receiver 356 o T,U: Specify DF field 357 o T,U: Get max. transport-message size that may be sent using a non- 358 fragmented IP packet from the configured interface 359 o T,U: Get max. transport-message size that may be received from the 360 configured interface 361 o T,U: Obtain ECN field 362 o T,U: Enable and configure a "Low Extra Delay Background Transfer" 364 TERMINATION: 366 o T: Close after reliably delivering all remaining data, causing an 367 event informing the application on the other side 368 o T: Abort without delivering remaining data, causing an event 369 informing the application on the other side 370 o T,U: Abort without delivering remaining data, not causing an event 371 informing the application on the other side 372 o T,U: Timeout event when data could not be delivered for too long 374 4.2. DATA Transfer Related Transport Features 376 4.2.1. Sending Data 378 o T: Reliably transfer data, with congestion control 379 o T: Reliably transfer a message, with congestion control 380 o T,U: Unreliably transfer a message 381 o T: Configurable Message Reliability 382 o T: Ordered message delivery (potentially slower than unordered) 383 o T,U: Unordered message delivery (potentially faster than ordered) 384 o T,U: Request not to bundle messages 385 o T: Specifying a key id to be used to authenticate a message 386 o T,U: Request not to delay the acknowledgement (SACK) of a message 388 4.2.2. Receiving Data 390 o T,U: Receive data (with no message delimiting) 391 o U: Receive a message 392 o T,U: Information about partial message arrival 394 4.2.3. Errors 396 This section describes sending failures that are associated with a 397 specific call to in the "Sending Data" category (Appendix A.2.1). 399 o T,U: Notification of send failures 400 o T,U: Notification that the stack has no more user data to send 401 o T,U: Notification to a receiver that a partial message delivery 402 has been aborted 404 5. Discussion 406 The reduced set in the previous section exhibits a number of 407 peculiarities, which we will discuss in the following. This section 408 focuses on TCP because, with the exception of one particular 409 transport feature ("Receive a message" -- we will discuss this in 410 Section 5.1), the list shows that UDP is strictly a subset of TCP. 411 We can first try to understand how to build a transport system that 412 can run over TCP, and then narrow down the result further to allow 413 that the system can always run over either TCP or UDP (which 414 effectively means removing everything related to reliability, 415 ordering, authentication and closing/aborting with a notification to 416 the peer). 418 Note that, because the functional transport features of UDP are -- 419 with the exception of "Receive a message" -- a subset of TCP, TCP can 420 be used as a replacement for UDP whenever an application does not 421 need message delimiting (e.g., because the application-layer protocol 422 already does it). This has been recognized by many applications that 423 already do this in practice, by trying to communicate with UDP at 424 first, and falling back to TCP in case of a connection failure. 426 5.1. Sending Messages, Receiving Bytes 428 For implementing a transport system over TCP, there are several 429 transport features related to sending, but only a single transport 430 feature related to receiving: "Receive data (with no message 431 delimiting)" (and, strangely, "information about partial message 432 arrival"). Notably, the transport feature "Receive a message" is 433 also the only non-automatable transport feature of UDP(-Lite) for 434 which no implementation over TCP is possible. 436 To support these TCP receiver semantics, we define an "Application- 437 Framed Bytestream" (AFra-Bytestream). AFra-Bytestreams allow senders 438 to operate on messages while minimizing changes to the TCP socket 439 API. In particular, nothing changes on the receiver side - data can 440 be accepted via a normal TCP socket. 442 In an AFra-Bytestream, the sending application can optionally inform 443 the transport about message boundaries and required properties per 444 message (configurable order and reliability, or embedding a request 445 not to delay the acknowledgement of a message). Whenever the sending 446 application specifies per-message properties that relax the notion of 447 reliable in-order delivery of bytes, it must assume that the 448 receiving application is 1) able to determine message boundaries, 449 provided that messages are always kept intact, and 2) able to accept 450 these relaxed per-message properties. Any signaling of such 451 information to the peer is up to an application-layer protocol and 452 considered out of scope of this document. 454 For example, if an application requests to transfer fixed-size 455 messages of 100 bytes with partial reliability, this needs the 456 receiving application to be prepared to accept data in chunks of 100 457 bytes. If, then, some of these 100-byte messages are missing (e.g., 458 if SCTP with Configurable Reliability is used), this is the expected 459 application behavior. With TCP, no messages would be missing, but 460 this is also correct for the application, and the possible 461 retransmission delay is acceptable within the best-effort service 462 model (see [RFC7305], Section 3.5). Still, the receiving application 463 would separate the byte stream into 100-byte chunks. 465 Note that this usage of messages does not require all messages to be 466 equal in size. Many application protocols use some form of Type- 467 Length-Value (TLV) encoding, e.g. by defining a header including 468 length fields; another alternative is the use of byte stuffing 469 methods such as COBS [COBS]. If an application needs message 470 numbers, e.g. to restore the correct sequence of messages, these must 471 also be encoded by the application itself, as the sequence number 472 related transport features of SCTP are not provided by the "minimum 473 set" (in the interest of enabling usage of TCP). 475 5.2. Stream Schedulers Without Streams 477 We have already stated that multi-streaming does not require 478 application-specific knowledge. Potential benefits or disadvantages 479 of, e.g., using two streams of an SCTP association versus using two 480 separate SCTP associations or TCP connections are related to 481 knowledge about the network and the particular transport protocol in 482 use, not the application. However, the transport features "Choose a 483 scheduler to operate between streams of an association" and 484 "Configure priority or weight for a scheduler" operate on streams. 485 Here, streams identify communication channels between which a 486 scheduler operates, and they can be assigned a priority. Moreover, 487 the transport features in the MAINTENANCE category all operate on 488 assocations in case of SCTP, i.e. they apply to all streams in that 489 assocation. 491 With only these semantics necessary to represent, the interface to a 492 transport system becomes easier if we assume that connections may be 493 not only a transport protocol's connection or association, but could 494 also be a stream of an existing SCTP association, for example. We 495 only need to allow for a way to define a possible grouping of 496 connections. Then, all MAINTENANCE transport features can be said to 497 operate on connection groups, not connections, and a scheduler 498 operates on the connections within a group. 500 To be compatible with multiple transport protocols and uniformly 501 allow access to both transport connections and streams of a multi- 502 streaming protocol, the semantics of opening and closing need to be 503 the most restrictive subset of all of the underlying options. For 504 example, TCP's support of half-closed connections can be seen as a 505 feature on top of the more restrictive "ABORT"; this feature cannot 506 be supported because not all protocols used by a transport system 507 (including streams of an association) support half-closed 508 connections. 510 5.3. Early Data Transmission 512 There are two transport features related to transferring a message 513 early: "Hand over a message to reliably transfer (possibly multiple 514 times) before connection establishment", which relates to TCP Fast 515 Open [RFC7413], and "Hand over a message to reliably transfer during 516 connection establishment", which relates to SCTP's ability to 517 transfer data together with the COOKIE-Echo chunk. Also without TCP 518 Fast Open, TCP can transfer data during the handshake, together with 519 the SYN packet -- however, the receiver of this data may not hand it 520 over to the application until the handshake has completed. Also, 521 different from TCP Fast Open, this data is not delimited as a message 522 by TCP (thus, not visible as a ``message''). This functionality is 523 commonly available in TCP and supported in several implementations, 524 even though the TCP specification does not explain how to provide it 525 to applications. 527 A transport system could differentiate between the cases of 528 transmitting data "before" (possibly multiple times) or "during" the 529 handshake. Alternatively, it could also assume that data that are 530 handed over early will be transmitted as early as possible, and 531 "before" the handshake would only be used for messages that are 532 explicitly marked as "idempotent" (i.e., it would be acceptable to 533 transfer them multiple times). 535 The amount of data that can successfully be transmitted before or 536 during the handshake depends on various factors: the transport 537 protocol, the use of header options, the choice of IPv4 and IPv6 and 538 the Path MTU. A transport system should therefore allow a sending 539 application to query the maximum amount of data it can possibly 540 transmit before (or, if exposed, during) connection establishment. 542 5.4. Sender Running Dry 544 The transport feature "Notification that the stack has no more user 545 data to send" relates to SCTP's "SENDER DRY" notification. Such 546 notifications can, in principle, be used to avoid having an 547 unnecessarily large send buffer, yet ensure that the transport sender 548 always has data available when it has an opportunity to transmit it. 549 This has been found to be very beneficial for some applications 550 [WWDC2015]. However, "SENDER DRY" truly means that the entire send 551 buffer (including both unsent and unacknowledged data) has emptied -- 552 i.e., when it notifies the sender, it is already too late, the 553 transport protocol already missed an opportunity to send data. Some 554 modern TCP implementations now include the unspecified 555 "TCP_NOTSENT_LOWAT" socket option that was proposed in [WWDC2015], 556 which limits the amount of unsent data that TCP can keep in the 557 socket buffer; this allows to specify at which buffer filling level 558 the socket becomes writable, rather than waiting for the buffer to 559 run empty. 561 SCTP allows to configure the sender-side buffer too: the automatable 562 Transport Feature "Configure send buffer size" provides this 563 functionality, but only for the complete buffer, which includes both 564 unsent and unacknowledged data. SCTP does not allow to control these 565 two sizes separately. It therefore makes sense for a transport 566 system to allow for uniform access to "TCP_NOTSENT_LOWAT" as well as 567 the "SENDER DRY" notification. 569 5.5. Capacity Profile 571 The transport features: 573 o Disable Nagle algorithm 574 o Enable and configure a "Low Extra Delay Background Transfer" 575 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 "Set Cookie life 608 value" as well as "Specifying a key id to be used to authenticate a 609 message". It also excludes security transport features not listed in 610 Appendix A, including content privacy to in-path devices. 612 5.7. Packet Size 614 UDP(-Lite) has a transport feature called "Specify DF field". This 615 yields an error message in case of sending a message that exceeds the 616 Path MTU, which is necessary for a UDP-based application to be able 617 to implement Path MTU Discovery (a function that UDP-based 618 applications must do by themselves). The "Get max. transport-message 619 size that may be sent using a non-fragmented IP packet from the 620 configured interface" transport feature yields an upper limit for the 621 Path MTU (minus headers) and can therefore help to implement Path MTU 622 Discovery more efficiently. 624 6. The Minimal Set of Transport Features 626 Based on the categorization, reduction, and discussion in Section 3, 627 this section describes a minimal set of transport features that end 628 systems should offer. Any configuration based the described minimum 629 set of transport feature can always be realized over TCP but also 630 gives the transport system flexibility to choose another transport if 631 implemented. In the text of this section, "not UDP" is used to 632 indicate elements of the system that cannot be implemented over UDP. 633 Conversely, all elements of the system that are not marked with "not 634 UDP" can also be implemented over UDP. 636 The arguments laid out in Section 5 ("discussion") were used to make 637 the final representation of the minimal set as short, simple and 638 general as possible. There may be situations where these arguments 639 do not apply -- e.g., implementers may have specific reasons to 640 expose multi-streaming as a visible functionality to applications, or 641 the restrictive open / close semantics may be problematic under some 642 circumstances. In such cases, the representation in Section 4 643 ("reduction") should be considered. 645 As in Section 3, Section 4 and [RFC8303], we categorize the minimal 646 set of transport features as 1) CONNECTION related (ESTABLISHMENT, 647 AVAILABILITY, MAINTENANCE, TERMINATION) and 2) DATA Transfer related 648 (Sending Data, Receiving Data, Errors). Here, the focus is on 649 connections that the transport system offers as an abstraction to the 650 application, as opposed to connections of transport protocols that 651 the transport system uses. 653 6.1. ESTABLISHMENT, AVAILABILITY and TERMINATION 655 A connection must first be "created" to allow for some initial 656 configuration to be carried out before the transport system can 657 actively or passively establish communication with a remote end 658 system. As a configuration of the newly created connection, an 659 application can choose to disallow usage of MPTCP. Furthermore, all 660 configuration parameters in Section 6.2 can be used initially, 661 although some of them may only take effect when a connection has been 662 established with a chosen transport protocol. Configuring a 663 connection early helps a transport system make the right decisions. 664 For example, grouping information can influence the transport system 665 to implement a connection as a stream of a multi-streaming protocol's 666 existing association or not. 668 For ungrouped connections, early configuration is necessary because 669 it allows the transport system to know which protocols it should try 670 to use. In particular, a transport system that only makes a one-time 671 choice for a particular protocol must know early about strict 672 requirements that must be kept, or it can end up in a deadlock 673 situation (e.g., having chosen UDP and later be asked to support 674 reliable transfer). As an example description of how to correctly 675 handle these cases, we provide the following decision tree (this is 676 derived from Section 4.1 excluding authentication, as explained in 677 Section 9): 679 - Will it ever be necessary to offer any of the following? 680 * Reliably transfer data 681 * Notify the peer of closing/aborting 682 * Preserve data ordering 684 Yes: SCTP or TCP can be used. 685 - Is any of the following useful to the application? 686 * Choosing a scheduler to operate between connections 687 in a group, with the possibility to configure a priority 688 or weight per connection 689 * Configurable message reliability 690 * Unordered message delivery 691 * Request not to delay the acknowledgement (SACK) of a message 693 Yes: SCTP is preferred. 694 No: 695 - Is any of the following useful to the application? 696 * Hand over a message to reliably transfer (possibly 697 multiple times) before connection establishment 698 * Suggest timeout to the peer 699 * Notification of Excessive Retransmissions (early 700 warning below abortion threshold) 701 * Notification of ICMP error message arrival 703 Yes: TCP is preferred. 704 No: SCTP and TCP are equally preferable. 706 No: all protocols can be used. 707 - Is any of the following useful to the application? 708 * Specify checksum coverage used by the sender 709 * Specify minimum checksum coverage required by receiver 711 Yes: UDP-Lite is preferred. 712 No: UDP is preferred. 714 Note that this decision tree is not optimal for all cases. For 715 example, if an application wants to use "Specify checksum coverage 716 used by the sender", which is only offered by UDP-Lite, and 717 "Configure priority or weight for a scheduler", which is only offered 718 by SCTP, the above decision tree will always choose UDP-Lite, making 719 it impossible to use SCTP's schedulers with priorities between 720 grouped connections. Also, several other factors may influence the 721 decisions for or against a protocol -- e.g. penetration rates, the 722 ability to work through NATs, etc. We caution implementers to be 723 aware of the full set of trade-offs, for which we recommend 724 consulting the list in Section 4.1 when deciding how to initialize a 725 connection. 727 To summarize, the following parameters serve as input for the 728 transport system to help it choose and configure a suitable protocol: 730 o Reliability: a boolean that should be set to true when any of the 731 following will be useful to the application: reliably transfer 732 data; notify the peer of closing/aborting; preserve data ordering. 733 o Checksum coverage: a boolean to specify whether it will be useful 734 to the application to specify checksum coverage when sending or 735 receiving. 736 o Configure message priority: a boolean that should be set to true 737 when any of the following per-message configuration or 738 prioritization mechanisms will be useful to the application: 739 choosing a scheduler to operate between grouped connections, with 740 the possibility to configure a priority or weight per connection; 741 configurable message reliability; unordered message delivery; 742 requesting not to delay the acknowledgement (SACK) of a message. 743 o Early message timeout notifications: a boolean that should be set 744 to true when any of the following will be useful to the 745 application: hand over a message to reliably transfer (possibly 746 multiple times) before connection establishment; suggest timeout 747 to the peer; notification of excessive retransmissions (early 748 warning below abortion threshold); notification of ICMP error 749 message arrival. 751 Once a connection is created, it can be queried for the maximum 752 amount of data that an application can possibly expect to have 753 reliably transmitted before or during transport connection 754 establishment (with zero being a possible answer) (see 755 Section 6.2.1). An application can also give the connection a 756 message for reliable transmission before or during connection 757 establishment (not UDP); the transport system will then try to 758 transmit it as early as possible. An application can facilitate 759 sending a message particularly early by marking it as "idempotent" 760 (see Section 6.3.1); in this case, the receiving application must be 761 prepared to potentially receive multiple copies of the message 762 (because idempotent messages are reliably transferred, asking for 763 idempotence is not necessary for systems that support UDP). 765 After creation, a transport system can actively establish 766 communication with a peer, or it can passively listen for incoming 767 connection requests. Note that active establishment may or may not 768 trigger a notification on the listening side. It is possible that 769 the first notification on the listening side is the arrival of the 770 first data that the active side sends (a receiver-side transport 771 system could handle this by continuing to block a "Listen" call, 772 immediately followed by issuing "Receive", for example; callback- 773 based implementations could simply skip the equivalent of "Listen"). 774 This also means that the active opening side is assumed to be the 775 first side sending data. 777 A transport system can actively close a connection, i.e. terminate it 778 after reliably delivering all remaining data to the peer (if reliable 779 data delivery was requested earlier (not UDP)), in which case the 780 peer is notified that the connection is closed. Alternatively, a 781 connection can be aborted without delivering outstanding data to the 782 peer. In case reliable or partially reliable data delivery was 783 requested earlier (not UDP), the peer is notified that the connection 784 is aborted. A timeout can be configured to abort a connection when 785 data could not be delivered for too long (not UDP); however, timeout- 786 based abortion does not notify the peer application that the 787 connection has been aborted. Because half-closed connections are not 788 supported, when a host implementing a transport system receives a 789 notification that the peer is closing or aborting the connection (not 790 UDP), its peer may not be able to read outstanding data. This means 791 that unacknowledged data residing in a transport system's send buffer 792 may have to be dropped from that buffer upon arrival of a "close" or 793 "abort" notification from the peer. 795 6.2. MAINTENANCE 797 A transport system must offer means to group connections, but it 798 cannot guarantee truly grouping them using the transport protocols 799 that it uses (e.g., it cannot be guaranteed that connections become 800 multiplexed as streams on a single SCTP association when SCTP may not 801 be available). The transport system must therefore ensure that 802 group- versus non-group-configurations are handled correctly in some 803 way (e.g., by applying the configuration to all grouped connections 804 even when they are not multiplexed, or informing the application 805 about grouping success or failure). 807 As a general rule, any configuration described below should be 808 carried out as early as possible to aid the transport system's 809 decision making. 811 6.2.1. Connection groups 813 The following transport features and notifications (some directly 814 from Section 4, some new or changed, based on the discussion in 815 Section 5) automatically apply to all grouped connections: 817 (not UDP) Configure a timeout: this can be done with the following 818 parameters: 820 o A timeout value for aborting connections, in seconds 821 o A timeout value to be suggested to the peer (if possible), in 822 seconds 823 o The number of retransmissions after which the application should 824 be notifed of "Excessive Retransmissions" 826 Configure urgency: this can be done with the following parameters: 828 o A number to identify the type of scheduler that should be used to 829 operate between connections in the group (no guarantees given). 830 Schedulers are defined in [RFC8260]. 831 o A "capacity profile" number to identify how an application wants 832 to use its available capacity. Choices can be "lowest possible 833 latency at the expense of overhead" (which would disable any 834 Nagle-like algorithm), "scavenger", or values that help determine 835 the DSCP value for a connection (e.g. similar to table 1 in 836 [I-D.ietf-tsvwg-rtcweb-qos]). 837 o A buffer limit (in bytes); when the sender has less than the 838 provided limit of bytes in the buffer, the application may be 839 notified. Notifications are not guaranteed, and it is optional 840 for a transport system to support buffer limit values greater than 841 0. Note that this limit and its notification should operate 842 across the buffers of the whole transport system, i.e. also any 843 potential buffers that the transport system itself may use on top 844 of the transport's send buffer. 846 Following Section 5.7, these properties can be queried: 848 o The maximum message size that may be sent without fragmentation 849 via the configured interface. This is optional for a transport 850 system to offer, and may return an error ("not available"). It 851 can aid applications implementing Path MTU Discovery. 852 o The maximum transport message size that can be sent, in bytes. 853 Irrespective of fragmentation, there is a size limit for the 854 messages that can be handed over to SCTP or UDP(-Lite); because 855 the service provided by a transport system is independent of the 856 transport protocol, it must allow an application to query this 857 value -- the maximum size of a message in an Application-Framed- 858 Bytestream (see Section 5.1). This may also return an error when 859 data is not delimited ("not available"). 860 o The maximum transport message size that can be received from the 861 configured interface, in bytes (or "not available"). 862 o The maximum amount of data that can possibly be sent before or 863 during connection establishment, in bytes. 865 In addition to the already mentioned closing / aborting notifications 866 and possible send errors, the following notifications can occur: 868 o Excessive Retransmissions: the configured (or a default) number of 869 retransmissions has been reached, yielding this early warning 870 below an abortion threshold. 871 o ICMP Arrival (parameter: ICMP message): an ICMP packet carrying 872 the conveyed ICMP message has arrived. 873 o ECN Arrival (parameter: ECN value): a packet carrying the conveyed 874 ECN value has arrived. This can be useful for applications 875 implementing congestion control. 876 o Timeout (parameter: s seconds): data could not be delivered for s 877 seconds. 878 o Drain: the send buffer has either drained below the configured 879 buffer limit or it has become completely empty. This is a generic 880 notification that tries to enable uniform access to 881 "TCP_NOTSENT_LOWAT" as well as the "SENDER DRY" notification (as 882 discussed in Section 5.4 -- SCTP's "SENDER DRY" is a special case 883 where the threshold (for unsent data) is 0 and there is also no 884 more unacknowledged data in the send buffer). 886 6.2.2. Individual connections 888 Configure priority or weight for a scheduler, as described in 889 [RFC8260]. 891 Configure checksum usage: this can be done with the following 892 parameters, but there is no guarantee that any checksum limitations 893 will indeed be enforced (the default behavior is "full coverage, 894 checksum enabled"): 896 o A boolean to enable / disable usage of a checksum when sending 897 o The desired coverage (in bytes) of the checksum used when sending 898 o A boolean to enable / disable requiring a checksum when receiving 899 o The required minimum coverage (in bytes) of the checksum when 900 receiving 902 6.3. DATA Transfer 904 6.3.1. Sending Data 906 When sending a message, no guarantees are given about the 907 preservation of message boundaries to the peer; if message boundaries 908 are needed, the receiving application at the peer must know about 909 them beforehand (or the transport system cannot use TCP). Note that 910 an application should already be able to hand over data before the 911 transport system establishes a connection with a chosen transport 912 protocol. Regarding the message that is being handed over, the 913 following parameters can be used: 915 o Reliability: this parameter is used to convey a choice of: fully 916 reliable with congestion control (not UDP), unreliable without 917 congestion control, unreliable with congestion control (not UDP), 918 partially reliable with congestion control (see [RFC3758] and 919 [RFC7496] for details on how to specify partial reliability) (not 920 UDP). The latter two choices are optional for a transport system 921 to offer and may result in full reliability. Note that 922 applications sending unreliable data without congestion control 923 should themselves perform congestion control in accordance with 924 [RFC8085]. 925 o (not UDP) Ordered: this boolean parameter lets an application 926 choose between ordered message delivery (true) and possibly 927 unordered, potentially faster message delivery (false). 928 o Bundle: a boolean that expresses a preference for allowing to 929 bundle messages (true) or not (false). No guarantees are given. 930 o DelAck: a boolean that, if false, lets an application request that 931 the peer would not delay the acknowledgement for this message. 932 o Fragment: a boolean that expresses a preference for allowing to 933 fragment messages (true) or not (false), at the IP level. No 934 guarantees are given. 935 o (not UDP) Idempotent: a boolean that expresses whether a message 936 is idempotent (true) or not (false). Idempotent messages may 937 arrive multiple times at the receiver (but they will arrive at 938 least once). When data is idempotent it can be used by the 939 receiver immediately on a connection establishment attempt. Thus, 940 if data is handed over before the transport system establishes a 941 connection with a chosen transport protocol, stating that a 942 message is idempotent facilitates transmitting it to the peer 943 application particularly early. 945 An application can be notified of a failure to send a specific 946 message. There is no guarantee of such notifications, i.e. send 947 failures can also silently occur. 949 6.3.2. Receiving Data 951 A receiving application obtains an "Application-Framed Bytestream" 952 (AFra-Bytestream); this concept is further described in Section 5.1). 953 In line with TCP's receiver semantics, an AFra-Bytestream is just a 954 stream of bytes to the receiver. If message boundaries were 955 specified by the sender, a receiver-side transport system 956 implementing only the minimum set of transport services defined here 957 will still not inform the receiving application about them (this 958 limitation is only needed for transport systems that are implemented 959 to directly use TCP). 961 Different from TCP's semantics, if the sending application has 962 allowed that messages are not fully reliably transferred, or 963 delivered out of order, then such re-ordering or unreliability may be 964 reflected per message in the arriving data. Messages will always 965 stay intact - i.e. if an incomplete message is contained at the end 966 of the arriving data block, this message is guaranteed to continue in 967 the next arriving data block. 969 7. Acknowledgements 971 The authors would like to thank all the participants of the TAPS 972 Working Group and the NEAT and MAMI research projects for valuable 973 input to this document. We especially thank Michael Tuexen for help 974 with connection connection establishment/teardown, Gorry Fairhurst 975 for his suggestions regarding fragmentation and packet sizes, and 976 Spencer Dawkins for his extremely detailed and constructive review. 977 This work has received funding from the European Union's Horizon 2020 978 research and innovation programme under grant agreement No. 644334 979 (NEAT). 981 8. IANA Considerations 983 This memo includes no request to IANA. 985 9. Security Considerations 987 Authentication, confidentiality protection, and integrity protection 988 are identified as transport features by [RFC8095]. As currently 989 deployed in the Internet, these features are generally provided by a 990 protocol or layer on top of the transport protocol; no current full- 991 featured standards-track transport protocol provides all of these 992 transport features on its own. Therefore, these transport features 993 are not considered in this document, with the exception of native 994 authentication capabilities of TCP and SCTP for which the security 995 considerations in [RFC5925] and [RFC4895] apply. The minimum 996 requirements for a secure transport system are discussed in a 997 separate document (Section 5 on Security Features and Transport 998 Dependencies of [I-D.ietf-taps-transport-security]). 1000 10. References 1002 10.1. Normative References 1004 [I-D.ietf-taps-transport-security] 1005 Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey 1006 of Transport Security Protocols", draft-ietf-taps- 1007 transport-security-02 (work in progress), June 2018. 1009 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 1010 Ed., "Services Provided by IETF Transport Protocols and 1011 Congestion Control Mechanisms", RFC 8095, 1012 DOI 10.17487/RFC8095, March 2017, 1013 . 1015 [RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of 1016 Transport Features Provided by IETF Transport Protocols", 1017 RFC 8303, DOI 10.17487/RFC8303, February 2018, 1018 . 1020 10.2. Informative References 1022 [COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte 1023 Stuffing", IEEE/ACM Transactions on Networking Vol. 7, No. 1024 2, April 1999. 1026 [I-D.ietf-tsvwg-rtcweb-qos] 1027 Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP 1028 Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- 1029 qos-18 (work in progress), August 2016. 1031 [LBE-draft] 1032 Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", 1033 Internet-draft draft-tsvwg-le-phb-03, February 2018. 1035 [POSIX] "IEEE Standard for Information Technology--Portable 1036 Operating System Interface (POSIX(R)) Base Specifications, 1037 Issue 7", IEEE Std 1003.1-2017 (Revision of IEEE Std 1038 1003.1-2008), January 2018, 1039 . 1042 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 1043 Conrad, "Stream Control Transmission Protocol (SCTP) 1044 Partial Reliability Extension", RFC 3758, 1045 DOI 10.17487/RFC3758, May 2004, 1046 . 1048 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 1049 "Authenticated Chunks for the Stream Control Transmission 1050 Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 1051 2007, . 1053 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1054 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 1055 . 1057 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1058 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1059 June 2010, . 1061 [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application 1062 Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, 1063 March 2013, . 1065 [RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet 1066 Technology Adoption and Transition (ITAT)", RFC 7305, 1067 DOI 10.17487/RFC7305, July 2014, 1068 . 1070 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1071 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1072 . 1074 [RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, 1075 "Additional Policies for the Partially Reliable Stream 1076 Control Transmission Protocol Extension", RFC 7496, 1077 DOI 10.17487/RFC7496, April 2015, 1078 . 1080 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1081 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1082 March 2017, . 1084 [RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 1085 "Stream Schedulers and User Message Interleaving for the 1086 Stream Control Transmission Protocol", RFC 8260, 1087 DOI 10.17487/RFC8260, November 2017, 1088 . 1090 [RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the 1091 User Datagram Protocol (UDP) and Lightweight UDP (UDP- 1092 Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018, 1093 . 1095 [SCTP-stream-1] 1096 Weinrank, F. and M. Tuexen, "Transparent Flow Mapping for 1097 NEAT", IFIP NETWORKING Workshop on Future of Internet 1098 Transport (FIT 2017), June 2017. 1100 [SCTP-stream-2] 1101 Welzl, M., Niederbacher, F., and S. Gjessing, "Beneficial 1102 Transparent Deployment of SCTP", IEEE GlobeCom 2011, 1103 December 2011. 1105 [WWDC2015] 1106 Lakhera, P. and S. Cheshire, "Your App and Next Generation 1107 Networks", Apple Worldwide Developers Conference 2015, San 1108 Francisco, USA, June 2015, 1109 . 1111 Appendix A. The Superset of Transport Features 1113 In this description, transport features are presented following the 1114 nomenclature "CATEGORY.[SUBCATEGORY].FEATURENAME.PROTOCOL", 1115 equivalent to "pass 2" in [RFC8303]. We also sketch how functional 1116 or optimizing transport features can be implemented by a transport 1117 system. The "minimal set" derived in this document is meant to be 1118 implementable "one-sided" over TCP, and, with limitations, UDP. 1119 Hence, for all transport features that are categorized as 1120 "functional" or "optimizing", and for which no matching TCP and/or 1121 UDP primitive exists in "pass 2" of [RFC8303], a brief discussion on 1122 how to implement them over TCP and/or UDP is included. 1124 We designate some transport features as "automatable" on the basis of 1125 a broader decision that affects multiple transport features: 1127 o Most transport features that are related to multi-streaming were 1128 designated as "automatable". This was done because the decision 1129 on whether to use multi-streaming or not does not depend on 1130 application-specific knowledge. This means that a connection that 1131 is exhibited to an application could be implemented by using a 1132 single stream of an SCTP association instead of mapping it to a 1133 complete SCTP association or TCP connection. This could be 1134 achieved by using more than one stream when an SCTP association is 1135 first established (CONNECT.SCTP parameter "outbound stream 1136 count"), maintaining an internal stream number, and using this 1137 stream number when sending data (SEND.SCTP parameter "stream 1138 number"). Closing or aborting a connection could then simply free 1139 the stream number for future use. This is discussed further in 1140 Section 5.2. 1141 o With the exception of "Disable MPTCP", all transport features that 1142 are related to using multiple paths or the choice of the network 1143 interface were designated as "automatable". For example, "Listen" 1144 could always listen on all available interfaces and "Connect" 1145 could use the default interface for the destination IP address. 1147 Finally, in three cases, transport features are aggregated and/or 1148 slightly changed from [RFC8303] in the description below. These 1149 transport features are marked as "CHANGED FROM RFC8303". These do 1150 not add any new functionality but just represent a simple refactoring 1151 step that helps to streamline the derivation process (e.g., by 1152 removing a choice of a parameter for the sake of applications that 1153 may not care about this choice). The corresponding transport 1154 features are automatable, and they are listed immediately below the 1155 "CHANGED FROM RFC8303" transport feature. 1157 A.1. CONNECTION Related Transport Features 1159 ESTABLISHMENT: 1161 o Connect 1162 Protocols: TCP, SCTP, UDP(-Lite) 1163 Functional because the notion of a connection is often reflected 1164 in applications as an expectation to be able to communicate after 1165 a "Connect" succeeded, with a communication sequence relating to 1166 this transport feature that is defined by the application 1167 protocol. 1168 Implementation: via CONNECT.TCP, CONNECT.SCTP or CONNECT.UDP(- 1169 Lite). 1171 o Specify which IP Options must always be used 1172 Protocols: TCP, UDP(-Lite) 1173 Automatable because IP Options relate to knowledge about the 1174 network, not the application. 1176 o Request multiple streams 1177 Protocols: SCTP 1178 Automatable because using multi-streaming does not require 1179 application-specific knowledge (example implementations of using 1180 multi-streaming without involving the application are described in 1181 [SCTP-stream-1] and [SCTP-stream-2]). 1183 Implementation: see Section 5.2. 1185 o Limit the number of inbound streams 1186 Protocols: SCTP 1187 Automatable because using multi-streaming does not require 1188 application-specific knowledge. 1189 Implementation: see Section 5.2. 1191 o Specify number of attempts and/or timeout for the first 1192 establishment message 1193 Protocols: TCP, SCTP 1194 Functional because this is closely related to potentially assumed 1195 reliable data delivery for data that is sent before or during 1196 connection establishment. 1197 Implementation: Using a parameter of CONNECT.TCP and CONNECT.SCTP. 1198 Implementation over UDP: Do nothing (this is irrelevant in case of 1199 UDP because there, reliable data delivery is not assumed). 1201 o Obtain multiple sockets 1202 Protocols: SCTP 1203 Automatable because the non-parallel usage of multiple paths to 1204 communicate between the same end hosts relates to knowledge about 1205 the network, not the application. 1207 o Disable MPTCP 1208 Protocols: MPTCP 1209 Optimizing because the parallel usage of multiple paths to 1210 communicate between the same end hosts can improve performance. 1211 Whether to use this feature depends on knowledge about the network 1212 as well as application-specific knowledge (see Section 3.1 of 1213 [RFC6897]). 1214 Implementation: via a boolean parameter in CONNECT.MPTCP. 1215 Implementation over TCP: Do nothing. 1216 Implementation over UDP: Do nothing. 1218 o Configure authentication 1219 Protocols: TCP, SCTP 1220 Functional because this has a direct influence on security. 1221 Implementation: via parameters in CONNECT.TCP and CONNECT.SCTP. 1222 With TCP, this allows to configure Master Key Tuples (MKTs) to 1223 authenticate complete segments (including the TCP IPv4 1224 pseudoheader, TCP header, and TCP data). With SCTP, this allows 1225 to specify which chunk types must always be authenticated. 1226 Authenticating only certain chunk types creates a reduced level of 1227 security that is not supported by TCP; to be compatible, this 1228 should therefore only allow to authenticate all chunk types. Key 1229 material must be provided in a way that is compatible with both 1230 [RFC4895] and [RFC5925]. 1231 Implementation over UDP: Not possible (UDP does not offer this 1232 functionality). 1234 o Indicate (and/or obtain upon completion) an Adaptation Layer via 1235 an adaptation code point 1236 Protocols: SCTP 1237 Functional because it allows to send extra data for the sake of 1238 identifying an adaptation layer, which by itself is application- 1239 specific. 1240 Implementation: via a parameter in CONNECT.SCTP. 1241 Implementation over TCP: not possible (TCP does not offer this 1242 functionality). 1243 Implementation over UDP: not possible (UDP does not offer this 1244 functionality). 1246 o Request to negotiate interleaving of user messages 1247 Protocols: SCTP 1248 Automatable because it requires using multiple streams, but 1249 requesting multiple streams in the CONNECTION.ESTABLISHMENT 1250 category is automatable. 1251 Implementation: controlled via a parameter in CONNECT.SCTP. One 1252 possible implementation is to always try to enable interleaving. 1254 o Hand over a message to reliably transfer (possibly multiple times) 1255 before connection establishment 1256 Protocols: TCP 1257 Functional because this is closely tied to properties of the data 1258 that an application sends or expects to receive. 1259 Implementation: via a parameter in CONNECT.TCP. 1260 Implementation over UDP: not possible (UDP does not provide 1261 reliability). 1263 o Hand over a message to reliably transfer during connection 1264 establishment 1265 Protocols: SCTP 1266 Functional because this can only work if the message is limited in 1267 size, making it closely tied to properties of the data that an 1268 application sends or expects to receive. 1269 Implementation: via a parameter in CONNECT.SCTP. 1270 Implementation over TCP: not possible (TCP does not allow 1271 identification of message boundaries because it provides a byte 1272 stream service) 1273 Implementation over UDP: not possible (UDP is unreliable). 1275 o Enable UDP encapsulation with a specified remote UDP port number 1276 Protocols: SCTP 1277 Automatable because UDP encapsulation relates to knowledge about 1278 the network, not the application. 1280 AVAILABILITY: 1282 o Listen 1283 Protocols: TCP, SCTP, UDP(-Lite) 1284 Functional because the notion of accepting connection requests is 1285 often reflected in applications as an expectation to be able to 1286 communicate after a "Listen" succeeded, with a communication 1287 sequence relating to this transport feature that is defined by the 1288 application protocol. 1289 CHANGED FROM RFC8303. This differs from the 3 automatable 1290 transport features below in that it leaves the choice of 1291 interfaces for listening open. 1292 Implementation: by listening on all interfaces via LISTEN.TCP (not 1293 providing a local IP address) or LISTEN.SCTP (providing SCTP port 1294 number / address pairs for all local IP addresses). LISTEN.UDP(- 1295 Lite) supports both methods. 1297 o Listen, 1 specified local interface 1298 Protocols: TCP, SCTP, UDP(-Lite) 1299 Automatable because decisions about local interfaces relate to 1300 knowledge about the network and the Operating System, not the 1301 application. 1303 o Listen, N specified local interfaces 1304 Protocols: SCTP 1305 Automatable because decisions about local interfaces relate to 1306 knowledge about the network and the Operating System, not the 1307 application. 1309 o Listen, all local interfaces 1310 Protocols: TCP, SCTP, UDP(-Lite) 1311 Automatable because decisions about local interfaces relate to 1312 knowledge about the network and the Operating System, not the 1313 application. 1315 o Specify which IP Options must always be used 1316 Protocols: TCP, UDP(-Lite) 1317 Automatable because IP Options relate to knowledge about the 1318 network, not the application. 1320 o Disable MPTCP 1321 Protocols: MPTCP 1322 Optimizing because the parallel usage of multiple paths to 1323 communicate between the same end hosts can improve performance. 1324 Whether to use this feature depends on knowledge about the network 1325 as well as application-specific knowledge (see Section 3.1 of 1326 [RFC6897]). 1327 Implementation: via a boolean parameter in LISTEN.MPTCP. 1328 Implementation over TCP: Do nothing. 1329 Implementation over UDP: Do nothing. 1331 o Configure authentication 1332 Protocols: TCP, SCTP 1333 Functional because this has a direct influence on security. 1334 Implementation: via parameters in LISTEN.TCP and LISTEN.SCTP. 1335 Implementation over TCP: With TCP, this allows to configure Master 1336 Key Tuples (MKTs) to authenticate complete segments (including the 1337 TCP IPv4 pseudoheader, TCP header, and TCP data). With SCTP, this 1338 allows to specify which chunk types must always be authenticated. 1339 Authenticating only certain chunk types creates a reduced level of 1340 security that is not supported by TCP; to be compatible, this 1341 should therefore only allow to authenticate all chunk types. Key 1342 material must be provided in a way that is compatible with both 1343 [RFC4895] and [RFC5925]. 1344 Implementation over UDP: not possible (UDP does not offer 1345 authentication). 1347 o Obtain requested number of streams 1348 Protocols: SCTP 1349 Automatable because using multi-streaming does not require 1350 application-specific knowledge. 1351 Implementation: see Section 5.2. 1353 o Limit the number of inbound streams 1354 Protocols: SCTP 1355 Automatable because using multi-streaming does not require 1356 application-specific knowledge. 1357 Implementation: see Section 5.2. 1359 o Indicate (and/or obtain upon completion) an Adaptation Layer via 1360 an adaptation code point 1361 Protocols: SCTP 1362 Functional because it allows to send extra data for the sake of 1363 identifying an adaptation layer, which by itself is application- 1364 specific. 1365 Implementation: via a parameter in LISTEN.SCTP. 1366 Implementation over TCP: not possible (TCP does not offer this 1367 functionality). 1368 Implementation over UDP: not possible (UDP does not offer this 1369 functionality). 1371 o Request to negotiate interleaving of user messages 1372 Protocols: SCTP 1373 Automatable because it requires using multiple streams, but 1374 requesting multiple streams in the CONNECTION.ESTABLISHMENT 1375 category is automatable. 1376 Implementation: via a parameter in LISTEN.SCTP. 1378 MAINTENANCE: 1380 o Change timeout for aborting connection (using retransmit limit or 1381 time value) 1382 Protocols: TCP, SCTP 1383 Functional because this is closely related to potentially assumed 1384 reliable data delivery. 1385 Implementation: via CHANGE_TIMEOUT.TCP or CHANGE_TIMEOUT.SCTP. 1386 Implementation over UDP: not possible (UDP is unreliable and there 1387 is no connection timeout). 1389 o Suggest timeout to the peer 1390 Protocols: TCP 1391 Functional because this is closely related to potentially assumed 1392 reliable data delivery. 1393 Implementation: via CHANGE_TIMEOUT.TCP. 1394 Implementation over UDP: not possible (UDP is unreliable and there 1395 is no connection timeout). 1397 o Disable Nagle algorithm 1398 Protocols: TCP, SCTP 1399 Optimizing because this decision depends on knowledge about the 1400 size of future data blocks and the delay between them. 1401 Implementation: via DISABLE_NAGLE.TCP and DISABLE_NAGLE.SCTP. 1402 Implementation over UDP: do nothing (UDP does not implement the 1403 Nagle algorithm). 1405 o Request an immediate heartbeat, returning success/failure 1406 Protocols: SCTP 1407 Automatable because this informs about network-specific knowledge. 1409 o Notification of Excessive Retransmissions (early warning below 1410 abortion threshold) 1411 Protocols: TCP 1412 Optimizing because it is an early warning to the application, 1413 informing it of an impending functional event. 1414 Implementation: via ERROR.TCP. 1415 Implementation over UDP: do nothing (there is no abortion 1416 threshold). 1418 o Add path 1419 Protocols: MPTCP, SCTP 1420 MPTCP Parameters: source-IP; source-Port; destination-IP; 1421 destination-Port 1422 SCTP Parameters: local IP address 1423 Automatable because the choice of paths to communicate between the 1424 same end hosts relates to knowledge about the network, not the 1425 application. 1427 o Remove path 1428 Protocols: MPTCP, SCTP 1429 MPTCP Parameters: source-IP; source-Port; destination-IP; 1430 destination-Port 1431 SCTP Parameters: local IP address 1432 Automatable because the choice of paths to communicate between the 1433 same end host relates to knowledge about the network, not the 1434 application. 1436 o Set primary path 1437 Protocols: SCTP 1438 Automatable because the choice of paths to communicate between the 1439 same end hosts relates to knowledge about the network, not the 1440 application. 1442 o Suggest primary path to the peer 1443 Protocols: SCTP 1444 Automatable because the choice of paths to communicate between the 1445 same end hosts relates to knowledge about the network, not the 1446 application. 1448 o Configure Path Switchover 1449 Protocols: SCTP 1450 Automatable because the choice of paths to communicate between the 1451 same end hosts relates to knowledge about the network, not the 1452 application. 1454 o Obtain status (query or notification) 1455 Protocols: SCTP, MPTCP 1456 SCTP parameters: association connection state; destination 1457 transport address list; destination transport address reachability 1458 states; current local and peer receiver window size; current local 1459 congestion window sizes; number of unacknowledged DATA chunks; 1460 number of DATA chunks pending receipt; primary path; most recent 1461 SRTT on primary path; RTO on primary path; SRTT and RTO on other 1462 destination addresses; MTU per path; interleaving supported yes/no 1463 MPTCP parameters: subflow-list (identified by source-IP; source- 1464 Port; destination-IP; destination-Port) 1465 Automatable because these parameters relate to knowledge about the 1466 network, not the application. 1468 o Specify DSCP field 1469 Protocols: TCP, SCTP, UDP(-Lite) 1470 Optimizing because choosing a suitable DSCP value requires 1471 application-specific knowledge. 1472 Implementation: via SET_DSCP.TCP / SET_DSCP.SCTP / SET_DSCP.UDP(- 1473 Lite) 1475 o Notification of ICMP error message arrival 1476 Protocols: TCP, UDP(-Lite) 1477 Optimizing because these messages can inform about success or 1478 failure of functional transport features (e.g., host unreachable 1479 relates to "Connect") 1480 Implementation: via ERROR.TCP or ERROR.UDP(-Lite). 1482 o Obtain information about interleaving support 1483 Protocols: SCTP 1484 Automatable because it requires using multiple streams, but 1485 requesting multiple streams in the CONNECTION.ESTABLISHMENT 1486 category is automatable. 1487 Implementation: via STATUS.SCTP. 1489 o Change authentication parameters 1490 Protocols: TCP, SCTP 1491 Functional because this has a direct influence on security. 1492 Implementation: via SET_AUTH.TCP and SET_AUTH.SCTP. 1493 Implementation over TCP: With SCTP, this allows to adjust key_id, 1494 key, and hmac_id. With TCP, this allows to change the preferred 1495 outgoing MKT (current_key) and the preferred incoming MKT 1496 (rnext_key), respectively, for a segment that is sent on the 1497 connection. Key material must be provided in a way that is 1498 compatible with both [RFC4895] and [RFC5925]. 1499 Implementation over UDP: not possible (UDP does not offer 1500 authentication). 1502 o Obtain authentication information 1503 Protocols: SCTP 1504 Functional because authentication decisions may have been made by 1505 the peer, and this has an influence on the necessary application- 1506 level measures to provide a certain level of security. 1507 Implementation: via GET_AUTH.SCTP. 1509 Implementation over TCP: With SCTP, this allows to obtain key_id 1510 and a chunk list. With TCP, this allows to obtain current_key and 1511 rnext_key from a previously received segment. Key material must 1512 be provided in a way that is compatible with both [RFC4895] and 1513 [RFC5925]. 1514 Implementation over UDP: not possible (UDP does not offer 1515 authentication). 1517 o Reset Stream 1518 Protocols: SCTP 1519 Automatable because using multi-streaming does not require 1520 application-specific knowledge. 1521 Implementation: see Section 5.2. 1523 o Notification of Stream Reset 1524 Protocols: STCP 1525 Automatable because using multi-streaming does not require 1526 application-specific knowledge. 1527 Implementation: see Section 5.2. 1529 o Reset Association 1530 Protocols: SCTP 1531 Automatable because deciding to reset an association does not 1532 require application-specific knowledge. 1533 Implementation: via RESET_ASSOC.SCTP. 1535 o Notification of Association Reset 1536 Protocols: STCP 1537 Automatable because this notification does not relate to 1538 application-specific knowledge. 1540 o Add Streams 1541 Protocols: SCTP 1542 Automatable because using multi-streaming does not require 1543 application-specific knowledge. 1544 Implementation: see Section 5.2. 1546 o Notification of Added Stream 1547 Protocols: STCP 1548 Automatable because using multi-streaming does not require 1549 application-specific knowledge. 1550 Implementation: see Section 5.2. 1552 o Choose a scheduler to operate between streams of an association 1553 Protocols: SCTP 1554 Optimizing because the scheduling decision requires application- 1555 specific knowledge. However, if a transport system would not use 1556 this, or wrongly configure it on its own, this would only affect 1557 the performance of data transfers; the outcome would still be 1558 correct within the "best effort" service model. 1559 Implementation: using SET_STREAM_SCHEDULER.SCTP. 1560 Implementation over TCP: do nothing (streams are not available in 1561 TCP, but no guarantee is given that this transport feature has any 1562 effect). 1563 Implementation over UDP: do nothing (streams are not available in 1564 UDP, but no guarantee is given that this transport feature has any 1565 effect). 1567 o Configure priority or weight for a scheduler 1568 Protocols: SCTP 1569 Optimizing because the priority or weight requires application- 1570 specific knowledge. However, if a transport system would not use 1571 this, or wrongly configure it on its own, this would only affect 1572 the performance of data transfers; the outcome would still be 1573 correct within the "best effort" service model. 1574 Implementation: using CONFIGURE_STREAM_SCHEDULER.SCTP. 1575 Implementation over TCP: do nothing (streams are not available in 1576 TCP, but no guarantee is given that this transport feature has any 1577 effect). 1578 Implementation over UDP: do nothing (streams are not available in 1579 UDP, but no guarantee is given that this transport feature has any 1580 effect). 1582 o Configure send buffer size 1583 Protocols: SCTP 1584 Automatable because this decision relates to knowledge about the 1585 network and the Operating System, not the application (see also 1586 the discussion in Section 5.4). 1588 o Configure receive buffer (and rwnd) size 1589 Protocols: SCTP 1590 Automatable because this decision relates to knowledge about the 1591 network and the Operating System, not the application. 1593 o Configure message fragmentation 1594 Protocols: SCTP 1595 Automatable because this relates to knowledge about the network 1596 and the Operating System, not the application. Note that this 1597 SCTP feature does not control IP-level fragmentation, but decides 1598 on fragmentation of messages by SCTP, in the end system. 1599 Implementation: by always enabling it with 1600 CONFIG_FRAGMENTATION.SCTP and auto-setting the fragmentation size 1601 based on network or Operating System conditions. 1603 o Configure PMTUD 1604 Protocols: SCTP 1605 Automatable because Path MTU Discovery relates to knowledge about 1606 the network, not the application. 1608 o Configure delayed SACK timer 1609 Protocols: SCTP 1610 Automatable because the receiver-side decision to delay sending 1611 SACKs relates to knowledge about the network, not the application 1612 (it can be relevant for a sending application to request not to 1613 delay the SACK of a message, but this is a different transport 1614 feature). 1616 o Set Cookie life value 1617 Protocols: SCTP 1618 Functional because it relates to security (possibly weakened by 1619 keeping a cookie very long) versus the time between connection 1620 establishment attempts. Knowledge about both issues can be 1621 application-specific. 1622 Implementation over TCP: the closest specified TCP functionality 1623 is the cookie in TCP Fast Open; for this, [RFC7413] states that 1624 the server "can expire the cookie at any time to enhance security" 1625 and section 4.1.2 describes an example implementation where 1626 updating the key on the server side causes the cookie to expire. 1627 Alternatively, for implementations that do not support TCP Fast 1628 Open, this transport feature could also affect the validity of SYN 1629 cookies (see Section 3.6 of [RFC4987]). 1630 Implementation over UDP: not possible (UDP does not offer this 1631 functionality). 1633 o Set maximum burst 1634 Protocols: SCTP 1635 Automatable because it relates to knowledge about the network, not 1636 the application. 1638 o Configure size where messages are broken up for partial delivery 1639 Protocols: SCTP 1640 Functional because this is closely tied to properties of the data 1641 that an application sends or expects to receive. 1642 Implementation over TCP: not possible (TCP does not offer 1643 identification of message boundaries). 1644 Implementation over UDP: not possible (UDP does not fragment 1645 messages). 1647 o Disable checksum when sending 1648 Protocols: UDP 1649 Functional because application-specific knowledge is necessary to 1650 decide whether it can be acceptable to lose data integrity with 1651 respect to random corruption. 1652 Implementation: via SET_CHECKSUM_ENABLED.UDP. 1653 Implementation over TCP: do nothing (TCP does not offer to disable 1654 the checksum, but transmitting data with an intact checksum will 1655 not yield a semantically wrong result). 1657 o Disable checksum requirement when receiving 1658 Protocols: UDP 1659 Functional because application-specific knowledge is necessary to 1660 decide whether it can be acceptable to lose data integrity with 1661 respect to random corruption. 1662 Implementation: via SET_CHECKSUM_REQUIRED.UDP. 1663 Implementation over TCP: do nothing (TCP does not offer to disable 1664 the checksum, but transmitting data with an intact checksum will 1665 not yield a semantically wrong result). 1667 o Specify checksum coverage used by the sender 1668 Protocols: UDP-Lite 1669 Functional because application-specific knowledge is necessary to 1670 decide for which parts of the data it can be acceptable to lose 1671 data integrity with respect to random corruption. 1672 Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite. 1673 Implementation over TCP: do nothing (TCP does not offer to limit 1674 the checksum length, but transmitting data with an intact checksum 1675 will not yield a semantically wrong result). 1676 Implementation over UDP: if checksum coverage is set to cover 1677 payload data, do nothing. Else, either do nothing (transmitting 1678 data with an intact checksum will not yield a semantically wrong 1679 result), or use the transport feature "Disable checksum when 1680 sending". 1682 o Specify minimum checksum coverage required by receiver 1683 Protocols: UDP-Lite 1684 Functional because application-specific knowledge is necessary to 1685 decide for which parts of the data it can be acceptable to lose 1686 data integrity with respect to random corruption. 1687 Implementation: via SET_MIN_CHECKSUM_COVERAGE.UDP-Lite. 1688 Implementation over TCP: do nothing (TCP does not offer to limit 1689 the checksum length, but transmitting data with an intact checksum 1690 will not yield a semantically wrong result). 1691 Implementation over UDP: if checksum coverage is set to cover 1692 payload data, do nothing. Else, either do nothing (transmitting 1693 data with an intact checksum will not yield a semantically wrong 1694 result), or use the transport feature "Disable checksum 1695 requirement when receiving". 1697 o Specify DF field 1698 Protocols: UDP(-Lite) 1699 Optimizing because the DF field can be used to carry out Path MTU 1700 Discovery, which can lead an application to choose message sizes 1701 that can be transmitted more efficiently. 1702 Implementation: via MAINTENANCE.SET_DF.UDP(-Lite) and 1703 SEND_FAILURE.UDP(-Lite). 1704 Implementation over TCP: do nothing (with TCP, the sending 1705 application is not in control of transport message sizes, making 1706 this functionality irrelevant). 1708 o Get max. transport-message size that may be sent using a non- 1709 fragmented IP packet from the configured interface 1710 Protocols: UDP(-Lite) 1711 Optimizing because this can lead an application to choose message 1712 sizes that can be transmitted more efficiently. 1714 Implementation over TCP: do nothing (this information is not 1715 available with TCP). 1717 o Get max. transport-message size that may be received from the 1718 configured interface 1719 Protocols: UDP(-Lite) 1720 Optimizing because this can, for example, influence an 1721 application's memory management. 1722 Implementation over TCP: do nothing (this information is not 1723 available with TCP). 1725 o Specify TTL/Hop count field 1726 Protocols: UDP(-Lite) 1727 Automatable because a transport system can use a large enough 1728 system default to avoid communication failures. Allowing an 1729 application to configure it differently can produce notifications 1730 of ICMP error message arrivals that yield information which only 1731 relates to knowledge about the network, not the application. 1733 o Obtain TTL/Hop count field 1734 Protocols: UDP(-Lite) 1735 Automatable because the TTL/Hop count field relates to knowledge 1736 about the network, not the application. 1738 o Specify ECN field 1739 Protocols: UDP(-Lite) 1740 Automatable because the ECN field relates to knowledge about the 1741 network, not the application. 1743 o Obtain ECN field 1744 Protocols: UDP(-Lite) 1745 Optimizing because this information can be used by an application 1746 to better carry out congestion control (this is relevant when 1747 choosing a data transmission transport service that does not 1748 already do congestion control). 1749 Implementation over TCP: do nothing (this information is not 1750 available with TCP). 1752 o Specify IP Options 1753 Protocols: UDP(-Lite) 1754 Automatable because IP Options relate to knowledge about the 1755 network, not the application. 1757 o Obtain IP Options 1758 Protocols: UDP(-Lite) 1759 Automatable because IP Options relate to knowledge about the 1760 network, not the application. 1762 o Enable and configure a "Low Extra Delay Background Transfer" 1763 Protocols: A protocol implementing the LEDBAT congestion control 1764 mechanism 1765 Optimizing because whether this feature is appropriate or not 1766 depends on application-specific knowledge. However, wrongly using 1767 this will only affect the speed of data transfers (albeit 1768 including other transfers that may compete with the transport 1769 system's transfer in the network), so it is still correct within 1770 the "best effort" service model. 1771 Implementation: via CONFIGURE.LEDBAT and/or SET_DSCP.TCP / 1772 SET_DSCP.SCTP / SET_DSCP.UDP(-Lite) [LBE-draft]. 1773 Implementation over TCP: do nothing (TCP does not support LEDBAT 1774 congestion control, but not implementing this functionality will 1775 not yield a semantically wrong behavior). 1776 Implementation over UDP: do nothing (UDP does not offer congestion 1777 control). 1779 TERMINATION: 1781 o Close after reliably delivering all remaining data, causing an 1782 event informing the application on the other side 1783 Protocols: TCP, SCTP 1784 Functional because the notion of a connection is often reflected 1785 in applications as an expectation to have all outstanding data 1786 delivered and no longer be able to communicate after a "Close" 1787 succeeded, with a communication sequence relating to this 1788 transport feature that is defined by the application protocol. 1789 Implementation: via CLOSE.TCP and CLOSE.SCTP. 1790 Implementation over UDP: not possible (UDP is unreliable and hence 1791 does not know when all remaining data is delivered; it does also 1792 not offer to cause an event related to closing at the peer). 1794 o Abort without delivering remaining data, causing an event 1795 informing the application on the other side 1796 Protocols: TCP, SCTP 1797 Functional because the notion of a connection is often reflected 1798 in applications as an expectation to potentially not have all 1799 outstanding data delivered and no longer be able to communicate 1800 after an "Abort" succeeded. On both sides of a connection, an 1801 application protocol may define a communication sequence relating 1802 to this transport feature. 1803 Implementation: via ABORT.TCP and ABORT.SCTP. 1804 Implementation over UDP: not possible (UDP does not offer to cause 1805 an event related to aborting at the peer). 1807 o Abort without delivering remaining data, not causing an event 1808 informing the application on the other side 1809 Protocols: UDP(-Lite) 1810 Functional because the notion of a connection is often reflected 1811 in applications as an expectation to potentially not have all 1812 outstanding data delivered and no longer be able to communicate 1813 after an "Abort" succeeded. On both sides of a connection, an 1814 application protocol may define a communication sequence relating 1815 to this transport feature. 1816 Implementation: via ABORT.UDP(-Lite). 1817 Implementation over TCP: stop using the connection, wait for a 1818 timeout. 1820 o Timeout event when data could not be delivered for too long 1821 Protocols: TCP, SCTP 1822 Functional because this notifies that potentially assumed reliable 1823 data delivery is no longer provided. 1824 Implementation: via TIMEOUT.TCP and TIMEOUT.SCTP. 1825 Implementation over UDP: do nothing (this event will not occur 1826 with UDP). 1828 A.2. DATA Transfer Related Transport Features 1830 A.2.1. Sending Data 1832 o Reliably transfer data, with congestion control 1833 Protocols: TCP, SCTP 1834 Functional because this is closely tied to properties of the data 1835 that an application sends or expects to receive. 1836 Implementation: via SEND.TCP and SEND.SCTP. 1837 Implementation over UDP: not possible (UDP is unreliable). 1839 o Reliably transfer a message, with congestion control 1840 Protocols: SCTP 1841 Functional because this is closely tied to properties of the data 1842 that an application sends or expects to receive. 1843 Implementation: via SEND.SCTP. 1844 Implementation over TCP: via SEND.TCP. With SEND.TCP, message 1845 boundaries will not be identifiable by the receiver, because TCP 1846 provides a byte stream service. 1847 Implementation over UDP: not possible (UDP is unreliable). 1849 o Unreliably transfer a message 1850 Protocols: SCTP, UDP(-Lite) 1851 Optimizing because only applications know about the time 1852 criticality of their communication, and reliably transfering a 1853 message is never incorrect for the receiver of a potentially 1854 unreliable data transfer, it is just slower. 1855 CHANGED FROM RFC8303. This differs from the 2 automatable 1856 transport features below in that it leaves the choice of 1857 congestion control open. 1858 Implementation: via SEND.SCTP or SEND.UDP(-Lite). 1859 Implementation over TCP: use SEND.TCP. With SEND.TCP, messages 1860 will be sent reliably, and message boundaries will not be 1861 identifiable by the receiver. 1863 o Unreliably transfer a message, with congestion control 1864 Protocols: SCTP 1865 Automatable because congestion control relates to knowledge about 1866 the network, not the application. 1868 o Unreliably transfer a message, without congestion control 1869 Protocols: UDP(-Lite) 1870 Automatable because congestion control relates to knowledge about 1871 the network, not the application. 1873 o Configurable Message Reliability 1874 Protocols: SCTP 1875 Optimizing because only applications know about the time 1876 criticality of their communication, and reliably transfering a 1877 message is never incorrect for the receiver of a potentially 1878 unreliable data transfer, it is just slower. 1879 Implementation: via SEND.SCTP. 1880 Implementation over TCP: By using SEND.TCP and ignoring this 1881 configuration: based on the assumption of the best-effort service 1882 model, unnecessarily delivering data does not violate application 1883 expectations. Moreover, it is not possible to associate the 1884 requested reliability to a "message" in TCP anyway. 1885 Implementation over UDP: not possible (UDP is unreliable). 1887 o Choice of stream 1888 Protocols: SCTP 1889 Automatable because it requires using multiple streams, but 1890 requesting multiple streams in the CONNECTION.ESTABLISHMENT 1891 category is automatable. Implementation: see Section 5.2. 1893 o Choice of path (destination address) 1894 Protocols: SCTP 1895 Automatable because it requires using multiple sockets, but 1896 obtaining multiple sockets in the CONNECTION.ESTABLISHMENT 1897 category is automatable. 1899 o Ordered message delivery (potentially slower than unordered) 1900 Protocols: SCTP 1901 Functional because this is closely tied to properties of the data 1902 that an application sends or expects to receive. 1903 Implementation: via SEND.SCTP. 1904 Implementation over TCP: By using SEND.TCP. With SEND.TCP, 1905 messages will not be identifiable by the receiver. 1906 Implementation over UDP: not possible (UDP does not offer any 1907 guarantees regarding ordering). 1909 o Unordered message delivery (potentially faster than ordered) 1910 Protocols: SCTP, UDP(-Lite) 1911 Functional because this is closely tied to properties of the data 1912 that an application sends or expects to receive. 1913 Implementation: via SEND.SCTP. 1915 Implementation over TCP: By using SEND.TCP and always sending data 1916 ordered: based on the assumption of the best-effort service model, 1917 ordered delivery may just be slower and does not violate 1918 application expectations. Moreover, it is not possible to 1919 associate the requested delivery order to a "message" in TCP 1920 anyway. 1922 o Request not to bundle messages 1923 Protocols: SCTP 1924 Optimizing because this decision depends on knowledge about the 1925 size of future data blocks and the delay between them. 1926 Implementation: via SEND.SCTP. 1927 Implementation over TCP: By using SEND.TCP and DISABLE_NAGLE.TCP 1928 to disable the Nagle algorithm when the request is made and enable 1929 it again when the request is no longer made. Note that this is 1930 not fully equivalent because it relates to the time of issuing the 1931 request rather than a specific message. 1932 Implementation over UDP: do nothing (UDP never bundles messages). 1934 o Specifying a "payload protocol-id" (handed over as such by the 1935 receiver) 1936 Protocols: SCTP 1937 Functional because it allows to send extra application data with 1938 every message, for the sake of identification of data, which by 1939 itself is application-specific. 1940 Implementation: SEND.SCTP. 1941 Implementation over TCP: not possible (this functionality is not 1942 available in TCP). 1943 Implementation over UDP: not possible (this functionality is not 1944 available in UDP). 1946 o Specifying a key id to be used to authenticate a message 1947 Protocols: SCTP 1948 Functional because this has a direct influence on security. 1949 Implementation: via a parameter in SEND.SCTP. 1950 Implementation over TCP: This could be emulated by using 1951 SET_AUTH.TCP before and after the message is sent. Note that this 1952 is not fully equivalent because it relates to the time of issuing 1953 the request rather than a specific message. 1954 Implementation over UDP: not possible (UDP does not offer 1955 authentication). 1957 o Request not to delay the acknowledgement (SACK) of a message 1958 Protocols: SCTP 1959 Optimizing because only an application knows for which message it 1960 wants to quickly be informed about success / failure of its 1961 delivery. 1962 Implementation over TCP: do nothing (TCP does not offer this 1963 functionality, but ignoring this request from the application will 1964 not yield a semantically wrong behavior). 1965 Implementation over UDP: do nothing (UDP does not offer this 1966 functionality, but ignoring this request from the application will 1967 not yield a semantically wrong behavior). 1969 A.2.2. Receiving Data 1971 o Receive data (with no message delimiting) 1972 Protocols: TCP 1973 Functional because a transport system must be able to send and 1974 receive data. 1975 Implementation: via RECEIVE.TCP. 1976 Implementation over UDP: do nothing (UDP only works on messages; 1977 these can be handed over, the application can still ignore the 1978 message boundaries). 1980 o Receive a message 1981 Protocols: SCTP, UDP(-Lite) 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 and RECEIVE.UDP(-Lite). 1985 Implementation over TCP: not possible (TCP does not support 1986 identification of message boundaries). 1988 o Choice of stream to receive from 1989 Protocols: SCTP 1990 Automatable because it requires using multiple streams, but 1991 requesting multiple streams in the CONNECTION.ESTABLISHMENT 1992 category is automatable. 1993 Implementation: see Section 5.2. 1995 o Information about partial message arrival 1996 Protocols: SCTP 1997 Functional because this is closely tied to properties of the data 1998 that an application sends or expects to receive. 1999 Implementation: via RECEIVE.SCTP. 2000 Implementation over TCP: do nothing (this information is not 2001 available with TCP). 2002 Implementation over UDP: do nothing (this information is not 2003 available with UDP). 2005 A.2.3. Errors 2007 This section describes sending failures that are associated with a 2008 specific call to in the "Sending Data" category (Appendix A.2.1). 2010 o Notification of send failures 2011 Protocols: SCTP, UDP(-Lite) 2012 Functional because this notifies that potentially assumed reliable 2013 data delivery is no longer provided. 2014 CHANGED FROM RFC8303. This differs from the 2 automatable 2015 transport features below in that it does not distinugish between 2016 unsent and unacknowledged messages. 2017 Implementation: via SENDFAILURE-EVENT.SCTP and SEND_FAILURE.UDP(- 2018 Lite). 2019 Implementation over TCP: do nothing (this notification is not 2020 available and will therefore not occur with TCP). 2022 o Notification of an unsent (part of a) message 2023 Protocols: SCTP, UDP(-Lite) 2024 Automatable because the distinction between unsent and 2025 unacknowledged does not relate to application-specific knowledge. 2027 o Notification of an unacknowledged (part of a) message 2028 Protocols: SCTP 2029 Automatable because the distinction between unsent and 2030 unacknowledged does not relate to application-specific knowledge. 2032 o Notification that the stack has no more user data to send 2033 Protocols: SCTP 2034 Optimizing because reacting to this notification requires the 2035 application to be involved, and ensuring that the stack does not 2036 run dry of data (for too long) can improve performance. 2037 Implementation over TCP: do nothing (see the discussion in 2038 Section 5.4). 2039 Implementation over UDP: do nothing (this notification is not 2040 available and will therefore not occur with UDP). 2042 o Notification to a receiver that a partial message delivery has 2043 been aborted 2044 Protocols: SCTP 2045 Functional because this is closely tied to properties of the data 2046 that an application sends or expects to receive. 2047 Implementation over TCP: do nothing (this notification is not 2048 available and will therefore not occur with TCP). 2049 Implementation over UDP: do nothing (this notification is not 2050 available and will therefore not occur with UDP). 2052 Appendix B. Revision information 2054 XXX RFC-Ed please remove this section prior to publication. 2056 -02: implementation suggestions added, discussion section added, 2057 terminology extended, DELETED category removed, various other fixes; 2058 list of Transport Features adjusted to -01 version of [RFC8303] 2059 except that MPTCP is not included. 2061 -03: updated to be consistent with -02 version of [RFC8303]. 2063 -04: updated to be consistent with -03 version of [RFC8303]. 2064 Reorganized document, rewrote intro and conclusion, and made a first 2065 stab at creating a real "minimal set". 2067 -05: updated to be consistent with -05 version of [RFC8303] (minor 2068 changes). Fixed a mistake regarding Cookie Life value. Exclusion of 2069 security related transport features (to be covered in a separate 2070 document). Reorganized the document (now begins with the minset, 2071 derivation is in the appendix). First stab at an abstract API for 2072 the minset. 2074 draft-ietf-taps-minset-00: updated to be consistent with -08 version 2075 of [RFC8303] ("obtain message delivery number" was removed, as this 2076 has also been removed in [RFC8303] because it was a mistake in 2077 RFC4960. This led to the removal of two more transport features that 2078 were only designated as functional because they affected "obtain 2079 message delivery number"). Fall-back to UDP incorporated (this was 2080 requested at IETF-99); this also affected the transport feature 2081 "Choice between unordered (potentially faster) or ordered delivery of 2082 messages" because this is a boolean which is always true for one 2083 fall-back protocol, and always false for the other one. This was 2084 therefore now divided into two features, one for ordered, one for 2085 unordered delivery. The word "reliably" was added to the transport 2086 features "Hand over a message to reliably transfer (possibly multiple 2087 times) before connection establishment" and "Hand over a message to 2088 reliably transfer during connection establishment" to make it clearer 2089 why this is not supported by UDP. Clarified that the "minset 2090 abstract interface" is not proposing a specific API for all TAPS 2091 systems to implement, but it is just a way to describe the minimum 2092 set. Author order changed. 2094 WG -01: "fall-back to" (TCP or UDP) replaced (mostly with 2095 "implementation over"). References to post-sockets removed (these 2096 were statments that assumed that post-sockets requires two-sided 2097 implementation). Replaced "flow" with "TAPS Connection" and "frame" 2098 with "message" to avoid introducing new terminology. Made sections 3 2099 and 4 in line with the categorization that is already used in the 2100 appendix and [RFC8303], and changed style of section 4 to be even 2101 shorter and less interface-like. Updated reference draft-ietf-tsvwg- 2102 sctp-ndata to RFC8260. 2104 WG -02: rephrased "the TAPS system" and "TAPS connection" etc. to 2105 more generally talk about transport after the intro (mostly replacing 2106 "TAPS system" with "transport system" and "TAPS connection" with 2107 "connection". Merged sections 3 and 4 to form a new section 3. 2109 WG -03: updated sentence referencing 2110 [I-D.ietf-taps-transport-security] to say that "the minimum security 2111 requirements for a taps system are discussed in a separate security 2112 document", wrote "example" in the paragraph introducing the decision 2113 tree. Removed reference draft-grinnemo-taps-he-03 and the sentence 2114 that referred to it. 2116 WG -04: addressed comments from Theresa Enghardt and Tommy Pauly. As 2117 part of that, removed "TAPS" as a term everywhere (abstract, intro, 2118 ..). 2120 WG -05: addressed comments from Spencer Dawkins. 2122 WG -06: Fixed nits. 2124 WG -07: Addressed Genart comments from Robert Sparks. 2126 WG -08: Addressed one more Genart comment from Robert Sparks. 2128 WG -09: Addressed comments from Mirja Kuehlewind, Alvaro Retana, Ben 2129 Campbell, Benjamin Kaduk and Eric Rescorla. 2131 WG -10: Addressed comments from Benjamin Kaduk and Eric Rescorla. 2133 Authors' Addresses 2135 Michael Welzl 2136 University of Oslo 2137 PO Box 1080 Blindern 2138 Oslo N-0316 2139 Norway 2141 Phone: +47 22 85 24 20 2142 Email: michawe@ifi.uio.no 2144 Stein Gjessing 2145 University of Oslo 2146 PO Box 1080 Blindern 2147 Oslo N-0316 2148 Norway 2150 Phone: +47 22 85 24 44 2151 Email: steing@ifi.uio.no