Draft: draft-trammell-taps-interface

Commentary: Send parameters were subsections , transport selection properties were not . This fixes that by promiting transport selection properties to subsections , and reorganizing the sections slightly to make that fit . There are no changes to technical content in this PR . 
 Makes sense - had that one also on my list of ugliness to be fixed .
Paragraph (version A):
Reliable Data Transfer: This boolean property specifies whether
the application wishes to use a transport protocol that that
provides mechanisms to help ensure that all data is received and
without corruption on the other side.  This also entails being
notified when a Connection is closed or aborted.  This property
applies to Connections and Connection Groups.  This is a strict
requirement.  The default is to enable Reliable Data Transfer.
Paragraph (version A):
Preservation of data ordering: This boolean property specifies
whether the application wishes to use a transport protocol that
provides mechanisms to ensure that data is received by the
application on the other end in the same order as it was sent.
This property applies to Connections and Connection Groups.  This
is a strict requirement.  The default is to preserve data
ordering.
Paragraph (version A):
Configure reliability on a per-Message basis: This boolean
property specifies whether an application considers it useful to
indicate its reliability requirements on a per-Message basis.
This property applies to Connections and Connection Groups.  This
is not a strict requirement.  The default is to not have this
option.
Paragraph (version A):
Use 0-RTT session establishment with an idempotent Message: This
boolean property specifies whether an application would like to
supply a Message to the transport protocol before Connection
establishment, which will then be reliably transferred to the
other side before or during Connection establishment, potentially
multiple times.  See also send-idempotent.  This is a strict
requirement.  The default is to not have this option.
Paragraph (version A):
Multistream Connections in Group: This boolean property specifies
that the application would prefer multiple Connections within a
Connection Group to be provided by streams of a single underlying
transport connection where possible.  This is not a strict
requirement.  The default is to not have this option.
Paragraph (version A):
Notification of excessive retransmissions: This boolean property
specifies whether an application considers it useful to be
informed in case sent data was retransmitted more often than a
certain threshold.  This property applies to Connections and
Connection Groups.  This is not a strict requirement.  The default
is to have this option.
Paragraph (version A):
Notification of ICMP soft error message arrival: This boolean
property specifies whether an application considers it useful to
be informed when an ICMP error message arrives that does not force
termination of a connection.  This property applies to Connections
and Connection Groups.  Received ICMP errors will be available as
SoftErrors.  Note that even if a protocol supporting this property
is selected, not all ICMP errors will necessarily be delivered, so
applications cannot rely on receiving them.  This is not a strict
requirement.  The default is not to have this option.
Paragraph (version A):
Control checksum coverage on sending or receiving: This boolean
property specifies whether the application considers it useful to
enable / disable / configure a checksum when sending data, or
decide whether to require a checksum or not when receiving data.
This property applies to Connections and Connection Groups.  This
is not a strict requirement, as it signifies a reduction in
reliability.  The default is full checksum coverage without being
able to change it, and requiring a checksum when receiving.
Paragraph (version A):
Interface Type: This enumerated property specifies which kind of
access network interface, e.g., WiFi, Ethernet, or LTE, to prefer
over others for this Connection, in case they are available.  In
general, Interface Types should be used only with the "Prefer" and
"Prohibit" preference level.  Specifically, using the "Require"
preference level for Interface Type may limit path selection in a
way that is detrimental to connectivity.  The default is to use
the default interface configured in the system policy.
Paragraph (version A):
The application makes no representation about its expected
capacity profile.  No special optimizations of the tradeoff
between delay, delay variation, and bandwidth efficiency should
be made when selecting and configuring stacks.
Paragraph (version A):
The application is interactive.  Response time (latency) should
be optimized at the expense of bandwidth efficiency and delay
variation.  This can be used by the system to disable the
coalescing of multiple small Messages into larger packets
(Nagle's algorithm), to prefer lower-latency paths, signal a
preference for lower-latency, higher-loss treatment, and so on.
Paragraph (version A):
The application expects to send/receive data at a constant rate
after Connection establishment.  Delay and delay variation
should be optimized at the expense of bandwidth efficiency.
This implies that the Connection may fail if the desired rate
cannot be maintained across the Path.  A transport may
interpret this capacity profile as preferring a circuit breaker
RFC8084 to a rate adaptive congestion controller.
Paragraph (version A):
The application is not interactive.  It expects to send/receive
a large amount of data, without any urgency.  This can be used
to select protocol stacks with scavenger transmission control,
to signal a preference for less-than-best-effort treatment, and
so on.
Paragraph (version B):
This boolean property specifies whether the application wishes to use
a transport protocol that that provides mechanisms to help ensure
that all data is received and without corruption on the other side.
This also entails being notified when a Connection is closed or
aborted.  This property applies to Connections and Connection Groups.
This is a strict requirement.  The default is to enable Reliable Data
Transfer.
Paragraph (version B):
This boolean property specifies whether the application wishes to use
a transport protocol that provides mechanisms to ensure that data is
received by the application on the other end in the same order as it
was sent.  This property applies to Connections and Connection
Groups.  This is a strict requirement.  The default is to preserve
data ordering.
Paragraph (version B):
This boolean property specifies whether an application considers it
useful to indicate its reliability requirements on a per-Message
basis.  This property applies to Connections and Connection Groups.
This is not a strict requirement.  The default is to not have this
option.
Paragraph (version B):
This boolean property specifies whether an application would like to
supply a Message to the transport protocol before Connection
establishment, which will then be reliably transferred to the other
side before or during Connection establishment, potentially multiple
times.  See also send-idempotent.  This is a strict requirement.  The
default is to not have this option.
Paragraph (version B):
This boolean property specifies that the application would prefer
multiple Connections within a Connection Group to be provided by
streams of a single underlying transport connection where possible.
This is not a strict requirement.  The default is to not have this
option.
Paragraph (version B):
This boolean property specifies whether an application considers it
useful to be informed in case sent data was retransmitted more often
than a certain threshold.  This property applies to Connections and
Connection Groups.  This is not a strict requirement.  The default is
to have this option.
Paragraph (version B):
This boolean property specifies whether an application considers it
useful to be informed when an ICMP error message arrives that does
not force termination of a connection.  This property applies to
Connections and Connection Groups.  Received ICMP errors will be
available as SoftErrors.  Note that even if a protocol supporting
this property is selected, not all ICMP errors will necessarily be
delivered, so applications cannot rely on receiving them.  This is
not a strict requirement.  The default is not to have this option.
Paragraph (version B):
This boolean property specifies whether the application considers it
useful to enable / disable / configure a checksum when sending data,
or decide whether to require a checksum or not when receiving data.
This property applies to Connections and Connection Groups.  This is
not a strict requirement, as it signifies a reduction in reliability.
The default is full checksum coverage without being able to change
it, and requiring a checksum when receiving.
Paragraph (version B):
This enumerated property specifies which kind of access network
interface, e.g., WiFi, Ethernet, or LTE, to prefer over others for
this Connection, in case they are available.  In general, Interface
Types should be used only with the "Prefer" and "Prohibit" preference
level.  Specifically, using the "Require" preference level for
Interface Type may limit path selection in a way that is detrimental
to connectivity.  The default is to use the default interface
configured in the system policy.
Paragraph (version B):
The application makes no representation about its expected
capacity profile.  No special optimizations of the tradeoff
between delay, delay variation, and bandwidth efficiency should be
made when selecting and configuring stacks.
Paragraph (version B):
The application is interactive.  Response time (latency) should be
optimized at the expense of bandwidth efficiency and delay
variation.  This can be used by the system to disable the
coalescing of multiple small Messages into larger packets (Nagle's
algorithm), to prefer lower-latency paths, signal a preference for
lower-latency, higher-loss treatment, and so on.
Paragraph (version B):
The application expects to send/receive data at a constant rate
after Connection establishment.  Delay and delay variation should
be optimized at the expense of bandwidth efficiency.  This implies
that the Connection may fail if the desired rate cannot be
maintained across the Path.  A transport may interpret this
capacity profile as preferring a circuit breaker RFC8084 to a rate
adaptive congestion controller.
Paragraph (version B):
The application is not interactive.  It expects to send/receive a
large amount of data, without any urgency.  This can be used to
select protocol stacks with scavenger transmission control, to
signal a preference for less-than-best-effort treatment, and so
on.
Paragraph (version A):
This enumerated property specifies the application's preferred
tradeoffs for sending this Message; it is a per-Message override of
the Capacity Profile protocol and path selection property (see
transport-params).
Paragraph (version B):
This enumerated property specifies the application's preferred
tradeoffs for sending this Message; it is a per-Message override of
the Capacity Profile protocol and path selection property (see prop-
cap-profile).