idnits 2.17.1 draft-gjessing-taps-minset-01.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 (March 18, 2016) is 2954 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-taps-transports-10 == Outdated reference: A later version (-09) exists of draft-ietf-taps-transports-usage-00 Summary: 0 errors (**), 0 flaws (~~), 3 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: September 19, 2016 March 18, 2016 7 A Minimal Set of Transport Services for TAPS Systems 8 draft-gjessing-taps-minset-01 10 Abstract 12 This draft will eventually recommend a minimal set of IETF Transport 13 Services offered by end systems supporting TAPS, and give guidance on 14 choosing among the available mechanisms and protocols. It 15 categorizes the set of transport services given in the TAPS document 16 draft-ietf-taps-transports-usage-00, assuming that the eventual 17 minimal set of transport services will be based on a similar form of 18 categorization. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 19, 2016. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology (as defined by draft-ietf-taps-transports-10) . . 4 56 3. The superset of transport service features . . . . . . . . . 4 57 3.1. CONNECTION Related Transport Service Features . . . . . . 5 58 3.2. DATA Transfer Related Transport Service Features . . . . 9 59 3.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 9 60 3.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 10 61 3.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . 11 62 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 66 8. Informative References . . . . . . . . . . . . . . . . . . . 13 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 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. There are however certain 109 requirements that are strictly kept by transport protocols today, and 110 these must also be kept by a TAPS system. Some of these requirements 111 relate to features that we call "Functional". 113 Functional features provide functionality that cannot be used without 114 the application knowing about them, or else they violate assumptions 115 that might cause the application to break. For example, unordered 116 message delivery is a functional feature: it cannot be used without 117 the application knowing about it because the application's assumption 118 could be that messages arrive in-order, and in this case unordered 119 delivery could cause the application to break. Change DSCP and data 120 bundling (Nagle in TCP) are optimizing features: if a TAPS system 121 autonomously decides to enable or disable them, an application will 122 not break, but a TAPS system may be able to communicate more 123 efficiently if the application is in control of this optimizing 124 feature. Change DSCP and data bundling are examples of features that 125 require application-specific knowledge (about delay/bandwidth 126 requirements and the length of future data blocks that are to be 127 transmitted, respectively). Some features, however, do not always 128 require application-specific knowledge, and could therefore sometimes 129 be used by a TAPS system without exposing them to the application. 130 We call these features potentially automatable. 132 To summarize, features offered to applications are divided into two 133 groups as follows: 135 o Potentially automatable 136 It may sometimes be possible to use this feature without support 137 by the application. 138 o Application-specific 139 It is not possible to use this feature without support by the 140 application. 142 The Application-specific features are further divided into two 143 groups: 145 o Functional 146 This feature is application-specific, and using it without 147 explicitly involving the application could lead to incorrect 148 operation. 149 o Optimizing 150 This feature is application-specific, and can allow an application 151 to improve its performance. 153 In the following, some features are additionally marked as DELETED. 154 These features are IETF Transport protocol features that are not 155 exposed to the TAPS user because they include functionality that is 156 automatable. A few features are marked as "ADDED". These provide 157 non-automatable functionality of DELETED features. 159 2. Terminology (as defined by draft-ietf-taps-transports-10) 161 The following terms are used throughout this document, and in 162 subsequent documents produced by TAPS that describe the composition 163 and decomposition of transport services. 165 Transport Service Feature: a specific end-to-end feature that the 166 transport layer provides to an application. Examples include 167 confidentiality, reliable delivery, ordered delivery, message- 168 versus-stream orientation, etc. 169 Transport Service: a set of Transport Features, without an 170 association to any given framing protocol, which provides a 171 complete service to an application. 172 Transport Protocol: an implementation that provides one or more 173 different transport services using a specific framing and header 174 format on the wire. 175 Transport Service Instance: an arrangement of transport protocols 176 with a selected set of features and configuration parameters that 177 implements a single transport service, e.g., a protocol stack (RTP 178 over UDP). 179 Application: an entity that uses the transport layer for end-to-end 180 delivery data across the network (this may also be an upper layer 181 protocol or tunnel encapsulation). 183 3. The superset of transport service features 185 This section is based on the classification of the transport service 186 features in pass 3 of [TAPS2]. As noted earlier, whether the usage 187 of potentially automatable features can be automatized in a TAPS 188 system depends on how much network-specific information an 189 application wants to manipulate (e.g., to directly expose to its 190 user). Therefore, in the following, "application-specific knowledge" 191 refers to knowledge that only applications have, as opposed to all 192 knowledge that applications may want to have. 194 3.1. CONNECTION Related Transport Service Features 196 ESTABLISHMENT: 198 o Connect 199 Protocols: TCP, SCTP 200 Functional because the notion of a connection is often reflected 201 in applications as an expectation to be able to communicate after 202 a "Connect" succeeded, with a communication sequence relating to 203 this feature that is defined by the application protocol. 204 ADDED. 206 o Specify IP Options 207 Protocols: TCP 208 Potentially automatable because IP Options relate to knowledge 209 about the network, not the application. 210 DELETED. 212 o Request multiple streams 213 Protocols: SCTP 214 Potentially automatable because using multi-streaming does not 215 require application-specific knowledge. 216 DELETED. 218 o Obtain multiple sockets 219 Protocols: SCTP 220 Potentially automatable because the usage of multiple paths to 221 communicate to the same end host relates to knowledge about the 222 network, not the application. 223 DELETED. 225 AVAILABILITY: 227 o Listen 228 Protocols: All 229 Functional because the notion of accepting connection requests is 230 often reflected in application as an expectation to be able to 231 communicate after a "Listen" succeeded, with a communication 232 sequence relating to this feature that is defined by the 233 application protocol. 234 ADDED. 236 o Listen, 1 specified local interface 237 Protocols: TCP, SCTP 238 Potentially automatable because decisions about local interfaces 239 relate to knowledge about the network and the Operating System, 240 not the application. 241 DELETED. 243 o Listen, N specified local interfaces 244 Protocols: SCTP 245 Potentially automatable because decisions about local interfaces 246 relate to knowledge about the network and the Operating System, 247 not the application. 248 DELETED. 250 o Listen, all local interfaces (unspecified) 251 Protocols: TCP, SCTP 252 Potentially automatable because decisions about local interfaces 253 relate to knowledge about the network and the Operating System, 254 not the application. 255 DELETED. 257 o Obtain requested number of streams 258 Protocols: SCTP 259 Potentially automatable because using multi-streaming does not 260 require application-specific knowledge. 262 MAINTENANCE: 264 o Change timeout for aborting connection (using retransmit limit or 265 time value) 266 Protocols: TCP, SCTP 267 Functional because this is closely related to potentially assumed 268 reliable data delivery. 270 o Control advertising timeout for aborting connection to remote 271 endpoint 272 Protocols: TCP 273 Functional because this is closely related to potentially assumed 274 reliable data delivery. 276 o Disable Nagle algorithm 277 Protocols: TCP, SCTP 278 Optimizing because this decision depends on knowledge about the 279 size of future data blocks and the delay between them. 281 o Request an immediate heartbeat, returning success/failure 282 Protocols: SCTP 283 Potentially automatable because this informs about network- 284 specific knowledge. 286 o Set protocol parameters 287 Protocols: SCTP 288 SCTP parameters: RTO.Initial; RTO.Min; RTO.Max; Max.Burst; 289 RTO.Alpha; RTO.Beta; Valid.Cookie.Life; Association.Max.Retrans; 290 Path.Max.Retrans; Max.Init.Retransmits; HB.interval; HB.Max.Burst 291 Potentially automatable because these parameters relate to 292 knowledge about the network, not the application. 294 o Notification of Excessive Retransmissions (early warning below 295 abortion threshold) 296 Protocols: TCP 297 Optimizing because it is an early warning to the application, 298 informing it of an impending functional event. 300 o Notification of ICMP error message arrival 301 Protocols: TCP 302 Optimizing because these messages can inform about success or 303 failure of functional features (e.g., host unreachable relates to 304 "Connect") 306 o Status (query or notification) 307 Protocols: SCTP 308 SCTP parameters: association connection state; socket list; socket 309 reachability states; current receiver window size; current 310 congestion window sizes; number of unacknowledged DATA chunks; 311 number of DATA chunks pending receipt; primary path; most recent 312 SRTT on primary path; RTO on primary path; SRTT and RTO on other 313 destination addresses; socket becoming active / inactive 314 Potentially automatable because these parameters relate to 315 knowledge about the network, not the application. 317 o Set primary path 318 Protocols: SCTP 319 Potentially automatable because it requires using multiple 320 sockets, but obtaining multiple sockets in the 321 CONNECTION.ESTABLISHMENT category is potentially automatable. 323 o Change DSCP 324 Protocols: TCP 325 Optimizing because choosing a suitable DSCP value requires 326 application-specific knowledge. 328 TERMINATION: 330 o Close after reliably delivering all remaining data, causing an 331 event informing the application on the other side 332 Protocols: TCP, SCTP 333 Functional because the notion of a connection is often reflected 334 in applications as an expectation to have all outstanding data 335 delivered and no longer be able to communicate after a "Close" 336 succeeded, with a communication sequence relating to this feature 337 that is defined by the application protocol. 339 o Abort without delivering remaining data, causing an event 340 informing the application on the other side 341 Protocols: TCP, SCTP 342 Functional because the notion of a connection is often reflected 343 in applications as an expectation to potentially not have all 344 outstanding data delivered and no longer be able to communicate 345 after an "Abort" succeeded, with a communication sequence relating 346 to this feature that is defined by the application protocol. 348 o Timeout event when data could not be delivered for too long 349 Protocols: TCP, SCTP 350 Functional because this notifies that potentially assumed reliable 351 data delivery is no longer provided. 353 3.2. DATA Transfer Related Transport Service Features 355 3.2.1. Sending Data 357 o Reliably transfer data 358 Protocols: TCP, SCTP 359 Functional because this is closely tied to properties of the data 360 that an application sends or expects to receive. 362 o Notifying the receiver to promptly hand over data to application 363 Protocols: TCP 364 Optimizing because this is meant to control sleep times of the 365 application's receiving process. 367 o Message identification 368 Protocols: SCTP 369 Functional because this is closely tied to properties of the data 370 that an application sends or expects to receive. 372 o Choice of stream 373 Protocols: SCTP 374 Potentially automatable because it requires using multiple 375 streams, but requesting multiple streams in the 376 CONNECTION.ESTABLISHMENT category is potentially automatable. 378 o Choice of path (destination address) 379 Protocols: SCTP 380 Potentially automatable because it requires using multiple 381 sockets, but obtaining multiple sockets in the 382 CONNECTION.ESTABLISHMENT category is potentially automatable. 384 o Message lifetime 385 Protocols: SCTP 386 Optimizing because only applications know about the time 387 criticality of their communication. 389 o Choice between unordered (potentially faster) or ordered delivery 390 Protocols: SCTP 391 Functional because this is closely tied to properties of the data 392 that an application sends or expects to receive. 394 o Request not to bundle messages 395 Protocols: SCTP 396 Optimizing because this decision depends on knowledge about the 397 size of future data blocks and the delay between them. 399 o Specifying a "payload protocol-id" (handed over as such by the 400 receiver) 401 Protocols: SCTP 402 Functional because it allows application data with every message, 403 for the sake of identification of data, which by itself is 404 application-specific. 406 3.2.2. Receiving Data 408 o Receive data 409 Protocols: TCP, SCTP 410 Functional because a TAPS system must be able to send and receive 411 data. 413 o Choice of stream to receive from 414 Protocols: SCTP 415 Potentially automatable because it requires using multiple 416 streams, but requesting multiple streams in the 417 CONNECTION.ESTABLISHMENT category is potentially automatable. 419 o Message identification 420 Protocols: SCTP 421 Functional because this is closely tied to properties of the data 422 that an application sends or expects to receive. 424 o Information about partial message arrival 425 Protocols: SCTP 426 Functional because this is closely tied to properties of the data 427 that an application sends or expects to receive. 429 3.2.3. Errors 431 o Notification of send failures 432 Protocols: All 433 Functional because this notifies that potentially assumed reliable 434 data delivery is no longer provided. 435 ADDED. 437 o Notification of unsent messages 438 Protocols: SCTP 439 Automatable because the distinction between unsent and 440 unacknowledged is network-specific. 441 DELETED. 443 o Notification of unacknowledged messages 444 Protocols: SCTP 445 Automatable because the distinction between unsent and 446 unacknowledged is network-specific. 447 DELETED. 449 4. Conclusion 451 The eventual recommendations are: 453 o A TAPS system should exhibit all functional features that are 454 offered by the transport protocols that it uses because these 455 features could otherwise not be utilized by the TAPS system. It 456 can still be possible to implement a TAPS system that does not 457 offer all functional features, e.g. for the sake of uniform 458 application operation across a broader set of protocols, but then 459 the corresponding functionality of transport protocols is not 460 exploited. 461 o A TAPS system should exhibit all application-specific optimizing 462 features. If an application-specific optimizing feature is only 463 available in a subset of the transport protocols used by the TAPS 464 system, it should be acceptable for the TAPS system to ignore its 465 usage when the transport protocol that is currently used does not 466 provide it because of the performance-optimizing nature of the 467 feature and the initially mentioned assumption of "best effort" 468 operation. 469 o By hiding potentially automatable features from the application, a 470 TAPS system can gain opportunities to automatize network-related 471 functionality. This can facilitate using the TAPS system for the 472 application programmer and it allows for optimizations that may 473 not be possible for an application. For instance, a kernel-level 474 TAPS system that hides SCTP multi-streaming from applications 475 could theoretically map application-level connections from 476 multiple applications onto the same SCTP association. Similarly, 477 system-wide configurations regarding the usage of multiple 478 interfaces could be exploited if the choice of the interface is 479 not given to the application. However, if an application wants to 480 directly expose such choices to its user, not offering this 481 functionality can become a disadvantage of a TAPS system. This is 482 a trade-off that must be considered in TAPS system design. 484 Given that the intention of TAPS is to break the design-time binding 485 between applications and transport protocols, the decision on which 486 features a TAPS system provides should also depend on the protocols 487 that support them. Features that are provided by only one particular 488 transport protocol have the potential to tie applications to that 489 protocol. They should either not be offered, or replaced by fall- 490 back functionality that allows for semantically correct operation 491 (for example, ordered data delivery is correct but potentially slower 492 for an application that requests unordered data delivery. 493 "Potentially slower" is not a hindrance to correct operation within 494 the "best effort" service model). 496 5. Acknowledgements 498 This work has received funding from the European Union's Horizon 2020 499 research and innovation programme under grant agreement No. 644334 500 (NEAT). The views expressed are solely those of the author(s). 502 6. IANA Considerations 504 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 506 This memo includes no request to IANA. 508 7. Security Considerations 510 Security will be considered in future versions of this document. 512 8. Informative References 514 [RFC5290] Floyd, S. and M. Allman, "Comments on the Usefulness of 515 Simple Best-Effort Traffic", RFC 5290, 516 DOI 10.17487/RFC5290, July 2008, 517 . 519 [RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet 520 Technology Adoption and Transition (ITAT)", RFC 7305, 521 DOI 10.17487/RFC7305, July 2014, 522 . 524 [TAPS1] Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services 525 provided by IETF transport protocols and congestion 526 control mechanisms", Internet-draft draft-ietf-taps- 527 transports-10, March 2016. 529 [TAPS2] Welzl, M., Tuexen, M., and N. Khademi, "An Approach to 530 Identify Services Provided by IETF Transport Protocols and 531 Congestion Control Mechanisms", Internet-draft draft-ietf- 532 taps-transports-usage-00, June 2015. 534 Authors' Addresses 536 Stein Gjessing 537 University of Oslo 538 PO Box 1080 Blindern 539 Oslo N-0316 540 Norway 542 Phone: +47 22 85 24 44 543 Email: steing@ifi.uio.no 544 Michael Welzl 545 University of Oslo 546 PO Box 1080 Blindern 547 Oslo N-0316 548 Norway 550 Phone: +47 22 85 24 20 551 Email: michawe@ifi.uio.no