Draft: draft-ietf-taps-interface

Commentary: done ! 
 Also 
 Great , thanks ! 
 " The transport system should have a list of supported protocols available " ... I think this means that the TAPS implementation does this , not that the kernel has any tabular notion of transport properties . If so , I have further suggestions for the wording here . 
 Yes ; I think we had once agreed that this should be " Transport Services system " everywhere , and we ( or at least I ) have been sloppy with this in the API and Implementation drafts . Thanks , this comment makes it clear to me why it 's important to use this term correctly . 
 TAPS -Transport Services 
 I realize that this is a silly discussion to have , and I just do n't care ... but I am curious : why ? 
 Well , mainly because we say " Transport Services " throughout and the term " TAPS " is n't defined . But also because I do n't and never have understood how " TAPS " is an abbreviation of " Transport Services " . If we want to abbreviate it , let 's just use " TS " . 
 Hey , I needed a 4 - letter acronym for a working group , that was all , and I did n't want to have a discussion about something that I considered so unimportant .... also , taps signals the end of the day , when everyone is to go to sleep : So yeah ... as you can see , I really do n't care , I was just curious . Let 's just use " transport services " throughout . And next time I form a WG I 'll really think hard to make a good acronym . :-) 
 +1 to " transport services " everywhere . ( actually i liked the name of the WG  ! ) 
 I 'd always assumed the AP was from API .
Paragraph (version A):
It derives specific path and protocol selection properties and
supported transport features from the analysis provided in RFC8095,
RFC8923, and RFC8922.  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.  The transport system
implementations should provide applications with a way to override
transport selection and instantiate a specific stack, e.g., to
support servers wishing to listen to a specific protocol.  This
specific transport stack choice is discouraged for general use,
because it can reduce the portability.
Paragraph (version B):
It derives specific path and protocol selection properties and
supported transport features from the analysis provided in RFC8095,
RFC8923, and RFC8922.  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.  The Transport Services
system implementations should provide applications with a way to
override transport selection and instantiate a specific stack, e.g.,
to support servers wishing to listen to a specific protocol.  This
specific transport stack choice is discouraged for general use,
because it can reduce the portability.
Paragraph (version A):
At least one Local Endpoint MUST be specified if the Preconnection is
used to Listen() for incoming Connections, but the list of Local
Endpoints MAY be empty if the Preconnection is used to Initiate()
connections.  If no Local Endpoint is specified, the Transport System
will assign an ephemeral local port to the Connection on the
appropriate interface(s).  At least one Remote Endpoint MUST be
specified if the Preconnection is used to Initiate() Connections, but
the list of Remote Endpoints MAY be empty if the Preconnection is
used to Listen() for incoming Connections.  At least one Local
Endpoint and one Remote Endpoint MUST be specified if a peer-to-peer
Rendezvous is to occur based on the Preconnection.
Paragraph (version B):
At least one Local Endpoint MUST be specified if the Preconnection is
used to Listen() for incoming Connections, but the list of Local
Endpoints MAY be empty if the Preconnection is used to Initiate()
connections.  If no Local Endpoint is specified, the Transport
Services system will assign an ephemeral local port to the Connection
on the appropriate interface(s).  At least one Remote Endpoint MUST
be specified if the Preconnection is used to Initiate() Connections,
but the list of Remote Endpoints MAY be empty if the Preconnection is
used to Listen() for incoming Connections.  At least one Local
Endpoint and one Remote Endpoint MUST be specified if a peer-to-peer
Rendezvous is to occur based on the Preconnection.
Paragraph (version A):
Note that this can have privacy implications because it might result
in users being linkable across the 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 _proactive advertisement_ of
addresses.
Paragraph (version B):
Note that this can have privacy implications because it might result
in users being linkable across the multiple paths.  Also, note that
setting this to false does not prevent the local Transport Services
system from _establishing_ connectivity using alternate paths (see
multipath-mode above); it only prevents _proactive advertisement_ of
addresses.
Paragraph (version A):
The most common client-server communication pattern involves the
client actively opening a connection, then sending data to the
server.  The server listens (passive open), reads, and then answers.
This property specifies whether an application wants to diverge from
this pattern - either by actively opening with Initiate(),
immediately followed by reading, or passively opening with Listen(),
immediately followed by writing.  This property is ignored when
establishing connections using Rendezvous().  Requiring this property
limits the choice of mappings to underlying protocols, which can
reduce efficiency.  For example, it prevents the transport system
from mapping Connections to SCTP streams, where the first transmitted
data takes the role of an active open signal I-D.ietf-taps-impl.
Paragraph (version B):
The most common client-server communication pattern involves the
client actively opening a connection, then sending data to the
server.  The server listens (passive open), reads, and then answers.
This property specifies whether an application wants to diverge from
this pattern - either by actively opening with Initiate(),
immediately followed by reading, or passively opening with Listen(),
immediately followed by writing.  This property is ignored when
establishing connections using Rendezvous().  Requiring this property
limits the choice of mappings to underlying protocols, which can
reduce efficiency.  For example, it prevents the Transport Services
system from mapping Connections to SCTP streams, where the first
transmitted data takes the role of an active open signal I-D.ietf-
taps-impl.
Paragraph (version A):
Note that calling Clone() can result in on-the-wire signaling, e.g.,
to open a new connection, depending on the underlying Protocol Stack.
When Clone() leads to multiple connections being opened instead of
multi-streaming, the transport system will ensure consistency of
Connection Properties by uniformly applying them to all underlying
connections in a group.  Even in such a case, there are possibilities
for a transport system to implement prioritization within a
Connection Group TCP-COUPLING RFC8699.
Paragraph (version B):
Note that calling Clone() can result in on-the-wire signaling, e.g.,
to open a new connection, depending on the underlying Protocol Stack.
When Clone() leads to multiple connections being opened instead of
multi-streaming, the Transport Services system will ensure
consistency of Connection Properties by uniformly applying them to
all underlying connections in a group.  Even in such a case, there
are possibilities for a Transport Services system to implement
prioritization within a Connection Group TCP-COUPLING RFC8699.
Paragraph (version A):
This Property is a non-negative integer representing the relative
inverse priority (i.e., a lower value reflects a higher priority) of
this Connection relative to other Connections in the same Connection
Group.  It has no effect on Connections not part of a Connection
Group.  As noted in groups, this property is not entangled when
Connections are cloned, i.e., changing the Priority on one Connection
in a Connection Group does not change it on the other Connections in
the same Connection Group.  No guarantees of a specific behavior
regarding Connection Priority are given; a transport system may
ignore this property.  See priority-in-taps for more details.
Paragraph (version B):
This Property is a non-negative integer representing the relative
inverse priority (i.e., a lower value reflects a higher priority) of
this Connection relative to other Connections in the same Connection
Group.  It has no effect on Connections not part of a Connection
Group.  As noted in groups, this property is not entangled when
Connections are cloned, i.e., changing the Priority on one Connection
in a Connection Group does not change it on the other Connections in
the same Connection Group.  No guarantees of a specific behavior
regarding Connection Priority are given; a Transport Services system
may ignore this property.  See priority-in-taps for more details.
Paragraph (version A):
A transport system can request a protocol that supports sending keep
alive packets keep-alive.  This property specifies the maximum time
an idle connection (one for which no transport packets have been
sent) should wait before the Local Endpoint sends a keep-alive packet
to the Remote Endpoint.  Adjusting this Property will only take
effect when the underlying stack supports sending keep-alive packets.
Guidance on setting this value for datagram transports is provided in
RFC8085.  The special value "Default" means that this timeout will
use the default for the selected transport.  A value greater than the
connection timeout (conn-timeout) will disable the sending of keep-
alive packets.
Paragraph (version B):
A Transport Services system can request a protocol that supports
sending keep alive packets keep-alive.  This property specifies the
maximum time an idle connection (one for which no transport packets
have been sent) should wait before the Local Endpoint sends a keep-
alive packet to the Remote Endpoint.  Adjusting this Property will
only take effect when the underlying stack supports sending keep-
alive packets.  Guidance on setting this value for datagram
transports is provided in RFC8085.  The special value "Default" means
that this timeout will use the default for the selected transport.  A
value greater than the connection timeout (conn-timeout) will disable
the sending of keep-alive packets.
Paragraph (version A):
This property specifies the desired network treatment for traffic
sent by the application and the tradeoffs the application is prepared
to make in path and protocol selection to receive that desired
treatment.  When the capacity profile is set to a value other than
Default, the transport system SHOULD select paths and configure
protocols to optimize the tradeoff between delay, delay variation,
and efficient use of the available capacity based on the capacity
profile specified.  How this is realized is implementation-specific.
The Capacity Profile MAY also be used to set markings on the wire for
Protocol Stacks supporting this.  Recommendations for use with DSCP
are provided below for each profile; note that when a Connection is
multiplexed, the guidelines in Section 6 of RFC7657 apply.
Paragraph (version A):
The application provides no information about its expected
capacity profile.  Transport system implementations that map the
requested capacity profile onto per-connection DSCP signaling
SHOULD assign the DSCP Default Forwarding RFC2474 Per Hop
Behaviour (PHB).
Paragraph (version A):
The application is not interactive.  It expects to send and/or
receive data without any urgency.  This can, for example, be used
to select protocol stacks with scavenger transmission control and/
or to assign the traffic to a lower-effort service.  Transport
system implementations that map the requested capacity profile
onto per-connection DSCP signaling SHOULD assign the DSCP Less
than Best Effort RFC8622 PHB.
Paragraph (version B):
This property specifies the desired network treatment for traffic
sent by the application and the tradeoffs the application is prepared
to make in path and protocol selection to receive that desired
treatment.  When the capacity profile is set to a value other than
Default, the Transport Services system SHOULD select paths and
configure protocols to optimize the tradeoff between delay, delay
variation, and efficient use of the available capacity based on the
capacity profile specified.  How this is realized is implementation-
specific.  The Capacity Profile MAY also be used to set markings on
the wire for Protocol Stacks supporting this.  Recommendations for
use with DSCP are provided below for each profile; note that when a
Connection is multiplexed, the guidelines in Section 6 of RFC7657
apply.
Paragraph (version B):
The application provides no information about its expected
capacity profile.  Transport Services system implementations that
map the requested capacity profile onto per-connection DSCP
signaling SHOULD assign the DSCP Default Forwarding RFC2474 Per
Hop Behaviour (PHB).
Paragraph (version B):
The application is not interactive.  It expects to send and/or
receive data without any urgency.  This can, for example, be used
to select protocol stacks with scavenger transmission control and/
or to assign the traffic to a lower-effort service.  Transport
Services system implementations that map the requested capacity
profile onto per-connection DSCP signaling SHOULD assign the DSCP
Less than Best Effort RFC8622 PHB.
Paragraph (version A):
The application is interactive, and prefers loss to latency.
Response time should be optimized at the expense of delay
variation and efficient use of the available capacity when sending
on this connection.  This can be used by the system to disable the
coalescing of multiple small Messages into larger packets (Nagle's
algorithm); to prefer immediate acknowledgment from the peer
endpoint when supported by the underlying transport; and so on.
Transport system implementations that map the requested capacity
profile onto per-connection DSCP signaling without multiplexing
SHOULD assign a DSCP Assured Forwarding (AF41,AF42,AF43,AF44)
RFC2597 PHB.  Inelastic traffic that is expected to conform to the
configured network service rate could be mapped to the DSCP
Expedited Forwarding RFC3246 or RFC5865 PHBs.
Paragraph (version B):
The application is interactive, and prefers loss to latency.
Response time should be optimized at the expense of delay
variation and efficient use of the available capacity when sending
on this connection.  This can be used by the system to disable the
coalescing of multiple small Messages into larger packets (Nagle's
algorithm); to prefer immediate acknowledgment from the peer
endpoint when supported by the underlying transport; and so on.
Transport Services system implementations that map the requested
capacity profile onto per-connection DSCP signaling without
multiplexing SHOULD assign a DSCP Assured Forwarding
(AF41,AF42,AF43,AF44) RFC2597 PHB.  Inelastic traffic that is
expected to conform to the configured network service rate could
be mapped to the DSCP Expedited Forwarding RFC3246 or RFC5865
PHBs.
Paragraph (version A):
The application expects to send/receive data at the maximum rate
allowed by its congestion controller over a relatively long period
of time.  Transport system implementations that map the requested
capacity profile onto per-connection DSCP signaling without
multiplexing SHOULD assign a DSCP Assured Forwarding
(AF11,AF12,AF13,AF14) RFC2597 PHB per Section 4.8 of RFC4594.
Paragraph (version B):
The application expects to send/receive data at the maximum rate
allowed by its congestion controller over a relatively long period
of time.  Transport Services system implementations that map the
requested capacity profile onto per-connection DSCP signaling
without multiplexing SHOULD assign a DSCP Assured Forwarding
(AF11,AF12,AF13,AF14) RFC2597 PHB per Section 4.8 of RFC4594.
Paragraph (version A):
These properties specify configurations for the User Timeout Option
(UTO), in the case that TCP becomes the chosen transport protocol.
Implementation is optional and useful only if TCP is implemented in
the transport system.
Paragraph (version B):
These properties specify configurations for the User Timeout Option
(UTO), in the case that TCP becomes the chosen transport protocol.
Implementation is optional and useful only if TCP is implemented in
the Transport Services system.
Paragraph (version A):
The Lifetime specifies how long a particular Message can wait to be
sent to the Remote Endpoint before it is irrelevant and no longer
needs to be (re-)transmitted.  This is a hint to the transport system
- it is not guaranteed that a Message will not be sent when its
Lifetime has expired.
Paragraph (version B):
The Lifetime specifies how long a particular Message can wait to be
sent to the Remote Endpoint before it is irrelevant and no longer
needs to be (re-)transmitted.  This is a hint to the Transport
Services system - it is not guaranteed that a Message will not be
sent when its Lifetime has expired.
Paragraph (version A):
Disabling this property indicates that the transport system may
disable retransmissions or other reliability mechanisms for this
particular Message, but such disabling is not guaranteed.
Paragraph (version B):
Disabling this property indicates that the Transport Services system
may disable retransmissions or other reliability mechanisms for this
particular Message, but such disabling is not guaranteed.
Paragraph (version A):
Sent Events allow an application to obtain an understanding of the
amount of buffering it creates.  That is, if an application calls the
Send Action multiple times without waiting for a Sent Event, it has
created more buffer inside the transport system than an application
that always waits for the Sent Event before calling the next Send
Action.
Paragraph (version B):
Sent Events allow an application to obtain an understanding of the
amount of buffering it creates.  That is, if an application calls the
Send Action multiple times without waiting for a Sent Event, it has
created more buffer inside the Transport Services system than an
application that always waits for the Sent Event before calling the
next Send Action.
Paragraph (version A):
Whenever possible, a messageContext should be provided to declare the
Message passed to InitiateWithSend as "Safely Replayable".  This
allows the transport system to make use of 0-RTT establishment in
case this is supported by the available protocol stacks.  When the
selected stack(s) do not support transmitting data upon connection
establishment, InitiateWithSend is identical to Initiate() followed
by Send().
Paragraph (version B):
Whenever possible, a messageContext should be provided to declare the
Message passed to InitiateWithSend as "Safely Replayable".  This
allows the Transport Services system to make use of 0-RTT
establishment in case this is supported by the available protocol
stacks.  When the selected stack(s) do not support transmitting data
upon connection establishment, InitiateWithSend is identical to
Initiate() followed by Send().
Paragraph (version A):
Once a Connection is established, it can be used for receiving data
(unless the "Direction of Communication" property is set to
"unidirectional send").  As with sending, the data is received in
Messages.  Receiving is an asynchronous operation, in which each call
to Receive enqueues a request to receive new data from the
connection.  Once data has been received, or an error is encountered,
an event will be delivered to complete any pending Receive requests
(see receive-events).  If Messages arrive at the transport system
before Receive requests are issued, ensuing Receive requests will
first operate on these Messages before awaiting any further Messages.
Paragraph (version B):
Once a Connection is established, it can be used for receiving data
(unless the "Direction of Communication" property is set to
"unidirectional send").  As with sending, the data is received in
Messages.  Receiving is an asynchronous operation, in which each call
to Receive enqueues a request to receive new data from the
connection.  Once data has been received, or an error is encountered,
an event will be delivered to complete any pending Receive requests
(see receive-events).  If Messages arrive at the Transport Services
system before Receive requests are issued, ensuing Receive requests
will first operate on these Messages before awaiting any further
Messages.
Paragraph (version A):
Close terminates a Connection after satisfying all the requirements
that were specified regarding the delivery of Messages that the
application has already given to the transport system.  For example,
if reliable delivery was requested for a Message handed over before
calling Close, the Closed Event will signify that this Message has
indeed been delivered.  If the Remote Endpoint still has data to
send, it cannot be received after this call.
Paragraph (version B):
Close terminates a Connection after satisfying all the requirements
that were specified regarding the delivery of Messages that the
application has already given to the Transport Services system.  For
example, if reliable delivery was requested for a Message handed over
before calling Close, the Closed Event will signify that this Message
has indeed been delivered.  If the Remote Endpoint still has data to
send, it cannot be received after this call.
Paragraph (version A):
The described 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 A):
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, some information could be privacy sensitive
because it might reveal usage characteristics and habits of the user
of an application.
Paragraph (version B):
The described API is used to exchange information between an
application and the Transport Services system.  While it is not
necessarily expected that both systems are implemented by the same
authority, it is expected that the Transport Services 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 Transport Services API is an internal interface
that is used to change information locally between two systems.
However, as the Transport Services 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
Transport Services API are useful to configure and select protocols
and paths and are not necessarily privacy sensitive.  Still, some
information could be privacy sensitive because it might reveal usage
characteristics and habits of the user of an application.
Paragraph (version A):
Applications should be aware that communication attempts can lead to
more than one connection establishment.  This is the case, for
example, when the transport system also executes name resolution,
when support mechanisms such as TURN or ICE are used to establish
connectivity, if protocols or paths are raised, or if a path fails
and fallback or re-establishment is supported in the transport
system.
Paragraph (version B):
Applications should be aware that communication attempts can lead to
more than one connection establishment.  This is the case, for
example, when the Transport Services system also executes name
resolution, when support mechanisms such as TURN or ICE are used to
establish connectivity, if protocols or paths are raised, or if a
path fails and fallback or re-establishment is supported in the
Transport Services system.
Paragraph (version A):
The transport system should have a list of supported protocols
available, which each have transport features reflecting the
capabilities of the protocol.  Once an application specifies its
Transport Properties, the transport system matches the required and
prohibited properties against the transport features of the available
protocols.
Paragraph (version B):
The Transport Services system should have a list of supported
protocols available, which each have transport features reflecting
the capabilities of the protocol.  Once an application specifies its
Transport Properties, the transport system matches the required and
prohibited properties against the transport features of the available
protocols.