idnits 2.17.1 draft-gjessing-taps-minset-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- 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 31, 2016) is 2733 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SUBCATEGORY' is mentioned on line 162, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-taps-transports-12 == Outdated reference: A later version (-09) exists of draft-ietf-taps-transports-usage-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TAPS S. Gjessing 3 Internet-Draft M. Welzl 4 Intended status: Informational University of Oslo 5 Expires: May 4, 2017 October 31, 2016 7 A Minimal Set of Transport Services for TAPS Systems 8 draft-gjessing-taps-minset-03 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 services given in the TAPS document draft- 16 ietf-taps-transports-usage-02. 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 http://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 May 4, 2017. 35 Copyright Notice 37 Copyright (c) 2016 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 (http://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 Superset of Transport Service Features . . . . . . . . . 5 55 3.1. CONNECTION Related Transport Service Features . . . . . . 5 56 3.2. DATA Transfer Related Transport Service Features . . . . 15 57 3.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 15 58 3.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 17 59 3.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . 18 60 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 19 61 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 19 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 65 9. Informative References . . . . . . . . . . . . . . . . . . . 21 66 Appendix A. Revision information . . . . . . . . . . . . . . . . 21 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 69 1. Introduction 71 An application has an intended usage and demands for transport 72 services, and the task of any system that implements TAPS is to offer 73 these services to its applications, i.e. the applications running on 74 top of TAPS, without binding an application to a particular transport 75 protocol. 77 The present draft is based on [TAPS1] and [TAPS2] and follows the 78 same terminology (also listed below). The purpose of these two 79 drafts is, according to the TAPS charter, to "Define a set of 80 Transport Services, identifying the services provided by existing 81 IETF protocols and congestion control mechanisms." This is item 1 in 82 the list of working group tasks. Also according to the TAPS charter, 83 the working group will then "Specify the subset of those Transport 84 Services, as identified in item 1, that end systems supporting TAPS 85 will provide, and give guidance on choosing among available 86 mechanisms and protocols. Note that not all the capabilities of IETF 87 Transport protocols need to be exposed as Transport Services." Hence 88 it is necessary to minimize the number of services that are offered. 89 We begin this by grouping the transport service features. 91 Following [TAPS2], we divide the transport service features into two 92 main groups as follows: 94 1. CONNECTION related transport service features 95 - ESTABLISHMENT 96 - AVAILABILITY 97 - MAINTENANCE 98 - TERMINATION 100 2. DATA Transfer Related transport service features 101 - Sending Data 102 - Receiving Data 103 - Errors 105 Because QoS is out of scope of TAPS, this document assumes a "best 106 effort" service model [RFC5290], [RFC7305]. Applications using a 107 TAPS system can therefore not make any assumptions about e.g. the 108 time it will take to send a message. It also assumes that TAPS 109 applications have no specific requirements that need knowledge about 110 the network, e.g. regarding the choice of network interface or the 111 end-to-end path. Even with these assumptions, there are certain 112 requirements that are strictly kept by transport protocols today, and 113 these must also be kept by a TAPS system. Some of these requirements 114 relate to transport service features that we call "Functional". 116 Functional transport service features provide functionality that 117 cannot be used without the application knowing about them, or else 118 they violate assumptions that might cause the application to fail. 119 For example, unordered message delivery is a functional transport 120 service feature: it cannot be used without the application knowing 121 about it because the application's assumption could be that messages 122 arrive in order. Failure includes any change of the application 123 behavior that is not performance oriented, e.g. security. 125 "Change DSCP" and "Disable Nagle algorithm" are what we call 126 "Optimizing" transport service features: if a TAPS system 127 autonomously decides to enable or disable them, an application will 128 not fail, but a TAPS system may be able to communicate more 129 efficiently if the application is in control of this optimizing 130 transport service feature. "Change DSCP" and "Disable Nagle 131 algorithm" are examples of transport service features that require 132 application-specific knowledge (about delay/bandwidth requirements 133 and the length of future data blocks that are to be transmitted, 134 respectively). 136 To summarize, transport service features that this memo recommends to 137 offer to applications are divided into two groups as follows: 139 o Functional 140 This transport service feature has to be specified by the 141 application, since if not, it cannot be used or the application 142 may fail (e.g. crash or be less secure). 143 o Optimizing 144 This transport service feature may be specified by the 145 application, and when specified can optimize the performance. 147 The transport service features of IETF transport protocols that are 148 not exposed to the TAPS user because they include functionality that 149 could be transparently utilized by a TAPS system are called 150 "Automatable". 152 Finally, some transport service features are aggregated or slightly 153 changed in the TAPS API. These transport service features are marked 154 as "ADDED". The corresponding transport service feature(s) is/are 155 automatable, and they are listed immediately below the "ADDED" 156 transport service feature. 158 This document also sketches how some of the TAPS transport services 159 can be implemented. Wherever it is not obvious how to implement a 160 service via TCP or UDP, a brief discussion is included. IETF 161 transport services are presented following the nomenclature 162 "CATEGORY.[SUBCATEGORY].SERVICENAME.PROTOCOL". The PROTOCOL name 163 "UDP(-Lite)" is used when transport service features are equivalent 164 for UDP and UDP-Lite; the PROTOCOL name "TCP" refers to both TCP and 165 MPTCP. 167 2. Terminology 169 The following terms are used throughout this document, and in 170 subsequent documents produced by TAPS that describe the composition 171 and decomposition of transport services. 173 Transport Service Feature: a specific end-to-end feature that the 174 transport layer provides to an application. Examples include 175 confidentiality, reliable delivery, ordered delivery, message- 176 versus-stream orientation, etc. 177 Transport Service: a set of Transport Features, without an 178 association to any given framing protocol, which provides a 179 complete service to an application. 180 Transport Protocol: an implementation that provides one or more 181 different transport services using a specific framing and header 182 format on the wire. 183 Transport Service Instance: an arrangement of transport protocols 184 with a selected set of features and configuration parameters that 185 implements a single transport service, e.g., a protocol stack (RTP 186 over UDP). 187 Application: an entity that uses the transport layer for end-to-end 188 delivery data across the network (this may also be an upper layer 189 protocol or tunnel encapsulation). 190 Application-specific knowledge: knowledge that only applications 191 have. 193 Endpoint: an entity that communicates with one or more other 194 endpoints using a transport protocol. 195 Connection: shared state of two or more endpoints that persists 196 across messages that are transmitted between these endpoints. 197 Socket: the combination of a destination IP address and a 198 destination port number. 200 3. The Superset of Transport Service Features 202 This section is based on the classification of the transport service 203 features in pass 3 of [TAPS2]. For every transport service feature, 204 a brief explanation of the classification is provided. Some more 205 general decisions affect multiple transport service features (e.g. 206 the decision that multi-streaming is automatable); the rationale for 207 such decisions is provided in Section 4. 209 3.1. CONNECTION Related Transport Service Features 211 ESTABLISHMENT: 213 o Connect 214 Protocols: TCP, SCTP, UDP(-Lite) 215 Functional because the notion of a connection is often reflected 216 in applications as an expectation to be able to communicate after 217 a "Connect" succeeded, with a communication sequence relating to 218 this transport service feature that is defined by the application 219 protocol. 220 Implementation: via CONNECT.TCP, CONNECT.SCTP or CONNECT.UDP(- 221 Lite). 223 o Specify which IP Options must always be used 224 Protocols: TCP 225 Automatable because IP Options relate to knowledge about the 226 network, not the application. 228 o Request multiple streams 229 Protocols: SCTP 230 Automatable because using multi-streaming does not require 231 application-specific knowledge. 232 Implementation: see Section 4. 234 o Obtain multiple sockets 235 Protocols: SCTP 236 Automatable because the usage of multiple paths to communicate to 237 the same end host relates to knowledge about the network, not the 238 application. 239 Implementation: see Section 4. 241 o Disable MPTCP 242 Protocols: MPTCP 243 Automatable because the usage of multiple paths to communicate to 244 the same end host relates to knowledge about the network, not the 245 application. 247 o Specify which chunk types must always be authenticated 248 Protocols: SCTP 249 Optimizing because a TAPS system could always authenticate all 250 chunk types; knowing which chunk types an application does not 251 care to have authenticated can then improve the performance. 253 o Indicate an Adaptation Layer (via an adaptation code point) 254 Protocols: SCTP 255 Functional because it allows to send extra data for the sake of 256 identifying an adaptation layer, which by itself is application- 257 specific. 259 AVAILABILITY: 261 o Listen 262 Protocols: TCP, SCTP, UDP(-Lite) 263 Functional because the notion of accepting connection requests is 264 often reflected in applications as an expectation to be able to 265 communicate after a "Listen" succeeded, with a communication 266 sequence relating to this transport service feature that is 267 defined by the application protocol. 268 ADDED. This differs from the 3 automatable transport service 269 features below in that it leaves the choice of interfaces for 270 listening open. 271 Implementation: by listening on all interfaces via LISTEN.TCP (not 272 providing a local IP address) or LISTEN.SCTP (providing SCTP port 273 number / address pairs for all local IP addresses). 275 o Listen, 1 specified local interface 276 Protocols: TCP, SCTP, UDP(-Lite) 277 Automatable because decisions about local interfaces relate to 278 knowledge about the network and the Operating System, not the 279 application. 281 o Listen, N specified local interfaces 282 Protocols: SCTP, UDP(-Lite) 283 Automatable because decisions about local interfaces relate to 284 knowledge about the network and the Operating System, not the 285 application. 287 o Listen, all local interfaces 288 Protocols: TCP, SCTP, UDP(-Lite) 289 Automatable because decisions about local interfaces relate to 290 knowledge about the network and the Operating System, not the 291 application. 293 o Specify which IP Options must always be used 294 Protocols: TCP 295 Automatable because IP Options relate to knowledge about the 296 network, not the application. 298 o Disable MPTCP 299 Protocols: MPTCP 300 Automatable because the usage of multiple paths to communicate to 301 the same end host relates to knowledge about the network, not the 302 application. 304 o Specify which chunk types must always be authenticated 305 Protocols: SCTP 306 Optimizing because a TAPS system could always authenticate all 307 chunk types; knowing which chunk types an application does not 308 care to have authenticated can then improve the performance. 310 o Obtain requested number of streams 311 Protocols: SCTP 312 Automatable because using multi-streaming does not require 313 application-specific knowledge. 314 Implementation: see Section 4. 316 o Indicate an Adaptation Layer (via an adaptation code point) 317 Protocols: SCTP 318 Functional because it allows to send extra data for the sake of 319 identifying an adaptation layer, which by itself is application- 320 specific. 322 MAINTENANCE: 324 o Change timeout for aborting connection (using retransmit limit or 325 time value) 326 Protocols: TCP, SCTP 327 Functional because this is closely related to potentially assumed 328 reliable data delivery. 329 Implementation: via CHANGE-TIMEOUT.TCP or CHANGE-TIMEOUT.SCTP. 331 o Control advertising timeout for aborting connection to remote 332 endpoint 333 Protocols: TCP 334 Functional because this is closely related to potentially assumed 335 reliable data delivery. 337 o Disable Nagle algorithm 338 Protocols: TCP, SCTP 339 Optimizing because this decision depends on knowledge about the 340 size of future data blocks and the delay between them. 341 Implementation: via DISABLE-NAGLE.TCP and [**Not yet included in 342 [TAPS2] FOR SCTP**]. 344 o Request an immediate heartbeat, returning success/failure 345 Protocols: SCTP 346 Automatable because this informs about network-specific knowledge. 348 o Set protocol parameters 349 Protocols: SCTP 350 SCTP parameters: RTO.Initial; RTO.Min; RTO.Max; Max.Burst; 351 RTO.Alpha; RTO.Beta; Valid.Cookie.Life; Association.Max.Retrans; 352 Path.Max.Retrans; Max.Init.Retransmits; HB.interval; HB.Max.Burst; 353 PotentiallyFailed.Max.Retrans; Primary.Switchover.Max.Retrans; 354 Remote.UDPEncapsPort 355 Automatable because these parameters relate to knowledge about the 356 network, not the application. 358 o Notification of Excessive Retransmissions (early warning below 359 abortion threshold) 360 Protocols: TCP 361 Optimizing because it is an early warning to the application, 362 informing it of an impending functional event. 363 Implementation: via ERROR.TCP. 365 o Notification of ICMP error message arrival 366 Protocols: TCP, UDP(-Lite) 367 Optimizing because these messages can inform about success or 368 failure of functional transport service features (e.g., host 369 unreachable relates to "Connect") 370 Implementation: via ERROR.TCP. 372 o Status (query or notification) 373 Protocols: SCTP, MPTCP 374 SCTP parameters: association connection state; socket list; socket 375 reachability states; current receiver window size; current 376 congestion window sizes; number of unacknowledged DATA chunks; 377 number of DATA chunks pending receipt; primary path; most recent 378 SRTT on primary path; RTO on primary path; SRTT and RTO on other 379 destination addresses; socket becoming active / inactive 380 MPTCP parameters: subflow-list (identified by source-IP; source- 381 Port; destination-IP; destination-Port) 382 Automatable because these parameters relate to knowledge about the 383 network, not the application. 385 o Change authentication parameters 386 Protocols: SCTP 387 Optimizing because a TAPS system could always authenticate all 388 chunk types; changing this behavior can then improve the 389 performance. 391 o Obtain authentication information 392 Protocols: SCTP 393 Functional because authentication decisions may have been made by 394 the peer, and this has an influence on the necessary application- 395 level measures to provide a certain level of security. 397 o Set primary path 398 Protocols: SCTP 399 Automatable because it requires using multiple sockets, but 400 obtaining multiple sockets in the CONNECTION.ESTABLISHMENT 401 category is automatable. 402 Implementation: see Section 4. 404 o Specify DSCP field 405 Protocols: TCP, SCTP 406 Optimizing because choosing a suitable DSCP value requires 407 application-specific knowledge. 408 Implementation: via CHANGE-DSCP.TCP and [**Not yet included in 409 [TAPS2] FOR SCTP**] 411 o Reset Stream 412 Protocols: SCTP 413 Automatable because using multi-streaming does not require 414 application-specific knowledge. 415 Implementation: see Section 4. 417 o Notification of Stream Reset 418 Protocols: STCP 419 Automatable because using multi-streaming does not require 420 application-specific knowledge. 421 Implementation: see Section 4. 423 o Reset Association 424 Protocols: SCTP 425 Functional because it affects "Obtain a message delivery number", 426 which is functional. 428 o Notification of Association Reset 429 Protocols: STCP 430 Functional because it affects "Obtain a message delivery number", 431 which is functional. 433 o Add Streams 434 Protocols: SCTP 435 Automatable because using multi-streaming does not require 436 application-specific knowledge. 437 Implementation: see Section 4. 439 o Notification of Added Stream 440 Protocols: STCP 441 Automatable because using multi-streaming does not require 442 application-specific knowledge. 443 Implementation: see Section 4. 445 o Set peer primary path 446 Protocols: SCTP 447 Automatable because decisions about local interfaces relate to 448 knowledge about the network and the Operating System, not the 449 application. 451 o Add subflow 452 Protocols: MPTCP 453 MPTCP Parameters: source-IP; source-Port; destination-IP; 454 destination-Port 455 Automatable because the usage of multiple paths to communicate to 456 the same end host relates to knowledge about the network, not the 457 application. 459 o Remove subflow 460 Protocols: MPTCP 461 MPTCP Parameters: source-IP; source-Port; destination-IP; 462 destination-Port 463 Automatable because the usage of multiple paths to communicate to 464 the same end host relates to knowledge about the network, not the 465 application. 467 o Add local address 468 Protocols: SCTP 469 Automatable because decisions about local interfaces relate to 470 knowledge about the network and the Operating System, not the 471 application. 473 o Remove local address 474 Protocols: SCTP 475 Automatable because decisions about local interfaces relate to 476 knowledge about the network and the Operating System, not the 477 application. 479 o Disable checksum when sending 480 Protocols: UDP 481 Functional because application-specific knowledge is necessary to 482 decide whether it can be acceptable to lose data integrity. 484 o Disable checksum requirement when receiving 485 Protocols: UDP 486 Functional because application-specific knowledge is necessary to 487 decide whether it can be acceptable to lose data integrity. 489 o Specify checksum coverage used by the sender 490 Protocols: UDP-Lite 491 Functional because application-specific knowledge is necessary to 492 decide for which parts of the data it can be acceptable to lose 493 data integrity. 495 o Specify minimum checksum coverage required by receiver 496 Protocols: UDP-Lite 497 Functional because application-specific knowledge is necessary to 498 decide for which parts of the data it can be acceptable to lose 499 data integrity. 501 o Specify DF field 502 Protocols: UDP(-Lite) 503 Optimizing because the DF field can be used to carry out Path MTU 504 Discovery, which can lead an application to choose message sizes 505 that can be transmitted more efficiently. 506 Implementation: via MAINTENANCE.SET_DF and SEND_FAILURE.UDP(-Lite) 508 o Specify TTL/Hop count field 509 Protocols: UDP(-Lite) 510 Automatable because a TAPS system can use a large enough system 511 default to avoid communication failures. Allowing an application 512 to configure it differently can produce notifications of ICMP 513 error message arrivals that yield information which only relates 514 to knowledge about the network, not the application. 516 o Obtain TTL/Hop count field 517 Protocols: UDP(-Lite) 518 Automatable because the TTL/Hop count field relates to knowledge 519 about the network, not the application. 521 o Specify ECN field 522 Protocols: UDP(-Lite) 523 Automatable because the ECN field relates to knowledge about the 524 network, not the application. 526 o Obtain ECN field 527 Protocols: UDP(-Lite) 528 Automatable because the ECN field relates to knowledge about the 529 network, not the application. 531 o Specify IP Options 532 Protocols: UDP(-Lite) 533 Automatable because IP Options relate to knowledge about the 534 network, not the application. 536 o Obtain IP Options 537 Protocols: UDP(-Lite) 538 Automatable because IP Options relate to knowledge about the 539 network, not the application. 541 TERMINATION: 543 o Close after reliably delivering all remaining data, causing an 544 event informing the application on the other side 545 Protocols: TCP, SCTP 546 Functional because the notion of a connection is often reflected 547 in applications as an expectation to have all outstanding data 548 delivered and no longer be able to communicate after a "Close" 549 succeeded, with a communication sequence relating to this 550 transport service feature that is defined by the application 551 protocol. 552 Implementation: via CLOSE.TCP and CLOSE.SCTP. 554 o Abort without delivering remaining data, causing an event 555 informing the application on the other side 556 Protocols: TCP, SCTP 557 Functional because the notion of a connection is often reflected 558 in applications as an expectation to potentially not have all 559 outstanding data delivered and no longer be able to communicate 560 after an "Abort" succeeded, with a communication sequence relating 561 to this transport service feature that is defined by the 562 application protocol. 563 Implementation: via ABORT.TCP and ABORT.SCTP. 565 o Timeout event when data could not be delivered for too long 566 Protocols: TCP, SCTP 567 Functional because this notifies that potentially assumed reliable 568 data delivery is no longer provided. Implementation: via 569 TIMEOUT.TCP and TIMEOUT.SCTP. 571 3.2. DATA Transfer Related Transport Service Features 573 3.2.1. Sending Data 575 o Reliably transfer data, with congestion control 576 Protocols: TCP, SCTP 577 Functional because this is closely tied to properties of the data 578 that an application sends or expects to receive. 579 Implementation: via SEND.TCP and SEND.SCTP. 581 o Reliably transfer a message, with congestion control 582 Protocols: SCTP 583 Functional because this is closely tied to properties of the data 584 that an application sends or expects to receive. 585 Implementation: via SEND.SCTP. 586 Fall-back to TCP: By using SEND.TCP and providing a means to let 587 the application query whether messages can be identified or not. 589 o Unreliably transfer a message 590 Protocols: SCTP, UDP(-Lite) 591 Optimizing because only applications know about the time 592 criticality of their communication, and reliably transfering a 593 message is never incorrect for the receiver of a potentially 594 unreliable data transfer, it is just slower. 595 ADDED. This differs from the 2 automatable transport service 596 features below in that it leaves the choice of congestion control 597 open. 598 Implementation: via SEND.SCTP or SEND.UDP. 600 o Unreliably transfer a message, with congestion control 601 Protocols: SCTP 602 Automatable because congestion control relates to knowledge about 603 the network, not the application. 605 o Unreliably transfer a message, without congestion control 606 Protocols: UDP(-Lite) 607 Automatable because congestion control relates to knowledge about 608 the network, not the application. 610 o Configurable Message Reliability 611 Protocols: SCTP 612 Optimizing because only applications know about the time 613 criticality of their communication, and reliably transfering a 614 message is never incorrect for the receiver of a potentially 615 unreliable data transfer, it is just slower. 616 Implementation: via SEND.SCTP. 617 Fall-back to TCP: By using SEND.TCP and ignoring this 618 configuration: based on the assumption of the best-effort service 619 model, unnecessarily delivering data does not violate application 620 expectations. Moreover, it is not possible to associate the 621 requested reliability to a "message" in TCP anyway. 623 o Choice of stream 624 Protocols: SCTP 625 Automatable because it requires using multiple streams, but 626 requesting multiple streams in the CONNECTION.ESTABLISHMENT 627 category is automatable. Implementation: see Section 4. 629 o Choice of path (destination address) 630 Protocols: SCTP 631 Automatable because it requires using multiple sockets, but 632 obtaining multiple sockets in the CONNECTION.ESTABLISHMENT 633 category is automatable. Implementation: see Section 4. 635 o Choice between unordered (potentially faster) or ordered delivery 636 of messages 637 Protocols: SCTP 638 Functional because this is closely tied to properties of the data 639 that an application sends or expects to receive. 640 Implementation: via SEND.SCTP. 641 Fall-back to TCP: By using SEND.TCP and always sending data 642 ordered: based on the assumption of the best-effort service model, 643 ordered delivery may just be slower and does not violate 644 application expectations. Moreover, it is not possible to 645 associate the requested delivery order to a "message" in TCP 646 anyway. 648 o Request not to bundle messages 649 Protocols: SCTP 650 Optimizing because this decision depends on knowledge about the 651 size of future data blocks and the delay between them. 653 Implementation: via SEND.SCTP. 654 Fall-back to TCP: By using SEND.TCP and DISABLE-NAGLE.TCP to 655 disable the Nagle algorithm when the request is made and enable it 656 again when the request is no longer made. 658 o Specifying a "payload protocol-id" (handed over as such by the 659 receiver) 660 Protocols: SCTP 661 Functional because it allows to send extra application data with 662 every message, for the sake of identification of data, which by 663 itself is application-specific. 664 Implementation: SEND.SCTP. 665 Fall-back to TCP: Not possible. 667 o Specifying a key id to be used to authenticate a message 668 Protocols: SCTP 669 Functional because this has a direct influence on security. 671 o Request not to delay the acknowledgement (SACK) of a message 672 Protocols: SCTP 673 Optimizing because only an application knows for which message it 674 wants to quickly informed about success / failure of its delivery. 676 3.2.2. Receiving Data 678 o Receive data 679 Protocols: TCP, SCTP 680 Functional because a TAPS system must be able to send and receive 681 data. 682 Implementation: via RECEIVE.SCTP and RECEIVE.TCP 684 o Receive a message 685 Protocols: SCTP 686 Functional because this is closely tied to properties of the data 687 that an application sends or expects to receive. 688 Implementation: via RECEIVE.SCTP. 690 Fall-back to TCP: By using RECEIVE.TCP and providing a means to 691 let the application query whether messages can be identified or 692 not. 694 o Choice of stream to receive from 695 Protocols: SCTP 696 Automatable because it requires using multiple streams, but 697 requesting multiple streams in the CONNECTION.ESTABLISHMENT 698 category is automatable. 699 Implementation: see Section 4. 701 o Information about partial message arrival 702 Protocols: SCTP 703 Functional because this is closely tied to properties of the data 704 that an application sends or expects to receive. 705 Implementation: via RECEIVE.SCTP. 706 Fall-back to TCP: Not possible (do not provide this event). 708 o Obtain a message delivery number 709 Protocols: SCTP 710 Functional because this number can let applications detect and, if 711 desired, correct reordering. Whether messages are in the correct 712 order or not is closely tied to properties of the data that an 713 application sends or expects to receive. 715 3.2.3. Errors 717 o Notification of send failures 718 Protocols: TCP, SCTP 719 Functional because this notifies that potentially assumed reliable 720 data delivery is no longer provided. 721 ADDED. This differs from the 2 automatable transport service 722 features below in that it does not distinugish between unsent and 723 unacknowledged messages. 724 Implementation: via SENDFAILURE-EVENT.SCTP. 725 Fall-back to TCP: Not possible (do not provide this event). 727 o Notification of unsent messages 728 Protocols: SCTP, UDP(-Lite) 729 Optimizing because the DF field can be used to carry out Path MTU 730 Discovery, which can lead an application to choose message sizes 731 that can be transmitted more efficiently. 732 Implementation: via MAINTENANCE.SET_DF and SEND_FAILURE.UDP(-Lite) 734 o Notification of unacknowledged messages 735 Protocols: SCTP 736 Automatable because the distinction between unsent and 737 unacknowledged is network-specific. 739 4. Discussion 741 Some of transport service features in Section 3 were designated as 742 "automatable" on the basis of a broader decision that affects 743 multiple transport service features. These decisions are explained 744 here: 746 o All transport service features that are related to multi-streaming 747 were designated as "automatable". The decision on whether to use 748 multi-streaming or not does not depend on application-specific 749 knowledge. This means that a connection that is exhibited to an 750 application could be implemented by using a single stream of an 751 SCTP association instead of mapping it to a complete SCTP 752 association. This could be achieved by using more than one stream 753 when an SCTP association is first established (CONNECT.SCTP 754 parameter "outbound stream count"), an internal stream number 755 could be maintained by the TAPS system, and this stream number 756 would then be used when sending data (SEND.SCTP parameter "stream 757 number"). Closing or aborting a connection could then simply free 758 the stream number for future use. 759 o All transport service features that are related to usage of 760 multiple paths or the choice of the network interface were 761 designated as "automatable". Choosing a path or an interface does 762 not depend on application-specific knowledge. For example, 763 "Listen" could always listen on all available interfaces and 764 "Connect" could use the default interface for the destination IP 765 address. 767 5. Conclusion 769 By decoupling applications from transport protocols, a TAPS system 770 provides a different abstraction level than the Berkeley sockets 771 interface. As with high- vs. low-level programming languages, a 772 higher abstraction level allows more freedom for automation below the 773 interface, yet it takes some control away from the application 774 programmer. This is the design trade-off that a TAPS system 775 developer is facing, and this document provides guidance on the 776 design of this abstraction level. Some transport service features 777 are currently rarely offered by APIs, yet they must be offered or 778 they can never be used ("functional" transport service features). 779 Other transport service features are offered by the APIs of the 780 protocols covered here, but not exposing them in a TAPS API would 781 allow for more freedom to automate protocol usage in a TAPS system. 783 The eventual recommendations are: 785 o A TAPS system should expose all functional transport service 786 features that are offered by the transport protocols that it uses 787 because these transport service features could otherwise not be 788 utilized by the TAPS system. It can still be possible to 789 implement a TAPS system that does not offer all functional 790 transport service features, e.g. for the sake of uniform 791 application operation across a broader set of protocols, but then 792 the corresponding functionality of transport protocols is not 793 exploited. If a protocol that provides a functional transport 794 service feature is not available, a TAPS system should 795 automatically fall back to a different protocol (e.g. TCP or UDP) 796 whenever possible to reduce the potential for protocol dependence 797 in applications. 798 o A TAPS system should exhibit all application-specific optimizing 799 transport service features. If an application-specific optimizing 800 transport service feature is only available in a subset of the 801 transport protocols used by the TAPS system, it should be 802 acceptable for the TAPS system to ignore its usage when the 803 transport protocol that is currently used does not provide it 804 because of the performance-optimizing nature of the transport 805 service feature and the initially mentioned assumption of "best 806 effort" operation. 807 o By hiding automatable transport service features from the 808 application, a TAPS system can gain opportunities to automatize 809 network-related functionality. This can facilitate using the TAPS 810 system for the application programmer and it allows for 811 optimizations that may not be possible for an application. For 812 instance, a kernel-level TAPS system that hides SCTP multi- 813 streaming from applications could theoretically map application- 814 level connections from multiple applications onto the same SCTP 815 association. Similarly, system-wide configurations regarding the 816 usage of multiple interfaces could be exploited if the choice of 817 the interface is not given to the application. However, if an 818 application wants to directly expose such choices to its user, not 819 offering this functionality can become a disadvantage of a TAPS 820 system. This is a trade-off that must be considered in TAPS 821 system design. 823 6. Acknowledgements 825 This work has received funding from the European Union's Horizon 2020 826 research and innovation programme under grant agreement No. 644334 827 (NEAT). The views expressed are solely those of the author(s). 829 7. IANA Considerations 831 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 833 This memo includes no request to IANA. 835 8. Security Considerations 837 Security will be considered in future versions of this document. 839 9. Informative References 841 [RFC5290] Floyd, S. and M. Allman, "Comments on the Usefulness of 842 Simple Best-Effort Traffic", RFC 5290, 843 DOI 10.17487/RFC5290, July 2008, 844 . 846 [RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet 847 Technology Adoption and Transition (ITAT)", RFC 7305, 848 DOI 10.17487/RFC7305, July 2014, 849 . 851 [TAPS1] Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services 852 provided by IETF transport protocols and congestion 853 control mechanisms", Internet-draft draft-ietf-taps- 854 transports-12, July 2016. 856 [TAPS2] Welzl, M., Tuexen, M., and N. Khademi, "An Approach to 857 Identify Services Provided by IETF Transport Protocols and 858 Congestion Control Mechanisms", Internet-draft draft-ietf- 859 taps-transports-usage-02, October 2016. 861 Appendix A. Revision information 863 XXX RFC-Ed please remove this section prior to publication. 865 -02: implementation suggestions added, discussion section added, 866 terminology extended, DELETED category removed, various other fixes; 867 list of Transport Service Features adjusted to -01 version of [TAPS2] 868 except that MPTCP is not included. 870 -03: updated to be consistent with -02 version of [TAPS2]. 872 Authors' Addresses 874 Stein Gjessing 875 University of Oslo 876 PO Box 1080 Blindern 877 Oslo N-0316 878 Norway 880 Phone: +47 22 85 24 44 881 Email: steing@ifi.uio.no 883 Michael Welzl 884 University of Oslo 885 PO Box 1080 Blindern 886 Oslo N-0316 887 Norway 889 Phone: +47 22 85 24 20 890 Email: michawe@ifi.uio.no