Draft: draft-ietf-taps-impl

Commentary: This is a follow - up issue for – As we have the ready to support connection coalescing and connection pooling , we have to describe it more closely in the Implementation . 
 Thanks for the fixes - I think this can be merged now . LGTM And : thanks for doing this ! This can make the transport system a lot more powerful , and it 's good to tell people about these interesting implementation options this draft , IMO .
Paragraph (version A):
If a leaf node has successfully completed its connection, all other
attempts should be made ineligible for use by the application for the
original request.  New connection attempts that involve transmitting
data on the network should not be started after another leaf node has
completed successfully, as the connection as a whole has been
established.  An implementation may choose to let certain handshakes
and negotiations complete in order to gather metrics to influence
future connections.  Similarly, an implementation may choose to hold
onto fully established leaf nodes that were not the first to
establish for use in future connections, but this approach is not
recommended since those attempts were slower to connect and may
exhibit less desirable properties.
Paragraph (version B):
If a leaf node has successfully completed its connection, all other
attempts should be made ineligible for use by the application for the
original request.  New connection attempts that involve transmitting
data on the network should not be started after another leaf node has
completed successfully, as the connection as a whole has been
established.  An implementation may choose to let certain handshakes
and negotiations complete in order to gather metrics to influence
future connections.  Similarly, an implementation may choose to hold
onto fully established leaf nodes that were not the first to
establish for use as part of a Pooled Connection, see pooled-
connections, or in future connections.  In both cases, keeping
additional connections is generally not recommended since those
attempts were slower to connect and may exhibit less desirable
properties.
Paragraph (version B):
For protocols that employ request/response pairs and do not require
in-order delivery of the responses, like HTTP, the transport
implementation may distribute interactions across several underlying
transport connections.  For these kinds of protocols, implementations
may hide the connection management and only expose a single
Connection object and the individual requests/responses as messages.
These Pooled Connections can use multiple connections or multiple
streams of multi-streaming connections between endpoints, as long as
all of these satisfy the requirements, and prohibitions specified in
the Selection Properties of the Pooled Connection.  This enables
implementations to realize transparent connection coalescing,
connection migration, and to perform per-message endpoint and path
selection by choosing among these underlying connections.
Paragraph (version A):
When a path change occurs, the Transport Services implementation is
responsible for notifying Protocol Instances in the Protocol Stack.
If the Protocol Stack includes a transport protocol that supports
multipath connectivity, an update to the available paths should
inform the Protocol Instance of the new set of paths that are
permissible based on the Selection Properties passed by the
application.  A multipath protocol can establish new subflows over
new paths, and should tear down subflows over paths that are no
longer available.  If the Protocol Stack includes a transport
protocol that does not support multipath, but support migrating
between paths, the update to available paths can be used as the
trigger to migrating the connection.  For protocols that do not
support multipath or migration, the Protocol Instances may be
informed of the path change, but should not be forcibly disconnected
if the previously used path becomes unavailable.  An exception to
this case is if the System Policy changes to prohibit traffic from
the Connection based on its properties, in which case the Protocol
Stack should be disconnected.
Paragraph (version B):
When a path change occurs, the Transport Services implementation is
responsible for notifying Protocol Instances in the Protocol Stack.
If the Protocol Stack includes a transport protocol that supports
multipath connectivity, an update to the available paths should
inform the Protocol Instance of the new set of paths that are
permissible based on the Selection Properties passed by the
application.  A multipath protocol can establish new subflows over
new paths, and should tear down subflows over paths that are no
longer available.  Pooled Connections pooled-connections may add or
remove underlying transport connections in a similar manner.  If the
Protocol Stack includes a transport protocol that does not support
multipath, but support migrating between paths, the update to
available paths can be used as the trigger to migrating the
connection.  For protocols that do not support multipath or
migration, the Protocol Instances may be informed of the path change,
but should not be forcibly disconnected if the previously used path
becomes unavailable.  An exception to this case is if the System
Policy changes to prohibit traffic from the Connection based on its
properties, in which case the Protocol Stack should be disconnected.