Draft: draft-ietf-taps-impl

Commentary: Thanks ! Two comments on the updates .
Paragraph (version A):
Connection objects represent the interface between the application
and the implementation to manage transport state, and conduct data
transfer.  During the process of establishment (conn-establish), the
Connection will be unbound to a specific transport flow, since there
may be multiple candidate Protocol Stacks being raced.  Once the
Connection is established, its interface maps actions and events to
the details of the chosen Protocol Stack.  For example, the same
Connection object may ultimately represent the interface into a TCP
connection, a TLS session over TCP, a UDP flow with fully-specified
local and remote endpoints, a DTLS session, a SCTP stream, a QUIC
stream, or an HTTP/2 stream.
Paragraph (version B):
Connection objects represent the interface between the application
and the implementation to manage transport state, and conduct data
transfer.  During the process of establishment (conn-establish), the
Connection will not be bound to a specific transport flow, since
there may be multiple candidate Protocol Stacks being raced.  Once
the Connection is established, its interface maps actions and events
to the details of the chosen Protocol Stack.  For example, the same
Connection object may ultimately represent the interface into a TCP
connection, a TLS session over TCP, a UDP flow with fully-specified
local and remote endpoints, a DTLS session, a SCTP stream, a QUIC
stream, or an HTTP/2 stream.
Paragraph (version A):
Both Local and Remote Endpoint Candidates must be discovered during
connection establishment.  To support Interactive Connectivity
Establishment (ICE) RFC8445, or similar protocols, that involve out-
of-band indirect signalling to exchange candidates with the Remote
Endpoint, it's important to be able to query the set of candidate
Local Endpoints, and give the protocol stack a set of candidate
Remote Endpoints, before it attempts to establish connections.
Paragraph (version B):
Both Local and Remote Endpoint Candidates must be discovered during
connection establishment.  To support Interactive Connectivity
Establishment (ICE) RFC8445, or similar protocols that involve out-
of-band indirect signalling to exchange candidates with the Remote
Endpoint, it's important to be able to query the set of candidate
Local Endpoints, and give the protocol stack a set of candidate
Remote Endpoints, before it attempts to establish connections.
Paragraph (version A):
Resolving the remote is not a local operation.  It will involve a
directory service, and can require communication with the remote to
rendezvous and exchange peer addresses.  This can expose some or all
of the candidate locals to the remote.
Paragraph (version B):
Resolving the Remote Endpoint is not a local operation.  It will
involve a directory service, and can require communication with the
remote to rendezvous and exchange peer addresses.  This can expose
some or all of the candidate locals to the remote.
Paragraph (version A):
If the Selection Properties do not require a single network interface
or path, but allow the use of multiple paths, the Listener object
should register for incoming traffic on all of the network interfaces
or paths that conform to the Properties.  The set of available paths
can change over time, so the implementation should monitor network
path changes and register and de-register the Listener across all
usable paths.  When using multiple paths, the Listener is generally
expected to use the same port for listening on each.
Paragraph (version B):
If the Selection Properties do not require a single network interface
or path, but allow the use of multiple paths, the Listener object
should register for incoming traffic on all of the network interfaces
or paths that conform to the Properties.  The set of available paths
can change over time, so the implementation should monitor network
path changes, and change the registration of the Listener across all
usable paths as appropriate.  When using multiple paths, the Listener
is generally expected to use the same port for listening on each.
Paragraph (version A):
Protocols that provide the framing (such as length-value protocols,
or protocols that use delimiters) provide data boundaries that may be
longer than a traditional packet datagram.  Each Message for framing
protocols corresponds to a single frame, which may be sent either as
a complete Message, or in multiple parts.
Paragraph (version B):
Protocols that provide the framing (such as length-value protocols,
or protocols that use delimiters) provide data boundaries that may be
longer than the typical datagram.  Each Message for framing protocols
corresponds to a single frame, which may be sent either as a complete
Message, or in multiple parts.
Paragraph (version A):
If a Connection becomes finished before a requested Receive action
can be satisfied, the implementation should deliver any partial
Message content outstanding, or if none is available, an indication
that there will be no more received Messages.
Paragraph (version A):
Several protocols allow sending higher-level protocol or application
data during their protocol establishment, such as TCP Fast Open
RFC7413 and TLS 1.3 RFC8446.  This approach is referred to as sending
Zero-RTT (0-RTT) data.  This is a desirable property, but poses
challenges to an implementation that uses racing during connection
establishment.
Paragraph (version B):
If a Connection finishes before a requested Receive action can be
satisfied, the implementation should deliver any partial Message
content outstanding, or if none is available, an indication that
there will be no more received Messages.
Paragraph (version B):
Several protocols allow sending higher-level protocol or application
data during their protocol establishment, such as TCP Fast Open
RFC7413 and TLS 1.3 RFC8446.  This approach is referred to as sending
Zero-RTT (0-RTT) data.  This is a desirable feature, but poses
challenges to an implementation that uses racing during connection
establishment.
Paragraph (version A):
Message Framers are pieces of code that define simple transformations
between application Message data and raw transport protocol data.  A
Framer can encapsulate or encode outbound Messages, and decapsulate
or decode inbound data into Messages.
Paragraph (version B):
Message Framers are functions that define simple transformations
between application Message data and raw transport protocol data.  A
Framer can encapsulate or encode outbound Messages, and decapsulate
or decode inbound data into Messages.
Paragraph (version A):
While many protocols can be represented as Message Framers, for the
purposes of the Transport Services interface these are ways for
applications or application frameworks to define their own Message
parsing to be included within a Connection's Protocol Stack.  As an
example, TLS can serve the purpose of framing data over TCP, but is
exposed as a protocol natively supported by the Transport Services
interface.
Paragraph (version B):
While many protocols can be represented as Message Framers, for the
purposes of the Transport Services interface these are ways for
applications or application frameworks to define their own Message
parsing to be included within a Connection's Protocol Stack.  As an
example, TLS is exposed as a protocol natively supported by the
Transport Services interface, even though it could also serve the
purpose of framing data over TCP.
Paragraph (version A):
A Message Framer is primarily defined by the set of code that handles
events for a framer implementation, specifically how it handles
inbound and outbound data parsing.  The piece of code that implements
custom framing logic will be referred to as the "framer
implementation", which may be provided by the Transport Services
implementation or the application itself.  The Message Framer refers
to the object or piece of code within the main Connection
implementation that delivers events to the custom framer
implementation whenever data is ready to be parsed or framed.
Paragraph (version B):
A Message Framer is primarily defined by the code that handles events
for a framer implementation, specifically how it handles inbound and
outbound data parsing.  The function that implements custom framing
logic will be referred to as the "framer implementation", which may
be provided by the Transport Services implementation or the
application itself.  The Message Framer refers to the object or
function within the main Connection implementation that delivers
events to the custom framer implementation whenever data is ready to
be parsed or framed.
Paragraph (version A):
The set of Connection Properties that are supported for setting and
getting on a Connection are described in I-D.ietf-taps-interface.
For any properties that are generic, and thus could apply to all
protocols being used by a Connection, the Transport System should
store the properties in a generic storage, and notify all protocol
instances in the Protocol Stack whenever the properties have been
modified by the application.  For protocol-specfic properties, such
as the User Timeout that applies to TCP, the Transport System only
needs to update the relevant protocol instance.
Paragraph (version B):
The set of Connection Properties that are supported for setting and
getting on a Connection are described in I-D.ietf-taps-interface.
For any properties that are generic, and thus could apply to all
protocols being used by a Connection, the Transport System should
store the properties in storage common to all protocols, and notify
all protocol instances in the Protocol Stack whenever the properties
have been modified by the application.  For protocol-specfic
properties, such as the User Timeout that applies to TCP, the
Transport System only needs to update the relevant protocol instance.
Paragraph (version A):
For protocols that do not support multipath or migration, the
Protocol Instances should be informed of the path change, but should
not be forcibly disconnected if the previously used path becomes
unavailable.
Paragraph (version A):
There are many common user scenarios that can lead to a path becoming
temporarily unavailable, and then recovering before the transport
protocol reaches a timeout error.  These are particularly common
using mobile devices.  Examples include: an Ethernet cable becoming
unplugged and then plugged back in; a device losing a Wi-Fi signal
while a user is in an elevator, and reattaching when the user leaves
the elevator; and a user losing the radio signal while riding a train
through a tunnel.  If the device is able to rejoin a network with the
same IP address, a stateful transport connection can generally
resume.  Thus, while it is useful for a Protocol Instance to be aware
of a temporary loss of connectivity, the Transport Services
implementation should not aggressively close connections in these
scenarios.
Paragraph (version B):
For protocols that do not support multipath or migration, the
Protocol Instances should be informed of the path change, but should
not be forcibly disconnected if the previously used path becomes
unavailable.  There are many common user scenarios that can lead to a
path becoming temporarily unavailable, and then recovering before the
transport protocol reaches a timeout error.  These are particularly
common using mobile devices.  Examples include: an Ethernet cable
becoming unplugged and then plugged back in; a device losing a Wi-Fi
signal while a user is in an elevator, and reattaching when the user
leaves the elevator; and a user losing the radio signal while riding
a train through a tunnel.  If the device is able to rejoin a network
with the same IP address, a stateful transport connection can
generally resume.  Thus, while it is useful for a Protocol Instance
to be aware of a temporary loss of connectivity, the Transport
Services implementation should not aggressively close connections in
these scenarios.
Paragraph (version A):
Calling "Clone" on a TCP Connection creates a new Connection with
equivalent parameters.  These Connections, and Connections
generated via later calls to "Clone" on one of them, form a
Connection Group.  To realize "entanglement" for these
Connections, with the exception of "Connection Priority", changing
a Connection Property on one of them must affect the Connection
Properties of the others too.  No guarantees of honoring the
Connection Property "Connection Priority" are given, and thus it
is safe for an implementation of a transport system to ignore this
property.  When it is reasonable to assume that Connections
traverse the same path (e.g., when they share the same
encapsulation), support for it can also experimentally be
implemented using a congestion control coupling mechanism (see for
example TCP-COUPLING or RFC3124).
Paragraph (version B):
Calling "Clone" on a TCP Connection creates a new Connection with
equivalent parameters.  These Connections, and Connections
generated via later calls to "Clone" on one of them, form a
Connection Group.  To realize entanglement for these Connections,
with the exception of "Connection Priority", changing a Connection
Property on one of them must affect the Connection Properties of
the others too.  No guarantees of honoring the Connection Property
"Connection Priority" are given, and thus it is safe for an
implementation of a transport system to ignore this property.
When it is reasonable to assume that Connections traverse the same
path (e.g., when they share the same encapsulation), support for
it can also experimentally be implemented using a congestion
control coupling mechanism (see for example TCP-COUPLING or
RFC3124).