Draft: draft-ietf-taps-impl

Commentary: Several small updates , mostly to clean things up a bit , and align property names and such . 
 - I think you 're wrong : my understanding ( and also the way the text is written - otherwise we 'd have to change it in the API draft ) was that Connection Properties can ( and should ) also be set on Preconnections , to give as much input as possible for Connection establishment . In the API draft , the Selection Properties in Section 5.2 can only be used on Preconnections : you ca n't ask for congestion control after establishment . You ca n't say that you 'd rather have multistreaming support after establishment . But that does n't exclude Connection properties from being usable earlier . Required minimum checksum coverage could influence choosing UDP - Lite vs. UDP . Bounds on Send or Receive Rate could influence the interface choice . The capacity profile could influence various things ( and no , there is n't a matching Selection Property now - there is a per - Message override ) . So ... I think that either you 're wrong , or I 'm missing something and the API draft heavily lags behind a decision that was made . I hope not ! 
 The API drafts says : I interpret this as only the Selection Properties influence selection and the Connection properties are used to further configure the connections according to user preferences . Otherwise what is the difference between them ? 
 If you interpret it as you do , I think the text is n't clear enough ( indeed it is n't super clear - in particular , " eventually established " is misleading IMO ) . Though , note that it says that Connection properties can also be used later . Regarding the difference between them : Selection Properties only make sense for Preconnections . 
 - sorry lost this thread . But I saw that you have started cleaning up some Connection properties that had mixed Connection and Selection properties up in the API draft . Does it mean that we are now in synch and agree that only Selection properties are used in the selection and Connection properties are used for configuration ( both during establisment and also after the connection setup ) . 
 the other PR means nothing about what I said here : it only tried to address issue which is about a wording inconsistency in a specific property . You say that Connection properties can also be used during establishment - if you agree with allowing this , then why not allow to configure them as early as possible and allow them to influence selection ? What 's bad about having more information available that can guide the selection process ? 
 the problem is that the Connection properties are not expressed in a way suitable for selection . If they should also be used for Selection they would have to be reworked to be of type Preference . Otherwise I do not know what they mean for selection . What does it mean if I pick say a particular connection group transmission scheduler ? Is it required or preferred ? Most connection properties also do not look very useful to me for selection so in case there are some we need I think it would be simpler to just define a matching selection property . 
 we 're only discussing whether it 's allowed to use them as additional input or not . I agree , some ( like the scheduler choice ) do n't seem useful , but some do ... generally we may not have good guidance on how they should be used by an implementation , but giving the system freedom to use as many inputs as possible is probably a good thing . Regarding the type , require / prefer//ignore / avoid / prohibit obviously works fine for a " wishlist " of boolean character : having something , or not having it . The selection properties are generally like that - except " Interface Instance or Type " and " Provisioning Domain Instance or Type " which are , well ... wishlist - collections . Consider the capacity profile . Surely configuring this early can be useful input - e.g. if someone picks low latency / interactive , you may even want to put this traffic on a specific network interface ! But if you 'd want to make a copy of the capacity profile as a " proper " selection property , how would you do it ? Apply require / prefer / ignore / avoid / prohibit for each of its values ? Then I could say " prefer " low latency / non - interactive but " avoid " low latency / non - interactive , which would surely be odd . Apply the qualifier to the whole thing ? Then it 's about , e.g. " avoiding " to use a capacity profile at all . That 's odd as well . I think it 's in the nature of the current selection properties that they merely say " I want to be able to do this , and this is how important it is to me " , which is different from configuring something . That 's also why , as written , they simply would n't work for later connection configuration . Connection properties really are about configuring something , but I still say that being able to use them as early input is good . I agree that the implementation is n't super clear as they do n't come with a require / prefer/ ... etc . qualifier , but then we just offer some freedom to implementers . 
 I just pushed a commit that updates the selection and connection properties text , removing " connection " almost everywhere , but adding a disclaimer in the beginning that says that connection properties should be configured as early as possible because they can influence decisions made by the implementation , and " In the remainder of this document , we only refer to Selection Properties because they are the more typical case . " Frankly I 'm not sure this is better ... but it does remove most of the " selection and connection " double mentions that you pointed out . 
 Fixed up branch building and resolved merge conflicts . I 'll merge this in later today before the posting deadline . 
 Cool thanks ! Sorry if I messed something up 
 As discussed in 
 Thank you for updating this – looks good ! just needs s / send - params / msg - properties/ and merging
Paragraph (version A):
During pre-establishment the application specifies the Endpoints to
be used for communication as well as its preferences regarding
Protocol and Path Selection.  The implementation stores these objects
and properties as part of the Preconnection object for use during
connection establishment.  For Protocol and Path Selection Properties
that are not provided by the application, the implementation must use
the default values specified in the Transport Services API (I-D.ietf-
taps-interface).
Paragraph (version B):
During pre-establishment the application specifies the Endpoints to
be used for communication as well as its preferences via Selection
Properties and, if desired, also Connection Properties.  Generally,
Connection Properties should be configured as early as possible, as
they may serve as input to decisions that are made by the
implementation (the Capacity Profile may guide usage of a protocol
offering scavenger-type congestion control, for example).  In the
remainder of this document, we only refer to Selection Properties
because they are the more typical case and have to be handled by all
implementations.
Paragraph (version B):
The implementation stores these objects and properties as part of the
Preconnection object for use during connection establishment.  For
Selection Properties that are not provided by the application, the
implementation must use the default values specified in the Transport
Services API (I-D.ietf-taps-interface).
Paragraph (version A):
Application preferences, i.e., preferences specified during the
pre-establishment such as Local Endpoint, Remote Endpoint, Path
Selection Properties, and Protocol Selection Properties.
Paragraph (version B):
Application preferences, i.e., preferences specified during the
pre-establishment via Selection Properties.
Paragraph (version A):
The step of gathering candidates involves identifying which paths,
protocols, and endpoints may be used for a given Connection.  This
list is determined by the requirements, prohibitions, and preferences
of the application as specified in the Path Selection Properties and
Protocol Selection Properties.
Paragraph (version B):
The step of gathering candidates involves identifying which paths,
protocols, and endpoints may be used for a given Connection.  This
list is determined by the requirements, prohibitions, and preferences
of the application as specified in the Selection Properties.
Paragraph (version B):
For example, if the application has indicated both a preference for
WiFi over LTE and for a feature only available in SCTP, branches will
be first sorted accord to path selection, with WiFi at the top.
Then, branches with SCTP will be sorted to the top within their
subtree according to the properties influencing protocol selection.
However, if the implementation has cached the information that SCTP
is not available on the path over WiFi, there is no SCTP node in the
WiFi subtree.  Here, the path over WiFi will be tried first, and, if
connection establishment succeeds, TCP will be used.  So the
Selection Property of preferring WiFi takes precedence over the
Property that led to a preference for SCTP.
Paragraph (version A):
Implementations should sort the branches of the tree of connection
options in order of their preference rank.  Leaf nodes on branches
with higher rankings represent connection attempts that will be raced
first.  Implementations should order the branches to reflect the
preferences expressed by the application for its new connection,
including Protocol and Path Selection Properties, which are specified
in I-D.ietf-taps-interface.
Paragraph (version A):
Interface Type: If the application specifies an interface type to
be preferred or avoided, implementations should rank paths
accordingly.  If the application specifies an interface type to be
required or prohibited, we expect an implementation to not include
the non-conforming paths into the three.
Paragraph (version A):
Implementations should process properties in the following order:
Prohibit, Require, Prefer, Avoid.  If Protocol or Path Selection
Properties contain any prohibited properties, the implementation
should first purge branches containing nodes with these properties.
For required properties, it should only keep branches that satisfy
these requirements.  Finally, it should order branches according to
preferred properties, and finally use avoided properties as a
tiebreaker.
Paragraph (version A):
For Require and Avoid, Path Selection Properties take precedence over
Protocol Selection Properties.  For example, if the application has
indicated both a preference for WiFi over LTE and for a feature only
available in SCTP, branches will be first sorted accord to the Path
Selection Property, with WiFi at the top.  Then, branches with SCTP
will be sorted to the top within their subtree according to the
Protocol Selection Property.  However, if the implementation has
cached the information that SCTP is not available on the path over
WiFi, there is no SCTP node in the WiFi subtree.  Here, the path over
WiFi will be tried first, and, if connection establishment succeeds,
TCP will be used.  So the Path Selection Property of preferring WiFi
takes precedence over the Protocol Selection Property of preferring
SCTP.
Paragraph (version B):
Implementations should sort the branches of the tree of connection
options in order of their preference rank.  Leaf nodes on branches
with higher rankings represent connection attempts that will be raced
first.  Implementations should order the branches to reflect the
preferences expressed by the application for its new connection,
including Selection Properties, which are specified in I-D.ietf-taps-
interface.
Paragraph (version B):
"Interface Instance or Type": If the application specifies an
interface type to be preferred or avoided, implementations should
rank paths accordingly.  If the application specifies an interface
type to be required or prohibited, we expect an implementation to
not include the non-conforming paths into the three.
Paragraph (version B):
Implementations should process properties in the following order:
Prohibit, Require, Prefer, Avoid.  If Selection Properties contain
any prohibited properties, the implementation should first purge
branches containing nodes with these properties.  For required
properties, it should only keep branches that satisfy these
requirements.  Finally, it should order branches according to
preferred properties, and finally use avoided properties as a
tiebreaker.
Paragraph (version A):
If the Path 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 Path Selection 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 A):
If the Protocol Selection Properties allow multiple protocols to be
used for listening, and the implementation supports it, the Listener
object should register across the eligble protocols for each path.
This means that inbound Connections delivered by the implementation
may have heterogeneous protocol stacks.
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 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 allow multiple protocols to be used for
listening, and the implementation supports it, the Listener object
should register across the eligble protocols for each path.  This
means that inbound Connections delivered by the implementation may
have heterogeneous protocol stacks.
Paragraph (version A):
Niceness: this represents the ability to de-prioritize a Message
in favor of other Messages.  This can be implemented by the system
re-ordering Messages that have yet to be handed to the Protocol
Stack, or by giving relative priority hints to protocols that
support priorities per Message.  For example, an implementation of
HTTP/2 could choose to send Messages of different niceness on
streams of different priority.
Paragraph (version A):
Immediate Acknowledgement: this informs the implementation that
the sender intends to execute tight control over the send buffer,
and therefore wants to avoid delayed acknowledgements.  In case of
SCTP, a request to immediately send acknowledgements can be
implemented using the "sack-immediately flag" described in
Section 4.2 of RFC8303 for the SEND.SCTP primitive.
Paragraph (version A):
Instantaneous Capacity Profile: when this is set to "Interactive/
Low Latency", the Message should be sent immediately, even when
this comes at the cost of using the network capacity less
efficiently.  For example, small messages can sometimes be bundled
to fit into a single data packet for the sake of reducing header
overhead; such bundling should not be used.  For example, in case
of TCP, the Nagle algorithm should be disabled when Interactive/
Low Latency is selected as the capacity profile.  Scavenger/Bulk
can translate into usage of a congestion control mechanism such as
LEDBAT, and/or the capacity profile can lead to a choice of a DSCP
value as described in I-D.ietf-taps-minset).
Paragraph (version B):
Final: when this is true, it means that a transport connection can
be closed immediately after its transmission.
Paragraph (version B):
Transmission Profile: TBD - because it's not final in the API yet.
Old text follows: when this is set to "Interactive/Low Latency",
the Message should be sent immediately, even when this comes at
the cost of using the network capacity less efficiently.  For
example, small messages can sometimes be bundled to fit into a
single data packet for the sake of reducing header overhead; such
bundling should not be used.  For example, in case of TCP, the
Nagle algorithm should be disabled when Interactive/Low Latency is
selected as the capacity profile.  Scavenger/Bulk can translate
into usage of a congestion control mechanism such as LEDBAT, and/
or the capacity profile can lead to a choice of a DSCP value as
described in I-D.ietf-taps-minset).
Paragraph (version B):
Singular Transmission: when this is true, the application requests
to avoid transport-layer segmentation or network-layer
fragmentation.  Some transports implement network-layer
fragmentation avoidance (Path MTU Discovery) without exposing this
functionality to the application; in this case, only transport-
layer segmentation should be avoided, by fitting the message into
a single transport-layer segment or otherwise failing.  Otherwise,
network-layer fragmentation should be avoided--e.g. by requesting
the IP Don't Fragment bit to be set in case of UDP(-Lite) and IPv4
(SET_DF in RFC8304).
Paragraph (version A):
Abort timeout to suggest to the Remote Endpoint: for TCP, this can
be done using the primitive CHANGE_TIMEOUT.TCP described in
section 4 of RFC8303.
Paragraph (version A):
Retransmission threshold before excessive retransmission
notification: for TCP, this can be done using ERROR.TCP described
in section 4 of RFC8303.
Paragraph (version B):
Appendix A.1 of I-D.ietf-taps-minset explains, using primitives from
RFC8303 and RFC8304, how to implement changing some of the following
protocol properties of an established connection with TCP and UDP.
Below, we amend this description for other protocols (if applicable)
and extend it with Connection Properties that are not contained in I-
D.ietf-taps-minset.
Paragraph (version B):
Retransmission threshold before excessive retransmission
notification: TODO; for TCP, this can be done using ERROR.TCP
described in section 4 of RFC8303.
Paragraph (version B):
Priority (Connection): TODO; for SCTP, this can be done using the
primitive CONFIGURE_STREAM_SCHEDULER.SCTP described in section 4
of RFC8303.
Paragraph (version B):
TCP-specific Property: User Timeout: for TCP, this can be
configured using the primitive CHANGE_TIMEOUT.TCP described in
section 4 of RFC8303.