Draft: draft-ietf-taps-interface

Commentary: This closed As we have no methods on a connection object that query properties , cansend / canreceive also became connection properties . As with all the other connection properties , these are indeed a little underspecified . I want to keep it that way till we fix it for all connection properties with and 
  … that comes surprising – why did n't you bring this up in ? Do you think this pull - request is the right place to discuss this issue ? I would prefer we merge it now and make a new issue for the question whether the uni - directional connection should be more reflected in the connection . I am not particularly found on keeping it a selection property but would like to have the concept of unidirectional connections rather sooner than later . Our consensus in was that unidirectional connection should use the same abstraction for QUIC unidirectional streams , multicast sources / sinks , and half - closed connections – despite they are constructed in completely different ways . The Selection property is just for the QUIC style ones … 
  … that comes surprising – why did n't you bring this up in ? Do you think this pull - request is the right place to discuss this issue ? Happy to move the discussion back over to the issue if you like . Will continue the thread here for now though since you 've got points to address below . fine , but keep open then , because adding the selection property is possibly - necessary but definitely - not - sufficient to fully address unidirectional connection semantics . good , I agree with this . then I 'm confused why this PR purports to since it only addresses part of the issue ... ? 
 agreed . The question ( and discussion ) was about support for including some support for unidirectional connections ( with focus on QUIC and half - closed ) , but omitted details on multicast , as this has not laned yet . So indeed , this pull - requests does everything requested by , but does not fully capture the topic . I will move the open issues ( Multicast support , is the Selection Property enough , find some place for more explanation of Uni / Bidi Streams ) to once this PR is merged . 
 In Section 9 – " Setting and Querying of Connection Properties " – the properties of an established connection and path are heavily underspecified . Should be fixed along with . 
 I 'm working on this issue within our pull request for , using the terminology as simplified there . For Section 9 , I 'm proposing the following : An application can query Connection Properties on a connection . Connection Properties include the status of the connection and whether it is possible to send and to receive data on it . ( One of them might not be possible , e.g. , in a unidirectional connection . ) Additionally , Connection Properties include the Connection 's Transport Properties . Transport Properties include Selection Properties , so the application can know which Protocol Selection Properties had been specified , and which ones are actually supported by the protocol that has been chosen . For Establishing connections ( i.e. , we are not done racing yet , the final protocols have not been selected yet ) , the application gets the Selection Properties that had been specified on the Preconnection earlier . For Established , Closing , or Closed connections ( i.e. , the protocols have been selected ) , the application learns whether the Selection Properties are actually provided by the selected protocols . For example , if the application specified earlier , " Control Checksum Coverage : Prefer " , now it will get " Control checksum coverage : True " , indicating that on this connection it can indeed control the checksum coverage . Transport Properties also include Protocol Properties (  and Specific ) . These Protocol Properties can still be modified by the application . Basically , Protocol Properties are the only thing that the application can still set , everything else it can only query at this point . Finally , the application can query properties of the path . Not sure how well we have to specify them , probably this part will be implementation - specific just like , e.g. , the Interface Instance or Type . Does everyone agree , or is there anything to discuss here ? For me this is not a big change , it 's just putting what was already there in terms of . The only thing I 'm wondering if whether the Protocol Selection Properties of the finally chosen protocols are still " Selection Properties " , as the selection is already done . That 's why they were called " Transport Features " before , but now I want less terms and they 're almost the same thing ... 
 OK - so I commented on these things before - but in these things I think I agree . I 'd personally prefer to keep the features as attributes implemented in the transport ( etc ) and the properties as the things requested . Indeed this begs the question about what to call the resulting transport when you selected properties and now get a transport . I think still calling them ( for consistency ) properties seems really good to me . :-) . 
 As QUIC has unidirectional streams , we might want to be able to accommodate them in our transport API . Do we want to handle them fundamentally different from a half - closed connection ? This should match the decisions made in . 
 Side note : we do n't support half - closed connections to begin with . As for unidirectional streams , is this the final decision in QUIC 's design , or might it change ? I 'd suggest postponing this until we can be sure . 
 regarding half - closed connections : we do n't have any top - level state in the connection for being half - closed . However , being able to express that a message is final in a given direction when sending allows the same functionality . As I 've discussed before , we absolutely need the ability to express sending a TCP FIN , but I whole - heartedly agree it does n't need to be a top level concept . I think this is somewhat different from half - closing , since a unidirectional stream never allows sending on one end . You could imagine that it is a connection object that returns an error if you ever try to send on it , etc . If you wanted it to look like half - closing , you could open a connection ( stream ) , and then mark it complete in a direction immediately ? But that 's a bit odd . 
 All ok , I agree with your suggestion to fin - mark a message 
 I agreee with regarding half - closed . My suggestion is to explicitly state that connections can be uni- or bi - directional and to add a method to query that ( cansend / canrecv ) . This aligns nicely with final messages after which can_send becomes false . I can do a PR for that . 
 Thanks ! I like this 
 Still missing unidirectional stream for multicast . – please continue discussion of multicast aspects in The connection properties ( can send / receive data ) are still a little under - specified - please discuss in details in – we should fix this together with . 
 We need unidirectional connections . You know , for multicast . And ICN . And unidirectional streaming protocols . 
 This is a dup of , which has more discussion 
 I am re - opening this ticket as only dealt with unidirectional streams in unicast context ( with PR ): Current status : The current model for unidirectional streams supports half - closed connections and QUIC style unidirectional streams so far . We do n't know yet whether it is sufficient to have canread / canwrite property on the connection level to model unidirectional connections We do n't have pre - connection methods to create multicast sessions yet 
 there 's a selection property for this , tagged discuss , which we have n't discussed yet . I 'm moving this down to the appendix as part of my restructuring in my work on 
 If help is still wanted here , I 'm maybe up for an attempt or 2 at adding multicast support . Has there been some prior discussion I can review about rough ideas on pre - connection methods for multicast sessions , or should I just try making something up ? 
 ok , with the caveat that we need to keep multicast as an open issueLGTM About the multicast concern : I agree that it would be good if this could function for multicast reception too , and I could n't tell if this is suitable for multicast . I suspect that multicast support is much harder anyway - see RFC 3678 ... so for now , this is a good step forward IMO , and let 's discuss how this relates to multicast when we see a concrete text proposal that addresses it .
Paragraph (version A):
The Transport Services Interface is the basic common abstract
application programming interface to the Transport Services
Architecture defined in I-D.ietf-taps-arch.  An application primarily
interacts with this interface through two Objects, Preconnections and
Connections.  A Preconnection represents a set of parameters and
constraints on the selection and configuration of paths and protocols
to establish a Connection with a remote endpoint.  A Connection
represents a transport Protocol Stack on which data can be sent to
and received from a remote endpoint.  Connections can be created from
Preconnections in three ways: by initiating the Preconnection (i.e.,
actively opening, as in a client), through listening on the
Preconnection (i.e., passively opening, as in a server), or
rendezvousing on the Preconnection (i.e. peer to peer establishment).
Paragraph (version B):
The Transport Services Interface is the basic common abstract
application programming interface to the Transport Services
Architecture defined in I-D.ietf-taps-arch.  An application primarily
interacts with this interface through two Objects, Preconnections and
Connections.  A Preconnection represents a set of parameters and
constraints on the selection and configuration of paths and protocols
to establish a Connection with a remote endpoint.  A Connection
represents a transport Protocol Stack on which data can be sent to
and/or received from a remote endpoint (i.e., depending on the kind
of transport, connections can be bi-directional or unidirectional).
Connections can be created from Preconnections in three ways: by
initiating the Preconnection (i.e., actively opening, as in a
client), through listening on the Preconnection (i.e., passively
opening, as in a server), or rendezvousing on the Preconnection (i.e.
peer to peer establishment).
Paragraph (version B):
The connection must support sending data.
Paragraph (version B):
In case a unidirectional connection is requested, but the system
should fall back to bidirectional transport if unidirectional
connections are not supported by the transport protocol.
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
unidirectional receive only or if a message with the final
property was sent over this connection.
Paragraph (version B):
Whether the connection can be used to receive data.  A connection
can not be used for reading if the connection was created
unidirectional send only or if a message with the final property
received was received.  The latter is only supported by certain
transport protocols, e.g., by TCP as half-closed connection.