Draft: draft-ietf-taps-interface

Commentary: This is my suggestion for cleaning up properties . It makes the following changes : 12 Transport Properties goes away . Its introduction to what transport properties are moves into a new section 4.1 ( since Properties are key to how the API works , they need to come first ) . Selection Properties move into Section 5.2 . Some of the explanation of each class has moved to the section of the document where the class is defined ( 5.2 Selection Properties , 7.3 Message Context Properties , 9.1 Connection Properties ) . Profile is a Connection Property , not a Selection Property , so it moves to Connection Properties . moves back into the appendix , because we 're not done discussing it yet . Things that ( might ) still need to happen , not part of this PR : Transmission Profile and Capacity Profile out the best way to cross reference Selection Properties with Connection and Message Context Properties they enable . Maybe this happens in a new Section 12 ( as the registry work wants to do / an 8095 - style table ) , and/or with direct references back to Selection Properties in each Connection and Message Context Property . Message Context Properties 
 i 'm also inclined to land this and fix the problems with it later . will wait for one more green check before doing so . ( For those trying to review this , the important bits to look at are the new and . ) 
 Whooop … that was fast . I like the overall result , except deleting the overview from Section 12 . Re - introducing it for the registry proposal will be another 2 - 3h of unnecessary work . 
 IMO the useful subset of the overview content ( for this document ) lives in 4.1 now , and information on each class to the respective section for the class . The reorganization into Selection , Connection , and Message properties makes a lot of the boilerplate in each entry unnecessary . What , in your opinion , is still missing here ? ISTM the next step toward the registry is assigning names - in - code for each of the properties ( for which I 'll file a separate issue to be done post - BKK ) ; after that 's done , summary information for each property should be collected into the IANA Considerations section , with normative references to the subsections within the document for each registry entry ( assuming , of course , we come to consensus that a registry is the right way to go ) . 
 Thanks for moving this further ! I really like introducing Properties early . I have two issues and two nits , see below . Best , TheresaLooks good , with a couple nitsThis is so hard to follow ... and it 's probably fine by me anyway . My choice would be to shoot first and ask second . ( land it , then let 's read this )
Paragraph (version A):
In the following sections, we describe the details of application
interaction with Objects through Actions and Events in each phase of
a Connection, following the phases described in I-D.ietf-taps-arch.
Paragraph (version B):
pre-establishment, establishment, sending, receiving, and termination
describe the details of application interaction with Objects through
Actions and Events in each phase of a Connection, following the
phases described in I-D.ietf-taps-arch.
Paragraph (version B):
Each application using the Transport Services Interface declares its
preferences for how the transport service should operate using
properties at each stage of the lifetime of a connection.  During
pre-establishment, Selection Properties selection-props are used to
specify which paths and protocol stacks can be used and are preferred
by the application, and Connection Properties connection-props can be
used to fine-tune the eventually established connection.  These
Connection Properties can also be used to monitor and fine-tune
established connections.  The behavior of the selected protocol
stack(s) when sending Messages is controlled by Message Context
Properties message-props.
Paragraph (version B):
Boolean: can take the values "true" and "false"; representation is
implementation-dependent.
Paragraph (version B):
Integer: can take positive or negative numeric values; range and
representation is implementation-dependent.
Paragraph (version B):
Enumeration: can take one value of a finite set of values,
dependent on the property itself.  The representation is
implementation dependent; however, implementations MUST provide a
method for the application to determine the entire set of possible
values for each property.
Paragraph (version B):
Preference: can take one of five values (Prohibit, Avoid, Ignore,
Prefer, Require) for the level of preference of a given property
during protocol selection; see selection-props.
Paragraph (version A):
A Preconnection Object holds properties reflecting the application's
requirements and preferences for the transport.  These include
Selection Properties (Protocol and Path Selection Properties), as
well as Generic and Specific Protocol Properties for configuration of
the detailed operation of the selected Protocol Stacks.
Paragraph (version A):
The protocol(s) and path(s) selected as candidates during Connection
establishment are determined by a set of properties.  Since there
could be paths over which some transport protocols are unable to
operate, or remote endpoints that support only specific network
addresses or transports, transport protocol selection is necessarily
tied to path selection.  This may involve choosing between multiple
local interfaces that are connected to different access networks.
Paragraph (version A):
Internally, the transport system will first exclude all protocols and
paths that match a Prohibit, then exclude all protocols and paths
that do not match a Require, then sort candidates according to
Preferred properties, and then use Avoided properties as a
tiebreaker.  In case of conflicts between Protocol and Path Selection
Properties, Path Selection Properties take precedence.  For example,
if an application indicates a preference for a specific path, but
also a preference for a protocol not available on this path, the
transport system will try the path first, so the Protocol Selection
Property might not have an effect.
Paragraph (version A):
All Transport Properties used in the pre-establishment phase are
collected in a TransportProperties Object that is passed to the
Preconnection Object.
Paragraph (version A):
The Individual properties are then added to the TransportProperties
Object.
Paragraph (version A):
transport-props provides a list of Transport Properties.
Paragraph (version A):
Note that many properties are only considered for Connection
establishment and can not be changed after a Connection is
established; however, they can be queried.  See introspection.
Paragraph (version B):
A Preconnection Object holds properties reflecting the application's
requirements and preferences for the transport.  These include
Selection Properties for selecting protocol stacks and paths, as well
as Connection Properties for configuration of the detailed operation
of the selected Protocol Stacks.
Paragraph (version B):
The protocol(s) and path(s) selected as candidates during
establishment are determined and configured using these properties.
Since there could be paths over which some transport protocols are
unable to operate, or remote endpoints that support only specific
network addresses or transports, transport protocol selection is
necessarily tied to path selection.  This may involve choosing
between multiple local interfaces that are connected to different
access networks.
Paragraph (version B):
Internally, the transport system will first exclude all protocols and
paths that match a Prohibit, then exclude all protocols and paths
that do not match a Require, then sort candidates according to
Preferred properties, and then use Avoided properties as a
tiebreaker.  Selection Properties which select paths take preference
over those which select protocols.  For example, if an application
indicates a preference for a specific path by specifying an
interface, but also a preference for a protocol not available on this
path, the transport system will try the path first, ignoring the
preference.
Paragraph (version B):
connection-props provides a list of Connection Properties, while
Selection Properties are listed in the subsections below.  Note that
many properties are only considered during establishment, and can not
be changed after a Connection is established; however, they can be
queried.  Querying a Selection Property after establishment yields
the value Required for properties of the selected protocol and path,
Avoid for properties avoided during selection, and Ignore for all
other properties.
Paragraph (version B):
An implementation of this interface must provide sensible defaults
for Selection Properties.  The recommended defaults given for each
property below represent a configuration that can be implemented over
TCP.  An alternate set of default Protocol Selection Properties would
represent a configuration that can be implemented over UDP.
Paragraph (version B):
This property specifies whether the application needs to use a
transport protocol that ensures that all data is received on the
other side without corruption.  This also entails being notified when
a Connection is closed or aborted.  The recommended default is to
enable Reliable Data Transfer.
Paragraph (version B):
This 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.  The
recommended default is to not have this option.
Paragraph (version B):
This property specifies whether the application wishes to use a
transport protocol that can ensure that data is received by the
application on the other end in the same order as it was sent.  The
recommended default is to preserve data ordering.
Paragraph (version B):
This 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 msg-idempotent.  The recommended default is to not have this
option.
Paragraph (version B):
This 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.  The
recommended default is to not have this option.
Paragraph (version B):
This property specifies whether the application considers it useful
to enable, disable, or configure a checksum when sending a Message,
or configure whether to require a checksum or not when receiving.
The recommended default is full checksum coverage without the option
to configure it, and requiring a checksum when receiving.
Paragraph (version B):
This property specifies whether the application would like the
Connection to be congestion controlled or not.  Note that if a
Connection is not congestion controlled, an application using such a
Connection should itself perform congestion control in accordance
with RFC2914.  Also note that reliability is usually combined with
congestion control in protocol implementations, rendering "reliable
but not congestion controlled" a request that is unlikely to succeed.
The recommended default is that the Connection is congestion
controlled.
Paragraph (version B):
In contrast to other Selection Properties, this property is tuple of
an (Enumerated) interface identifier and a preference, and can either
be implemented directly as such, or for making one preference
available for each interface and interface type available on the
system.
Paragraph (version B):
Note that marking a specific interface as "Required" strictly limits
path selection to a single interface, and leads to less flexible and
resilient connection establishment.
Paragraph (version B):
As with interface instances and types, this property is tuple of an
(Enumerated) PvD identifier and a preference, and can either be
implemented directly as such, or for making one preference available
for each interface and interface type available on the system.
Paragraph (version A):
Applications may need to annotate the Messages they send with extra
information to control how data is scheduled and processed by the
transport protocols in the Connection.  A messageContext object
contains parameters for sending Messages, and can be passed to the
Send Action.  Some of these parameters are properties as defined in
transport-props.  Note that these properties are per-Message, not
per-Send if partial Messages are sent (send-partial).  All data
blocks associated with a single Message share properties.  For
example, it would not make sense to have the beginning of a Message
expire, but allow the end of a Message to still be sent.
Paragraph (version A):
Message Properties share a single namespace with Transport Properties
(see transport-props).  This allows the specification of per-
Connection Protocol Properties that can be overridden on a per-
Message basis.
Paragraph (version B):
Applications may need to annotate the Messages they send with extra
information to control how data is scheduled and processed by the
transport protocols in the Connection.  A messageContext object
contains parameters for sending Messages, and can be passed to the
Send Action.  Note that these properties are per-Message, not per-
Send if partial Messages are sent (send-partial).  All data blocks
associated with a single Message share properties.  For example, it
would not make sense to have the beginning of a Message expire, but
allow the end of a Message to still be sent.
Paragraph (version A):
The Received Message Context can indicate whether or not this Message
is the Final Message on a Connection.  For any Message that is marked
as Final, the application can assume that there will be no more
Messages received on the Connection once the Message has been
completely delivered.  This corresponds to the Final property that
may be marked on a sent Message send-final.
Paragraph (version B):
The Received Message Context can indicate whether or not this Message
is the Final Message on a Connection.  For any Message that is marked
as Final, the application can assume that there will be no more
Messages received on the Connection once the Message has been
completely delivered.  This corresponds to the Final property that
may be marked on a sent Message msg-final.
Paragraph (version B):
After establishment, connections can be configured and queried using
Connection Properties, and asynchronous information may be available
about the state of the connection via Soft Errors.
Paragraph (version B):
Connection Properties represent the configuration and state of the
selected Protocol Stack(s) backing a Connection.  These Connection
Properties may be Generic, applying regardless of transport protocol,
or Specific, applicable to a single implementation of a single
transport protocol stack.  Generic Connection Properties are defined
in connection-props below.  Specific Protocol Properties are defined
in a transport- and implementation-specific way, and must not be
assumed to apply across different protocols.  Attempts to set
Specific Protocol Properties on a protocol stack not containing that
specific protocol are simply ignored, and do not raise an error;
however, too much reliance by an application on Specific Protocol
Properties may significantly reduce the flexibility of a transport
services implementation.
Paragraph (version A):
Whether the connection can be used to send data.  A connection can
not be used for sending if the connection was created with the
Selection Property "Direction of Communication" set to
"unidirectional receive" or if a Message marked as "Final" was
sent over this connection, see send-final.
Paragraph (version B):
Whether the connection can be used to send data.  A connection can
not be used for sending if the connection was created with the
Selection Property "Direction of Communication" set to
"unidirectional receive" or if a Message marked as "Final" was
sent over this connection, see msg-final.
Paragraph (version A):
For Connections that are Establishing: Transport Properties that
the application specified on the Preconnection, see connection-
props.
Paragraph (version A):
For Connections that are Established, Closing, or Closed:
Transport Properties of the actual protocols that were selected
and instantiated.  These features correspond to the properties
given in transport-props and include Selection Properties and
Protocol Properties.
Paragraph (version A):
Selection Properties indicate whether or not the Connection has
or offers a certain Selection Property.  Note that the actually
instantiated protocol stack may not match all Protocol
Selection Properties that the application specified on the
Preconnection.  For example, a certain Protocol Selection
Property that an application specified as Preferred may not
actually be present in the chosen protocol stack because none
of the currently available transport protocols had this
feature.
Paragraph (version A):
Protocol Properties of the protocol stack in use (see protocol-
props).
Paragraph (version A):
For Connections that are Established, properties of the path(s) in
use.  These properties can be derived from the local provisioning
domain RFC7556, measurements by the Protocol Stack, or other
sources.
Paragraph (version B):
For Connections that are Establishing: Transport Properties that
the application specified on the Preconnection, see selection-
props.
Paragraph (version B):
For Connections that are Established, Closing, or Closed:
Selection (selection-props) and Connection Properties (connection-
props) of the actual protocols that were selected and
instantiated.  Selection Properties indicate whether or not the
Connection has or offers a certain Selection Property.  Note that
the actually instantiated protocol stack may not match all
Protocol Selection Properties that the application specified on
the Preconnection.  For example, a certain Protocol Selection
Property that an application specified as Preferred may not
actually be present in the chosen protocol stack because none of
the currently available transport protocols had this feature.
Paragraph (version B):
For Connections that are Established, additional properties of the
path(s) in use.  These properties can be derived from the local
provisioning domain RFC7556, measurements by the Protocol Stack,
or other sources.
Paragraph (version B):
The Connection Properties defined as independent, and available on
all Connections are defined in the subsections below.
Paragraph (version A):
The default is to have this option.
Paragraph (version B):
The recommended default is to have this option.
Paragraph (version A):
This property applies to Connections and Connection Groups.  The
default is not to have this option.
Paragraph (version B):
This property applies to Connections and Connection Groups.  The
recommended default is not to have this option.
Paragraph (version A):
Slightly different from "querying", a SoftError Event can also occur,
informing the application about the receipt of an ICMP error message
related to the Connection.  This will only happen if the underlying
protocol stack supports access to soft errors; however, even if the
underlying stack supports it, there is no guarantee that a soft error
will be signaled.
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 transport protocol stacks.
Transport system implementations that map the requested capacity
profile onto per-connection DSCP signaling without multiplexing
SHOULD assign the DSCP Default Forwarding RFC2474 PHB; when the
Connection is multiplexed, the guidelines in section 6 of RFC7657
apply.
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
system implementations that map the requested capacity profile
onto per-connection DSCP signaling without multiplexing SHOULD
assign the DSCP Less than Best Effort LE-PHB PHB; when the
Connection is multiplexed, the guidelines in section 6 of RFC7657
apply.
Paragraph (version B):
The application is interactive, and prefers loss to latency.
Response time should be optimized at the expense of bandwidth
efficiency and delay variation 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 the DSCP Expedited Forwarding RFC3246 PHB; when the
Connection is multiplexed, the guidelines in section 6 of RFC7657
apply.
Paragraph (version B):
The application prefers loss to latency but is not interactive.
Response time should be optimized at the expense of bandwidth
efficiency and delay variation when sending on this
connection.Transport system implementations that map the requested
capacity profile onto per-connection DSCP signaling without
multiplexing SHOULD assign a DSCP Assured Forwarding
(AF21,AF22,AF23,AF24) RFC2597 PHB; when the Connection is
multiplexed, the guidelines in section 6 of RFC7657 apply.
Paragraph (version B):
The application expects to send/receive data at a constant rate
after Connection establishment.  Delay and delay variation should
be minimized 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.  Transport system
implementations that map the requested capacity profile onto per-
connection DSCP signaling without multiplexing SHOULD assign a
DSCP Assured Forwarding (AF31,AF32,AF33,AF34) RFC2597 PHB; when
the Connection is multiplexed, the guidelines in section 6 of
RFC7657 apply.
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 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.
When the Connection is multiplexed, the guidelines in section 6 of
RFC7657 apply.
Paragraph (version B):
The Capacity Profile for a selected protocol stack may be modified on
a per-Message basis using the Transmission Profile Message Context
Property; see send-profile.
Paragraph (version B):
Asynchronous introspection is also possible, via the SoftError Event.
This event informing the application about the receipt of an ICMP
error message related to the Connection.  This will only happen if
the underlying protocol stack supports access to soft errors;
however, even if the underlying stack supports it, there is no
guarantee that a soft error will be signaled.
Paragraph (version A):
Having discussed Selection Properties in selection-props, Connection
Properties connection-props, and Message Properties (message-props),
we now provide a complete overview of a transport system's defined
Transport Properties.
Paragraph (version A):
All Transport Properties are organized within a single namespace.
This enables setting them as defaults in earlier stages and querying
them in later stages: - Connections Properties can be set on
Preconnections - Message Properties can be set on Preconnections and
Connections - The effect of Selection Properties can be queried on
Connections and Messages.
Paragraph (version A):
Note that it is possible for a set of specified Transport Properties
to be internally inconsistent, or to be inconsistent with the later
use of the API by the application.  Application developers can reduce
inconsistency by only using the most stringent preference levels when
failure to meet the property would break the application's
functionality.  For example, they can set the Selection Property
"Reliable Data Transfer", which is a core assumption of many
application protocols, as Required.  However, since this comes at the
cost of flexibility of the transport system, such strict choices
should be made with care.  Implementations of this interface should
also raise any detected errors in configuration as early as possible,
to help ensure that inconsistencies are caught early in the
development process.
Paragraph (version A):
Each Transport Property takes a value of a property-specific type.
Paragraph (version A):
A boolean is a data type that can be either "true" or "false".
Boolean transport properties should only be used for properties that
can not be used in an optional way or to query the state of the
transport implementation.  For optional features, especially in
Selection Properties, the usage of the Preference type (see
transport-props-preference) is preferred.
Paragraph (version A):
Enumeration types are used for transport properties that can take one
value out of a limited set of choices.  The representation is
implementation dependent.
Paragraph (version A):
Integer types are used to represent integer numbers.  The
representation is implementation dependent.
Paragraph (version A):
When used on a Connection, this type becomes a (read-only) Boolean
representing whether the selected transport supports the requested
feature.
Paragraph (version A):
Selection Properties influence protocol and path selection.  Their
value usually is or includes a Preference that constrains (in case of
Require or Prohibit) or influences (Prefer, Ignore, Avoid) the
selection of transport protocols and paths used.
Paragraph (version A):
An implementation of this interface must provide sensible defaults
for Selection Properties.  The defaults given for each property below
represent a configuration that can be implemented over TCP.  An
alternate set of default Protocol Selection Properties would
represent a configuration that can be implemented over UDP.
Paragraph (version A):
Protocol Selection Properties can only be set on Preconnections, see
connection-props.  Path Selection Properties are usually used on
Preconnections, but might also be used on messages to assist per-
message path selection for multipath aware protocols.
Paragraph (version A):
Protocol Properties represent the configuration of the selected
Protocol Stacks backing a Connection.  Some properties apply
generically across multiple transport protocols, while other
properties only apply to specific protocols.  Generic properties will
be passed to the selected candidate Protocol Stack(s) to configure
them before candidate Connection establishment.  The default settings
of these properties will vary based on the specific protocols being
used and the system's configuration.
Paragraph (version A):
Most Protocol Properties can be set on a Preconnection during pre-
establishment to preconfigure Protocol Stacks during establishment.
Paragraph (version A):
In order to specify Specific Protocol Properties, transport system
implementations may offer applications to attach a set of options to
the Preconnection Object, associated with a specific protocol.  For
example, an application could specify a set of TCP Options to use if
and only if TCP is selected by the system.  Such properties must not
be assumed to apply across different protocols.  Attempts to set
specific protocol properties on a protocol stack not containing that
specific protocol are simply ignored, and do not raise an error.
Paragraph (version A):
Note that many protocol properties have a corresponding selection
property which asks for a protocol providing a specific transport
feature that is controlled by the protocol property.
Paragraph (version A):
Control properties manage the local transport system behavior or
request state changes in the local transport system.  Depending on
the protocols used, setting these properties might also influence the
protocol state machine.  See send-final for an example.
Paragraph (version A):
Intents are hints to the transport system that do not directly map to
a single protocol/transport feature or behavior of the transport
system, but express a presumed application behavior or generic
application needs.
Paragraph (version A):
The application can expect the transport system to take appropriate
actions involving protocol selection, path selection and setting of
protocol flags.  For example, if an application sets the "Capacity
Profile" to "bulk" on a Preconnection, this will likely influence
path selection, DSCP flags in the IP header as well as Niceness for
multi-streaming connections.  When using Intents, the application
must not expect consistent behavior across different environments,
implementations or versions of the same implementation.
Paragraph (version A):
Boolean Message Property - see final.
Paragraph (version A):
This property specifies whether the application needs to use a
transport protocol that ensures that all data is received on the
other side without corruption.  This also entails being notified when
a Connection is closed or aborted.  The default is to enable Reliable
Data Transfer.
Paragraph (version A):
This 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.  The default
is to not have this option.
Paragraph (version A):
This property specifies whether the application wishes to use a
transport protocol that can ensure that data is received by the
application on the other end in the same order as it was sent.  The
default is to preserve data ordering.
Paragraph (version A):
Boolean Message Property - see msg-ordered.
Paragraph (version A):
The connection must support sending data.
Paragraph (version A):
In case a unidirectional connection is requested, but unidirectional
connections are not supported by the transport protocol, the system
should fall back to bidirectional transport.
Paragraph (version A):
This 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 msg-idempotent.  The default is to not have this option.
Paragraph (version A):
Boolean Message Property - see msg-idempotent.
Paragraph (version A):
This 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.  The default
is to not have this option.
Paragraph (version A):
Boolean Connection Property - see conn-retrans-notify.
Paragraph (version A):
This property specifies whether the application considers it useful
to enable, disable, or configure a checksum when sending a Message,
or configure whether to require a checksum or not when receiving.
The default is full checksum coverage without the option to configure
it, and requiring a checksum when receiving.
Paragraph (version A):
Integer Message Property - see msg-checksum.
Paragraph (version A):
If a system supports discovery of specific interface identifiers,
such as "en0" or "eth0" on Unix-style systems, an implemention should
allow using these identifiers to define path preferences.  Note that
marking a specific interface as "Required" strictly limits path
selection to a single interface, and leads to less flexible and
resilient connection establishment.
Paragraph (version A):
Default: : 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 transport protocol stacks.  Transport
system implementations that map the requested capacity profile onto
per-connection DSCP signaling without multiplexing SHOULD assign the
DSCP Default Forwarding RFC2474 PHB; when the Connection is
multiplexed, the guidelines in section 6 of RFC7657 apply.
Paragraph (version A):
Scavenger: : 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 without multiplexing SHOULD assign the
DSCP Less than Best Effort LE-PHB PHB; when the Connection is
multiplexed, the guidelines in section 6 of RFC7657 apply.
Paragraph (version A):
Low Latency/Interactive: : The application is interactive, and
prefers loss to latency.  Response time should be optimized at the
expense of bandwidth efficiency and delay variation 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 the
DSCP Expedited Forwarding RFC3246 PHB; when the Connection is
multiplexed, the guidelines in section 6 of RFC7657 apply.
Paragraph (version A):
Low Latency/Non-Interactive: : The application prefers loss to
latency but is not interactive.  Response time should be optimized at
the expense of bandwidth efficiency and delay variation when sending
on this connection.Transport system implementations that map the
requested capacity profile onto per-connection DSCP signaling without
multiplexing SHOULD assign a DSCP Assured Forwarding
(AF21,AF22,AF23,AF24) RFC2597 PHB; when the Connection is
multiplexed, the guidelines in section 6 of RFC7657 apply.
Paragraph (version A):
Constant-Rate Streaming: : The application expects to send/receive
data at a constant rate after Connection establishment.  Delay and
delay variation should be minimized 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.  Transport system
implementations that map the requested capacity profile onto per-
connection DSCP signaling without multiplexing SHOULD assign a DSCP
Assured Forwarding (AF31,AF32,AF33,AF34) RFC2597 PHB; when the
Connection is multiplexed, the guidelines in section 6 of RFC7657
apply.
Paragraph (version A):
High Throughput Data: : 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.  When the Connection is multiplexed, the guidelines in
section 6 of RFC7657 apply.
Paragraph (version A):
This property specifies whether the application would like the
Connection to be congestion controlled or not.  Note that if a
Connection is not congestion controlled, an application using such a
Connection should itself perform congestion control in accordance
with RFC2914.  Also note that reliability is usually combined with
congestion control in protocol implementations, rendering "reliable
but not congestion controlled" a request that is unlikely to succeed.
The default is that the Connection is congestion controlled.
Paragraph (version A):
Integer Message Property - see msg-niceness.
Paragraph (version A):
Integer Message Property - see msg-lifetime.
Paragraph (version A):
TODO: Maybe move some of the above properties here.
Paragraph (version A):
TODO: Move appendix-non-consensus here.