idnits 2.17.00 (12 Aug 2021) /tmp/idnits31404/draft-trammell-post-sockets-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2016) is 2025 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-hamilton-quic-transport-protocol-00 == Outdated reference: A later version (-04) exists of draft-trammell-plus-statefulness-00 -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TAPS Working Group B. Trammell 3 Internet-Draft ETH Zurich 4 Intended status: Informational C. Perkins 5 Expires: April 30, 2017 University of Glasgow 6 T. Pauly 7 Apple Inc. 8 M. Kuehlewind 9 ETH Zurich 10 October 27, 2016 12 Post Sockets, An Abstract Programming Interface for the Transport Layer 13 draft-trammell-post-sockets-00 15 Abstract 17 This document describes Post Sockets, an asynchronous abstract 18 programming interface for the atomic transmission of objects in an 19 explicitly multipath environment. Post replaces connections with 20 long-lived associations between endpoints, with the possibility to 21 cache cryptographic state in order to reduce amortized connection 22 latency. We present this abstract interface as an illustration of 23 what is possible with present developments in transport protocols 24 when freed from the strictures of the current sockets API. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 30, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Abstractions and Terminology . . . . . . . . . . . . . . . . 5 62 2.1. Association . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2. Listener . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.3. Remote . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.4. Local . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.5. Path . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 2.6. Object . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.7. Stream . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 3. Abstract Programming Interface . . . . . . . . . . . . . . . 9 70 3.1. Active Association Creation . . . . . . . . . . . . . . . 10 71 3.2. Listener and Passive Association Creation . . . . . . . . 11 72 3.3. Sending Objects . . . . . . . . . . . . . . . . . . . . . 12 73 3.4. Receiving Objects . . . . . . . . . . . . . . . . . . . . 12 74 3.5. Creating and Destroying Streams . . . . . . . . . . . . . 13 75 3.6. Events . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 3.7. Paths and Path Properties . . . . . . . . . . . . . . . . 14 77 3.8. Address Resolution . . . . . . . . . . . . . . . . . . . 14 78 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 79 5. Informative References . . . . . . . . . . . . . . . . . . . 15 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 82 1. Introduction 84 The BSD Unix Sockets API's SOCK_STREAM abstraction, by bringing 85 network sockets into the UNIX programming model, allowing anyone who 86 knew how to write programs that dealt with sequential-access files to 87 also write network applications, was a revolution in simplicity. It 88 would not be an overstatement to say that this simple API is the 89 reason the Internet won the protocol wars of the 1980s. SOCK_STREAM 90 is tied to the Transmission Control Protocol (TCP), specified in 1981 91 [RFC0793]. TCP has scaled remarkably well over the past three and a 92 half decades, but its total ubiquity has hidden an uncomfortable 93 fact: the network is not really a file, and stream abstractions are 94 too simplistic for many modern application programming models. 96 In the meantime, the nature of Internet access is evolving. Many 97 end-user devices are connected to the Internet via multiple 98 interfaces, which suggests it is time to promote the "path" by which 99 a host is connected to a first-order object; we call this "path 100 primacy". 102 Implicit multipath communication is available for these multihomed 103 nodes in the present Internet architecture with the Multipath TCP 104 extension (MPTCP) [RFC6824]. Since many multihomed nodes are 105 connected to the Internet through access paths with widely different 106 properties with respect to bandwidth, latency and cost, adding 107 explicit path control to MPTCP's API would be useful in many 108 situations. Path primacy for cooperation with path elements is also 109 useful in single-homed architectures, such as the mechanism proposed 110 by the Path Layer UDP Substrate (PLUS) effort (see 111 [I-D.trammell-plus-statefulness] and 112 [I-D.trammell-plus-abstract-mech]). 114 Another trend straining the traditional layering of the transport 115 stack associated with the SOCK_STREAM interface is the widespread 116 interest in ubiquitous deployment of encryption to guarantee 117 confidentiality, authenticity, and integrity, in the face of 118 pervasive surveillance [RFC7258]. Layering the most widely deployed 119 encryption technology, Transport Layer Security (TLS), strictly atop 120 TCP (i.e., via a TLS library such as OpenSSL that uses the sockets 121 API) requires the encryption-layer handshake to happen after the 122 transport-layer handshake, which increases connection setup latency 123 on the order of one or two round-trip times, an unacceptable delay 124 for many applications. Integrating cryptographic state setup and 125 maintenance into the path abstraction naturally complements efforts 126 in new protocols (e.g. QUIC [I-D.hamilton-quic-transport-protocol]) 127 to mitigate this strict layering. 129 From these three starting points - more flexible abstraction, path 130 primacy, and encryption by default - we define the Post-Socket 131 Application Programming Interface (API), described in detail in this 132 work. Post is designed to be language, transport protocol, and 133 architecture independent, allowing applications to be written to a 134 common abstract interface, easily ported among different platforms, 135 and used even in environments where transport protocol selection may 136 be done dynamically, as proposed in the IETF's Transport Services 137 wotking group (see https://datatracker.ietf.org/wg/taps/charter). 139 Post replaces the traditional SOCK_STREAM abstraction with an Object 140 abstraction, which can be seen as a generalization of the Stream 141 Control Transmission Protocol's [RFC4960] SOCK_SEQPACKET service. 142 Objects can be small (e.g. messages in message-oriented protocols) or 143 large (e.g. an HTTP response containing header and body). It 144 replaces the notions of a socket address and connected socket with an 145 Association with a remote endpoint via set of Paths. Implementation 146 and wire format for transport protocol(s) implementing the Post API 147 are explicitly out of scope for this work; these abstractions need 148 not map directly to implementation-level concepts, and indeed with 149 various amounts of shimming and glue could be implemented with 150 varying success atop any sufficiently flexible transport protocol. 152 For compatibility with situations where only strictly stream-oriented 153 transport protocols are available, applications with data streams 154 that cannot be easily split into Objects at the sender, and and for 155 easy porting of the great deal of existing stream-oriented 156 application code to Post, Post also provides a SOCK_STREAM compatible 157 abstraction, unimaginatively named Stream. 159 The key features of Post as compared with the existing sockets API 160 are: 162 o Explicit Object orientation, with framing and atomicity guarantees 163 for Object transmission. 165 o Asynchronous reception, allowing all receiver-side interactions to 166 be event-driven. 168 o Explicit support for multipath transport protocols and network 169 architectures. 171 o Long-lived Associations, whose lifetimes may not be bound to 172 underlying transport connections. This allows associations to 173 cache state and cryptographic key material to enable fast (0-rtt) 174 resumption of communication. 176 This work is the synthesis of many years of Internet transport 177 protocol research and development. It is heavily inspired by 178 concepts from the Stream Control Transmission Protocol (SCTP) 179 [RFC4960], TCP Minion [I-D.iyengar-minion-protocol], 180 MinimaLT[MinimaLT], and various bulk object transports. 182 We present Post Sockets as an illustration of what is possible with 183 present developments in transport protocols when freed from the 184 strictures of the current sockets API. While much of the work for 185 building parts of the protocols needed to implement Post are already 186 ongoing in other IETF working groups (e.g. TAPS, MPTCP, QUIC, TLS), 187 we argue that an abstract programming interface unifying access all 188 these efforts is necessary to fully exploit their potential. 190 2. Abstractions and Terminology 192 gratuitously colorful SVG goes here; see slide six of 194 https://www.ietf.org/proceedings/96/slides/slides-96-taps-2.pdf 196 in the meantime 198 Figure 1: Abstractions and relationships in Post Sockets 200 Post is based on a small set of abstractions, the relationships among 201 which are shown in Figure Figure 1 and detailed in this section. 203 2.1. Association 205 An Association is a container for all the state necessary for a local 206 endpoint to communicate with a remote endpoint in an explicitly 207 multipath environment. It contains a set of Paths, certificate(s) 208 for identifying the remote endpoint, certificate(s) and key(s) for 209 identifying the local endpoint to the remote endpoint, and any cached 210 cryptographic state for the communication to the remote endpoint. An 211 Association may have one or more Streams active at any given time. 212 Objects are sent to Associations, as well. 214 Note that, in contrast to current SOCK_STREAM sockets, Associations 215 are meant to be relatively long-lived. The lifetime of an 216 Association is not bound to the lifetime of any transport-layer 217 connection between the two endpoints; connections may be opened or 218 closed as necessary to support the Streams and Object transmissions 219 required by the application, and the application need not be bothered 220 with the underlying connectivity state unless this is important to 221 the application's semantics. 223 Paths may be dynamically added or removed from an association, as 224 well, as connectivity between the endpoints changes. Cryptographic 225 identifiers and state for endpoints may also be added and removed as 226 necessary due to certificate lifetimes, key rollover, and revocation. 228 2.2. Listener 230 In many applications, there is a distinction between the active 231 opener (or connection initiator, often a client), and the passive 232 opener (often a server). A Listener represents an endpoint's 233 willingness to start Associations in this passive opener/server role. 234 It is, in essence, a one-sided, Path-less Association from which 235 fully-formed Associations can be created. 237 Listeners work very much like sockets on which the listen(2) call has 238 been called in the SOCK_STREAM API. 240 2.3. Remote 242 A Remote represents all the information required to establish and 243 maintain a connection with the far end of an Association: network- 244 layer address, transport-layer port, information about public keys or 245 certificate authorities used to identify the remote on connection 246 establishment, etc. Each Association is associated with a single 247 Remote, either explicitly by the application (when created by active 248 open) or by the Listener (when created by passive open). The 249 resolution of Remotes from higher-layer information (URIs, hostnames) 250 is architecture-dependent. 252 2.4. Local 254 A Local represents all the information about the local endpoint 255 necessary to establish an Association or a Listener: interface and 256 port designators, as well as certificates and associated private 257 keys. 259 2.5. Path 261 A Path represents a local and remote endpoint address, an optional 262 set of intermediary path elements between the local and remote 263 endpoint addresses, and a set of properties associated with the path. 265 The set of available properties is a function of the underlying 266 network-layer protocols used to expose the properties to the 267 endpoint. However, the following core properties are generally 268 useful for applications and transport layer protocols to choose among 269 paths for specific Objects: 271 o Maximum Transmission Unit (MTU): the maximum size of an Object's 272 payload (subtracting transport, network, and link layer overhead) 273 which will likely fit into a single frame. Derived from signals 274 sent by path elements, where available, and/or path MTU discovery 275 processes run by the transport layer. 277 o Latency Expectation: expected one-way delay along the Path. 278 Generally provided by inline measurements performed by the 279 transport layer, as opposed to signaled by path elements. 281 o Loss Probability Expectation: expected probability of a loss of 282 any given single frame along the Path. Generally provided by 283 inline measurements performed by the transport layer, as opposed 284 to signaled by path elements. 286 o Available Data Rate Expectation: expected maximum data rate along 287 the Path. May be derived from passive measurements by the 288 transport layer, or from signals from path elements. 290 o Reserved Data Rate: Committed, reserved data rate for the given 291 Association along the Path. Requires a bandwidth reservation 292 service in the underlying transport and network layer protocol. 294 o Path Element Membership: Identifiers for some or all nodes along 295 the path, depending on the capabilities of the underlying network 296 layer protocol to provide this. 298 Path properties are generally read-only. MTU is a property of the 299 underlying link-layer technology on each link in the path; latency, 300 loss, and rate expectations are dynamic properties of the network 301 configuration and network traffic conditions; path element membership 302 is a function of network topology. In an explicitly multipath 303 architecture, application and transport layer requirements are met by 304 having multiple paths with different properties to select from. Post 305 can also provide signaling to the path, but this signaling is derived 306 from information provided to the Object abstraction, below. 308 Note that information about the path and signaling to path elements 309 could be provided by a facility such as PLUS 310 [I-D.trammell-plus-abstract-mech]. 312 2.6. Object 314 Post provides two ways to send data over an Association. We start 315 with the Object abstraction, as a fundamental insight behind the 316 interface is that most applications fundamentally deal in object 317 transport. 319 An Object is an atomic unit of communication between applications; or 320 in other words, an ordered collection of bytes B0..Bm, such that 321 every byte Bn depends on every other byte in the Object. An object 322 that cannot be delivered in its entirety within the constraints of 323 the network connectivity and the requirements of the application is 324 not delivered at all. 326 Objects can represent both relatively small structures, such as 327 messages in application-layer protocols built around datagram or 328 message exchange, as well as relatively large structures, such files 329 of arbitrary size in a filesystem. Objects larger than the MTU on 330 the Path on which they are sent will be segmented into multiple 331 frames. Multiple objects that will fit into a single frame may be 332 concatenated into one frame. There is no preference for transmitting 333 the multiple frames for a given Object in any particular order, or by 334 default, that objects will be delivered in the order sent by the 335 application. This implies that both the sending and receiving 336 endpoint, whether in the application layer or the transport layer, 337 must guarantee storage for the full size of an object. 339 Three object properties allow applications fine control ordering and 340 reliability requirements in line with application semantics. An 341 Object may have a "lifetime" - a wallclock duration before which the 342 object must be available to the application layer at the remote end. 343 If a lifetime cannot be met, the object is discarded as soon as 344 possible; therefore, Objects with lifetimes are implicitly sent non- 345 reliably, and lifetimes are used to prioritize Object delivery. 346 Lifetimes may be signaled to path elements by the underlying 347 transport, so that path elements that realize a lifetime cannot be 348 met can discard frames containing the object instead of forwarding 349 them. 351 Second, Objects may have a "niceness" - a category in an unbounded 352 hierarchy most naturally represented as a non-negative integer. By 353 default, Objects are in niceness class 0, or highest priority. 354 Niceness class 1 Objects will yield to niceness class 0 objects, 355 class 2 to class 1, and so on. Niceness may be translated to a 356 priority signal for exposure to path elements (e.g. DSCP codepoint) 357 to allow prioritization along the path as well as at the sender and 358 receiver. This inversion of normal schemes for expressing priority 359 has a convenient property: priority increases as both niceness and 360 deadline decrease. 362 An object may have both a niceness and a lifetime - objects with 363 higher niceness classes will yield to lower classes if resource 364 constraints mean only one can meet the lifetime. 366 Third, an Object may have "antecedents" - other Objects on which it 367 depends, which must be delivered before it (the "successor") is 368 delivered. The sending transport uses deadlines, niceness, and 369 antecedents, along with information about the properties of the Paths 370 available, to determine when to send which object down which Path. 372 When an application has hard semantic requirements that all the 373 frames of a given object be sent down a given Path or Paths, these 374 hard constraints can also be expressed by the application. 376 After calling the send function, the application can register event 377 handlers to be informed of the transmission status of the object; the 378 object can either be acknowledged (i.e., it has been received in full 379 by the remote endpoint) or expired (its lifetime ran out before it 380 was acknowledged). 382 2.7. Stream 384 The Stream abstraction is provided for two reasons. First, since it 385 is the most like the existing SOCK_STREAM interface, it is the 386 simplest abstraction to be used by applications ported to Post to 387 take advantages of Path primacy. Second, some environments have 388 connectivity so impaired (by local network operation policy and/or 389 accidental middlebox interference) that only stream- based transport 390 protocols are available, and applications should have the option to 391 use streams directly in these situations. 393 A Stream is a sequence of bytes B0 .. Bm such that the reception (and 394 delivery to the receiving application of) Bn always depends on Bn-1. 395 This property is inherited from the BSD UNIX file abstraction, which 396 in turn inherited it from the physical limitations of sequential 397 access media (stacks of punch cards, paper and/or magnetic tape). 399 A Stream is bound to an Association. Writing a byte to the stream 400 will cause it to be received by the remote, in order, or will cause 401 an error condition and termination of the stream if the byte cannot 402 be delivered. Due to the strong sequential dependence on a stream, 403 streams must always be reliable and ordered. If frames containing 404 Stream data are lost, these must be retransmitted or reconstructed 405 using an error correction technique. If frames containing Stream 406 data arrive out of order, the remote end must buffer them until the 407 unordered frames are received and reassembled. 409 As with Objects, Streams may have a niceness for prioritization. 410 When mixing Stream and Object data on the same Path in an 411 association, the niceness classes for Streams and Objects are 412 interleaved; e.g. niceness 2 Stream frames will yield to niceness 1 413 Object frames. 415 The underlying transport protocol may make whatever use of the Paths 416 and known properties of those Paths it sees fit when transporting a 417 Stream. 419 3. Abstract Programming Interface 421 We now turn to the design of an abstract programming interface to 422 provide a simple interface to Post's abstractions, constrained by the 423 following design principles: 425 o Flexibility is paramount. So is simplicity. Applications must be 426 given as many controls and as much information as they may need, 427 but they must be able to ignore controls and information 428 irrelevant to their operation. This implies that the "default" 429 interface must be no more complicated than BSD sockets, and must 430 do something reasonable. 432 o A new API cannot be bound to a single transport protocol and 433 expect wide deployment. As the API is transport-independent and 434 may support runtime transport selection, it must impose the 435 minimum possible set of constraints on its underlying transports, 436 though some API features may require underlying transport features 437 to work optimally. It must be possible to implement Post over 438 vanilla TCP in the present Internet architecture. 440 o Reception is an inherently asynchronous activity. While the API 441 is designed to be as platform-independent as possible, one key 442 insight it is based on is that an object receiver's behavior in a 443 packet-switched network is inherently asynchronous, driven by the 444 receipt of packets, and that this asynchronicity must be reflected 445 in the API. The actual implementation of receive and event 446 callbacks will need to be aligned to the method a given platform 447 provides for asynchronous I/O. 449 The API we define consists of three classes (listener, association, 450 and stream), four entry points (listen(), associate(), send(), and 451 open_stream()) and a set of callbacks for handling events at each 452 endpoint. The details are given in the subsections below. 454 3.1. Active Association Creation 456 Associations can be created two ways: actively by a connection 457 initiator, and passively by a Listener that accepts a connection. 458 Connection initiation uses the associate() entry point: 460 association = associate(local, remote, receive_handler) 462 where: 464 o local: a resolved Local (see Section 3.8) describing the local 465 identity and interface(s) to use 467 o remote: a resolved Remote (see Section 3.8) to associate with 469 o receive_handler: a callback to be invoked when new objects are 470 received; see Section 3.4 472 The returned association has the following additional properties: 474 o paths: a set of Paths that the Association can currently use to 475 transport Objects. When the underlying transport connection is 476 closed, this set will be empty. For explicitly multipath 477 architectures and transports, this set may change dynamically 478 during the lifetime of an association, even while it remains 479 connected. 481 Since the existence of an association does not necessarily imply 482 current connection state at both ends of the Association, these 483 objects are durable, and can be cached, migrated, and restored, as 484 long as the mappings to their event handlers are stable. An attempts 485 to send an object or open a stream on a dormant, previously actively- 486 opened association will cause the underlying transport connection 487 state to be resumed. 489 3.2. Listener and Passive Association Creation 491 In order to accept new Association requests from clients, a server 492 must create a Listener object, using the listen() entry point: 494 listener = listen(local, accept_handler) 496 where: 498 o local: resolved Local (see Section 3.8) describing the local 499 identity and interface(s) to use for Associations created by this 500 listener. 502 o accept_handler: callback to be invoked each time an association is 503 requested by a remote, to finalize setting the association up. 504 Platforms may provide a default here for supporting synchronous 505 association request handling via an object queue. 507 The accept_handler has the following prototype: 509 accepted = accept_handler(listener, local, remote) 511 where: 513 o local: a resolved Local on which the association request was 514 received. 516 o remote: a resolved Remote from which the association request was 517 received. 519 o accepted: flag, true if the handler decided to accept the request, 520 false otherwise. 522 The accept_handler() calls the accept() entry point to finally create 523 the association: 525 association = accept(listener, local, remote, receive_handler) 527 3.3. Sending Objects 529 Objects are sent using the send() entry point: 531 send(association, bytes, [lifetime], [niceness], [oid], 532 [antecedent_oids], [paths])} 534 where: 536 o association: the association to send the object on 538 o bytes: sequence of bytes making up the object. For platforms 539 without bounded byte arrays, this may be implemented as a pointer 540 and a length. 542 o lifetime: lifetime of the object in milliseconds. This parameter 543 is optional and defaults to infinity (for fully reliable object 544 transport). 546 o niceness: the object's niceness class. This parameter is optional 547 and defaults to zero (for lowest niceness / highest priority) 549 o oid: opaque identifier for an object, assigned by the application. 550 Used to refer to this object as a subsequently sent object's 551 antecedent, or in an ack or expired handler (see Section 3.6). 552 Optional, defaults to null. 554 o antecedent_oids: set of object identifiers on which this object 555 depends and which must be sent before this object. Optional, 556 defaults to empty, meaning this object has no antecedent 557 constraints. 559 o paths: set of paths, as a subset of those available to the 560 association, to explicitly use for this object. Optional, 561 defaults to empty, meaning all paths are acceptable. 563 Calls to send are non-blocking; a synchronous send which blocks on 564 remote acknowledgment or expiry of an object can be implemented by a 565 call to send() followed by a wait on the ack or expired events (see 566 Section 3.6). 568 3.4. Receiving Objects 570 An application receives objects via its receive_handler callback, 571 registered at association creation time. This callback has the 572 following prototype: 574 receive_handler(association, bytes) 576 where: - association: the association the object was received from. 577 - bytes: the sequence of bytes making up the object. 579 For ease of porting synchronous datagram applications, 580 implementations may make a default receive handler available, which 581 allows messages to be synchronously polled from a per-association 582 object queue. If this default is available, the entry point for the 583 polling call is: 585 bytes = receive_next(association) 587 3.5. Creating and Destroying Streams 589 A stream may be created on an association via the open_stream() entry 590 point: 592 stream = open_stream(association, [sid]) 594 where: 596 o association: the association to open the stream on 598 o sid: opaque identifier for a stream. For transport protocols 599 which do not support multiple streaming, this argument has no 600 effect. 602 A stream with a given sid must be opened by both sides before it can 603 be used. 605 The stream object returned should act like a file descriptor or 606 bidirectional I/O object, according to the conventions of the 607 platform implementing Post. 609 3.6. Events 611 Message reception is a specific case of an event that can occur on an 612 association. Other events are also available, and the application 613 can register event handlers for each of these. Event handlers are 614 registered via the handle() entry point: 616 handle(association, event, handler) or 618 handle(oid, event, handler) 620 where 621 o association: the association to register a handler on, or 623 o oid: the object identifier to register a handler on 625 o event: an identifier of the event to register a handler on 627 o handler: a callback to be invoked when the event occurs, or null 628 if the event should be ignored. 630 The following events are supported; every event handler takes the 631 association on which it is registered as well as any additional 632 arguments listed: 634 o receive (bytes): an object has been received 636 o path_up (path): a path is newly available 638 o path_down (path): a path is no longer available 640 o dormant: no more paths are available, the association is now 641 dormant, and the connection will need to be resumed if further 642 objects are to be sent 644 o ack (oid): an object was successfully received by the remote 646 o expired (oid): an object expired before being sent to the remote 648 Handlers for the ack and expired events can be registered on an 649 association (in which case they are called for all objects sent on 650 the association) or on an oid (in which case they are only called for 651 the oid). 653 3.7. Paths and Path Properties 655 As defined in Section 2.5, the properties of a path include both the 656 addresses of elements along the path as well as measurement-derived 657 latency and capacity characteristics. The path_up and path_down 658 events provide access to information about the paths available via 659 the path argument to the event handler. This argument encapsulates 660 these properties in a platform and transport-specific way, depending 661 on the availability of information about the path. 663 3.8. Address Resolution 665 Address resolution turns the name of a Remote into a resolved Remote 666 object, which encapsulates all the information needed to connect 667 (address, certificate parameters, cached cryptographic state, etc.); 668 and an interface identifier on a local system to information needed 669 to connect. Remote and local resolvers have the following entry 670 points: 672 remote = resolve(endpoint_name, configuration) 674 local = resolve_local(endpoint_name, configuration) 676 where: 678 o endpoint_name: a name identifying the remote or local endpoint, 679 including port 681 o configuration: a platform-specific configuration object for 682 configuring certificates, name resolution contexts, cached 683 cryptographic state, etc. 685 4. Acknowledgments 687 Many thanks to Laurent Chuat and Jason Lee at the Network Security 688 Group at ETH Zurich for contributions to the initial design of Post 689 Sockets. 691 This work is partially supported by the European Commission under 692 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 693 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 694 for Education, Research, and Innovation under contract no. 15.0268. 695 This support does not imply endorsement. 697 5. Informative References 699 [I-D.hamilton-quic-transport-protocol] 700 Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC: 701 A UDP-Based Multiplexed and Secure Transport", draft- 702 hamilton-quic-transport-protocol-00 (work in progress), 703 July 2016. 705 [I-D.iyengar-minion-protocol] 706 Jana, J., Cheshire, S., and J. Graessley, "Minion - Wire 707 Protocol", draft-iyengar-minion-protocol-02 (work in 708 progress), October 2013. 710 [I-D.trammell-plus-abstract-mech] 711 Trammell, B., "Abstract Mechanisms for a Cooperative Path 712 Layer under Endpoint Control", draft-trammell-plus- 713 abstract-mech-00 (work in progress), September 2016. 715 [I-D.trammell-plus-statefulness] 716 Kuehlewind, M., Trammell, B., and J. Hildebrand, 717 "Transport-Independent Path Layer State Management", 718 draft-trammell-plus-statefulness-00 (work in progress), 719 October 2016. 721 [MinimaLT] 722 Petullo, W., Zhang, X., Solworth, J., Bernstein, D., and 723 T. Lange, "MinimaLT, Minimal-latency Networking Through 724 Better Security", May 2013. 726 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 727 RFC 793, DOI 10.17487/RFC0793, September 1981, 728 . 730 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 731 RFC 4960, DOI 10.17487/RFC4960, September 2007, 732 . 734 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 735 "TCP Extensions for Multipath Operation with Multiple 736 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 737 . 739 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 740 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 741 2014, . 743 Authors' Addresses 745 Brian Trammell 746 ETH Zurich 747 Gloriastrasse 35 748 8092 Zurich 749 Switzerland 751 Email: ietf@trammell.ch 753 Colin Perkins 754 University of Glasgow 755 School of Computing Science 756 Glasgow G12 8QQ 757 United Kingdom 759 Email: csp@cperkins.net 760 Tommy Pauly 761 Apple Inc. 762 1 Infinite Loop 763 Cupertino, California 95014 764 United States of America 766 Email: tpauly@apple.com 768 Mirja Kuehlewind 769 ETH Zurich 770 Gloriastrasse 35 771 8092 Zurich 772 Switzerland 774 Email: mirja.kuehlewind@tik.ee.ethz.ch