idnits 2.17.1 draft-ietf-taps-interface-12.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There are 4 instances of too long lines in the document, the longest one being 12 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (9 April 2021) is 1084 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'HostCandidate' is mentioned on line 487, but not defined == Missing Reference: 'StunCandidate' is mentioned on line 487, but not defined == Outdated reference: A later version (-19) exists of draft-ietf-taps-arch-09 ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Downref: Normative reference to an Informational RFC: RFC 8303 == Outdated reference: A later version (-12) exists of draft-ietf-httpbis-priority-03 == Outdated reference: A later version (-18) exists of draft-ietf-taps-impl-08 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) -- Obsolete informational reference (is this intentional?): RFC 8229 (Obsoleted by RFC 9329) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TAPS Working Group B. Trammell, Ed. 3 Internet-Draft Google Switzerland GmbH 4 Intended status: Standards Track M. Welzl, Ed. 5 Expires: 11 October 2021 University of Oslo 6 T. Enghardt 7 Netflix 8 G. Fairhurst 9 University of Aberdeen 10 M. Kuehlewind 11 Ericsson 12 C. Perkins 13 University of Glasgow 14 P. Tiesel 15 SAP SE 16 C.A. Wood 17 Cloudflare 18 T. Pauly 19 Apple Inc. 20 K. Rose 21 Akamai Technologies, Inc. 22 9 April 2021 24 An Abstract Application Layer Interface to Transport Services 25 draft-ietf-taps-interface-12 27 Abstract 29 This document describes an abstract application programming 30 interface, API, to the transport layer, following the Transport 31 Services Architecture. It supports the asynchronous, atomic 32 transmission of messages over transport protocols and network paths 33 dynamically selected at runtime. It is intended to replace the 34 traditional BSD sockets API as the common interface to the transport 35 layer, in an environment where endpoints could select from multiple 36 interfaces and potential transport protocols. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on 11 October 2021. 55 Copyright Notice 57 Copyright (c) 2021 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 62 license-info) in effect on the date of publication of this document. 63 Please review these documents carefully, as they describe your rights 64 and restrictions with respect to this document. Code Components 65 extracted from this document must include Simplified BSD License text 66 as described in Section 4.e of the Trust Legal Provisions and are 67 provided without warranty as described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. Terminology and Notation . . . . . . . . . . . . . . . . 5 73 1.2. Specification of Requirements . . . . . . . . . . . . . . 6 74 2. Overview of Interface Design . . . . . . . . . . . . . . . . 7 75 3. API Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.1. Usage Examples . . . . . . . . . . . . . . . . . . . . . 8 77 3.1.1. Server Example . . . . . . . . . . . . . . . . . . . 9 78 3.1.2. Client Example . . . . . . . . . . . . . . . . . . . 10 79 3.1.3. Peer Example . . . . . . . . . . . . . . . . . . . . 11 80 3.2. Transport Properties . . . . . . . . . . . . . . . . . . 12 81 3.2.1. Transport Property Names . . . . . . . . . . . . . . 12 82 3.2.2. Transport Property Types . . . . . . . . . . . . . . 13 83 3.3. Scope of the Interface Definition . . . . . . . . . . . . 14 84 4. Pre-Establishment Phase . . . . . . . . . . . . . . . . . . . 15 85 4.1. Specifying Endpoints . . . . . . . . . . . . . . . . . . 16 86 4.1.1. Using Multicast Endpoints . . . . . . . . . . . . . . 17 87 4.1.2. Endpoint Aliases . . . . . . . . . . . . . . . . . . 17 88 4.1.3. Endpoint Examples . . . . . . . . . . . . . . . . . . 18 89 4.2. Specifying Transport Properties . . . . . . . . . . . . . 19 90 4.2.1. Reliable Data Transfer (Connection) . . . . . . . . . 22 91 4.2.2. Preservation of Message Boundaries . . . . . . . . . 22 92 4.2.3. Configure Per-Message Reliability . . . . . . . . . . 22 93 4.2.4. Preservation of Data Ordering . . . . . . . . . . . . 22 94 4.2.5. Use 0-RTT Session Establishment with a Safely 95 Replayable Message . . . . . . . . . . . . . . . . . 23 97 4.2.6. Multistream Connections in Group . . . . . . . . . . 23 98 4.2.7. Full Checksum Coverage on Sending . . . . . . . . . . 23 99 4.2.8. Full Checksum Coverage on Receiving . . . . . . . . . 23 100 4.2.9. Congestion control . . . . . . . . . . . . . . . . . 24 101 4.2.10. Keep alive . . . . . . . . . . . . . . . . . . . . . 24 102 4.2.11. Interface Instance or Type . . . . . . . . . . . . . 24 103 4.2.12. Provisioning Domain Instance or Type . . . . . . . . 25 104 4.2.13. Use Temporary Local Address . . . . . . . . . . . . . 26 105 4.2.14. Multipath Transport . . . . . . . . . . . . . . . . . 27 106 4.2.15. Advertisement of Alternative Addresses . . . . . . . 28 107 4.2.16. Direction of communication . . . . . . . . . . . . . 28 108 4.2.17. Notification of ICMP soft error message arrival . . . 29 109 4.2.18. Initiating side is not the first to write . . . . . . 29 110 4.3. Specifying Security Parameters and Callbacks . . . . . . 29 111 4.3.1. Pre-Connection Parameters . . . . . . . . . . . . . . 30 112 4.3.2. Connection Establishment Callbacks . . . . . . . . . 31 113 5. Establishing Connections . . . . . . . . . . . . . . . . . . 31 114 5.1. Active Open: Initiate . . . . . . . . . . . . . . . . . . 31 115 5.2. Passive Open: Listen . . . . . . . . . . . . . . . . . . 33 116 5.3. Peer-to-Peer Establishment: Rendezvous . . . . . . . . . 34 117 5.4. Connection Groups . . . . . . . . . . . . . . . . . . . . 36 118 6. Managing Connections . . . . . . . . . . . . . . . . . . . . 37 119 6.1. Generic Connection Properties . . . . . . . . . . . . . . 39 120 6.1.1. Required Minimum Corruption Protection Coverage for 121 Receiving . . . . . . . . . . . . . . . . . . . . . . 39 122 6.1.2. Connection Priority . . . . . . . . . . . . . . . . . 39 123 6.1.3. Timeout for Aborting Connection . . . . . . . . . . . 40 124 6.1.4. Timeout for keep alive packets . . . . . . . . . . . 40 125 6.1.5. Connection Group Transmission Scheduler . . . . . . . 40 126 6.1.6. Capacity Profile . . . . . . . . . . . . . . . . . . 41 127 6.1.7. Policy for using Multipath Transports . . . . . . . . 42 128 6.1.8. Bounds on Send or Receive Rate . . . . . . . . . . . 43 129 6.1.9. Group Connection Limit . . . . . . . . . . . . . . . 43 130 6.1.10. Isolate Session . . . . . . . . . . . . . . . . . . . 44 131 6.1.11. Read-only Connection Properties . . . . . . . . . . . 44 132 6.2. TCP-specific Properties: User Timeout Option (UTO) . . . 45 133 6.2.1. Advertised User Timeout . . . . . . . . . . . . . . . 46 134 6.2.2. User Timeout Enabled . . . . . . . . . . . . . . . . 46 135 6.2.3. Timeout Changeable . . . . . . . . . . . . . . . . . 46 136 6.3. Connection Lifecycle Events . . . . . . . . . . . . . . . 46 137 6.3.1. Soft Errors . . . . . . . . . . . . . . . . . . . . . 47 138 6.3.2. Path change . . . . . . . . . . . . . . . . . . . . . 47 139 7. Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . 47 140 7.1. Messages and Framers . . . . . . . . . . . . . . . . . . 47 141 7.1.1. Message Contexts . . . . . . . . . . . . . . . . . . 47 142 7.1.2. Message Framers . . . . . . . . . . . . . . . . . . . 48 143 7.1.3. Message Properties . . . . . . . . . . . . . . . . . 50 144 7.2. Sending Data . . . . . . . . . . . . . . . . . . . . . . 56 145 7.2.1. Basic Sending . . . . . . . . . . . . . . . . . . . . 56 146 7.2.2. Send Events . . . . . . . . . . . . . . . . . . . . . 57 147 7.2.3. Partial Sends . . . . . . . . . . . . . . . . . . . . 58 148 7.2.4. Batching Sends . . . . . . . . . . . . . . . . . . . 58 149 7.2.5. Send on Active Open: InitiateWithSend . . . . . . . . 59 150 7.2.6. Priority in TAPS . . . . . . . . . . . . . . . . . . 59 151 7.3. Receiving Data . . . . . . . . . . . . . . . . . . . . . 60 152 7.3.1. Enqueuing Receives . . . . . . . . . . . . . . . . . 60 153 7.3.2. Receive Events . . . . . . . . . . . . . . . . . . . 61 154 7.3.3. Receive Message Properties . . . . . . . . . . . . . 63 155 8. Connection Termination . . . . . . . . . . . . . . . . . . . 64 156 9. Connection State and Ordering of Operations and Events . . . 65 157 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 158 11. Privacy and Security Considerations . . . . . . . . . . . . . 66 159 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 68 160 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 68 161 13.1. Normative References . . . . . . . . . . . . . . . . . . 69 162 13.2. Informative References . . . . . . . . . . . . . . . . . 69 163 Appendix A. Implementation Mapping . . . . . . . . . . . . . . . 73 164 A.1. Types . . . . . . . . . . . . . . . . . . . . . . . . . . 73 165 A.2. Events and Errors . . . . . . . . . . . . . . . . . . . . 73 166 A.3. Time Duration . . . . . . . . . . . . . . . . . . . . . . 73 167 Appendix B. Convenience Functions . . . . . . . . . . . . . . . 74 168 B.1. Adding Preference Properties . . . . . . . . . . . . . . 74 169 B.2. Transport Property Profiles . . . . . . . . . . . . . . . 74 170 B.2.1. reliable-inorder-stream . . . . . . . . . . . . . . . 74 171 B.2.2. reliable-message . . . . . . . . . . . . . . . . . . 75 172 B.2.3. unreliable-datagram . . . . . . . . . . . . . . . . . 75 173 Appendix C. Relationship to the Minimal Set of Transport Services 174 for End Systems . . . . . . . . . . . . . . . . . . . . . 76 175 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 79 177 1. Introduction 179 This document specifies a modern abstract application programming 180 interface (API) atop the high-level architecture for transport 181 services defined in [I-D.ietf-taps-arch]. It supports the 182 asynchronous, atomic transmission of messages over transport 183 protocols and network paths dynamically selected at runtime. It is 184 intended to replace the traditional BSD sockets API as the common 185 interface to the transport layer, in environments where an endpoint 186 selects from multiple interfaces and potential transport protocols. 188 As applications adopt this interface, they will benefit from a wide 189 set of transport features that can evolve over time, and ensure that 190 the system providing the interface can optimize its behavior based on 191 the application requirements and network conditions, without 192 requiring changes to the applications. This flexibility enables 193 faster deployment of new features and protocols. It can also support 194 applications by offering racing and fallback mechanisms, which 195 otherwise need to be separately implemented in each application. 197 It derives specific path and protocol selection properties and 198 supported transport features from the analysis provided in [RFC8095], 199 [RFC8923], and [RFC8922]. The design encourages implementations 200 underneath the interface to dynamically choose a transport protocol 201 depending on an application's choices rather than statically binding 202 applications to a protocol at compile time. The Transport Services 203 system implementations should provide applications with a way to 204 override transport selection and instantiate a specific stack, e.g., 205 to support servers wishing to listen to a specific protocol. This 206 specific transport stack choice is discouraged for general use, 207 because it can reduce the portability. 209 1.1. Terminology and Notation 211 This API is described in terms of Objects with which an application 212 can interact; Actions the application can perform on these Objects; 213 Events, which an Object can send to an application asynchronously; 214 and Parameters associated with these Actions and Events. 216 The following notations, which can be combined, are used in this 217 document: 219 * An Action creates an Object: 221 Object := Action() 223 * An Action creates an array of Objects: 225 []Object := Action() 227 * An Action is performed on an Object: 229 Object.Action() 231 * An Object sends an Event: 233 Object -> Event<> 235 * An Action takes a set of Parameters; an Event contains a set of 236 Parameters. Action and Event parameters whose names are suffixed 237 with a question mark are optional. 239 Action(param0, param1?, ...) / Event 240 Actions associated with no Object are Actions on the abstract 241 interface itself; they are equivalent to Actions on a per-application 242 global context. 244 We also make use of the following basic types: 246 * Boolean: Instances take the value "true" or "false". 248 * Integer: Instances take positive or negative numeric integer 249 values, or sometimes special non-numeric (symbolic) values. 251 * Numeric: Instances take positive or negative numeric values, or 252 sometimes special non-numeric (symbolic) values. 254 * Enumeration: A family of types in which each instance takes one of 255 a fixed, predefined set of values specific to a given enumerated 256 type. 258 * Tuple: An ordered grouping of multiple value types, represented as 259 a comma-separated list in parentheses, e.g., "(Enumeration, 260 Preference)". Instances take a sequence of values each valid for 261 the corresponding value type. The composition of types and their 262 order depends on the property and is fixed for the property. 264 * Array: Denoted []Type, an instance takes a value for each of zero 265 or more elements in a sequence of the given Type. An array may be 266 of fixed or variable length. 268 * Collection: An unordered grouping of one or more values of the 269 same type. 271 For guidance on how these abstract concepts may be implemented in 272 languages in accordance with native design patterns and language and 273 platform features, see Appendix A. 275 1.2. Specification of Requirements 277 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 278 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 279 "OPTIONAL" in this document are to be interpreted as described in BCP 280 14 [RFC2119] [RFC8174] when, and only when, they appear in all 281 capitals, as shown here. 283 2. Overview of Interface Design 285 The design of the interface specified in this document is based on a 286 set of principles, themselves an elaboration on the architectural 287 design principles defined in [I-D.ietf-taps-arch]. The interface 288 defined in this document provides: 290 * Access to a variety of transport protocols, independent of the the 291 Protocol Stacks that will be used at runtime, such that all common 292 features of these protocol stacks are made available to the 293 application in a transport-independent way to the degree possible, 294 enabling applications written to a single API to make use of 295 transport protocols in terms of the features they provide; 297 * Message-orientation, as opposed to stream-orientation, using 298 application-assisted framing and deframing where the underlying 299 transport does not provide these; 301 * Asynchronous Connection establishment, transmission, and 302 reception, allowing concurrent operations during establishment and 303 supporting event-driven application interactions with the 304 transport layer, in line with developments in modern platforms and 305 programming languages; 307 * Explicit support for transport-specific features to be applied 308 should that particular transport be part of a chosen Protocol 309 Stack. 311 * Explicit support for security properties as first-order transport 312 features, and for configuration of cryptographic identities and 313 transport security parameters persistent across multiple 314 Connections; and 316 * Explicit support for multistreaming and multipath transport 317 protocols, and the grouping of related Connections into Connection 318 Groups through cloning of Connections, to allow applications to 319 take full advantage of new transport protocols supporting these 320 features. 322 3. API Summary 324 The Transport Services API is the basic common abstract application 325 programming interface to the Transport Services Architecture defined 326 in the TAPS Architecture [I-D.ietf-taps-arch]. 328 An application primarily interacts with this API through two Objects: 329 Preconnections and Connections. A Preconnection represents a set of 330 properties and constraints on the selection and configuration of 331 paths and protocols to establish a Connection with a Remote Endpoint. 332 A Connection represents a transport Protocol Stack on which data can 333 be sent to and/or received from a Remote Endpoint (i.e., depending on 334 the kind of transport, connections can be bi-directional or 335 unidirectional). Connections can be created from Preconnections in 336 three ways: by initiating the Preconnection (i.e., actively opening, 337 as in a client), through listening on the Preconnection (i.e., 338 passively opening, as in a server), or rendezvousing on the 339 Preconnection (i.e. peer to peer establishment). 341 Once a Connection is established, data can be sent and received on it 342 in the form of Messages. The interface supports the preservation of 343 message boundaries both via explicit Protocol Stack support, and via 344 application support through a Message Framer which finds message 345 boundaries in a stream. Messages are received asynchronously through 346 event handlers registered by the application. Errors and other 347 notifications also happen asynchronously on the Connection. It is 348 not necessary for an application to handle all Events; some Events 349 may have implementation-specific default handlers. The application 350 should not assume that ignoring Events (e.g., Errors) is always safe. 352 Section 4, Section 5, Section 7.2, Section 7.3, and Section 8 353 describe the details of application interaction with Objects through 354 Actions and Events in each phase of a Connection, following the 355 phases (Pre-Establishment, Establishment, Data Transfer, and 356 Termination) described in Section 4.1 of [I-D.ietf-taps-arch]. 358 3.1. Usage Examples 360 The following usage examples illustrate how an application might use 361 a Transport Services Interface to: 363 * Act as a server, by listening for incoming connections, receiving 364 requests, and sending responses, see Section 3.1.1. 366 * Act as a client, by connecting to a Remote Endpoint using 367 Initiate, sending requests, and receiving responses, see 368 Section 3.1.2. 370 * Act as a peer, by connecting to a Remote Endpoint using Rendezvous 371 while simultaneously waiting for incoming Connections, sending 372 Messages, and receiving Messages, see Section 3.1.3. 374 The examples in this section presume that a transport protocol is 375 available between the Local and Remote Endpoints that provides 376 Reliable Data Transfer, Preservation of data ordering, and 377 Preservation of Message Boundaries. In this case, the application 378 can choose to receive only complete messages. 380 If none of the available transport protocols provides Preservation of 381 Message Boundaries, but there is a transport protocol that provides a 382 reliable ordered byte stream, an application could receive this byte 383 stream as partial Messages and transform it into application-layer 384 Messages. Alternatively, an application might provide a Message 385 Framer, which can transform a sequence of Messages into a byte stream 386 and vice versa (Section 7.1.2). 388 3.1.1. Server Example 390 This is an example of how an application might listen for incoming 391 Connections using the Transport Services Interface, and receive a 392 request, and send a response. 394 LocalSpecifier := NewLocalEndpoint() 395 LocalSpecifier.WithInterface("any") 396 LocalSpecifier.WithService("https") 398 TransportProperties := NewTransportProperties() 399 TransportProperties.Require(preserve-msg-boundaries) 400 // Reliable Data Transfer and Preserve Order are Required by default 402 SecurityParameters := NewSecurityParameters() 403 SecurityParameters.Set(identity, myIdentity) 404 SecurityParameters.Set(key-pair, myPrivateKey, myPublicKey) 406 // Specifying a remote endpoint is optional when using Listen() 407 Preconnection := NewPreconnection(LocalSpecifier, 408 TransportProperties, 409 SecurityParameters) 411 Listener := Preconnection.Listen() 413 Listener -> ConnectionReceived 415 // Only receive complete messages in a Conn.Received handler 416 Connection.Receive() 418 Connection -> Received 420 //---- Receive event handler begin ---- 421 Connection.Send(messageDataResponse) 422 Connection.Close() 424 // Stop listening for incoming Connections 425 // (this example supports only one Connection) 426 Listener.Stop() 427 //---- Receive event handler end ---- 429 3.1.2. Client Example 431 This is an example of how an application might open two Connections 432 to a remote application using the Transport Services Interface, and 433 send a request as well as receive a response on each of them. 435 RemoteSpecifier := NewRemoteEndpoint() 436 RemoteSpecifier.WithHostname("example.com") 437 RemoteSpecifier.WithService("https") 439 TransportProperties := NewTransportProperties() 440 TransportProperties.Require(preserve-msg-boundaries) 441 // Reliable Data Transfer and Preserve Order are Required by default 443 SecurityParameters := NewSecurityParameters() 444 TrustCallback := NewCallback({ 445 // Verify identity of the remote endpoint, return the result 446 }) 447 SecurityParameters.SetTrustVerificationCallback(TrustCallback) 449 // Specifying a local endpoint is optional when using Initiate() 450 Preconnection := NewPreconnection(RemoteSpecifier, 451 TransportProperties, 452 SecurityParameters) 454 Connection := Preconnection.Initiate() 455 Connection2 := Connection.Clone() 457 Connection -> Ready<> 458 Connection2 -> Ready<> 460 //---- Ready event handler for any Connection C begin ---- 461 C.Send(messageDataRequest) 463 // Only receive complete messages 464 C.Receive() 465 //---- Ready event handler for any Connection C end ---- 467 Connection -> Received 468 Connection2 -> Received 470 // Close the Connection in a Receive event handler 471 Connection.Close() 472 Connection2.Close() 474 3.1.3. Peer Example 476 This is an example of how an application might establish a connection 477 with a peer using Rendezvous(), send a Message, and receive a 478 Message. 480 // Configure local candidates: a port on the local host and via a STUN server 481 HostCandidate := NewLocalEndpoint() 482 HostCandidate.WithPort(9876) 484 StunCandidate := NewLocalEndpoint() 485 StunCandidate.WithStunServer(address, port, credentials) 487 LocalCandidates = [HostCandidate, StunCandidate] 489 // Configure transport and security properties 490 TransportProperties := ... 491 SecurityParameters := ... 493 Preconnection := NewPreconnection(LocalCandidates, 494 [], // No remote candidates yet 495 TransportProperties, 496 SecurityParameters) 498 // Resolve the LocalCandidates. The Preconnection.Resolve() call 499 // resolves both local and remote candidates but, since the remote 500 // candidates have not yet been specified, the ResolvedRemote list 501 // returned will be empty and is not used. 502 ResolvedLocal, ResolvedRemote = Preconnection.Resolve() 504 // ...Send the ResolvedLocal list to peer via signalling channel 505 // ...Receive a list of RemoteCandidates from peer via signalling channel 507 Preconnection.AddRemote(RemoteCandidates) 508 Preconnection.Rendezvous() 510 Preconnection -> RendezvousDone 512 //---- Ready event handler begin ---- 513 Connection.Send(messageDataRequest) 514 Connection.Receive() 515 //---- Ready event handler end ---- 517 Connection -> Received 519 // Close the Connection in a Receive event handler 520 Connection.Close() 521 3.2. Transport Properties 523 Each application using the Transport Services Interface declares its 524 preferences for how the transport service should operate using 525 properties at each stage of the lifetime of a connection using 526 Transport Properties, as defined in [I-D.ietf-taps-arch]. 528 Transport Properties are divided into Selection, Connection, and 529 Message Properties. Selection Properties (see The behavior of the 530 selected protocol stack(s) when sending Messages is controlled by 531 Message Properties (see Section 4.2) can only be set during pre- 532 establishment. They are only used to specify which paths and 533 protocol stacks can be used and are preferred by the application. 534 Although Connection Properties (see Section 6.1) can be set during 535 pre-establishment, they may be changed later. They are used to 536 inform decisions made during establishment and to fine-tune the 537 established connection.Section 7.1.3). 539 All Transport Properties, regardless of the phase in which they are 540 used, are organized within a single namespace. This enables setting 541 them as defaults at earlier stages and querying them in later stages: 543 * Connection Properties can be set on Preconnections and Connections 545 * Message Properties can be set on Preconnections, Connections and 546 Messages 548 * The effect of Selection Properties can be queried on Connections 549 and Messages 551 Note that configuring Connection Properties and Message Properties on 552 Preconnections is preferred over setting them later. Early 553 specification of Connection Properties allows their use as additional 554 input to the selection process. Protocol Specific Properties, which 555 enable configuration of specialized features of a specific protocol, 556 see Section 3.2 of [I-D.ietf-taps-arch], are not used as an input to 557 the selection process but only support configuration if the 558 respective protocol has been selected. 560 3.2.1. Transport Property Names 562 Transport Properties are referred to by property names. For the 563 purposes of this document, these names are alphanumeric strings in 564 which words may be separated by hyphens. These names serve two 565 purposes: 567 * Allowing different components of a TAPS implementation to pass 568 Transport Properties, e.g., between a language frontend and a 569 policy manager, or as a representation of properties retrieved 570 from a file or other storage. 572 * Making the code of different TAPS implementations look similar. 573 While individual programming languages may preclude strict 574 adherence to the aforementioned naming convention (for instance, 575 by prohibiting the use of hyphens in symbols), users interacting 576 with multiple implementations will still benefit from the 577 consistency resulting from the use of visually similar symbols. 579 Transport Property Names are hierarchically organized in the form 580 [.]. 582 * The Namespace component MUST be empty for well-known, generic 583 properties, i.e., for properties that are not specific to a 584 protocol and are defined in an RFC. 586 * Protocol Specific Properties MUST use the protocol acronym as the 587 Namespace, e.g., "tcp" for TCP specific Transport Properties. For 588 IETF protocols, property names under these namespaces SHOULD be 589 defined in an RFC. 591 * Vendor or implementation specific properties MUST use a string 592 identifying the vendor or implementation as the Namespace. 594 Namespaces for each of the keywords provided in the IANA protocol 595 numbers registry (see https://www.iana.org/assignments/protocol- 596 numbers/protocol-numbers.xhtml), reformatted where necessary to 597 conform to an implementation's naming conventions, are reserved for 598 Protocol Specific Properties and MUST NOT be used for vendor or 599 implementation-specific properties. 601 3.2.2. Transport Property Types 603 Transport Properties each have a type, which can be: 605 * One of the basic types described in Section 1.1; or 607 * Preference, which is an Enumeration with five possible values: 608 Prohibit, Avoid, Ignore, Prefer, or Require. Each of these 609 denotes a level of preference of a given property during protocol 610 selection. (See Section 4.2.) The Preference type is used only 611 on Preconnections, and only for Selection Properties. 613 3.3. Scope of the Interface Definition 615 This document defines a language- and platform-independent interface 616 to a Transport Services system. Given the wide variety of languages 617 and language conventions used to write applications that use the 618 transport layer to connect to other applications over the Internet, 619 this independence makes this interface necessarily abstract. 621 There is no interoperability benefit in tightly defining how the 622 interface is presented to application programmers across diverse 623 platforms. However, maintaining the "shape" of the abstract 624 interface across different platforms reduces the effort for 625 programmers who learn the transport services interface to then apply 626 their knowledge to another platform. 628 We therefore make the following recommendations: 630 * Actions, Events, and Errors in implementations of this interface 631 SHOULD use the names given for them in the document, subject to 632 capitalization, punctuation, and other typographic conventions in 633 the language of the implementation, unless the implementation 634 itself uses different names for substantially equivalent objects 635 for networking by convention. 637 * Implementations of this interface SHOULD implement each Selection 638 Property, Connection Property, and Message Context Property 639 specified in this document. Each interface SHOULD be implemented 640 even when in a specific implementation/platform it will always 641 result in no operation, e.g. there is no action when the API 642 specifies a Property that is not available in a transport protocol 643 implemented on a specific platform. For example, if TCP is the 644 only underlying transport protocol, the Message Property 645 "msgOrdered" can be implemented (trivially, as a no-op) as 646 disabling the requirement for ordering will not have any effect on 647 delivery order for Connections over TCP. Similarly, the "msg- 648 lifetime" Message Property can be implemented but ignored, as the 649 description of this Property states that "it is not guaranteed 650 that a Message will not be sent when its Lifetime has expired". 652 * Implementations may use other representations for Transport 653 Property Names, e.g., by providing constants, but should provide a 654 straight-forward mapping between their representation and the 655 property names specified here. 657 4. Pre-Establishment Phase 659 The Pre-Establishment phase allows applications to specify properties 660 for the Connections that they are about to make, or to query the API 661 about potential Connections they could make. 663 A Preconnection Object represents a potential Connection. It has 664 state that describes the properties of a Connection that might exist 665 in the future. This state comprises Local Endpoint and Remote 666 Endpoint Objects that denote the endpoints of the potential 667 Connection (see Section 4.1), the Selection Properties (see 668 Section 4.2), any preconfigured Connection Properties (Section 6.1), 669 and the security parameters (see Section 4.3): 671 Preconnection := NewPreconnection([]LocalEndpoint, 672 []RemoteEndpoint, 673 TransportProperties, 674 SecurityParameters?) 676 At least one Local Endpoint MUST be specified if the Preconnection is 677 used to Listen() for incoming Connections, but the list of Local 678 Endpoints MAY be empty if the Preconnection is used to Initiate() 679 connections. If no Local Endpoint is specified, the Transport 680 Services system will assign an ephemeral local port to the Connection 681 on the appropriate interface(s). At least one Remote Endpoint MUST 682 be specified if the Preconnection is used to Initiate() Connections, 683 but the list of Remote Endpoints MAY be empty if the Preconnection is 684 used to Listen() for incoming Connections. At least one Local 685 Endpoint and one Remote Endpoint MUST be specified if a peer-to-peer 686 Rendezvous is to occur based on the Preconnection. 688 If more than one Local Endpoint is specified on a Preconnection, then 689 all the Local Endpoints on the Preconnection MUST represent the same 690 host. For example, they might correspond to different interfaces on 691 a multi-homed host, of they might correspond to local interfaces and 692 a STUN server that can be resolved to a server reflexive address for 693 a Preconnection used to make a peer-to-peer Rendezvous(). 695 If more than one Remote Endpoint is specified on the Preconnection, 696 then all the Remote Endpoints on the Preconnection SHOULD represent 697 the same host. For example, the Remote Endpoints might represent 698 various network interfaces of a host, or a server reflexive address 699 that can be used to reach a host, or a set of hosts that provide 700 equivalent local balanced service. 702 In most cases, it is expected that a single Remote Endpoint will be 703 specified by name, and a later call to Initiate() on the 704 Preconnection (see Section 5.1) will internally resolve that name to 705 a list of concrete endpoints. Specifying multiple Remote Endpoints 706 on a Preconnection allows applications to override this for more 707 detailed control. 709 Transport Properties MUST always be specified while security 710 parameters are OPTIONAL. 712 If Message Framers are used (see Section 7.1.2), they MUST be added 713 to the Preconnection during pre-establishment. 715 4.1. Specifying Endpoints 717 The transport services API uses the Local Endpoint and Remote 718 Endpoint Objects to refer to the endpoints of a transport connection. 719 Endpoints can be created as either Remote or Local: 721 RemoteSpecifier := NewRemoteEndpoint() 722 LocalSpecifier := NewLocalEndpoint() 724 A single Endpoint Object represents the identity of a network host. 725 That endpoint can be more or less specific depending on which 726 identifiers are set. For example, an Endpoint that only specifies a 727 hostname may in fact end up corresponding to several different IP 728 addresses on different hosts. 730 An Endpoint Object can be configured with the following identifiers: 732 * Hostname (string) 734 RemoteSpecifier.WithHostname("example.com") 736 * Port (a 16-bit integer) or a Service (string) that maps to a port 738 RemoteSpecifier.WithPort(443) 740 RemoteSpecifier.WithService("https") 742 * IP address (IPv4 or IPv6 address) 744 RemoteSpecifier.WithIPv4Address(192.0.2.21) 746 RemoteSpecifier.WithIPv6Address(2001:db8:4920:e29d:a420:7461:7073:0a) 748 * Interface (string name) 750 LocalSpecifier.WithInterface("en0") 751 An Endpoint cannot have multiple identifiers of a same type set. 752 That is, an endpoint cannot have two IP addresses specified. Two 753 separate IP addresses are represented as two Endpoint Objects. If a 754 Preconnection specifies a Remote Endpoint with a specific IP address 755 set, it will only establish Connections to that IP address. If, on 756 the other hand, the Remote Endpoint specifies a hostname but no 757 addresses, the Connection can perform name resolution and attempt 758 using any address derived from the original hostname of the Remote 759 Endpoint. 761 The Transport Services API resolves names internally, when the 762 Initiate(), Listen(), or Rendezvous() method is called to establish a 763 Connection. Privacy considerations for the timing of this resolution 764 are given in Section 11. 766 The Resolve() action on a Preconnection can be used by the 767 application to force early binding when required, for example with 768 some Network Address Translator (NAT) traversal protocols (see 769 Section 5.3). 771 4.1.1. Using Multicast Endpoints 773 Specifying a multicast group address on a Local Endpoint will 774 indicate to the transport system that the resulting connection will 775 be used to receive multicast messages. The Remote Endpoint can be 776 used to filter incoming multicast from specific senders. Such a 777 Preconnection will only support calling Listen(), not Initiate(). 778 The accepted Connections are receive-only. 780 Similarly, specifying a multicast group address on the Remote 781 Endpoint will indicate that the resulting connection will be used to 782 send multicast messages. 784 4.1.2. Endpoint Aliases 786 An Endpoint can have an alternative definition when using different 787 protocols. For example, a server that supports both TLS/TCP and QUIC 788 may be accessible on two different port numbers depending on which 789 protocol is used. 791 To support this, Endpoint Objects can specify "aliases". An Endpoint 792 can have multiple aliases set. 794 RemoteSpecifier.AddAlias(AlternateRemoteSpecifier) 796 In order to scope an alias to a specific transport protocol, an 797 Endpoint can specify a protocol identifier. These identifiers MUST 798 only be set for aliases. 800 RemoteSpecifier.WithProtocol(QUIC) 802 The following example shows a case where "example.com" has a server 803 running on port 443, with an alternate port of 8443 for QUIC. 805 RemoteSpecifier := NewRemoteEndpoint() 806 RemoteSpecifier.WithHostname("example.com") 807 RemoteSpecifier.WithPort(443) 809 QUICRemoteSpecifier := NewRemoteEndpoint() 810 QUICRemoteSpecifier.WithHostname("example.com") 811 QUICRemoteSpecifier.WithPort(8443) 812 QUICRemoteSpecifier.WithProtocol(QUIC) 814 RemoteSpecifier.AddAlias(QUICRemoteSpecifier) 816 4.1.3. Endpoint Examples 818 The following examples of Endpoints show common usage patterns. 820 Specify a Remote Endpoint using a hostname and service name: 822 RemoteSpecifier := NewRemoteEndpoint() 823 RemoteSpecifier.WithHostname("example.com") 824 RemoteSpecifier.WithService("https") 826 Specify a Remote Endpoint using an IPv6 address and remote port: 828 RemoteSpecifier := NewRemoteEndpoint() 829 RemoteSpecifier.WithIPv6Address(2001:db8:4920:e29d:a420:7461:7073:0a) 830 RemoteSpecifier.WithPort(443) 832 Specify a Remote Endpoint using an IPv4 address and remote port: 834 RemoteSpecifier := NewRemoteEndpoint() 835 RemoteSpecifier.WithIPv4Address(192.0.2.21) 836 RemoteSpecifier.WithPort(443) 838 Specify a Local Endpoint using a local interface name and local port: 840 LocalSpecifier := NewLocalEndpoint() 841 LocalSpecifier.WithInterface("en0") 842 LocalSpecifier.WithPort(443) 844 As an alternative to specifying an interface name for the Local 845 Endpoint, an application can express more fine-grained preferences 846 using the "Interface Instance or Type" Selection Property, see 847 Section 4.2.11. However, if the application specifies Selection 848 Properties that are inconsistent with the Local Endpoint, this will 849 result in an Error once the application attempts to open a 850 Connection. 852 Specify a Local Endpoint using a STUN server: 854 LocalSpecifier := NewLocalEndpoint() 855 LocalSpecifier.WithStunServer(address, port, credentials) 857 Specify a Local Endpoint using a Any-Source Multicast group to join 858 on a named local interface: 860 LocalSpecifier := NewLocalEndpoint() 861 LocalSpecifier.WithIPv4Address(233.252.0.0) 862 LocalSpecifier.WithInterface("en0") 864 Source-Specific Multicast requires setting both a Local and Remote 865 Endpoint: 867 LocalSpecifier := NewLocalEndpoint() 868 LocalSpecifier.WithIPv4Address(232.1.1.1) 869 LocalSpecifier.WithInterface("en0") 871 RemoteSpecifier := NewRemoteEndpoint() 872 RemoteSpecifier.WithIPv4Address(192.0.2.22) 874 4.2. Specifying Transport Properties 876 A Preconnection Object holds properties reflecting the application's 877 requirements and preferences for the transport. These include 878 Selection Properties for selecting protocol stacks and paths, as well 879 as Connection Properties for configuration of the detailed operation 880 of the selected Protocol Stacks. 882 The protocol(s) and path(s) selected as candidates during 883 establishment are determined and configured using these properties. 884 Since there could be paths over which some transport protocols are 885 unable to operate, or remote endpoints that support only specific 886 network addresses or transports, transport protocol selection is 887 necessarily tied to path selection. This may involve choosing 888 between multiple local interfaces that are connected to different 889 access networks. 891 Most Selection Properties are represented as Preferences, which can 892 take one of five values: 894 +============+========================================+ 895 | Preference | Effect | 896 +============+========================================+ 897 | Require | Select only protocols/paths providing | 898 | | the property, fail otherwise | 899 +------------+----------------------------------------+ 900 | Prefer | Prefer protocols/paths providing the | 901 | | property, proceed otherwise | 902 +------------+----------------------------------------+ 903 | Ignore | No preference | 904 +------------+----------------------------------------+ 905 | Avoid | Prefer protocols/paths not providing | 906 | | the property, proceed otherwise | 907 +------------+----------------------------------------+ 908 | Prohibit | Select only protocols/paths not | 909 | | providing the property, fail otherwise | 910 +------------+----------------------------------------+ 912 Table 1: Selection Property Preference Levels 914 The implementation MUST ensure an outcome that is consistent with all 915 application requirements expressed using Require and Prohibit. While 916 preferences expressed using Prefer and Avoid influence protocol and 917 path selection as well, outcomes can vary given the same Selection 918 Properties, because the available protocols and paths can differ 919 across systems and contexts. However, implementations are 920 RECOMMENDED to seek to provide a consistent outcome to an 921 application, given the same set of Selection Properties. 923 Note that application preferences can conflict with each other. For 924 example, if an application indicates a preference for a specific path 925 by specifying an interface, but also a preference for a protocol, a 926 situation might occur in which the preferred protocol is not 927 available on the preferred path. In such cases, implementations 928 SHOULD prioritize Selection Properties that select paths over those 929 that select protocols. Therefore, the transport system SHOULD race 930 the path first, ignoring the protocol preference if a specific 931 protocol does not work on the path. 933 Selection and Connection Properties, as well as defaults for Message 934 Properties, can be added to a Preconnection to configure the 935 selection process and to further configure the eventually selected 936 protocol stack(s). They are collected into a TransportProperties 937 object to be passed into a Preconnection object: 939 TransportProperties := NewTransportProperties() 940 Individual properties are then set on the TransportProperties Object. 941 Setting a Transport Property to a value overrides the previous value 942 of this Transport Property. 944 TransportProperties.Set(property, value) 946 To aid readability, implementations MAY provide additional 947 convenience functions to simplify use of Selection Properties: see 948 Appendix B.1 for examples. In addition, implementations MAY provide 949 a mechanism to create TransportProperties objects that are 950 preconfigured for common use cases as outlined in Appendix B.2. 952 Transport Properties for an established connection can be queried via 953 the Connection object, as outlined in Section 6. 955 A Connection gets its Transport Properties either by being explicitly 956 configured via a Preconnection, by configuration after establishment, 957 or by inheriting them from an antecedent via cloning; see Section 5.4 958 for more. 960 Section 6.1 provides a list of Connection Properties, while Selection 961 Properties are listed in the subsections below. Many properties are 962 only considered during establishment, and can not be changed after a 963 Connection is established; however, they can still be queried. The 964 return type of a queried Selection Property is Boolean, where "true" 965 means that the Selection Property has been applied and "false" means 966 that the Selection Property has not been applied. Note that "true" 967 does not mean that a request has been honored. For example, if 968 "Congestion control" was requested with preference level "Prefer", 969 but congestion control could not be supported, querying the 970 "congestionControl" property yields the value "false". If the 971 preference level "Avoid" was used for "Congestion control", and, as 972 requested, the Connection is not congestion controlled, querying the 973 "congestionControl" property also yields the value "false". 975 An implementation of this interface must provide sensible defaults 976 for Selection Properties. The recommended default values for each 977 property below represent a configuration that can be implemented over 978 TCP. If these default values are used and TCP is not supported by a 979 Transport Services implementation, then an application using the 980 default set of Properties might not succeed in establishing a 981 connection. Using the same default values for independent Transport 982 Services implementations can be beneficial when applications are 983 ported between different implementations/platforms, even if this 984 default could lead to a connection failure when TCP is not available. 985 If default values other than those recommended below are used, it is 986 recommended to clearly document any differences. 988 4.2.1. Reliable Data Transfer (Connection) 990 Name: reliability 992 Type: Preference 994 Default: Require 996 This property specifies whether the application needs to use a 997 transport protocol that ensures that all data is received at the 998 Remote Endpoint without corruption. When reliable data transfer is 999 enabled, this also entails being notified when a Connection is closed 1000 or aborted. 1002 4.2.2. Preservation of Message Boundaries 1004 Name: preserveMsgBoundaries 1006 Type: Preference 1008 Default: Prefer 1010 This property specifies whether the application needs or prefers to 1011 use a transport protocol that preserves message boundaries. 1013 4.2.3. Configure Per-Message Reliability 1015 Name: perMsgReliability 1017 Type: Preference 1019 Default: Ignore 1021 This property specifies whether an application considers it useful to 1022 indicate its reliability requirements on a per-Message basis. This 1023 property applies to Connections and Connection Groups. 1025 4.2.4. Preservation of Data Ordering 1027 Name: preserveOrder 1029 Type: Preference 1031 Default: Require 1033 This property specifies whether the application wishes to use a 1034 transport protocol that can ensure that data is received by the 1035 application on the other end in the same order as it was sent. 1037 4.2.5. Use 0-RTT Session Establishment with a Safely Replayable Message 1039 Name: zeroRttMsg 1041 Type: Preference 1043 Default: Ignore 1045 This property specifies whether an application would like to supply a 1046 Message to the transport protocol before Connection establishment 1047 that will then be reliably transferred to the other side before or 1048 during Connection establishment. This Message can potentially be 1049 received multiple times (i.e., multiple copies of the message data 1050 may be passed to the Remote Endpoint). See also Section 7.1.3.4. 1051 Note that disabling this property has no effect for protocols that 1052 are not connection-oriented and do not protect against duplicated 1053 messages, e.g., UDP. 1055 4.2.6. Multistream Connections in Group 1057 Name: multistreaming 1059 Type: Preference 1061 Default: Prefer 1063 This property specifies that the application would prefer multiple 1064 Connections within a Connection Group to be provided by streams of a 1065 single underlying transport connection where possible. 1067 4.2.7. Full Checksum Coverage on Sending 1069 Name: perMsgChecksumLenSend 1071 Type: Preference 1073 Default: Require 1075 This property specifies the application's need for protection against 1076 corruption for all data transmitted on this Connection. Disabling 1077 this property could enable later control of the sender checksum 1078 coverage (see Section 7.1.3.6). 1080 4.2.8. Full Checksum Coverage on Receiving 1082 Name: perMsgChecksumLenRecv 1084 Type: Preference 1085 Default: Require 1087 This property specifies the application's need for protection against 1088 corruption for all data received on this Connection. Disabling this 1089 property could enable later control of the required minimum receiver 1090 checksum coverage (see Section 6.1.1). 1092 4.2.9. Congestion control 1094 Name: congestionControl 1096 Type: Preference 1098 Default: Require 1100 This property specifies whether the application would like the 1101 Connection to be congestion controlled or not. Note that if a 1102 Connection is not congestion controlled, an application using such a 1103 Connection SHOULD itself perform congestion control in accordance 1104 with [RFC2914] or use a circuit breaker in accordance with [RFC8084], 1105 whichever is appropriate. Also note that reliability is usually 1106 combined with congestion control in protocol implementations, 1107 rendering "reliable but not congestion controlled" a request that is 1108 unlikely to succeed. If the Connection is congestion controlled, 1109 performing additional congestion control in the application can have 1110 negative performance implications. 1112 4.2.10. Keep alive 1114 Name: keepAlive 1116 Type: Preference 1118 Default: Ignore 1120 This property specifies whether the application would like the 1121 Connection to send keep-alive packets or not. Note that if a 1122 Connection determines that keep-alive packets are being sent, the 1123 applicaton should itself avoid generating additional keep alive 1124 messages. Note that when supported, the system will use the default 1125 period for generation of the keep alive-packets. (See also 1126 Section 6.1.4). 1128 4.2.11. Interface Instance or Type 1130 Name: interface 1132 Type: Collection of (Preference, Enumeration) 1133 Default: Empty (not setting a preference for any interface) 1135 This property allows the application to select any specific network 1136 interfaces or categories of interfaces it wants to "Require", 1137 "Prohibit", "Prefer", or "Avoid". Note that marking a specific 1138 interface as "Require" strictly limits path selection to that single 1139 interface, and often leads to less flexible and resilient connection 1140 establishment. 1142 In contrast to other Selection Properties, this property is a tuple 1143 of an (Enumerated) interface identifier and a preference, and can 1144 either be implemented directly as such, or for making one preference 1145 available for each interface and interface type available on the 1146 system. 1148 The set of valid interface types is implementation- and system- 1149 specific. For example, on a mobile device, there may be "Wi-Fi" and 1150 "Cellular" interface types available; whereas on a desktop computer, 1151 "Wi-Fi" and "Wired Ethernet" interface types might be available. An 1152 implementation should provide all types that are supported on the 1153 local system to all remote systems, to allow applications to be 1154 written generically. For example, if a single implementation is used 1155 on both mobile devices and desktop devices, it should define the 1156 "Cellular" interface type for both systems, since an application 1157 might wish to always prohibit cellular. 1159 The set of interface types is expected to change over time as new 1160 access technologies become available. The taxonomy of interface 1161 types on a given Transport Services system is implementation- 1162 specific. 1164 Interface types should not be treated as a proxy for properties of 1165 interfaces such as metered or unmetered network access. If an 1166 application needs to prohibit metered interfaces, this should be 1167 specified via Provisioning Domain attributes (see Section 4.2.12) or 1168 another specific property. 1170 4.2.12. Provisioning Domain Instance or Type 1172 Name: pvd 1174 Type: Collection of (Preference, Enumeration) 1176 Default: Empty (not setting a preference for any PvD) 1178 Similar to interface instances and types (see Section 4.2.11), this 1179 property allows the application to control path selection by 1180 selecting which specific Provisioning Domain (PvD) or categories of 1181 PVDs it wants to "Require", "Prohibit", "Prefer", or "Avoid". 1182 Provisioning Domains define consistent sets of network properties 1183 that may be more specific than network interfaces [RFC7556]. 1185 As with interface instances and types, this property is a tuple of an 1186 (Enumerated) PvD identifier and a preference, and can either be 1187 implemented directly as such, or for making one preference available 1188 for each interface and interface type available on the system. 1190 The identification of a specific PvD is implementation- and system- 1191 specific, because there is currently no portable standard format for 1192 a PvD identifier. For example, this identifier might be a string 1193 name or an integer. As with requiring specific interfaces, requiring 1194 a specific PvD strictly limits the path selection. 1196 Categories or types of PvDs are also defined to be implementation- 1197 and system-specific. These can be useful to identify a service that 1198 is provided by a PvD. For example, if an application wants to use a 1199 PvD that provides a Voice-Over-IP service on a Cellular network, it 1200 can use the relevant PvD type to require a PvD that provides this 1201 service, without needing to look up a particular instance. While 1202 this does restrict path selection, it is broader than requiring 1203 specific PvD instances or interface instances, and should be 1204 preferred over these options. 1206 4.2.13. Use Temporary Local Address 1208 Name: useTemporaryLocalAddress 1210 Type: Preference 1212 Default: Avoid for Listeners and Rendezvous Connections. Prefer for 1213 other Connections. 1215 This property allows the application to express a preference for the 1216 use of temporary local addresses, sometimes called "privacy" 1217 addresses [RFC4941]. Temporary addresses are generally used to 1218 prevent linking connections over time when a stable address, 1219 sometimes called "permanent" address, is not needed. There are some 1220 caveats to note when specifying this property. First, if an 1221 application Requires the use of temporary addresses, the resulting 1222 Connection cannot use IPv4, because temporary addresses do not exist 1223 in IPv4. Second, temporary local addresses might involve trading off 1224 privacy for performance. For instance, temporary addresses can 1225 interfere with resumption mechanisms that some protocols rely on to 1226 reduce initial latency. 1228 4.2.14. Multipath Transport 1230 Name: multipath 1232 Type: Enumeration 1234 Default: Disabled for connections created through initiate and 1235 rendezvous, Passive for listeners 1237 This property specifies whether and how applications want to take 1238 advantage of transferring data across multiple paths between the same 1239 end hosts. Using multiple paths allows connections to migrate 1240 between interfaces or aggregate bandwidth as availability and 1241 performance properties change. Possible values are: 1243 Disabled: The connection will not use multiple paths once 1244 established, even if the chosen transport supports using multiple 1245 paths. 1247 Active: The connection will negotiate the use of multiple paths if 1248 the chosen transport supports this. 1250 Passive: The connection will support the use of multiple paths if 1251 the remote endpoint requests it. 1253 The policy for using multiple paths is specified using the separate 1254 "multipath-policy" property, see Section 6.1.7 below. To enable the 1255 peer endpoint to initiate additional paths towards a local address 1256 other than the one initially used, it is necessary to set the 1257 Alternative Addresses property (see Section 4.2.15 below). 1259 Setting this property to "Active", can have privacy implications: It 1260 enables the transport to establish connectivity using alternate paths 1261 that might result in users being linkable across the multiple paths, 1262 even if the Advertisement of Alternative Addresses property (see 1263 Section 4.2.15 below) is set to false. 1265 Enumeration values other than "Disabled" are interpreted as a 1266 preference for choosing protocols that can make use of multiple 1267 paths. The "Disabled" value implies a requirement not to use 1268 multiple paths in parallel but does not prevent choosing a protocol 1269 that is capable of using multiple paths, e.g., it does not prevent 1270 choosing TCP, but prevents sending the "MP_CAPABLE" option in the TCP 1271 handshake. 1273 4.2.15. Advertisement of Alternative Addresses 1275 Name: advertises-altaddr 1277 Type: Boolean 1279 Default: False 1281 This property specifies whether alternative addresses, e.g., of other 1282 interfaces, should be advertised to the peer endpoint by the protocol 1283 stack. Advertising these addresses enables the peer-endpoint to 1284 establish additional connectivity, e.g., for connection migration or 1285 using multiple paths. 1287 Note that this can have privacy implications because it might result 1288 in users being linkable across the multiple paths. Also, note that 1289 setting this to false does not prevent the local Transport Services 1290 system from _establishing_ connectivity using alternate paths (see 1291 Section 4.2.14 above); it only prevents _proactive advertisement_ of 1292 addresses. 1294 4.2.16. Direction of communication 1296 Name: direction 1298 Type: Enumeration 1300 Default: Bidirectional 1302 This property specifies whether an application wants to use the 1303 connection for sending and/or receiving data. Possible values are: 1305 Bidirectional: The connection must support sending and receiving 1306 data 1308 Unidirectional send: The connection must support sending data, and 1309 the application cannot use the connection to receive any data 1311 Unidirectional receive: The connection must support receiving data, 1312 and the application cannot use the connection to send any data 1314 Since unidirectional communication can be supported by transports 1315 offering bidirectional communication, specifying unidirectional 1316 communication may cause a transport stack that supports bidirectional 1317 communication to be selected. 1319 4.2.17. Notification of ICMP soft error message arrival 1321 Name: softErrorNotify 1323 Type: Preference 1325 Default: Ignore 1327 This property specifies whether an application considers it useful to 1328 be informed when an ICMP error message arrives that does not force 1329 termination of a connection. When set to true, received ICMP errors 1330 are available as SoftErrors, see Section 6.3.1. Note that even if a 1331 protocol supporting this property is selected, not all ICMP errors 1332 will necessarily be delivered, so applications cannot rely upon 1333 receiving them [RFC8085]. 1335 4.2.18. Initiating side is not the first to write 1337 Name: activeReadBeforeSend 1339 Type: Preference 1341 Default: Ignore 1343 The most common client-server communication pattern involves the 1344 client actively opening a connection, then sending data to the 1345 server. The server listens (passive open), reads, and then answers. 1346 This property specifies whether an application wants to diverge from 1347 this pattern - either by actively opening with Initiate(), 1348 immediately followed by reading, or passively opening with Listen(), 1349 immediately followed by writing. This property is ignored when 1350 establishing connections using Rendezvous(). Requiring this property 1351 limits the choice of mappings to underlying protocols, which can 1352 reduce efficiency. For example, it prevents the Transport Services 1353 system from mapping Connections to SCTP streams, where the first 1354 transmitted data takes the role of an active open signal 1355 [I-D.ietf-taps-impl]. 1357 4.3. Specifying Security Parameters and Callbacks 1359 Most security parameters, e.g., TLS ciphersuites, local identity and 1360 private key, etc., may be configured statically. Others are 1361 dynamically configured during connection establishment. Security 1362 parameters and callbacks are partitioned based on their place in the 1363 lifetime of connection establishment. Similar to Transport 1364 Properties, both parameters and callbacks are inherited during 1365 cloning (see Section 5.4). 1367 4.3.1. Pre-Connection Parameters 1369 Common parameters such as TLS ciphersuites are known to 1370 implementations. Clients should use common safe defaults for these 1371 values whenever possible. However, as discussed in [RFC8922], many 1372 transport security protocols require specific security parameters and 1373 constraints from the client at the time of configuration and actively 1374 during a handshake. These configuration parameters need to be 1375 specified in the pre-connection phase and are created as follows: 1377 SecurityParameters := NewSecurityParameters() 1379 Security configuration parameters and sample usage follow: 1381 * Local identity and private keys: Used to perform private key 1382 operations and prove one's identity to the Remote Endpoint. 1383 (Note, if private keys are not available, e.g., since they are 1384 stored in hardware security modules (HSMs), handshake callbacks 1385 must be used. See below for details.) 1387 SecurityParameters.Set(identity, myIdentity) 1388 SecurityParameters.Set(key-pair, myPrivateKey, myPublicKey) 1390 * Supported algorithms: Used to restrict what parameters are used by 1391 underlying transport security protocols. When not specified, 1392 these algorithms should use known and safe defaults for the 1393 system. Parameters include: ciphersuites, supported groups, and 1394 signature algorithms. These parameters take a collection of 1395 supported algorithms as parameter. 1397 SecurityParameters.Set(supported-group, "secp256k1") 1398 SecurityParameters.Set(ciphersuite, "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256") 1399 SecurityParameters.Set(signature-algorithm, "ed25519") 1401 * Pre-Shared Key import: Used to install pre-shared keying material 1402 established out-of-band. Each pre-shared keying material is 1403 associated with some identity that typically identifies its use or 1404 has some protocol-specific meaning to the Remote Endpoint. 1406 SecurityParameters.Set(pre-shared-key, key, identity) 1408 * Session cache management: Used to tune session cache capacity, 1409 lifetime, and other policies. 1411 SecurityParameters.Set(max-cached-sessions, 16) 1412 SecurityParameters.Set(cached-session-lifetime-seconds, 3600) 1413 Representation of Security Parameters in implementations should 1414 parallel that chosen for Transport Property names as recommended in 1415 Section 3.3. 1417 4.3.2. Connection Establishment Callbacks 1419 Security decisions, especially pertaining to trust, are not static. 1420 Once configured, parameters may also be supplied during connection 1421 establishment. These are best handled as client-provided callbacks. 1422 Security handshake callbacks that may be invoked during connection 1423 establishment include: 1425 * Trust verification callback: Invoked when a Remote Endpoint's 1426 trust must be validated before the handshake protocol can 1427 continue. 1429 TrustCallback := NewCallback({ 1430 // Handle trust, return the result 1431 }) 1432 SecurityParameters.SetTrustVerificationCallback(trustCallback) 1434 * Identity challenge callback: Invoked when a private key operation 1435 is required, e.g., when local authentication is requested by a 1436 remote. 1438 ChallengeCallback := NewCallback({ 1439 // Handle challenge 1440 }) 1441 SecurityParameters.SetIdentityChallengeCallback(challengeCallback) 1443 5. Establishing Connections 1445 Before a Connection can be used for data transfer, it needs to be 1446 established. Establishment ends the pre-establishment phase; all 1447 transport properties and cryptographic parameter specification must 1448 be complete before establishment, as these will be used to select 1449 candidate Paths and Protocol Stacks for the Connection. 1450 Establishment may be active, using the Initiate() Action; passive, 1451 using the Listen() Action; or simultaneous for peer-to-peer, using 1452 the Rendezvous() Action. These Actions are described in the 1453 subsections below. 1455 5.1. Active Open: Initiate 1457 Active open is the Action of establishing a Connection to a Remote 1458 Endpoint presumed to be listening for incoming Connection requests. 1459 Active open is used by clients in client-server interactions. Active 1460 open is supported by this interface through the Initiate Action: 1462 Connection := Preconnection.Initiate(timeout?) 1464 The timeout parameter specifies how long to wait before aborting 1465 Active open. Before calling Initiate, the caller must have populated 1466 a Preconnection Object with a Remote Endpoint specifier, optionally a 1467 Local Endpoint specifier (if not specified, the system will attempt 1468 to determine a suitable Local Endpoint), as well as all properties 1469 necessary for candidate selection. 1471 The Initiate() Action returns a Connection object. Once Initiate() 1472 has been called, any changes to the Preconnection MUST NOT have any 1473 effect on the Connection. However, the Preconnection can be reused, 1474 e.g., to Initiate another Connection. 1476 Once Initiate is called, the candidate Protocol Stack(s) may cause 1477 one or more candidate transport-layer connections to be created to 1478 the specified remote endpoint. The caller may immediately begin 1479 sending Messages on the Connection (see Section 7.2) after calling 1480 Initiate(); note that any data marked "Safely Replayable" that is 1481 sent while the Connection is being established may be sent multiple 1482 times or on multiple candidates. 1484 The following Events may be sent by the Connection after Initiate() 1485 is called: 1487 Connection -> Ready<> 1489 The Ready Event occurs after Initiate has established a transport- 1490 layer connection on at least one usable candidate Protocol Stack over 1491 at least one candidate Path. No Receive Events (see Section 7.3) 1492 will occur before the Ready Event for Connections established using 1493 Initiate. 1495 Connection -> EstablishmentError 1497 An EstablishmentError occurs either when the set of transport 1498 properties and security parameters cannot be fulfilled on a 1499 Connection for initiation (e.g., the set of available Paths and/or 1500 Protocol Stacks meeting the constraints is empty) or reconciled with 1501 the Local and/or Remote Endpoints; when the remote specifier cannot 1502 be resolved; or when no transport-layer connection can be established 1503 to the Remote Endpoint (e.g., because the Remote Endpoint is not 1504 accepting connections, the application is prohibited from opening a 1505 Connection by the operating system, or the establishment attempt has 1506 timed out for any other reason). 1508 Connection establishment and transmission of the first message can be 1509 combined in a single action Section 7.2.5. 1511 5.2. Passive Open: Listen 1513 Passive open is the Action of waiting for Connections from Remote 1514 Endpoints, commonly used by servers in client-server interactions. 1515 Passive open is supported by this interface through the Listen Action 1516 and returns a Listener object: 1518 Listener := Preconnection.Listen() 1520 Before calling Listen, the caller must have initialized the 1521 Preconnection during the pre-establishment phase with a Local 1522 Endpoint specifier, as well as all properties necessary for Protocol 1523 Stack selection. A Remote Endpoint may optionally be specified, to 1524 constrain what Connections are accepted. 1526 The Listen() Action returns a Listener object. Once Listen() has 1527 been called, any changes to the Preconnection MUST NOT have any 1528 effect on the Listener. The Preconnection can be disposed of or 1529 reused, e.g., to create another Listener. 1531 Listener.Stop() 1533 Listening continues until the global context shuts down, or until the 1534 Stop action is performed on the Listener object. 1536 Listener -> ConnectionReceived 1538 The ConnectionReceived Event occurs when a Remote Endpoint has 1539 established a transport-layer connection to this Listener (for 1540 Connection-oriented transport protocols), or when the first Message 1541 has been received from the Remote Endpoint (for Connectionless 1542 protocols), causing a new Connection to be created. The resulting 1543 Connection is contained within the ConnectionReceived Event, and is 1544 ready to use as soon as it is passed to the application via the 1545 event. 1547 Listener.SetNewConnectionLimit(value) 1549 If the caller wants to rate-limit the number of inbound Connections 1550 that will be delivered, it can set a cap using 1551 SetNewConnectionLimit(). This mechanism allows a server to protect 1552 itself from being drained of resources. Each time a new Connection 1553 is delivered by the ConnectionReceived Event, the value is 1554 automatically decremented. Once the value reaches zero, no further 1555 Connections will be delivered until the caller sets the limit to a 1556 higher value. By default, this value is Infinite. The caller is 1557 also able to reset the value to Infinite at any point. 1559 Listener -> EstablishmentError 1561 An EstablishmentError occurs either when the Properties and Security 1562 Parameters of the Preconnection cannot be fulfilled for listening or 1563 cannot be reconciled with the Local Endpoint (and/or Remote Endpoint, 1564 if specified), when the Local Endpoint (or Remote Endpoint, if 1565 specified) cannot be resolved, or when the application is prohibited 1566 from listening by policy. 1568 Listener -> Stopped<> 1570 A Stopped Event occurs after the Listener has stopped listening. 1572 5.3. Peer-to-Peer Establishment: Rendezvous 1574 Simultaneous peer-to-peer Connection establishment is supported by 1575 the Rendezvous() Action: 1577 Preconnection.Rendezvous() 1579 A Preconnection Object used in a Rendezvous() MUST have both the 1580 Local Endpoint candidates and the Remote Endpoint candidates 1581 specified, along with the transport properties and security 1582 parameters needed for Protocol Stack selection, before the 1583 Rendezvous() Action is initiated. 1585 The Rendezvous() Action listens on the Local Endpoint candidates for 1586 an incoming Connection from the Remote Endpoint candidates, while 1587 also simultaneously trying to establish a Connection from the Local 1588 Endpoint candidates to the Remote Endpoint candidates. 1590 If there are multiple Local Endpoints or Remote Endpoints configured, 1591 then initiating a Rendezvous() action will systematically probe the 1592 reachability of those endpoint candidates following an approach such 1593 as that used in Interactive Connectivity Establishment (ICE) 1594 [RFC5245]. 1596 If the endpoints are suspected to be behind a NAT, Rendezvous() can 1597 be initiated using Local Endpoints that support a method of 1598 discovering NAT bindings such as Session Traversal Utilities for NAT 1599 (STUN) [RFC8489] or Traversal Using Relays around NAT (TURN) 1600 [RFC5766]. In this case, the Local Endpoint will resolve to a 1601 mixture of local and server reflexive addresses. The Resolve() 1602 action on the Preconnection can be used to discover these bindings: 1604 []LocalEndpoint, []RemoteEndpoint := Preconnection.Resolve() 1605 The Resolve() call returns lists of Local Endpoints and Remote 1606 Endpoints, that represent the concrete addresses, local and server 1607 reflexive, on which a Rendezvous() for the Preconnection will listen 1608 for incoming Connections, and to which it will attempt to establish 1609 connections. 1611 An application that uses Rendezvous() to establish a peer-to-peer 1612 connection in the presence of NATs will configure the Preconnection 1613 object with at least one a Local Endpoint that supports NAT binding 1614 discovery. It will then Resolve() the Preconnection, and pass the 1615 resulting list of Local Endpoint candidates to the peer via a 1616 signalling protocol, for example as part of an ICE [RFC5245] exchange 1617 within SIP [RFC3261] or WebRTC [RFC7478]. The peer will then, via 1618 the same signalling channel, return the Remote Endpoint candidates. 1619 The set of Remote Endpoint candidates are then configured onto the 1620 Preconnection: 1622 Preconnection.AddRemote([]RemoteEndpoint) 1624 The Rendezvous() Action can be initiated once both the Local Endpoint 1625 candidates and the Remote Endpoint candidates retrieved from the peer 1626 via the signalling channel have been added to the Preconnection. 1628 If successful, the Rendezvous() Action returns a Connection object 1629 via a RendezvousDone<> Event: 1631 Preconnection -> RendezvousDone 1633 The RendezvousDone<> Event occurs when a Connection is established 1634 with the Remote Endpoint. For Connection-oriented transports, this 1635 occurs when the transport-layer connection is established; for 1636 Connectionless transports, it occurs when the first Message is 1637 received from the Remote Endpoint. The resulting Connection is 1638 contained within the RendezvousDone<> Event, and is ready to use as 1639 soon as it is passed to the application via the Event. Changes made 1640 to a Preconnection after Rendezvous() has been called do not have any 1641 effect on existing Connections. 1643 An EstablishmentError occurs either when the Properties and Security 1644 Parameters of the Preconnection cannot be fulfilled for rendezvous or 1645 cannot be reconciled with the Local and/or Remote Endpoints, when the 1646 Local Endpoint or Remote Endpoint cannot be resolved, when no 1647 transport-layer connection can be established to the Remote Endpoint, 1648 or when the application is prohibited from rendezvous by policy: 1650 Preconnection -> EstablishmentError 1652 5.4. Connection Groups 1654 Entangled Connections can be created using the Clone Action: 1656 Connection := Connection.Clone() 1658 Calling Clone on a Connection yields a group of Connections: the 1659 parent Connection on which Clone was called, and a resulting cloned 1660 Connection. The connections within a group are "entangled" with each 1661 other, and become part of a Connection Group. Calling Clone on any 1662 of these Connections adds another Connection to the Connection Group, 1663 and so on. "Entangled" Connections share all Connection Properties 1664 except "Connection Priority" (see Section 6.1.2) . Like all other 1665 Properties, Connection Priority is copied to the new Connection when 1666 calling Clone(), but it is not entangled: Changing Connection 1667 Priority on one Connection does not change it on the other 1668 Connections in the same Connection Group. 1670 The stack of Message Framers associated with a Connection are also 1671 copied to the cloned Connection when calling Clone. In other words, 1672 a cloned Connection has the same stack of Message Framers as the 1673 Connection from which they are Cloned, but these Framers may 1674 internally maintain per-Connection state. 1676 It is also possible to check which Connections belong to the same 1677 Connection Group. Calling GroupedConnections() on a specific 1678 Connection returns a set of all Connections in the same group. 1680 []Connection := Connection.GroupedConnections() 1682 Connections will belong to the same group if the application 1683 previously called Clone. Passive Connections can also be added to 1684 the same group - e.g., when a Listener receives a new Connection that 1685 is just a new stream of an already active multi-streaming protocol 1686 instance. 1688 Changing one of the Connection Properties on one Connection in the 1689 group changes it for all others. Message Properties, however, are 1690 not entangled. For example, changing "Timeout for aborting 1691 Connection" (see Section 6.1.3) on one Connection in a group will 1692 automatically change this Connection Property for all Connections in 1693 the group in the same way. However, changing "Lifetime" (see 1694 Section 7.1.3.1) of a Message will only affect a single Message on a 1695 single Connection, entangled or not. 1697 If the underlying protocol supports multi-streaming, it is natural to 1698 use this functionality to implement Clone. In that case, entangled 1699 Connections are multiplexed together, giving them similar treatment 1700 not only inside endpoints, but also across the end-to-end Internet 1701 path. 1703 Note that calling Clone() can result in on-the-wire signaling, e.g., 1704 to open a new connection, depending on the underlying Protocol Stack. 1705 When Clone() leads to multiple connections being opened instead of 1706 multi-streaming, the Transport Services system will ensure 1707 consistency of Connection Properties by uniformly applying them to 1708 all underlying connections in a group. Even in such a case, there 1709 are possibilities for a Transport Services system to implement 1710 prioritization within a Connection Group [TCP-COUPLING] [RFC8699]. 1712 Attempts to clone a Connection can result in a CloneError: 1714 Connection -> CloneError 1716 The Connection Priority Connection Property operates on entangled 1717 Connections using the same approach as in Section 7.1.3.2: when 1718 allocating available network capacity among Connections in a 1719 Connection Group, sends on Connections with lower Priority values 1720 will be prioritized over sends on Connections with higher Priority 1721 values. Capacity will be shared among these Connections according to 1722 the Connection Group Transmission Scheduler property (Section 6.1.5). 1723 See Section 7.2.6 for more. 1725 6. Managing Connections 1727 During pre-establishment and after establishment, connections can be 1728 configured and queried using Connection Properties, and asynchronous 1729 information may be available about the state of the connection via 1730 Soft Errors. 1732 Connection Properties represent the configuration and state of the 1733 selected Protocol Stack(s) backing a Connection. These Connection 1734 Properties may be Generic, applying regardless of transport protocol, 1735 or Specific, applicable to a single implementation of a single 1736 transport protocol stack. Generic Connection Properties are defined 1737 in Section 6.1 below. Specific Protocol Properties are defined in a 1738 transport- and implementation-specific way, and MUST NOT be assumed 1739 to apply across different protocols. Attempts to set Specific 1740 Protocol Properties on a protocol stack not containing that specific 1741 protocol are simply ignored, and do not raise an error; however, too 1742 much reliance by an application on Specific Protocol Properties can 1743 significantly reduce the flexibility of a transport services 1744 implementation. 1746 The application can set and query Connection Properties on a per- 1747 Connection basis. Connection Properties that are not read-only can 1748 be set during pre-establishment (see Section 4.2), as well as on 1749 connections directly using the SetProperty action: 1751 Connection.SetProperty(property, value) 1753 Note that changing one of the Connection Properties on one Connection 1754 in a Connection Group will also change it for all other Connections 1755 of that group; see further Section 5.4. 1757 At any point, the application can query Connection Properties. 1759 ConnectionProperties := Connection.GetProperties() 1760 value := ConnectionProperties.Get(property) 1761 if ConnectionProperties.Has(boolean_or_preference_property) then ... 1763 Depending on the status of the connection, the queried Connection 1764 Properties will include different information: 1766 * The connection state, which can be one of the following: 1767 Establishing, Established, Closing, or Closed. 1769 * Whether the connection can be used to send data. A connection can 1770 not be used for sending if the connection was created with the 1771 Selection Property "Direction of Communication" set to 1772 "unidirectional receive" or if a Message marked as "Final" was 1773 sent over this connection. See Section 7.1.3.5. 1775 * Whether the connection can be used to receive data. A connection 1776 cannot be used for reading if the connection was created with the 1777 Selection Property "Direction of Communication" set to 1778 "unidirectional send" or if a Message marked as "Final" was 1779 received. See Section 7.3.3.3. The latter is only supported by 1780 certain transport protocols, e.g., by TCP as half-closed 1781 connection. 1783 * For Connections that are Established or Closing: Transport 1784 Properties that the application specified on the Preconnection. 1785 See Section 4.2. Selection properties of type "Preference" will 1786 be exposed as boolean values indicating whether or not the 1787 property applies to the selected transport. 1789 * For Connections that are Established, Closing, or Closed: 1790 Selection (Section 4.2) and Connection Properties (Section 6.1) of 1791 the actual protocols that were selected and instantiated. 1792 Selection Properties indicate whether or not the Connection has or 1793 offers a certain Selection Property. The actually instantiated 1794 protocol stack might not match all Protocol Selection Properties 1795 that the application specified on the Preconnection. For example, 1796 a certain Protocol Selection Property that an application 1797 specified as Preferred might not actually be present in the chosen 1798 protocol stack because none of the currently available transport 1799 protocols had this feature. 1801 * For Connections that are Established, additional properties of the 1802 path(s) in use. These properties can be derived from the local 1803 provisioning domain [RFC7556], measurements by the Protocol Stack, 1804 or other sources. 1806 6.1. Generic Connection Properties 1808 Generic Connection Properties are defined independent of the chosen 1809 protocol stack and therefore available on all Connections. 1811 Many Connection Properties have a corresponding Selection Property 1812 that enables applications to express their preference for protocols 1813 providing a supporting transport feature. 1815 6.1.1. Required Minimum Corruption Protection Coverage for Receiving 1817 Name: recvChecksumLen 1819 Type: Integer, with special value "Full Coverage" 1821 Default: Full Coverage 1823 This property specifies the minimum number of bytes in a received 1824 message that need to be covered by a checksum. A special value of 0 1825 means that no checksum is permitted. A receiving Endpoint will not 1826 forward messages to the application that have less coverage. The 1827 application is responsible for handling any corruption within the 1828 non-protected part of the message [RFC8085]. 1830 6.1.2. Connection Priority 1832 Name: connPrio 1834 Type: Integer 1836 Default: 100 1838 This Property is a non-negative integer representing the relative 1839 inverse priority (i.e., a lower value reflects a higher priority) of 1840 this Connection relative to other Connections in the same Connection 1841 Group. It has no effect on Connections not part of a Connection 1842 Group. As noted in Section 5.4, this property is not entangled when 1843 Connections are cloned, i.e., changing the Priority on one Connection 1844 in a Connection Group does not change it on the other Connections in 1845 the same Connection Group. No guarantees of a specific behavior 1846 regarding Connection Priority are given; a Transport Services system 1847 may ignore this property. See Section 7.2.6 for more details. 1849 6.1.3. Timeout for Aborting Connection 1851 Name: connTimeout 1853 Type: Numeric, with special value "Disabled" 1855 Default: Disabled 1857 This property specifies how long to wait before deciding that an 1858 active Connection has failed when trying to reliably deliver data to 1859 the Remote Endpoint. Adjusting this Property will only take effect 1860 when the underlying stack supports reliability. The special value 1861 "Disabled" means that no timeout is scheduled. 1863 6.1.4. Timeout for keep alive packets 1865 Name: keepAliveTimeout 1867 Type: Numeric, with special value "Disabled" 1869 Default: Implementation-defined 1871 A Transport Services system can request a protocol that supports 1872 sending keep alive packets Section 4.2.10. This property specifies 1873 the maximum length of time an idle connection (one for which no 1874 transport packets have been sent) should wait before the Local 1875 Endpoint sends a keep-alive packet to the Remote Endpoint. Adjusting 1876 this Property will only take effect when the underlying stack 1877 supports sending keep-alive packets. Guidance on setting this value 1878 for datagram transports is provided in [RFC8085]. A value greater 1879 than the connection timeout (Section 6.1.3), or the special value 1880 "Disabled", will disable the sending of keep-alive packets. 1882 6.1.5. Connection Group Transmission Scheduler 1884 Name: connScheduler 1886 Type: Enumeration 1888 Default: Weighted Fair Queueing (see Section 3.6 in [RFC8260]) 1889 This property specifies which scheduler should be used among 1890 Connections within a Connection Group, see Section 5.4. The set of 1891 schedulers can be taken from [RFC8260]. 1893 6.1.6. Capacity Profile 1895 Name: connCapacityProfile 1897 This property specifies the desired network treatment for traffic 1898 sent by the application and the tradeoffs the application is prepared 1899 to make in path and protocol selection to receive that desired 1900 treatment. When the capacity profile is set to a value other than 1901 Default, the Transport Services system SHOULD select paths and 1902 configure protocols to optimize the tradeoff between delay, delay 1903 variation, and efficient use of the available capacity based on the 1904 capacity profile specified. How this is realized is implementation- 1905 specific. The Capacity Profile MAY also be used to set markings on 1906 the wire for Protocol Stacks supporting this. Recommendations for 1907 use with DSCP are provided below for each profile; note that when a 1908 Connection is multiplexed, the guidelines in Section 6 of [RFC7657] 1909 apply. 1911 The following values are valid for the Capacity Profile: 1913 Default: The application provides no information about its expected 1914 capacity profile. Transport Services system implementations that 1915 map the requested capacity profile onto per-connection DSCP 1916 signaling SHOULD assign the DSCP Default Forwarding [RFC2474] Per 1917 Hop Behaviour (PHB). 1919 Scavenger: The application is not interactive. It expects to send 1920 and/or receive data without any urgency. This can, for example, 1921 be used to select protocol stacks with scavenger transmission 1922 control and/or to assign the traffic to a lower-effort service. 1923 Transport Services system implementations that map the requested 1924 capacity profile onto per-connection DSCP signaling SHOULD assign 1925 the DSCP Less than Best Effort [RFC8622] PHB. 1927 Low Latency/Interactive: The application is interactive, and prefers 1928 loss to latency. Response time should be optimized at the expense 1929 of delay variation and efficient use of the available capacity 1930 when sending on this connection. This can be used by the system 1931 to disable the coalescing of multiple small Messages into larger 1932 packets (Nagle's algorithm); to prefer immediate acknowledgment 1933 from the peer endpoint when supported by the underlying transport; 1934 and so on. Transport Services system implementations that map the 1935 requested capacity profile onto per-connection DSCP signaling 1936 without multiplexing SHOULD assign a DSCP Assured Forwarding 1937 (AF41,AF42,AF43,AF44) [RFC2597] PHB. Inelastic traffic that is 1938 expected to conform to the configured network service rate could 1939 be mapped to the DSCP Expedited Forwarding [RFC3246] or [RFC5865] 1940 PHBs. 1942 Low Latency/Non-Interactive: The application prefers loss to 1943 latency, but is not interactive. Response time should be 1944 optimized at the expense of delay variation and efficient use of 1945 the available capacity when sending on this connection. Transport 1946 system implementations that map the requested capacity profile 1947 onto per-connection DSCP signaling without multiplexing SHOULD 1948 assign a DSCP Assured Forwarding (AF21,AF22,AF23,AF24) [RFC2597] 1949 PHB. 1951 Constant-Rate Streaming: The application expects to send/receive 1952 data at a constant rate after Connection establishment. Delay and 1953 delay variation should be minimized at the expense of efficient 1954 use of the available capacity. This implies that the Connection 1955 might fail if the desired rate cannot be maintained across the 1956 Path. A transport can interpret this capacity profile as 1957 preferring a circuit breaker [RFC8084] to a rate-adaptive 1958 congestion controller. Transport system implementations that map 1959 the requested capacity profile onto per-connection DSCP signaling 1960 without multiplexing SHOULD assign a DSCP Assured Forwarding 1961 (AF31,AF32,AF33,AF34) [RFC2597] PHB. 1963 Capacity-Seeking: The application expects to send/receive data at 1964 the maximum rate allowed by its congestion controller over a 1965 relatively long period of time. Transport Services system 1966 implementations that map the requested capacity profile onto per- 1967 connection DSCP signaling without multiplexing SHOULD assign a 1968 DSCP Assured Forwarding (AF11,AF12,AF13,AF14) [RFC2597] PHB per 1969 Section 4.8 of [RFC4594]. 1971 The Capacity Profile for a selected protocol stack may be modified on 1972 a per-Message basis using the Transmission Profile Message Property; 1973 see Section 7.1.3.8. 1975 6.1.7. Policy for using Multipath Transports 1977 Name: multipath-policy 1979 Type: Enumeration 1981 Default: Handover 1982 This property specifies the local policy for transferring data across 1983 multiple paths between the same end hosts if Multipath Transport is 1984 not set to Disabled (see Section 4.2.14). Possible values are: 1986 Handover: The connection ought only to attempt to migrate between 1987 different paths when the original path is lost or becomes 1988 unusable. The thresholds used to declare a path unusable are 1989 implementation specific. 1991 Interactive: The connection ought only to attempt to minimize the 1992 latency for interactive traffic patterns by transmitting data 1993 across multiple paths when this is beneficial. The goal of 1994 minimizing the latency will be balanced against the cost of each 1995 of these paths. Depending on the cost of the lower-latency path, 1996 the scheduling might choose to use a higher-latency path. Traffic 1997 can be scheduled such that data may be transmitted on multiple 1998 paths in parallel to achieve a lower latency. The specific 1999 scheduling algorithm is implementation-specific. 2001 Aggregate: The connection ought to attempt to use multiple paths in 2002 parallel to maximize available capacity and possibly overcome the 2003 capacity limitations of the individual paths. The actual strategy 2004 is implementation specific. 2006 Note that this is a local choice - the Remote Endpoint can choose a 2007 different policy. 2009 6.1.8. Bounds on Send or Receive Rate 2011 Name: minSendRate / minRecvRate / maxSendRate / maxRecvRate 2013 Type: Numeric (with special value "Unlimited") / Numeric (with 2014 special value "Unlimited") / Numeric (with special value 2015 "Unlimited") / Numeric (with special value "Unlimited") 2017 Default: Unlimited / Unlimited / Unlimited / Unlimited 2019 This property specifies an upper-bound rate that a transfer is not 2020 expected to exceed (even if flow control and congestion control allow 2021 higher rates), and/or a lower-bound rate below which the application 2022 does not deem it will be useful. These are specified in bits per 2023 second. The special value "Unlimited" indicates that no bound is 2024 specified. 2026 6.1.9. Group Connection Limit 2028 Name: groupConnLimit 2029 Type: Numeric (with special value "Unlimited") 2031 Default: Unlimited 2033 This property controls the number of Connections that can be accepted 2034 from a peer as new members of the Connection's group. Similar to 2035 SetNewConnectionLimit(), this limits the number of ConnectionReceived 2036 Events that will occur, but constrained to the group of the 2037 Connection associated with this property. For a multi-streaming 2038 transport, this limits the number of allowed streams. 2040 6.1.10. Isolate Session 2042 Name: isolateSession 2044 Type: Boolean 2046 Default: false 2048 When set to true, this property will initiate new Connections using 2049 as little cached information (such as session tickets or cookies) as 2050 possible from previous connections that are not entangled with it. 2051 Any state generated by this Connection will only be shared with 2052 entangled connections. Cloned Connections will use saved state from 2053 within the Connection Group. This is used for separating Connection 2054 Contexts as specified in [I-D.ietf-taps-arch]. 2056 Note that this does not guarantee no leakage of information, as 2057 implementations may not be able to fully isolate all caches (e.g. 2058 RTT estimates). Note that this property may degrade connection 2059 performance. 2061 6.1.11. Read-only Connection Properties 2063 The following generic Connection Properties are read-only, i.e. they 2064 cannot be changed by an application. 2066 6.1.11.1. Maximum Message Size Concurrent with Connection Establishment 2068 Name: zeroRttMsgMaxLen 2070 Type: Integer 2072 This property represents the maximum Message size that can be sent 2073 before or during Connection establishment, see also Section 7.1.3.4. 2074 It is given in Bytes. 2076 6.1.11.2. Maximum Message Size Before Fragmentation or Segmentation 2078 Name: singularTransmissionMsgMaxLen 2080 Type: Integer 2082 This property, if applicable, represents the maximum Message size 2083 that can be sent without incurring network-layer fragmentation or 2084 transport layer segmentation at the sender. It exposes the Maximum 2085 Packet Size (MPS) as described in Datagram PLPMTUD 2086 [I-D.ietf-tsvwg-datagram-plpmtud]. 2088 6.1.11.3. Maximum Message Size on Send 2090 Name: sendMsgMaxLen 2092 Type: Integer 2094 This property represents the maximum Message size that an application 2095 can send. 2097 6.1.11.4. Maximum Message Size on Receive 2099 Name: recvMsgMaxLen 2101 Type: Integer 2103 This numeric property represents the maximum Message size that an 2104 application can receive. 2106 6.2. TCP-specific Properties: User Timeout Option (UTO) 2108 These properties specify configurations for the User Timeout Option 2109 (UTO), in the case that TCP becomes the chosen transport protocol. 2110 Implementation is optional and useful only if TCP is implemented in 2111 the Transport Services system. 2113 These TCP-specific properties are included here because the feature 2114 "Suggest timeout to the peer" is part of the minimal set of transport 2115 services [RFC8923], where this feature was categorized as 2116 "functional". This means that when an implementation offers this 2117 feature, it has to expose an interface to it to the application. 2118 Otherwise, the implementation might violate assumptions by the 2119 application, which could cause the application to fail. 2121 All of the below properties are optional (e.g., it is possible to 2122 specify "User Timeout Enabled" as true, but not specify an Advertised 2123 User Timeout value; in this case, the TCP default will be used). 2124 These properties reflect the API extension specified in Section 3 of 2125 [RFC5482]. 2127 6.2.1. Advertised User Timeout 2129 Name: tcp.userTimeoutValue 2131 Type: Integer 2133 Default: the TCP default 2135 This time value is advertised via the TCP User Timeout Option (UTO) 2136 [RFC5482] at the Remote Endpoint to adapt its own "Timeout for 2137 aborting Connection" (see Section 6.1.3) value. 2139 6.2.2. User Timeout Enabled 2141 Name: tcp.userTimeout 2143 Type: Boolean 2145 Default: false 2147 This property controls whether the UTO option is enabled for a 2148 connection. This applies to both sending and receiving. 2150 6.2.3. Timeout Changeable 2152 Name: tcp.userTimeoutRecv 2154 Type: Boolean 2156 Default: true 2158 This property controls whether the "Timeout for aborting Connection" 2159 (see Section 6.1.3) may be changed based on a UTO option received 2160 from the remote peer. This boolean becomes false when "Timeout for 2161 aborting Connection" (see Section 6.1.3) is used. 2163 6.3. Connection Lifecycle Events 2165 During the lifetime of a connection there are events that can occur 2166 when configured. 2168 6.3.1. Soft Errors 2170 Asynchronous introspection is also possible, via the SoftError Event. 2171 This event informs the application about the receipt and contents of 2172 an ICMP error message related to the Connection. This will only 2173 happen if the underlying protocol stack supports access to soft 2174 errors; however, even if the underlying stack supports it, there is 2175 no guarantee that a soft error will be signaled. 2177 Connection -> SoftError<> 2179 6.3.2. Path change 2181 This event notifies the application when at least one of the paths 2182 underlying a Connection has changed. Changes occur on a single path 2183 when the PMTU changes as well as when multiple paths are used and 2184 paths are added or removed, or a handover has been performed. 2186 Connection -> PathChange<> 2188 7. Data Transfer 2190 Data is sent and received as Messages, which allows the application 2191 to communicate the boundaries of the data being transferred. 2193 7.1. Messages and Framers 2195 Each Message has an optional Message Context, which allows to add 2196 Message Properties, identify Send Events related to a specific 2197 Message or to inspect meta-data related to the Message sent. Framers 2198 can be used to extend or modify the message data with additional 2199 information that can be processed at the receiver to detect message 2200 boundaries. 2202 7.1.1. Message Contexts 2204 Using the MessageContext object, the application can set and retrieve 2205 meta-data of the message, including Message Properties (see 2206 Section 7.1.3) and framing meta-data (see Section 7.1.2.2). 2207 Therefore, a MessageContext object can be passed to the Send action 2208 and is returned by each Send and Receive related event. 2210 Message Properties can be set and queried using the Message Context: 2212 MessageContext.add(scope?, parameter, value) 2213 PropertyValue := MessageContext.get(scope?, property) 2214 To get or set Message Properties, the optional scope parameter is 2215 left empty. To get or set meta-data for a Framer, the application 2216 has to pass a reference to this Framer as the scope parameter. 2218 For MessageContexts returned by send Events (see Section 7.2.2) and 2219 receive Events (see Section 7.3.2), the application can query 2220 information about the local and Remote Endpoint: 2222 RemoteEndpoint := MessageContext.GetRemoteEndpoint() 2223 LocalEndpoint := MessageContext.GetLocalEndpoint() 2225 7.1.2. Message Framers 2227 Although most applications communicate over a network using well- 2228 formed Messages, the boundaries and metadata of the Messages are 2229 often not directly communicated by the transport protocol itself. 2230 For example, HTTP applications send and receive HTTP messages over a 2231 byte-stream transport, requiring that the boundaries of HTTP messages 2232 be parsed from the stream of bytes. 2234 Message Framers allow extending a Connection's Protocol Stack to 2235 define how to encapsulate or encode outbound Messages, and how to 2236 decapsulate or decode inbound data into Messages. Message Framers 2237 allow message boundaries to be preserved when using a Connection 2238 object, even when using byte-stream transports. This is designed 2239 based on the fact that many of the current application protocols 2240 evolved over TCP, which does not provide message boundary 2241 preservation, and since many of these protocols require message 2242 boundaries to function, each application layer protocol has defined 2243 its own framing. 2245 To use a Message Framer, the application adds it to its Preconnection 2246 object. Then, the Message Framer can intercept all calls to Send() 2247 or Receive() on a Connection to add Message semantics, in addition to 2248 interacting with the setup and teardown of the Connection. A Framer 2249 can start sending data before the application sends data if the 2250 framing protocol requires a prefix or handshake (see [RFC8229] for an 2251 example of such a framing protocol). 2253 Initiate() Send() Receive() Close() 2254 | | ^ | 2255 | | | | 2256 +----v----------v---------+----------v-----+ 2257 | Connection | 2258 +----+----------+---------^----------+-----+ 2259 | | | | 2260 | +-----------------+ | 2261 | | Messages | | 2262 | +-----------------+ | 2263 | | | | 2264 +----v----------v---------+----------v-----+ 2265 | Framer(s) | 2266 +----+----------+---------^----------+-----+ 2267 | | | | 2268 | +-----------------+ | 2269 | | Byte-stream | | 2270 | +-----------------+ | 2271 | | | | 2272 +----v----------v---------+----------v-----+ 2273 | Transport Protocol Stack | 2274 +------------------------------------------+ 2276 Figure 1: Protocol Stack showing a Message Framer 2278 Note that while Message Framers add the most value when placed above 2279 a protocol that otherwise does not preserve message boundaries, they 2280 can also be used with datagram- or message-based protocols. In these 2281 cases, they add an additional transformation to further encode or 2282 encapsulate, and can potentially support packing multiple 2283 application-layer Messages into individual transport datagrams. 2285 The API to implement a Message Framer can vary depending on the 2286 implementation; guidance on implementing Message Framers can be found 2287 in [I-D.ietf-taps-impl]. 2289 7.1.2.1. Adding Message Framers to Connections 2291 The Message Framer object can be added to one or more Preconnections 2292 to run on top of transport protocols. Multiple Framers may be added 2293 to a Preconnection; in this case, the Framers operate as a framing 2294 stack, i.e. the last one added runs first when framing outbound 2295 messages, and last when parsing inbound data. 2297 The following example adds a basic HTTP Message Framer to a 2298 Preconnection: 2300 framer := NewHTTPMessageFramer() 2301 Preconnection.AddFramer(framer) 2303 Since Message Framers pass from Preconnection to Listener or 2304 Connection, addition of Framers must happen before any operation that 2305 may result in the creation of a Connection. 2307 7.1.2.2. Framing Meta-Data 2309 When sending Messages, applications can add Framer-specific key/value 2310 pairs to a MessageContext (Section 7.1.1). This mechanism can be 2311 used, for example, to set the type of a Message for a TLV format. 2312 The namespace of values is custom for each unique Message Framer. 2314 messageContext := NewMessageContext() 2315 messageContext.add(framer, key, value) 2316 Connection.Send(messageData, messageContext) 2318 When an application receives a MessageContext in a Receive event, it 2319 can also look to see if a value was set by a specific Message Framer. 2321 messageContext.get(framer, key) -> value 2323 For example, if an HTTP Message Framer is used, the values could 2324 correspond to HTTP headers: 2326 httpFramer := NewHTTPMessageFramer() 2327 ... 2328 messageContext := NewMessageContext() 2329 messageContext.add(httpFramer, "accept", "text/html") 2331 7.1.3. Message Properties 2333 Applications needing to annotate the Messages they send with extra 2334 information (for example, to control how data is scheduled and 2335 processed by the transport protocols supporting the Connection) can 2336 include this information in the Message Context passed to the Send 2337 Action. For other uses of the message context, see Section 7.1.1. 2339 Message Properties are per-Message, not per-Send if partial Messages 2340 are sent (Section 7.2.3). All data blocks associated with a single 2341 Message share properties specified in the Message Contexts. For 2342 example, it would not make sense to have the beginning of a Message 2343 expire, but allow the end of a Message to still be sent. 2345 A MessageContext object contains metadata for the Messages to be sent 2346 or received. 2348 messageData := "hello" 2349 messageContext := NewMessageContext() 2350 messageContext.add(parameter, value) 2351 Connection.Send(messageData, messageContext) 2353 The simpler form of Send, which does not take any messageContext, is 2354 equivalent to passing a default MessageContext without adding any 2355 Message Properties. 2357 If an application wants to override Message Properties for a specific 2358 message, it can acquire an empty MessageContext Object and add all 2359 desired Message Properties to that Object. It can then reuse the 2360 same messageContext Object for sending multiple Messages with the 2361 same properties. 2363 Properties can be added to a MessageContext object only before the 2364 context is used for sending. Once a messageContext has been used 2365 with a Send call, it is invalid to modify any of its properties. 2367 The Message Properties could be inconsistent with the properties of 2368 the Protocol Stacks underlying the Connection on which a given 2369 Message is sent. For example, a Protocol Stack must be able to 2370 provide ordering if the msgOrdered property of a Message is enabled. 2371 Sending a Message with Message Properties inconsistent with the 2372 Selection Properties of the Connection yields an error. 2374 Connection Properties describe the default behavior for all Messages 2375 on a Connection. If a Message Property contradicts a Connection 2376 Property, and if this per-Message behavior can be supported, it 2377 overrides the Connection Property for the specific Message. For 2378 example, if "Reliable Data Transfer (Connection)" is set to "Require" 2379 and a protocol with configurable per-Message reliability is used, 2380 setting "Reliable Data Transfer (Message)" to "false" for a 2381 particular Message will allow this Message to be unreliably 2382 delivered. Changing the Reliable Data Transfer property on Messages 2383 is only possible for Connections that were established enabling the 2384 Selection Property "Configure Per-Message Reliability". 2386 The following Message Properties are supported: 2388 7.1.3.1. Lifetime 2390 Name: msgLifetime 2392 Type: Numeric 2394 Default: infinite 2395 The Lifetime specifies how long a particular Message can wait to be 2396 sent to the Remote Endpoint before it is irrelevant and no longer 2397 needs to be (re-)transmitted. This is a hint to the Transport 2398 Services system - it is not guaranteed that a Message will not be 2399 sent when its Lifetime has expired. 2401 Setting a Message's Lifetime to infinite indicates that the 2402 application does not wish to apply a time constraint on the 2403 transmission of the Message, but it does not express a need for 2404 reliable delivery; reliability is adjustable per Message via the 2405 "Reliable Data Transfer (Message)" property (see Section 7.1.3.7). 2406 The type and units of Lifetime are implementation-specific. 2408 7.1.3.2. Priority 2410 Name: msgPrio 2412 Type: Integer (non-negative) 2414 Default: 100 2416 This property represents a hierarchy of priorities. It can specify 2417 the priority of a Message, relative to other Messages sent over the 2418 same Connection. 2420 A Message with Priority 0 will yield to a Message with Priority 1, 2421 which will yield to a Message with Priority 2, and so on. Priorities 2422 may be used as a sender-side scheduling construct only, or be used to 2423 specify priorities on the wire for Protocol Stacks supporting 2424 prioritization. 2426 Note that this property is not a per-message override of the 2427 connection Priority - see Section 6.1.2. The Priority properties may 2428 interact, but can be used independently and be realized by different 2429 mechanisms; see Section 7.2.6. 2431 7.1.3.3. Ordered 2433 Name: msgOrdered 2435 Type: Boolean 2437 Default: the queried Boolean value of the Selection Property 2438 "reliability" (Section 4.2.1) 2440 The order in which Messages were submitted for transmission via the 2441 Send Action will be preserved on delivery via Receive<> events for 2442 all Messages on a Connection that have this Message Property set to 2443 true. 2445 If false, the Message is delivered to the receiving application 2446 without preserving the ordering. This property is used for protocols 2447 that support preservation of data ordering, see Section 4.2.4, but 2448 allow out-of-order delivery for certain messages, e.g., by 2449 multiplexing independent messages onto different streams. 2451 7.1.3.4. Safely Replayable 2453 Name: safelyReplayable 2455 Type: Boolean 2457 Default: false 2459 If true, Safely Replayable specifies that a Message is safe to send 2460 to the Remote Endpoint more than once for a single Send Action. It 2461 marks the data as safe for certain 0-RTT establishment techniques, 2462 where retransmission of the 0-RTT data may cause the remote 2463 application to receive the Message multiple times. 2465 For protocols that do not protect against duplicated messages, e.g., 2466 UDP, all messages need to be marked as "Safely Replayable". To 2467 enable protocol selection to choose such a protocol, "Safely 2468 Replayable" needs to be added to the TransportProperties passed to 2469 the Preconnection. If such a protocol was chosen, disabling "Safely 2470 Replayable" on individual messages MUST result in a SendError. 2472 7.1.3.5. Final 2474 Name: final 2476 Type: Boolean 2478 Default: false 2480 If true, this indicates a Message is the last that the application 2481 will send on a Connection. This allows underlying protocols to 2482 indicate to the Remote Endpoint that the Connection has been 2483 effectively closed in the sending direction. For example, TCP-based 2484 Connections can send a FIN once a Message marked as Final has been 2485 completely sent, indicated by marking endOfMessage. Protocols that 2486 do not support signalling the end of a Connection in a given 2487 direction will ignore this property. 2489 A Final Message must always be sorted to the end of a list of 2490 Messages. The Final property overrides Priority and any other 2491 property that would re-order Messages. If another Message is sent 2492 after a Message marked as Final has already been sent on a 2493 Connection, the Send Action for the new Message will cause a 2494 SendError Event. 2496 7.1.3.6. Sending Corruption Protection Length 2498 Name: msgChecksumLen 2500 Type: Integer (non-negative with special value "Full Coverage") 2502 Default: Full Coverage 2504 This property specifies the minimum length of the section of a sent 2505 Message, starting from byte 0, that the application requires to be 2506 delivered without corruption due to lower layer errors. It is used 2507 to specify options for simple integrity protection via checksums. A 2508 value of 0 means that no checksum is required, and "Full Coverage" 2509 means that the entire Message needs to be protected by a checksum. 2510 Only "Full Coverage" is guaranteed, any other requests are advisory, 2511 which may result in "Full Coverage" being applied. 2513 7.1.3.7. Reliable Data Transfer (Message) 2515 Name: msgReliable 2517 Type: Boolean 2519 Default: the queried Boolean value of the Selection Property 2520 "reliability" (Section 4.2.1) 2522 When true, this property specifies that a Message should be sent in 2523 such a way that the transport protocol ensures all data is received 2524 on the other side without corruption. Changing the "Reliable Data 2525 Transfer" property on Messages is only possible for Connections that 2526 were established enabling the Selection Property "Configure Per- 2527 Message Reliability". When this is not the case, changing 2528 "msgReliable" will generate an error. 2530 Disabling this property indicates that the Transport Services system 2531 may disable retransmissions or other reliability mechanisms for this 2532 particular Message, but such disabling is not guaranteed. 2534 7.1.3.8. Message Capacity Profile Override 2536 Name: msgCapacityProfile 2538 Type: Enumeration 2540 Default: inherited from the Connection Property 2541 "connCapacityProfile" (Section 6.1.6) 2543 This enumerated property specifies the application's preferred 2544 tradeoffs for sending this Message; it is a per-Message override of 2545 the Capacity Profile connection property (see Section 6.1.6). 2547 7.1.3.9. No Network-Layer Fragmentation 2549 Name: noFragmentation 2551 Type: Boolean 2553 Default: false 2555 This property specifies that a message should be sent and received as 2556 a single packet without network-layer fragmentation, if possible. 2557 This only takes effect when the transport uses a network layer that 2558 supports this functionality. When it does take effect, setting this 2559 property to true will cause the Don't Fragment bit to be set in the 2560 IP header, and attempts to send a message with this property set to a 2561 size greater than the transport's current estimate of its maximum 2562 packet size ("singularTransmissionMsgMaxLen") will result in a 2563 "SendError". 2565 7.1.3.10. No Segmentation 2567 Name: noSegmentation 2569 Type: Boolean 2571 Default: false 2573 When set to true, this property requests the network layer at the 2574 sending endpoint to not fragment the packets generated by the 2575 transport layer. When running over IPv4, setting this property to 2576 true will also cause the Don't Fragment bit to be set in the IP 2577 header. When this property is set, an attempt to send a message size 2578 greater than the transport's current estimate of its maximum packet 2579 size (singularTransmissionMsgMaxLen) will result in a SendError. 2580 This only takes effect when the transport and network layer support 2581 this functionality. 2583 7.2. Sending Data 2585 Once a Connection has been established, it can be used for sending 2586 Messages. By default, Send enqueues a complete Message, and takes 2587 optional per-Message properties (see Section 7.2.1). All Send 2588 actions are asynchronous, and deliver Events (see Section 7.2.2). 2589 Sending partial Messages for streaming large data is also supported 2590 (see Section 7.2.3). 2592 Messages are sent on a Connection using the Send action: 2594 Connection.Send(messageData, messageContext?, endOfMessage?) 2596 where messageData is the data object to send, and messageContext 2597 allows adding Message Properties, identifying Send Events related to 2598 a specific Message or inspecting meta-data related to the Message 2599 sent (see Section 7.1.1). 2601 The optional endOfMessage parameter supports partial sending and is 2602 described in Section 7.2.3. 2604 7.2.1. Basic Sending 2606 The most basic form of sending on a connection involves enqueuing a 2607 single Data block as a complete Message with default Message 2608 Properties. 2610 messageData := "hello" 2611 Connection.Send(messageData) 2613 The interpretation of a Message to be sent is dependent on the 2614 implementation, and on the constraints on the Protocol Stacks implied 2615 by the Connection's transport properties. For example, a Message may 2616 be a single datagram for UDP Connections; or an HTTP Request for HTTP 2617 Connections. 2619 Some transport protocols can deliver arbitrarily sized Messages, but 2620 other protocols constrain the maximum Message size. Applications can 2621 query the Connection Property "Maximum Message size on send" 2622 (Section 6.1.11.3) to determine the maximum size allowed for a single 2623 Message. If a Message is too large to fit in the Maximum Message 2624 Size for the Connection, the Send will fail with a SendError event 2625 (Section 7.2.2.3). For example, it is invalid to send a Message over 2626 a UDP connection that is larger than the available datagram sending 2627 size. 2629 7.2.2. Send Events 2631 Like all Actions in this interface, the Send Action is asynchronous. 2632 There are several Events that can be delivered in response to Sending 2633 a Message. Exactly one Event (Sent, Expired, or SendError) will be 2634 delivered in response to each call to Send. 2636 Note that if partial Sends are used (Section 7.2.3), there will still 2637 be exactly one Send Event delivered for each call to Send. For 2638 example, if a Message expired while two requests to Send data for 2639 that Message are outstanding, there will be two Expired events 2640 delivered. 2642 The interface should allow the application to correlate which Send 2643 Action resulted in a particular Send Event. The manner in which this 2644 correlation is indicated is implementation-specific. 2646 7.2.2.1. Sent 2648 Connection -> Sent 2650 The Sent Event occurs when a previous Send Action has completed, 2651 i.e., when the data derived from the Message has been passed down or 2652 through the underlying Protocol Stack and is no longer the 2653 responsibility of this interface. The exact disposition of the 2654 Message (i.e., whether it has actually been transmitted, moved into a 2655 buffer on the network interface, moved into a kernel buffer, and so 2656 on) when the Sent Event occurs is implementation-specific. The Sent 2657 Event contains a reference to the Message to which it applies. 2659 Sent Events allow an application to obtain an understanding of the 2660 amount of buffering it creates. That is, if an application calls the 2661 Send Action multiple times without waiting for a Sent Event, it has 2662 created more buffer inside the Transport Services system than an 2663 application that always waits for the Sent Event before calling the 2664 next Send Action. 2666 7.2.2.2. Expired 2668 Connection -> Expired 2670 The Expired Event occurs when a previous Send Action expired before 2671 completion; i.e. when the Message was not sent before its Lifetime 2672 (see Section 7.1.3.1) expired. This is separate from SendError, as 2673 it is an expected behavior for partially reliable transports. The 2674 Expired Event contains a reference to the Message to which it 2675 applies. 2677 7.2.2.3. SendError 2679 Connection -> SendError 2681 A SendError occurs when a Message was not sent due to an error 2682 condition: an attempt to send a Message which is too large for the 2683 system and Protocol Stack to handle, some failure of the underlying 2684 Protocol Stack, or a set of Message Properties not consistent with 2685 the Connection's transport properties. The SendError contains a 2686 reference to the Message to which it applies. 2688 7.2.3. Partial Sends 2690 It is not always possible for an application to send all data 2691 associated with a Message in a single Send Action. The Message data 2692 may be too large for the application to hold in memory at one time, 2693 or the length of the Message may be unknown or unbounded. 2695 Partial Message sending is supported by passing an endOfMessage 2696 boolean parameter to the Send Action. This value is always true by 2697 default, and the simpler forms of Send are equivalent to passing true 2698 for endOfMessage. 2700 The following example sends a Message in two separate calls to Send. 2702 messageContext := NewMessageContext() 2703 messageContext.add(parameter, value) 2705 messageData := "hel" 2706 endOfMessage := false 2707 Connection.Send(messageData, messageContext, endOfMessage) 2709 messageData := "lo" 2710 endOfMessage := true 2711 Connection.Send(messageData, messageContext, endOfMessage) 2713 All data sent with the same MessageContext object will be treated as 2714 belonging to the same Message, and will constitute an in-order series 2715 until the endOfMessage is marked. 2717 7.2.4. Batching Sends 2719 To reduce the overhead of sending multiple small Messages on a 2720 Connection, the application could batch several Send Actions 2721 together. This provides a hint to the system that the sending of 2722 these Messages ought to be coalesced when possible, and that sending 2723 any of the batched Messages can be delayed until the last Message in 2724 the batch is enqueued. 2726 The semantics for starting and ending a batch can be implementation- 2727 specific, but need to allow multiple Send Actions to be enqueued. 2729 Connection.StartBatch() 2730 Connection.Send(messageData) 2731 Connection.Send(messageData) 2732 Connection.EndBatch() 2734 7.2.5. Send on Active Open: InitiateWithSend 2736 For application-layer protocols where the Connection initiator also 2737 sends the first message, the InitiateWithSend() action combines 2738 Connection initiation with a first Message sent: 2740 Connection := Preconnection.InitiateWithSend(messageData, messageContext?, timeout?) 2742 Whenever possible, a messageContext should be provided to declare the 2743 Message passed to InitiateWithSend as "Safely Replayable". This 2744 allows the Transport Services system to make use of 0-RTT 2745 establishment in case this is supported by the available protocol 2746 stacks. When the selected stack(s) do not support transmitting data 2747 upon connection establishment, InitiateWithSend is identical to 2748 Initiate() followed by Send(). 2750 Neither partial sends nor send batching are supported by 2751 InitiateWithSend(). 2753 The Events that may be sent after InitiateWithSend() are equivalent 2754 to those that would be sent by an invocation of Initiate() followed 2755 immediately by an invocation of Send(), with the caveat that a send 2756 failure that occurs because the Connection could not be established 2757 will not result in a SendError separate from the InitiateError 2758 signaling the failure of Connection establishment. 2760 7.2.6. Priority in TAPS 2762 The Transport Services interface provides two properties to allow a 2763 sender to signal the relative priority of data transmission: the 2764 Priority Message Property Section 7.1.3.2, and the Connection 2765 Priority Connection Property Section 6.1.2. These properties are 2766 designed to allow the expression and implementation of a wide variety 2767 of approaches to transmission priority in the transport and 2768 application layer, including those which do not appear on the wire 2769 (affecting only sender-side transmission scheduling) as well as those 2770 that do (e.g. [I-D.ietf-httpbis-priority]. 2772 A Transport Services system gives no guarantees about how its 2773 expression of relative priorities will be realized; for example, if a 2774 transport stack that only provides a single in-order reliable stream 2775 is selected, prioritization information can only be ignored. 2776 However, the Transport Services system will seek to ensure that 2777 performance of relatively-prioritized connections and messages is not 2778 worse with respect to those connections and messages than an 2779 equivalent configuration in which all prioritization properties are 2780 left at their defaults. 2782 The Transport Services interface does order Connection Priority over 2783 the Priority Message Property. In the absense of other externalities 2784 (e.g., transport-layer flow control), a priority 1 Message on a 2785 priority 0 Connection will be sent before a priority 0 Message on a 2786 priority 1 Connection in the same group. 2788 7.3. Receiving Data 2790 Once a Connection is established, it can be used for receiving data 2791 (unless the "Direction of Communication" property is set to 2792 "unidirectional send"). As with sending, the data is received in 2793 Messages. Receiving is an asynchronous operation, in which each call 2794 to Receive enqueues a request to receive new data from the 2795 connection. Once data has been received, or an error is encountered, 2796 an event will be delivered to complete any pending Receive requests 2797 (see Section 7.3.2). If Messages arrive at the Transport Services 2798 system before Receive requests are issued, ensuing Receive requests 2799 will first operate on these Messages before awaiting any further 2800 Messages. 2802 7.3.1. Enqueuing Receives 2804 Receive takes two parameters to specify the length of data that an 2805 application is willing to receive, both of which are optional and 2806 have default values if not specified. 2808 Connection.Receive(minIncompleteLength?, maxLength?) 2810 By default, Receive will try to deliver complete Messages in a single 2811 event (Section 7.3.2.1). 2813 The application can set a minIncompleteLength value to indicate the 2814 smallest partial Message data size in bytes that should be delivered 2815 in response to this Receive. By default, this value is infinite, 2816 which means that only complete Messages should be delivered (see 2817 Section 7.3.2.2 and Section 7.1.2 for more information on how this is 2818 accomplished). If this value is set to some smaller value, the 2819 associated receive event will be triggered only when at least that 2820 many bytes are available, or the Message is complete with fewer 2821 bytes, or the system needs to free up memory. Applications should 2822 always check the length of the data delivered to the receive event 2823 and not assume it will be as long as minIncompleteLength in the case 2824 of shorter complete Messages or memory issues. 2826 The maxLength argument indicates the maximum size of a Message in 2827 bytes that the application is currently prepared to receive. The 2828 default value for maxLength is infinite. If an incoming Message is 2829 larger than the minimum of this size and the maximum Message size on 2830 receive for the Connection's Protocol Stack, it will be delivered via 2831 ReceivedPartial events (Section 7.3.2.2). 2833 Note that maxLength does not guarantee that the application will 2834 receive that many bytes if they are available; the interface could 2835 return ReceivedPartial events with less data than maxLength according 2836 to implementation constraints. Note also that maxLength and 2837 minIncompleteLength are intended only to manage buffering, and are 2838 not interpreted as a receiver preference for message reordering. 2840 7.3.2. Receive Events 2842 Each call to Receive will be paired with a single Receive Event, 2843 which can be a success or an error. This allows an application to 2844 provide backpressure to the transport stack when it is temporarily 2845 not ready to receive messages. 2847 The interface should allow the application to correlate which call to 2848 Receive resulted in a particular Receive Event. The manner in which 2849 this correlation is indicated is implementation-specific. 2851 7.3.2.1. Received 2853 Connection -> Received 2855 A Received event indicates the delivery of a complete Message. It 2856 contains two objects, the received bytes as messageData, and the 2857 metadata and properties of the received Message as messageContext. 2859 The messageData object provides access to the bytes that were 2860 received for this Message, along with the length of the byte array. 2861 The messageContext is provided to enable retrieving metadata about 2862 the message and referring to the message, e.g., to send replies and 2863 map responses to their requests. See Section 7.1.1 for details. 2865 See Section 7.1.2 for handling Message framing in situations where 2866 the Protocol Stack only provides a byte-stream transport. 2868 7.3.2.2. ReceivedPartial 2870 Connection -> ReceivedPartial 2872 If a complete Message cannot be delivered in one event, one part of 2873 the Message can be delivered with a ReceivedPartial event. To 2874 continue to receive more of the same Message, the application must 2875 invoke Receive again. 2877 Multiple invocations of ReceivedPartial deliver data for the same 2878 Message by passing the same MessageContext, until the endOfMessage 2879 flag is delivered or a ReceiveError occurs. All partial blocks of a 2880 single Message are delivered in order without gaps. This event does 2881 not support delivering discontiguous partial Messages. If, for 2882 example, Message A is divided into three pieces (A1, A2, A3) and 2883 Message B is divided into three pieces (B1, B2, B3), the 2884 ReceivedPartial may deliver them in a sequence like this: A1, B1, B2, 2885 A2, A3, B3, because the messageContext allows the application to 2886 identify the pieces as belonging to Message A and B, respectively. 2887 However, a sequence like: A1, A3 will never occur. 2889 If the minIncompleteLength in the Receive request was set to be 2890 infinite (indicating a request to receive only complete Messages), 2891 the ReceivedPartial event may still be delivered if one of the 2892 following conditions is true: 2894 * the underlying Protocol Stack supports message boundary 2895 preservation, and the size of the Message is larger than the 2896 buffers available for a single message; 2898 * the underlying Protocol Stack does not support message boundary 2899 preservation, and the Message Framer (see Section 7.1.2) cannot 2900 determine the end of the message using the buffer space it has 2901 available; or 2903 * the underlying Protocol Stack does not support message boundary 2904 preservation, and no Message Framer was supplied by the 2905 application 2907 Note that in the absence of message boundary preservation or a 2908 Message Framer, all bytes received on the Connection will be 2909 represented as one large Message of indeterminate length. 2911 7.3.2.3. ReceiveError 2913 Connection -> ReceiveError 2914 A ReceiveError occurs when data is received by the underlying 2915 Protocol Stack that cannot be fully retrieved or parsed, or when some 2916 other indication is received that reception has failed. In contrast, 2917 conditions that irrevocably lead to the termination of the Connection 2918 are instead signaled using ConnectionError (see Section 8). 2920 The ReceiveError event passes an optional associated MessageContext. 2921 This can indicate that a Message that was being partially received 2922 previously, but had not completed, encountered an error and will not 2923 be completed. 2925 7.3.3. Receive Message Properties 2927 Each Message Context may contain metadata from protocols in the 2928 Protocol Stack; which metadata is available is Protocol Stack 2929 dependent. These are exposed though additional read-only Message 2930 Properties that can be queried from the MessageContext object (see 2931 Section 7.1.1) passed by the receive event. The following metadata 2932 values are supported: 2934 7.3.3.1. UDP(-Lite)-specific Property: ECN 2936 When available, Message metadata carries the value of the Explicit 2937 Congestion Notification (ECN) field. This information can be used 2938 for logging and debugging, and for building applications that need 2939 access to information about the transport internals for their own 2940 operation. This property is specific to UDP and UDP-Lite because 2941 these protocols do not implement congestion control, and hence expose 2942 this functionality to the application. 2944 7.3.3.2. Early Data 2946 In some cases it can be valuable to know whether data was read as 2947 part of early data transfer (before connection establishment has 2948 finished). This is useful if applications need to treat early data 2949 separately, e.g., if early data has different security properties 2950 than data sent after connection establishment. In the case of TLS 2951 1.3, client early data can be replayed maliciously (see [RFC8446]). 2952 Thus, receivers might wish to perform additional checks for early 2953 data to ensure it is safely replayable. If TLS 1.3 is available and 2954 the recipient Message was sent as part of early data, the 2955 corresponding metadata carries a flag indicating as such. If early 2956 data is enabled, applications should check this metadata field for 2957 Messages received during connection establishment and respond 2958 accordingly. 2960 7.3.3.3. Receiving Final Messages 2962 The Message Context can indicate whether or not this Message is the 2963 Final Message on a Connection. For any Message that is marked as 2964 Final, the application can assume that there will be no more Messages 2965 received on the Connection once the Message has been completely 2966 delivered. This corresponds to the Final property that may be marked 2967 on a sent Message, see Section 7.1.3.5. 2969 Some transport protocols and peers do not support signaling of the 2970 Final property. Applications therefore should not rely on receiving 2971 a Message marked Final to know that the sending endpoint is done 2972 sending on a connection. 2974 Any calls to Receive once the Final Message has been delivered will 2975 result in errors. 2977 8. Connection Termination 2979 Close terminates a Connection after satisfying all the requirements 2980 that were specified regarding the delivery of Messages that the 2981 application has already given to the Transport Services system. For 2982 example, if reliable delivery was requested for a Message handed over 2983 before calling Close, the Closed Event will signify that this Message 2984 has indeed been delivered. This action does not affect any other 2985 Connection that is entangled with this one in a Connection Group. 2987 Connection.Close() 2989 The Closed Event informs the application that the Remote Endpoint has 2990 closed the Connection. There is no guarantee that a remote Close 2991 will indeed be signaled. 2993 Connection -> Closed<> 2995 Abort terminates a Connection without delivering any remaining 2996 Messages. This action does not affect any other Connection that is 2997 entangled with this one in a Connection Group. 2999 Connection.Abort() 3001 CloseGroup gracefully terminates a Connection and any other 3002 Connections that are entangled with this one in a Connection Group. 3003 For example, all of the Connections in a group might be streams of a 3004 single session for a multistreaming protocol; closing the entire 3005 group will close the underlying session. See also Section 5.4. As 3006 with Close, any Messages remaining to be processed on a Connection 3007 will be handled prior to closing. 3009 Connection.CloseGroup() 3011 AbortGroup terminates a Connection and any other Connections that are 3012 entangled with this one in a Connection Group without delivering any 3013 remaining Messages. 3015 Connection.AbortGroup() 3017 A ConnectionError informs the application that: 1) data could not be 3018 delivered to the peer after a timeout, or 2) the Connection has been 3019 aborted (e.g., because the peer has called Abort). There is no 3020 guarantee that an Abort will indeed be signaled. 3022 Connection -> ConnectionError 3024 9. Connection State and Ordering of Operations and Events 3026 This interface is designed to be independent of an implementation's 3027 concurrency model. The details of how exactly actions are handled, 3028 and how events are dispatched, are implementation dependent. 3030 Each transition of connection state is associated with one of more 3031 events: 3033 * Ready<> occurs when a Connection created with Initiate() or 3034 InitiateWithSend() transitions to Established state. 3036 * ConnectionReceived<> occurs when a Connection created with 3037 Listen() transitions to Established state. 3039 * RendezvousDone<> occurs when a Connection created with 3040 Rendezvous() transitions to Established state. 3042 * Closed<> occurs when a Connection transitions to Closed state 3043 without error. 3045 * InitiateError<> occurs when a Connection created with Initiate() 3046 transitions from Establishing state to Closed state due to an 3047 error. 3049 * ConnectionError<> occurs when a Connection transitions to Closed 3050 state due to an error in all other circumstances. 3052 The following diagram shows the possible states of a Connection and 3053 the events that occur upon a transition from one state to another. 3055 (*) (**) 3056 Establishing -----> Established -----> Closing ------> Closed 3057 | ^ 3058 | | 3059 +---------------------------------------------------+ 3060 InitiateError<> 3062 (*) Ready<>, ConnectionReceived<>, RendezvousDone<> 3063 (**) Closed<>, ConnectionError<> 3065 Figure 2: Connection State Diagram 3067 The interface provides the following guarantees about the ordering of 3068 operations: 3070 * Sent<> events will occur on a Connection in the order in which the 3071 Messages were sent (i.e., delivered to the kernel or to the 3072 network interface, depending on implementation). 3074 * Received<> will never occur on a Connection before it is 3075 Established; i.e. before a Ready<> event on that Connection, or a 3076 ConnectionReceived<> or RendezvousDone<> containing that 3077 Connection. 3079 * No events will occur on a Connection after it is Closed; i.e., 3080 after a Closed<> event, an InitiateError<> or ConnectionError<> 3081 will not occur on that connection. To ensure this ordering, 3082 Closed<> will not occur on a Connection while other events on the 3083 Connection are still locally outstanding (i.e., known to the 3084 interface and waiting to be dealt with by the application). 3086 10. IANA Considerations 3088 RFC-EDITOR: Please remove this section before publication. 3090 This document has no Actions for IANA. Later versions of this 3091 document may create IANA registries for generic transport property 3092 names and transport property namespaces (see Section 3.2.1). 3094 11. Privacy and Security Considerations 3096 This document describes a generic API for interacting with a 3097 transport services (TAPS) system. Part of this API includes 3098 configuration details for transport security protocols, as discussed 3099 in Section 4.3. It does not recommend use (or disuse) of specific 3100 algorithms or protocols. Any API-compatible transport security 3101 protocol ought to work in a TAPS system. Security considerations for 3102 these protocols are discussed in the respective specifications. 3104 The described API is used to exchange information between an 3105 application and the Transport Services system. While it is not 3106 necessarily expected that both systems are implemented by the same 3107 authority, it is expected that the Transport Services system 3108 implementation is either provided as a library that is selected by 3109 the application from a trusted party, or that it is part of the 3110 operating system that the application also relies on for other tasks. 3112 In either case, the Transport Services API is an internal interface 3113 that is used to change information locally between two systems. 3114 However, as the Transport Services system is responsible for network 3115 communication, it is in the position to potentially share any 3116 information provided by the application with the network or another 3117 communication peer. Most of the information provided over the 3118 Transport Services API are useful to configure and select protocols 3119 and paths and are not necessarily privacy sensitive. Still, some 3120 information could be privacy sensitive because it might reveal usage 3121 characteristics and habits of the user of an application. 3123 Of course any communication over a network reveals usage 3124 characteristics, as all packets, as well as their timing and size, 3125 are part of the network-visible wire image [RFC8546]. However, the 3126 selection of a protocol and its configuration also impacts which 3127 information is visible, potentially in clear text, and which other 3128 entities can access it. In most cases, information provided for 3129 protocol and path selection should not directly translate to 3130 information that can be observed by network devices on the path. 3131 However, there might be specific configuration information that is 3132 intended for path exposure, e.g., a DiffServ codepoint setting, that 3133 is either provided directly by the application or indirectly 3134 configured for a traffic profile. 3136 Applications should be aware that communication attempts can lead to 3137 more than one connection establishment. This is the case, for 3138 example, when the Transport Services system also executes name 3139 resolution, when support mechanisms such as TURN or ICE are used to 3140 establish connectivity, if protocols or paths are raised, or if a 3141 path fails and fallback or re-establishment is supported in the 3142 Transport Services system. 3144 Applications should also take care to not assume that all data 3145 received using the Transport Services API is always complete or well- 3146 formed. Specifically, messages that are received partially 3147 Section 7.3.2.2 could be a source of truncation attacks if 3148 applications do not distinguish between partial messages and complete 3149 messages. 3151 The interface explicitly does not require the application to resolve 3152 names, though there is a tradeoff between early and late binding of 3153 addresses to names. Early binding allows the API implementation to 3154 reduce connection setup latency, at the cost of potentially limited 3155 scope for alternate path discovery during Connection establishment, 3156 as well as potential additional information leakage about application 3157 interest when used with a resolution method (such as DNS without TLS) 3158 which does not protect query confidentiality. 3160 These communication activities are not different from what is used 3161 today. However, the goal of a Transport Services system is to 3162 support such mechanisms as a generic service within the transport 3163 layer. This enables applications to more dynamically benefit from 3164 innovations and new protocols in the transport, although it reduces 3165 transparency of the underlying communication actions to the 3166 application itself. The TAPS API is designed such that protocol and 3167 path selection can be limited to a small and controlled set if 3168 required by the application for functional or security purposes. 3169 Further, TAPS implementations should provide an interface to poll 3170 information about which protocol and path is currently in use as well 3171 as provide logging about the communication events of each connection. 3173 12. Acknowledgements 3175 This work has received funding from the European Union's Horizon 2020 3176 research and innovation programme under grant agreements No. 644334 3177 (NEAT) and No. 688421 (MAMI). 3179 This work has been supported by Leibniz Prize project funds of DFG - 3180 German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ 3181 FE 570/4-1). 3183 This work has been supported by the UK Engineering and Physical 3184 Sciences Research Council under grant EP/R04144X/1. 3186 This work has been supported by the Research Council of Norway under 3187 its "Toppforsk" programme through the "OCARINA" project. 3189 Thanks to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric 3190 Kinnear for their implementation and design efforts, including Happy 3191 Eyeballs, that heavily influenced this work. Thanks to Laurent Chuat 3192 and Jason Lee for initial work on the Post Sockets interface, from 3193 which this work has evolved. Thanks to Maximilian Franke for asking 3194 good questions based on implementation experience and for 3195 contributing text, e.g., on multicast. 3197 13. References 3198 13.1. Normative References 3200 [I-D.ietf-taps-arch] 3201 Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., 3202 Perkins, C., Tiesel, P., and C. Wood, "An Architecture for 3203 Transport Services", Work in Progress, Internet-Draft, 3204 draft-ietf-taps-arch-09, 2 November 2020, 3205 . 3208 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3209 Requirement Levels", BCP 14, RFC 2119, 3210 DOI 10.17487/RFC2119, March 1997, 3211 . 3213 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 3214 RFC 2914, DOI 10.17487/RFC2914, September 2000, 3215 . 3217 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 3218 Extensions for Stateless Address Autoconfiguration in 3219 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 3220 . 3222 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", 3223 BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, 3224 . 3226 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 3227 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 3228 March 2017, . 3230 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3231 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3232 May 2017, . 3234 [RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of 3235 Transport Features Provided by IETF Transport Protocols", 3236 RFC 8303, DOI 10.17487/RFC8303, February 2018, 3237 . 3239 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3240 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3241 . 3243 13.2. Informative References 3245 [I-D.ietf-httpbis-priority] 3246 Oku, K. and L. Pardue, "Extensible Prioritization Scheme 3247 for HTTP", Work in Progress, Internet-Draft, draft-ietf- 3248 httpbis-priority-03, 11 January 2021, 3249 . 3252 [I-D.ietf-taps-impl] 3253 Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K., 3254 Jones, T., Tiesel, P., Perkins, C., and M. Welzl, 3255 "Implementing Interfaces to Transport Services", Work in 3256 Progress, Internet-Draft, draft-ietf-taps-impl-08, 2 3257 November 2020, . 3260 [I-D.ietf-tsvwg-datagram-plpmtud] 3261 Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and 3262 T. Voelker, "Packetization Layer Path MTU Discovery for 3263 Datagram Transports", Work in Progress, Internet-Draft, 3264 draft-ietf-tsvwg-datagram-plpmtud-22, 10 June 2020, 3265 . 3268 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 3269 "Definition of the Differentiated Services Field (DS 3270 Field) in the IPv4 and IPv6 Headers", RFC 2474, 3271 DOI 10.17487/RFC2474, December 1998, 3272 . 3274 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 3275 "Assured Forwarding PHB Group", RFC 2597, 3276 DOI 10.17487/RFC2597, June 1999, 3277 . 3279 [RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le 3280 Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D. 3281 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 3282 Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, 3283 . 3285 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3286 A., Peterson, J., Sparks, R., Handley, M., and E. 3287 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3288 DOI 10.17487/RFC3261, June 2002, 3289 . 3291 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 3292 Guidelines for DiffServ Service Classes", RFC 4594, 3293 DOI 10.17487/RFC4594, August 2006, 3294 . 3296 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 3297 (ICE): A Protocol for Network Address Translator (NAT) 3298 Traversal for Offer/Answer Protocols", RFC 5245, 3299 DOI 10.17487/RFC5245, April 2010, 3300 . 3302 [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", 3303 RFC 5482, DOI 10.17487/RFC5482, March 2009, 3304 . 3306 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 3307 Relays around NAT (TURN): Relay Extensions to Session 3308 Traversal Utilities for NAT (STUN)", RFC 5766, 3309 DOI 10.17487/RFC5766, April 2010, 3310 . 3312 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 3313 Services Code Point (DSCP) for Capacity-Admitted Traffic", 3314 RFC 5865, DOI 10.17487/RFC5865, May 2010, 3315 . 3317 [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 3318 Time Communication Use Cases and Requirements", RFC 7478, 3319 DOI 10.17487/RFC7478, March 2015, 3320 . 3322 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 3323 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 3324 . 3326 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 3327 (Diffserv) and Real-Time Communication", RFC 7657, 3328 DOI 10.17487/RFC7657, November 2015, 3329 . 3331 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 3332 Ed., "Services Provided by IETF Transport Protocols and 3333 Congestion Control Mechanisms", RFC 8095, 3334 DOI 10.17487/RFC8095, March 2017, 3335 . 3337 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 3338 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 3339 August 2017, . 3341 [RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 3342 "Stream Schedulers and User Message Interleaving for the 3343 Stream Control Transmission Protocol", RFC 8260, 3344 DOI 10.17487/RFC8260, November 2017, 3345 . 3347 [RFC8489] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, 3348 D., Mahy, R., and P. Matthews, "Session Traversal 3349 Utilities for NAT (STUN)", RFC 8489, DOI 10.17487/RFC8489, 3350 February 2020, . 3352 [RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a 3353 Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April 3354 2019, . 3356 [RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for 3357 Differentiated Services", RFC 8622, DOI 10.17487/RFC8622, 3358 June 2019, . 3360 [RFC8699] Islam, S., Welzl, M., and S. Gjessing, "Coupled Congestion 3361 Control for RTP Media", RFC 8699, DOI 10.17487/RFC8699, 3362 January 2020, . 3364 [RFC8922] Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C. 3365 Wood, "A Survey of the Interaction between Security 3366 Protocols and Transport Services", RFC 8922, 3367 DOI 10.17487/RFC8922, October 2020, 3368 . 3370 [RFC8923] Welzl, M. and S. Gjessing, "A Minimal Set of Transport 3371 Services for End Systems", RFC 8923, DOI 10.17487/RFC8923, 3372 October 2020, . 3374 [TCP-COUPLING] 3375 Islam, S., Welzl, M., Hiorth, K., Hayes, D., Armitage, G., 3376 and S. Gjessing, "ctrlTCP: Reducing Latency through 3377 Coupled, Heterogeneous Multi-Flow TCP Congestion Control", 3378 IEEE INFOCOM Global Internet Symposium (GI) workshop (GI 3379 2018) , 2018. 3381 Appendix A. Implementation Mapping 3383 The way the concepts from this abstract interface map into concrete 3384 APIs in a given language on a given platform largely depends on the 3385 features and norms of the language and the platform. Actions could 3386 be implemented as functions or method calls, for instance, and Events 3387 could be implemented via event queues, handler functions or classes, 3388 communicating sequential processes, or other asynchronous calling 3389 conventions. 3391 A.1. Types 3393 The basic types mentioned in Section 1.1 typically have natural 3394 correspondences in practical programming languages, perhaps 3395 constrained by implementation-specific limitations. For example: 3397 * An Integer can typically be represented in C by an "int" or 3398 "long", subject to the underlying platform's ranges for each. To 3399 accommodate special values, a C function that returns a non- 3400 negative "int" on success may return -1 on failure. In Python, 3401 such a function might return "None" or raise an exception. 3403 * In C, a Tuple may be represented as a "struct" with one member for 3404 each of the value types in the ordered grouping. In Python, by 3405 contrast, a Tuple may be represented natively as a "tuple", a 3406 sequence of dynamically-typed elements. 3408 * A Collection may be represented as a "std::set" in C++ or as a 3409 "set" in Python. In C, it may be represented as an array or as a 3410 higher-level data structure with appropriate accessors defined. 3412 A.2. Events and Errors 3414 This specification treats Events and Errors similarly. Errors, just 3415 as any other Events, may occur asynchronously in network 3416 applications. However, implementations of this interface may report 3417 Errors synchronously, according to the error handling idioms of the 3418 implementation platform, where they can be immediately detected, such 3419 as by throwing an exception when attempting to initiate a connection 3420 with inconsistent Transport Properties. An error can provide an 3421 optional reason to the application with further details about why the 3422 error occurred. 3424 A.3. Time Duration 3426 Time duration types are implementation-specific. For instance, it 3427 could be a number of seconds, number of milliseconds, or a "struct 3428 timeval" in C or a user-defined "Duration" class in C++. 3430 Appendix B. Convenience Functions 3432 B.1. Adding Preference Properties 3434 As Selection Properties of type "Preference" will be set on a 3435 TransportProperties object quite frequently, implementations should 3436 provide special actions for adding each preference level i.e, 3437 "TransportProperties.Set(some_property, avoid)" is equivalent to 3438 "TransportProperties.Avoid(some_property)": 3440 TransportProperties.Require(property) 3441 TransportProperties.Prefer(property) 3442 TransportProperties.Ignore(property) 3443 TransportProperties.Avoid(property) 3444 TransportProperties.Prohibit(property) 3446 B.2. Transport Property Profiles 3448 To ease the use of the interface specified by this document, 3449 implementations should provide a mechanism to create Transport 3450 Property objects (see Section 4.2) that are pre-configured with 3451 frequently used sets of properties. Implementations should at least 3452 offer short-hands to specify the following property profiles: 3454 B.2.1. reliable-inorder-stream 3456 This profile provides reliable, in-order transport service with 3457 congestion control. TCP is an example of a protocol that provides 3458 this service. It should consist of the following properties: 3460 +=======================+=========+ 3461 | Property | Value | 3462 +=======================+=========+ 3463 | reliability | require | 3464 +-----------------------+---------+ 3465 | preserveOrder | require | 3466 +-----------------------+---------+ 3467 | congestionControl | require | 3468 +-----------------------+---------+ 3469 | preserveMsgBoundaries | ignore | 3470 +-----------------------+---------+ 3472 Table 2 3474 B.2.2. reliable-message 3476 This profile provides message-preserving, reliable, in-order 3477 transport service with congestion control. SCTP is an example of a 3478 protocol that provides this service. It should consist of the 3479 following properties: 3481 +=======================+=========+ 3482 | Property | Value | 3483 +=======================+=========+ 3484 | reliability | require | 3485 +-----------------------+---------+ 3486 | preserveOrder | require | 3487 +-----------------------+---------+ 3488 | congestionControl | require | 3489 +-----------------------+---------+ 3490 | preserveMsgBoundaries | require | 3491 +-----------------------+---------+ 3493 Table 3 3495 B.2.3. unreliable-datagram 3497 This profile provides unreliable datagram transport service. An 3498 example of a protocol that provides this service is UDP. It consists 3499 of the following properties: 3501 +=======================+=========+ 3502 | Property | Value | 3503 +=======================+=========+ 3504 | reliability | ignore | 3505 +-----------------------+---------+ 3506 | preserveOrder | ignore | 3507 +-----------------------+---------+ 3508 | congestionControl | ignore | 3509 +-----------------------+---------+ 3510 | preserveMsgBoundaries | require | 3511 +-----------------------+---------+ 3512 | safely replayable | true | 3513 +-----------------------+---------+ 3515 Table 4 3517 Applications that choose this Transport Property Profile for latency 3518 reasons should also consider setting an appropriate Capacity Profile 3519 Property, see Section 6.1.6 and could benefit from controlling 3520 checksum coverage, see Section 4.2.7 and Section 4.2.8. 3522 Appendix C. Relationship to the Minimal Set of Transport Services for 3523 End Systems 3525 [RFC8923] identifies a minimal set of transport services that end 3526 systems should offer. These services make all non-security-related 3527 transport features of TCP, MPTCP, UDP, UDP-Lite, SCTP and LEDBAT 3528 available that 1) require interaction with the application, and 2) do 3529 not get in the way of a possible implementation over TCP (or, with 3530 limitations, UDP). The following text explains how this minimal set 3531 is reflected in the present API. For brevity, it is based on the 3532 list in Section 4.1 of [RFC8923], updated according to the discussion 3533 in Section 5 of [RFC8923]. The present API covers all elements of 3534 this section except "Notification of Excessive Retransmissions (early 3535 warning below abortion threshold)". This list is a subset of the 3536 transport features in Appendix A of [RFC8923], which refers to the 3537 primitives in "pass 2" (Section 4) of [RFC8303] for further details 3538 on the implementation with TCP, MPTCP, UDP, UDP-Lite, SCTP and 3539 LEDBAT. 3541 * Connect: "Initiate" Action (Section 5.1). 3543 * Listen: "Listen" Action (Section 5.2). 3545 * Specify number of attempts and/or timeout for the first 3546 establishment message: "timeout" parameter of "Initiate" 3547 (Section 5.1) or "InitiateWithSend" Action (Section 7.2.5). 3549 * Disable MPTCP: "Multipath Transport" Property (Section 4.2.14). 3551 * Hand over a message to reliably transfer (possibly multiple times) 3552 before connection establishment: "InitiateWithSend" Action 3553 (Section 7.2.5). 3555 * Change timeout for aborting connection (using retransmit limit or 3556 time value): "Timeout for Aborting Connection" property, using a 3557 time value (Section 6.1.3). 3559 * Timeout event when data could not be delivered for too long: 3560 "ConnectionError" Event (Section 8). 3562 * Suggest timeout to the peer: "TCP-specific Properties: User 3563 Timeout Option (UTO)" (Section 6.2). 3565 * Notification of ICMP error message arrival: "Notification of ICMP 3566 soft error message arrival" property (Section 4.2.17). 3568 * Choose a scheduler to operate between streams of an association: 3569 "Connection Group Transmission Scheduler" property 3570 (Section 6.1.5). 3572 * Configure priority or weight for a scheduler: "Connection 3573 Priority" property (Section 6.1.2). 3575 * "Specify checksum coverage used by the sender" and "Disable 3576 checksum when sending": "Sending Corruption Protection Length" 3577 property (Section 7.1.3.6) and "Full Checksum Coverage on Sending" 3578 property (Section 4.2.7). 3580 * "Specify minimum checksum coverage required by receiver" and 3581 "Disable checksum requirement when receiving": "Required Minimum 3582 Corruption Protection Coverage for Receiving" property 3583 (Section 6.1.1) and "Full Checksum Coverage on Receiving" property 3584 (Section 4.2.8). 3586 * "Specify DF field": "No Network-Layer Fragmentation" property 3587 (Section 7.1.3.9). 3589 * "Request not to bundle messages": "No Segmentation" property 3590 (Section 7.1.3.10). 3592 * Get max. transport-message size that may be sent using a non- 3593 fragmented IP packet from the configured interface: "Maximum 3594 Message Size Before Fragmentation or Segmentation" property 3595 (Section 6.1.11.2). 3597 * Get max. transport-message size that may be received from the 3598 configured interface: "Maximum Message Size on Receive" property 3599 (Section 6.1.11.4). 3601 * Obtain ECN field: "UDP(-Lite)-specific Property: ECN" is a read- 3602 only Message Property of the MessageContext object 3603 (Section 7.3.3.1). 3605 * "Specify DSCP field", "Disable Nagle algorithm", "Enable and 3606 configure a "Low Extra Delay Background Transfer"": as suggested 3607 in Section 5.5 of [RFC8923], these transport features are 3608 collectively offered via the "Capacity Profile" property 3609 (Section 6.1.6). Per-Message control is offered via the "Message 3610 Capacity Profile Override" property (Section 7.1.3.8). 3612 * Close after reliably delivering all remaining data, causing an 3613 event informing the application on the other side: this is offered 3614 by the "Close" Action with slightly changed semantics in line with 3615 the discussion in Section 5.2 of [RFC8923] (Section 8). 3617 * "Abort without delivering remaining data, causing an event 3618 informing the application on the other side" and "Abort without 3619 delivering remaining data, not causing an event informing the 3620 application on the other side": this is offered by the "Abort" 3621 action without promising that this is signaled to the other side. 3622 If it is, a "ConnectionError" Event will fire at the peer 3623 (Section 8). 3625 * "Reliably transfer data, with congestion control", "Reliably 3626 transfer a message, with congestion control" and "Unreliably 3627 transfer a message": data is transferred via the "Send" action 3628 (Section 7.2). Reliability is controlled via the "Reliable Data 3629 Transfer (Connection)" (Section 4.2.1) property and the "Reliable 3630 Data Transfer (Message)" Message Property (Section 7.1.3.7). 3631 Transmitting data as a message or without delimiters is controlled 3632 via Message Framers (Section 7.1.2). The choice of congestion 3633 control is provided via the "Congestion control" property 3634 (Section 4.2.9). 3636 * Configurable Message Reliability: the "Lifetime" Message Property 3637 implements a time-based way to configure message reliability 3638 (Section 7.1.3.1). 3640 * "Ordered message delivery (potentially slower than unordered)" and 3641 "Unordered message delivery (potentially faster than ordered)": 3642 these two transport features are controlled via the Message 3643 Property "Ordered" (Section 7.1.3.3). 3645 * Request not to delay the acknowledgement (SACK) of a message: 3646 should the protocol support it, this is one of the transport 3647 features the Transport Services system can apply when an 3648 application uses the "Capacity Profile" Property (Section 6.1.6) 3649 or the "Message Capacity Profile Override" Message Property 3650 (Section 7.1.3.8) with value "Low Latency/Interactive". 3652 * Receive data (with no message delimiting): "Received" Event 3653 (Section 7.3.2.1). See Section 7.1.2 for handling Message framing 3654 in situations where the Protocol Stack only provides a byte-stream 3655 transport. 3657 * Receive a message: "Received" Event (Section 7.3.2.1), using 3658 Message Framers (Section 7.1.2). 3660 * Information about partial message arrival: "ReceivedPartial" Event 3661 (Section 7.3.2.2). 3663 * Notification of send failures: "Expired" Event (Section 7.2.2.2) 3664 and "SendError" Event (Section 7.2.2.3). 3666 * Notification that the stack has no more user data to send: 3667 applications can obtain this information via the "Sent" Event 3668 (Section 7.2.2.1). 3670 * Notification to a receiver that a partial message delivery has 3671 been aborted: "ReceiveError" Event (Section 7.3.2.3). 3673 Authors' Addresses 3675 Brian Trammell (editor) 3676 Google Switzerland GmbH 3677 Gustav-Gull-Platz 1 3678 CH- 8004 Zurich 3679 Switzerland 3681 Email: ietf@trammell.ch 3683 Michael Welzl (editor) 3684 University of Oslo 3685 PO Box 1080 Blindern 3686 0316 Oslo 3687 Norway 3689 Email: michawe@ifi.uio.no 3691 Theresa Enghardt 3692 Netflix 3693 121 Albright Way 3694 Los Gatos, CA 95032, 3695 United States of America 3697 Email: ietf@tenghardt.net 3699 Godred Fairhurst 3700 University of Aberdeen 3701 Fraser Noble Building 3702 Aberdeen, AB24 3UE 3704 Email: gorry@erg.abdn.ac.uk 3705 URI: http://www.erg.abdn.ac.uk/ 3707 Mirja Kuehlewind 3708 Ericsson 3709 Ericsson-Allee 1 3710 Herzogenrath 3711 Germany 3713 Email: mirja.kuehlewind@ericsson.com 3715 Colin Perkins 3716 University of Glasgow 3717 School of Computing Science 3718 Glasgow G12 8QQ 3719 United Kingdom 3721 Email: csp@csperkins.org 3723 Philipp S. Tiesel 3724 SAP SE 3725 Konrad-Zuse-Ring 10 3726 14469 Potsdam 3727 Germany 3729 Email: philipp@tiesel.net 3731 Christopher A. Wood 3732 Cloudflare 3733 101 Townsend St 3734 San Francisco, 3735 United States of America 3737 Email: caw@heapingbits.net 3739 Tommy Pauly 3740 Apple Inc. 3741 One Apple Park Way 3742 Cupertino, California 95014, 3743 United States of America 3745 Email: tpauly@apple.com 3747 Kyle Rose 3748 Akamai Technologies, Inc. 3749 145 Broadway 3750 Cambridge, MA, 3751 United States of America 3752 Email: krose@krose.org