idnits 2.17.1 draft-ietf-taps-interface-02.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 11 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 (October 22, 2018) is 2012 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) == Unused Reference: 'I-D.ietf-tsvwg-rtcweb-qos' is defined on line 1978, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-taps-arch-01 ** Downref: Normative reference to an Informational draft: draft-ietf-taps-minset (ref. 'I-D.ietf-taps-minset') == Outdated reference: A later version (-12) exists of draft-ietf-taps-transport-security-02 == Outdated reference: A later version (-10) exists of draft-ietf-tsvwg-le-phb-06 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 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 ETH Zurich 4 Intended status: Standards Track M. Welzl, Ed. 5 Expires: April 25, 2019 University of Oslo 6 T. Enghardt 7 TU Berlin 8 G. Fairhurst 9 University of Aberdeen 10 M. Kuehlewind 11 ETH Zurich 12 C. Perkins 13 University of Glasgow 14 P. Tiesel 15 TU Berlin 16 C. Wood 17 Apple Inc. 18 October 22, 2018 20 An Abstract Application Layer Interface to Transport Services 21 draft-ietf-taps-interface-02 23 Abstract 25 This document describes an abstract programming interface to the 26 transport layer, following the Transport Services Architecture. It 27 supports the asynchronous, atomic transmission of messages over 28 transport protocols and network paths dynamically selected at 29 runtime. It is intended to replace the traditional BSD sockets API 30 as the lowest common denominator interface to the transport layer, in 31 an environment where endpoints have multiple interfaces and potential 32 transport protocols to select from. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 25, 2019. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 5 69 3. Interface Design Principles . . . . . . . . . . . . . . . . . 6 70 4. API Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.1. Transport Properties . . . . . . . . . . . . . . . . . . 7 72 4.2. Scope of the Interface Definition . . . . . . . . . . . . 8 73 5. Pre-Establishment Phase . . . . . . . . . . . . . . . . . . . 9 74 5.1. Specifying Endpoints . . . . . . . . . . . . . . . . . . 9 75 5.2. Specifying Transport Properties . . . . . . . . . . . . . 11 76 5.2.1. Reliable Data Transfer (Connection) . . . . . . . . . 13 77 5.2.2. Configure per-Message reliability . . . . . . . . . . 13 78 5.2.3. Preservation of data ordering . . . . . . . . . . . . 13 79 5.2.4. Use 0-RTT session establishment with an idempotent 80 Message . . . . . . . . . . . . . . . . . . . . . . . 13 81 5.2.5. Multistream Connections in Group . . . . . . . . . . 13 82 5.2.6. Control checksum coverage on sending or receiving . . 13 83 5.2.7. Congestion control . . . . . . . . . . . . . . . . . 14 84 5.2.8. Interface Instance or Type . . . . . . . . . . . . . 14 85 5.2.9. Provisioning Domain Instance or Type . . . . . . . . 15 86 5.3. Specifying Security Parameters and Callbacks . . . . . . 15 87 5.3.1. Pre-Connection Parameters . . . . . . . . . . . . . . 16 88 5.3.2. Connection Establishment Callbacks . . . . . . . . . 17 89 6. Establishing Connections . . . . . . . . . . . . . . . . . . 17 90 6.1. Active Open: Initiate . . . . . . . . . . . . . . . . . . 17 91 6.2. Passive Open: Listen . . . . . . . . . . . . . . . . . . 18 92 6.3. Peer-to-Peer Establishment: Rendezvous . . . . . . . . . 19 93 6.4. Connection Groups . . . . . . . . . . . . . . . . . . . . 21 94 7. Sending Data . . . . . . . . . . . . . . . . . . . . . . . . 22 95 7.1. Basic Sending . . . . . . . . . . . . . . . . . . . . . . 22 96 7.2. Send Events . . . . . . . . . . . . . . . . . . . . . . . 22 97 7.2.1. Sent . . . . . . . . . . . . . . . . . . . . . . . . 23 98 7.2.2. Expired . . . . . . . . . . . . . . . . . . . . . . . 23 99 7.2.3. SendError . . . . . . . . . . . . . . . . . . . . . . 23 100 7.3. Message Properties . . . . . . . . . . . . . . . . . . . 24 101 7.3.1. Lifetime . . . . . . . . . . . . . . . . . . . . . . 24 102 7.3.2. Niceness . . . . . . . . . . . . . . . . . . . . . . 25 103 7.3.3. Ordered . . . . . . . . . . . . . . . . . . . . . . . 25 104 7.3.4. Idempotent . . . . . . . . . . . . . . . . . . . . . 25 105 7.3.5. Final . . . . . . . . . . . . . . . . . . . . . . . . 25 106 7.3.6. Corruption Protection Length . . . . . . . . . . . . 26 107 7.3.7. Reliable Data Transfer (Message) . . . . . . . . . . 26 108 7.3.8. Transmission Profile . . . . . . . . . . . . . . . . 26 109 7.3.9. Singular Transmission . . . . . . . . . . . . . . . . 27 110 7.4. Partial Sends . . . . . . . . . . . . . . . . . . . . . . 27 111 7.5. Batching Sends . . . . . . . . . . . . . . . . . . . . . 28 112 7.6. Send on Active Open: InitiateWithIdempotentSend . . . . . 28 113 7.7. Sender-side Framing . . . . . . . . . . . . . . . . . . . 29 114 8. Receiving Data . . . . . . . . . . . . . . . . . . . . . . . 29 115 8.1. Enqueuing Receives . . . . . . . . . . . . . . . . . . . 30 116 8.2. Receive Events . . . . . . . . . . . . . . . . . . . . . 30 117 8.2.1. Received . . . . . . . . . . . . . . . . . . . . . . 30 118 8.2.2. ReceivedPartial . . . . . . . . . . . . . . . . . . . 31 119 8.2.3. ReceiveError . . . . . . . . . . . . . . . . . . . . 32 120 8.3. Message Receive Context . . . . . . . . . . . . . . . . . 32 121 8.3.1. ECN . . . . . . . . . . . . . . . . . . . . . . . . . 32 122 8.3.2. Early Data . . . . . . . . . . . . . . . . . . . . . 32 123 8.3.3. Receiving Final Messages . . . . . . . . . . . . . . 33 124 8.4. Receiver-side De-framing over Stream Protocols . . . . . 33 125 9. Managing Connections . . . . . . . . . . . . . . . . . . . . 34 126 9.1. Generic Connection Properties . . . . . . . . . . . . . . 35 127 9.1.1. Notification of excessive retransmissions . . . . . . 35 128 9.1.2. Retransmission threshold before excessive 129 retransmission notification . . . . . . . . . . . . . 36 130 9.1.3. Notification of ICMP soft error message arrival . . . 36 131 9.1.4. Required minimum coverage of the checksum for 132 receiving . . . . . . . . . . . . . . . . . . . . . . 36 133 9.1.5. Niceness (Connection) . . . . . . . . . . . . . . . . 36 134 9.1.6. Timeout for aborting Connection . . . . . . . . . . . 37 135 9.1.7. Connection group transmission scheduler . . . . . . . 37 136 9.1.8. Maximum message size concurrent with Connection 137 establishment . . . . . . . . . . . . . . . . . . . . 37 138 9.1.9. Maximum Message size before fragmentation or 139 segmentation . . . . . . . . . . . . . . . . . . . . 37 140 9.1.10. Maximum Message size on send . . . . . . . . . . . . 37 141 9.1.11. Maximum Message size on receive . . . . . . . . . . . 37 142 9.1.12. Capacity Profile . . . . . . . . . . . . . . . . . . 38 143 9.2. Soft Errors . . . . . . . . . . . . . . . . . . . . . . . 39 145 10. Connection Termination . . . . . . . . . . . . . . . . . . . 39 146 11. Connection State and Ordering of Operations and Events . . . 40 147 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 148 13. Security Considerations . . . . . . . . . . . . . . . . . . . 41 149 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 150 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 151 15.1. Normative References . . . . . . . . . . . . . . . . . . 42 152 15.2. Informative References . . . . . . . . . . . . . . . . . 43 153 Appendix A. Additional Properties . . . . . . . . . . . . . . . 44 154 A.1. Experimental Transport Properties . . . . . . . . . . . . 45 155 A.1.1. Direction of communication . . . . . . . . . . . . . 45 156 A.1.2. Suggest a timeout to the Remote Endpoint . . . . . . 45 157 A.1.3. Abort timeout to suggest to the Remote Endpoint . . . 46 158 A.1.4. Traffic Category . . . . . . . . . . . . . . . . . . 46 159 A.1.5. Size to be Sent or Received . . . . . . . . . . . . . 46 160 A.1.6. Duration . . . . . . . . . . . . . . . . . . . . . . 47 161 A.1.7. Send or Receive Bit-rate . . . . . . . . . . . . . . 47 162 A.1.8. Cost Preferences . . . . . . . . . . . . . . . . . . 47 163 Appendix B. Sample API definition in Go . . . . . . . . . . . . 48 164 Appendix C. Relationship to the Minimal Set of Transport 165 Services for End Systems . . . . . . . . . . . . . . 48 166 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 168 1. Introduction 170 The BSD Unix Sockets API's SOCK_STREAM abstraction, by bringing 171 network sockets into the UNIX programming model, allowing anyone who 172 knew how to write programs that dealt with sequential-access files to 173 also write network applications, was a revolution in simplicity. The 174 simplicity of this API is a key reason the Internet won the protocol 175 wars of the 1980s. SOCK_STREAM is tied to the Transmission Control 176 Protocol (TCP), specified in 1981 [RFC0793]. TCP has scaled 177 remarkably well over the past three and a half decades, but its total 178 ubiquity has hidden an uncomfortable fact: the network is not really 179 a file, and stream abstractions are too simplistic for many modern 180 application programming models. 182 In the meantime, the nature of Internet access, and the variety of 183 Internet transport protocols, is evolving. The challenges that new 184 protocols and access paradigms present to the sockets API and to 185 programming models based on them inspire the design principles of a 186 new approach, which we outline in Section 3. 188 As a first step to realizing this design, [I-D.ietf-taps-arch] 189 describes a high-level architecture for transport services. This 190 document builds a modern abstract programming interface atop this 191 architecture, deriving specific path and protocol selection 192 properties and supported transport features from the analysis 193 provided in [RFC8095], [I-D.ietf-taps-minset], and 194 [I-D.ietf-taps-transport-security]. 196 2. Terminology and Notation 198 This API is described in terms of Objects, which an application can 199 interact with; Actions the application can perform on these Objects; 200 Events, which an Object can send to an application asynchronously; 201 and Parameters associated with these Actions and Events. 203 The following notations, which can be combined, are used in this 204 document: 206 o An Action creates an Object: 208 Object := Action() 210 o An Action creates an array of Objects: 212 []Object := Action() 214 o An Action is performed on an Object: 216 Object.Action() 218 o An Object sends an Event: 220 Object -> Event<> 222 o An Action takes a set of Parameters; an Event contains a set of 223 Parameters: 225 Action(parameter, parameter, ...) / Event 227 Actions associated with no Object are Actions on the abstract 228 interface itself; they are equivalent to Actions on a per-application 229 global context. 231 How these abstract concepts map into concrete implementations of this 232 API in a given language on a given platform is largely dependent on 233 the features of the language and the platform. Actions could be 234 implemented as functions or method calls, for instance, and Events 235 could be implemented via callbacks, communicating sequential 236 processes, or other asynchronous calling conventions. The method for 237 dispatching and handling Events is left as an implementation detail, 238 with the caveat that the interface for receiving Messages must 239 require the application to invoke the Connection.Receive() Action 240 once per Message to be received (see Section 8). 242 This specification treats Events and errors similarly. Errors, just 243 as any other Events, may occur asynchronously in network 244 applications. However, it is recommended that implementations of 245 this interface also return errors immediately, according to the error 246 handling idioms of the implementation platform, for errors which can 247 be immediately detected, such as inconsistency in Transport 248 Properties. 250 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 251 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 252 "OPTIONAL" in this document are to be interpreted as described in BCP 253 14 [RFC2119] [RFC8174] when, and only when, they appear in all 254 capitals, as shown here. 256 3. Interface Design Principles 258 The design of the interface specified in this document is based on a 259 set of princples, themselves an elaboration on the architectural 260 design principles defined in [I-D.ietf-taps-arch]. The interface 261 defined in this document provides: 263 o A single interface to a variety of transport protocols to be used 264 in a variety of application design patterns, independent of the 265 properties of the application and the Protocol Stacks that will be 266 used at runtime, such that all common specialized features of 267 these protocol stacks are made available to the application as 268 necessary in a transport-independent way, to enable applications 269 written to a single API to make use of transport protocols in 270 terms of the features they provide; 272 o Message- as opposed to stream-orientation, using application- 273 assisted framing and deframing where the underlying transport does 274 not provide these; 276 o Asynchronous Connection establishment, transmission, and 277 reception, allowing concurrent operations during establishment and 278 supporting event-driven application interactions with the 279 transport layer, in line with developments in modern platforms and 280 programming languages; 282 o Explicit support for security properties as first-order transport 283 features, and for long-term caching of cryptographic identities 284 and parameters for associations among endpoints; and 286 o Explicit support for multistreaming and multipath transport 287 protocols, and the grouping of related Connections into Connection 288 Groups through cloning of Connections, to allow applications to 289 take full advantage of new transport protocols supporting these 290 features. 292 4. API Summary 294 The Transport Services Interface is the basic common abstract 295 application programming interface to the Transport Services 296 Architecture defined in [I-D.ietf-taps-arch]. 298 An application primarily interacts with this interface through two 299 Objects, Preconnections and Connections. A Preconnection represents 300 a set of properties and constraints on the selection and 301 configuration of paths and protocols to establish a Connection with a 302 remote endpoint. A Connection represents a transport Protocol Stack 303 on which data can be sent to and/or received from a remote endpoint 304 (i.e., depending on the kind of transport, connections can be bi- 305 directional or unidirectional). Connections can be created from 306 Preconnections in three ways: by initiating the Preconnection (i.e., 307 actively opening, as in a client), through listening on the 308 Preconnection (i.e., passively opening, as in a server), or 309 rendezvousing on the Preconnection (i.e. peer to peer 310 establishment). 312 Once a Connection is established, data can be sent on it in the form 313 of Messages. The interface supports the preservation of message 314 boundaries both via explicit Protocol Stack support, and via 315 application support through a deframing callback which finds message 316 boundaries in a stream. Messages are received asynchronously through 317 a callback registered by the application. Errors and other 318 notifications also happen asynchronously on the Connection. 320 Section 5, Section 6, Section 7, Section 8, and Section 10 describe 321 the details of application interaction with Objects through Actions 322 and Events in each phase of a Connection, following the phases 323 described in [I-D.ietf-taps-arch]. 325 4.1. Transport Properties 327 Each application using the Transport Services Interface declares its 328 preferences for how the transport service should operate using 329 properties at each stage of the lifetime of a connection. During 330 pre-establishment, Selection Properties Section 5.2 are used to 331 specify which paths and protocol stacks can be used and are preferred 332 by the application, and Connection Properties Section 9.1 can be used 333 to fine-tune the eventually established connection. These Connection 334 Properties can also be used to monitor and fine-tune established 335 connections. The behavior of the selected protocol stack(s) when 336 sending Messages is controlled by Message Properties Section 7.3. 338 Collectively, Selection, Connection, and Message Properties can be 339 referred to as Transport Properties. All Transport Properties, 340 regardless of the phase in which they are used, are organized within 341 a single namespace. This enables setting them as defaults in earlier 342 stages and querying them in later stages: - Connection Properties can 343 be set on Preconnections - Message Properties can be set on 344 Preconnections and Connections - The effect of Selection Properties 345 can be queried on Connections and Messages 347 Transport Properties can have one of a set of data types: 349 o Boolean: can take the values "true" and "false"; representation is 350 implementation-dependent. 352 o Integer: can take positive or negative numeric values; range and 353 representation is implementation-dependent. 355 o Enumeration: can take one value of a finite set of values, 356 dependent on the property itself. The representation is 357 implementation dependent; however, implementations MUST provide a 358 method for the application to determine the entire set of possible 359 values for each property. 361 o Preference: can take one of five values (Prohibit, Avoid, Ignore, 362 Prefer, Require) for the level of preference of a given property 363 during protocol selection; see Section 5.2. 365 4.2. Scope of the Interface Definition 367 This document defines a language- and platform-independent interface 368 to a Transport Services system. Given the wide variety of languages 369 and language conventions used to write applications that use the 370 transport layer to connect to other applications over the Internet, 371 this independence makes this interface necessarily abstract. While 372 there is no interoperability benefit to tightly defining how the 373 interface be presented to application programmers in diverse 374 platforms, maintaining the "shape" of the abstract interface across 375 these platforms reduces the effort for programmers who learn the 376 transport services interface to apply their knowledge in multiple 377 platforms. We therefore make the following recommendations: 379 o Actions, Events, and Errors in implementations of this interface 380 SHOULD carry the names given for them in the document, subject to 381 capitalization and punctuation conventions in the language of the 382 implementation, unless the implementation itself uses different 383 names for substantially equivalent objects for networking by 384 convention. 386 o Implementations of this interface SHOULD implement each Selection 387 Property, Connection Property, and Message Context Property 388 specified in this document, exclusive of appendices, even if said 389 implementation is a non-operation, e.g. because transport 390 protocols implementing a given Property are not available on the 391 platform. 393 5. Pre-Establishment Phase 395 The pre-establishment phase allows applications to specify properties 396 for the Connections they are about to make, or to query the API about 397 potential connections they could make. 399 A Preconnection Object represents a potential Connection. It has 400 state that describes properties of a Connection that might exist in 401 the future. This state comprises Local Endpoint and Remote Endpoint 402 Objects that denote the endpoints of the potential Connection (see 403 Section 5.1), the Selection Properties (see Section 5.2), any 404 preconfigured Connection Properties (Section 9.1), and the security 405 parameters (see Section 5.3): 407 Preconnection := NewPreconnection(LocalEndpoint, 408 RemoteEndpoint, 409 TransportProperties, 410 SecurityParams) 412 The Local Endpoint MUST be specified if the Preconnection is used to 413 Listen() for incoming Connections, but is OPTIONAL if it is used to 414 Initiate() connections. The Remote Endpoint MUST be specified if the 415 Preconnection is used to Initiate() Connections, but is OPTIONAL if 416 it is used to Listen() for incoming Connections. The Local Endpoint 417 and the Remote Endpoint MUST both be specified if a peer-to-peer 418 Rendezvous is to occur based on the Preconnection. 420 Framers (see Section 7.7) and deframers (see Section 8.4), if 421 necessary, should be bound to the Preconnection during pre- 422 establishment. 424 5.1. Specifying Endpoints 426 The transport services API uses the Local Endpoint and Remote 427 Endpoint types to refer to the endpoints of a transport connection. 428 Subtypes of these represent various different types of endpoint 429 identifiers, such as IP addresses, DNS names, and interface names, as 430 well as port numbers and service names. 432 RemoteSpecifier := NewRemoteEndpoint() 433 RemoteSpecifier.WithHostname("example.com") 434 RemoteSpecifier.WithService("https") 436 RemoteSpecifier := NewRemoteEndpoint() 437 RemoteSpecifier.WithIPv6Address(2001:db8:4920:e29d:a420:7461:7073:0a) 438 RemoteSpecifier.WithPort(443) 440 RemoteSpecifier := NewRemoteEndpoint() 441 RemoteSpecifier.WithIPv4Address(192.0.2.21) 442 RemoteSpecifier.WithPort(443) 444 LocalSpecifier := NewLocalEndpoint() 445 LocalSpecifier.WithInterface("en0") 446 LocalSpecifier.WithPort(443) 448 LocalSpecifier := NewLocalEndpoint() 449 LocalSpecifier.WithStunServer(address, port, credentials) 451 Implementations may also support additional endpoint representations 452 and provide a single NewEndpoint() call that takes different endpoint 453 representations. 455 Multiple endpoint identifiers can be specified for each Local 456 Endpoint and Remote Endpoint. For example, a Local Endpoint could be 457 configured with two interface names, or a Remote Endpoint could be 458 specified via both IPv4 and IPv6 addresses. These multiple 459 identifiers refer to the same transport endpoint. 461 The transport services API resolves names internally, when the 462 Initiate(), Listen(), or Rendezvous() method is called establish a 463 Connection. The API explicitly does not require the application to 464 resolve names, though there is a tradeoff between early and late 465 binding of addresses to names. Early binding allows the API 466 implementation to reduce connection setup latency, at the cost of 467 potentially limited scope for alternate path discovery during 468 Connection establishment, as well as potential additional information 469 leakage about application interest when used with a resolution method 470 (such as DNS without TLS) which does not protect query 471 confidentiality. 473 The Resolve() action on Preconnection can be used by the application 474 to force early binding when required, for example with some Network 475 Address Translator (NAT) traversal protocols (see Section 6.3). 477 5.2. Specifying Transport Properties 479 A Preconnection Object holds properties reflecting the application's 480 requirements and preferences for the transport. These include 481 Selection Properties for selecting protocol stacks and paths, as well 482 as Connection Properties for configuration of the detailed operation 483 of the selected Protocol Stacks. 485 The protocol(s) and path(s) selected as candidates during 486 establishment are determined and configured using these properties. 487 Since there could be paths over which some transport protocols are 488 unable to operate, or remote endpoints that support only specific 489 network addresses or transports, transport protocol selection is 490 necessarily tied to path selection. This may involve choosing 491 between multiple local interfaces that are connected to different 492 access networks. 494 Selection properties are represented as preferences, which can have 495 one of five preference levels: 497 +------------+------------------------------------------------------+ 498 | Preference | Effect | 499 +------------+------------------------------------------------------+ 500 | Require | Select only protocols/paths providing the property, | 501 | | fail otherwise | 502 | | | 503 | Prefer | Prefer protocols/paths providing the property, | 504 | | proceed otherwise | 505 | | | 506 | Ignore | Cancel any system default preference for this | 507 | | property | 508 | | | 509 | Avoid | Prefer protocols/paths not providing the property, | 510 | | proceed otherwise | 511 | | | 512 | Prohibit | Select only protocols/paths not providing the | 513 | | property, fail otherwise | 514 +------------+------------------------------------------------------+ 516 Internally, the transport system will first exclude all protocols and 517 paths that match a Prohibit, then exclude all protocols and paths 518 that do not match a Require, then sort candidates according to 519 Preferred properties, and then use Avoided properties as a 520 tiebreaker. Selection Properties which select paths take preference 521 over those which select protocols. For example, if an application 522 indicates a preference for a specific path by specifying an 523 interface, but also a preference for a protocol not available on this 524 path, the transport system will try the path first, ignoring the 525 preference. 527 Both Selection and Connection Properties can be added to a 528 Preconnection to configure the selection process, and to further 529 configure the eventually selected protocol stack(s). They are 530 collected into a TransportProperties object to be passed into a 531 Preconnection object: 533 TransportProperties := NewTransportProperties() 535 Individual properties are then added to the TransportProperties 536 Object: 538 TransportProperties.Add(property, value) 540 Selection Properties can be added to a TransportProperties object 541 using special actions for each preference level i.e, 542 "TransportProperties.Add(some_property, avoid)" is equivalent to 543 "TransportProperties.Avoid(some_property)": 545 TransportProperties.Require(property) 546 TransportProperties.Prefer(property) 547 TransportProperties.Ignore(property) 548 TransportProperties.Avoid(property) 549 TransportProperties.Prohibit(property) 551 For an existing Connection, the Transport Properties can be queried 552 any time by using the following call on the Connection Object: 554 TransportProperties := Connection.GetTransportProperties() 556 A Connection gets its Transport Properties either by being explicitly 557 configured via a Preconnection, by configuration after establishment, 558 or by inheriting them from an antecedent via cloning; see Section 6.4 559 for more. 561 Section 9.1 provides a list of Connection Properties, while Selection 562 Properties are listed in the subsections below. Note that many 563 properties are only considered during establishment, and can not be 564 changed after a Connection is established; however, they can be 565 queried. Querying a Selection Property after establishment yields 566 the value Required for properties of the selected protocol and path, 567 Avoid for properties avoided during selection, and Ignore for all 568 other properties. 570 An implementation of this interface must provide sensible defaults 571 for Selection Properties. The recommended defaults given for each 572 property below represent a configuration that can be implemented over 573 TCP. An alternate set of default Protocol Selection Properties would 574 represent a configuration that can be implemented over UDP. 576 5.2.1. Reliable Data Transfer (Connection) 578 This property specifies whether the application needs to use a 579 transport protocol that ensures that all data is received on the 580 other side without corruption. This also entails being notified when 581 a Connection is closed or aborted. The recommended default is to 582 enable Reliable Data Transfer. 584 5.2.2. Configure per-Message reliability 586 This property specifies whether an application considers it useful to 587 indicate its reliability requirements on a per-Message basis. This 588 property applies to Connections and Connection Groups. The 589 recommended default is to not have this option. 591 5.2.3. Preservation of data ordering 593 This property specifies whether the application wishes to use a 594 transport protocol that can ensure that data is received by the 595 application on the other end in the same order as it was sent. The 596 recommended default is to preserve data ordering. 598 5.2.4. Use 0-RTT session establishment with an idempotent Message 600 This property specifies whether an application would like to supply a 601 Message to the transport protocol before Connection establishment, 602 which will then be reliably transferred to the other side before or 603 during Connection establishment, potentially multiple times. See 604 also Section 7.3.4. The recommended default is to not have this 605 option. 607 5.2.5. Multistream Connections in Group 609 This property specifies that the application would prefer multiple 610 Connections within a Connection Group to be provided by streams of a 611 single underlying transport connection where possible. The 612 recommended default is to not have this option. 614 5.2.6. Control checksum coverage on sending or receiving 616 This property specifies whether the application considers it useful 617 to enable, disable, or configure a checksum when sending a Message, 618 or configure whether to require a checksum or not when receiving. 620 The recommended default is full checksum coverage without the option 621 to configure it, and requiring a checksum when receiving. 623 5.2.7. Congestion control 625 This property specifies whether the application would like the 626 Connection to be congestion controlled or not. Note that if a 627 Connection is not congestion controlled, an application using such a 628 Connection should itself perform congestion control in accordance 629 with [RFC2914]. Also note that reliability is usually combined with 630 congestion control in protocol implementations, rendering "reliable 631 but not congestion controlled" a request that is unlikely to succeed. 632 The recommended default is that the Connection is congestion 633 controlled. 635 5.2.8. Interface Instance or Type 637 This property allows the application to select which specific network 638 interfaces or categories of interfaces it wants to "Require", 639 "Prohibit", "Prefer", or "Avoid". 641 In contrast to other Selection Properties, this property is tuple of 642 an (Enumerated) interface identifier and a preference, and can either 643 be implemented directly as such, or for making one preference 644 available for each interface and interface type available on the 645 system. 647 Note that marking a specific interface as "Required" strictly limits 648 path selection to a single interface, and leads to less flexible and 649 resilient connection establishment. 651 The set of valid interface types is implementation- and system- 652 specific. For example, on a mobile device, there may be "Wi-Fi" and 653 "Cellular" interface types available; whereas on a desktop computer, 654 there may be "Wi-Fi" and "Wired Ethernet" interface types available. 655 Implementations should provide all types that are supported on some 656 system to all systems, in order to allow applications to write 657 generic code. For example, if a single implementation is used on 658 both mobile devices and desktop devices, it should define the 659 "Cellular" interface type for both systems, since an application may 660 want to always "Prohibit Cellular". Note that marking a specific 661 interface type as "Required" limits path selection to a small set of 662 interfaces, and leads to less flexible and resilient connection 663 establishment. 665 The set of interface types is expected to change over time as new 666 access technologies become available. 668 Interface types should not be treated as a proxy for properties of 669 interfaces such as metered or unmetered network access. If an 670 application needs to prohibit metered interfaces, this should be 671 specified via Provisioning Domain attributes (see Section 5.2.9) or 672 another specific property. 674 5.2.9. Provisioning Domain Instance or Type 676 Similar to interface instances and types (see Section 5.2.8), this 677 property allows the application to control path selection by 678 selecting which specific Provisioning Domains or categories of 679 Provisioning Domains it wants to "Require", "Prohibit", "Prefer", or 680 "Avoid". Provisioning Domains define consistent sets of network 681 properties that may be more specific than network interfaces 682 [RFC7556]. 684 As with interface instances and types, this property is tuple of an 685 (Enumerated) PvD identifier and a preference, and can either be 686 implemented directly as such, or for making one preference available 687 for each interface and interface type available on the system. 689 The identification of a specific Provisioning Domain (PvD) is defined 690 to be implementation- and system-specific, since there is not a 691 portable standard format for a PvD identitfier. For example, this 692 identifier may be a string name or an integer. As with requiring 693 specific interfaces, requiring a specific PvD strictly limits path 694 selection. 696 Categories or types of PvDs are also defined to be implementation- 697 and system-specific. These may be useful to identify a service that 698 is provided by a PvD. For example, if an application wants to use a 699 PvD that provides a Voice-Over-IP service on a Cellular network, it 700 can use the relevant PvD type to require some PvD that provides this 701 service, without needing to look up a particular instance. While 702 this does restrict path selection, it is broader than requiring 703 specific PvD instances or interface instances, and should be 704 preferred over these options. 706 5.3. Specifying Security Parameters and Callbacks 708 Most security parameters, e.g., TLS ciphersuites, local identity and 709 private key, etc., may be configured statically. Others are 710 dynamically configured during connection establishment. Thus, we 711 partition security parameters and callbacks based on their place in 712 the lifetime of connection establishment. Similar to Transport 713 Properties, both parameters and callbacks are inherited during 714 cloning (see Section 6.4). 716 5.3.1. Pre-Connection Parameters 718 Common parameters such as TLS ciphersuites are known to 719 implementations. Clients should use common safe defaults for these 720 values whenever possible. However, as discussed in 721 [I-D.ietf-taps-transport-security], many transport security protocols 722 require specific security parameters and constraints from the client 723 at the time of configuration and actively during a handshake. These 724 configuration parameters are created as follows: 726 SecurityParameters := NewSecurityParameters() 728 Security configuration parameters and sample usage follow: 730 o Local identity and private keys: Used to perform private key 731 operations and prove one's identity to the Remote Endpoint. 732 (Note, if private keys are not available, e.g., since they are 733 stored in hardware security modules (HSMs), handshake callbacks 734 must be used. See below for details.) 736 SecurityParameters.AddIdentity(identity) 737 SecurityParameters.AddPrivateKey(privateKey, publicKey) 739 o Supported algorithms: Used to restrict what parameters are used by 740 underlying transport security protocols. When not specified, 741 these algorithms should default to known and safe defaults for the 742 system. Parameters include: ciphersuites, supported groups, and 743 signature algorithms. 745 SecurityParameters.AddSupportedGroup(secp256k1) 746 SecurityParameters.AddCiphersuite(TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256) 747 SecurityParameters.AddSignatureAlgorithm(ed25519) 749 o Session cache management: Used to tune cache capacity, lifetime, 750 re-use, and eviction policies, e.g., LRU or FIFO. Constants and 751 policies for these interfaces are implementation-specific. 753 SecurityParameters.SetSessionCacheCapacity(MAX_CACHE_ELEMENTS) 754 SecurityParameters.SetSessionCacheLifetime(SECONDS_PER_DAY) 755 SecurityParameters.SetSessionCachePolicy(CachePolicyOneTimeUse) 757 o Pre-Shared Key import: Used to install pre-shared keying material 758 established out-of-band. Each pre-shared keying material is 759 associated with some identity that typically identifies its use or 760 has some protocol-specific meaning to the Remote Endpoint. 762 SecurityParameters.AddPreSharedKey(key, identity) 764 5.3.2. Connection Establishment Callbacks 766 Security decisions, especially pertaining to trust, are not static. 767 Once configured, parameters may also be supplied during connection 768 establishment. These are best handled as client-provided callbacks. 769 Security handshake callbacks that may be invoked during connection 770 establishment include: 772 o Trust verification callback: Invoked when a Remote Endpoint's 773 trust must be validated before the handshake protocol can proceed. 775 TrustCallback := NewCallback({ 776 // Handle trust, return the result 777 }) 778 SecurityParameters.SetTrustVerificationCallback(trustCallback) 780 o Identity challenge callback: Invoked when a private key operation 781 is required, e.g., when local authentication is requested by a 782 remote. 784 ChallengeCallback := NewCallback({ 785 // Handle challenge 786 }) 787 SecurityParameters.SetIdentityChallengeCallback(challengeCallback) 789 6. Establishing Connections 791 Before a Connection can be used for data transfer, it must be 792 established. Establishment ends the pre-establishment phase; all 793 transport properties and cryptographic parameter specification must 794 be complete before establishment, as these will be used to select 795 candidate Paths and Protocol Stacks for the Connection. 796 Establishment may be active, using the Initiate() Action; passive, 797 using the Listen() Action; or simultaneous for peer-to-peer, using 798 the Rendezvous() Action. These Actions are described in the 799 subsections below. 801 6.1. Active Open: Initiate 803 Active open is the Action of establishing a Connection to a Remote 804 Endpoint presumed to be listening for incoming Connection requests. 805 Active open is used by clients in client-server interactions. Active 806 open is supported by this interface through the Initiate Action: 808 Connection := Preconnection.Initiate() 810 Before calling Initiate, the caller must have populated a 811 Preconnection Object with a Remote Endpoint specifier, optionally a 812 Local Endpoint specifier (if not specified, the system will attempt 813 to determine a suitable Local Endpoint), as well as all properties 814 necessary for candidate selection. 816 The Initiate() Action consumes the Preconnection. Once Initiate() 817 has been called, no further properties may be added to the 818 Preconnection, and no subsequent establishment call may be made on 819 the Preconnection. 821 Once Initiate is called, the candidate Protocol Stack(s) may cause 822 one or more candidate transport-layer connections to be created to 823 the specified remote endpoint. The caller may immediately begin 824 sending Messages on the Connection (see Section 7) after calling 825 Initate(); note that any idempotent data sent while the Connection is 826 being established may be sent multiple times or on multiple 827 candidates. 829 The following Events may be sent by the Connection after Initiate() 830 is called: 832 Connection -> Ready<> 834 The Ready Event occurs after Initiate has established a transport- 835 layer connection on at least one usable candidate Protocol Stack over 836 at least one candidate Path. No Receive Events (see Section 8) will 837 occur before the Ready Event for Connections established using 838 Initiate. 840 Connection -> InitiateError<> 842 An InitiateError occurs either when the set of transport properties 843 and security parameters cannot be fulfilled on a Connection for 844 initiation (e.g. the set of available Paths and/or Protocol Stacks 845 meeting the constraints is empty) or reconciled with the local and/or 846 remote endpoints; when the remote specifier cannot be resolved; or 847 when no transport-layer connection can be established to the remote 848 endpoint (e.g. because the remote endpoint is not accepting 849 connections, or the application is prohibited from opening a 850 Connection by the operating system). 852 See also Section 7.6 to combine Connection establishment and 853 transmission of the first message in a single action. 855 6.2. Passive Open: Listen 857 Passive open is the Action of waiting for Connections from remote 858 endpoints, commonly used by servers in client-server interactions. 860 Passive open is supported by this interface through the Listen 861 Action: 863 Preconnection.Listen() 865 Before calling Listen, the caller must have initialized the 866 Preconnection during the pre-establishment phase with a Local 867 Endpoint specifier, as well as all properties necessary for Protocol 868 Stack selection. A Remote Endpoint may optionally be specified, to 869 constrain what Connections are accepted. The Listen() Action 870 consumes the Preconnection. Once Listen() has been called, no 871 further properties may be added to the Preconnection, and no 872 subsequent establishment call may be made on the Preconnection. 874 Listening continues until the global context shuts down, or until the 875 Stop action is performed on the same Preconnection: 877 Preconnection.Stop() 879 After Stop() is called, the preconnection can be disposed of. 881 Preconnection -> ConnectionReceived 883 The ConnectionReceived Event occurs when a Remote Endpoint has 884 established a transport-layer connection to this Preconnection (for 885 Connection-oriented transport protocols), or when the first Message 886 has been received from the Remote Endpoint (for Connectionless 887 protocols), causing a new Connection to be created. The resulting 888 Connection is contained within the ConnectionReceived event, and is 889 ready to use as soon as it is passed to the application via the 890 event. 892 Preconnection -> ListenError<> 894 A ListenError occurs either when the Preconnection cannot be 895 fulfilled for listening, when the Local Endpoint (or Remote Endpoint, 896 if specified) cannot be resolved, or when the application is 897 prohibited from listening by policy. 899 Preconnection -> Stopped<> 901 A Stopped event occurs after the Preconnection has stopped listening. 903 6.3. Peer-to-Peer Establishment: Rendezvous 905 Simultaneous peer-to-peer Connection establishment is supported by 906 the Rendezvous() Action: 908 Preconnection.Rendezvous() 910 The Preconnection Object must be specified with both a Local Endpoint 911 and a Remote Endpoint, and also the transport properties and security 912 parameters needed for Protocol Stack selection. 914 The Rendezvous() Action causes the Preconnection to listen on the 915 Local Endpoint for an incoming Connection from the Remote Endpoint, 916 while simultaneously trying to establish a Connection from the Local 917 Endpoint to the Remote Endpoint. This corresponds to a TCP 918 simultaneous open, for example. 920 The Rendezvous() Action consumes the Preconnection. Once 921 Rendezvous() has been called, no further properties may be added to 922 the Preconnection, and no subsequent establishment call may be made 923 on the Preconnection. 925 Preconnection -> RendezvousDone 927 The RendezvousDone<> Event occurs when a Connection is established 928 with the Remote Endpoint. For Connection-oriented transports, this 929 occurs when the transport-layer connection is established; for 930 Connectionless transports, it occurs when the first Message is 931 received from the Remote Endpoint. The resulting Connection is 932 contained within the RendezvousDone<> Event, and is ready to use as 933 soon as it is passed to the application via the Event. 935 Preconnection -> RendezvousError 937 An RendezvousError occurs either when the Preconnection cannot be 938 fulfilled for listening, when the Local Endpoint or Remote Endpoint 939 cannot be resolved, when no transport-layer connection can be 940 established to the Remote Endpoint, or when the application is 941 prohibited from rendezvous by policy. 943 When using some NAT traversal protocols, e.g., Interactive 944 Connectivity Establishment (ICE) [RFC5245], it is expected that the 945 Local Endpoint will be configured with some method of discovering NAT 946 bindings, e.g., a Session Traversal Utilities for NAT (STUN) server. 947 In this case, the Local Endpoint may resolve to a mixture of local 948 and server reflexive addresses. The Resolve() action on the 949 Preconnection can be used to discover these bindings: 951 []Preconnection := Preconnection.Resolve() 953 The Resolve() call returns a list of Preconnection Objects, that 954 represent the concrete addresses, local and server reflexive, on 955 which a Rendezvous() for the Preconnection will listen for incoming 956 Connections. These resolved Preconnections will share all other 957 Properties with the Preconnection from which they are derived, though 958 some Properties may be made more-specific by the resolution process. 959 This list can be passed to a peer via a signalling protocol, such as 960 SIP [RFC3261] or WebRTC [RFC7478], to configure the remote. 962 6.4. Connection Groups 964 Groups of Connections can be created using the Clone Action: 966 Connection := Connection.Clone() 968 Calling Clone on a Connection yields a group of two Connections: the 969 parent Connection on which Clone was called, and the resulting cloned 970 Connection. These connections are "entangled" with each other, and 971 become part of a Connection Group. Calling Clone on any of these two 972 Connections adds a third Connection to the Connection Group, and so 973 on. Connections in a Connection Group share all Protocol Properties 974 that are not applicable to a Message. 976 Changing one of these Protocol Properties on one Connection in the 977 group changes it for all others. Per-Message Protocol Properties, 978 however, are not entangled. For example, changing "Timeout for 979 aborting Connection" (see Section 9.1.6) on one Connection in a group 980 will automatically change this Protocol Property for all Connections 981 in the group in the same way. However, changing "Lifetime" (see 982 Section 7.3.1) of a Message will only affect a single Message on a 983 single Connection, entangled or not. 985 If the underlying protocol supports multi-streaming, it is natural to 986 use this functionality to implement Clone. In that case, entangled 987 Connections are multiplexed together, giving them similar treatment 988 not only inside endpoints but also across the end-to-end Internet 989 path. 991 If the underlying Protocol Stack does not support cloning, or cannot 992 create a new stream on the given Connection, then attempts to clone a 993 connection will result in a CloneError: 995 Connection -> CloneError<> 997 The Protocol Property "Niceness" operates on entangled Connections as 998 in Section 7.3.2: when allocating available network capacity among 999 Connections in a Connection Group, sends on Connections with higher 1000 Niceness values will be prioritized over sends on Connections with 1001 lower Niceness values. An ideal transport system implementation 1002 would assign each Connection the capacity share (M-N) x C / M, where 1003 N is the Connection's Niceness value, M is the maximum Niceness value 1004 used by all Connections in the group and C is the total available 1005 capacity. However, the Niceness setting is purely advisory, and no 1006 guarantees are given about the way capacity is shared. Each 1007 implementation is free to implement a way to share capacity that it 1008 sees fit. 1010 7. Sending Data 1012 Once a Connection has been established, it can be used for sending 1013 data. Data is sent in terms of Messages, which allow the application 1014 to communicate the boundaries of the data being transferred. By 1015 default, Send enqueues a complete Message, and takes optional per- 1016 Message properties (see Section 7.1). All Send actions are 1017 asynchronous, and deliver events (see Section 7.2). Sending partial 1018 Messages for streaming large data is also supported (see 1019 Section 7.4). 1021 7.1. Basic Sending 1023 The most basic form of sending on a connection involves enqueuing a 1024 single Data block as a complete Message, with default Message 1025 Properties. Message data is created as an array of octets, and the 1026 resulting object contains both the byte array and the length of the 1027 array. 1029 messageData := "hello".octets() 1030 Connection.Send(messageData) 1032 The interpretation of a Message to be sent is dependent on the 1033 implementation, and on the constraints on the Protocol Stacks implied 1034 by the Connection's transport properties. For example, a Message may 1035 be a single datagram for UDP Connections; or an HTTP Request for HTTP 1036 Connections. 1038 Some transport protocols can deliver arbitrarily sized Messages, but 1039 other protocols constrain the maximum Message size. Applications can 1040 query the protocol property Maximum Message Size on Send to determine 1041 the maximum size allowed for a single Message. If a Message is too 1042 large to fit in the Maximum Message Size for the Connection, the Send 1043 will fail with a SendError event (Section 7.2.3). For example, it is 1044 invalid to send a Message over a UDP connection that is larger than 1045 the available datagram sending size. 1047 7.2. Send Events 1049 Like all Actions in this interface, the Send Action is asynchronous. 1050 There are several events that can be delivered in response to Sending 1051 a Message. 1053 Note that if partial Sends are used (Section 7.4), there will still 1054 be exactly one Send Event delivered for each call to Send. For 1055 example, if a Message expired while two requests to Send data for 1056 that Message are outstanding, there will be two Expired events 1057 delivered. 1059 7.2.1. Sent 1061 Connection -> Sent 1063 The Sent Event occurs when a previous Send Action has completed, 1064 i.e., when the data derived from the Message has been passed down or 1065 through the underlying Protocol Stack and is no longer the 1066 responsibility of the implementation of this interface. The exact 1067 disposition of the Message (i.e., whether it has actually been 1068 transmitted, moved into a buffer on the network interface, moved into 1069 a kernel buffer, and so on) when the Sent Event occurs is 1070 implementation-specific. The Sent Event contains an implementation- 1071 specific reference to the Message to which it applies. 1073 Sent Events allow an application to obtain an understanding of the 1074 amount of buffering it creates. That is, if an application calls the 1075 Send Action multiple times without waiting for a Sent Event, it has 1076 created more buffer inside the transport system than an application 1077 that always waits for the Sent Event before calling the next Send 1078 Action. 1080 7.2.2. Expired 1082 Connection -> Expired 1084 The Expired Event occurs when a previous Send Action expired before 1085 completion; i.e. when the Message was not sent before its Lifetime 1086 (see Section 7.3.1) expired. This is separate from SendError, as it 1087 is an expected behavior for partially reliable transports. The 1088 Expired Event contains an implementation-specific reference to the 1089 Message to which it applies. 1091 7.2.3. SendError 1093 Connection -> SendError 1095 A SendError occurs when a Message could not be sent due to an error 1096 condition: an attempt to send a Message which is too large for the 1097 system and Protocol Stack to handle, some failure of the underlying 1098 Protocol Stack, or a set of Message Properties not consistent with 1099 the Connection's transport properties. The SendError contains an 1100 implementation-specific reference to the Message to which it applies. 1102 7.3. Message Properties 1104 Applications may need to annotate the Messages they send with extra 1105 information to control how data is scheduled and processed by the 1106 transport protocols in the Connection. A MessageContext object 1107 contains properties for sending Messages, and can be passed to the 1108 Send Action. Note that these properties are per-Message, not per- 1109 Send if partial Messages are sent (Section 7.4). All data blocks 1110 associated with a single Message share properties. For example, it 1111 would not make sense to have the beginning of a Message expire, but 1112 allow the end of a Message to still be sent. 1114 messageData := "hello".octets() 1115 messageContext := NewMessageContext() 1116 messageContext.add(parameter, value) 1117 Connection.Send(messageData, messageContext) 1119 The simpler form of Send that does not take any messageContext is 1120 equivalent to passing a default MessageContext with not values added. 1122 If an application wants to override Message Properties for a specific 1123 message, it can acquire an empty MessageContext Object and add all 1124 desired Message Properties to that Object. It can then reuse the 1125 same messageContext Object for sending multiple Messages with the 1126 same properties. 1128 Properties may be added to a MessageContext object only before the 1129 context is used for sending. Once a messageContext has been used 1130 with a Send call, modifying any of its properties is invalid. 1132 Message Properties may be inconsistent with the properties of the 1133 Protocol Stacks underlying the Connection on which a given Message is 1134 sent. For example, a Connection must provide reliability to allow 1135 setting an infinitie value for the lifetime property of a Message. 1136 Sending a Message with Message Properties inconsistent with the 1137 Selection Properties of the Connection yields an error. 1139 The following Message Properties are supported: 1141 7.3.1. Lifetime 1143 Type: Integer 1145 Lifetime specifies how long a particular Message can wait to be sent 1146 to the remote endpoint before it is irrelevant and no longer needs to 1147 be (re-)transmitted. When a Message's Lifetime is infinite, it must 1148 be transmitted reliably. The type and units of Lifetime are 1149 implementation-specific. 1151 7.3.2. Niceness 1153 Type: Integer (non-negative) 1155 This property represents an unbounded hierarchy of priorities. It 1156 can specify the priority of a Message, relative to other Messages 1157 sent over the same Connection. 1159 A Message with Niceness 0 will yield to a Message with Niceness 1, 1160 which will yield to a Message with Niceness 2, and so on. Niceness 1161 may be used as a sender-side scheduling construct only, or be used to 1162 specify priorities on the wire for Protocol Stacks supporting 1163 prioritization. 1165 Note that this property is not a per-message override of the 1166 connection Niceness - see Section 9.1.5. Both Niceness properties 1167 may interact, but can be used independently and be realized by 1168 different mechanisms. 1170 7.3.3. Ordered 1172 Type: Boolean 1174 If true, it specifies that the receiver-side transport protocol stack 1175 only deliver the Message to the receiving application after the 1176 previous ordered Message which was passed to the same Connection via 1177 the Send Action, when such a Message exists. If false, the Message 1178 may be delivered to the receiving application out of order. This 1179 property is used for protocols that support preservation of data 1180 ordering, see Section 5.2.3, but allow out-of-order delivery for 1181 certain messages. 1183 7.3.4. Idempotent 1185 Type: Boolean 1187 If true, it specifies that a Message is safe to send to the remote 1188 endpoint more than once for a single Send Action. It is used to mark 1189 data safe for certain 0-RTT establishment techniques, where 1190 retransmission of the 0-RTT data may cause the remote application to 1191 receive the Message multiple times. 1193 7.3.5. Final 1195 Type: Boolean 1197 If true, this Message is the last one that the application will send 1198 on a Connection. This allows underlying protocols to indicate to the 1199 Remote Endpoint that the Connection has been effectively closed in 1200 the sending direction. For example, TCP-based Connections can send a 1201 FIN once a Message marked as Final has been completely sent, 1202 indicated by marking endOfMessage. Protocols that do not support 1203 signalling the end of a Connection in a given direction will ignore 1204 this property. 1206 Note that a Final Message must always be sorted to the end of a list 1207 of Messages. The Final property overrides Niceness and any other 1208 property that would re-order Messages. If another Message is sent 1209 after a Message marked as Final has already been sent on a 1210 Connection, the Send Action for the new Message will cause a 1211 SendError Event. 1213 7.3.6. Corruption Protection Length 1215 Type: Integer (non-negative with -1 as special value) 1217 This property specifies the length of the section of the Message, 1218 starting from byte 0, that the application requires to be delivered 1219 without corruption due to lower layer errors. It is used to specify 1220 options for simple integrity protection via checksums. By default, 1221 the entire Message is protected by a checksum. A value of 0 means 1222 that no checksum is required, and a special value (e.g. -1) can be 1223 used to indicate the default. Only full coverage is guaranteed, any 1224 other requests are advisory. 1226 7.3.7. Reliable Data Transfer (Message) 1228 Type: Boolean 1230 This property specifies that a message should be sent in such a way 1231 that the transport protocol ensures all data is received on the other 1232 side without corruption. Changing the 'Reliable Data Transfer' 1233 property on Messages is only possible if the Connection supports 1234 reliability. When this is not the case, changing it will generate an 1235 error. 1237 7.3.8. Transmission Profile 1239 Type: Enumeration 1241 This enumerated property specifies the application's preferred 1242 tradeoffs for sending this Message; it is a per-Message override of 1243 the Capacity Profile protocol and path selection property (see 1244 Section 9.1.12). 1246 The following values are valid for Transmission Profile: 1248 Default: No special optimizations of the tradeoff between delay, 1249 delay variation, and bandwidth efficiency should be made when 1250 sending this message. 1252 Low Latency: Response time (latency) should be optimized at the 1253 expense of efficiently using the available capacity when sending 1254 this message. This can be used by the system to disable the 1255 coalescing of multiple small Messages into larger packets (Nagle's 1256 algorithm); to prefer immediate acknowledgment from the peer 1257 endpoint when supported by the underlying transport; to signal a 1258 preference for lower-latency, higher-loss treatment; and so on. 1260 [TODO: This is inconsistent with {prop-cap-profile}} - needs to be 1261 fixed] 1263 7.3.9. Singular Transmission 1265 Type: Boolean 1267 This property specifies that a message should be sent and received as 1268 a single packet without transport-layer segmentation or network-layer 1269 fragmentation. Attempts to send a message with this property set 1270 with a size greater to the transport's current estimate of its 1271 maximum transmission segment size will result in a "SendError". When 1272 used with transports supporting this functionality and running over 1273 IP version 4, the Don't Fragment bit will be set. 1275 7.4. Partial Sends 1277 It is not always possible for an application to send all data 1278 associated with a Message in a single Send Action. The Message data 1279 may be too large for the application to hold in memory at one time, 1280 or the length of the Message may be unknown or unbounded. 1282 Partial Message sending is supported by passing an endOfMessage 1283 boolean parameter to the Send Action. This value is always true by 1284 default, and the simpler forms of Send are equivalent to passing true 1285 for endOfMessage. 1287 The following example sends a Message in two separate calls to Send. 1289 messageContext := NewMessageContext() 1290 messageContext.add(parameter, value) 1292 messageData := "hel".octets() 1293 endOfMessage := false 1294 Connection.Send(messageData, messageContext, endOfMessage) 1296 messageData := "lo".octets() 1297 endOfMessage := true 1298 Connection.Send(messageData, messageContext, endOfMessage) 1300 All data sent with the same MessageContext object will be treated as 1301 belonging to the same Message, and will constitute an in-order series 1302 until the endOfMessage is marked. Once the end of the Message is 1303 marked, the MessageContext object may be re-used as a new Message 1304 with identical parameters. 1306 7.5. Batching Sends 1308 In order to reduce the overhead of sending multiple small Messages on 1309 a Connection, the application may want to batch several Send actions 1310 together. This provides a hint to the system that the sending of 1311 these Messages should be coalesced when possible, and that sending 1312 any of the batched Messages may be delayed until the last Message in 1313 the batch is enqueued. 1315 Connection.Batch( 1316 Connection.Send(messageData) 1317 Connection.Send(messageData) 1318 ) 1320 7.6. Send on Active Open: InitiateWithIdempotentSend 1322 For application-layer protocols where the Connection initiator also 1323 sends the first message, the InitiateWithIdempotentSend() action 1324 combines Connection initiation with a first Message sent, provided 1325 that message is idempotent. 1327 Without a message context (as in Section 7.1): 1329 Connection := Preconnection.InitiateWithIdempotentSend(messageData) 1331 With a message context (as in Section 7.3): 1333 Connection := Preconnection.InitiateWithIdempotentSend(messageData, messageContext) 1335 The message passed to InitiateWithIdempotentSend() is, as suggested 1336 by the name, considered to be idempotent (see Section 7.3.4) 1337 regardless of declared message properties or defaults. If protocol 1338 stacks supporting 0-RTT establishment with idempotent data are 1339 available on the Preconnection, then 0-RTT establishment may be used 1340 with the given message when establishing candidate connections. For 1341 a non-idemponent initial message, or when the selected stack(s) do 1342 not support 0-RTT establishment, InitiateWithIdempotentSend is 1343 identical to Initiate() followed by Send(). 1345 Neither partial sends nor send batching are supported by 1346 InitiateWithIdempotentSend(). 1348 The Events that may be sent after InitiateWithIdempotentSend() are 1349 equivalent to those that would be sent by an invocation of Initate() 1350 followed immediately by an invocation of Send(), with the caveat that 1351 a send failure that occurs because the Connection could not be 1352 established will not result in a SendError separate from the 1353 InitiateError signaling the failure of Connection establishment. 1355 7.7. Sender-side Framing 1357 Sender-side framing allows a caller to provide the interface with a 1358 function that takes a Message of an appropriate application-layer 1359 type and returns an array of octets, the on-the-wire representation 1360 of the Message to be handed down to the Protocol Stack. It consists 1361 of a Framer Object with a single Action, Frame. Since the Framer 1362 depends on the protocol used at the application layer, it is bound to 1363 the Preconnection during the pre-establishment phase: 1365 Preconnection.FrameWith(Framer) 1367 OctetArray := Framer.Frame(messageData) 1369 Sender-side framing is a convenience feature of the interface, for 1370 parity with receiver-side framing (see Section 8.4). 1372 8. Receiving Data 1374 Once a Connection is established, it can be used for receiving data. 1375 As with sending, data is received in terms of Messages. Receiving is 1376 an asynchronous operation, in which each call to Receive enqueues a 1377 request to receive new data from the connection. Once data has been 1378 received, or an error is encountered, an event will be delivered to 1379 complete the Receive request (see Section 8.2). 1381 As with sending, the type of the Message to be passed is dependent on 1382 the implementation, and on the constraints on the Protocol Stacks 1383 implied by the Connection's transport parameters. 1385 8.1. Enqueuing Receives 1387 Receive takes two parameters to specify the length of data that an 1388 application is willing to receive, both of which are optional and 1389 have default values if not specified. 1391 Connection.Receive(minIncompleteLength, maxLength) 1393 By default, Receive will try to deliver complete Messages in a single 1394 event (Section 8.2.1). 1396 The application can set a minIncompleteLength value to indicates the 1397 smallest partial Message data size in bytes that should be delivered 1398 in response to this Receive. By default, this value is infinite, 1399 which means that only complete Messages should be delivered (see 1400 Section 8.2.2 and Section 8.4 for more information on how this is 1401 accomplished). If this value is set to some smaller value, the 1402 associated receive event will be triggered only when at least that 1403 many bytes are available, or the Message is complete with fewer 1404 bytes, or the system needs to free up memory. Applications should 1405 always check the length of the data delivered to the receive event 1406 and not assume it will be as long as minIncompleteLength in the case 1407 of shorter complete Messages or memory issues. 1409 The maxLength argument indicates the maximum size of a Message in 1410 bytes the application is currently prepared to receive. The default 1411 value for maxLength is infinite. If an incoming Message is larger 1412 than the minimum of this size and the maximum Message size on receive 1413 for the Connection's Protocol Stack, it will be delivered via 1414 ReceivedPartial events (Section 8.2.2). 1416 Note that maxLength does not guarantee that the application will 1417 receive that many bytes if they are available; the interface may 1418 return ReceivedPartial events with less data than maxLength according 1419 to implementation constraints. 1421 8.2. Receive Events 1423 Each call to Receive will be paired with a single Receive Event, 1424 which can be a success or an error. This allows an application to 1425 provide backpressure to the transport stack when it is temporarily 1426 not ready to receive messages. 1428 8.2.1. Received 1430 Connection -> Received 1431 A Received event indicates the delivery of a complete Message. It 1432 contains two objects, the received bytes as messageData, and the 1433 metadata and properties of the received Message as messageContext. 1434 See {#receive-context} for details about the received context. 1436 The messageData object provides access to the bytes that were 1437 received for this Message, along with the length of the byte array. 1439 See Section 8.4 for handling Message framing in situations where the 1440 Protocol Stack provides octet-stream transport only. 1442 8.2.2. ReceivedPartial 1444 Connection -> ReceivedPartial 1446 If a complete Message cannot be delivered in one event, one part of 1447 the Message may be delivered with a ReceivedPartial event. In order 1448 to continue to receive more of the same Message, the application must 1449 invoke Receive again. 1451 Multiple invocations of ReceivedPartial deliver data for the same 1452 Message by passing the same MessageContext, until the endOfMessage 1453 flag is delivered or a ReceiveError occurs. All partial blocks of a 1454 single Message are delivered in order without gaps. This event does 1455 not support delivering discontiguous partial Messages. 1457 If the minIncompleteLength in the Receive request was set to be 1458 infinite (indicating a request to receive only complete Messages), 1459 the ReceivedPartial event may still be delivered if one of the 1460 following conditions is true: 1462 o the underlying Protocol Stack supports message boundary 1463 preservation, and the size of the Message is larger than the 1464 buffers available for a single message; 1466 o the underlying Protocol Stack does not support message boundary 1467 preservation, and the deframer (see Section 8.4) cannot determine 1468 the end of the message using the buffer space it has available; or 1470 o the underlying Protocol Stack does not support message boundary 1471 preservation, and no deframer was supplied by the application 1473 Note that in the absence of message boundary preservation or 1474 deframing, all bytes received on the Connection will be represented 1475 as one large message of indeterminate length. 1477 8.2.3. ReceiveError 1479 Connection -> ReceiveError 1481 A ReceiveError occurs when data is received by the underlying 1482 Protocol Stack that cannot be fully retrieved or deframed, or when 1483 some other indication is received that reception has failed. Such 1484 conditions that irrevocably lead to the termination of the Connection 1485 are signaled using ConnectionError instead (see Section 10). 1487 The ReceiveError event passes an optional associated MessageContext. 1488 This may indicate that a Message that was being partially received 1489 previously, but had not completed, encountered an error and will not 1490 be completed. 1492 8.3. Message Receive Context 1494 Each Received Message Context may contain metadata from protocols in 1495 the Protocol Stack; which metadata is available is Protocol Stack 1496 dependent. The following metadata values are supported: 1498 8.3.1. ECN 1500 When available, Message metadata carries the value of the Explicit 1501 Congestion Notification (ECN) field. This information can be used 1502 for logging and debugging purposes, and for building applications 1503 which need access to information about the transport internals for 1504 their own operation. 1506 8.3.2. Early Data 1508 In some cases it may be valuable to know whether data was read as 1509 part of early data transfer (before connection establishment has 1510 finished). This is useful if applications need to treat early data 1511 separately, e.g., if early data has different security properties 1512 than data sent after connection establishment. In the case of TLS 1513 1.3, client early data can be replayed maliciously (see 1514 [I-D.ietf-tls-tls13]). Thus, receivers may wish to perform 1515 additional checks for early data to ensure it is idempotent or not 1516 replayed. If TLS 1.3 is available and the recipient Message was sent 1517 as part of early data, the corresponding metadata carries a flag 1518 indicating as such. If early data is enabled, applications should 1519 check this metadata field for Messages received during connection 1520 establishment and respond accordingly. 1522 8.3.3. Receiving Final Messages 1524 The Received Message Context can indicate whether or not this Message 1525 is the Final Message on a Connection. For any Message that is marked 1526 as Final, the application can assume that there will be no more 1527 Messages received on the Connection once the Message has been 1528 completely delivered. This corresponds to the Final property that 1529 may be marked on a sent Message Section 7.3.5. 1531 Some transport protocols and peers may not support signaling of the 1532 Final property. Applications therefore should not rely on receiving 1533 a Message marked Final to know that the other endpoint is done 1534 sending on a connection. 1536 Any calls to Receive once the Final Message has been delivered will 1537 result in errors. 1539 8.4. Receiver-side De-framing over Stream Protocols 1541 The Receive Event is intended to be fired once per application-layer 1542 Message sent by the remote endpoint; i.e., it is a desired property 1543 of this interface that a Send at one end of a Connection maps to 1544 exactly one Receive on the other end. This is possible with Protocol 1545 Stacks that provide message boundary preservation, but is not the 1546 case over Protocol Stacks that provide a simple octet stream 1547 transport. 1549 For preserving message boundaries over stream transports, this 1550 interface provides receiver-side de-framing. This facility is based 1551 on the observation that, since many of our current application 1552 protocols evolved over TCP, which does not provide message boundary 1553 preservation, and since many of these protocols require message 1554 boundaries to function, each application layer protocol has defined 1555 its own framing. A Deframer allows an application to push this de- 1556 framing down into the interface, in order to transform an octet 1557 stream into a sequence of Messages. 1559 Concretely, receiver-side de-framing allows a caller to provide the 1560 interface with a function that takes an octet stream, as provided by 1561 the underlying Protocol Stack, reads and returns a single Message of 1562 an appropriate type for the application and platform, and leaves the 1563 octet stream at the start of the next Message to deframe. It 1564 consists of a Deframer Object with a single Action, Deframe. Since 1565 the Deframer depends on the protocol used at the application layer, 1566 it is bound to the Preconnection during the pre-establishment phase: 1568 Preconnection.DeframeWith(Deframer) 1570 {messageData} := Deframer.Deframe(OctetStream, ...) 1572 9. Managing Connections 1574 After establishment, connections can be configured and queried using 1575 Connection Properties, and asynchronous information may be available 1576 about the state of the connection via Soft Errors. 1578 Connection Properties represent the configuration and state of the 1579 selected Protocol Stack(s) backing a Connection. These Connection 1580 Properties may be Generic, applying regardless of transport protocol, 1581 or Specific, applicable to a single implementation of a single 1582 transport protocol stack. Generic Connection Properties are defined 1583 in Section 9.1 below. Specific Protocol Properties are defined in a 1584 transport- and implementation-specific way, and must not be assumed 1585 to apply across different protocols. Attempts to set Specific 1586 Protocol Properties on a protocol stack not containing that specific 1587 protocol are simply ignored, and do not raise an error; however, too 1588 much reliance by an application on Specific Protocol Properties may 1589 significantly reduce the flexibility of a transport services 1590 implementation. 1592 The application can set and query Connection Properties on a per- 1593 Connection basis. Connection Properties that are not read-only can 1594 be set during pre-establishment (see Section 5.2), as well as on 1595 connections directly using the SetProperty action: ~~~ 1596 Connection.SetProperty(property, value) ~~~ 1598 At any point, the application can query Connection Properties. ~~~ 1599 ConnectionProperties := Connection.GetProperties() ~~~ 1601 Depending on the status of the connection, the queried Connection 1602 Properties will include different information: 1604 o The connection state, which can be one of the following: 1605 Establishing, Established, Closing, or Closed. 1607 o Whether the connection can be used to send data. A connection can 1608 not be used for sending if the connection was created with the 1609 Selection Property "Direction of Communication" set to 1610 "unidirectional receive" or if a Message marked as "Final" was 1611 sent over this connection, see Section 7.3.5. 1613 o Whether the connection can be used to receive data. A connection 1614 can not be used for reading if the connection was created with the 1615 Selection Property "Direction of Communication" set to 1616 "unidirectional send" or if a Message marked as "Final" was 1617 received, see Section 8.3.3. The latter is only supported by 1618 certain transport protocols, e.g., by TCP as half-closed 1619 connection. 1621 o For Connections that are Establishing: Transport Properties that 1622 the application specified on the Preconnection, see Section 5.2. 1624 o For Connections that are Established, Closing, or Closed: 1625 Selection (Section 5.2) and Connection Properties (Section 9.1) of 1626 the actual protocols that were selected and instantiated. 1627 Selection Properties indicate whether or not the Connection has or 1628 offers a certain Selection Property. Note that the actually 1629 instantiated protocol stack may not match all Protocol Selection 1630 Properties that the application specified on the Preconnection. 1631 For example, a certain Protocol Selection Property that an 1632 application specified as Preferred may not actually be present in 1633 the chosen protocol stack because none of the currently available 1634 transport protocols had this feature. 1636 o For Connections that are Established, additional properties of the 1637 path(s) in use. These properties can be derived from the local 1638 provisioning domain [RFC7556], measurements by the Protocol Stack, 1639 or other sources. 1641 9.1. Generic Connection Properties 1643 The Connection Properties defined as independent, and available on 1644 all Connections are defined in the subsections below. 1646 Note that many protocol properties have a corresponding selection 1647 property, which prefers protocols providing a specific transport 1648 feature that controlled by that protocol property. [EDITOR'S NOTE: 1649 todo: add these cross-references up to Section 5.2] 1651 9.1.1. Notification of excessive retransmissions 1653 Type: Boolean 1655 This property specifies whether an application considers it useful to 1656 be informed in case sent data was retransmitted more often than a 1657 certain threshold. When set to true, the effect is twofold: The 1658 application may receive events in case excessive retransmissions. In 1659 addition, the transport system considers this as a preference to use 1660 transports stacks that can provide this notification. This is not a 1661 strict requirement. If set to false, no notification of excessive 1662 retransmissions will be sent and this transport feature is ignored 1663 for protocol selection. 1665 The recommended default is to have this option. 1667 9.1.2. Retransmission threshold before excessive retransmission 1668 notification 1670 Type: Integer 1672 This property specifies after how many retransmissions to inform the 1673 application about "Excessive Retransmissions". 1675 9.1.3. Notification of ICMP soft error message arrival 1677 Type: Boolean 1679 This property specifies whether an application considers it useful to 1680 be informed when an ICMP error message arrives that does not force 1681 termination of a connection. When set to true, received ICMP errors 1682 will be available as SoftErrors. Note that even if a protocol 1683 supporting this property is selected, not all ICMP errors will 1684 necessarily be delivered, so applications cannot rely on receiving 1685 them. Setting this option also implies a preference to prefer 1686 transports stacks that can provide this notification. If not set, no 1687 events will be sent for ICMP soft error message and this transport 1688 feature is ignored for protocol selection. 1690 This property applies to Connections and Connection Groups. The 1691 recommended default is not to have this option. 1693 9.1.4. Required minimum coverage of the checksum for receiving 1695 Type: Integer 1697 This property specifies the part of the received data that needs to 1698 be covered by a checksum. It is given in Bytes. A value of 0 means 1699 that no checksum is required, and a special value (e.g., -1) 1700 indicates full checksum coverage. 1702 9.1.5. Niceness (Connection) 1704 Type: Integer 1706 This Property is a non-negative integer representing the relative 1707 inverse priority of this Connection relative to other Connections in 1708 the same Connection Group. It has no effect on Connections not part 1709 of a Connection Group. As noted in Section 6.4, this property is not 1710 entangled when Connections are cloned. 1712 9.1.6. Timeout for aborting Connection 1714 Type: Integer 1716 This property specifies how long to wait before aborting a Connection 1717 during establishment, or before deciding that a Connection has failed 1718 after establishment. It is given in seconds. 1720 9.1.7. Connection group transmission scheduler 1722 Type: Enum 1724 This property specifies which scheduler should be used among 1725 Connections within a Connection Group, see Section 6.4. The set of 1726 schedulers can be taken from [I-D.ietf-tsvwg-sctp-ndata]. 1728 9.1.8. Maximum message size concurrent with Connection establishment 1730 Type: Integer (read only) 1732 This property represents the maximum Message size that can be sent 1733 before or during Connection establishment, see also Section 7.3.4. 1734 It is given in Bytes. 1736 9.1.9. Maximum Message size before fragmentation or segmentation 1738 Type: Integer (read only) 1740 This property, if applicable, represents the maximum Message size 1741 that can be sent without incurring network-layer fragmentation or 1742 transport layer segmentation at the sender. 1744 9.1.10. Maximum Message size on send 1746 Type: Integer (read only) 1748 This property represents the maximum Message size that can be sent. 1750 9.1.11. Maximum Message size on receive 1752 Type: Integer (read only) 1754 This numeric property represents the maximum Message size that can be 1755 received. 1757 9.1.12. Capacity Profile 1759 This property specifies the desired network treatment for traffic 1760 sent by the application and the tradeoffs the application is prepared 1761 to make in path and protocol selection to receive that desired 1762 treatment. When the capacity profile is set to a value other than 1763 Default, the transport system should select paths and profiles to 1764 optimize for the capacity profile specified. The following values 1765 are valid for the Capacity Profile: 1767 Default: The application makes no representation about its expected 1768 capacity profile. No special optimizations of the tradeoff 1769 between delay, delay variation, and bandwidth efficiency should be 1770 made when selecting and configuring transport protocol stacks. 1771 Transport system implementations that map the requested capacity 1772 profile onto per-connection DSCP signaling without multiplexing 1773 SHOULD assign the DSCP Default Forwarding [RFC2474] PHB; when the 1774 Connection is multiplexed, the guidelines in section 6 of 1775 [RFC7657] apply. 1777 Scavenger: The application is not interactive. It expects to send 1778 and/or receive data without any urgency. This can, for example, 1779 be used to select protocol stacks with scavenger transmission 1780 control and/or to assign the traffic to a lower-effort service. 1781 Transport system implementations that map the requested capacity 1782 profile onto per-connection DSCP signaling without multiplexing 1783 SHOULD assign the DSCP Less than Best Effort [LE-PHB] PHB; when 1784 the Connection is multiplexed, the guidelines in section 6 of 1785 [RFC7657] apply. 1787 Low Latency/Interactive: The application is interactive, and prefers 1788 loss to latency. Response time should be optimized at the expense 1789 of bandwidth efficiency and delay variation when sending on this 1790 connection. This can be used by the system to disable the 1791 coalescing of multiple small Messages into larger packets (Nagle's 1792 algorithm); to prefer immediate acknowledgment from the peer 1793 endpoint when supported by the underlying transport; and so on. 1794 Transport system implementations that map the requested capacity 1795 profile onto per-connection DSCP signaling without multiplexing 1796 SHOULD assign the DSCP Expedited Forwarding [RFC3246] PHB; when 1797 the Connection is multiplexed, the guidelines in section 6 of 1798 [RFC7657] apply. 1800 Low Latency/Non-Interactive: The application prefers loss to latency 1801 but is not interactive. Response time should be optimized at the 1802 expense of bandwidth efficiency and delay variation when sending 1803 on this connection.Transport system implementations that map the 1804 requested capacity profile onto per-connection DSCP signaling 1805 without multiplexing SHOULD assign a DSCP Assured Forwarding 1806 (AF21,AF22,AF23,AF24) [RFC2597] PHB; when the Connection is 1807 multiplexed, the guidelines in section 6 of [RFC7657] apply. 1809 Constant-Rate Streaming: The application expects to send/receive 1810 data at a constant rate after Connection establishment. Delay and 1811 delay variation should be minimized at the expense of bandwidth 1812 efficiency. This implies that the Connection may fail if the 1813 desired rate cannot be maintained across the Path. A transport 1814 may interpret this capacity profile as preferring a circuit 1815 breaker [RFC8084] to a rate-adaptive congestion controller. 1816 Transport system implementations that map the requested capacity 1817 profile onto per-connection DSCP signaling without multiplexing 1818 SHOULD assign a DSCP Assured Forwarding (AF31,AF32,AF33,AF34) 1819 [RFC2597] PHB; when the Connection is multiplexed, the guidelines 1820 in section 6 of [RFC7657] apply. 1822 High Throughput Data: The application expects to send/receive data 1823 at the maximum rate allowed by its congestion controller over a 1824 relatively long period of time. Transport system implementations 1825 that map the requested capacity profile onto per-connection DSCP 1826 signaling without multiplexing SHOULD assign a DSCP Assured 1827 Forwarding (AF11,AF12,AF13,AF14) [RFC2597] PHB per section 4.8 of 1828 [RFC4594]. When the Connection is multiplexed, the guidelines in 1829 section 6 of [RFC7657] apply. 1831 The Capacity Profile for a selected protocol stack may be modified on 1832 a per-Message basis using the Transmission Profile Message Property; 1833 see Section 7.3.8. 1835 9.2. Soft Errors 1837 Asynchronous introspection is also possible, via the SoftError Event. 1838 This event informing the application about the receipt of an ICMP 1839 error message related to the Connection. This will only happen if 1840 the underlying protocol stack supports access to soft errors; 1841 however, even if the underlying stack supports it, there is no 1842 guarantee that a soft error will be signaled. 1844 Connection -> SoftError<> 1846 10. Connection Termination 1848 Close terminates a Connection after satisfying all the requirements 1849 that were specified regarding the delivery of Messages that the 1850 application has already given to the transport system. For example, 1851 if reliable delivery was requested for a Message handed over before 1852 calling Close, the transport system will ensure that this Message is 1853 indeed delivered. If the Remote Endpoint still has data to send, it 1854 cannot be received after this call. 1856 Connection.Close() 1858 The Closed Event can inform the application that the Remote Endpoint 1859 has closed the Connection; however, there is no guarantee that a 1860 remote Close will indeed be signaled. 1862 Connection -> Closed<> 1864 Abort terminates a Connection without delivering remaining data: 1866 Connection.Abort() 1868 A ConnectionError can inform the application that the other side has 1869 aborted the Connection; however, there is no guarantee that an Abort 1870 will indeed be signaled. 1872 Connection -> ConnectionError<> 1874 11. Connection State and Ordering of Operations and Events 1876 As this interface is designed to be independent of an 1877 implementation's concurrency model, the details of how exactly 1878 actions are handled, and on which threads/callbacks events are 1879 dispatched, are implementation dependent. 1881 Each transition of connection state is associated with one of more 1882 events: 1884 o Ready<> occurs when a Connection created with Initiate() or 1885 InitiateWithIdempotentData() transitions to Established state. 1887 o ConnectionReceived<> occurs when a Connection created with 1888 Listen() transitions to Established state. 1890 o RendezvousDone<> occurs when a Connection created with 1891 Rendezvous() transitions to Established state. 1893 o Closed<> occurs when a Connection transitions to Closed state 1894 without error. 1896 o InitiateError<> occurs when a Connection created with Initiate() 1897 transitions from Establishing state to Closed state due to an 1898 error. 1900 o ConnectionError<> occurs when a Connection transitions to Closed 1901 state due to an error in all other circumstances. 1903 The interface provides the following guarantees about the ordering of 1904 operations: 1906 o Sent<> events will occur on a Connection in the order in which the 1907 Messages were sent (i.e., delivered to the kernel or to the 1908 network interface, depending on implementation). 1910 o Received<> will never occur on a Connection before it is 1911 Established; i.e. before a Ready<> event on that Connection, or a 1912 ConnectionReceived<> or RendezvousDone<> containing that 1913 Connection. 1915 o No events will occur on a Connection after it is Closed; i.e., 1916 after a Closed<> event, an InitiateError<> or ConnectionError<> on 1917 that connection. To ensure this ordering, Closed<> will not occur 1918 on a Connection while other events on the Connection are still 1919 locally outstanding (i.e., known to the interface and waiting to 1920 be dealt with by the application). ConnectionError<> may occur 1921 after Closed<>, but the interface must gracefully handle all cases 1922 where application ignores these errors. 1924 12. IANA Considerations 1926 RFC-EDITOR: Please remove this section before publication. 1928 This document has no Actions for IANA. 1930 13. Security Considerations 1932 This document describes a generic API for interacting with a 1933 transport services (TAPS) system. Part of this API includes 1934 configuration details for transport security protocols, as discussed 1935 in Section 5.3. It does not recommend use (or disuse) of specific 1936 algorithms or protocols. Any API-compatible transport security 1937 protocol should work in a TAPS system. 1939 14. Acknowledgements 1941 This work has received funding from the European Union's Horizon 2020 1942 research and innovation programme under grant agreements No. 644334 1943 (NEAT) and No. 688421 (MAMI). 1945 This work has been supported by Leibniz Prize project funds of DFG - 1946 German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ 1947 FE 570/4-1). 1949 This work has been supported by the UK Engineering and Physical 1950 Sciences Research Council under grant EP/R04144X/1. 1952 Thanks to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric 1953 Kinnear for their implementation and design efforts, including Happy 1954 Eyeballs, that heavily influenced this work. Thanks to Laurent Chuat 1955 and Jason Lee for initial work on the Post Sockets interface, from 1956 which this work has evolved. 1958 15. References 1960 15.1. Normative References 1962 [I-D.ietf-taps-arch] 1963 Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., 1964 Perkins, C., Tiesel, P., and C. Wood, "An Architecture for 1965 Transport Services", draft-ietf-taps-arch-01 (work in 1966 progress), July 2018. 1968 [I-D.ietf-taps-minset] 1969 Welzl, M. and S. Gjessing, "A Minimal Set of Transport 1970 Services for End Systems", draft-ietf-taps-minset-11 (work 1971 in progress), September 2018. 1973 [I-D.ietf-tls-tls13] 1974 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1975 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 1976 March 2018. 1978 [I-D.ietf-tsvwg-rtcweb-qos] 1979 Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP 1980 Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- 1981 qos-18 (work in progress), August 2016. 1983 [I-D.ietf-tsvwg-sctp-ndata] 1984 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 1985 "Stream Schedulers and User Message Interleaving for the 1986 Stream Control Transmission Protocol", draft-ietf-tsvwg- 1987 sctp-ndata-13 (work in progress), September 2017. 1989 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1990 Requirement Levels", BCP 14, RFC 2119, 1991 DOI 10.17487/RFC2119, March 1997, 1992 . 1994 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1995 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1996 May 2017, . 1998 15.2. Informative References 2000 [I-D.ietf-taps-transport-security] 2001 Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey 2002 of Transport Security Protocols", draft-ietf-taps- 2003 transport-security-02 (work in progress), June 2018. 2005 [LE-PHB] Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", 2006 draft-ietf-tsvwg-le-phb-06 (work in progress), October 2007 2018. 2009 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2010 RFC 793, DOI 10.17487/RFC0793, September 1981, 2011 . 2013 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2014 "Definition of the Differentiated Services Field (DS 2015 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2016 DOI 10.17487/RFC2474, December 1998, 2017 . 2019 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 2020 "Assured Forwarding PHB Group", RFC 2597, 2021 DOI 10.17487/RFC2597, June 1999, 2022 . 2024 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 2025 RFC 2914, DOI 10.17487/RFC2914, September 2000, 2026 . 2028 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 2029 J., Courtney, W., Davari, S., Firoiu, V., and D. 2030 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 2031 Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, 2032 . 2034 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2035 A., Peterson, J., Sparks, R., Handley, M., and E. 2036 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2037 DOI 10.17487/RFC3261, June 2002, 2038 . 2040 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 2041 Guidelines for DiffServ Service Classes", RFC 4594, 2042 DOI 10.17487/RFC4594, August 2006, 2043 . 2045 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2046 (ICE): A Protocol for Network Address Translator (NAT) 2047 Traversal for Offer/Answer Protocols", RFC 5245, 2048 DOI 10.17487/RFC5245, April 2010, 2049 . 2051 [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 2052 Time Communication Use Cases and Requirements", RFC 7478, 2053 DOI 10.17487/RFC7478, March 2015, 2054 . 2056 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 2057 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 2058 . 2060 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 2061 (Diffserv) and Real-Time Communication", RFC 7657, 2062 DOI 10.17487/RFC7657, November 2015, 2063 . 2065 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", 2066 BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, 2067 . 2069 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 2070 Ed., "Services Provided by IETF Transport Protocols and 2071 Congestion Control Mechanisms", RFC 8095, 2072 DOI 10.17487/RFC8095, March 2017, 2073 . 2075 Appendix A. Additional Properties 2077 The interface specified by this document represents the minimal 2078 common interface to an endpoint in the transport services 2079 architecture [I-D.ietf-taps-arch], based upon that architecture and 2080 on the minimal set of transport service features elaborated in 2081 [I-D.ietf-taps-minset]. However, the interface has been designed 2082 with extension points to allow the implementation of features beyond 2083 those in the minimal common interface: Protocol Selection Properties, 2084 Path Selection Properties, and Message Properties are open sets. 2085 Implementations of the interface are free to extend these sets to 2086 provide additional expressiveness to applications written on top of 2087 them. 2089 This appendix enumerates a few additional properties that could be 2090 used to enhance transport protocol and/or path selection, or the 2091 transmission of messages given a Protocol Stack that implements them. 2092 These are not part of the interface, and may be removed from the 2093 final document, but are presented here to support discussion within 2094 the TAPS working group as to whether they should be added to a future 2095 revision of the base specification. 2097 A.1. Experimental Transport Properties 2099 The following Transport Properties might be made available in 2100 addition to those specified in Section 5.2, Section 9.1, and 2101 Section 7.3. 2103 A.1.1. Direction of communication 2105 Classification: Selection Property, Control Property [TODO: Discuss] 2107 Type: Enumeration 2109 Applicability: Preconnection, Connection (read only) 2111 This property specifies whether an application wants to use the 2112 connection for sending and/or receiving data. Possible values are: 2114 Bidirectional (default): The connection must support sending and 2115 receiving data 2117 unidirectional send: The connection must support sending data. 2119 unidirectional receive: The connection must support receiving data 2121 In case a unidirectional connection is requested, but unidirectional 2122 connections are not supported by the transport protocol, the system 2123 should fall back to bidirectional transport. 2125 A.1.2. Suggest a timeout to the Remote Endpoint 2127 Classification: Selection Property 2129 Type: Preference 2131 Applicability: Preconnection 2133 This property specifies whether an application considers it useful to 2134 propose a timeout until the Connection is assumed to be lost. The 2135 default is to have this option. 2137 [EDITOR'S NOTE: For discussion of this option, see 2138 https://github.com/taps-api/drafts/issues/109] 2140 A.1.3. Abort timeout to suggest to the Remote Endpoint 2142 Classification: Protocol Property 2144 Type: Integer 2146 Applicability: Preconnection, Connection 2148 This numeric property specifies the timeout to propose to the Remote 2149 Endpoint. It is given in seconds. 2151 [EDITOR'S NOTE: For discussion of this property, see 2152 https://github.com/taps-api/drafts/issues/109] 2154 A.1.4. Traffic Category 2156 Classification: Intent 2158 Type: Enumeration 2160 Applicability: Preconnection 2162 This property specifies what the application expects the dominating 2163 traffic pattern to be. Possible values are: 2165 Query: Single request / response style workload, latency bound 2167 Control: Long lasting low bandwidth control channel, not bandwidth 2168 bound 2170 Stream: Stream of data with steady data rate 2172 Bulk: Bulk transfer of large Messages, presumably bandwidth bound 2174 The default is to not assume any particular traffic pattern. Most 2175 categories suggest the use of other intents to further describe the 2176 traffic pattern anticipated, e.g., the bulk category suggesting the 2177 use of the Message Size intents or the stream category suggesting the 2178 Stream Bitrate and Duration intents. 2180 A.1.5. Size to be Sent or Received 2182 Classification: Intent 2184 Type: Integer 2186 Applicability: Preconnection, Message 2187 This property specifies how many bytes the application expects to 2188 send (Size to be Sent) or how many bytes the application expects to 2189 receive in response (Size to be Received). 2191 A.1.6. Duration 2193 Classification: Intent 2195 Type: Integer 2197 Applicability: Preconnection 2199 This Intent specifies what the application expects the lifetime of a 2200 Connection to be. It is given in milliseconds. 2202 A.1.7. Send or Receive Bit-rate 2204 Classification: Intent 2206 Type: Integer 2208 Applicability: Preconnection, Message 2210 This Intent specifies what the application expects the bit-rate of a 2211 transfer to be. It is given in Bytes per second. 2213 On a Message, this property specifies at what bitrate the application 2214 wishes the Message to be sent. A transport system supporting this 2215 feature will not exceed the requested Send Bitrate even if flow- 2216 control and congestion control allow higher bitrates. This helps to 2217 avoid a bursty traffic pattern on busy streaming video servers. 2219 A.1.8. Cost Preferences 2221 Classification: Intent 2223 Type: Enumeration 2225 Applicability: Preconnection, Message 2227 This property describes what an application prefers regarding 2228 monetary costs, e.g., whether it considers it acceptable to utilize 2229 limited data volume. It provides hints to the transport system on 2230 how to handle trade-offs between cost and performance or reliability. 2232 Possible values are: 2234 No Expense: Avoid transports associated with monetary cost 2235 Optimize Cost: Prefer inexpensive transports and accept service 2236 degradation 2238 Balance Cost: Use system policy to balance cost and other criteria 2240 Ignore Cost: Ignore cost, choose transport solely based on other 2241 criteria 2243 The default is "Balance Cost". 2245 Appendix B. Sample API definition in Go 2247 This document defines an abstract interface. To illustrate how this 2248 would map concretely into a programming language, an API interface 2249 definition in Go is available online at https://github.com/mami- 2250 project/postsocket. Documentation for this API - an illustration of 2251 the documentation an application developer would see for an instance 2252 of this interface - is available online at 2253 https://godoc.org/github.com/mami-project/postsocket. This API 2254 definition will be kept largely in sync with the development of this 2255 abstract interface definition. 2257 Appendix C. Relationship to the Minimal Set of Transport Services for 2258 End Systems 2260 [I-D.ietf-taps-minset] identifies a minimal set of transport services 2261 that end systems should offer. These services make all transport 2262 features offered by TCP, MPTCP, UDP, UDP-Lite, SCTP and LEDBAT 2263 available that 1) require interaction with the application, and 2) do 2264 not get in the way of a possible implementation over TCP or, with 2265 limitations, UDP. The following text explains how this minimal set 2266 is reflected in the present API. For brevity, this uses the list in 2267 Section 4.1 of [I-D.ietf-taps-minset], updated according to the 2268 discussion in Section 5 of [I-D.ietf-taps-minset]. 2270 [EDITOR'S NOTE: This is early text. In the future, this section will 2271 contain backward references, which we currently avoid because things 2272 are still being moved around and names / categories etc. are 2273 changing. Also, clearly, the intention is for the full minset to be 2274 reflected by the API at some point.] 2276 o Connect: 2277 "Initiate" Action. 2279 o Listen: 2280 "Listen" Action. 2282 o Specify number of attempts and/or timeout for the first 2283 establishment message: 2284 TODO. 2286 o Disable MPTCP: 2287 TODO. 2289 o Hand over a message to reliably transfer (possibly multiple times) 2290 before connection establishment: 2291 "InitiateWithIdempotentSend" Action. 2293 o Hand over a message to reliably transfer during connection 2294 establishment: 2295 TODO. 2297 o Change timeout for aborting connection (using retransmit limit or 2298 time value): 2299 "Timeout for aborting Connection" property, using a time value in 2300 seconds. 2302 o Timeout event when data could not be delivered for too long: 2303 TODO: this should probably be covered by the "ConnectionError" 2304 Event, but the text above it currently reads: "...can inform the 2305 application that the other side has aborted the Connection". In 2306 this case, it is the local side. 2308 o Suggest timeout to the peer: 2309 "Suggest a timeout to the Remote Endpoint" and "Abort timeout to 2310 suggest to the Remote Endpoint" Selection property. [EDITOR'S 2311 NOTE: For discussion of this option, see https://github.com/taps- 2312 api/drafts/issues/109]. 2314 o Notification of Excessive Retransmissions (early warning below 2315 abortion threshold): 2316 "Notification of excessive retransmissions" property. 2318 o Notification of ICMP error message arrival: 2319 "Notification of ICMP soft error message arrival" property. 2321 o Choose a scheduler to operate between streams of an association: 2322 "Connection group transmission scheduler" property. 2324 o Configure priority or weight for a scheduler: 2325 "Niceness (Connection)" property. 2327 o "Specify checksum coverage used by the sender" and "Disable 2328 checksum when sending": 2329 "Corruption Protection Length" property (value 0 to disable). 2331 o "Specify minimum checksum coverage required by receiver" and 2332 "Disable checksum requirement when receiving": 2333 "Required minimum coverage of the checksum for receiving" property 2334 (value 0 to disable). 2336 o "Specify DF" field and "Request not to bundle messages:" 2337 The "Singular Transmission" Message property combines both of 2338 these requests, i.e. if a request not to bundle messages is made, 2339 this also turns off DF in case of protocols that allow this (only 2340 UDP and UDP-Lite, which cannot bundle messages anyway). 2342 o Get max. transport-message size that may be sent using a non- 2343 fragmented IP packet from the configured interface: 2344 "Maximum Message size before fragmentation or segmentation" 2345 property. 2347 o Get max. transport-message size that may be received from the 2348 configured interface: 2349 "Maximum Message size on receive" property. 2351 o Obtain ECN field: 2352 "ECN" is a defined metadata value as part of the Message Receive 2353 Context. 2355 o "Specify DSCP field", "Disable Nagle algorithm", "Enable and 2356 configure a 'Low Extra Delay Background Transfer'": 2357 As suggested in Section 5.5 of [I-D.ietf-taps-minset], these 2358 transport features are collectively offered via the "Capacity 2359 profile" property. 2361 o Close after reliably delivering all remaining data, causing an 2362 event informing the application on the other side: 2363 This is offered by the "Close" Action with slightly changed 2364 semantics in line with the discussion in Section 5.2 of 2365 [I-D.ietf-taps-minset]. 2367 o "Abort without delivering remaining data, causing an event 2368 informing the application on the other side" and "Abort without 2369 delivering remaining data, not causing an event informing the 2370 application on the other side": 2371 This is offered by the "Abort" action without promising that this 2372 is signaled to the other side. If it is, a "ConnectionError" 2373 Event will fire at the peer. 2375 o "Reliably transfer data, with congestion control", "Reliably 2376 transfer a message, with congestion control" and "Unreliably 2377 transfer a message": 2379 Reliability is controlled via the "Reliable Data Transfer 2380 (Message)" Message property. Transmitting data without delimiters 2381 is done by not using a Framer. The choice of congestion control 2382 is provided via the "Congestion control" property. 2384 o Configurable Message Reliability: 2385 The "Lifetime" Message Property implements a time-based way to 2386 configure message reliability. 2388 o "Ordered message delivery (potentially slower than unordered)" and 2389 "Unordered message delivery (potentially faster than ordered)": 2390 The two transport features are controlled via the Message property 2391 "Ordered". 2393 o Request not to delay the acknowledgement (SACK) of a message: 2394 Should the protocol support it, this is one of the transport 2395 features the transport system can use when an application uses the 2396 Capacity Profile Property with value "Low Latency/Interactive". 2398 o Receive data (with no message delimiting): 2399 "Received" Event without using a Deframer. 2401 o Receive a message: 2402 "Received" Event. Section 5.1 of [I-D.ietf-taps-minset] discusses 2403 how messages can be obtained from a bytestream in case of 2404 implementation over TCP. Here, this is dealt with by Framers and 2405 Deframers. 2407 o Information about partial message arrival: 2408 "ReceivedPartial" Event. 2410 o Notification of send failures: 2411 "Expired" and "SendError" Events. 2413 o Notification that the stack has no more user data to send: 2414 Applications can obtain this information via the "Sent" Event. 2416 o Notification to a receiver that a partial message delivery has 2417 been aborted: 2418 "ReceiveError" Event. 2420 Authors' Addresses 2421 Brian Trammell (editor) 2422 ETH Zurich 2423 Gloriastrasse 35 2424 8092 Zurich 2425 Switzerland 2427 Email: ietf@trammell.ch 2429 Michael Welzl (editor) 2430 University of Oslo 2431 PO Box 1080 Blindern 2432 0316 Oslo 2433 Norway 2435 Email: michawe@ifi.uio.no 2437 Theresa Enghardt 2438 TU Berlin 2439 Marchstrasse 23 2440 10587 Berlin 2441 Germany 2443 Email: theresa@inet.tu-berlin.de 2445 Godred Fairhurst 2446 University of Aberdeen 2447 Fraser Noble Building 2448 Aberdeen, AB24 3UE 2449 Scotland 2451 Email: gorry@erg.abdn.ac.uk 2452 URI: http://www.erg.abdn.ac.uk/ 2454 Mirja Kuehlewind 2455 ETH Zurich 2456 Gloriastrasse 35 2457 8092 Zurich 2458 Switzerland 2460 Email: mirja.kuehlewind@tik.ee.ethz.ch 2461 Colin Perkins 2462 University of Glasgow 2463 School of Computing Science 2464 Glasgow G12 8QQ 2465 United Kingdom 2467 Email: csp@csperkins.org 2469 Philipp S. Tiesel 2470 TU Berlin 2471 Marchstrasse 23 2472 10587 Berlin 2473 Germany 2475 Email: philipp@inet.tu-berlin.de 2477 Chris Wood 2478 Apple Inc. 2479 1 Infinite Loop 2480 Cupertino, California 95014 2481 United States of America 2483 Email: cawood@apple.com