Draft: draft-ietf-taps-impl

Commentary: Note , the change to the API draft here is a purely editorial detail that I fixed here in passing : the multipath selection property was renamed and this fixes the text referring to it . 
 " what we discussed " - you mean in , where I say that I stumbled over a sentence ? This PR does update that sentence ( simply removing " with migration support " from it because any multipath protocol can do that ) . 
 no , i meant what we discussed at the interim about using the handover , interactive , aggregate terminology . but i saw that this was not so easily done and we are all happy with your solution , so all good :) 
 Before distinguishing between protocols that do " multipath " and " migrating between paths " , it might help to define these terms . This is tripping is up in QUIC , and IIRC the original " Multipath TCP " was pretty much the migration case . Something like , " In this section we distinguish between ' multipath ' protocols and protocols that allow migration between paths . The first means < blah blah ... " 
 This is in section 7.2 of taps - impl . 
 We define multipath ( by policy in section 6.1.7 handover , interactive , aggregate ) in the API doc . Section 4.2 in Implementation should use these definitions . 
 I wanted to fix this now , but stumbled over the following sentence in the implementation draft : This talks about the protocol below the transport services system ; do multipath - supporting protocols with no migration support exist ? I struggle to imagine a scheduler that would n't make this happen ... e.g. lowest latency scheduling , but with the exception : if a path becomes completely unavailable , keep going ? :-) Looking at the three policies in section 6.1.7 of our API , clearly , migration should work with all of them ( and " Handover " is limited in that it does n't do anything else , but it 's got ta be a subset of the others anyway , I 'd say ) . Am I missing something ? Just checking ... 
 I think the example of no migration support would be a multipath protocol that is not able to add new paths , so SCTP without support for the ADD_ADDR extension perhaps ? Not sure this is a case we need to worry about though ... 
 Ah , a multipath protocol that does n't do multipath :-) 
 Well , it can do multipath with the paths you give it from the beginning :) Possibly something else was intended with the text from the beginning , but this is what I could think of ... 
 Looks good to me!Thanks for fixing the nits !
Paragraph (version A):
When a path change occurs, e.g., when the IP address of an interface
changes or a new interface becomes available, the Transport Services
implementation is responsible for notifying the application of the
change.  The path change may interrupt connectivity on a path for an
active connection or provide an opportunity for a transport that
supports multipath or migration to adapt to the new paths.
Paragraph (version B):
When a path change occurs, e.g., when the IP address of an interface
changes or a new interface becomes available, the Transport Services
implementation is responsible for notifying the Protocol Instance of
the change.  The path change may interrupt connectivity on a path for
an active connection or provide an opportunity for a transport that
supports multipath or migration to adapt to the new paths.  Note
that, from the Transport Services API point of view, migration is
considered a part of multipath connectivity; it is just a limiting
policy on multipath usage.  If the "multipath" Selection Property is
set to "Disabled", migration is disallowed.
Paragraph (version A):
If the Protocol Stack includes a transport protocol that also
supports multipath connectivity with migration support, the Transport
Services implementation should also inform the Protocol Instance of
potentially new paths that become permissible based on the Selection
Properties passed by the application.  A protocol can then establish
new subflows over new paths while an active path is still available
or, if migration is supported, also after a break has been detected,
and should attempt to tear down subflows over paths that are no
longer used.  The Transport Services API provides an interface to set
a multipath policy that indicates when and how different paths should
be used.  However, detailed handling of these policies is still
implementation-specific.  The decision about when to create a new
path or to announce a new path or set of paths to the remote
endpoint, e.g., in the form of additional IP addresses, is
implementation-specific or could be be supported by future API
extensions.  If the Protocol Stack includes a transport protocol that
does not support multipath, but does support migrating between paths,
the update to the set of available paths can trigger the connection
to be migrated.
Paragraph (version A):
In case of Pooled Connections pooled-connections, the transport
system may add connections over new paths or different protocols to
the pool if permissible based on the multipath policy and Selection
Properties.  In case a previously used path becomes unavailable, the
transport system may disconnect all connections that require this
path, but should not disconnect the pooled connection object exposed
to the application.  The strategy to do so is implementation-
specific, but should be consistent with the behavior of multipath
transports.
Paragraph (version B):
If the Protocol Stack includes a transport protocol that supports
multipath connectivity, the Transport Services implementation should
also inform the Protocol Instance of potentially new paths that
become permissible based on the "multipath" Selection Property and
the "multipath-policy" Connection Property choices made by the
application.  A protocol can then establish new subflows over new
paths while an active path is still available or, if migration is
supported, also after a break has been detected, and should attempt
to tear down subflows over paths that are no longer used.  The
Transport Services API's Connection Property "multipath-policy"
allows an application to indicate when and how different paths should
be used.  However, detailed handling of these policies is still
implementation-specific.  For example, if the "multipath" Selection
Property is set to "active", the decision about when to create a new
path or to announce a new path or set of paths to the remote
endpoint, e.g., in the form of additional IP addresses, is
implementation-specific.  If the Protocol Stack includes a transport
protocol that does not support multipath, but does support migrating
between paths, the update to the set of available paths can trigger
the connection to be migrated.
Paragraph (version B):
In case of Pooled Connections pooled-connections, the Transport
Services implementation may add connections over new paths to the
pool if permissible based on the multipath policy and Selection
Properties.  In case a previously used path becomes unavailable, the
transport system may disconnect all connections that require this
path, but should not disconnect the pooled connection object exposed
to the application.  The strategy to do so is implementation-
specific, but should be consistent with the behavior of multipath
transports.