Draft: draft-ietf-taps-arch

Commentary: This proposal consolidates normative language into the section on design principles ( now requirements ) , using the suggestions in . 
 Please review the latest updates ! 
 Early art - art review of draft - ietf - taps - architecture My first observation and request is that the group rethink the separation of the architecture and interface documents . It is a warning - sign that the interface document is a normative reference for the architecture document . As the documents are currently constructed , a new reader can not grasp the architecture without inferring some of it through reading the interface . Consider reformulating the architecture document as an overview - introduce principles , concepts , and terminology , but do n't attempt to be normative . ( There are signs that this may already be , or have been , a path the document was being pushed towards ) . If nothing else , rename it , and acknowledge that the actual architecture is specified using the interface definition . Note that the first sentence of the Overview in the interface document also highlights the current structural problem . 
 I do n't entirely agree with this ART - ART comment : I think I might well agree with moving more of the description to this  document , but as discussed before , I also think it useful here to set the actual requirements for the architecture , and to define the architecture . It may need to be much clearer that this architecture consists of more the API . 
 For completeness , this is the first statement of the interface document review : This document reads fairly well . I have some structural concerns ( see the early review of the architecture document ) . In particular I think this document contains the actual definition of the architecture and some of that is inferential . 
 Discussion at September 2021 interim : pass through this document with a view toward making it a high level introduction , not an architecture definition : " An Introduction to the Transport Services Architecture " . remove normative language from this document ( moving it to API , where necessary ) . move details not useful in a high level intro to API . 
 I disagree with this conclusion at first pass — we did a specific analysis and pass on this over a year ago , with PR . The normative language and the standards - track aspect was very intentional and something the WG had consensus on . The point is that the API is a specific incarnation of the TAPS architecture , but there are overarching architectural properties that go beyond a specific abstract API . 
 I completely agree with  here , and recommend we fix this in . We should also of course check for any stray text or missing concepts . I think it would also be useful to somehow better explain that in figure 3 the API function is ONE part of the system . 
 See linked PR first please to see if this resolves this ? 
 A PR was merged that addressed important text issues with separation of requirements and overview , and should more clearly set out that the requirements are for the system . The question of whether the overall TAPS systems requirements belong in this ID ; the API ; or a separate RFC needs some discussion based on the review , before this can be closed . 
 Many good text improvements in the PR but I noticed two smaller updates in the PR that I think were incorrect . Fixed in 
 The review comment showed were many places where the wording of architecture can be improved . There are some high level principles that I think should remain in the architecture document . The decision in today 's interim is to review the architecture to get this more into a shape that is valuable as a reference , and then check the updated draft . 
 I now suggest the issues are addressed and we close this issue without moving text between documents 
 I agree with that ; closing . 
 Overall review : I think we need to keep the normative language for the key features that differentiate the API . I 'd really like to use REQUIRED , RECOMMENDED , rather MUST and SHOULD - because these are not protocol operation requirements , but are implementation requirements to conform . This includes requirements based on Minset - where the WG dervied this API : This is after all why the WG worked on Minset as the basis of the API . I suggest we group all the requirements on architecture as short one or two sentence blocks ( preferably as a bullet or definition list ) collected into a single subsection , so they are easy to find and read and we say that these are the key architectural requirements . We insert this new requirements text either their own section , or in section 1.3 ( although I am open to other places where we can call - out the architectural requirements ) . The following are key requirements , that define the TAPS architecture : It is RECOMMENDED that functionality that is common across multiple transport protocols is made accessible through a unified set of TAPS interface calls . As a baseline , a Transport Services system interface is REQUIRED to allow access to the minimal set of features offered by transport protocols { { ? I - D.ietf - taps - minset } } . A Transport Services system automates the selection of protocols and features and network , based on a set of Properties supplied through the TAPS interface . It is RECOMMENDED that a Transport Services system offers Properties that are common to multiple transport protocols . Specifying common Properties enables a system to appropriately select between protocols that offer equivalent features . This design permits evolution of the transport protocols and functions without affecting the programs using the system . Specifying common Properties enables a Transport Services system to appropriately select an appropriate network interface . It is RECOMMENDED that a system offers Properties that are common to a variety network layer interfaces and paths . This design permits racing of different network paths without affecting the programs using the system . Applications using the Transport Services system interface are REQUIRED to be robust to the automated selection provided by the system , including the possibility to express requirements and preferences that constrain the choices that can be made by the system . If two different Protocol Stacks can be safely swapped , or raced in parallel ( see Section 4.2.2 ) , by the Transport Services system then they are considered to be " equivalent " . Equivalent Protocol Stacks need to meet the requirements for racing specified in section XX . Applications using a Transport Services system MAY explicitly require or prevent the use of specific transport features ( and transport protocols ) and XXXinterfaces using the " REQUIRED " and " PROHIBIT " preferences . This allows an application to constrain the set of protocols and features that will be selected for the transport service . It is RECOMMENDED that the default usage by applications does not necessarily restrict this selection , so that the system can make informed choices ( e.g. , based on the availability of interfaces or set of transport protocols available for the specified remote endpoint ) . When a Transport Services system races between two different   , both SHOULD use the same security protocols and options . However , a Transport Services system MAY race different security protocols , e.g. , if the application explicitly specifies that it considers them equivalent . Transport Services systems MUST NOT automatically fall back from secure protocols to insecure protocols , or to weaker versions of secure protocols . A Transport Services system MAY allow applications to specify that fallback to a specific other version of a protocol is allowed . It is RECOMMENDED that in normal use , a Transport Services system is designed so that all selection decisions result in consistent choices for the same network conditions when they have the same set of preferences . This is intended to provide predictable outcomes to the application using the transport service . I would then suggest to use lower case within other parts of the document - except were pointed to from here , ( we could refer to the requirements subsection , if we thought necessary ) . 
 for discussion at the interim , but IMO we could start the interim with a PR based on these suggestions and work from there . 
 I suspect that we need more protocol - specific properties to be able to talk to various kinds of native protocol peers ( other than TCP and UDP : these should already work fine with what we have , I believe ) . A concrete example : we 're hiding stream numbers . In NEAT , we needed to make them configurable though , because we wanted a NEAT client to be able to talk to a native SCTP server , where an application may expect certain type of data to arrive via a certain stream number . I suspect that we may need something similar for a QUIC peer . Should we address this ? ( I 'd say yes ) How .. is it a protocol - specific ( per - Message ) property ? ( I 'd say yes ... and perhaps a per - Connection property too , with text explaining that the per - Message one automatically becomes the Connection default unless otherwise specified ) What other such things are we missing ... what other expectations may e.g. a native QUIC or SCTP application have that we just can not fulfil with our current system ?
Paragraph (version A):
design explains the design principles behind the Transport
Services API.  These principles are intended to make sure that
transport protocols can continue to be enhanced and evolve without
requiring too many changes by application developers.
Paragraph (version B):
requirements explains the fundamental requirements for a Transport
Services API.  These principles are intended to make sure that
transport protocols can continue to be enhanced and evolve without
requiring significant changes by application developers.
Paragraph (version A):
There are several degrees in which a Transport Services system is
intended to offer flexibility to an application: it can provide
access to multiple sets of protocols and protocol features; it can
use these protocols across multiple paths that could have different
performance and functional characteristics; and it can communicate
with different remote systems to optimize performance, robustness to
failure, or some other metric.  Beyond these, if the API for the
system remains the same over time, new protocols and features could
be added to the system's implementation without requiring changes in
applications for adoption.
Paragraph (version A):
Functionality that is common across multiple transport protocols
ought to be accessible through a unified set of API calls.  An
application using a Transport Services API can implement logic for
its basic use of transport networking (establishing the transport,
and sending and receiving data) once, and expect that implementation
to continue to function as the transports change.
Paragraph (version A):
As a baseline, any Transport Services API needs to allow access to
the distilled minimal set of features offered by transport protocols
I-D.ietf-taps-minset.
Paragraph (version A):
There are applications that will need to control fine-grained details
of transport protocols to optimize their behavior and ensure
compatibility with remote systems.  A Transport Services system
therefore ought to also permit more specialized protocol features to
be used.  The interface for these specialized options ought to be
exposed differently from the common options to ensure flexibility.
Paragraph (version B):
There are several degrees in which a Transport Services system is
intended to offer flexibility to an application: it can provide
access to multiple sets of protocols and protocol features; it can
use these protocols across multiple paths that could have different
performance and functional characteristics; and it can communicate
with different remote systems to optimize performance, robustness to
failure, or some other metric.  Beyond these, if the API for the
system remains the same over time, new protocols and features can be
added to the system's implementation without requiring changes in
applications for adoption.
Paragraph (version B):
The normative requirements described here allow Transport Services
APIs and Implementations to provide this functionlity without causing
incompatibility or introducing security vulnerabilities.  The rest of
this document describes the architecture non-normatively.
Paragraph (version B):
Any functionality that is common across multiple transport protocols
SHOULD be made accessible through a unified set of Transport Services
API calls.  As a baseline, any Transport Services API MUST allow
access to the minimal set of features offered by transport protocols
I-D.ietf-taps-minset.
Paragraph (version B):
An application can specify constraints and preferences for the
protocols, features, and network interfaces it will use via
Properties.  A Transport Services API SHOULD offer Properties that
are common to multiple transport protocols, in order to enable the
system to appropriately select between protocols that offer
equivalent features.  Similarly, a Transport Services API SHOULD
offer Properties that are applicable to a variety of network layer
interfaces and paths, in order to permit racing of different network
paths without affecting the applications using the system.  Each
Property is expected to have a default value.
Paragraph (version B):
The default values for Properties SHOULD be selected to ensure
correctness for the widest set of applications, while providing the
widest set of options for selection.  For example, since both
applications that require reliability and those that do not require
reliability can function correctly when a protocol provides
reliability, reliability ought to be enabled by default.  As another
example, the default value for a Property regarding the selection of
network interfaces ought to permit as many interfaces as possible.
Paragraph (version B):
Applications using a Transport Services system interface are REQUIRED
to be robust to the automated selection provided by the system, where
the automated selection is constrained by the requirements and
preferences expressed by the application.
Paragraph (version B):
There are applications that will need to control fine-grained details
of transport protocols to optimize their behavior and ensure
compatibility with remote systems.  A Transport Services system
therefore SHOULD permit more specialized protocol features to be
used.
Paragraph (version A):
The Transport Services API is envisioned as the abstract model for a
family of APIs that share a common way to expose transport features
and encourage flexibility.  The abstract API definition I-D.ietf-
taps-interface describes this interface and how it can be exposed to
application developers.
Paragraph (version A):
Implementations that provide the Transport Services API I-D.ietf-
taps-impl will vary due to system-specific support and the needs of
the deployment scenario.  It is expected that all implementations of
Transport Services will offer the entire mandatory API.  All
implementations are expected to offer an API that is sufficient to
use the distilled minimal set of features offered by transport
protocols I-D.ietf-taps-minset, including API support for TCP and UDP
transport.  However, some features provided by this API will not be
functional in certain implementations.  For example, it is possible
that some very constrained devices might not have a full TCP
implementation beneath the API.
Paragraph (version A):
To preserve flexibility and compatibility with future protocols, top-
level features in the Transport Services API ought to avoid
referencing particular transport protocols.  The mappings of these
API features to specific implementations of each feature is explained
in the I-D.ietf-taps-impl along with the implications of the feature
on existing protocols.  It is expected that I-D.ietf-taps-interface
will be updated and supplemented as new protocols and protocol
features are developed.
Paragraph (version A):
It is important to note that neither the Transport Services API I-
D.ietf-taps-interface nor the Implementation document I-D.ietf-taps-
impl define new protocols or protocol capabilities that affect what
is communicated across the network.  Use of a Transport Services
system does not require that a peer on the other side of a connection
uses the same API or implementation.  A Transport Services system
acting as a connection initiator can communicate with any existing
system that implements the transport protocol(s) selected by the
Transport Services system.  Similarly, a Transport Services system
acting as a listener can receive connections for any protocol that is
supported by the system from existing initiators that implement the
protocol, independent of whether the initiator uses Transport
Services as well or not.
Paragraph (version B):
A Transport Services implementation can select Protocol Stacks based
on the Properties communicated by the application.  If two different
Protocol Stacks can be safely swapped, or raced in parallel (see
racing), then they are considered to be "equivalent".  Equivalent
Protocol Stacks are defined as stacks that can provide the same
transport properties and interface expectations as requested by the
application.
Paragraph (version B):
If the application requires preservation of message boundaries, a
Protocol Stack that runs UDP as the top-level interface to the
application is not equivalent to a Protocol Stack that runs TCP as
the top-level interface.  A UDP stack would allow an application
to read out message boundaries based on datagrams sent from the
remote system, whereas TCP does not preserve message boundaries on
its own, but needs a framing protocol on top to determine message
boundaries.
Paragraph (version B):
If the application specifies that it requires reliable
transmission of data, then a Protocol Stack using UDP without any
reliability layer on top would not be allowed to replace a
Protocol Stack using TCP.
Paragraph (version B):
If the application does not require reliable transmission of data,
then a Protocol Stack that adds reliability could be regarded as
an equivalent Protocol Stack as long as providing this would not
conflict with any other application-requested properties.
Paragraph (version B):
To ensure that security protocols are not incorrectly swapped,
Transport Services systems MUST only select Protocol Stacks that meet
application requirements (I-D.ietf-taps-transport-security).  Systems
SHOULD only race Protocol Stacks where the transport security
protocols within the stacks are identical.  Transport Services
systems MUST NOT automatically fall back from secure protocols to
insecure protocols, or to weaker versions of secure protocols.  A
Transport Services system MAY allow applications to explicitly
specify that fallback to a specific other version of a protocol is
allowed, e.g., to allow fallback to TLS 1.2 if TLS 1.3 is not
available.
Paragraph (version B):
It is important to note that neither the Transport Services API I-
D.ietf-taps-interface nor the Implementation document I-D.ietf-taps-
impl define new protocols or protocol capabilities that affect what
is communicated across the network.  Use of a Transport Services
system MUST NOT require that a peer on the other side of a connection
uses the same API or implementation.  A Transport Services system
acting as a connection initiator is able to communicate with any
existing system that implements the transport protocol(s) and all the
required properties selected by the Transport Services system.
Similarly, a Transport Services system acting as a listener can
receive connections for any protocol that is supported by the system
from existing initiators that implement the protocol, independent of
whether the initiator uses a Transport Services system or not.
Paragraph (version B):
In normal use, a Transport Services system SHOULD result in
consistent protocol and interface selection decisions for the same
network conditions given the same set of Properties.  This is
intended to provide predictable outcomes to the application using the
API.
Paragraph (version A):
The Transport Services architecture defines a mechanism that allows
applications to easily make use of various network paths and Protocol
Stacks without requiring major changes in application logic.  In some
cases, changing which Protocol Stacks or network paths are used will
require updating the preferences expressed by the application that
uses the Transport Services system.  For example, an application can
enable the use of a multipath or multistreaming transport protocol by
modifying the properties in its Pre-Connection configuration.  In
some cases, however, the Transport Services system will be able to
automatically change Protocol Stacks without an update to the
application, either by selecting a new stack entirely, or by racing
multiple candidate Protocol Stacks during connection establishment.
This functionality in the API can be a powerful driver of new
protocol adoption, but needs to be constrained carefully to avoid
unexpected behavior that can lead to functional or security problems.
Paragraph (version A):
Both stacks MUST offer the interface requested by the application
for connection establishment and data transmission.  For example,
if an application requires preservation of message boundaries, a
Protocol Stack that runs UDP as the top-level interface to the
application is not equivalent to a Protocol Stack that runs TCP as
the top-level interface.  A UDP stack would allow an application
to read out message boundaries based on datagrams sent from the
remote system, whereas TCP does not preserve message boundaries on
its own, but needs a framing protocol on top to determine message
boundaries.
Paragraph (version A):
Both stacks MUST offer the transport services that are requested
by the application.  For example, if an application specifies that
it requires reliable transmission of data, then a Protocol Stack
using UDP without any reliability layer on top would not be
allowed to replace a Protocol Stack using TCP.  However, if the
application does not require reliability, then a Protocol Stack
that adds reliability could be regarded as an equivalent Protocol
Stack as long as providing this would not conflict with any other
application-requested properties.
Paragraph (version A):
Both stacks MUST offer security protocols and parameters as
requested by the application I-D.ietf-taps-transport-security.
Security features and properties, such as cryptographic
algorithms, peer authentication, and identity privacy vary across
security protocols, and across versions of security protocols.
Protocol equivalence ought not to be assumed for different
protocols or protocol versions, even if they offer similar
application configuration options.  To ensure that security
protocols are not incorrectly swapped, Transport Services systems
SHOULD only automatically generate equivalent Protocol Stacks when
the transport security protocols within the stacks are identical.
Specifically, a Transport Services system would consider protocols
identical only if they are of the same type and version.  For
example, the same version of TLS running over two different
transport Protocol Stacks are considered equivalent, whereas TLS
1.2 and TLS 1.3 RFC8446 are not considered equivalent.  However,
Transport Services systems MAY allow applications to indicate that
they consider two different transport protocols equivalent, e.g.,
to allow fallback to TLS 1.2 if TLS 1.3 is not available.
Paragraph (version A):
As described above in equivalence, if a Transport Services system
races between two different Protocol Stacks, both SHOULD use the same
security protocols and options.  However, a Transport Services system
MAY race different security protocols, e.g., if the application
explicitly specifies that it considers them equivalent.
Paragraph (version B):
As described above in equivalence, if a Transport Services system
races between two different Protocol Stacks, both need to use the
same security protocols and options.  However, a Transport Services
system can race different security protocols, e.g., if the
application explicitly specifies that it considers them equivalent.
Paragraph (version A):
Moreover, Transport Services systems MUST NOT automatically fall back
from secure protocols to insecure protocols, or to weaker versions of
secure protocols.  For example, if an application requests a specific
version of TLS, but the desired version of TLS is not available, its
connection will fail.  Applications are thus responsible for
implementing security protocol fallback or version fallback by
creating multiple Transport Services Connections, if so desired.