TAPS Working Group B. Trammell Internet-Draft ETH Zurich Intended status: Informational C. Perkins Expires: April 30, 2017 University of Glasgow T. Pauly Apple Inc. M. Kuehlewind ETH Zurich October 27, 2016 Post Sockets, An Abstract Programming Interface for the Transport Layer draft-trammell-post-sockets-00 Abstract This document describes Post Sockets, an asynchronous abstract programming interface for the atomic transmission of objects in an explicitly multipath environment. Post replaces connections with long-lived associations between endpoints, with the possibility to cache cryptographic state in order to reduce amortized connection latency. We present this abstract interface as an illustration of what is possible with present developments in transport protocols when freed from the strictures of the current sockets API. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 30, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. Trammell, et al. Expires April 30, 2017 [Page 1] Internet-Draft Post Sockets October 2016 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Abstractions and Terminology . . . . . . . . . . . . . . . . 5 2.1. Association . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Listener . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Remote . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Local . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.5. Path . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.6. Object . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.7. Stream . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Abstract Programming Interface . . . . . . . . . . . . . . . 9 3.1. Active Association Creation . . . . . . . . . . . . . . . 10 3.2. Listener and Passive Association Creation . . . . . . . . 11 3.3. Sending Objects . . . . . . . . . . . . . . . . . . . . . 12 3.4. Receiving Objects . . . . . . . . . . . . . . . . . . . . 12 3.5. Creating and Destroying Streams . . . . . . . . . . . . . 13 3.6. Events . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.7. Paths and Path Properties . . . . . . . . . . . . . . . . 14 3.8. Address Resolution . . . . . . . . . . . . . . . . . . . 14 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 5. Informative References . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction The BSD Unix Sockets API's SOCK_STREAM abstraction, by bringing network sockets into the UNIX programming model, allowing anyone who knew how to write programs that dealt with sequential-access files to also write network applications, was a revolution in simplicity. It would not be an overstatement to say that this simple API is the reason the Internet won the protocol wars of the 1980s. SOCK_STREAM is tied to the Transmission Control Protocol (TCP), specified in 1981 [RFC0793]. TCP has scaled remarkably well over the past three and a half decades, but its total ubiquity has hidden an uncomfortable fact: the network is not really a file, and stream abstractions are too simplistic for many modern application programming models. Trammell, et al. Expires April 30, 2017 [Page 2] Internet-Draft Post Sockets October 2016 In the meantime, the nature of Internet access is evolving. Many end-user devices are connected to the Internet via multiple interfaces, which suggests it is time to promote the "path" by which a host is connected to a first-order object; we call this "path primacy". Implicit multipath communication is available for these multihomed nodes in the present Internet architecture with the Multipath TCP extension (MPTCP) [RFC6824]. Since many multihomed nodes are connected to the Internet through access paths with widely different properties with respect to bandwidth, latency and cost, adding explicit path control to MPTCP's API would be useful in many situations. Path primacy for cooperation with path elements is also useful in single-homed architectures, such as the mechanism proposed by the Path Layer UDP Substrate (PLUS) effort (see [I-D.trammell-plus-statefulness] and [I-D.trammell-plus-abstract-mech]). Another trend straining the traditional layering of the transport stack associated with the SOCK_STREAM interface is the widespread interest in ubiquitous deployment of encryption to guarantee confidentiality, authenticity, and integrity, in the face of pervasive surveillance [RFC7258]. Layering the most widely deployed encryption technology, Transport Layer Security (TLS), strictly atop TCP (i.e., via a TLS library such as OpenSSL that uses the sockets API) requires the encryption-layer handshake to happen after the transport-layer handshake, which increases connection setup latency on the order of one or two round-trip times, an unacceptable delay for many applications. Integrating cryptographic state setup and maintenance into the path abstraction naturally complements efforts in new protocols (e.g. QUIC [I-D.hamilton-quic-transport-protocol]) to mitigate this strict layering. From these three starting points - more flexible abstraction, path primacy, and encryption by default - we define the Post-Socket Application Programming Interface (API), described in detail in this work. Post is designed to be language, transport protocol, and architecture independent, allowing applications to be written to a common abstract interface, easily ported among different platforms, and used even in environments where transport protocol selection may be done dynamically, as proposed in the IETF's Transport Services wotking group (see https://datatracker.ietf.org/wg/taps/charter). Post replaces the traditional SOCK_STREAM abstraction with an Object abstraction, which can be seen as a generalization of the Stream Control Transmission Protocol's [RFC4960] SOCK_SEQPACKET service. Objects can be small (e.g. messages in message-oriented protocols) or large (e.g. an HTTP response containing header and body). It Trammell, et al. Expires April 30, 2017 [Page 3] Internet-Draft Post Sockets October 2016 replaces the notions of a socket address and connected socket with an Association with a remote endpoint via set of Paths. Implementation and wire format for transport protocol(s) implementing the Post API are explicitly out of scope for this work; these abstractions need not map directly to implementation-level concepts, and indeed with various amounts of shimming and glue could be implemented with varying success atop any sufficiently flexible transport protocol. For compatibility with situations where only strictly stream-oriented transport protocols are available, applications with data streams that cannot be easily split into Objects at the sender, and and for easy porting of the great deal of existing stream-oriented application code to Post, Post also provides a SOCK_STREAM compatible abstraction, unimaginatively named Stream. The key features of Post as compared with the existing sockets API are: o Explicit Object orientation, with framing and atomicity guarantees for Object transmission. o Asynchronous reception, allowing all receiver-side interactions to be event-driven. o Explicit support for multipath transport protocols and network architectures. o Long-lived Associations, whose lifetimes may not be bound to underlying transport connections. This allows associations to cache state and cryptographic key material to enable fast (0-rtt) resumption of communication. This work is the synthesis of many years of Internet transport protocol research and development. It is heavily inspired by concepts from the Stream Control Transmission Protocol (SCTP) [RFC4960], TCP Minion [I-D.iyengar-minion-protocol], MinimaLT[MinimaLT], and various bulk object transports. We present Post Sockets as an illustration of what is possible with present developments in transport protocols when freed from the strictures of the current sockets API. While much of the work for building parts of the protocols needed to implement Post are already ongoing in other IETF working groups (e.g. TAPS, MPTCP, QUIC, TLS), we argue that an abstract programming interface unifying access all these efforts is necessary to fully exploit their potential. Trammell, et al. Expires April 30, 2017 [Page 4] Internet-Draft Post Sockets October 2016 2. Abstractions and Terminology gratuitously colorful SVG goes here; see slide six of https://www.ietf.org/proceedings/96/slides/slides-96-taps-2.pdf in the meantime Figure 1: Abstractions and relationships in Post Sockets Post is based on a small set of abstractions, the relationships among which are shown in Figure Figure 1 and detailed in this section. 2.1. Association An Association is a container for all the state necessary for a local endpoint to communicate with a remote endpoint in an explicitly multipath environment. It contains a set of Paths, certificate(s) for identifying the remote endpoint, certificate(s) and key(s) for identifying the local endpoint to the remote endpoint, and any cached cryptographic state for the communication to the remote endpoint. An Association may have one or more Streams active at any given time. Objects are sent to Associations, as well. Note that, in contrast to current SOCK_STREAM sockets, Associations are meant to be relatively long-lived. The lifetime of an Association is not bound to the lifetime of any transport-layer connection between the two endpoints; connections may be opened or closed as necessary to support the Streams and Object transmissions required by the application, and the application need not be bothered with the underlying connectivity state unless this is important to the application's semantics. Paths may be dynamically added or removed from an association, as well, as connectivity between the endpoints changes. Cryptographic identifiers and state for endpoints may also be added and removed as necessary due to certificate lifetimes, key rollover, and revocation. 2.2. Listener In many applications, there is a distinction between the active opener (or connection initiator, often a client), and the passive opener (often a server). A Listener represents an endpoint's willingness to start Associations in this passive opener/server role. It is, in essence, a one-sided, Path-less Association from which fully-formed Associations can be created. Trammell, et al. Expires April 30, 2017 [Page 5] Internet-Draft Post Sockets October 2016 Listeners work very much like sockets on which the listen(2) call has been called in the SOCK_STREAM API. 2.3. Remote A Remote represents all the information required to establish and maintain a connection with the far end of an Association: network- layer address, transport-layer port, information about public keys or certificate authorities used to identify the remote on connection establishment, etc. Each Association is associated with a single Remote, either explicitly by the application (when created by active open) or by the Listener (when created by passive open). The resolution of Remotes from higher-layer information (URIs, hostnames) is architecture-dependent. 2.4. Local A Local represents all the information about the local endpoint necessary to establish an Association or a Listener: interface and port designators, as well as certificates and associated private keys. 2.5. Path A Path represents a local and remote endpoint address, an optional set of intermediary path elements between the local and remote endpoint addresses, and a set of properties associated with the path. The set of available properties is a function of the underlying network-layer protocols used to expose the properties to the endpoint. However, the following core properties are generally useful for applications and transport layer protocols to choose among paths for specific Objects: o Maximum Transmission Unit (MTU): the maximum size of an Object's payload (subtracting transport, network, and link layer overhead) which will likely fit into a single frame. Derived from signals sent by path elements, where available, and/or path MTU discovery processes run by the transport layer. o Latency Expectation: expected one-way delay along the Path. Generally provided by inline measurements performed by the transport layer, as opposed to signaled by path elements. o Loss Probability Expectation: expected probability of a loss of any given single frame along the Path. Generally provided by inline measurements performed by the transport layer, as opposed to signaled by path elements. Trammell, et al. Expires April 30, 2017 [Page 6] Internet-Draft Post Sockets October 2016 o Available Data Rate Expectation: expected maximum data rate along the Path. May be derived from passive measurements by the transport layer, or from signals from path elements. o Reserved Data Rate: Committed, reserved data rate for the given Association along the Path. Requires a bandwidth reservation service in the underlying transport and network layer protocol. o Path Element Membership: Identifiers for some or all nodes along the path, depending on the capabilities of the underlying network layer protocol to provide this. Path properties are generally read-only. MTU is a property of the underlying link-layer technology on each link in the path; latency, loss, and rate expectations are dynamic properties of the network configuration and network traffic conditions; path element membership is a function of network topology. In an explicitly multipath architecture, application and transport layer requirements are met by having multiple paths with different properties to select from. Post can also provide signaling to the path, but this signaling is derived from information provided to the Object abstraction, below. Note that information about the path and signaling to path elements could be provided by a facility such as PLUS [I-D.trammell-plus-abstract-mech]. 2.6. Object Post provides two ways to send data over an Association. We start with the Object abstraction, as a fundamental insight behind the interface is that most applications fundamentally deal in object transport. An Object is an atomic unit of communication between applications; or in other words, an ordered collection of bytes B0..Bm, such that every byte Bn depends on every other byte in the Object. An object that cannot be delivered in its entirety within the constraints of the network connectivity and the requirements of the application is not delivered at all. Objects can represent both relatively small structures, such as messages in application-layer protocols built around datagram or message exchange, as well as relatively large structures, such files of arbitrary size in a filesystem. Objects larger than the MTU on the Path on which they are sent will be segmented into multiple frames. Multiple objects that will fit into a single frame may be concatenated into one frame. There is no preference for transmitting the multiple frames for a given Object in any particular order, or by Trammell, et al. Expires April 30, 2017 [Page 7] Internet-Draft Post Sockets October 2016 default, that objects will be delivered in the order sent by the application. This implies that both the sending and receiving endpoint, whether in the application layer or the transport layer, must guarantee storage for the full size of an object. Three object properties allow applications fine control ordering and reliability requirements in line with application semantics. An Object may have a "lifetime" - a wallclock duration before which the object must be available to the application layer at the remote end. If a lifetime cannot be met, the object is discarded as soon as possible; therefore, Objects with lifetimes are implicitly sent non- reliably, and lifetimes are used to prioritize Object delivery. Lifetimes may be signaled to path elements by the underlying transport, so that path elements that realize a lifetime cannot be met can discard frames containing the object instead of forwarding them. Second, Objects may have a "niceness" - a category in an unbounded hierarchy most naturally represented as a non-negative integer. By default, Objects are in niceness class 0, or highest priority. Niceness class 1 Objects will yield to niceness class 0 objects, class 2 to class 1, and so on. Niceness may be translated to a priority signal for exposure to path elements (e.g. DSCP codepoint) to allow prioritization along the path as well as at the sender and receiver. This inversion of normal schemes for expressing priority has a convenient property: priority increases as both niceness and deadline decrease. An object may have both a niceness and a lifetime - objects with higher niceness classes will yield to lower classes if resource constraints mean only one can meet the lifetime. Third, an Object may have "antecedents" - other Objects on which it depends, which must be delivered before it (the "successor") is delivered. The sending transport uses deadlines, niceness, and antecedents, along with information about the properties of the Paths available, to determine when to send which object down which Path. When an application has hard semantic requirements that all the frames of a given object be sent down a given Path or Paths, these hard constraints can also be expressed by the application. After calling the send function, the application can register event handlers to be informed of the transmission status of the object; the object can either be acknowledged (i.e., it has been received in full by the remote endpoint) or expired (its lifetime ran out before it was acknowledged). Trammell, et al. Expires April 30, 2017 [Page 8] Internet-Draft Post Sockets October 2016 2.7. Stream The Stream abstraction is provided for two reasons. First, since it is the most like the existing SOCK_STREAM interface, it is the simplest abstraction to be used by applications ported to Post to take advantages of Path primacy. Second, some environments have connectivity so impaired (by local network operation policy and/or accidental middlebox interference) that only stream- based transport protocols are available, and applications should have the option to use streams directly in these situations. A Stream is a sequence of bytes B0 .. Bm such that the reception (and delivery to the receiving application of) Bn always depends on Bn-1. This property is inherited from the BSD UNIX file abstraction, which in turn inherited it from the physical limitations of sequential access media (stacks of punch cards, paper and/or magnetic tape). A Stream is bound to an Association. Writing a byte to the stream will cause it to be received by the remote, in order, or will cause an error condition and termination of the stream if the byte cannot be delivered. Due to the strong sequential dependence on a stream, streams must always be reliable and ordered. If frames containing Stream data are lost, these must be retransmitted or reconstructed using an error correction technique. If frames containing Stream data arrive out of order, the remote end must buffer them until the unordered frames are received and reassembled. As with Objects, Streams may have a niceness for prioritization. When mixing Stream and Object data on the same Path in an association, the niceness classes for Streams and Objects are interleaved; e.g. niceness 2 Stream frames will yield to niceness 1 Object frames. The underlying transport protocol may make whatever use of the Paths and known properties of those Paths it sees fit when transporting a Stream. 3. Abstract Programming Interface We now turn to the design of an abstract programming interface to provide a simple interface to Post's abstractions, constrained by the following design principles: o Flexibility is paramount. So is simplicity. Applications must be given as many controls and as much information as they may need, but they must be able to ignore controls and information irrelevant to their operation. This implies that the "default" Trammell, et al. Expires April 30, 2017 [Page 9] Internet-Draft Post Sockets October 2016 interface must be no more complicated than BSD sockets, and must do something reasonable. o A new API cannot be bound to a single transport protocol and expect wide deployment. As the API is transport-independent and may support runtime transport selection, it must impose the minimum possible set of constraints on its underlying transports, though some API features may require underlying transport features to work optimally. It must be possible to implement Post over vanilla TCP in the present Internet architecture. o Reception is an inherently asynchronous activity. While the API is designed to be as platform-independent as possible, one key insight it is based on is that an object receiver's behavior in a packet-switched network is inherently asynchronous, driven by the receipt of packets, and that this asynchronicity must be reflected in the API. The actual implementation of receive and event callbacks will need to be aligned to the method a given platform provides for asynchronous I/O. The API we define consists of three classes (listener, association, and stream), four entry points (listen(), associate(), send(), and open_stream()) and a set of callbacks for handling events at each endpoint. The details are given in the subsections below. 3.1. Active Association Creation Associations can be created two ways: actively by a connection initiator, and passively by a Listener that accepts a connection. Connection initiation uses the associate() entry point: association = associate(local, remote, receive_handler) where: o local: a resolved Local (see Section 3.8) describing the local identity and interface(s) to use o remote: a resolved Remote (see Section 3.8) to associate with o receive_handler: a callback to be invoked when new objects are received; see Section 3.4 The returned association has the following additional properties: o paths: a set of Paths that the Association can currently use to transport Objects. When the underlying transport connection is closed, this set will be empty. For explicitly multipath Trammell, et al. Expires April 30, 2017 [Page 10] Internet-Draft Post Sockets October 2016 architectures and transports, this set may change dynamically during the lifetime of an association, even while it remains connected. Since the existence of an association does not necessarily imply current connection state at both ends of the Association, these objects are durable, and can be cached, migrated, and restored, as long as the mappings to their event handlers are stable. An attempts to send an object or open a stream on a dormant, previously actively- opened association will cause the underlying transport connection state to be resumed. 3.2. Listener and Passive Association Creation In order to accept new Association requests from clients, a server must create a Listener object, using the listen() entry point: listener = listen(local, accept_handler) where: o local: resolved Local (see Section 3.8) describing the local identity and interface(s) to use for Associations created by this listener. o accept_handler: callback to be invoked each time an association is requested by a remote, to finalize setting the association up. Platforms may provide a default here for supporting synchronous association request handling via an object queue. The accept_handler has the following prototype: accepted = accept_handler(listener, local, remote) where: o local: a resolved Local on which the association request was received. o remote: a resolved Remote from which the association request was received. o accepted: flag, true if the handler decided to accept the request, false otherwise. The accept_handler() calls the accept() entry point to finally create the association: Trammell, et al. Expires April 30, 2017 [Page 11] Internet-Draft Post Sockets October 2016 association = accept(listener, local, remote, receive_handler) 3.3. Sending Objects Objects are sent using the send() entry point: send(association, bytes, [lifetime], [niceness], [oid], [antecedent_oids], [paths])} where: o association: the association to send the object on o bytes: sequence of bytes making up the object. For platforms without bounded byte arrays, this may be implemented as a pointer and a length. o lifetime: lifetime of the object in milliseconds. This parameter is optional and defaults to infinity (for fully reliable object transport). o niceness: the object's niceness class. This parameter is optional and defaults to zero (for lowest niceness / highest priority) o oid: opaque identifier for an object, assigned by the application. Used to refer to this object as a subsequently sent object's antecedent, or in an ack or expired handler (see Section 3.6). Optional, defaults to null. o antecedent_oids: set of object identifiers on which this object depends and which must be sent before this object. Optional, defaults to empty, meaning this object has no antecedent constraints. o paths: set of paths, as a subset of those available to the association, to explicitly use for this object. Optional, defaults to empty, meaning all paths are acceptable. Calls to send are non-blocking; a synchronous send which blocks on remote acknowledgment or expiry of an object can be implemented by a call to send() followed by a wait on the ack or expired events (see Section 3.6). 3.4. Receiving Objects An application receives objects via its receive_handler callback, registered at association creation time. This callback has the following prototype: Trammell, et al. Expires April 30, 2017 [Page 12] Internet-Draft Post Sockets October 2016 receive_handler(association, bytes) where: - association: the association the object was received from. - bytes: the sequence of bytes making up the object. For ease of porting synchronous datagram applications, implementations may make a default receive handler available, which allows messages to be synchronously polled from a per-association object queue. If this default is available, the entry point for the polling call is: bytes = receive_next(association) 3.5. Creating and Destroying Streams A stream may be created on an association via the open_stream() entry point: stream = open_stream(association, [sid]) where: o association: the association to open the stream on o sid: opaque identifier for a stream. For transport protocols which do not support multiple streaming, this argument has no effect. A stream with a given sid must be opened by both sides before it can be used. The stream object returned should act like a file descriptor or bidirectional I/O object, according to the conventions of the platform implementing Post. 3.6. Events Message reception is a specific case of an event that can occur on an association. Other events are also available, and the application can register event handlers for each of these. Event handlers are registered via the handle() entry point: handle(association, event, handler) or handle(oid, event, handler) where Trammell, et al. Expires April 30, 2017 [Page 13] Internet-Draft Post Sockets October 2016 o association: the association to register a handler on, or o oid: the object identifier to register a handler on o event: an identifier of the event to register a handler on o handler: a callback to be invoked when the event occurs, or null if the event should be ignored. The following events are supported; every event handler takes the association on which it is registered as well as any additional arguments listed: o receive (bytes): an object has been received o path_up (path): a path is newly available o path_down (path): a path is no longer available o dormant: no more paths are available, the association is now dormant, and the connection will need to be resumed if further objects are to be sent o ack (oid): an object was successfully received by the remote o expired (oid): an object expired before being sent to the remote Handlers for the ack and expired events can be registered on an association (in which case they are called for all objects sent on the association) or on an oid (in which case they are only called for the oid). 3.7. Paths and Path Properties As defined in Section 2.5, the properties of a path include both the addresses of elements along the path as well as measurement-derived latency and capacity characteristics. The path_up and path_down events provide access to information about the paths available via the path argument to the event handler. This argument encapsulates these properties in a platform and transport-specific way, depending on the availability of information about the path. 3.8. Address Resolution Address resolution turns the name of a Remote into a resolved Remote object, which encapsulates all the information needed to connect (address, certificate parameters, cached cryptographic state, etc.); and an interface identifier on a local system to information needed Trammell, et al. Expires April 30, 2017 [Page 14] Internet-Draft Post Sockets October 2016 to connect. Remote and local resolvers have the following entry points: remote = resolve(endpoint_name, configuration) local = resolve_local(endpoint_name, configuration) where: o endpoint_name: a name identifying the remote or local endpoint, including port o configuration: a platform-specific configuration object for configuring certificates, name resolution contexts, cached cryptographic state, etc. 4. Acknowledgments Many thanks to Laurent Chuat and Jason Lee at the Network Security Group at ETH Zurich for contributions to the initial design of Post Sockets. This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat for Education, Research, and Innovation under contract no. 15.0268. This support does not imply endorsement. 5. Informative References [I-D.hamilton-quic-transport-protocol] Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC: A UDP-Based Multiplexed and Secure Transport", draft- hamilton-quic-transport-protocol-00 (work in progress), July 2016. [I-D.iyengar-minion-protocol] Jana, J., Cheshire, S., and J. Graessley, "Minion - Wire Protocol", draft-iyengar-minion-protocol-02 (work in progress), October 2013. [I-D.trammell-plus-abstract-mech] Trammell, B., "Abstract Mechanisms for a Cooperative Path Layer under Endpoint Control", draft-trammell-plus- abstract-mech-00 (work in progress), September 2016. Trammell, et al. Expires April 30, 2017 [Page 15] Internet-Draft Post Sockets October 2016 [I-D.trammell-plus-statefulness] Kuehlewind, M., Trammell, B., and J. Hildebrand, "Transport-Independent Path Layer State Management", draft-trammell-plus-statefulness-00 (work in progress), October 2016. [MinimaLT] Petullo, W., Zhang, X., Solworth, J., Bernstein, D., and T. Lange, "MinimaLT, Minimal-latency Networking Through Better Security", May 2013. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, . [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . Authors' Addresses Brian Trammell ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland Email: ietf@trammell.ch Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom Email: csp@cperkins.net Trammell, et al. Expires April 30, 2017 [Page 16] Internet-Draft Post Sockets October 2016 Tommy Pauly Apple Inc. 1 Infinite Loop Cupertino, California 95014 United States of America Email: tpauly@apple.com Mirja Kuehlewind ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland Email: mirja.kuehlewind@tik.ee.ethz.ch Trammell, et al. Expires April 30, 2017 [Page 17]