Draft: draft-ietf-taps-interface

Commentary: allow to control active / passive opertaion clairify functionality allow to control exposure of alternative addresses 
 I think having one parameter for all interfaces is not enough as you might want to decide differently on a per interface basis . You can also have a look at section 5.3 of rfc6897 for what was recommended for MPTCP . Maybe the Apple people have also more input based in what is currently implemented for MPTCP in their stack ? 
 I think this would be a cool extension , but I would prefer to have a basic version first that leaves interface specific decisions to the implementation / system policy . 
 I do n't see that as an extension but an alternative . I just believe a generic config to enable this for all interfaces will not be useful at all because you always want to make a decision on a per interface basis . 
 Discussion seems ongoing enough that we should n't merge for the 107 draft deadline . Keeping this one open . 
 I clarified the relationship between the two multi - path properties . Please review whether this works for you now , as I do n't think merging them would make things clearer . With regards to the per - interface choice , I would prefer to use or Properties and add a few notes how these effect multi - path in a separate PR 
 Interim discussion : Possible knobs : Who opens the paths ? ( active / passive / disabled ) Should we announce our other IP addresses ? ( allowed or not ) How are packets scheduled on the subpaths ? ( handover , interactive , aggregate ) 
 I made a new version based on the decisions we made in the interim . Please review . 
 For MP use we have the following option : Disable , Handover , Interactive , Aggregate . I think the option as not well defined ( except Disable ) . Maybe the following is a bit better : Handover : : The connection should attempt to migrate to a new paths when interface availability changes and performance of the currently used path decreased below a certain threshold . This threshold is implementation - specific . Interactive : : The connection should attempt to use multiple paths in parallel in order to always select the best path available or at least achieve about the same aggregated bandwidth as provided by the best of the available paths . This can be achieved by using coupled congestion control as proposed in { { ? RFC6356 } } for MP - TCP . Aggregate : : The connection should attempt to use multiple paths in parallel in order to maximize bandwidth . That usually means that independent congestion control instances are used on each path . I also proposed another option : Redundant : : The connection should send the same data on two of the available paths . A message property could be used to indicate which messages should be send redundantly . And further I think we also need a configuration option to indicate when / if a new subpath should be opened . I think there are four options : Never - passive ( rely on other ending opening new paths and never send new available IPs ) , Never - active ( rely on other ending opening new paths but signal send new available IPs ) , Immediate ( open new path when IP because available locally or provided by other end ) , On - Request ( application needs to indicate ) . Note that there is also rfc6897 specifying a rather different interface ... 
 There are many options for MP . I think the idea with the current proposal was to start simple and stick to options that have deployment experience . As I understand the currenr proposal Aggregate is the option that uses both paths with coupled cc . I do not think we should have an option for uncoupled cc . Interactive is not targeting bulk traffic and will try to use a single path unless performance drops too much . So that is the most fuzzy . 
 Handover - sounds like what is called failover in many places . Can we call failover ? I 'm concerned by " interactive " - This is fuzzy indeed . Can we manage without this ? I do n't like " redundant " - true you can do this , but then when you have different paths ; CC ; etc you can introduce issues - do we have experience of this - is this a great thing to do below the transport , rather than in the App ... I am quite unsure . 
 Interim discussion : generally not wanting to expose redundant . Exposing alternate addresses to the peer and actively migrating is likely a separate property that we should specify . 
 Also review description text on enum instances 
 Still some things to sort out , but I think this PR is a good improvement , thanks modulo the comments from which I all agree with .
Paragraph (version A):
This document describes an abstract programming interface to the
transport layer, following the Transport Services Architecture.  It
supports the asynchronous, atomic transmission of messages over
transport protocols and network paths dynamically selected at
runtime.  It is intended to replace the traditional BSD sockets API
as the lowest common denominator interface to the transport layer, in
an environment where endpoints have multiple interfaces and potential
transport protocols to select from.
Paragraph (version A):
This document specifies a modern abstract programming interface atop
the high-level architecture for transport services defined in I-
D.ietf-taps-arch.  It supports the asynchronous, atomic transmission
of messages over transport protocols and network paths dynamically
selected at runtime.  It is intended to replace the traditional BSD
sockets API as the lowest common denominator interface to the
transport layer, in an environment where endpoints have multiple
interfaces and potential transport protocols to select from.
Paragraph (version A):
As applications adopt this interface, they will benefit from a wide
set of transport features that can evolve over time, and ensure that
the system providing the interface can optimize its behavior based on
the application requirements and network conditions, without
requiring changes to the applications.  This flexibility enables
faster deployment of new features and protocols.  It can also support
applications by offering racing and fallback mechanisms, which
otherwise need to be implemented in each application separately.
Paragraph (version A):
It derives specific path and protocol selection properties and
supported transport features from the analysis provided in RFC8095,
I-D.ietf-taps-minset, and I-D.ietf-taps-transport-security.  The
design encourages implementations underneath the interface to
dynamically choose a transport protocol depending on an application's
choices rather than statically binding applications to a protocol at
compile time.  We note that transport system implementations SHOULD
provide applications a way to override transport selection and
instantiate a specific stack, e.g. to support servers wanting to
listen to a specific protocol.  This specific transport stack choice
is discouraged for general use, as it comes at the cost of reduced
portability.
Paragraph (version A):
This API is described in terms of Objects, which an application can
interact with; Actions the application can perform on these Objects;
Events, which an Object can send to an application asynchronously;
and Parameters associated with these Actions and Events.
Paragraph (version B):
This API is described in terms of Objects with which an application
can interact; Actions the application can perform on these Objects;
Events, which an Object can send to an application asynchronously;
and Parameters associated with these Actions and Events.
Paragraph (version A):
How these abstract concepts map into concrete implementations of this
API in a given language on a given platform is largely dependent on
the features of the language and the platform.  Actions could be
implemented as functions or method calls, for instance, and Events
could be implemented via event queues, handler functions or classes,
communicating sequential processes, or other asynchronous calling
conventions.  The method for dispatching and handling Events is an
implementation detail, with the caveat that the interface for
receiving Messages must require the application to invoke the
Connection.Receive() Action once per Message to be received (see
receiving).
Paragraph (version B):
The way these abstract concepts map into concrete implementations of
this API in a given language on a given platform largely depends on
the features of the language and the platform.  Actions could be
implemented as functions or method calls, for instance, and Events
could be implemented via event queues, handler functions or classes,
communicating sequential processes, or other asynchronous calling
conventions.
Paragraph (version A):
This specification treats Events and errors similarly.  Errors, just
as any other Events, may occur asynchronously in network
applications.  However, it is recommended that implementations of
this interface also return errors immediately, according to the error
handling idioms of the implementation platform, for errors that can
be immediately detected, such as inconsistency in Transport
Properties.  Errors can provide an optional reason to give the
application further details as to why the error occured.
Paragraph (version B):
An application primarily interacts with this API through two Objects:
Preconnections and Connections.  A Preconnection represents a set of
properties and constraints on the selection and configuration of
paths and protocols to establish a Connection with a remote Endpoint.
A Connection represents a transport Protocol Stack on which data can
be sent to and/or received from a remote Endpoint (i.e., depending on
the kind of transport, connections can be bi-directional or
unidirectional).  Connections can be created from Preconnections in
three ways: by initiating the Preconnection (i.e., actively opening,
as in a client), through listening on the Preconnection (i.e.,
passively opening, as in a server), or rendezvousing on the
Preconnection (i.e.  peer to peer establishment).
Paragraph (version B):
Note that configuring Connection Properties and Message Properties on
Preconnections is preferred over setting them later.  Early
specification of Connection Properties allows their use as additional
input to the selection process.  Protocol Specific Properties, which
enable configuration of specialized features of a specific protocol,
see Section 3.2 of I-D.ietf-taps-arch, are not used as an input to
the selection process but only support configuration if the
respective protocol has been selected.
Paragraph (version A):
The Local Endpoint MUST be specified if the Preconnection is used to
Listen() for incoming Connections, but is OPTIONAL if it is used to
Initiate() connections.  The Remote Endpoint MUST be specified if the
Preconnection is used to Initiate() Connections, but is OPTIONAL if
it is used to Listen() for incoming Connections.  The Local Endpoint
and the Remote Endpoint MUST both be specified if a peer-to-peer
Rendezvous is to occur based on the Preconnection.
Paragraph (version A):
Preference-typed Selection Properties can be frequently used.
Implementations MAY therefore provide additional convenience
functions, see preference-conv for examples.  In addition,
implementations MAY provide a mechanism to create TransportProperties
objects that are preconfigured for common use cases as outlined in
property-profiles.
Paragraph (version A):
This property specifies whether the application needs to use a
transport protocol that ensures that all data is received on the
other side without corruption.  This also entails being notified when
a Connection is closed or aborted.
Paragraph (version B):
This property specifies whether the application needs to use a
transport protocol that ensures that all data is received on the
other side without corruption.  This also entails being notified when
a Connection is closed or aborted when reliable data transfer is
enabled.
Paragraph (version A):
The set of valid interface types is implementation- and system-
specific.  For example, on a mobile device, there may be "Wi-Fi" and
"Cellular" interface types available; whereas on a desktop computer,
there may be "Wi-Fi" and "Wired Ethernet" interface types available.
An implementation should provide all types that are supported on the
local system to all remote systems, to allow applications to be
written generically.  For example, if a single implementation is used
on both mobile devices and desktop devices, it should define the
"Cellular" interface type for both systems, since an application may
want to always "Prohibit Cellular".  Note that marking a specific
interface type as "Required" limits path selection to a small set of
interfaces, and leads to less flexible and resilient connection
establishment.
Paragraph (version B):
The set of valid interface types is implementation- and system-
specific.  For example, on a mobile device, there may be "Wi-Fi" and
"Cellular" interface types available; whereas on a desktop computer,
there may be "Wi-Fi" and "Wired Ethernet" interface types available.
An implementation should provide all types that are supported on the
local system to all remote systems, to allow applications to be
written generically.  For example, if a single implementation is used
on both mobile devices and desktop devices, it should define the
"Cellular" interface type for both systems, since an application may
want to always "Prohibit Cellular".
Paragraph (version B):
Avoid for Listeners and Rendezvous Connections.  Prefer for other
Connections.
Paragraph (version A):
Enumeration values other than "Disabled" are interpreted as
preferences.
Paragraph (version B):
The connection will not use multiple paths once established, even
if the chosen transport supports using multiple paths.
Paragraph (version B):
The connection will negotiate the use of multiple paths if the
chosen transport supports this.  It will actively bring up paths
based on the multipath policy (multipath-policy) selected by the
application, as limited by the Interface Instance and Provisioning
Domain Instance properties (see prop-interface and prop-pvd).
Paragraph (version B):
The connection will support the use of multiple paths if the
remote endpoint requests it.  The connection will not actively
initiate the use of any new paths, but will accept paths initiated
by the remote endpoint.
Paragraph (version B):
The policy for using multiple paths is specified using the separate
"multipath-policy" property, see multipath-policy below.  To enable
the peer endpoint to initiate additional paths towards a local
address other than the one initially used, it is necessary to set the
Alternative Addresses property (see altaddr below).
Paragraph (version B):
Setting this property to "Active", may have privacy implications: It
enables the transport to establish connectivity using alternate paths
that may make users linkable across multiple paths, even if the
Advertisement of Alternative Addresses property (see altaddr below)
is set to false.
Paragraph (version B):
Enumeration values other than "Disabled" are interpreted as a
preference for choosing protocols that can make use of multiple
paths.  The "Disabled" value implies a requirement not to use
multiple paths in parallel but does not prevent choosing a protocol
that is capable of using multiple paths, e.g., it does not prevent
choosing TCP, but prevents sending the "MP_CAPABLE" option in the TCP
handshake.
Paragraph (version B):
This property specifies whether alternative addresses, e.g., of other
interfaces, should be advertised to the peer endpoint by the protocol
stack.  Advertising these addresses enables the peer-endpoint to
establish additional connectivity, e.g., for connection migration or
using multiple paths.
Paragraph (version B):
Note that this may have privacy implications because it may make
users linkable across multiple paths.  Also, note that setting this
to false does not prevent the local transport system from
_establishing_ connectivity using alternate paths (see multipath-mode
above); it only prevents _procative advertisement_ of addresses.
Paragraph (version A):
Trust verification callback: Invoked when a Remote Endpoint's
trust must be validated before the handshake protocol can proceed.
Paragraph (version B):
Trust verification callback: Invoked when a Remote Endpoint's
trust must be validated before the handshake protocol can
continue.
Paragraph (version B):
Once Initiate is called, the candidate Protocol Stack(s) may cause
one or more candidate transport-layer connections to be created to
the specified remote endpoint.  The caller may immediately begin
sending Messages on the Connection (see sending) after calling
Initiate(); note that any data marked "Safely Replayable" that is
sent while the Connection is being established may be sent multiple
times or on multiple candidates.
Paragraph (version A):
The Connection Property "Priority" operates on entangled Connections
as in msg-priority: when allocating available network capacity among
Connections in a Connection Group, sends on Connections with higher
Priority values will be prioritized over sends on Connections with
lower Priority values.  An ideal transport system implementation
would assign each Connection the capacity share (M-N) x C / M, where
N is the Connection's Priority value, M is the maximum Priority value
used by all Connections in the group and C is the total available
capacity.  However, the Priority setting is purely advisory, and no
guarantees are given about the way capacity is shared.  Each
implementation is free to implement a way to share capacity that it
sees fit.
Paragraph (version A):
Like all Actions in this interface, the Send Action is asynchronous.
There are several Events that can be delivered in response to Sending
a Message.  Exactly one Event (Sent, Expired, or SendError) will be
delivered in reponse to each call to Send.
Paragraph (version B):
All data sent with the same MessageContext object will be treated as
belonging to the same Message, and will constitute an in-order series
until the endOfMessage is marked.
Paragraph (version A):
In some cases it may be valuable to know whether data was read as
part of early data transfer (before connection establishment has
finished).  This is useful if applications need to treat early data
separately, e.g., if early data has different security properties
than data sent after connection establishment.  In the case of TLS
Thus, receivers may wish to perform additional checks for early data
to ensure it is idempotent or not replayed.  If TLS 1.3 is available
and the recipient Message was sent as part of early data, the
corresponding metadata carries a flag indicating as such.  If early
data is enabled, applications should check this metadata field for
Messages received during connection establishment and respond
accordingly.
Paragraph (version B):
In some cases it may be valuable to know whether data was read as
part of early data transfer (before connection establishment has
finished).  This is useful if applications need to treat early data
separately, e.g., if early data has different security properties
than data sent after connection establishment.  In the case of TLS
Thus, receivers may wish to perform additional checks for early data
to ensure it is safely replayable.  If TLS 1.3 is available and the
recipient Message was sent as part of early data, the corresponding
metadata carries a flag indicating as such.  If early data is
enabled, applications should check this metadata field for Messages
received during connection establishment and respond accordingly.
Paragraph (version B):
The connection should only attempt to migrate between different
paths when the original path is lost or becomes unusable.  The
actual thresholds to declare a path unusable are implementation
specific.
Paragraph (version B):
The connection should attempt to use multiple paths in parallel in
order to minimize loss and delay.  The actual strategy is
implementation specific.
Paragraph (version B):
The connection should attempt to use multiple paths in parallel in
order to maximize bandwidth and possibly overcome bandwidth
limitations of the individual paths.  The actual strategy is
implementation specific.
Paragraph (version B):
Note that this is a local choice - the peer endpoint can choose a
different policy.
Paragraph (version B):
Asynchronous introspection is also possible, via the SoftError Event.
This event informs the application about the receipt and contents of
an ICMP error message related to the Connection.  This will only
happen if the underlying protocol stack supports access to soft
errors; however, even if the underlying stack supports it, there is
no guarantee that a soft error will be signaled.
Paragraph (version B):
The following diagram shows the possible states of a Connection and
the events that occur upon a transition from one state to another.
Paragraph (version B):
security protocol should work in a TAPS system.  Security
consideration for these protocols should be discussed in the
respective specifications.
Paragraph (version B):
The desribed API is used to exchange information between an
application and the transport system.  While it is not necessarily
expected that both systems are implemented by the same authority, it
is expected that the transport system implementation is either
provided as a library that is selected by the application from a
trusted party, or that it is part of the operating system that the
application also relies on for other tasks.
Paragraph (version B):
In either case, the TAPS API is an internal interface that is used to
change information locally between two systems.  However, as the
transport system is responsible for network communication, it is in
the position to potentially share any information provided by the
application with the network or another communication peer.  Most of
the information provided over the TAPS API are useful to configure
and select protocols and paths and are not necessarily privacy
sensitive.  Still, there is some information that could be privacy
sensitve because this might reveal usage characteristics and habits
of the user of an application.
Paragraph (version B):
Of course any communication over a network reveals usage
characteristics, as all packets as well as their timing and size are
part of the network-visible wire image RFC8546.  However, the
selection of a protocol and its configuration also impacts which
information is visible, potentially in clear text, and which other
enties can access it.  In most cases information that is provided for
protocol and path selection should not directly translate to
information that is can be observed by network devices on the path.
But there might be specific configuration information that are
intended for path exposure, such as e.g. a DiffServ codepoint
setting, that is either povided directly by the application or
indirectly configured over a traffic profile.
Paragraph (version B):
Further, applications should be aware that communication attempts can
lead to more than one connection establishment.  This is for example
the case when the transport system also excecutes name resolution; or
when support mechanisms such as TURN or ICE are used to establish
connectivity; or if protocols or paths are raised; or if a path fails
and fallback or re-establishment is supported in the transport
system.