Draft: draft-ietf-taps-interface

Commentary: Notable changes : control over using multipath ( which was a late addition to minset ) a timeout for conn . establishment , separate from the other conn . abort timeout ( see ) renamed InitiateWithIdempotentSend into InitiateWithSend , and adjusted the text to recommend declaring idempotence . This addresses the minset function that goes back to TCP 's send - with - SYN . 
 Status : said " LGTM modulo tiny nits " and I think these nits are now addressed . requests something more than just a boolean to enable / disable usage of multiple paths . It seems to me that this needs more discussion , but it also does n't seem like a show - stopper for the boolean to begin with ; I think we can discuss this more after landing this PR . has n't reacted ( or am I missing this ) , but this has an ok from and In conclusion : I think this is good to go . I 'll wait until tomorrow ; unless someone speaks up by then , I 'll merge this PR . 
 If you make it a boolean it can not be used as a selection property , so I do not think that is a good choice . Or how should it be interpreted for the selection ? 
 what do you mean , that it should be a ( binary - yes / no ) Preference instead ? I thought this would be more limiting but I 'm fine with this as well . 
 I meant that it should be a Preference as pointed out in the original comment by I do not understand what a boolean means during selection ( is it a requirement or a preference ? ) I also do not understand what it means in the middle of a connection . You mean you should try and use a single or several subflows for scheduling data , assuming you already have a multipath connection ? I guess this is possible , but then the description needs to be more clear that this is what it means . In the appendix about minset your have " Disable MPTCP : " Parallel Use of Multiple Paths " Property . " I assume this refers to the Protocol Selection phase ? It does not make sense to disable or enable MPTCP in the middle of a connection I think . I guess part of how to specify the property depends on how to interpret this part from the intro to the Managing Connections section : " The application can set and query Connection Properties on a per - Connection basis . Connection Properties that are not read - only can be set during pre - establishment ( see { { selection - props } } ) , as well as on connections directly using the SetProperty action " I interpreted this as properties set during pre - establishment are selection properties , but maybe this is not the intention as they may need to be expressed differently ? If they are not intended as selection properties , we are missing a selection property for multipath I guess . 
 Ok . That 's what I meant , yes - but I agree that 's not covered by the description , it really is a selection preference only as it 's written now . OK ( though you CAN do it with the " real " API , by closing subflows , but this goes beyond the spec'd protocol , and I 'm also not sure it 's a good idea , especially when limited to only enabling / disabling it altogether ) . I would have understood this as in your first interpretation : " properties set during pre - establishment are selection properties " . 
 Closing a subflow is not the same as disabling MPTCP to me . You will still be using MPTCP , only with a single subflow . And you can certainly not open a subflow unless MPTCP is already enabled . But seems we now have a common understanding . 
 ack , we 've converged . I just pushed a commit that turns the " Parallel Use of Multiple Paths " property into a Selection property . 
 these are a few minor changes to apply , and properties to add ( e.g. " disable MPTCP " ) 
 this is done , yes ? 
 No . But I 'm planning to do a PR to address this issue this week . 
 Note that this also requires closing , which I re - opened with a concrete proposal to address something from minset . 
 LGTM modulo tiny nitsSorry , missed this until just now . Looks fine with me , I just have a small question and my 2 cents to the multipath discussion ( which we can have at a later point ) .
Paragraph (version B):
This property specifies whether an application considers it useful to
transfer data across multiple paths between the same end hosts.
Generally, in most cases, this will improve performance (e.g.,
achieve greater throughput).  One possible side-effect is increased
jitter, which may be problematic for delay-sensitive applications.
Paragraph (version B):
This property specifies how long to wait before aborting a Connection
during establishment.
Paragraph (version A):
For application-layer protocols where the Connection initiator also
sends the first message, the InitiateWithIdempotentSend() action
combines Connection initiation with a first Message sent, provided
that message is idempotent.
Paragraph (version A):
The message passed to InitiateWithIdempotentSend() is, as suggested
by the name, considered to be idempotent (see msg-idempotent)
regardless of declared message properties or defaults.  If protocol
stacks supporting 0-RTT establishment with idempotent data are
available on the Preconnection, then 0-RTT establishment may be used
with the given message when establishing candidate connections.  For
a non-idemponent initial message, or when the selected stack(s) do
not support 0-RTT establishment, InitiateWithIdempotentSend is
identical to Initiate() followed by Send().
Paragraph (version A):
Neither partial sends nor send batching are supported by
InitiateWithIdempotentSend().
Paragraph (version A):
The Events that may be sent after InitiateWithIdempotentSend() are
equivalent to those that would be sent by an invocation of Initate()
followed immediately by an invocation of Send(), with the caveat that
a send failure that occurs because the Connection could not be
established will not result in a SendError separate from the
InitiateError signaling the failure of Connection establishment.
Paragraph (version B):
Neither partial sends nor send batching are supported by
InitiateWithSend().
Paragraph (version A):
This property specifies how long to wait before aborting a Connection
during establishment, or before deciding that a Connection has failed
after establishment.  It is given in seconds.
Paragraph (version B):
This property specifies how long to wait before deciding that a
Connection has failed after establishment.
Paragraph (version A):
A ConnectionError can inform the application that the other side has
aborted the Connection; however, there is no guarantee that an Abort
will indeed be signaled.
Paragraph (version B):
A ConnectionError informs the application that data to could not be
delivered after a timeout, or the other side has aborted the
Connection; however, there is no guarantee that an Abort will indeed
be signaled.
Paragraph (version A):
Ready<> occurs when a Connection created with Initiate() or
InitiateWithIdempotentData() transitions to Established state.
Paragraph (version B):
Ready<> occurs when a Connection created with Initiate() or
InitiateWithSend() transitions to Established state.