Draft: draft-ietf-taps-interface

Commentary: Inspired by the discussion in , I do n't think we adequately addressed . Abstracting away from current designs , in a connection group there are four possible termination actions : Clean close a connection  a connection Clean close a connection group  a connection group TAPS has all but the third . QUIC has three of these ; SCTP has two ( three with RFC 6525 ) ; HTTP/2 , IIUC , in principle has all four , though I believe RFC 7540 does n't envision HTTP/2 ever initiating TCP RST . There is an complication that in some protocols these are half - closes or half - aborts . I think we 're trying to be too cute by not offering all four of these . Let 's just have all of them ( which means adding CloseGroup ) and then figure out how the protocol mappings respond to actions they do n't actually support . For example -streaming protocols simply apply the close or abort to each of their connections . QUIC gets CloseGroup , it sends clean close on all connections and then sends group abort . ( Note that apps with mandatory streams [ like  ] ca n't use this functionality ) SCTP with 7525 gets ConnectionAbort , it does ConnectionClose instead SCTP without 7525 gets ConnectionClose or  , it 's a NOP . HTTP/2 gets AbortGroup , it sends GOAWAY followed by a CloseGroup . 
 I 'm copy+pasting my answer from the PR here . I 'm not against " let 's just have all of them and then figure out how ... " , but I 'm also not sure if we need to get so complex ? Perhaps .... I 'll just leave this text here for consideration : [ paste from ] About stream abort : not quite , I think . Using a " stream abort " would mean that the TCP - like half - closed behavior would n't work - you could n't send a stream reset and then expect to receive something on a stream . However , that is n't possible anyway , because SCTP streams are only unidirectional . And , there 's only a guarantee of a notification by a returning " stream reset " because we define it in this PR . I agree that this is bigger and should be separate from this PR ... but what 's your plan ? Do we really have a big problem here ? In the end , it 's a matter of having the right semantics at the API level . This began with just picking the strictest possible semantics : no half - closed connections , calling " close " means that what the app already gave to the transport system for transmission before the call will still be sent , but the app can not expect to send or receive anything after this call . This way , SCTP ( which does n't allow half - closed associations ) is covered , and the behavior is " correct " for TCP as well . These semantics also work for SCTP streams with stream reset as above . So ... altogether , I thought we 'll be safe if we just go strict . Now , quite recently , the wording was changed a bit , because of the need to support TCP half - closed connections ( which is implemented via the " Final " Message Property ) . I felt a bit uneasy about this change , but in the end I could n't see how things would go wrong with the wording that we now have in the API draft . My high - level view is that we still have this rather strict thing , and then there is the option to use " Final " , with no guarantee of it working ( because we do n't know if we get a protocol that supports half - closed connections ) . But there may be a devil in the details on how we worded it ... definitely worth another careful look . 
 I agree that our treatment of half and full closes is alright , although it does n't give us away to do a QUIC STOP_SENDING frame , for example . I think the close and abort semantics are quite clear to the application developer , but it 's not sufficient to have them at the Connection level because it can lead to many messages where one would suffice . I do n't like that we 've merged the SCTP SHUTDOWN and ABORT chunks , for instance . 
 Re : the need for more primitives to do , e.g. , STOP_SENDING , I agree . Re : close and abort not being sufficient : I agree . Re : merging SCTP SHUTDOWN and ABORT chunks : that sounds like a mistake that we should n't have made . Which text in which draft gives you this impression ? I checked the implementation draft , it talks about CLOSE.SCTP ( for Close ) and ABORT.SCTP ( for Abort ) , and all of this is preceded by " Below , terms in capitals with a dot ( e.g. , " CONNECT.SCTP " ) refer to the primitives with the same name in section 4 of [ RFC8303 ] . " In RFC 8303 , these terms refer back to the Shutdown and Abort primitives of RFC 4960 ( the current spec at the time RFC 8303 was written ) , where it is explained that these work using the SHUTDOWN and ABORT chunks ... so where is the mistake ? 
 Which text in which draft gives you this impression ? IIUC , for multistreaming protocols Connection . Close ( ) and Connection . Abort ( ) apply to streams while Connection . AbortGroup ( ) applies to the protocol connection / association . We lack a Connection . CloseGroup ( ) and therefore there is no way to trigger a SHUTDOWN chunk . In practice , since stream closing capabilities are slim in SCTP , we can repurpose Close ( ) and  ( ) , but this seems conceptually messier . 
 discussed at 2021 - 02 - 26 interim : we are indeed being a little too cute by pretending an application is n't going to interact with groups . Decision is to add CloseGroup ( ) . 
 Looks good , thanks for doing this !
Paragraph (version A):
Abort terminates a Connection without delivering any remaining data.
This action does not affect any other Connection that is entangled
with this one in a Connection Group.
Paragraph (version A):
AbortGroup terminates a Connection and also terminates any other
Connections that are entangled with this one in a Connection Group.
For example, all of the Connections in a group might be streams of a
single session for a multistreaming protocol; aborting the entire
group would close the underlying session.  See also groups.
Paragraph (version B):
Abort terminates a Connection without delivering any remaining
Messages.  This action does not affect any other Connection that is
entangled with this one in a Connection Group.
Paragraph (version B):
CloseGroup gracefully terminates a Connection and any other
Connections that are entangled with this one in a Connection Group.
For example, all of the Connections in a group might be streams of a
single session for a multistreaming protocol; closing the entire
group will close the underlying session.  See also groups.  As with
Close, any Messages remaining to be processed on a Connection will be
handled prior to closing.
Paragraph (version B):
AbortGroup terminates a Connection and any other Connections that are
entangled with this one in a Connection Group without delivering any
remaining Messages.