draft-trammell-taps-post-sockets-01.txt   draft-trammell-taps-post-sockets-02.txt 
TAPS Working Group B. Trammell TAPS Working Group B. Trammell
Internet-Draft ETH Zurich Internet-Draft ETH Zurich
Intended status: Informational C. Perkins Intended status: Informational C. Perkins
Expires: March 12, 2018 University of Glasgow Expires: April 30, 2018 University of Glasgow
T. Pauly T. Pauly
Apple Inc. Apple Inc.
M. Kuehlewind M. Kuehlewind
ETH Zurich ETH Zurich
C. Wood C. Wood
Apple Inc. Apple Inc.
September 08, 2017 October 27, 2017
Post Sockets, An Abstract Programming Interface for the Transport Layer Post Sockets, An Abstract Programming Interface for the Transport Layer
draft-trammell-taps-post-sockets-01 draft-trammell-taps-post-sockets-02
Abstract Abstract
This document describes Post Sockets, an asynchronous abstract This document describes Post Sockets, an asynchronous abstract
programming interface for the atomic transmission of messages in an programming interface for the atomic transmission of messages in an
inherently multipath environment. Post replaces connections with inherently multipath environment. Post replaces connections with
long-lived associations between endpoints, with the possibility to long-lived associations between endpoints, with the possibility to
cache cryptographic state in order to reduce amortized connection cache cryptographic state in order to reduce amortized connection
latency. We present this abstract interface as an illustration of latency. We present this abstract interface as an illustration of
what is possible with present developments in transport protocols what is possible with present developments in transport protocols
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 12, 2018. This Internet-Draft will expire on April 30, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Abstractions and Terminology . . . . . . . . . . . . . . . . 5 2. Abstractions and Terminology . . . . . . . . . . . . . . . . 5
2.1. Message Carrier . . . . . . . . . . . . . . . . . . . . . 6 2.1. Message Carrier . . . . . . . . . . . . . . . . . . . . . 6
2.2. Message . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Message . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Association . . . . . . . . . . . . . . . . . . . . . . . 11 2.3. Association . . . . . . . . . . . . . . . . . . . . . . . 11
2.4. Remote . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4. Remote . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5. Local . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5. Local . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.6. Policy Context . . . . . . . . . . . . . . . . . . . . . 12 2.6. Configuration . . . . . . . . . . . . . . . . . . . . . . 12
2.7. Transient . . . . . . . . . . . . . . . . . . . . . . . . 13 2.7. Transient . . . . . . . . . . . . . . . . . . . . . . . . 13
2.8. Path . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.8. Path . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3. Abstract Programming Interface . . . . . . . . . . . . . . . 14 3. Abstract Programming Interface . . . . . . . . . . . . . . . 15
3.1. Example Connection Patterns . . . . . . . . . . . . . . . 15 3.1. Example Connection Patterns . . . . . . . . . . . . . . . 16
3.1.1. Client-Server . . . . . . . . . . . . . . . . . . . . 16 3.1.1. Client-Server . . . . . . . . . . . . . . . . . . . . 16
3.1.2. Client-Server with Happy Eyeballs and 0-RTT 3.1.2. Client-Server with Happy Eyeballs and 0-RTT
establishment . . . . . . . . . . . . . . . . . . . . 17 establishment . . . . . . . . . . . . . . . . . . . . 18
3.1.3. Peer to Peer with Network Address Translation . . . . 17 3.1.3. Peer to Peer with Network Address Translation . . . . 18
3.1.4. Multicast Receiver . . . . . . . . . . . . . . . . . 17 3.1.4. Multicast Receiver . . . . . . . . . . . . . . . . . 18
3.2. Association Bootstrapping . . . . . . . . . . . . . . . . 18 3.1.5. Association Bootstrapping . . . . . . . . . . . . . . 19
4. Implementation Considerations . . . . . . . . . . . . . . . . 19 3.2. API Dynamics . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Protocol Stack Instance (PSI) . . . . . . . . . . . . . . 19 4. Implementation Considerations . . . . . . . . . . . . . . . . 23
4.2. Message Framing, Parsing, and Serialization . . . . . . . 20 4.1. Protocol Stack Instance (PSI) . . . . . . . . . . . . . . 23
4.3. Message Size Limitations . . . . . . . . . . . . . . . . 22 4.2. Message Framing, Parsing, and Serialization . . . . . . . 24
4.4. Back-pressure . . . . . . . . . . . . . . . . . . . . . . 22 4.3. Message Size Limitations . . . . . . . . . . . . . . . . 25
4.5. Associations, Transients, Racing, and Rendezvous . . . . 22 4.4. Back-pressure . . . . . . . . . . . . . . . . . . . . . . 26
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 4.5. Associations, Transients, Racing, and Rendezvous . . . . 26
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. Normative References . . . . . . . . . . . . . . . . . . 25 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2. Informative References . . . . . . . . . . . . . . . . . 25 6.1. Normative References . . . . . . . . . . . . . . . . . . 28
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 27 6.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
The BSD Unix Sockets API's SOCK_STREAM abstraction, by bringing The BSD Unix Sockets API's SOCK_STREAM abstraction, by bringing
network sockets into the UNIX programming model, allowing anyone who network sockets into the UNIX programming model, allowing anyone who
knew how to write programs that dealt with sequential-access files to knew how to write programs that dealt with sequential-access files to
also write network applications, was a revolution in simplicity. It also write network applications, was a revolution in simplicity. It
would not be an overstatement to say that this simple API is the 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 reason the Internet won the protocol wars of the 1980s. SOCK_STREAM
is tied to the Transmission Control Protocol (TCP), specified in 1981 is tied to the Transmission Control Protocol (TCP), specified in 1981
skipping to change at page 6, line 10 skipping to change at page 6, line 10
programming interface unifying access all these efforts is necessary programming interface unifying access all these efforts is necessary
to fully exploit their potential. to fully exploit their potential.
2. Abstractions and Terminology 2. Abstractions and Terminology
+===============+ +===============+
| Message | | Message |
+===============+ +===============+
| ^ | | | ^ | |
send()| |ready() |initiate() |listen() send()| |ready() |initiate() |listen()
V | V V V | V V
+=====================+ +============+ +=======================+ +============+
| | accept() | | | | accept()| |
| Carrier |<----------| Listener | | Carrier |<--------| Listener |
| | | | | | | |
+=====================+ +============+ +=======================+ +============+
|1 | n| | +=========+ |1 | n| | +=========+
| | |1 | +---| Local | | | |1 | +---| Local |
| +=========+ +=======================+ | +=========+ | +===============+ +=======================+ | +=========+
| | Policy |n | |---+ | | | | |---+
| | Context |---| Association | +=========+ | | Configuration |--| Association | +=========+
| | | 1| |-------| Remote | | | | | |-------| Remote |
| +=========+ +=======================+ +=========+ | +===============+ +=======================+ +=========+
| | 1| durable end-to-end | | 1| durable end-to-end
+-------+ | | state via many paths, +-------+ | | state via many paths,
| | | policies, and prefs | | | policies, and prefs
n| | n| n| | n|
+===========+ +==========+ +===========+ +==========+
ephemeral | | | | ephemeral | | | |
transport & | Transient |-------| Path | properties of transport & | Transient |-------| Path | properties of
crypto state | |n 1| | address pair crypto state | |n 1| | address pair
+===========+ +==========+ +===========+ +==========+
skipping to change at page 7, line 19 skipping to change at page 7, line 19
corresponding Carrier at the remote endpoint, though not necessarily corresponding Carrier at the remote endpoint, though not necessarily
reliably or in order, depending on Message properties and the reliably or in order, depending on Message properties and the
underlying transport protocol stack. underlying transport protocol stack.
A Carrier that is backed by current transport protocol stack state A Carrier that is backed by current transport protocol stack state
(such as a TCP connection; see Section 2.7) is said to be "active": (such as a TCP connection; see Section 2.7) is said to be "active":
messages can be sent and received over it. A Carrier can also be messages can be sent and received over it. A Carrier can also be
"dormant": there is long-term state associated with it (via the "dormant": there is long-term state associated with it (via the
underlying Association; see Section 2.3), and it may be able to underlying Association; see Section 2.3), and it may be able to
reactivated, but messages cannot be sent and received immediately. reactivated, but messages cannot be sent and received immediately.
Carriers become dormant when the underlying transport protocol stack
determines that an underlying connection has been lost and there is
insufficient state in the Association to re-establish it (e.g., in
the case of a server-side Carrier where the client's address has
changed unexpectedly). Passive close can be handled by the
application via an event on the carrier. Attempting to use a carrier
after passive close results in an error.
If supported by the underlying transport protocol stack, a Carrier If supported by the underlying transport protocol stack, a Carrier
may be forked: creating a new Carrier associated with a new Carrier may be forked: creating a new Carrier associated with a new Carrier
at the same remote endpoint. The semantics of the usage of multiple at the same remote endpoint. The semantics of the usage of multiple
Carriers based on the same Association are application-specific. Carriers based on the same Association are application-specific.
When a Carrier is forked, its corresponding Carrier at the remote When a Carrier is forked, its corresponding Carrier at the remote
endpoint receives a fork request, which it must accept in order to endpoint receives a fork request, which it must accept in order to
fully establish the new carrier. Multiple Carriers between endpoints fully establish the new carrier. Multiple Carriers between endpoints
are implemented differently by different transport protocol stacks, are implemented differently by different transport protocol stacks,
either using multiple separate transport-layer connections, or using either using multiple separate transport-layer connections, or using
skipping to change at page 11, line 14 skipping to change at page 11, line 18
Message has expired before transmission/acknowledgement. Not all Message has expired before transmission/acknowledgement. Not all
transport protocol stacks will support all of these events. transport protocol stacks will support all of these events.
2.3. Association 2.3. Association
An Association contains the long-term state necessary to support An Association contains the long-term state necessary to support
communications between a Local (see Section 2.5) and a Remote (see communications between a Local (see Section 2.5) and a Remote (see
Section 2.4) endpoint, such as trust model information, including Section 2.4) endpoint, such as trust model information, including
pinned public keys or anchor certificates, cryptographic session pinned public keys or anchor certificates, cryptographic session
resumption parameters, or rendezvous information. It uses resumption parameters, or rendezvous information. It uses
information from the Policy Context (see Section 2.6) to constrain information from the Configuration (see Section 2.6) to constrain the
the selection of transport protocols and local interfaces to create selection of transport protocols and local interfaces to create
Transients (see Section 2.7) to carry Messages; and information about Transients (see Section 2.7) to carry Messages; and information about
the paths through the network available available between them (see the paths through the network available available between them (see
Section 2.8). Section 2.8).
All Carriers are bound to an Association. New Carriers will reuse an All Carriers are bound to an Association. New Carriers will reuse an
Association if they can be carried from the same Local to the same Association if they can be carried from the same Local to the same
Remote over the same Paths; this re-use of an Association may implies Remote over the same Paths; this re-use of an Association may implies
the creation of a new Transient. the creation of a new Transient.
Associations may exist and be created without a Carrier. This may be Associations may exist and be created without a Carrier. This may be
skipping to change at page 12, line 23 skipping to change at page 12, line 25
and a transport protocol to try connecting with. A second pass and a transport protocol to try connecting with. A second pass
resolution would then look up network-layer addresses associated with resolution would then look up network-layer addresses associated with
that name through DNS, and store any certificates available from that name through DNS, and store any certificates available from
DANE. Once a Remote has been resolved to the point that a transport DANE. Once a Remote has been resolved to the point that a transport
protocol stack can use it to create a Transient, it is considered protocol stack can use it to create a Transient, it is considered
fully resolved. fully resolved.
2.5. Local 2.5. Local
A Local represents all the information about the local endpoint A Local represents all the information about the local endpoint
necessary to establish an Association or a Listener: interface, port, necessary to establish an Association or a Listener. It encapsulates
and transport protocol stack information, and, per the Provisioning Domain (PvD) of a single interface in the multiple
provisioning domain architecture [RFC7556], and adds information
about the service endpoint (transport protocol port), and, per
[I-D.pauly-taps-transport-security], cryptographic identities [I-D.pauly-taps-transport-security], cryptographic identities
(certificates and associated private keys) bound to this endpoint. (certificates and associated private keys) bound to this endpoint.
2.6. Policy Context 2.6. Configuration
The Policy Context describes preferences for, and restrictions on, A Configuration encapsulates an application's preferences around Path
how to configure Transients to support communication between a Local selection and protocol options.
and a Remote over one or more Paths between endpoints. For instance,
an application may require, or prefer to use, certain features (see
[I-D.ietf-taps-transports]) of the transport protocol stacks used by
the Transients underlying the Carrier. Alternatively, it might also
prefer Paths over one interface to those over another (e.g., WiFi
access over LTE when roaming on a foreign LTE network, due to cost).
These policies are expressed in the Policy Context(s) that are bound Each Association has exactly one Configuration, and all Carriers
to the Association. Multiple policy contexts can be active at once. belonging to that Association share the same Configuration.
For example, a system Policy Context can express the administrative
preferences around network interface and protocol selection, while an The application cannot modify the Configuration for a Carrier or
application Policy Context expresses preferences for use of different Association once it is set. If a new set of options needs to be
transport services. Expression of policy contexts and the resolution used, then the application needs a new Carrier or Association
of conflicts among Policy Contexts is currently implementation- instance. This is necessary to ensure that a single Carrier can
specific (the Policy API in the NEAT architecture [NEAT] provides an consistently track the Paths and protocol options it uses, since it
example of how this can be done). is usually not possible to modify these properties without breaking
connectivity.
To influence Path selection, the application can configure a set of
requirements, preferences, and restrictions concerning which Paths
may be selected by the Association to use for creating Transients
between a Local and a Remote. For example, a Configuration can
specify that the application prefers Wi-Fi access over LTE when
roaming on a foreign LTE network, due to monetary cost to the user.
The Association uses the Configuration's Path preferences as a key
part of determining the Paths to use for its Transients. The
Configuration is provided as input when examining the complete list
of available Paths on the system (to limit the list, or order the
Paths by preference). The system's policy will further restrict and
modify the Path that is ultimately selected, using other aspects of
the Configuration (protocol options and originating application) to
select the most appropriate Path.
To influence protocol selection and options, the Configuration
contains one or more allowed Protocol Stack Configurations. Each of
these is comprised of application- and transport-layer protocols that
may be used together to communicate to the Remote, along with any
protocol-specific options. For example, a Configuration could
specify two alternate, but equivalent, protocol stacks: one using
HTTP/2 over TLS over TCP, and the other using QUIC over UDP.
Alternatively, the Configuration could specify two protocol stacks
with the same protocols, but different protocol options: one using
TLS with TLS 1.3 0-RTT enabled and TCP with TCP Fast-Open enabled,
and one using TLS with out 0-RTT and TCP without TCP Fast-Open.
Protocol-specific options within the Configuration include trust
settings and acceptable cryptographic algorithms to be used by
security protocols. These may be configured for specific protocols
to allow different settings for each (such as between TLS over TCP
and TLS for use with QUIC), or set as default security settings on
the Configuration to be used by any protocol that needs to evaluate
trust. Trust settings may include certificate anchors and
certificate pinning options.
2.7. Transient 2.7. Transient
A Transient represents a binding between a Carrier and the instance A Transient represents a binding between a Carrier and the instance
of the transport protocol stack that implements it. As an of the transport protocol stack that implements it. As an
Association contains long-term state for communications between two Association contains long-term state for communications between two
endpoints, a Transient contains ephemeral state for a single endpoints, a Transient contains ephemeral state for a single
transport protocol over a single Path at a given point in time. transport protocol over a one or more Paths at a given point in time.
A Carrier may be served by multiple Transients at once, e.g. when A Carrier may be served by multiple Transients at once, e.g. when
implementing multipath communication such that the separate paths are implementing multipath communication such that the separate paths are
exposed to the API by the underlying transport protocol stack. Each exposed to the API by the underlying transport protocol stack. Each
Transient serves only one Carrier, although multiple Transients may Transient serves only one Carrier, although multiple Transients may
share the same underlying protocol stack; e.g. when multiplexing share the same underlying protocol stack; e.g. when multiplexing
Carriers over streams in a multistreaming protocol. Carriers over streams in a multistreaming protocol.
Transients are generally not exposed by the API to the application, Transients are generally not exposed by the API to the application,
though they may be accessible for debugging and logging purposes. though they may be accessible for debugging and logging purposes.
skipping to change at page 15, line 48 skipping to change at page 16, line 33
highest probably for a successful connection attempt) or which PSIs highest probably for a successful connection attempt) or which PSIs
to probe for (first). A Transient is created when an application to probe for (first). A Transient is created when an application
actually sends a Message over a Carrier. As further explained below actually sends a Message over a Carrier. As further explained below
this step can actually create multiple transients for probing or this step can actually create multiple transients for probing or
assign a new transient to an already active PSI, e.g. if multi- assign a new transient to an already active PSI, e.g. if multi-
streaming is provided and supported for these kind of use on both streaming is provided and supported for these kind of use on both
sides. sides.
3.1. Example Connection Patterns 3.1. Example Connection Patterns
[EDITOR'S NOTE: ensure these are in line with the Section 3.2 below.]
Here, we illustrate the usage of the API for common connection Here, we illustrate the usage of the API for common connection
patterns. Note that error handling is ignored in these illustrations patterns. Note that error handling is ignored in these illustrations
for ease of reading. for ease of reading.
3.1.1. Client-Server 3.1.1. Client-Server
Here's an example client-server application. The server echoes Here's an example client-server application. The server echoes
messages. The client sends a message and prints what it receives. messages. The client sends a message and prints what it receives.
The client in Figure 2 connects, sends a message, and sets up a The client in Figure 2 connects, sends a message, and sets up a
skipping to change at page 18, line 15 skipping to change at page 19, line 5
multicast address forever. multicast address forever.
func receiveMulticast() { func receiveMulticast() {
sink = NewSink(local) sink = NewSink(local)
sink.Ready(func (msg InMessage) { sink.Ready(func (msg InMessage) {
fmt.Println(string([]byte(msg))) fmt.Println(string([]byte(msg)))
return true return true
}) })
} }
3.2. Association Bootstrapping 3.1.5. Association Bootstrapping
Here, we show how Association state may be initialized without a Here, we show how Association state may be initialized without a
carrier. The goal is to create a long-term Association from which carrier. The goal is to create a long-term Association from which
Carriers may be derived and, if possible, used immediately. Per Carriers may be derived and, if possible, used immediately. Per
[I-D.pauly-taps-transport-security], a first step is to specify trust [I-D.pauly-taps-transport-security], a first step is to specify trust
model constraints, such as pinned public keys and anchor model constraints, such as pinned public keys and anchor
certificates, which are needed to create Remote connections. certificates, which are needed to create Remote connections.
We begin by creating shared security parameters that will be used We begin by creating shared security parameters that will be used
later for creating a remote connection. later for creating a remote connection.
skipping to change at page 18, line 40 skipping to change at page 19, line 30
parameters = parameters.SetTrustedCerts(trustedCerts) parameters = parameters.SetTrustedCerts(trustedCerts)
return parameters return parameters
} }
Using these statically configured parameters, we now show how to Using these statically configured parameters, we now show how to
create an Association between a Local and Remote using these create an Association between a Local and Remote using these
parameters. parameters.
// create an Association using shared parameters // create an Association using shared parameters
func createAssociation(local Local, remote Remote, parameters Parameters) Association { func createAssociation(local Local, remote Remote, parameters Parameters) Association {
association := AssociationWithParameters(local, remote, parameters) association := NewAssociation(local, remote, parameters)
return association return association
} }
We may also create an Association with a pre-shared key configured We may also create an Association with a pre-shared key configured
out-of-band. out-of-band.
// create an Association using a pre-shared key // create an Association using a pre-shared key
func createAssociationWithPSK(local Local, remote Remote, parameters Parameters, preSharedKey []byte) Association { func createAssociationWithPSK(local Local, remote Remote, parameters Parameters, preSharedKey []byte) Association {
association := AssociationWithParameters(local, remote, parameters) association := NewAssociation(local, remote, parameters)
association = association.SetPreSharedKey(preSharedKey) association = association.SetPreSharedKey(preSharedKey)
return association return association
} }
We now show how to create a Carrier from an existing, pre-configured We now show how to create a Carrier from an existing, pre-configured
Association. This Association may or may not contain shared Association. This Association may or may not contain shared
cryptographic static between the Local and Remote, depending on how cryptographic static between the Local and Remote, depending on how
it was configured. it was configured.
// open a connection to a server using an existing Association and send some data, // open a connection to a server using an existing Association and send some data,
// which will be sent early if possible. // which will be sent early if possible.
func sayHelloWithAssociation(association Association) { func sayHelloWithAssociation(association Association) {
carrier := InitiateWithAssociation(association) carrier := association.Initiate()
carrier.SendMsg(OutMessage{Content: []byte("Hello!"), Idempotent: true}, nil, nil, nil) carrier.SendMsg(OutMessage{Content: []byte("Hello!"), Idempotent: true}, nil, nil, nil)
carrier.Ready(func (msg InMessage) { carrier.Ready(func (msg InMessage) {
fmt.Println(string([]byte(msg))) fmt.Println(string([]byte(msg)))
return false return false
}) })
carrier.Close() carrier.Close()
} }
3.2. API Dynamics
As Carriers provide the central entry point to Post, they are key to
API dynamics. The lifecycle of a carrier is shown in Figure 5.
Carriers are created by active openers by calling Initiate() given a
Local and a Remote, and by passive openers by calling Listen() given
a Local; the .Accept() method on the listener Carrier can then be
used to create active carriers. By default, the underlying
Association is automatically created and managed by the underlying
API. This underlying Association can be accessed by the Carrier's
.Association() method. Alternately, an association can be explicitly
created using NewAssociation(), and a Carrier on the association may
be accessed or initiated by calling the association's .Initiate()
method.
Once a Carrier has been created (via Initiate(),
Association.Initiate(), NewSource(), NewSink(), or
Listen()/Accept()), it may be used to send and receive Messages. The
existence of a Carrier does not imply the existence of an active
Transient or associated transport-layer connection; these may be
created when the carrier is, or may be deferred, depending on the
network environment, configuration, and protocol stacks available.
Listen(local) Initiate(local,remote) NewSource(local,remote)
| | or NewSink(local)
[ Carrier ] | |
[(listener)] +--------------------+
| V
.Accept()-----------> [Carrier] -+----------> .Close()
| ^ | close [ Carrier ]
| | +- event -> [ (closed) ]
| |
.Association() .Carriers()
| .Initiate()
V |
[Association]
^
|
NewAssociation(local,remote)
Figure 5: Carrier and Association Life Cycle
Access to more detailed information is possible through accessors on
Carriers and Associations, as shown in Figure 6. The set of
currently active Transients can be accessed through the Carrier's
.Transients() methods. The active path(s) used by a Transient can be
accessed through the Transient's .Paths() method, and the set of all
paths for which properties are cached by an Association can be
accessed through the Association's .Paths() method. The set of
active carriers on an association can be accessed through the
Association's .Carriers() method. Access to transients and paths is
not necessary in normal operation; these accessors are provided
primarily for logging and debugging purposes.
[Carrier]---.Transients()--->[Transient]
| ^ |
| | |
.Association() .Carriers() .Paths()
| .Initiate() |
V | V
[Association]---.Paths()------>[Path]
Figure 6: Accessors on Carriers and Associations
Each Carrier has a .Send() method, by which Messages can be sent with
given properties, and a .Ready() method, which supplies a callback
for reading Messages from the remote side. .Send() is not available
on Sinks, and .Ready() is not available on Sources. Carriers also
provide .OnSent(), .OnAcked(), and .OnExpired() calls for binding
default send event handlers to the Carrier, and .OnClosed() for
handling passive close notifications.
+---------[incoming]-----------+
| [Message ] V
[outgoing] ---> .Send() ---> [Carrier] <---- .Ready() <---- [Receiver]
[Message ] |
+--- .OnSent()
+--- .OnAcked()
+--- .OnExpired()
+--- .OnClosed()
Figure 7: Sending and Receiving Messages and Events
An application may have a global Configuation, as well as more
specific Configurations to apply to the establishment of a given
Association or Carrier. These Configurations are optional arguments
to the Association and Carrier creation calls.
[EDITOR'S NOTE (bht): the text below does not belong here, figure out
what to do with it when https://github.com/mami-project/draft-
trammell-post-sockets/pull/23 lands: Each Configuration is
conceptually a key-value store, where information in more specific
scopes overrides information in less specific scopes: application
defaults can be overriden by specific Configurations bound to
Carriers or Associations, all of which may be overriden by system or
user-scoped configuration parameters. Configurations are also made
directly available to protocol stack instances (PSIs, see
Section 4.1) for fine-grained control of implementation-specific
configuration parameters.]
In order to initiate a connection with a remote endpoint, a user of
Post Sockets must start from a Remote (see Section 2.4). A Remote
encapsulates identifying information about a remote endpoint at a
specific level of resolution. A new Remote can be wrapped around
some identifying information by via the NewRemote() call. A Remote
has a .Resolve() method, which can be iteratively revoked to increase
the level of resolution; a call to Resolve on a given Remote may
result in one to many Remotes, as shown in Figure 8. Remotes at any
level of resolution may be passed to Post Sockets calls; each call
will continue resolution to the point necessary to establish or
resume a Carrier.
+----------------------------+
n | | 1
NewRemote(identifiers) ---+--->[Remote] --.Resolve()---+
Figure 8: Recursive resolution of Remotes
Information about the local endpoint is also necessary to establish
an Association, whether explicitly or implicitly through the creation
of a Carrier or Listener. This is passed in the form of a Local (see
Section 2.5). A Local is created with a NewLocal() call, which takes
a Configuration (including certificates to present and secret keys
associated with them) and identifying information (interface(s) and
port(s) to use).
4. Implementation Considerations 4. Implementation Considerations
Here we discuss an incomplete list of API implementation Here we discuss an incomplete list of API implementation
considerations that have arisen with experimentation with prototype considerations that have arisen with experimentation with prototype
implementations of Post. implementations of Post.
4.1. Protocol Stack Instance (PSI) 4.1. Protocol Stack Instance (PSI)
A PSI encapsulates an arbitrary stack of protocols (e.g., TCP over A PSI encapsulates an arbitrary stack of protocols (e.g., TCP over
IPv6, SCTP over DTLS over UDP over IPv4). PSIs provide the bridge IPv6, SCTP over DTLS over UDP over IPv4). PSIs provide the bridge
skipping to change at page 20, line 26 skipping to change at page 23, line 51
|TLS | |SCTP | |TLS | | TLS| |TLS | |SCTP | |TLS | | TLS|
|TCP | |DTLS | |TCP | | TCP| |TCP | |DTLS | |TCP | | TCP|
|IPv6 | |UDP | |IPv6 | | IPv4| |IPv6 | |UDP | |IPv6 | | IPv4|
|802.3 | |IPv6 | |802.11| |802.11| |802.3 | |IPv6 | |802.11| |802.11|
+------+ |802.3 | +------+ +------+ +------+ |802.3 | +------+ +------+
+------+ +------+
(a) Transient (b) Carrier multiplexing (c) Multiple candidates (a) Transient (b) Carrier multiplexing (c) Multiple candidates
bound to PSI over a multi-streaming racing during session bound to PSI over a multi-streaming racing during session
transport protocol establishment transport protocol establishment
Figure 5: Example Protocol Stack Instances Figure 9: Example Protocol Stack Instances
For example, Figure 5(a) shows a TLS over TCP stack, usable on most For example, Figure 9(a) shows a TLS over TCP stack, usable on most
network connections. Protocols are layered to ensure that the PSI network connections. Protocols are layered to ensure that the PSI
provides all the transport services required by the application. A provides all the transport services required by the application. A
single PSI may be bound to multiple Carriers, as shown in single PSI may be bound to multiple Carriers, as shown in
Figure 5(b): a multi-streaming transport protocol like QUIC or SCTP Figure 9(b): a multi-streaming transport protocol like QUIC or SCTP
can support one carrier per stream. Where multi-streaming transport can support one carrier per stream. Where multi-streaming transport
is not available, these carriers could be serviced by different PSIs is not available, these carriers could be serviced by different PSIs
on different flows. On the other hand, multiple PSIs are bound to a on different flows. On the other hand, multiple PSIs are bound to a
single transient during establishment, as shown in Figure 5(c). single transient during establishment, as shown in Figure 9(c).
Here, the losing PSI in a happy-eyeballs race will be terminated, and Here, the losing PSI in a happy-eyeballs race will be terminated, and
the carrier will continue using the winning PSI. the carrier will continue using the winning PSI.
4.2. Message Framing, Parsing, and Serialization 4.2. Message Framing, Parsing, and Serialization
While some transports expose a byte stream abstraction, most higher While some transports expose a byte stream abstraction, most higher
level protocols impose some structure onto that byte stream. That level protocols impose some structure onto that byte stream. That
is, the higher level protocol operates in terms of messages, protocol is, the higher level protocol operates in terms of messages, protocol
data units (PDUs), rather than using unstructured sequences of bytes, data units (PDUs), rather than using unstructured sequences of bytes,
with each message being processed in turn. Protocols are specified with each message being processed in turn. Protocols are specified
skipping to change at page 22, line 21 skipping to change at page 25, line 46
Ideally, Messages can be of infinite size. However, protocol stacks Ideally, Messages can be of infinite size. However, protocol stacks
and protocol stack implementations may impose their own limits on and protocol stack implementations may impose their own limits on
message sizing; For example, SCTP [RFC4960] and TLS message sizing; For example, SCTP [RFC4960] and TLS
[I-D.ietf-tls-tls13] impose record size limitations of 64kB and 16kB, [I-D.ietf-tls-tls13] impose record size limitations of 64kB and 16kB,
respectively. Message sizes may also be limited by the available respectively. Message sizes may also be limited by the available
buffer at the receiver, since a Message must be fully assembled by buffer at the receiver, since a Message must be fully assembled by
the transport layer before it can be passed on to the application the transport layer before it can be passed on to the application
layer. Since not every transport protocol stack implements the layer. Since not every transport protocol stack implements the
signaling necessary to negotiate or expose message size limitations, signaling necessary to negotiate or expose message size limitations,
these are currently configured out of band, and are probably best these may need to be defined out of band, and are probably best
exposed through the policy context. exposed through the Configuration.
A truly infinite message service - e.g. large file transfer where A truly infinite message service - e.g. large file transfer where
both endpoints have committed persistent storage to the message - is both endpoints have committed persistent storage to the message - is
probably best realized as a layer above Post Sockets, and may be probably best realized as a layer above Post Sockets, and may be
added as a new type of Message Carrier to a future revision of this added as a new type of Message Carrier to a future revision of this
document. document.
4.4. Back-pressure 4.4. Back-pressure
Regardless of how asynchronous reception is implemented, it is Regardless of how asynchronous reception is implemented, it is
skipping to change at page 25, line 34 skipping to change at page 29, line 9
[I-D.ietf-taps-transports] [I-D.ietf-taps-transports]
Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services
provided by IETF transport protocols and congestion provided by IETF transport protocols and congestion
control mechanisms", draft-ietf-taps-transports-14 (work control mechanisms", draft-ietf-taps-transports-14 (work
in progress), December 2016. in progress), December 2016.
6.2. Informative References 6.2. Informative References
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-05 (work and Secure Transport", draft-ietf-quic-transport-07 (work
in progress), August 2017. in progress), October 2017.
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-21 (work in progress), Version 1.3", draft-ietf-tls-tls13-21 (work in progress),
July 2017. July 2017.
[I-D.iyengar-minion-protocol] [I-D.iyengar-minion-protocol]
Jana, J., Cheshire, S., and J. Graessley, "Minion - Wire Jana, J., Cheshire, S., and J. Graessley, "Minion - Wire
Protocol", draft-iyengar-minion-protocol-02 (work in Protocol", draft-iyengar-minion-protocol-02 (work in
progress), October 2013. progress), October 2013.
skipping to change at page 26, line 49 skipping to change at page 30, line 23
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010, DOI 10.17487/RFC5245, April 2010,
<https://www.rfc-editor.org/info/rfc5245>. <https://www.rfc-editor.org/info/rfc5245>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
2012, <https://www.rfc-editor.org/info/rfc6555>. 2012, <https://www.rfc-editor.org/info/rfc6555>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple "TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<https://www.rfc-editor.org/info/rfc6824>. <https://www.rfc-editor.org/info/rfc6824>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
 End of changes. 28 change blocks. 
71 lines changed or deleted 246 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/