idnits 2.17.1 draft-ietf-taps-arch-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 (April 30, 2018) is 2186 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-taps-minset-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TAPS Working Group T. Pauly, Ed. 3 Internet-Draft Apple Inc. 4 Intended status: Informational B. Trammell, Ed. 5 Expires: November 1, 2018 ETH Zurich 6 A. Brunstrom 7 Karlstad University 8 G. Fairhurst 9 University of Aberdeen 10 C. Perkins 11 University of Glasgow 12 P. Tiesel 13 TU Berlin 14 C. Wood 15 Apple Inc. 16 April 30, 2018 18 An Architecture for Transport Services 19 draft-ietf-taps-arch-00 21 Abstract 23 This document provides an overview of the architecture of Transport 24 Services, a system for exposing the features of transport protocols 25 to applications. This architecture serves as a basis for Application 26 Programming Interfaces (APIs) and implementations that provide 27 flexible transport networking services. It defines the common set of 28 terminology and concepts to be used in more detailed discussion of 29 Transport Services. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on November 1, 2018. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Common APIs for Common Features . . . . . . . . . . . . . 4 69 3.2. Access to Specialized Features . . . . . . . . . . . . . 4 70 3.3. Scope for API and Implementation Definitions . . . . . . 5 71 4. Transport Services Architecture and Concepts . . . . . . . . 6 72 4.1. Transport Services API Concepts . . . . . . . . . . . . . 7 73 4.1.1. Basic Objects . . . . . . . . . . . . . . . . . . . . 9 74 4.1.2. Pre-Establishment . . . . . . . . . . . . . . . . . . 10 75 4.1.3. Establishment Actions . . . . . . . . . . . . . . . . 11 76 4.1.4. Data Transfer Objects and Actions . . . . . . . . . . 11 77 4.1.5. Event Handling . . . . . . . . . . . . . . . . . . . 12 78 4.1.6. Termination Actions . . . . . . . . . . . . . . . . . 13 79 4.2. Transport System Implementation Concepts . . . . . . . . 13 80 4.2.1. Gathering . . . . . . . . . . . . . . . . . . . . . . 14 81 4.2.2. Racing . . . . . . . . . . . . . . . . . . . . . . . 14 82 4.2.3. Message Framing, Parsing, and Serialization . . . . . 14 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 86 8. Informative References . . . . . . . . . . . . . . . . . . . 16 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 89 1. Introduction 91 Many APIs to perform transport networking have been deployed, perhaps 92 the most widely known and imitated being the BSD socket() interface. 93 The names and functions between these APIs are not consistent, and 94 vary depending on the protocol being used. For example, sending and 95 receiving on a stream of data is conceptually the same between 96 operating on an unencrypted Transmission Control Protocol (TCP) 97 stream and operating on an encrypted Transport Layer Security (TLS) 98 [I-D.ietf-tls-tls13] stream over TCP, but applications cannot use the 99 same socket send() and recv() calls on top of both kinds of 100 connections. Similarly, terminology for the implementation of 101 protocols offering transport services vary based on the context of 102 the protocols themselves. This variety can lead to confusion when 103 trying to understand the similarities and differences between 104 protocols, and how applications can use them effectively. 106 The goal of the Transport Services architecture is to provide a 107 common, flexible, and reusable interface for transport protocols. As 108 applications adopt this interface, they will benefit from a wide set 109 of transport features that can evolve over time, and ensure that the 110 system providing the interface can optimize its behavior based on the 111 application requirements and network conditions. 113 This document is developed in parallel with the specification of the 114 Transport Services API [I-D.trammell-taps-interface] and 115 Implementation [draft-brunstrom-taps-impl] documents. 117 2. Background 119 The Transport Services architecture is based on the survey of 120 Services Provided by IETF Transport Protocols and Congestion Control 121 Mechanisms [RFC8095], and the distilled minimal set of the features 122 offered by transport protocols [I-D.ietf-taps-minset]. This work has 123 identified common features and patterns across all transport 124 protocols developed thus far in the IETF. 126 Since transport security is an increasingly relevant aspect of using 127 transport protocols on the Internet, this architecture also considers 128 the impact of transport security protocols on the feature set exposed 129 by transport services [I-D.pauly-taps-transport-security]. 131 One of the key insights to come from identifying the minimal set of 132 features provided by transport protocols [I-D.ietf-taps-minset] was 133 that features either require application interaction and guidance 134 (referred to as Functional Features), or else can be handled 135 automatically by a system implementing Transport Services (referred 136 to as Automatable Features). Among the Functional Features, some 137 were common across all or nearly all transport protocols, while 138 others could be seen as features that, if specified, would only be 139 useful with a subset of protocols, or perhaps even a single transport 140 protocol, but would not harm the functionality of other protocols. 141 For example, some protocols can deliver messages faster for 142 applications that do not require them to arrive in the order in which 143 they were sent. However, this functionality must be explicitly 144 allowed by the application, since reordering messages would be 145 undesirable in many cases. 147 3. Design Principles 149 The goal of the Transport Services architecture is to redefine the 150 interface between applications and transports in a way that allows 151 the transport layer to evolve and improve without fundamentally 152 changing the contract with the application. This requires a careful 153 consideration of how to expose the capabilities of protocols. 155 There are several degrees in which a Transport Services system can 156 offer flexibility to an application: it can provide access to 157 multiple sets of protocols and protocol features, it can use these 158 protocols across multiple paths that may have different performance 159 and functional characteristics, and it can communicate with different 160 Remote Endpoints to optimize performance. Beyond these, if the API 161 for the system remains the same over time, new protocols and features 162 may be added to the system's implementation without requiring changes 163 in applications for adoption. 165 The following considerations were used in the design of this 166 architecture. 168 3.1. Common APIs for Common Features 170 Functionality that is common across multiple transport protocols 171 should be accessible through a unified set of API calls. An 172 application should be able to implement logic for its basic use of 173 transport networking (establishing the transport, and sending and 174 receiving data) once, and expect that implementation to continue to 175 function as the transports change. 177 Any Transport Services API must allow access to the distilled minimal 178 set of features offered by transport protocols 179 [I-D.ietf-taps-minset]. 181 3.2. Access to Specialized Features 183 Since applications will often need to control fine-grained details of 184 transport protocols to optimize their behavior and ensure 185 compatibility with remote peers, a Transport Services system also 186 needs to allow more specialized protocol features to be used. The 187 interface for these specialized options should be exposed differently 188 from the common options to ensure flexibility. 190 A specialized feature may be required by an application only when 191 using a specific protocol, and not when using others. For example, 192 if an application is using UDP, it may require control over the 193 checksum or fragmentation behavior for UDP; if it used a protocol to 194 frame its data over a byte stream like TCP, it would not need these 195 options. In such cases, the API should expose the features in such a 196 way that they take effect when a particular protocol is selected, but 197 do not imply that only that protocol may be used if there are 198 equivalent options. 200 Other specialized features, however, may be strictly required by an 201 application and thus constrain the set of protocols that can be used. 202 For example, if an application requires encryption of its transport 203 data, only protocol stacks that include some transport security 204 protocol are eligible to be used. A Transport Services API must 205 allow applications to define such requirements and constrain the 206 system's options. Since such options are not part of the core/common 207 features, it should be simple for an application to modify its set of 208 constraints and change the set of allowable protocol features without 209 changing the core implementation. 211 3.3. Scope for API and Implementation Definitions 213 The Transport Services API is envisioned as the abstract model for a 214 family of APIs that share a common way to expose transport features 215 and encourage flexibility. The abstract API definition 216 [I-D.trammell-taps-interface] describes this interface and is aimed 217 at application developers. 219 Implementations that provide the Transport Services API 220 [draft-brunstrom-taps-impl] will vary due to system-specific support 221 and the needs of the deployment scenario. It is expected that all 222 implementations of Transport Services will offer the entire mandatory 223 API, but that some features will not be functional in certain 224 implementations. All implementations must offer sufficient APIs to 225 use the distilled minimal set of features offered by transport 226 protocols [I-D.ietf-taps-minset], including API support for TCP and 227 UDP transport, but it is possible that some very constrained devices 228 might not have, for example, a full TCP implementation. 230 In order to preserve flexibility and compatibility with future 231 protocols, top-level features in the Transport Services API should 232 avoid referencing particular transport protocols. Mappings of these 233 API features in the Implementation document, on the other hand, must 234 explain the ramifications of each feature on existing protocols. It 235 is expected that the Implementation document will be updated and 236 supplemented as new protocols and protocol features are developed. 238 It is important to note that neither the Transport Services API nor 239 the Implementation document defines new protocols that require any 240 changes on remote hosts. The Transport Services system must be 241 deployable on one side only, as a way to allow an application to make 242 better use of available capabilities on a system and protocol 243 features that may be supported by peers across the network. 245 4. Transport Services Architecture and Concepts 247 The concepts defined in this document are intended primarily for use 248 in the documents and specifications that describe the Transport 249 Services architecture and API. While the specific terminology may be 250 used in some implementations, it is expected that there will remain a 251 variety of terms used by running code. 253 The architecture divides the concepts for Transport Services into two 254 categories: 256 1. API concepts, which are meant to be exposed to applications; and 258 2. System-implementation concepts, which are meant to be internally 259 used when building systems that implement Transport Services. 261 The following diagram summarizes the top-level concepts in the 262 architecture and how they relate to one another. 264 +------------------------------------------------------+ 265 | Application | 266 +-+----------------+------^-------+--------^-----------+ 267 | | | | | 268 pre- | data | events 269 establishment | transfer | | 270 | establishment | termination | 271 | | | | | 272 | +--v------v-------v+ | 273 +-v-------------+ Basic Objects +-------+----------+ 274 | Transport +--------+---------+ | 275 | Services | | 276 | API | | 277 +------------------------|----------------------------+ 278 | 279 +------------------------|----------------------------+ 280 | Transport | | 281 | System | +-----------------+ | 282 | Implementation | | Cached | | 283 | | | State | | 284 | (Candidate Gathering) | +-----------------+ | 285 | | | 286 | (Candidate Racing) | +-----------------+ | 287 | | | System | | 288 | | | Policy | | 289 | +----------v-----+ +-----------------+ | 290 | | Protocol | | 291 +-------------+ Stack(s) +----------------------+ 292 +-------+--------+ 293 V 294 Network Layer Interface 296 Figure 1: Concepts and Relationships in the Transport Services 297 Architecture 299 4.1. Transport Services API Concepts 301 Fundamentally, a Transport Services API needs to provide basic 302 objects (Section 4.1.1) that allow applications to establish 303 communication and send and receive data. These may be exposed as 304 handles or referenced objects, depending on the language. 306 Beyond the basic objects, there are several high-level groups of 307 actions that any Transport Services API must provide: 309 o Pre-Establishment (Section 4.1.2) encompasses the properties that 310 an application can pass to describe its intent, requirements, 311 prohibitions, and preferences for its networking operations. For 312 any system that provides generic Transport Services, these 313 properties should primarily offer knobs that are applicable to 314 multiple transports. Properties may have a large impact on the 315 rest of the aspects of the interface: they can modify how 316 establishment occurs, they can influence the expectations around 317 data transfer, and they determine the set of events that will be 318 supported. 320 o Establishment (Section 4.1.3) focuses on the actions that an 321 application takes on the basic objects to prepare for data 322 transfer. 324 o Data Transfer (Section 4.1.4) consists of how an application 325 represents data to be sent and received, the functions required to 326 send and receive that data, and how the application is notified of 327 the status of its data transfer. 329 o Event Handling (Section 4.1.5) defines the set of properties about 330 which an application can receive notifications during the lifetime 331 of transport objects. Events can also provide opportunities for 332 the application to interact with the underlying transport by 333 querying state or updating maintenance options. 335 o Termination (Section 4.1.6) focuses on the methods by which data 336 transmission is ceased, and state is torn down in the transport. 338 The diagram below provides a high-level view of the actions taken 339 during the lifetime of a connection. 341 Pre-Establishment : Established : Termination 342 ----------------- : ----------- : ----------- 343 : Close() : 344 +---------------+ Initiate() +------------+ Abort() : 345 +-->| Preconnection |----------->| Connection |---------------> Closed 346 | +---------------+ : +------------+ Connection: 347 | : ^ ^ | Finished : 348 +-- Local Endpoint : | | | : 349 | : | | +---------+ : 350 +-- Remote Endpoint : | | | : 351 | : | |Send() | : 352 +-- Path Selection : | +---------+ v : 353 | Properties : | | Message | Message : 354 | : | | to send | Received : 355 +-- Protocol Selection : | +---------+ : 356 | Properties : | : 357 | : | : 358 +-- Specific Protocol : | : 359 | Properties : | : 360 | : | : 361 | +----------+ : | : 362 +-->| Listener |-----------------+ : 363 +----------+ Connection Received : 364 ^ : : 365 | : : 366 Listen() : : 368 Figure 2: The lifetime of a connection 370 4.1.1. Basic Objects 372 o Preconnection: A Preconnection object is a representation of a 373 potential connection. It has state that describes parameters of a 374 Connection that might exist in the future: the Local Endpoint from 375 which that Connection will be established, the Remote Endpoint to 376 which it will connect, and Path Selection Properties, Protocol 377 Selection Properties, and Specific Protocol Properties that 378 influence the choice of transport that a Connection will use. A 379 Preconnection can be fully specified and represent a single 380 possible Connection, or it can be partially specified such that it 381 represents a family of possible Connections. The Local Endpoint 382 must be specified if the Preconnection is used to Listen for 383 incoming connections, but is optional if it is used to Initiate 384 connections. The Remote Endpoint must be specified in the 385 Preconnection is used to Initiate connections, but is optional if 386 it is used to Listen for incoming connections. The Local Endpoint 387 and the Remote Endpoint must both be specified if a peer-to-peer 388 Rendezvous is to occur based on the Preconnection. 390 o Connection: A Connection object represents an active transport 391 protocol instance that can send and/or receive Messages between a 392 Local Endpoint and a Remote Endpoint. It holds state pertaining 393 to the underlying transport protocol instance and any ongoing data 394 transfer. This represents, for example, an active connection in a 395 connection-oriented protocol such as TCP, or a fully-specified 396 5-tuple for a connectionless protocol such as UDP. 398 o Listener: A Listener object accepts incoming transport protocol 399 connections from Remote Endpoints and generates corresponding 400 Connection objects. It is created from a Preconnection object 401 that specifies the type of incoming connections it will accept. 403 4.1.2. Pre-Establishment 405 o Endpoint: An Endpoint represents one side of a transport 406 connection. Endpoints can be Local Endpoints or Remote Endpoints, 407 and respectively represent an identity that the application uses 408 for the source or destination of a connection. Endpoint can vary 409 in levels of specificity, and can be resolved to more concrete 410 identities. 412 o Remote Endpoint: The Remote Endpoint represents the application's 413 name for a peer that can participate in a transport connection. 414 For example, the combination of a DNS name for the peer and a 415 service name/port. 417 o Local Endpoint: The Local Endpoint represents the application's 418 name for itself that it wants to use for transport connections. 419 For example, a local IP address and port. 421 o Path Selection Properties: The Path Selection Properties consist 422 of the options that an application may set to influence the 423 selection of paths between itself and the Remote Endpoint. These 424 options can come in the form of requirements, prohibitions, or 425 preferences. Examples of options which may influence path 426 selection include the interface type (such as a Wi-Fi Ethernet 427 connection, or a Cellular LTE connection), characteristics of the 428 path that are locally known like Maximum Transmission Unit (MTU) 429 or discovered like Path MTU (PMTU), or predicted based on cached 430 information like expected throughput or latency. 432 o Protocol Selection Properties: The Protocol Selection Properties 433 consist of the options that an application may set to influence 434 the selection of transport protocol, or to configure the behavior 435 of generic transport protocol features. These options come in the 436 form of requirements, prohibitions, and preferences. Examples 437 include reliability, service class, multipath support, and fast 438 open support. 440 o Specific Protocol Properties: The Specific Protocol Properties 441 refer to the subset of Protocol Properties options that apply to a 442 single protocol (transport protocol, IP, or security protocol). 443 The presence of such Properties does not necessarily require that 444 a specific protocol must be used when a Connection is established, 445 but that if this protocol is employed, a particular set of options 446 should be used. 448 4.1.3. Establishment Actions 450 o Initiate is the primary action that an application can take to 451 create a Connection to a remote endpoint, and prepare any required 452 local or remote state to be able to send and/or receive Messages. 453 For some protocols, this may initiate a client-to-server style 454 handshake; for other protocols, this may just establish local 455 state. The process of identifying options for connecting, such as 456 resolution of the Remote Endpoint, occurs in response the Initiate 457 call. 459 o Listen is the action of marking a Listener as willing to accept 460 incoming Connections. The Listener will then create Connection 461 objects as incoming connections are accepted (Section 4.1.5). 463 o Rendezvous is the action of establishing a peer-to-peer connection 464 with a remote endpoint. It simultaneously attempts to initiate a 465 connection to a remote endpoint whilst listening for an incoming 466 connection from that endpoint. This corresponds, for example, to 467 a TCP simultaneous open. The process of identifying options for 468 the connection, such as resolution of the Remote Endpoint, occurs 469 during the Rendezvous call. If successful, the rendezvous call 470 returns a Connection object to represent the established peer-to- 471 peer connection. 473 4.1.4. Data Transfer Objects and Actions 475 o Message: A Message object is a unit of data that can be 476 represented as bytes that can be transferred between two endpoints 477 over a transport connection. The bytes within a Message are 478 assumed to be ordered within the Message. If an application does 479 not care about the order in which a peer receives two distinct 480 spans of bytes, those spans of bytes are considered independent 481 Messages. Messages may or may not be usable if incomplete or 482 corrupted. Boundaries of a Message may or may not be understood 483 or transmitted by transport protocols. Specifically, what one 484 application considers to be two Messages sent on a stream-based 485 transport may be treated as a single Message by the application on 486 the other side. 488 o Send is the action to transmit a Message or partial Message over a 489 Connection to a Remote Endpoint. The interface to Send may 490 include options specific to how the Message's content is to be 491 sent. Status of the Send operation may be delivered back to the 492 application in an event (Section 4.1.5). 494 o Receive is an action that indicates that the application is ready 495 to asynchronously accept a Message over a Connection from a Remote 496 Endpoint, while the Message content itself will be delivered in an 497 event (Section 4.1.5). The interface to Receive may include 498 options specific to the Message that is to be delivered to the 499 application. 501 4.1.5. Event Handling 503 This list of events that can be delivered to an application is not 504 exhaustive, but gives the top-level categories of events. The API 505 may expand this list. 507 o Connection Ready: Signals to an application that a given 508 Connection is ready to send and/or receive Messages. If the 509 Connection relies on handshakes to establish state between peers, 510 then it is assumed that these steps have been taken. 512 o Connection Finished: Signals to an application that a given 513 Connection is no longer usable for sending or receiving Messages. 514 This should deliver an error to the application that describes the 515 nature of the termination. 517 o Connection Received: Signals to an application that a given 518 Listener has passively received a Connection. 520 o Message Received: Delivers received Message content to the 521 application, based on a Receive action. This may include an error 522 if the Receive action cannot be satisfied due to the Connection 523 being closed. 525 o Message Sent: Notifies the application of the status of its Send 526 action. This may be an error if the Message cannot be sent, or an 527 indication that Message has been processed by the protocol stack. 529 o Path Properties Changed: Notifies the application that some 530 property of the Connection has changed that may influence how and 531 where data is sent and/or received. 533 4.1.6. Termination Actions 535 o Close is the action an application may take on a Connection to 536 indicate that it no longer intends to send data, is no longer 537 willing to receive data, and that the protocol should signal this 538 state to the remote endpoint if applicable. 540 o Abort is an action the application may take on a Connection to 541 indicate a Close, but with the additional indication that the 542 transport system should not attempt to deliver any outstanding 543 data. 545 4.2. Transport System Implementation Concepts 547 The Transport System Implementation Concepts define the set of 548 objects used internally to a system or library to provide the 549 functionality of transport networking, as required by the abstract 550 interface. 552 o Connection Group: A Connections Group is a set of Connections that 553 share properties. For multiplexing transport protocols, the 554 Connection Group defines the set of Connections that can be 555 multiplexed together. 557 o Path: A Path represents an available set of properties of a 558 network route on which packets may be sent or received. 560 o Protocol Instance: A Protocol Instance is a single instance of one 561 protocol, including any state it has necessary to establish 562 connectivity or send and receive Messages. 564 o Protocol Stack: A Protocol Stack is a set of Protocol Instances 565 (including relevant application, security, transport, or Internet 566 protocols) that are used together to establish connectivity or 567 send and receive Messages. A single stack may be simple (a single 568 transport protocol instance over IP), or complex (multiple 569 application protocol streams going through a single security and 570 transport protocol, over IP; or, a multi-path transport protocol 571 over multiple transport sub-flows). 573 o System Policy: System Policy represents the input from an 574 operating system or other global preferences that can constrain or 575 influence how an implementation will gather candidate paths and 576 protocols (Section 4.2.1) and race the candidates during 577 establishment (Section 4.2.2). Specific aspects of the System 578 Policy may apply to all Connections, or only certain ones 579 depending on the runtime context and properties of the Connection. 581 o Cached State: Cached State is the state and history that the 582 implementation keeps for each set of associated endpoints that 583 have been used previously. This can include DNS results, TLS 584 session state, previous success and quality of transport protocols 585 over certain paths. 587 4.2.1. Gathering 589 o Path Selection: Path Selection represents the act of choosing one 590 or more paths that are available to use based on the Path 591 Selection Properties provided by the application, and a Transport 592 Services system's policies and heuristics. 594 o Protocol Selection: Protocol Selection represents the act of 595 choosing one or more sets of protocol options that are available 596 to use based on the Protocol Properties provided by the 597 application, and a Transport Services system's policies and 598 heuristics. 600 4.2.2. Racing 602 o Protocol Option Racing: Protocol Racing is the act of attempting 603 to establish, or scheduling attempts to establish, multiple 604 Protocol Stacks that differ based on the composition of protocols 605 or the options used for protocols. 607 o Path Racing: Path Racing is the act of attempting to establish, or 608 scheduling attempts to establish, multiple Protocol Stacks that 609 differ based on a selection from the available Paths. 611 o Endpoint Racing: Endpoint Racing is the act of attempting to 612 establish, or scheduling attempts to establish, multiple Protocol 613 Stacks that differ based on the specific representation of the 614 Remote Endpoint and the Local Endpoint, such as IP addresses 615 resolved from a DNS hostname. 617 4.2.3. Message Framing, Parsing, and Serialization 619 While some transports expose a byte stream abstraction, most higher 620 level protocols impose some structure onto that byte stream. That 621 is, the higher level protocol operates in terms of messages, protocol 622 data units (PDUs), rather than using unstructured sequences of bytes, 623 with each message being processed in turn. Protocols are specified 624 in terms of state machines acting on semantic messages, with parsing 625 the byte stream into messages being a necessary annoyance, rather 626 than a semantic concern. Accordingly, the Transport Services 627 architecture exposes messages as the primary abstraction. Protocols 628 that deal only in byte streams, such as TCP, represent their data in 629 each direction as a single, long message. When framing protocols are 630 placed on top of byte streams, the messages used in the API represent 631 the framed messages within the stream. 633 Providing a message-based abstraction also provides: 635 o the ability to associate deadlines with messages, for transports 636 that care about timing; 638 o the ability to provide control of reliability, choosing what 639 messages to retransmit in the event of packet loss, and how best 640 to make use of the data that arrived; 642 o the ability to manage dependencies between messages, when some 643 messages may not be delivered due to either packet loss or missing 644 a deadline, in particular the ability to avoid (re-)sending data 645 that relies on a previous transmission that was never received. 647 All require explicit message boundaries, and application-level 648 framing of messages, to be effective. Once a message is passed to 649 the transport, it can not be cancelled or paused, but prioritization 650 as well as lifetime and retransmission management will provide the 651 protocol stack with all needed information to send the messages as 652 quickly as possible without blocking transmission unnecessarily. The 653 transport services architecture facilitates this by handling 654 messages, with known identity (sequence numbers, in the simple case), 655 lifetimes, niceness, and antecedents. 657 Transport protocols such as SCTP provide a message-oriented API that 658 has similar features to those we describe. Other transports, such as 659 TCP, do not. To support a message oriented API, while still being 660 compatible with stream-based transport protocols, implementations of 661 the transport services architecture should provide APIs for framing 662 and de-framing messages. That is, we push message framing down into 663 the transport services API, allowing applications to send and receive 664 complete messages. This is backwards compatible with existing 665 protocols and APIs, since the wire format of messages does not 666 change, but gives the protocol stack additional information to allow 667 it to make better use of modern transport services. 669 5. IANA Considerations 671 RFC-EDITOR: Please remove this section before publication. 673 This document has no actions for IANA. 675 6. Security Considerations 677 The Transport Services architecture does not recommend use of 678 specific security protocols or algorithms. Its goal is to offer ease 679 of use for existing protocols by providing a generic security-related 680 interface. Each provided interface mimics an existing protocol- 681 specific interface provided by supported security protocols. For 682 example, trust verification callbacks are common parts of TLS APIs. 683 Transport Services APIs will expose similar functionality. 685 Clients must take care to use security APIs appropriately. In cases 686 where clients use said interface to provide sensitive keying 687 material, e.g., access to private keys or copies of pre-shared keys 688 (PSKs), key use must be validated. For example, clients should not 689 use PSK material created for the Encapsulating Security Protocol 690 (ESP, part of IPsec) [RFC4303] with QUIC, and clients must not use 691 private keys intended for server authentication as a keys for client 692 authentication. Moreover, unlike certain transport features such as 693 TCP Fast Open (TFO) [RFC7413] or Explicit Congestion Notification 694 (ECN) [RFC3168] which can fall back to standard configurations, 695 Transport Services systems must not permit fallback for security 696 protocols. For example, if a client requests TLS, yet TLS or the 697 desired version are not available, its connection must fail. Clients 698 are responsible for implementing protocol or version fallback using a 699 Transport Services API if so desired. 701 7. Acknowledgements 703 This work has received funding from the European Union's Horizon 2020 704 research and innovation programme under grant agreement No. 644334 705 (NEAT). 707 This work has been supported by Leibniz Prize project funds of DFG - 708 German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ 709 FE 570/4-1). 711 This work has been supported by the UK Engineering and Physical 712 Sciences Research Council under grant EP/R04144X/1. 714 Thanks to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric 715 Kinnear for their implementation and design efforts, including Happy 716 Eyeballs, that heavily influenced this work. 718 8. Informative References 720 [draft-brunstrom-taps-impl] 721 Anna Brunstrom, . and . Tommy Pauly, "Implementing 722 Interfaces to Transport Services", n.d.. 724 [I-D.ietf-taps-minset] 725 Welzl, M. and S. Gjessing, "A Minimal Set of Transport 726 Services for TAPS Systems", draft-ietf-taps-minset-03 727 (work in progress), March 2018. 729 [I-D.ietf-tls-tls13] 730 Rescorla, E., "The Transport Layer Security (TLS) Protocol 731 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 732 March 2018. 734 [I-D.pauly-taps-transport-security] 735 Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey 736 of Transport Security Protocols", draft-pauly-taps- 737 transport-security-02 (work in progress), March 2018. 739 [I-D.trammell-taps-interface] 740 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 741 Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An 742 Abstract Application Layer Interface to Transport 743 Services", draft-trammell-taps-interface-00 (work in 744 progress), March 2018. 746 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 747 of Explicit Congestion Notification (ECN) to IP", 748 RFC 3168, DOI 10.17487/RFC3168, September 2001, 749 . 751 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 752 RFC 4303, DOI 10.17487/RFC4303, December 2005, 753 . 755 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 756 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 757 . 759 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 760 Ed., "Services Provided by IETF Transport Protocols and 761 Congestion Control Mechanisms", RFC 8095, 762 DOI 10.17487/RFC8095, March 2017, 763 . 765 Authors' Addresses 766 Tommy Pauly (editor) 767 Apple Inc. 768 One Apple Park Way 769 Cupertino, California 95014 770 United States of America 772 Email: tpauly@apple.com 774 Brian Trammell (editor) 775 ETH Zurich 776 Gloriastrasse 35 777 8092 Zurich 778 Switzerland 780 Email: ietf@trammell.ch 782 Anna Brunstrom 783 Karlstad University 784 Universitetsgatan 2 785 651 88 Karlstad 786 Sweden 788 Email: anna.brunstrom@kau.se 790 Godred Fairhurst 791 University of Aberdeen 792 Fraser Noble Building 793 Aberdeen, AB24 3UE 794 Scotland 796 Email: gorry@erg.abdn.ac.uk 797 URI: http://www.erg.abdn.ac.uk/ 799 Colin Perkins 800 University of Glasgow 801 School of Computing Science 802 Glasgow G12 8QQ 803 United Kingdom 805 Email: csp@csperkins.org 806 Philipp S. Tiesel 807 TU Berlin 808 Marchstrasse 23 809 10587 Berlin 810 Germany 812 Email: philipp@inet.tu-berlin.de 814 Chris Wood 815 Apple Inc. 816 One Apple Park Way 817 Cupertino, California 95014 818 United States of America 820 Email: cawood@apple.com