idnits 2.17.1 draft-ietf-taps-minset-00.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 (October 22, 2017) is 2378 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SUBCATEGORY' is mentioned on line 987, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-taps-transports-usage-08 == Outdated reference: A later version (-02) exists of draft-pauly-taps-transport-security-00 == Outdated reference: A later version (-03) exists of draft-trammell-taps-post-sockets-01 -- Unexpected draft version: The latest known version of draft-tsvwg-le-phb is -00, but you're referring to -02. Summary: 0 errors (**), 0 flaws (~~), 5 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: April 25, 2018 October 22, 2017 7 A Minimal Set of Transport Services for TAPS Systems 8 draft-ietf-taps-minset-00 10 Abstract 12 This draft recommends a minimal set of IETF Transport Services 13 offered by end systems supporting TAPS, and gives guidance on 14 choosing among the available mechanisms and protocols. It is based 15 on the set of transport features given in the TAPS document draft- 16 ietf-taps-transports-usage-08. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 25, 2018. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. The Minimal Set of Transport Features . . . . . . . . . . . . 5 55 3.1. Flow Creation . . . . . . . . . . . . . . . . . . . . . . 5 56 3.2. Flow Connection and Termination . . . . . . . . . . . . . 7 57 3.3. Flow Group Configuration . . . . . . . . . . . . . . . . 8 58 3.4. Flow Configuration . . . . . . . . . . . . . . . . . . . 8 59 3.5. Data Transfer . . . . . . . . . . . . . . . . . . . . . . 9 60 3.5.1. The Sender . . . . . . . . . . . . . . . . . . . . . 9 61 3.5.2. The Receiver . . . . . . . . . . . . . . . . . . . . 10 62 4. An MinSet Abstract Interface . . . . . . . . . . . . . . . . 11 63 4.1. Specification . . . . . . . . . . . . . . . . . . . . . . 12 64 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 17 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 70 9.2. Informative References . . . . . . . . . . . . . . . . . 19 71 Appendix A. Deriving the minimal set . . . . . . . . . . . . . . 21 72 A.1. Step 1: Categorization -- The Superset of Transport 73 Features . . . . . . . . . . . . . . . . . . . . . . . . 21 74 A.1.1. CONNECTION Related Transport Features . . . . . . . . 23 75 A.1.2. DATA Transfer Related Transport Features . . . . . . 38 76 A.2. Step 2: Reduction -- The Reduced Set of Transport 77 Features . . . . . . . . . . . . . . . . . . . . . . . . 43 78 A.2.1. CONNECTION Related Transport Features . . . . . . . . 44 79 A.2.2. DATA Transfer Related Transport Features . . . . . . 45 80 A.3. Step 3: Discussion . . . . . . . . . . . . . . . . . . . 46 81 A.3.1. Sending Messages, Receiving Bytes . . . . . . . . . . 46 82 A.3.2. Stream Schedulers Without Streams . . . . . . . . . . 48 83 A.3.3. Early Data Transmission . . . . . . . . . . . . . . . 49 84 A.3.4. Sender Running Dry . . . . . . . . . . . . . . . . . 50 85 A.3.5. Capacity Profile . . . . . . . . . . . . . . . . . . 50 86 A.3.6. Security . . . . . . . . . . . . . . . . . . . . . . 51 87 A.3.7. Packet Size . . . . . . . . . . . . . . . . . . . . . 51 88 Appendix B. Revision information . . . . . . . . . . . . . . . . 52 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 91 1. Introduction 93 The task of any system that implements TAPS is to offer transport 94 services to its applications, i.e. the applications running on top of 95 TAPS, without binding them to a particular transport protocol. 96 Currently, the set of transport services that most applications use 97 is based on TCP and UDP; this limits the ability for the network 98 stack to make use of features of other protocols. For example, if a 99 protocol supports out-of-order message delivery but applications 100 always assume that the network provides an ordered bytestream, then 101 the network stack can never utilize out-of-order message delivery: 102 doing so would break a fundamental assumption of the application. 104 By exposing the transport services of multiple transport protocols, a 105 TAPS system can make it possible to use these services without having 106 to statically bind an application to a specific transport protocol. 107 The first step towards the design of such a system was taken by 108 [RFC8095], which surveys a large number of transports, and [TAPS2] as 109 well as [TAPS2UDP], which identify the specific transport features 110 that are exposed to applications by the protocols TCP, MPTCP, UDP(- 111 Lite) and SCTP as well as the LEDBAT congestion control mechanism. 112 The present draft is based on these documents and follows the same 113 terminology (also listed below). 115 The number of transport features of current IETF transports is large, 116 and exposing all of them has a number of disadvantages: generally, 117 the more functionality is exposed, the less freedom a TAPS system has 118 to automate usage of the various functions of its available set of 119 transport protocols. Some functions only exist in one particular 120 protocol, and if an application would use them, this would statically 121 tie the application to this protocol, counteracting the purpose of a 122 TAPS system. Also, if the number of exposed features is exceedingly 123 large, a TAPS system might become very hard to use for an application 124 programmer. Taking [TAPS2] as a basis, this document therefore 125 develops a minimal set of transport features, removing the ones that 126 could be harmful to the purpose of a TAPS system but keeping the ones 127 that must be retained for applications to benefit from useful 128 transport functionality. 130 Applications use a wide variety of APIs today. The transport 131 features in the minimal set in this document must be reflected in 132 *all* network APIs in order for the underlying functionality to 133 become usable everywhere. For example, it does not help an 134 application that talks to a middleware if only the Berkeley Sockets 135 API is extended to offer "unordered message delivery", but the 136 middleware only offers an ordered bytestream. Both the Berkeley 137 Sockets API and the middleware would have to expose the "unordered 138 message delivery" transport feature (alternatively, there may be 139 interesting ways for certain types of middleware to use some 140 transport features without exposing them, based on knowledge about 141 the applications -- but this is not the general case). In most 142 situations, in the interest of being as flexible and efficient as 143 possible, the best choice will be for a middleware or library to 144 expose at least all of the transport features that are recommended as 145 a "minimal set" here. 147 This "minimal set" can be implemented one-sided with a fall-back to 148 TCP (or UDP, if certain limitations are put in place). This means 149 that a sender-side TAPS system can talk to a non-TAPS TCP (or UDP) 150 receiver, and a receiver-side TAPS system can talk to a non-TAPS TCP 151 (or UDP) sender. For systems that do not have this requirement, 152 [I-D.trammell-taps-post-sockets] describes a way to extend the 153 functionality of the minimal set such that some of its limitations 154 are removed. 156 2. Terminology 158 The following terms are used throughout this document, and in 159 subsequent documents produced by TAPS that describe the composition 160 and decomposition of transport services. 162 Transport Feature: a specific end-to-end feature that the transport 163 layer provides to an application. Examples include 164 confidentiality, reliable delivery, ordered delivery, message- 165 versus-stream orientation, etc. 166 Transport Service: a set of Transport Features, without an 167 association to any given framing protocol, which provides a 168 complete service to an application. 169 Transport Protocol: an implementation that provides one or more 170 different transport services using a specific framing and header 171 format on the wire. 172 Transport Service Instance: an arrangement of transport protocols 173 with a selected set of features and configuration parameters that 174 implements a single transport service, e.g., a protocol stack (RTP 175 over UDP). 176 Application: an entity that uses the transport layer for end-to-end 177 delivery data across the network (this may also be an upper layer 178 protocol or tunnel encapsulation). 179 Application-specific knowledge: knowledge that only applications 180 have. 181 Endpoint: an entity that communicates with one or more other 182 endpoints using a transport protocol. 183 Connection: shared state of two or more endpoints that persists 184 across messages that are transmitted between these endpoints. 185 Socket: the combination of a destination IP address and a 186 destination port number. 188 Moreover, throughout the document, the protocol name "UDP(-Lite)" is 189 used when discussing transport features that are equivalent for UDP 190 and UDP-Lite; similarly, the protocol name "TCP" refers to both TCP 191 and MPTCP. 193 3. The Minimal Set of Transport Features 195 Based on the categorization, reduction and discussion in Appendix A, 196 this section describes the minimal set of transport features that is 197 offered by end systems supporting TAPS. This TAPS system is able to 198 fall back to TCP; elements of the system that may prohibit falling 199 back to UDP are marked with "!UDP". To implement a TAPS system that 200 is also able to fall back to UDP, these marked transport features 201 should be excluded. 203 3.1. Flow Creation 205 A TAPS flow must be "created" before it is connected, to allow for 206 initial configurations to be carried out. All configuration 207 parameters in Section 3.3 and Section 3.4 can be used initially, 208 although some of them may only take effect when the flow has been 209 connected. Configuring a flow early helps a TAPS system make the 210 right decisions. In particular, the "group number" can influence the 211 TAPS system to implement a TAPS flow as a stream of a multi-streaming 212 protocol's existing association or not. 214 For flows that use a new "group number", early configuration is 215 necessary because it allows the TAPS system to know which protocols 216 it should try to use (to steer a mechanism such as "Happy Eyeballs" 217 [I-D.grinnemo-taps-he]). In particular, a TAPS system that only 218 makes a one-time choice for a particular protocol must know early 219 about strict requirements that must be kept, or it can end up in a 220 deadlock situation (e.g., having chosen UDP and later be asked to 221 support reliable transfer). As one possibility to correctly handle 222 these cases, we provide the following decision tree (this is derived 223 from Appendix A.2.1 excluding authentication, as explained in 224 Section 8): 226 - Will it ever be necessary to offer any of the following? 227 * Reliably transfer data 228 * Notify the peer of closing/aborting 229 * Preserve data ordering 231 Yes: SCTP or TCP can be used. 232 - Is any of the following useful to the application? 233 * Choosing a scheduler to operate between flows in a group, 234 with the possibility to configure a priority or weight per flow 235 * Configurable message reliability 236 * Unordered message delivery 237 * Request not to delay the acknowledgement (SACK) of a message 239 Yes: SCTP is preferred. 240 No: 241 - Is any of the following useful to the application? 242 * Hand over a message to reliably transfer (possibly 243 multiple times) before connection establishment 244 * Suggest timeout to the peer 245 * Notification of Excessive Retransmissions (early 246 warning below abortion threshold) 247 * Notification of ICMP error message arrival 249 Yes: TCP is preferred. 250 No: SCTP and TCP are equally preferable. 252 No: all protocols can be used. 253 - Is any of the following useful to the application? 254 * Specify checksum coverage used by the sender 255 * Specify minimum checksum coverage required by receiver 257 Yes: UDP-Lite is preferred. 258 No: UDP is preferred. 260 Note that this decision tree is not optimal for all cases. For 261 example, if an application wants to use "Specify checksum coverage 262 used by the sender", which is only offered by UDP-Lite, and 263 "Configure priority or weight for a scheduler", which is only offered 264 by SCTP, the above decision tree will always choose UDP-Lite, making 265 it impossible to use SCTP's schedulers with priorities between flows 266 in a group. The TAPS system must know which choice is more important 267 for the application in order to make the best decision. We caution 268 implementers to be aware of the full set of trade-offs, for which we 269 recommend consulting the list in Appendix A.2.1 when deciding how to 270 initialize a flow. 272 Once a flow is created, it can be queried for the maximum amount of 273 data that an application can possibly expect to have reliably 274 transmitted before or during connection establishment (with zero 275 being a possible answer). An application can also give the flow a 276 message for reliable transmission before or during connection 277 establishment (!UDP); the TAPS system will then try to transmit it as 278 early as possible. An application can facilitate sending the message 279 particularly early by marking it as "idempotent"; in this case, the 280 receiving application must be prepared to potentially receive 281 multiple copies of the message (because idempotent messages are 282 reliably transferred, asking for idempotence is not necessary for 283 systems that support UDP-fall-back). 285 3.2. Flow Connection and Termination 287 To be compatible with multiple transports, including streams of a 288 multi-streaming protocol (used as if they were transports 289 themselves), the semantics of opening and closing need to be the most 290 restrictive subset of all of them. For example, TCP's support of 291 half-closed connections can be seen as a feature on top of the more 292 restrictive "ABORT"; this feature cannot be supported because not all 293 protocols used by a TAPS system (including streams of an association) 294 support half-closed connections. 296 After creation, a flow can be actively connected to the other side 297 using "Connect", or it can passively listen for incoming connection 298 requests with "Listen". Note that "Connect" may or may not trigger a 299 notification on the listening side. It is possible that the first 300 notification on the listening side is the arrival of the first data 301 that the active side sends (a receiver-side TAPS system could handle 302 this by continuing to block a "Listen" call, immediately followed by 303 issuing "Receive", for example; callback-based implementations may 304 simply skip the equivalent of "Listen"). This also means that the 305 active opening side is assumed to be the first side sending data. 307 A TAPS system can actively close a connection, i.e. terminate it 308 after reliably delivering all remaining data to the peer, or it can 309 abort it, i.e. terminate it without delivering remaining data. 310 Unless all data transfers only used unreliable frame transmission 311 without congestion control (i.e., UDP-style transfer), closing a 312 connection is guaranteed to cause an event to notify the peer 313 application that the connection has been closed (!UDP). Similarly, 314 for anything but (UDP-style) unreliable non-congestion-controlled 315 data transfer, aborting a connection will cause an event to notify 316 the peer application that the connection has been aborted (!UDP). A 317 timeout can be configured to abort a flow when data could not be 318 delivered for too long (!UDP); however, timeout-based abortion does 319 not notify the peer application that the connection has been aborted. 321 Because half-closed connections are not supported, when a TAPS host 322 receives a notification that the peer is closing or aborting the flow 323 (!UDP), the other side may not be able to read outstanding data. 324 This means that unacknowledged data residing in the TAPS system's 325 send buffer may have to be dropped from that buffer upon arrival of a 326 notification to close or abort the flow from the peer. 328 3.3. Flow Group Configuration 330 A flow group can be configured with a number of transport features, 331 and there are some notifications to applications about a flow group. 332 Here we list transport features and notifications from Appendix A.2 333 that sometimes automatically apply to groups of flows (e.g., when a 334 flow is mapped to a stream of a multi-streaming protocol). 336 Timeout, error notifications: 338 o Change timeout for aborting connection (using retransmit limit or 339 time value) (!UDP) 340 o Suggest timeout to the peer (!UDP) 341 o Notification of Excessive Retransmissions (early warning below 342 abortion threshold) 343 o Notification of ICMP error message arrival 345 Others: 347 o Choose a scheduler to operate between flows of a group 348 o Obtain ECN field 350 The following transport features are new or changed, based on the 351 discussion in Appendix A.3: 353 o Capacity profile 354 This describes how an application wants to use its available 355 capacity. Choices can be "lowest possible latency at the expense 356 of overhead" (which would disable any Nagle-like algorithm), 357 "scavenger", and some more values that help determine the DSCP 358 value for a flow (e.g. similar to table 1 in 359 [I-D.ietf-tsvwg-rtcweb-qos]). 361 3.4. Flow Configuration 363 Here we list transport features and notifications from Appendix A.2 364 that only apply to a single flow. 366 Configure priority or weight for a scheduler 367 Checksums: 369 o Disable checksum when sending 370 o Disable checksum requirement when receiving 371 o Specify checksum coverage used by the sender 372 o Specify minimum checksum coverage required by receiver 374 3.5. Data Transfer 376 3.5.1. The Sender 378 This section discusses how to send data after flow establishment. 379 Section 3.2 discusses the possiblity to hand over a message to 380 reliably send before or during establishment. 382 Here we list per-frame properties that a sender can optionally 383 configure if it hands over a delimited frame for sending with 384 congestion control (!UDP), taken from Appendix A.2: 386 o Configurable Message Reliability 387 o Ordered message delivery (potentially slower than unordered) 388 o Unordered message delivery (potentially faster than ordered) 389 o Request not to bundle messages 390 o Request not to delay the acknowledgement (SACK) of a message 392 Additionally, an application can hand over delimited frames for 393 unreliable transmission without congestion control (note that such 394 applications should perform congestion control in accordance with 395 [RFC2914]). Then, none of the per-frame properties listed above have 396 any effect, but it is possible to use the transport feature "Specify 397 DF field" to allow/disallow fragmentation. 399 Following Appendix A.3.7, there are three transport features (two 400 old, one new) and a notification: 402 o Get max. transport frame size that may be sent without 403 fragmentation from the configured interface 404 This is optional for a TAPS system to offer, and may return an 405 error ("not available"). It can aid applications implementing 406 Path MTU Discovery. 408 o Get max. transport frame size that may be received from the 409 configured interface 410 This is optional for a TAPS system to offer, and may return an 411 error ("not available"). 413 o Get maximum transport frame size 414 Irrespective of fragmentation, there is a size limit for the 415 messages that can be handed over to SCTP or UDP(-Lite); because a 416 TAPS system is independent of the transport, it must allow a TAPS 417 application to query this value -- the maximum size of a frame in 418 an Application-Framed-Bytestream. This may also return an error 419 when frames are not delimited ("not available"). 421 There are two more sender-side notifications. These are unreliable, 422 i.e. a TAPS system cannot be assumed to implement them, but they may 423 occur: 425 o Notification of send failures 426 A TAPS system may inform a sender application of a failure to send 427 a specific frame. 429 o Notification of draining below a low water mark 430 A TAPS system can notify a sender application when the TAPS 431 system's filling level of the buffer of unsent data is below a 432 configurable threshold in bytes. Even for TAPS systems that do 433 implement this notification, supporting thresholds other than 0 is 434 optional. 436 "Notification of draining below a low water mark" is a generic 437 notification that tries to enable uniform access to 438 "TCP_NOTSENT_LOWAT" as well as the "SENDER DRY" notification (as 439 discussed in Appendix A.3.4 -- SCTP's "SENDER DRY" is a special case 440 where the threshold (for unsent data) is 0 and there is also no more 441 unacknowledged data in the send buffer). Note that this threshold 442 and its notification should operate across the buffers of the whole 443 TAPS system, i.e. also any potential buffers that the TAPS system 444 itself may use on top of the transport's send buffer. 446 3.5.2. The Receiver 448 A receiving application obtains an Application-Framed Bytestream. 449 Similar to TCP's receiver semantics, it is just a stream of bytes. 450 If frame boundaries were specified by the sender, a receiver-side 451 TAPS system will still not inform the receiving application about 452 them. Within the bytestream, frames themselves will always stay 453 intact (partial frames are not supported - see Appendix A.3.1). 454 Different from TCP's semantics, there is no guarantee that all frames 455 in the bytestream are transmitted from the sender to the receiver, 456 and that all of them are in the same sequence in which they were 457 handed over by the sender. If an application is aware of frame 458 delimiters in the bytestream, and if the sender-side application has 459 informed the TAPS system about these boundaries and about potentially 460 relaxed requirements regarding the sequence of frames or per-frame 461 reliability, frames within the receiver-side bytestream may be out- 462 of-order or missing. 464 4. An MinSet Abstract Interface 466 Here we present the minimum set in the form of an abstract interface 467 that a TAPS system could implement. This abstract interface is 468 derived from the description in the previous section. The primitives 469 of this abstract interface can be implemented in various ways. For 470 example, information that is provided to an application can either be 471 offered via a primitive that is polled, or via an asynchronous 472 notification. 474 We note that this is just a different form to represent the text in 475 the previous section, and not an abstract API that is recommended to 476 be implemented in this form by all TAPS systems. Specifically, TAPS 477 systems implementing this specific abstract interface would have the 478 following properties: 480 1. Support one-sided deployment with a fall-back to TCP (or UDP) 481 2. Offer all the transport features of (MP)TCP, UDP(-Lite), LEDBAT 482 and SCTP that require application-specific knowledge 483 3. Not offer any of the transport features of these protocols and 484 the LEDBAT congestion control mechanism that do not require 485 application-specific knowledge (to give maximum flexibility to a 486 TAPS system) 488 This reciprocally means that this is probably not the ideal interface 489 to implement for systems that: 491 1. Assume that there is a system on both sides -- in this case, 492 richer functionality can be provided (cf. 493 [I-D.trammell-taps-post-sockets]) -- or assume different fall- 494 back protocols than TCP or UDP 495 2. Use other protocols than (MP)TCP, UDP(-Lite), SCTP or the LEDBAT 496 congestion control mechanism underneath the TAPS interface 497 3. Want to offer transport features that do not require application- 498 specific knowledge 500 4.1. Specification 502 CREATE (flow-group-id, reliability, checksum_coverage, 503 config_msg_prio, earlymsg_timeout_notifications) 504 Returns: flow-id 506 Create a flow and associate it with an existing or new flow group 507 number. The group number can influence the TAPS system to implement 508 a TAPS flow as a stream of a multi-streaming protocol's existing 509 association or not, and the other parameters serve as input to the 510 decision tree described in Section 3.1. The TAPS systems gives no 511 guarantees about honoring any of the requests at this stage, these 512 parameters are just meant to help it to choose and configure a 513 suitable protocol. 515 PARAMETERS: 517 flow-group-id: the flow's group number; all other parameters are 518 only relevant when this number is not currently in use by an 519 ongoing flow to the same destination (in which case the flow 520 becomes a member of the existing flow's group and inherits the 521 configuration of the group). 522 reliability: a boolean that should be set to true when any of the 523 following will be useful to the application: reliably transfer 524 data; notify the peer of closing/aborting; preserve data ordering. 525 checksum_coverage: a boolean to specify whether it will be useful to 526 the application to specify checksum coverage when sending or 527 receiving. 528 config_msg_prio: a boolean that should be set to true when any of 529 the following per-message configuration or prioritization 530 mechanisms will be useful to the application: choosing a scheduler 531 to operate between flows in a group, with the possibility to 532 configure a priority or weight per flow; configurable message 533 reliability; unordered message delivery; requesting not to delay 534 the acknowledgement (SACK) of a message. 535 earlymsg_timeout_notifications: a boolean that should be set to true 536 when any of the following will be useful to the application: hand 537 over a message to reliably transfer (possibly multiple times) 538 before connection establishment; suggest timeout to the peer; 539 notification of excessive retransmissions (early warning below 540 abortion threshold); notification of ICMP error message arrival. 542 (!UDP) CONFIGURE_TIMEOUT (flow-group-id [timeout] [peer_timeout] 543 [retrans_notify]) 545 This configures timeouts for all flows in a group. Configuration 546 should generally be carried out as early as possible, ideally before 547 flows are connected, to aid the TAPS system's decision taking. 549 PARAMETERS: 551 timeout: a timeout value for aborting connections, in seconds 552 peer_timeout: a timeout value to be suggested to the peer (if 553 possible), in seconds 554 retrans_notify: the number of retransmissions after which the 555 application should be notifed of "Excessive Retransmissions" 557 CONFIGURE_CHECKSUM (flow-id [send [send_length]] [receive 558 [receive_length]]) 560 This configures the usage of checksums for a flow in a group. 561 Configuration should generally be carried out as early as possible, 562 ideally before the flow is connected, to aid the TAPS system's 563 decision taking. "send" parameters concern using a checksum when 564 sending, "receive" parameters concern requiring a checksum when 565 receiving. There is no guarantee that any checksum limitations will 566 indeed be enforced; all defaults are: "full coverage, checksum 567 enabled". 569 PARAMETERS: 571 send: boolean, enable / disable usage of a checksum 572 send_length: if send is true, this optional parameter can provide 573 the desired coverage of the checksum in bytes 574 receive: boolean, enable / disable requiring a checksum 575 receive_length: if receive is true, this optional parameter can 576 provide the required minimum coverage of the checksum in bytes 578 CONFIGURE_URGENCY (flow-group-id [scheduler] [capacity_profile] 579 [low_watermark]) 581 This carries out configuration related to the urgency of sending data 582 on flows of a group. Configuration should generally be carried out 583 as early as possible, ideally before flows are connected, to aid the 584 TAPS system's decision taking. 586 PARAMETERS: 588 scheduler: a number to identify the type of scheduler that should be 589 used to operate between flows in the group (no guarantees given). 590 Future versions of this document will be self contained, but for 591 now we suggest the schedulers defined in 592 [I-D.ietf-tsvwg-sctp-ndata]. 593 capacity_profile: a number to identify how an application wants to 594 use its available capacity. Future versions of this document will 595 be self contained, but for now choices can be "lowest possible 596 latency at the expense of overhead" (which would disable any 597 Nagle-like algorithm), "scavenger", and some more values that help 598 determine the DSCP value for a flow (e.g. similar to table 1 in 599 [I-D.ietf-tsvwg-rtcweb-qos]). 600 low_watermark: a buffer limit (in bytes); when the sender has less 601 then low_watermark bytes in the buffer, the application may be 602 notified. Notifications are not guaranteed, and supporting 603 watermark numbers greater than 0 is not guaranteed. 605 CONFIGURE_PRIORITY (flow-id priority) 607 This configures a flow's priority or weight for a scheduler. 608 Configuration should generally be carried out as early as possible, 609 ideally before flows are connected, to aid the TAPS system's decision 610 taking. 612 PARAMETERS: 614 priority: future versions of this document will be self contained, 615 but for now we suggest the priority as described in 616 [I-D.ietf-tsvwg-sctp-ndata]. 618 NOTIFICATIONS 619 Returns: flow-group-id notification_type 621 This is fired when an event occurs, notifying the application about 622 something happening in relation to a flow group. Notification types 623 are: 625 Excessive Retransmissions: the configured (or a default) number of 626 retransmissions has been reached, yielding this early warning 627 below an abortion threshold. 628 ICMP Arrival (parameter: ICMP message): an ICMP packet carrying the 629 conveyed ICMP message has arrived. 630 ECN Arrival (parameter: ECN value): a packet carrying the conveyed 631 ECN value has arrived. This can be useful for applications 632 implementing congestion control. 633 Timeout (parameter: s seconds): data could not be delivered for s 634 seconds. 635 Close: the peer has closed the connection. The peer has no more 636 data to send, and will not read more data. Data that is in 637 transit or resides in the local send buffer will be discarded. 638 Abort: the peer has aborted the connection. The peer has no more 639 data to send, and will not read more data. Data that is in 640 transit or resides in the local send buffer will be discarded. 642 Note that there is no guarantee that this notification will be 643 invoked when the peer aborts. 644 Drain: the send buffer has either drained below the configured low 645 water mark or it has become completely empty. 646 Path Change (parameter: path identifier): the path has changed; the 647 path identifier is a number that can be used to determine a 648 previously used path is used again (e.g., the TAPS system has 649 switched from one interface to the other and back). 650 Send Failure (parameter: frame identifier): this informs the 651 application of a failure to send a specific frame. There can be a 652 send failure without this notification happening. 654 QUERY_PROPERTIES (flow-group-id property_identifier) 655 Returns: requested property (see below) 657 This allows to query some properties of a flow group. Return values 658 per property identifier are: 660 o The maximum frame size that may be sent without fragmentation, in 661 bytes (or "not available") 662 o The maximum transport frame size that can be sent, in bytes (or 663 "not available") 664 o The maximum transport frame size that can be received, in bytes 665 (or "not available") 666 o The maximum amount of data that can possibly be sent before or 667 during connection establishment, in bytes (or "not available") 669 CONNECT (flow-id dst_addr) 671 Connects a flow. This primitive may or may not trigger a 672 notification (continuing LISTEN) on the listening side. If a send 673 precedes this call, then data may be transmitted with this connect. 675 PARAMETERS: 677 dst_addr: the destination transport address to connect to 679 LISTEN (flow-id) 681 Blocking passive connect, listening on all interfaces. This may not 682 be the direct result of the peer calling CONNECT - it may also be 683 invoked upon reception of the first block of data. In this case, 684 RECEIVE_FRAME is invoked immediately after. 686 SEND_FRAME (flow-id frame [reliability] [ordered] [bundle] [delack] 687 [fragment] [idempotent]) 689 Sends an application frame. No guarantees are given about the 690 preservation of frame boundaries to the peer; if frame boundaries are 691 needed, the receiving application at the peer must know about them 692 beforehand (or the TAPS system cannot fall back to TCP). Note that 693 this call can already be used before a flow is connected. All 694 parameters refer to the frame that is being handed over. 696 PARAMETERS: 698 (!UDP) reliability: this parameter is used to convey a choice of: 699 fully reliable, unreliable without congestion control (which is 700 guaranteed), unreliable, partially reliable (how to configure: 701 TBD, probably using a time value). The latter two choices are not 702 guaranteed and may result in full reliability. 703 (!UDP) ordered: this boolean parameter lets an application choose 704 between ordered message delivery (true) and possibly unordered, 705 potentially faster message delivery (false). 706 bundle: a boolean that expresses a preference for allowing to bundle 707 frames (true) or not (false). No guarantees are given. 708 delack: a boolean that, if false, lets an application request that 709 the peer would not delay the acknowledgement for this frame. 710 fragment: a boolean that expresses a preference for allowing to 711 fragment frames (true) or not (false), at the IP level. No 712 guarantees are given. 713 (!UDP) idempotent: a boolean that expresses whether a frame is 714 idempotent (true) or not (false). Idempotent frames may arrive 715 multiple times at the receiver (but they will arrive at least 716 once). When data is idempotent it can be used by the receiver 717 immediately on a connection establishment attempt. Thus, if 718 SEND_FRAME is used before connecting, stating that a frame is 719 idempotent facilitates transmitting it to the peer application 720 particularly early. 722 (!UDP) CLOSE (flow-id) 724 Closes the flow after all outstanding data is reliably delivered to 725 the peer (if reliable data delivery was requested). In case reliable 726 or partially reliable data delivery was requested earlier, the peer 727 is notified of the CLOSE. 729 ABORT (flow-id) 730 Aborts the flow without delivering outstanding data to the peer. In 731 case reliable or partially reliable data delivery was requested 732 earlier (!UDP), the peer is notified of the ABORT. 734 RECEIVE_FRAME (flow-id buffer) 736 This receives a block of data. This block may or may not correspond 737 to a sender-side frame, i.e. the receiving application is not 738 informed about frame boundaries (this limitation is only needed for 739 TAPS systems that want to be able to fall back to TCP). However, if 740 the sending application has allowed that frames are not fully 741 reliably transferred, or delivered out of order, then such re- 742 ordering or unreliability may be reflected per frame in the arriving 743 data. Frames will always stay intact - i.e. if an incomplete frame 744 is contained at the end of the arriving data block, this frame is 745 guaranteed to continue in the next arriving data block. 747 PARAMETERS: 749 buffer: the buffer where the received data will be stored. 751 5. Conclusion 753 By decoupling applications from transport protocols, a TAPS system 754 provides a different abstraction level than the Berkeley sockets 755 interface. As with high- vs. low-level programming languages, a 756 higher abstraction level allows more freedom for automation below the 757 interface, yet it takes some control away from the application 758 programmer. This is the design trade-off that a TAPS system 759 developer is facing, and this document provides guidance on the 760 design of this abstraction level. Some transport features are 761 currently rarely offered by APIs, yet they must be offered or they 762 can never be used ("functional" transport features). Other transport 763 features are offered by the APIs of the protocols covered here, but 764 not exposing them in a TAPS API would allow for more freedom to 765 automate protocol usage in a TAPS system. 767 The minimal set presented in this document is an effort to find a 768 middle ground that can be recommended for TAPS systems to implement, 769 on the basis of the transport features discussed in [TAPS2]. This 770 middle ground eliminates a large number of transport features because 771 they do not require application-specific knowledge, but instead rely 772 on knowledge about the network or the Operating System. This leaves 773 us with an unanswered question about how exactly a TAPS system should 774 automate using all of these "automatable" transport features. 776 In some cases, it may be best to not entirely automate the decision 777 making, but leave it up to a system-wide policy. For example, when 778 multiple paths are available, a system policy could guide the 779 decision on whether to connect via a WiFi or a cellular interface. 780 Such high-level guidance could also be provided by application 781 developers, e.g. via a primitive that lets applications specify such 782 preferences. As long as this kind of information from applications 783 is treated as advisory, it will not lead to a permanent protocol 784 binding and does therefore not limit the flexibility of a TAPS 785 system. Decisions to add such primitives are therefore left open to 786 TAPS system designers. 788 6. Acknowledgements 790 The authors would like to thank the participants of the TAPS Working 791 Group and the NEAT research project for valuable input to this 792 document. We especially thank Michael Tuexen for help with TAPS flow 793 connection establishment/teardown and Gorry Fairhurst for his 794 suggestions regarding fragmentation and packet sizes. This work has 795 received funding from the European Union's Horizon 2020 research and 796 innovation programme under grant agreement No. 644334 (NEAT). 798 7. IANA Considerations 800 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 802 This memo includes no request to IANA. 804 8. Security Considerations 806 Authentication, confidentiality protection, and integrity protection 807 are identified as transport features by [RFC8095]. As currently 808 deployed in the Internet, these features are generally provided by a 809 protocol or layer on top of the transport protocol; no current full- 810 featured standards-track transport protocol provides all of these 811 transport features on its own. Therefore, these transport features 812 are not considered in this document, with the exception of native 813 authentication capabilities of TCP and SCTP for which the security 814 considerations in [RFC5925] and [RFC4895] apply. 816 9. References 818 9.1. Normative References 820 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 821 Ed., "Services Provided by IETF Transport Protocols and 822 Congestion Control Mechanisms", RFC 8095, 823 DOI 10.17487/RFC8095, March 2017, 824 . 826 [TAPS2] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of 827 Transport Features Provided by IETF Transport Protocols", 828 Internet-draft draft-ietf-taps-transports-usage-08, August 829 2017. 831 [TAPS2UDP] 832 Fairhurst, G. and T. Jones, "Features of the User Datagram 833 Protocol (UDP) and Lightweight UDP (UDP-Lite) Transport 834 Protocols", Internet-draft draft-ietf-taps-transports- 835 usage-udp-07, September 2017. 837 9.2. Informative References 839 [COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte 840 Stuffing", September 1997, 841 . 843 [I-D.grinnemo-taps-he] 844 Grinnemo, K., Brunstrom, A., Hurtig, P., Khademi, N., and 845 Z. Bozakov, "Happy Eyeballs for Transport Selection", 846 draft-grinnemo-taps-he-03 (work in progress), July 2017. 848 [I-D.ietf-tsvwg-rtcweb-qos] 849 Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP 850 Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- 851 qos-18 (work in progress), August 2016. 853 [I-D.ietf-tsvwg-sctp-ndata] 854 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 855 "Stream Schedulers and User Message Interleaving for the 856 Stream Control Transmission Protocol", draft-ietf-tsvwg- 857 sctp-ndata-13 (work in progress), September 2017. 859 [I-D.pauly-taps-transport-security] 860 Pauly, T. and C. Wood, "A Survey of Transport Security 861 Protocols", draft-pauly-taps-transport-security-00 (work 862 in progress), July 2017. 864 [I-D.trammell-taps-post-sockets] 865 Trammell, B., Perkins, C., Pauly, T., Kuehlewind, M., and 866 C. Wood, "Post Sockets, An Abstract Programming Interface 867 for the Transport Layer", draft-trammell-taps-post- 868 sockets-01 (work in progress), September 2017. 870 [LBE-draft] 871 Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", 872 Internet-draft draft-tsvwg-le-phb-02, June 2017. 874 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 875 RFC 2914, DOI 10.17487/RFC2914, September 2000, 876 . 878 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 879 "Authenticated Chunks for the Stream Control Transmission 880 Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 881 2007, . 883 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 884 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 885 . 887 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 888 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 889 June 2010, . 891 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 892 Yasevich, "Sockets API Extensions for the Stream Control 893 Transmission Protocol (SCTP)", RFC 6458, 894 DOI 10.17487/RFC6458, December 2011, 895 . 897 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 898 Transmission Protocol (SCTP) Stream Reconfiguration", 899 RFC 6525, DOI 10.17487/RFC6525, February 2012, 900 . 902 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 903 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 904 . 906 [WWDC2015] 907 Lakhera, P. and S. Cheshire, "Your App and Next Generation 908 Networks", Apple Worldwide Developers Conference 2015, San 909 Francisco, USA, June 2015, 910 . 912 Appendix A. Deriving the minimal set 914 We approach the construction of a minimal set of transport features 915 in the following way: 917 1. Categorization: the superset of transport features from [TAPS2] 918 is presented, and transport features are categorized for later 919 reduction. 920 2. Reduction: a shorter list of transport features is derived from 921 the categorization in the first step. This removes all transport 922 features that do not require application-specific knowledge or 923 cannot be implemented with TCP. !!!TODO discuss UDP 924 3. Discussion: the resulting list shows a number of peculiarities 925 that are discussed, to provide a basis for constructing the 926 minimal set. 927 4. Construction: Based on the reduced set and the discussion of the 928 transport features therein, a minimal set is constructed. 930 The first three steps as well as the underlying rationale for 931 constructing the minimal set are described in this appendix. The 932 minimal set itself is described in Section 3. 934 A.1. Step 1: Categorization -- The Superset of Transport Features 936 Following [TAPS2], we divide the transport features into two main 937 groups as follows: 939 1. CONNECTION related transport features 940 - ESTABLISHMENT 941 - AVAILABILITY 942 - MAINTENANCE 943 - TERMINATION 945 2. DATA Transfer Related transport features 946 - Sending Data 947 - Receiving Data 948 - Errors 950 We assume that TAPS applications have no specific requirements that 951 need knowledge about the network, e.g. regarding the choice of 952 network interface or the end-to-end path. Even with these 953 assumptions, there are certain requirements that are strictly kept by 954 transport protocols today, and these must also be kept by a TAPS 955 system. Some of these requirements relate to transport features that 956 we call "Functional". 958 Functional transport features provide functionality that cannot be 959 used without the application knowing about them, or else they violate 960 assumptions that might cause the application to fail. For example, 961 ordered message delivery is a functional transport feature: it cannot 962 be configured without the application knowing about it because the 963 application's assumption could be that messages always arrive in 964 order. Failure includes any change of the application behavior that 965 is not performance oriented, e.g. security. 967 "Change DSCP" and "Disable Nagle algorithm" are examples of transport 968 features that we call "Optimizing": if a TAPS system autonomously 969 decides to enable or disable them, an application will not fail, but 970 a TAPS system may be able to communicate more efficiently if the 971 application is in control of this optimizing transport feature. 972 These transport features require application-specific knowledge 973 (e.g., about delay/bandwidth requirements or the length of future 974 data blocks that are to be transmitted). 976 The transport features of IETF transport protocols that do not 977 require application-specific knowledge and could therefore be 978 transparently utilized by a TAPS system are called "Automatable". 980 Finally, some transport features are aggregated and/or slightly 981 changed in the description below. These transport features are 982 marked as "ADDED". The corresponding transport features are 983 automatable, and they are listed immediately below the "ADDED" 984 transport feature. 986 In this description, transport services are presented following the 987 nomenclature "CATEGORY.[SUBCATEGORY].SERVICENAME.PROTOCOL", 988 equivalent to "pass 2" in [TAPS2]. We also sketch how some of the 989 TAPS transport features can be implemented by a TAPS system. For all 990 transport features that are categorized as "functional" or 991 "optimizing", and for which no matching TCP and/or UDP primitive 992 exists in "pass 2" of [TAPS2], a brief discussion on how to fall back 993 to TCP and/or UDP is included. 995 We designate some transport features as "automatable" on the basis of 996 a broader decision that affects multiple transport features: 998 o Most transport features that are related to multi-streaming were 999 designated as "automatable". This was done because the decision 1000 on whether to use multi-streaming or not does not depend on 1001 application-specific knowledge. This means that a connection that 1002 is exhibited to an application could be implemented by using a 1003 single stream of an SCTP association instead of mapping it to a 1004 complete SCTP association or TCP connection. This could be 1005 achieved by using more than one stream when an SCTP association is 1006 first established (CONNECT.SCTP parameter "outbound stream 1007 count"), maintaining an internal stream number, and using this 1008 stream number when sending data (SEND.SCTP parameter "stream 1009 number"). Closing or aborting a connection could then simply free 1010 the stream number for future use. This is discussed further in 1011 Appendix A.3.2. 1012 o All transport features that are related to using multiple paths or 1013 the choice of the network interface were designated as 1014 "automatable". Choosing a path or an interface does not depend on 1015 application-specific knowledge. For example, "Listen" could 1016 always listen on all available interfaces and "Connect" could use 1017 the default interface for the destination IP address. 1019 A.1.1. CONNECTION Related Transport Features 1021 ESTABLISHMENT: 1023 o Connect 1024 Protocols: TCP, SCTP, UDP(-Lite) 1025 Functional because the notion of a connection is often reflected 1026 in applications as an expectation to be able to communicate after 1027 a "Connect" succeeded, with a communication sequence relating to 1028 this transport feature that is defined by the application 1029 protocol. 1030 Implementation: via CONNECT.TCP, CONNECT.SCTP or CONNECT.UDP(- 1031 Lite). 1033 o Specify which IP Options must always be used 1034 Protocols: TCP, UDP(-Lite) 1035 Automatable because IP Options relate to knowledge about the 1036 network, not the application. 1038 o Request multiple streams 1039 Protocols: SCTP 1040 Automatable because using multi-streaming does not require 1041 application-specific knowledge. 1042 Implementation: see Appendix A.3.2. 1044 o Limit the number of inbound streams 1045 Protocols: SCTP 1046 Automatable because using multi-streaming does not require 1047 application-specific knowledge. 1048 Implementation: see Appendix A.3.2. 1050 o Specify number of attempts and/or timeout for the first 1051 establishment message 1052 Protocols: TCP, SCTP 1053 Functional because this is closely related to potentially assumed 1054 reliable data delivery for data that is sent before or during 1055 connection establishment. 1056 Implementation: Using a parameter of CONNECT.TCP and CONNECT.SCTP. 1057 Fall-back to UDP: Do nothing (this is irrelevant in case of UDP 1058 because there, reliable data delivery is not assumed). 1060 o Obtain multiple sockets 1061 Protocols: SCTP 1062 Automatable because the usage of multiple paths to communicate to 1063 the same end host relates to knowledge about the network, not the 1064 application. 1066 o Disable MPTCP 1067 Protocols: MPTCP 1068 Automatable because the usage of multiple paths to communicate to 1069 the same end host relates to knowledge about the network, not the 1070 application. 1071 Implementation: via a boolean parameter in CONNECT.MPTCP. 1073 o Configure authentication 1074 Protocols: TCP, SCTP 1075 Functional because this has a direct influence on security. 1076 Implementation: via parameters in CONNECT.TCP and CONNECT.SCTP. 1077 Fall-back to TCP: With TCP, this allows to configure Master Key 1078 Tuples (MKTs) to authenticate complete segments (including the TCP 1079 IPv4 pseudoheader, TCP header, and TCP data). With SCTP, this 1080 allows to specify which chunk types must always be authenticated. 1081 Authenticating only certain chunk types creates a reduced level of 1082 security that is not supported by TCP; to be compatible, this 1083 should therefore only allow to authenticate all chunk types. Key 1084 material must be provided in a way that is compatible with both 1085 [RFC4895] and [RFC5925]. 1086 Fall-back to UDP: Not possible. 1088 o Indicate (and/or obtain upon completion) an Adaptation Layer via 1089 an adaptation code point 1090 Protocols: SCTP 1091 Functional because it allows to send extra data for the sake of 1092 identifying an adaptation layer, which by itself is application- 1093 specific. 1094 Implementation: via a parameter in CONNECT.SCTP. 1095 Fall-back to TCP: not possible. 1096 Fall-back to UDP: not possible. 1098 o Request to negotiate interleaving of user messages 1099 Protocols: SCTP 1100 Automatable because it requires using multiple streams, but 1101 requesting multiple streams in the CONNECTION.ESTABLISHMENT 1102 category is automatable. 1103 Implementation: via a parameter in CONNECT.SCTP. 1105 o Hand over a message to reliably transfer (possibly multiple times) 1106 before connection establishment 1107 Protocols: TCP 1108 Functional because this is closely tied to properties of the data 1109 that an application sends or expects to receive. 1110 Implementation: via a parameter in CONNECT.TCP. 1111 Fall-back to UDP: not possible. 1113 o Hand over a message to reliably transfer during connection 1114 establishment 1115 Protocols: SCTP 1116 Functional because this can only work if the message is limited in 1117 size, making it closely tied to properties of the data that an 1118 application sends or expects to receive. 1119 Implementation: via a parameter in CONNECT.SCTP. 1120 Fall-back to UDP: not possible. 1122 o Enable UDP encapsulation with a specified remote UDP port number 1123 Protocols: SCTP 1124 Automatable because UDP encapsulation relates to knowledge about 1125 the network, not the application. 1127 AVAILABILITY: 1129 o Listen 1130 Protocols: TCP, SCTP, UDP(-Lite) 1131 Functional because the notion of accepting connection requests is 1132 often reflected in applications as an expectation to be able to 1133 communicate after a "Listen" succeeded, with a communication 1134 sequence relating to this transport feature that is defined by the 1135 application protocol. 1136 ADDED. This differs from the 3 automatable transport features 1137 below in that it leaves the choice of interfaces for listening 1138 open. 1139 Implementation: by listening on all interfaces via LISTEN.TCP (not 1140 providing a local IP address) or LISTEN.SCTP (providing SCTP port 1141 number / address pairs for all local IP addresses). LISTEN.UDP(- 1142 Lite) supports both methods. 1144 o Listen, 1 specified local interface 1145 Protocols: TCP, SCTP, UDP(-Lite) 1146 Automatable because decisions about local interfaces relate to 1147 knowledge about the network and the Operating System, not the 1148 application. 1150 o Listen, N specified local interfaces 1151 Protocols: SCTP 1152 Automatable because decisions about local interfaces relate to 1153 knowledge about the network and the Operating System, not the 1154 application. 1156 o Listen, all local interfaces 1157 Protocols: TCP, SCTP, UDP(-Lite) 1158 Automatable because decisions about local interfaces relate to 1159 knowledge about the network and the Operating System, not the 1160 application. 1162 o Specify which IP Options must always be used 1163 Protocols: TCP, UDP(-Lite) 1164 Automatable because IP Options relate to knowledge about the 1165 network, not the application. 1167 o Disable MPTCP 1168 Protocols: MPTCP 1169 Automatable because the usage of multiple paths to communicate to 1170 the same end host relates to knowledge about the network, not the 1171 application. 1173 o Configure authentication 1174 Protocols: TCP, SCTP 1175 Functional because this has a direct influence on security. 1176 Implementation: via parameters in LISTEN.TCP and LISTEN.SCTP. 1177 Fall-back to TCP: With TCP, this allows to configure Master Key 1178 Tuples (MKTs) to authenticate complete segments (including the TCP 1179 IPv4 pseudoheader, TCP header, and TCP data). With SCTP, this 1180 allows to specify which chunk types must always be authenticated. 1181 Authenticating only certain chunk types creates a reduced level of 1182 security that is not supported by TCP; to be compatible, this 1183 should therefore only allow to authenticate all chunk types. Key 1184 material must be provided in a way that is compatible with both 1185 [RFC4895] and [RFC5925]. 1186 Fall-back to UDP: not possible. 1188 o Obtain requested number of streams 1189 Protocols: SCTP 1190 Automatable because using multi-streaming does not require 1191 application-specific knowledge. 1192 Implementation: see Appendix A.3.2. 1194 o Limit the number of inbound streams 1195 Protocols: SCTP 1196 Automatable because using multi-streaming does not require 1197 application-specific knowledge. 1198 Implementation: see Appendix A.3.2. 1200 o Indicate (and/or obtain upon completion) an Adaptation Layer via 1201 an adaptation code point 1202 Protocols: SCTP 1203 Functional because it allows to send extra data for the sake of 1204 identifying an adaptation layer, which by itself is application- 1205 specific. 1206 Implementation: via a parameter in LISTEN.SCTP. 1207 Fall-back to TCP: not possible. 1208 Fall-back to UDP: not possible. 1210 o Request to negotiate interleaving of user messages 1211 Protocols: SCTP 1212 Automatable because it requires using multiple streams, but 1213 requesting multiple streams in the CONNECTION.ESTABLISHMENT 1214 category is automatable. 1215 Implementation: via a parameter in LISTEN.SCTP. 1217 MAINTENANCE: 1219 o Change timeout for aborting connection (using retransmit limit or 1220 time value) 1221 Protocols: TCP, SCTP 1222 Functional because this is closely related to potentially assumed 1223 reliable data delivery. 1224 Implementation: via CHANGE-TIMEOUT.TCP or CHANGE-TIMEOUT.SCTP. 1225 Fall-back to UDP: not possible (UDP is unreliable and there is no 1226 connection timeout). 1228 o Suggest timeout to the peer 1229 Protocols: TCP 1230 Functional because this is closely related to potentially assumed 1231 reliable data delivery. 1232 Implementation: via CHANGE-TIMEOUT.TCP. 1233 Fall-back to UDP: not possible (UDP is unreliable and there is no 1234 connection timeout). 1236 o Disable Nagle algorithm 1237 Protocols: TCP, SCTP 1238 Optimizing because this decision depends on knowledge about the 1239 size of future data blocks and the delay between them. 1240 Implementation: via DISABLE-NAGLE.TCP and DISABLE-NAGLE.SCTP. 1241 Fall-back to UDP: do nothing (UDP does not implement the Nagle 1242 algorithm). 1244 o Request an immediate heartbeat, returning success/failure 1245 Protocols: SCTP 1246 Automatable because this informs about network-specific knowledge. 1248 o Notification of Excessive Retransmissions (early warning below 1249 abortion threshold) 1250 Protocols: TCP 1251 Optimizing because it is an early warning to the application, 1252 informing it of an impending functional event. 1253 Implementation: via ERROR.TCP. 1254 Fall-back to UDP: do nothing (there is no abortion threshold). 1256 o Add path 1257 Protocols: MPTCP, SCTP 1258 MPTCP Parameters: source-IP; source-Port; destination-IP; 1259 destination-Port 1260 SCTP Parameters: local IP address 1261 Automatable because the usage of multiple paths to communicate to 1262 the same end host relates to knowledge about the network, not the 1263 application. 1265 o Remove path 1266 Protocols: MPTCP, SCTP 1267 MPTCP Parameters: source-IP; source-Port; destination-IP; 1268 destination-Port 1269 SCTP Parameters: local IP address 1270 Automatable because the usage of multiple paths to communicate to 1271 the same end host relates to knowledge about the network, not the 1272 application. 1274 o Set primary path 1275 Protocols: SCTP 1276 Automatable because the usage of multiple paths to communicate to 1277 the same end host relates to knowledge about the network, not the 1278 application. 1280 o Suggest primary path to the peer 1281 Protocols: SCTP 1282 Automatable because the usage of multiple paths to communicate to 1283 the same end host relates to knowledge about the network, not the 1284 application. 1286 o Configure Path Switchover 1287 Protocols: SCTP 1288 Automatable because the usage of multiple paths to communicate to 1289 the same end host relates to knowledge about the network, not the 1290 application. 1292 o Obtain status (query or notification) 1293 Protocols: SCTP, MPTCP 1294 SCTP parameters: association connection state; destination 1295 transport address list; destination transport address reachability 1296 states; current local and peer receiver window size; current local 1297 congestion window sizes; number of unacknowledged DATA chunks; 1298 number of DATA chunks pending receipt; primary path; most recent 1299 SRTT on primary path; RTO on primary path; SRTT and RTO on other 1300 destination addresses; MTU per path; interleaving supported yes/no 1301 MPTCP parameters: subflow-list (identified by source-IP; source- 1302 Port; destination-IP; destination-Port) 1303 Automatable because these parameters relate to knowledge about the 1304 network, not the application. 1306 o Specify DSCP field 1307 Protocols: TCP, SCTP, UDP(-Lite) 1308 Optimizing because choosing a suitable DSCP value requires 1309 application-specific knowledge. 1310 Implementation: via SET_DSCP.TCP / SET_DSCP.SCTP / SET_DSCP.UDP(- 1311 Lite) 1313 o Notification of ICMP error message arrival 1314 Protocols: TCP, UDP(-Lite) 1315 Optimizing because these messages can inform about success or 1316 failure of functional transport features (e.g., host unreachable 1317 relates to "Connect") 1318 Implementation: via ERROR.TCP or ERROR.UDP(-Lite). 1320 o Obtain information about interleaving support 1321 Protocols: SCTP 1322 Automatable because it requires using multiple streams, but 1323 requesting multiple streams in the CONNECTION.ESTABLISHMENT 1324 category is automatable. 1325 Implementation: via a parameter in GETINTERL.SCTP. 1327 o Change authentication parameters 1328 Protocols: TCP, SCTP 1329 Functional because this has a direct influence on security. 1330 Implementation: via SET_AUTH.TCP and SET_AUTH.SCTP. 1331 Fall-back to TCP: With SCTP, this allows to adjust key_id, key, 1332 and hmac_id. With TCP, this allows to change the preferred 1333 outgoing MKT (current_key) and the preferred incoming MKT 1334 (rnext_key), respectively, for a segment that is sent on the 1335 connection. Key material must be provided in a way that is 1336 compatible with both [RFC4895] and [RFC5925]. 1337 Fall-back to UDP: not possible. 1339 o Obtain authentication information 1340 Protocols: SCTP 1341 Functional because authentication decisions may have been made by 1342 the peer, and this has an influence on the necessary application- 1343 level measures to provide a certain level of security. 1344 Implementation: via GETAUTH.SCTP. 1345 Fall-back to TCP: With SCTP, this allows to obtain key_id and a 1346 chunk list. With TCP, this allows to obtain current_key and 1347 rnext_key from a previously received segment. Key material must 1348 be provided in a way that is compatible with both [RFC4895] and 1349 [RFC5925]. 1350 Fall-back to UDP: not possible. 1352 o Reset Stream 1353 Protocols: SCTP 1354 Automatable because using multi-streaming does not require 1355 application-specific knowledge. 1356 Implementation: see Appendix A.3.2. 1358 o Notification of Stream Reset 1359 Protocols: STCP 1360 Automatable because using multi-streaming does not require 1361 application-specific knowledge. 1362 Implementation: see Appendix A.3.2. 1364 o Reset Association 1365 Protocols: SCTP 1366 Automatable because deciding to reset an association does not 1367 require application-specific knowledge. 1368 Implementation: via RESETASSOC.SCTP. 1370 o Notification of Association Reset 1371 Protocols: STCP 1372 Automatable because this notification does not relate to 1373 application-specific knowledge. 1375 o Add Streams 1376 Protocols: SCTP 1377 Automatable because using multi-streaming does not require 1378 application-specific knowledge. 1379 Implementation: see Appendix A.3.2. 1381 o Notification of Added Stream 1382 Protocols: STCP 1383 Automatable because using multi-streaming does not require 1384 application-specific knowledge. 1385 Implementation: see Appendix A.3.2. 1387 o Choose a scheduler to operate between streams of an association 1388 Protocols: SCTP 1389 Optimizing because the scheduling decision requires application- 1390 specific knowledge. However, if a TAPS system would not use this, 1391 or wrongly configure it on its own, this would only affect the 1392 performance of data transfers; the outcome would still be correct 1393 within the "best effort" service model. 1394 Implementation: using SETSTREAMSCHEDULER.SCTP. 1395 Fall-back to TCP: do nothing. 1396 Fall-back to UDP: do nothing. 1398 o Configure priority or weight for a scheduler 1399 Protocols: SCTP 1400 Optimizing because the priority or weight requires application- 1401 specific knowledge. However, if a TAPS system would not use this, 1402 or wrongly configure it on its own, this would only affect the 1403 performance of data transfers; the outcome would still be correct 1404 within the "best effort" service model. 1405 Implementation: using CONFIGURESTREAMSCHEDULER.SCTP. 1406 Fall-back to TCP: do nothing. 1407 Fall-back to UDP: do nothing. 1409 o Configure send buffer size 1410 Protocols: SCTP 1411 Automatable because this decision relates to knowledge about the 1412 network and the Operating System, not the application (see also 1413 the discussion in Appendix A.3.4). 1415 o Configure receive buffer (and rwnd) size 1416 Protocols: SCTP 1417 Automatable because this decision relates to knowledge about the 1418 network and the Operating System, not the application. 1420 o Configure message fragmentation 1421 Protocols: SCTP 1422 Automatable because fragmentation relates to knowledge about the 1423 network and the Operating System, not the application. 1424 Implementation: by always enabling it with 1425 CONFIG_FRAGMENTATION.SCTP and auto-setting the fragmentation size 1426 based on network or Operating System conditions. 1428 o Configure PMTUD 1429 Protocols: SCTP 1430 Automatable because Path MTU Discovery relates to knowledge about 1431 the network, not the application. 1433 o Configure delayed SACK timer 1434 Protocols: SCTP 1435 Automatable because the receiver-side decision to delay sending 1436 SACKs relates to knowledge about the network, not the application 1437 (it can be relevant for a sending application to request not to 1438 delay the SACK of a message, but this is a different transport 1439 feature). 1441 o Set Cookie life value 1442 Protocols: SCTP 1443 Functional because it relates to security (possibly weakened by 1444 keeping a cookie very long) versus the time between connection 1445 establishment attempts. Knowledge about both issues can be 1446 application-specific. 1448 Fall-back to TCP: the closest specified TCP functionality is the 1449 cookie in TCP Fast Open; for this, [RFC7413] states that the 1450 server "can expire the cookie at any time to enhance security" and 1451 section 4.1.2 describes an example implementation where updating 1452 the key on the server side causes the cookie to expire. 1453 Alternatively, for implementations that do not support TCP Fast 1454 Open, this transport feature could also affect the validity of SYN 1455 cookies (see Section 3.6 of [RFC4987]). 1456 Fall-back to UDP: do nothing. 1458 o Set maximum burst 1459 Protocols: SCTP 1460 Automatable because it relates to knowledge about the network, not 1461 the application. 1463 o Configure size where messages are broken up for partial delivery 1464 Protocols: SCTP 1465 Functional because this is closely tied to properties of the data 1466 that an application sends or expects to receive. 1467 Fall-back to TCP: not possible. 1468 Fall-back to UDP: not possible. 1470 o Disable checksum when sending 1471 Protocols: UDP 1472 Functional because application-specific knowledge is necessary to 1473 decide whether it can be acceptable to lose data integrity. 1474 Implementation: via SET_CHECKSUM_ENABLED.UDP. 1475 Fall-back to TCP: do nothing. 1477 o Disable checksum requirement when receiving 1478 Protocols: UDP 1479 Functional because application-specific knowledge is necessary to 1480 decide whether it can be acceptable to lose data integrity. 1481 Implementation: via SET_CHECKSUM_REQUIRED.UDP. 1482 Fall-back to TCP: do nothing. 1484 o Specify checksum coverage used by the sender 1485 Protocols: UDP-Lite 1486 Functional because application-specific knowledge is necessary to 1487 decide for which parts of the data it can be acceptable to lose 1488 data integrity. 1489 Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite. 1490 Fall-back to TCP: do nothing. 1492 o Specify minimum checksum coverage required by receiver 1493 Protocols: UDP-Lite 1494 Functional because application-specific knowledge is necessary to 1495 decide for which parts of the data it can be acceptable to lose 1496 data integrity. 1497 Implementation: via SET_MIN_CHECKSUM_COVERAGE.UDP-Lite. 1498 Fall-back to TCP: do nothing. 1500 o Specify DF field 1501 Protocols: UDP(-Lite) 1502 Optimizing because the DF field can be used to carry out Path MTU 1503 Discovery, which can lead an application to choose message sizes 1504 that can be transmitted more efficiently. 1505 Implementation: via MAINTENANCE.SET_DF.UDP(-Lite) and 1506 SEND_FAILURE.UDP(-Lite). 1507 Fall-back to TCP: do nothing. With TCP the sender is not in 1508 control of transport message sizes, making this functionality 1509 irrelevant. 1511 o Get max. transport-message size that may be sent using a non- 1512 fragmented IP packet from the configured interface 1513 Protocols: UDP(-Lite) 1514 Optimizing because this can lead an application to choose message 1515 sizes that can be transmitted more efficiently. 1516 Fall-back to TCP: do nothing: this information is not available 1517 with TCP. 1519 o Get max. transport-message size that may be received from the 1520 configured interface 1521 Protocols: UDP(-Lite) 1522 Optimizing because this can, for example, influence an 1523 application's memory management. 1524 Fall-back to TCP: do nothing: this information is not available 1525 with TCP. 1527 o Specify TTL/Hop count field 1528 Protocols: UDP(-Lite) 1529 Automatable because a TAPS system can use a large enough system 1530 default to avoid communication failures. Allowing an application 1531 to configure it differently can produce notifications of ICMP 1532 error message arrivals that yield information which only relates 1533 to knowledge about the network, not the application. 1535 o Obtain TTL/Hop count field 1536 Protocols: UDP(-Lite) 1537 Automatable because the TTL/Hop count field relates to knowledge 1538 about the network, not the application. 1540 o Specify ECN field 1541 Protocols: UDP(-Lite) 1542 Automatable because the ECN field relates to knowledge about the 1543 network, not the application. 1545 o Obtain ECN field 1546 Protocols: UDP(-Lite) 1547 Optimizing because this information can be used by an application 1548 to better carry out congestion control (this is relevant when 1549 choosing a data transmission transport service that does not 1550 already do congestion control). 1551 Fall-back to TCP: do nothing: this information is not available 1552 with TCP. 1554 o Specify IP Options 1555 Protocols: UDP(-Lite) 1556 Automatable because IP Options relate to knowledge about the 1557 network, not the application. 1559 o Obtain IP Options 1560 Protocols: UDP(-Lite) 1561 Automatable because IP Options relate to knowledge about the 1562 network, not the application. 1564 o Enable and configure a "Low Extra Delay Background Transfer" 1565 Protocols: A protocol implementing the LEDBAT congestion control 1566 mechanism 1567 Optimizing because whether this service is appropriate or not 1568 depends on application-specific knowledge. However, wrongly using 1569 this will only affect the speed of data transfers (albeit 1570 including other transfers that may compete with the TAPS transfer 1571 in the network), so it is still correct within the "best effort" 1572 service model. 1573 Implementation: via CONFIGURE.LEDBAT and/or SET_DSCP.TCP / 1574 SET_DSCP.SCTP / SET_DSCP.UDP(-Lite) [LBE-draft]. 1575 Fall-back to TCP: do nothing. 1576 Fall-back to UDP: do nothing. 1578 TERMINATION: 1580 o Close after reliably delivering all remaining data, causing an 1581 event informing the application on the other side 1582 Protocols: TCP, SCTP 1583 Functional because the notion of a connection is often reflected 1584 in applications as an expectation to have all outstanding data 1585 delivered and no longer be able to communicate after a "Close" 1586 succeeded, with a communication sequence relating to this 1587 transport feature that is defined by the application protocol. 1588 Implementation: via CLOSE.TCP and CLOSE.SCTP. 1589 Fall-back to UDP: not possible. 1591 o Abort without delivering remaining data, causing an event 1592 informing the application on the other side 1593 Protocols: TCP, SCTP 1594 Functional because the notion of a connection is often reflected 1595 in applications as an expectation to potentially not have all 1596 outstanding data delivered and no longer be able to communicate 1597 after an "Abort" succeeded. On both sides of a connection, an 1598 application protocol may define a communication sequence relating 1599 to this transport feature. 1600 Implementation: via ABORT.TCP and ABORT.SCTP. 1601 Fall-back to UDP: not possible. 1603 o Abort without delivering remaining data, not causing an event 1604 informing the application on the other side 1605 Protocols: UDP(-Lite) 1606 Functional because the notion of a connection is often reflected 1607 in applications as an expectation to potentially not have all 1608 outstanding data delivered and no longer be able to communicate 1609 after an "Abort" succeeded. On both sides of a connection, an 1610 application protocol may define a communication sequence relating 1611 to this transport feature. 1612 Implementation: via ABORT.UDP(-Lite). 1613 Fall-back to TCP: stop using the connection, wait for a timeout. 1615 o Timeout event when data could not be delivered for too long 1616 Protocols: TCP, SCTP 1617 Functional because this notifies that potentially assumed reliable 1618 data delivery is no longer provided. 1619 Implementation: via TIMEOUT.TCP and TIMEOUT.SCTP. 1620 Fall-back to UDP: do nothing: this event will not occur with UDP. 1622 A.1.2. DATA Transfer Related Transport Features 1624 A.1.2.1. Sending Data 1626 o Reliably transfer data, with congestion control 1627 Protocols: TCP, SCTP 1628 Functional because this is closely tied to properties of the data 1629 that an application sends or expects to receive. 1630 Implementation: via SEND.TCP and SEND.SCTP. 1631 Fall-back to UDP: not possible. 1633 o Reliably transfer a message, with congestion control 1634 Protocols: SCTP 1635 Functional because this is closely tied to properties of the data 1636 that an application sends or expects to receive. 1637 Implementation: via SEND.SCTP. 1638 Fall-back to TCP: via SEND.TCP. With SEND.TCP, messages will not 1639 be identifiable by the receiver. 1640 Fall-back to UDP: not possible. 1642 o Unreliably transfer a message 1643 Protocols: SCTP, UDP(-Lite) 1644 Optimizing because only applications know about the time 1645 criticality of their communication, and reliably transfering a 1646 message is never incorrect for the receiver of a potentially 1647 unreliable data transfer, it is just slower. 1648 ADDED. This differs from the 2 automatable transport features 1649 below in that it leaves the choice of congestion control open. 1650 Implementation: via SEND.SCTP or SEND.UDP(-Lite). 1651 Fall-back to TCP: use SEND.TCP. With SEND.TCP, messages will be 1652 sent reliably, and they will not be identifiable by the receiver. 1654 o Unreliably transfer a message, with congestion control 1655 Protocols: SCTP 1656 Automatable because congestion control relates to knowledge about 1657 the network, not the application. 1659 o Unreliably transfer a message, without congestion control 1660 Protocols: UDP(-Lite) 1661 Automatable because congestion control relates to knowledge about 1662 the network, not the application. 1664 o Configurable Message Reliability 1665 Protocols: SCTP 1666 Optimizing because only applications know about the time 1667 criticality of their communication, and reliably transfering a 1668 message is never incorrect for the receiver of a potentially 1669 unreliable data transfer, it is just slower. 1670 Implementation: via SEND.SCTP. 1671 Fall-back to TCP: By using SEND.TCP and ignoring this 1672 configuration: based on the assumption of the best-effort service 1673 model, unnecessarily delivering data does not violate application 1674 expectations. Moreover, it is not possible to associate the 1675 requested reliability to a "message" in TCP anyway. 1676 Fall-back to UDP: not possible. 1678 o Choice of stream 1679 Protocols: SCTP 1680 Automatable because it requires using multiple streams, but 1681 requesting multiple streams in the CONNECTION.ESTABLISHMENT 1682 category is automatable. Implementation: see Appendix A.3.2. 1684 o Choice of path (destination address) 1685 Protocols: SCTP 1686 Automatable because it requires using multiple sockets, but 1687 obtaining multiple sockets in the CONNECTION.ESTABLISHMENT 1688 category is automatable. 1690 o Ordered message delivery (potentially slower than unordered) 1691 Protocols: SCTP 1692 Functional because this is closely tied to properties of the data 1693 that an application sends or expects to receive. 1694 Implementation: via SEND.SCTP. 1695 Fall-back to TCP: By using SEND.TCP. With SEND.TCP, messages will 1696 not be identifiable by the receiver. 1697 Fall-back to UDP: not possible. 1699 o Unordered message delivery (potentially faster than ordered) 1700 Protocols: SCTP, UDP(-Lite) 1701 Functional because this is closely tied to properties of the data 1702 that an application sends or expects to receive. 1703 Implementation: via SEND.SCTP. 1704 Fall-back to TCP: By using SEND.TCP and always sending data 1705 ordered: based on the assumption of the best-effort service model, 1706 ordered delivery may just be slower and does not violate 1707 application expectations. Moreover, it is not possible to 1708 associate the requested delivery order to a "message" in TCP 1709 anyway. 1711 o Request not to bundle messages 1712 Protocols: SCTP 1713 Optimizing because this decision depends on knowledge about the 1714 size of future data blocks and the delay between them. 1715 Implementation: via SEND.SCTP. 1716 Fall-back to TCP: By using SEND.TCP and DISABLE-NAGLE.TCP to 1717 disable the Nagle algorithm when the request is made and enable it 1718 again when the request is no longer made. Note that this is not 1719 fully equivalent because it relates to the time of issuing the 1720 request rather than a specific message. 1721 Fall-back to UDP: do nothing (UDP never bundles messages). 1723 o Specifying a "payload protocol-id" (handed over as such by the 1724 receiver) 1725 Protocols: SCTP 1726 Functional because it allows to send extra application data with 1727 every message, for the sake of identification of data, which by 1728 itself is application-specific. 1729 Implementation: SEND.SCTP. 1730 Fall-back to TCP: not possible. 1731 Fall-back to UDP: not possible. 1733 o Specifying a key id to be used to authenticate a message 1734 Protocols: SCTP 1735 Functional because this has a direct influence on security. 1736 Implementation: via a parameter in SEND.SCTP. 1737 Fall-back to TCP: This could be emulated by using SET_AUTH.TCP 1738 before and after the message is sent. Note that this is not fully 1739 equivalent because it relates to the time of issuing the request 1740 rather than a specific message. 1741 Fall-back to UDP: not possible. 1743 o Request not to delay the acknowledgement (SACK) of a message 1744 Protocols: SCTP 1745 Optimizing because only an application knows for which message it 1746 wants to quickly be informed about success / failure of its 1747 delivery. 1748 Fall-back to TCP: do nothing. 1749 Fall-back to UDP: do nothing. 1751 A.1.2.2. Receiving Data 1753 o Receive data (with no message delimiting) 1754 Protocols: TCP 1755 Functional because a TAPS system must be able to send and receive 1756 data. 1757 Implementation: via RECEIVE.TCP. 1758 Fall-back to UDP: do nothing (hand over a message, let the 1759 application ignore frame boundaries). 1761 o Receive a message 1762 Protocols: SCTP, UDP(-Lite) 1763 Functional because this is closely tied to properties of the data 1764 that an application sends or expects to receive. 1765 Implementation: via RECEIVE.SCTP and RECEIVE.UDP(-Lite). 1766 Fall-back to TCP: not possible. 1768 o Choice of stream to receive from 1769 Protocols: SCTP 1770 Automatable because it requires using multiple streams, but 1771 requesting multiple streams in the CONNECTION.ESTABLISHMENT 1772 category is automatable. 1773 Implementation: see Appendix A.3.2. 1775 o Information about partial message arrival 1776 Protocols: SCTP 1777 Functional because this is closely tied to properties of the data 1778 that an application sends or expects to receive. 1779 Implementation: via RECEIVE.SCTP. 1780 Fall-back to TCP: do nothing: this information is not available 1781 with TCP. 1782 Fall-back to UDP: do nothing: this information is not available 1783 with UDP. 1785 A.1.2.3. Errors 1787 This section describes sending failures that are associated with a 1788 specific call to in the "Sending Data" category (Appendix A.1.2.1). 1790 o Notification of send failures 1791 Protocols: SCTP, UDP(-Lite) 1792 Functional because this notifies that potentially assumed reliable 1793 data delivery is no longer provided. 1794 ADDED. This differs from the 2 automatable transport features 1795 below in that it does not distinugish between unsent and 1796 unacknowledged messages. 1797 Implementation: via SENDFAILURE-EVENT.SCTP and SEND_FAILURE.UDP(- 1798 Lite). 1799 Fall-back to TCP: do nothing: this notification is not available 1800 and will therefore not occur with TCP. 1802 o Notification of an unsent (part of a) message 1803 Protocols: SCTP, UDP(-Lite) 1804 Automatable because the distinction between unsent and 1805 unacknowledged is network-specific. 1807 o Notification of an unacknowledged (part of a) message 1808 Protocols: SCTP 1809 Automatable because the distinction between unsent and 1810 unacknowledged is network-specific. 1812 o Notification that the stack has no more user data to send 1813 Protocols: SCTP 1814 Optimizing because reacting to this notification requires the 1815 application to be involved, and ensuring that the stack does not 1816 run dry of data (for too long) can improve performance. 1817 Fall-back to TCP: do nothing. See also the discussion in 1818 Appendix A.3.4. 1819 Fall-back to UDP: do nothing. This notification is not available 1820 and will therefore not occur with UDP. 1822 o Notification to a receiver that a partial message delivery has 1823 been aborted 1824 Protocols: SCTP 1825 Functional because this is closely tied to properties of the data 1826 that an application sends or expects to receive. 1827 Fall-back to TCP: do nothing. This notification is not available 1828 and will therefore not occur with TCP. 1829 Fall-back to UDP: do nothing. This notification is not available 1830 and will therefore not occur with UDP. 1832 A.2. Step 2: Reduction -- The Reduced Set of Transport Features 1834 By hiding automatable transport features from the application, a TAPS 1835 system can gain opportunities to automate the usage of network- 1836 related functionality. This can facilitate using the TAPS system for 1837 the application programmer and it allows for optimizations that may 1838 not be possible for an application. For instance, system-wide 1839 configurations regarding the usage of multiple interfaces can better 1840 be exploited if the choice of the interface is not entirely up to the 1841 application. Therefore, since they are not strictly necessary to 1842 expose in a TAPS system, we do not include automatable transport 1843 features in the reduced set of transport features. This leaves us 1844 with only the transport features that are either optimizing or 1845 functional. 1847 A TAPS system should be able to fall back to TCP or UDP if 1848 alternative transport protocols are found not to work. For many 1849 transport features, this is possible -- often by simply not doing 1850 anything. For some transport features, however, it was identified 1851 that neither a fall-back to TCP nor a fall-back to UDP is possible: 1852 in these cases, even not doing anything would incur semantically 1853 incorrect behavior. Whenever an application would make use of one of 1854 these transport features, this would eliminate the possibility to use 1855 TCP or UDP. Thus, we only keep the functional and optimizing 1856 transport features for which a fall-back to either TCP or UDP is 1857 possible in our reduced set. 1859 In the following list, we precede a transport feature with "T:" if a 1860 fall-back to TCP is possible, "U:" if a fall-back to UDP is possible, 1861 and "TU:" if a fall-back to either TCP or UDP is possible. 1863 A.2.1. CONNECTION Related Transport Features 1865 ESTABLISHMENT: 1867 o T,U: Connect 1868 o T,U: Specify number of attempts and/or timeout for the first 1869 establishment message 1870 o T: Configure authentication 1871 o T: Hand over a message to reliably transfer (possibly multiple 1872 times) before connection establishment 1873 o T: Hand over a message to reliably transfer during connection 1874 establishment 1876 AVAILABILITY: 1878 o T,U: Listen 1879 o T: Configure authentication 1881 MAINTENANCE: 1883 o T: Change timeout for aborting connection (using retransmit limit 1884 or time value) 1885 o T: Suggest timeout to the peer 1886 o T,U: Disable Nagle algorithm 1887 o T,U: Notification of Excessive Retransmissions (early warning 1888 below abortion threshold) 1890 o T,U: Specify DSCP field 1891 o T,U: Notification of ICMP error message arrival 1892 o T: Change authentication parameters 1893 o T: Obtain authentication information 1894 o T,U: Set Cookie life value 1895 o T,U: Choose a scheduler to operate between streams of an 1896 association 1897 o T,U: Configure priority or weight for a scheduler 1898 o T,U: Disable checksum when sending 1899 o T,U: Disable checksum requirement when receiving 1900 o T,U: Specify checksum coverage used by the sender 1901 o T,U: Specify minimum checksum coverage required by receiver 1902 o T,U: Specify DF field 1903 o T,U: Get max. transport-message size that may be sent using a non- 1904 fragmented IP packet from the configured interface 1905 o T,U: Get max. transport-message size that may be received from the 1906 configured interface 1907 o T,U: Obtain ECN field 1908 o T,U: Enable and configure a "Low Extra Delay Background Transfer" 1910 TERMINATION: 1912 o T: Close after reliably delivering all remaining data, causing an 1913 event informing the application on the other side 1914 o T: Abort without delivering remaining data, causing an event 1915 informing the application on the other side 1916 o T,U: Abort without delivering remaining data, not causing an event 1917 informing the application on the other side 1918 o T,U: Timeout event when data could not be delivered for too long 1920 A.2.2. DATA Transfer Related Transport Features 1922 A.2.2.1. Sending Data 1924 o T: Reliably transfer data, with congestion control 1925 o T: Reliably transfer a message, with congestion control 1926 o T,U: Unreliably transfer a message 1927 o T: Configurable Message Reliability 1928 o T: Ordered message delivery (potentially slower than unordered) 1929 o T,U: Unordered message delivery (potentially faster than ordered) 1930 o T,U: Request not to bundle messages 1931 o T: Specifying a key id to be used to authenticate a message 1932 o T,U: Request not to delay the acknowledgement (SACK) of a message 1934 A.2.2.2. Receiving Data 1936 o T,U: Receive data (with no message delimiting) 1937 o U: Receive a message 1938 o T,U: Information about partial message arrival 1940 A.2.2.3. Errors 1942 This section describes sending failures that are associated with a 1943 specific call to in the "Sending Data" category (Appendix A.1.2.1). 1945 o T,U: Notification of send failures 1946 o T,U: Notification that the stack has no more user data to send 1947 o T,U: Notification to a receiver that a partial message delivery 1948 has been aborted 1950 A.3. Step 3: Discussion 1952 The reduced set in the previous section exhibits a number of 1953 peculiarities, which we will discuss in the following. This section 1954 focuses on TCP because, with the exception of one particular 1955 transport feature ("Receive a message" -- we will discuss this in 1956 Appendix A.3.1), the list shows that UDP is strictly a subset of TCP. 1957 We can first try to understand how to build a TAPS system that is 1958 able to fall back to TCP, and then narrow down the result further to 1959 allow that the system can always fall back to either TCP or UDP 1960 (which effectively means removing everything related to reliability, 1961 ordering, authentication and closing/aborting with a notification to 1962 the peer). 1964 Note that, because the functional transport features of UDP are -- 1965 with the exception of "Receive a message" -- a subset of TCP, TCP can 1966 be used as a fall-back for UDP whenever an application does not need 1967 message delimiting (e.g., because the application-layer protocol 1968 already does it). This has been recognized by many applications that 1969 already do this in practice, by trying to communicate with UDP at 1970 first, and falling back to TCP in case of a connection failure. 1972 A.3.1. Sending Messages, Receiving Bytes 1974 When considering to fall back to TCP, there are several transport 1975 features related to sending, but only a single transport feature 1976 related to receiving: "Receive data (with no message delimiting)" 1977 (and, strangely, "information about partial message arrival"). 1978 Notably, the transport feature "Receive a message" is also the only 1979 non-automatable transport feature of UDP(-Lite) for which no fall- 1980 back to TCP is possible. 1982 To support these TCP receiver semantics, we define an "Application- 1983 Framed Bytestream" (AFra-Bytestream). AFra-Bytestreams allow senders 1984 to operate on messages while minimizing changes to the TCP socket 1985 API. In particular, nothing changes on the receiver side - data can 1986 be accepted via a normal TCP socket. 1988 In an AFra-Bytestream, the sending application can optionally inform 1989 the transport about frame boundaries and required properties per 1990 frame (configurable order and reliability, or embedding a request not 1991 to delay the acknowledgement of a frame). Whenever the sending 1992 application specifies per-frame properties that relax the notion of 1993 reliable in-order delivery of bytes, it must assume that the 1994 receiving application is 1) able to determine frame boundaries, 1995 provided that frames are always kept intact, and 2) able to accept 1996 these relaxed per-frame properties. Any signaling of such 1997 information to the peer is up to an application-layer protocol and 1998 considered out of scope of this document. 2000 For example, if an application requests to transfer fixed-size 2001 messages of 100 bytes with partial reliability, this needs the 2002 receiving application to be prepared to accept data in chunks of 100 2003 bytes. If, then, some of these 100-byte messages are missing (e.g., 2004 if SCTP with Configurable Reliability is used), this is the expected 2005 application behavior. With TCP, no messages would be missing, but 2006 this is also correct for the application, and the possible 2007 retransmission delay is acceptable within the best effort service 2008 model. Still, the receiving application would separate the byte 2009 stream into 100-byte chunks. 2011 Note that this usage of messages does not require all messages to be 2012 equal in size. Many application protocols use some form of Type- 2013 Length-Value (TLV) encoding, e.g. by defining a header including 2014 length fields; another alternative is the use of byte stuffing 2015 methods such as COBS [COBS]. If an application needs message 2016 numbers, e.g. to restore the correct sequence of messages, these must 2017 also be encoded by the application itself, as the sequence number 2018 related transport features of SCTP are no longer provided (in the 2019 interest of enabling a fall-back to TCP). 2021 For the implementation of a TAPS system, this has the following 2022 consequences: 2024 o Because the receiver-side transport leaves it up to the 2025 application to delimit messages, messages must always remain 2026 intact as they are handed over by the transport receiver. Data 2027 can be handed over at any time as they arrive, but the byte stream 2028 must never "skip ahead" to the beginning of the next message. 2030 o With SCTP, a "partial flag" informs a receiving application that a 2031 message is incomplete. Then, the next receive calls will only 2032 deliver remaining parts of the same message (i.e., no messages or 2033 partial messages will arrive on other streams until the message is 2034 complete) (see Section 8.1.20 in [RFC6458]). This can facilitate 2035 the implementation of the receiver buffer in the receiving 2036 application, but then such an application does not support message 2037 interleaving (which is required by stream schedulers). However, 2038 receiving a byte stream from multiple SCTP streams requires a per- 2039 stream receiver buffer anyway, so this potential benefit is lost 2040 and the "partial flag" (the transport feature "Information about 2041 partial message arrival") becomes unnecessary for a TAPS system. 2042 With it, the transport feature "Notification to a receiver that a 2043 partial message delivery has been aborted" becomes unnecessary 2044 too. 2045 o From the above, a TAPS system should always support message 2046 interleaving because it enables the use of stream schedulers and 2047 comes at no additional implementation cost on the receiver side. 2048 Stream schedulers operate on the sender side. Hence, because a 2049 TAPS sender-side application may talk to an SCTP receiver that 2050 does not support interleaving, it cannot assume that stream 2051 schedulers will always work as expected. 2053 A.3.2. Stream Schedulers Without Streams 2055 We have already stated that multi-streaming does not require 2056 application-specific knowledge. Potential benefits or disadvantages 2057 of, e.g., using two streams over an SCTP association versus using two 2058 separate SCTP associations or TCP connections are related to 2059 knowledge about the network and the particular transport protocol in 2060 use, not the application. However, the transport features "Choose a 2061 scheduler to operate between streams of an association" and 2062 "Configure priority or weight for a scheduler" operate on streams. 2063 Here, streams identify communication channels between which a 2064 scheduler operates, and they can be assigned a priority. Moreover, 2065 the transport features in the MAINTENANCE category all operate on 2066 assocations in case of SCTP, i.e. they apply to all streams in that 2067 assocation. 2069 With only these semantics necessary to represent, the interface to a 2070 TAPS system becomes easier if we rename connections into "TAPS flows" 2071 (the TAPS equivalent of a connection which may be a transport 2072 connection or association, but could also become a stream of an 2073 existing SCTP association, for example) and allow assigning a "Group 2074 Number" to a TAPS flow. Then, all MAINTENANCE transport features can 2075 be said to operate on flow groups, not connections, and a scheduler 2076 also operates on the flows within a group. 2078 For the implementation of a TAPS system, this has the following 2079 consequences: 2081 o Streams may be identified in different ways across different 2082 protocols. The only multi-streaming protocol considered in this 2083 document, SCTP, uses a stream id. The transport association below 2084 still uses a Transport Address (which includes one port number) 2085 for each communicating endpoint. To implement a TAPS system 2086 without exposed streams, an application must be given an 2087 identifier for each TAPS flow (akin to a socket), and depending on 2088 whether streams are used or not, there will be a 1:1 mapping 2089 between this identifier and local ports or not. 2090 o In SCTP, a fixed number of streams exists from the beginning of an 2091 association; streams are not "established", there is no handshake 2092 or any other form of signaling to create them: they can just be 2093 used. They are also not "gracefully shut down" -- at best, an 2094 "SSN Reset Request Parameter" in a "RE-CONFIG" chunk [RFC6525] can 2095 be used to inform the peer that of a "Stream Reset", as a rough 2096 equivalent of an "Abort". This has an impact on the semantics 2097 connection establishment and teardown (see Section 3.2). 2098 o To support stream schedulers, a receiver-side TAPS system should 2099 always support message interleaving because it comes at no 2100 additional implementation cost (because of the receiver-side 2101 stream reception discussed in Appendix A.3.1). Note, however, 2102 that Stream schedulers operate on the sender side. Hence, because 2103 a TAPS sender-side application may talk to a native TCP-based 2104 receiver-side application, it cannot assume that stream schedulers 2105 will always work as expected. 2107 A.3.3. Early Data Transmission 2109 There are two transport features related to transferring a message 2110 early: "Hand over a message to reliably transfer (possibly multiple 2111 times) before connection establishment", which relates to TCP Fast 2112 Open [RFC7413], and "Hand over a message to reliably transfer during 2113 connection establishment", which relates to SCTP's ability to 2114 transfer data together with the COOKIE-Echo chunk. Also without TCP 2115 Fast Open, TCP can transfer data during the handshake, together with 2116 the SYN packet -- however, the receiver of this data may not hand it 2117 over to the application until the handshake has completed. Also, 2118 different from TCP Fast Open, this data is not delimited as a message 2119 by TCP (thus, not visible as a ``message''). This functionality is 2120 commonly available in TCP and supported in several implementations, 2121 even though the TCP specification does not explain how to provide it 2122 to applications. 2124 A TAPS system could differentiate between the cases of transmitting 2125 data "before" (possibly multiple times) or during the handshake. 2127 Alternatively, it could also assume that data that are handed over 2128 early will be transmitted as early as possible, and "before" the 2129 handshake would only be used for data that are explicitly marked as 2130 "idempotent" (i.e., it would be acceptable to transfer it multiple 2131 times). 2133 The amount of data that can successfully be transmitted before or 2134 during the handshake depends on various factors: the transport 2135 protocol, the use of header options, the choice of IPv4 and IPv6 and 2136 the Path MTU. A TAPS system should therefore allow a sending 2137 application to query the maximum amount of data it can possibly 2138 transmit before (or, if exposed, during) connection establishment. 2140 A.3.4. Sender Running Dry 2142 The transport feature "Notification that the stack has no more user 2143 data to send" relates to SCTP's "SENDER DRY" notification. Such 2144 notifications can, in principle, be used to avoid having an 2145 unnecessarily large send buffer, yet ensure that the transport sender 2146 always has data available when it has an opportunity to transmit it. 2147 This has been found to be very beneficial for some applications 2148 [WWDC2015]. However, "SENDER DRY" truly means that the entire send 2149 buffer (including both unsent and unacknowledged data) has emptied -- 2150 i.e., when it notifies the sender, it is already too late, the 2151 transport protocol already missed an opportunity to send data. Some 2152 modern TCP implementations now include the unspecified 2153 "TCP_NOTSENT_LOWAT" socket option proposed in [WWDC2015], which 2154 limits the amount of unsent data that TCP can keep in the socket 2155 buffer; this allows to specify at which buffer filling level the 2156 socket becomes writable, rather than waiting for the buffer to run 2157 empty. 2159 SCTP allows to configure the sender-side buffer too: the automatable 2160 Transport Feature "Configure send buffer size" provides this 2161 functionality, but only for the complete buffer, which includes both 2162 unsent and unacknowledged data. SCTP does not allow to control these 2163 two sizes separately. A TAPS system should allow for uniform access 2164 to "TCP_NOTSENT_LOWAT" as well as the "SENDER DRY" notification. 2166 A.3.5. Capacity Profile 2168 The transport features: 2170 o Disable Nagle algorithm 2171 o Enable and configure a "Low Extra Delay Background Transfer" 2172 o Specify DSCP field 2173 all relate to a QoS-like application need such as "low latency" or 2174 "scavenger". In the interest of flexibility of a TAPS system, they 2175 could therefore be offered in a uniform, more abstract way, where a 2176 TAPS system could e.g. decide by itself how to use combinations of 2177 LEDBAT-like congestion control and certain DSCP values, and an 2178 application would only specify a general "capacity profile" (a 2179 description of how it wants to use the available capacity). A need 2180 for "lowest possible latency at the expense of overhead" could then 2181 translate into automatically disabling the Nagle algorithm. 2183 In some cases, the Nagle algorithm is best controlled directly by the 2184 application because it is not only related to a general profile but 2185 also to knowledge about the size of future messages. For fine-grain 2186 control over Nagle-like functionality, the "Request not to bundle 2187 messages" is available. 2189 A.3.6. Security 2191 Both TCP and SCTP offer authentication. TCP authenticates complete 2192 segments. SCTP allows to configure which of SCTP's chunk types must 2193 always be authenticated -- if this is exposed as such, it creates an 2194 undesirable dependency on the transport protocol. For compatibility 2195 with TCP, a TAPS system should only allow to configure complete 2196 transport layer packets, including headers, IP pseudo-header (if any) 2197 and payload. 2199 Security is discussed in a separate TAPS document 2200 [I-D.pauly-taps-transport-security]. The minimal set presented in 2201 the present document therefore excludes all security related 2202 transport features: "Configure authentication", "Change 2203 authentication parameters", "Obtain authentication information" and 2204 and "Set Cookie life value" as well as "Specifying a key id to be 2205 used to authenticate a message". 2207 A.3.7. Packet Size 2209 UDP(-Lite) has a transport feature called "Specify DF field". This 2210 yields an error message in case of sending a message that exceeds the 2211 Path MTU, which is necessary for a UDP-based application to be able 2212 to implement Path MTU Discovery (a function that UDP-based 2213 applications must do by themselves). The "Get max. transport-message 2214 size that may be sent using a non-fragmented IP packet from the 2215 configured interface" transport feature yields an upper limit for the 2216 Path MTU (minus headers) and can therefore help to implement Path MTU 2217 Discovery more efficiently. 2219 This also relates to the fact that the choice of path is automatable: 2220 if a TAPS system can switch a path at any time, unknown to an 2221 application, yet the application intends to do Path MTU Discovery, 2222 this could yield a very inefficient behavior. Thus, a TAPS system 2223 should probably avoid automatically switching paths, and inform the 2224 application about any unavoidable path changes, when applications 2225 request to disallow fragmentation with the "Specify DF field" 2226 feature. 2228 Appendix B. Revision information 2230 XXX RFC-Ed please remove this section prior to publication. 2232 -02: implementation suggestions added, discussion section added, 2233 terminology extended, DELETED category removed, various other fixes; 2234 list of Transport Features adjusted to -01 version of [TAPS2] except 2235 that MPTCP is not included. 2237 -03: updated to be consistent with -02 version of [TAPS2]. 2239 -04: updated to be consistent with -03 version of [TAPS2]. 2240 Reorganized document, rewrote intro and conclusion, and made a first 2241 stab at creating a real "minimal set". 2243 -05: updated to be consistent with -05 version of [TAPS2] (minor 2244 changes). Fixed a mistake regarding Cookie Life value. Exclusion of 2245 security related transport features (to be covered in a separate 2246 document). Reorganized the document (now begins with the minset, 2247 derivation is in the appendix). First stab at an abstract API for 2248 the minset. 2250 draft-ietf-taps-minset-00: updated to be consistent with -08 version 2251 of [TAPS2] ("obtain message delivery number" was removed, as this has 2252 also been removed in [TAPS2] because it was a mistake in RFC4960. 2253 This led to the removal of two more transport features that were only 2254 designated as functional because they affected "obtain message 2255 delivery number"). Fall-back to UDP incorporated (this was requested 2256 at IETF-99); this also affected the transport feature "Choice between 2257 unordered (potentially faster) or ordered delivery of messages" 2258 because this is a boolean which is always true for one fall-back 2259 protocol, and always false for the other one. This was therefore now 2260 divided into two features, one for ordered, one for unordered 2261 delivery. The word "reliably" was added to the transport features 2262 "Hand over a message to reliably transfer (possibly multiple times) 2263 before connection establishment" and "Hand over a message to reliably 2264 transfer during connection establishment" to make it clearer why this 2265 is not supported by UDP. Clarified that the "minset abstract 2266 interface" is not proposing a specific API for all TAPS systems to 2267 implement, but it is just a way to describe the minimum set. Author 2268 order changed. 2270 Authors' Addresses 2272 Michael Welzl 2273 University of Oslo 2274 PO Box 1080 Blindern 2275 Oslo N-0316 2276 Norway 2278 Phone: +47 22 85 24 20 2279 Email: michawe@ifi.uio.no 2281 Stein Gjessing 2282 University of Oslo 2283 PO Box 1080 Blindern 2284 Oslo N-0316 2285 Norway 2287 Phone: +47 22 85 24 44 2288 Email: steing@ifi.uio.no