Draft: draft-ietf-taps-arch

Commentary: Apologies for not organising these better -- this train journey is too short to subdivide before I arrive . § 1 , 1st para : " imitated being the BSD socket ( ) [ POSIX ] interface . " -"imitated being the Berkeley sockets interface [ POSIX ] " § 2.1 , 1st para : discussion of async uses of sockets , immediately after saying sockets provide a blocking sycnhronous interface , confuses . It should maybe say " When emulating an asynchronous interface using sockets ... " rather than " Wehn sockets are presented as an asynchronous interface ... " ? § 2.1 , 4th para : " Using asynchronous events allows for a much simpler interaction model when establishing connections and transferring data " . This depends on the programming language , surely ? For simple cases , if you do n't care about performance and advanced features , the synchronous model is easier to use . Maybe " ... a more natural interaction model " since it better reflects the underlying behaviour ? § 2.2 , 2nd para : " Messages seamlessly work with transport protocols that support datagrams or records , but can also be used over a stream by defining an application - layer framer " . This make it seem like each application needs to define its own framers when using the TAPS , but I 'd expect most framers to be introduced implicitly by the stack and it to be unusual for them to be provided by the application . That is , the applications says " I want an HTTP connection " and the stack then implicitly figures out HTTP/2 - TLS - TCP vs HTTP/3 - QUIC and inserts the appropriate framers itself . § 3.2 , 2nd para : " if the API allows an application to specify a preference for constrained checksum usage , communication would not fail when a protocol such as TCP is selected , which uses a checksum covering the entire payload " - what 's a constrained checksum ? Does this mean partial checksums over only part of the packet ? Figure 4 : should this also show send calls , receive events , Messages , and other events in Established ? I understand that it 's just showing lifetime related events , but it seems incomplete because of that , and the later sections introduce objects not shown in the diagram . §  : rename the subsection to " Connection - related Objects " since it 's broader than just Connection ? § 4.1.1 : Can Connection Properties be specified on a Preconnection ? Can Message Properties be specified on a Preconnection or Connection , or only on Messages ? § 4.1.1 specifies that a  is creared from a Preconnection , but does n't say that a Connection is created from a Preconneciton or a  . Should it ? § 4.1.2 : " An Endpoint can be specified at various levels " - what 's a level here ? § 4.1.2 , 1st bullet : " with wider scope ( such as a hostname ) " -- a hostname does n't necessarily have wider scope than an IP address . It might be more abstract . § 4.1.2 Selection Properties : " a Wi - Fi Ethernet connection " ? § 4.1.2 Connection Properties : " Connection Properties SHOULD be specified on a Preconnection prior to Connection establishment , but MAY be modified later " -- modified on the Preconnection later , or modified on the Connection object after it 's been established ? § 4.1.2 Connection Properties : " Such changes do not affect protocol or path selection , but only modify the manner in which a connection sends and receives data " -- might this cause the connection to select a different path ? I can imagine setting certain properties might make certain paths unviable in a way that the transport could detect . § 4.1.3 Initiate : " for other protocols , this will just establish local state " - it might be worth giving an example here , since otherwise it could be interpreted as being like a Listen , or saying " for connectionless protocols ... " ? § 4.1.3 Listen : " The action of marking a  as willing to accept incoming Connections " -- phrasing is cumbersome , maybe just " Enables a  to accept incoming Connections " ? § 4.1.3 Listen : " Listeners by default register with multiple paths , protocols , and local endpoints , unless constrained by Selection Properties " -- does n't this depend on the Local Endpoint too ? § 4.1.3 Rendezvous : TCP simultaneous open is one type of rendezvous , but only giving this as an example makes it seems more narrowly scoped that I envisaged . For example , I 'd expect Rendezvous could perform an ICE exchange it STUN candidates were passed as Remote Endpoints . Should this description be generalised ? § 4.1.4 Message : " Boundaries of a Message might or might not be understood or transmitted by transport protocols . Specifically , what one application considers to be multiple Messages sent on a stream - based transport can be treated as a single Message by the application on the other side , and vice versa . " -- I 'm unconvinced by this . A stream protocol , such as TCP , does n't send arbitrary messages , it sends messages framed by some higher layer protocol . The endpoints need to agree on that protocol , and hence on the meaning and boundaries of the messages , if communication is to proceed . § 4.1.4 Message Properties : The initial sentence ( " Message Properties can be used to annotate specific Messages " ) can be read as this is the only way to set properties ; the later text that " Message Properties MAY be set on a Preconnection " then surprises . Maybe combine these and restructure : " Message Properties can be used to annotate specific Messages or can be set on a Preconnection [ or Connection ? ] to specify defaults for future messages . Message Properites might apply to how a Message is sent ... When recieving Messages ... " § 4.1.4 Send : What 's a " partial Message " ? The previous text has spoken only in terms of Messages , and has not hinted that partial messages can be sent . Need prior introduction , if we 're to allow this . It 's not clear that the architecture needs the concept of partial messages ; are there examples of protocols that send partial messages , rather than messages of unknown size that are fragmented by the framer ? § 4.1.5 : " This list is not exhaustive " -- that the list of events is not exhaustive makes sense , but surely we should be able to provide a list of categories of events ? Error events are missing ; are there more ? § 4.1.6 Close : The way this is written suggests that the API does n't support half closed connections . That may be reasonable , but it 's a limitation . If intended , can it be made explicit . § 4.1.6 is the only semantic difference between Close and Abort that one attempts to deliver outstanding data and the other does n't ? It seems unusual that there 's no implication that Close is successful and  is a failure action . § 4.2.1 Path Selection : do the Selection Properties include multiple   and Remote Endpoints ? Or is a Preconnection supplied with a set of Local and Remote Endpoints along with some Selection Properties ? Is Candidate Gathering itself not an operation to be performed by the implementation before a Rendezvous can be performed ? § 4.2.2 Candidate Racing : The term " racing " implies that candidates are tried simultaneously to see which succeeds first . That 's true in some cases , but others probe candidates in a defined order . Should this be phrased as " Candidate Selection and/or Racing " ? § 4.2.4 , 1st para : what 's a " process " in this context ? The term has not been introduced previously .
Paragraph (version A):
Originally, sockets presented a blocking interface for establishing
connections and transferring data.  However, most modern applications
interact with the network asynchronously.  When sockets are presented
as an asynchronous interface, they generally use a try-and-fail
model.  If the application wants to read, but data has not yet been
received from the peer, the call to read will fail.  The application
then waits and can try again later.
Paragraph (version B):
Originally, sockets presented a blocking interface for establishing
connections and transferring data.  However, most modern applications
interact with the network asynchronously.  Emulation of an
asynchronous interface using sockets generally uses a try-and-fail
model.  If the application wants to read, but data has not yet been
received from the peer, the call to read will fail.  The application
then waits and can try again later.
Paragraph (version A):
Using asynchronous events allows for a much simpler interaction model
when establishing connections and transferring data.  Events in time
more closely reflect the nature of interactions over networks, as
opposed to how sockets represent network resources as file system
objects that may be temporarily unavailable.
Paragraph (version B):
Using asynchronous events allows for a more natural interaction model
when establishing connections and transferring data.  Events in time
more closely reflect the nature of interactions over networks, as
opposed to how sockets represent network resources as file system
objects that may be temporarily unavailable.
Paragraph (version A):
The Transport Services API represents data as messages, so that it
more closely matches the way applications use the network.  Messages
seamlessly work with transport protocols that support datagrams or
records, but can also be used over a stream by defining an
application-layer framer (datatransfer).  When framing protocols are
placed on top of unstructured streams, the messages used in the API
represent the framed messages within the stream.  In the absence of a
framer, protocols that deal only in byte streams, such as TCP,
represent their data in each direction as a single, long message.
Paragraph (version A):
Allowing applications to interact with messages is backwards-
compatible with existings protocols and APIs, as it does not change
the wire format of any protocol.  Instead, it gives the protocol
stack additional information to allow it to make better use of modern
transport services, while simplifying the application's role in
parsing data.
Paragraph (version B):
Allowing applications to interact with messages is backwards-
compatible with existings protocols and APIs, as it does not change
the wire format of any protocol.  Instead, it gives the protocol
stack additional information to allow it to make better use of modern
transport services, while simplifying the application's role in
parsing data.  For protocols which natively use a streaming
abstraction, framers (datatransfer) bridge the gap between the two
abstractions.
Paragraph (version A):
A specialized feature could be required by an application only when
using a specific protocol, and not when using others.  For example,
if an application is using UDP, it could require control over the
checksum or fragmentation behavior for UDP; if it used a protocol to
frame its data over a byte stream like TCP, it would not need these
options.  In such cases, the API ought to expose the features in such
a way that they take effect when a particular protocol is selected,
but do not imply that only that protocol could be used.  For example,
if the API allows an application to specify a preference for
constrained checksum usage, communication would not fail when a
protocol such as TCP is selected, which uses a checksum covering the
entire payload.
Paragraph (version B):
A specialized feature could be required by an application only when
using a specific protocol, and not when using others.  For example,
if an application is using UDP, it could require control over the
checksum or fragmentation behavior for UDP; if it used a protocol to
frame its data over a byte stream like TCP, it would not need these
options.  In such cases, the API ought to expose the features in such
a way that they take effect when a particular protocol is selected,
but do not imply that only that protocol could be used.  For example,
if the API allows an application to specify a preference to use a
partial checksum, communication would not fail when a protocol such
as TCP is selected, which uses a checksum covering the entire
payload.
Paragraph (version A):
Connection Properties (preestablishment) that may be changed on
the Connection.
Paragraph (version A):
Message Properties (datatransfer) that can also be specified
during data transfer to affect specific Messages.
Paragraph (version B):
Connection Properties (preestablishment) that can be specified
on a Preconnection and changed on the Connection.
Paragraph (version B):
Message Properties (datatransfer) that can be specified as
defaults on a Preconnection or a Connection, and can also be
specified during data transfer to affect specific Messages.
Paragraph (version A):
Connection: A Connection object represents one or more active
transport protocol instances that can send and/or receive Messages
between local and remote systems.  It holds state pertaining to
the underlying transport protocol instances and any ongoing data
transfers.  This represents, for example, an active connection in
a connection-oriented protocol such as TCP, or a fully-specified
5-tuple for a connectionless protocol such as UDP.  It can also
represent a pool of transport protocol instances, e.g., a set of
TCP and QUIC connections to equivalent endpoints, or a stream of a
multi-streaming transport protocol instance.
Paragraph (version B):
Connection: A Connection object represents one or more active
transport protocol instances that can send and/or receive Messages
between local and remote systems.  It holds state pertaining to
the underlying transport protocol instances and any ongoing data
transfers.  This represents, for example, an active connection in
a connection-oriented protocol such as TCP, or a fully-specified
5-tuple for a connectionless protocol such as UDP.  It can also
represent a pool of transport protocol instances, e.g., a set of
TCP and QUIC connections to equivalent endpoints, or a stream of a
multi-streaming transport protocol instance.  Connections can be
created from a Preconnection or by a Listener.
Paragraph (version A):
Endpoint: An Endpoint represents an identifier for one side of a
transport connection.  Endpoints can be Local Endpoints or Remote
Endpoints, and respectively represent an identity that the
application uses for the source or destination of a connection.
An Endpoint can be specified at various levels, and an Endpoint
with wider scope (such as a hostname) can be resolved to more
concrete identities (such as IP addresses).
Paragraph (version B):
Endpoint: An Endpoint represents an identifier for one side of a
transport connection.  Endpoints can be Local Endpoints or Remote
Endpoints, and respectively represent an identity that the
application uses for the source or destination of a connection.
An Endpoint can be specified at various levels of abstraction, and
an Endpoint at a higher level of abstraction (such as a hostname)
can be resolved to more concrete identities (such as IP
addresses).
Paragraph (version A):
Selection Properties: The Selection Properties consist of the
options that an application can set to influence the selection of
paths between the local and remote systems, to influence the
selection of transport protocols, or to configure the behavior of
generic transport protocol features.  These options can take the
form of requirements, prohibitions, or preferences.  Examples of
options that influence path selection include the interface type
(such as a Wi-Fi Ethernet connection, or a Cellular LTE
connection), requirements around the Maximum Transmission Unit
(MTU) or path MTU (PMTU), or preferences for throughput and
latency properties.  Examples of options that influence protocol
selection and configuration of transport protocol features include
reliability, service class, multipath support, and fast open
support.
Paragraph (version B):
Selection Properties: The Selection Properties consist of the
options that an application can set to influence the selection of
paths between the local and remote systems, to influence the
selection of transport protocols, or to configure the behavior of
generic transport protocol features.  These options can take the
form of requirements, prohibitions, or preferences.  Examples of
options that influence path selection include the interface type
(such as a Wi-Fi connection, or a Cellular LTE connection),
requirements around the Maximum Transmission Unit (MTU) or path
MTU (PMTU), or preferences for throughput and latency properties.
Examples of options that influence protocol selection and
configuration of transport protocol features include reliability,
service class, multipath support, and fast open support.
Paragraph (version A):
Connection Properties: The Connection Properties are used to
configure protocol-specific options and control per-connection
behavior of the Transport System; for example, a protocol-specific
Connection Property can express that if UDP is used, the
implementation ought to use checksums.  Note that the presence of
such a property does not require that a specific protocol will be
used.  In general, these properties do not explicitly determine
the selection of paths or protocols, but MAY be used in this way
by an implementation during connection establishment.  Connection
Properties SHOULD be specified on a Preconnection prior to
Connection establishment, but MAY be modified later.  Changes made
to Connection Properties after establishment take effect on a
best-effort basis.  Such changes do not affect protocol or path
selection, but only modify the manner in which a connection sends
and receives data.
Paragraph (version B):
Connection Properties: The Connection Properties are used to
configure protocol-specific options and control per-connection
behavior of the Transport System; for example, a protocol-specific
Connection Property can express that if UDP is used, the
implementation ought to use checksums.  Note that the presence of
such a property does not require that a specific protocol will be
used.  In general, these properties do not explicitly determine
the selection of paths or protocols, but can be used in this way
by an implementation during connection establishment.  Connection
Properties are specified on a Preconnection prior to Connection
establishment, and can be modified on the Connection later.
Changes made to Connection Properties after Connection
establishment take effect on a best-effort basis.
Paragraph (version A):
Initiate: The primary action that an application can take to
create a Connection to a Remote Endpoint, and prepare any required
local or remote state to enable the transmission of Messages.  For
some protocols, this will initiate a client-to-server style
handshake; for other protocols, this will just establish local
state.  The process of identifying options for connecting, such as
resolution of the Remote Endpoint, occurs in response to the
Initiate call.
Paragraph (version A):
Listen: The action of marking a Listener as willing to accept
incoming Connections.  The Listener will then create Connection
objects as incoming connections are accepted (events).  Listeners
by default register with multiple paths, protocols, and local
endpoints, unless constrained by Selection Properties.
Connections can be accepted on any of the available paths or
endpoints.
Paragraph (version B):
Initiate: The primary action that an application can take to
create a Connection to a Remote Endpoint, and prepare any required
local or remote state to enable the transmission of Messages.  For
some protocols, this will initiate a client-to-server style
handshake; for other protocols, this will just establish local
state (e.g., with connectionless protocols such as UDP).  The
process of identifying options for connecting, such as resolution
of the Remote Endpoint, occurs in response to the Initiate call.
Paragraph (version B):
Listen: Enables a listener to accept incoming Connections.  The
Listener will then create Connection objects as incoming
connections are accepted (events).  Listeners by default register
with multiple paths, protocols, and local endpoints, unless
constrained by Selection Properties and/or the specified Local
Endpoint(s).  Connections can be accepted on any of the available
paths or endpoints.
Paragraph (version A):
Message: A Message object is a unit of data that can be
represented as bytes that can be transferred between two systems
over a transport connection.  The bytes within a Message are
assumed to be ordered within the Message.  If an application does
not care about the order in which a peer receives two distinct
spans of bytes, those spans of bytes are considered independent
Messages.  Boundaries of a Message might or might not be
understood or transmitted by transport protocols.  Specifically,
what one application considers to be multiple Messages sent on a
stream-based transport can be treated as a single Message by the
application on the other side, and vice versa.
Paragraph (version A):
Message Properties: Message Properties can be used to annotate
specific Messages.  These properties might only apply to how a
Message is sent (such as how the transport will treat
prioritization and reliability), but can also include properties
that specific protocols encode and communicate to the Remote
Endpoint.  Message Properties MAY be set on a Preconnection to
define default properties for sending.  When receiving Messages,
Message Properties can contain information about the received
Message, such as metadata generated at the receiver and
information signalled by the remote endpoint.
Paragraph (version A):
Send: The action to transmit a Message or partial Message over a
Connection to the remote system.  The interface to Send MAY
include Message Properties specific to how the Message content is
to be sent.  The status of the Send operation MUST be delivered
back to the sending application in an event (events).
Paragraph (version B):
Message: A Message object is a unit of data that can be
represented as bytes that can be transferred between two systems
over a transport connection.  The bytes within a Message are
assumed to be ordered within the Message.  If an application does
not care about the order in which a peer receives two distinct
spans of bytes, those spans of bytes are considered independent
Messages.
Paragraph (version B):
Message Properties: Message Properties are used to specify details
about Message transmission.  They can be specified directly on
individual Messages, or can be set on a Preconnection or
Connection as defaults.  These properties might only apply to how
a Message is sent (such as how the transport will treat
prioritization and reliability), but can also include properties
that specific protocols encode and communicate to the Remote
Endpoint.  When receiving Messages, Message Properties can contain
information about the received Message, such as metadata generated
at the receiver and information signalled by the remote endpoint.
Paragraph (version B):
Send: The action to transmit a Message over a Connection to the
remote system.  The interface to Send MAY include Message
Properties specific to how the Message content is to be sent.  The
status of the Send operation MUST be delivered back to the sending
application in an event (events).
Paragraph (version A):
This section provides the categories of events that can be delivered
to an application.  This list is not exhaustive.
Paragraph (version A):
Abort: The action the application takes on a Connection to
indicate a Close and also indicate that the transport system
SHOULD NOT attempt to deliver any outstanding data.
Paragraph (version B):
Abort: The action the application takes on a Connection to
indicate a Close and also indicate that the transport system
SHOULD NOT attempt to deliver any outstanding data.  This is
intended for immediate termination of a connection, without
cleaning up state.
Paragraph (version A):
Path Selection: Path Selection represents the act of choosing one
or more paths that are available to use based on the Selection
Properties provided by the application, and the policies and
heuristics of a Transport Services system.
Paragraph (version A):
Protocol Selection: Protocol Selection represents the act of
choosing one or more sets of protocol stacks that are available to
use based on the Transport Properties provided by the application,
and the heuristics or policies within the Transport Services
system.
Paragraph (version A):
Protocol Option Racing: Protocol Racing is the act of attempting
to establish, or scheduling attempts to establish, multiple
Protocol Stacks that differ based on the composition of protocols
or the options used for protocols.
Paragraph (version B):
Candidate Path Selection: Candidate Path Selection represents the
act of choosing one or more paths that are available to use based
on the Selection Properties and any available Local and Remote
Endpoints provided by the application, as well as the policies and
heuristics of a Transport Services system.
Paragraph (version B):
Candidate Protocol Selection: Candidate Protocol Selection
represents the act of choosing one or more sets of protocol stacks
that are available to use based on the Transport Properties
provided by the application, and the heuristics or policies within
the Transport Services system.
Paragraph (version B):
Connection establishment attempts for a set of candidates may be
performed simultaneously, synchronously, serially, or some
combination of all of these.  We refer to this process as racing,
borrowing terminology from Happy Eyeballs RFC8305.
Paragraph (version B):
Protocol Option Racing: Protocol Option Racing is the act of
attempting to establish, or scheduling attempts to establish,
multiple Protocol Stacks that differ based on the composition of
protocols or the options used for protocols.
Paragraph (version A):
By default, all stored properties of the implementation are shared
within a process, such as cached protocol state, cached path state,
and heuristics.  This provides efficiency and convenience for the
application, since the Transport System implementation can
automatically optimize behavior.
Paragraph (version B):
By default, stored properties of the implementation, such as cached
protocol state, cached path state, and heuristics, may be shared
(e.g. across multiple connections in an application).  This provides
efficiency and convenience for the application, since the Transport
System implementation can automatically optimize behavior.