implementation to communicate control data to the Remote Endpoint that can be used to parse Messages.  Similarly, when a Message Framer generates a "Stop" event, the framer implementation has the opportunity to write some final data or clear up its local state before the "Closed" event is delivered to the Application.  The framer implementation can indicate that it has <del> finished with this. </del>  At any time if the implementation encounters a fatal error, it can also cause the Connection to fail and provide an error.

Capitalization seems to be a problem for us. We need to make things uniform. At first, I reacted to seeing "connection" as parameters in this PR, because we use the term "Connection" to refer to a TAPS-provided connection (as opposed to a connection of the underlying system), and so, de-capitalizing the term here may look better, but it is also somewhat imprecise. This said, we do the same with other capitalized terms too, here and in the API draft - e.g., "messageContext". Should we generally agree to begin terms with a lowercase letter when they are used as parameters in code examples? I think we have this in most places, though at least the API draft has several counterexamples... e.g., the server example code: Preconnection := NewPreconnection(LocalSpecifier, TransportProperties, SecurityParameters) (..) Listener -> ConnectionReceived
From discussion on
This was a mistake. As I wanted to do this now, I noticed that all occurrences of capitalized terms as parameters are objects that are defined and used elsewhere in the code examples. For example: Preconnection := NewPreconnection(RemoteSpecifier, TransportProperties, SecurityParameters) refers to RemoteSpecifier etc., being objects that are initialized some lines above. Making them appear in lower case everywhere would be awkward, this is then a much more drastic change to our pseudocode. As a result, I think it's fine to leave things as they are, and I suggest to close this issue with no action.
Framers: What is the difference between the Final message property and the separate IsEndOfMessage event argument?
Also there, the term MessageContext could use a definition
and searching "isEndOfMessage" tells me that there is no text describing this parameter. Regarding the question, the difference should be clear: seems self-explanatory, whereas indicates that the Message carrying it is the last one of the Connection. So, this is End of the Message vs. End of the Connection.
Sounds like this needs a reference to the API doc, and change IsEndOfMessage to endOfMessage to match the API.
Probably fix with
I think this looks ok (and thanks for doing this!), but see also my comment about making things uniform wrt. capitalization: if we merge this PR, we should also do one that does the same with the API draft.Thanks LGTM! Although I noticed another nit that can perhaps be fixed in the same PR even if not directly related to the parameter names. Regarding the capitalization I think we can merge this PR and then have a separate issue for the capitalization as we will need to fix this either way.

implementation to communicate control data to the Remote Endpoint that can be used to parse Messages. <ins> Once the framer implementation has completed its setup or handshake, it can indicate to the application that it is ready to handling data with this call. </ins> Similarly, when a Message Framer generates a "Stop" event, the framer implementation has the opportunity to write some final data or clear up its local state before the "Closed" event is delivered to the Application.  The framer implementation can indicate that it has  <ins> finished with this call. </ins> At any time if the implementation encounters a fatal error, it can also cause the Connection to fail and provide an error.


6.2. Message Framers generate an event whenever a Connection sends a new <del> Message. </del>  Upon receiving this event, a framer implementation is responsible for performing any necessary transformations and sending the resulting

6.2. Message Framers generate an event whenever a Connection sends a new  <ins> Message.  The parameters to the event align with the Send call in the API (Section 9.2 of I-D.ietf-taps-interface). </ins> Upon receiving this event, a framer implementation is responsible for performing any necessary transformations and sending the resulting


In order to parse a received flow of data into Messages, the Message Framer notifies the framer implementation whenever new data is <del> available to parse. </del>  Upon receiving this event, the framer implementation can inspect the inbound data.  The data is parsed from a particular cursor

In order to parse a received flow of data into Messages, the Message Framer notifies the framer implementation whenever new data is  <ins> available to parse.  The parameters to the the events and calls for receiving data with a framer align with the Receive call in the API (Section 9.3 of I-D.ietf-taps-interface). </ins> Upon receiving this event, the framer implementation can inspect the inbound data.  The data is parsed from a particular cursor


the IP header can be obtained (GET_ECN.UDP(-Lite)). Calling "Close" on a UDP Connection (ABORT.UDP(-Lite)) releases <del> the local port reservation. </del>  Calling "Abort" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close", except that the Connection will send <del> a ConnectionError Event rather than a Closed Event. </del>  Calling "CloseGroup" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this Connection and on all

Takes care of item 5 and .
See discussion on
Provide a complete template that covers all functions/properties from the API. Indicate how the template should be used (e.g. leave out the parts that are not relevant for a particular protocol or include all fields and mark fields that are not relevant as such.
I'm wondering if this is really something that's in scope that we should cover. We do have the message properties section that explains how to implement various properties, but I think adding each property to every protocol mapping will be a huge amount of text that will be difficult to get exactly right.
I agree, we have added additional properties since we opened this issue to check the mapping and make sure we have a complete coverage. We should still be consistent in how we treat things though, and perhaps add a sentence that we do not describe all the properties for instance. I have made a pass through to check the mapping from the API to impl. draft for all the protocol mappings as a basis for making things consistent. Here is the summary. We cover the same actions and events for all the protocols with the exceptions that UDP Multicast does not cover the ConnectionError event and SCTP covers the Priority connection property. And MPTCP and UDP-lite are special as they refer back to the base protocols. There is one terminology inconsistency where the impl. draft refers to InitiateError and this has been generalized to EstablishmentError in the API Unless I missed something, there are only two actions that can be made on a connection that are not covered, addRemote and removeRemote. This is probably fine as they do not mean much for most of the protocols (or we could add them to be complete). We should perhaps mention how they relate to MPTCP though if we leave them out. We also do not cover the Preconnection.Rendezvous action. Again this may be fine as it is a bit special (or we can mention it for consistency.) For the events, we cover a subset with main focus on the connection related events. The Closed Event and some events related to connection setup are missing. As we cover ConnectionError we should perhaps cover the Closed event as well? We do not cover any of the Send or Receive events which seems fine. In relation to Connection and Message properties, we do not cover any of them except for the Connection priority covered for SCTP and we talk about some properties in connection to UDP-lite and MPTCP. SCTP also has support for partial reliability and unordered messages so not sure why the priority part was singled out and added. NAME any particular reasoning behind this part? Possibly we should remove the priority part for SCTP or discuss it in running text in a similar fashion as for UDP-lite and MPTCP We may want to update the UDP-lite description to also say something about what properties it supports over UDP. The current description sounds like it is a subset. Once we agree on how to deal with the bullets above, only smaller modifications should be needed to the text.
ConnectionError should be added; SCTP priority should be removed Fix the inconsistency Add addRemote and removeRemote text related to MPTCP No action Mention Closed Event See item 1, no further action Update UDP-Lite description

the IP header can be obtained (GET_ECN.UDP(-Lite)). Calling "Close" on a UDP Connection (ABORT.UDP(-Lite)) releases  <ins> the local port reservation.  The Connection then issues a "Closed" event. </ins> Calling "Abort" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close", except that the Connection will send  <ins> a "ConnectionError" Event rather than a "Closed" Event. </ins> Calling "CloseGroup" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this Connection and on all


Calling "Close" on a UDP Multicast Receive Connection (ABORT.UDP(- Lite)) releases the local port reservation and leaves the group.  Calling "Abort" on a UDP Multicast Receive Connection (ABORT.UDP(- <del> Lite)) is identical to calling "Close". </del>  Calling "CloseGroup" on a UDP Multicast Receive Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this

Calling "Close" on a UDP Multicast Receive Connection (ABORT.UDP(- Lite)) releases the local port reservation and leaves the group. <ins> The Connection then issues a "Closed" Event. </ins> Calling "Abort" on a UDP Multicast Receive Connection (ABORT.UDP(-  <ins> Lite)) is identical to calling "Close", except that the Connection will send a "ConnectionError" Event rather than a "Closed" Event. </ins> Calling "CloseGroup" on a UDP Multicast Receive Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this


Protocol-specific Properties MUST use the protocol acronym as the Namespace (e.g., a "tcp" Connection could support a TCP-specific <del> Transport Property, such as the user timeout value, in a protocol- specific property called "tcp.userTimeoutValue" (see tcp-uto). </del>  Vendor or implementation specific properties MUST use a string identifying the vendor or implementation as the Namespace.

We don't have "Protocol Properties" - two occurrences in -interface should really refer to "protocol-specific Properties", and two occurrences in -impl should really refer to properties.
URL Are Protocol Specific Properties and Protocol Properties same or different? Also note that we are first time defining the Protocol Properties in the interface document ( described along with Connection Properties) and not introduced in the architecture document. I think we should be clear about what we are defining where and describing where. I would suggest use of cross reference rather describing everything again and again, which might create confusion and inconsistency.
Oh, this seems like a mistake (great catch, thanks!) - "Protocol Properties" don't exist, I think we only have "protocol-specific Properties".
I caught this when reading the implementation doc. So it should be fixed there as well.

Protocol-specific Properties MUST use the protocol acronym as the Namespace (e.g., a "tcp" Connection could support a TCP-specific  <ins> Transport Property, such as the user timeout value, in a Protocol- specific Property called "tcp.userTimeoutValue" (see tcp-uto). </ins> Vendor or implementation specific properties MUST use a string identifying the vendor or implementation as the Namespace.


Namespaces for each of the keywords provided in the IANA protocol numbers registry (see https://www.iana.org/assignments/protocol- <del> numbers/protocol-numbers.xhtml) are reserved for protocol-specific </del>  Properties and MUST NOT be used for vendor or implementation-specific properties.  Avoid using any of the terms listed as keywords in the protocol numbers registry as any part of a vendor- or implementation-

Namespaces for each of the keywords provided in the IANA protocol numbers registry (see https://www.iana.org/assignments/protocol-  <ins> numbers/protocol-numbers.xhtml) are reserved for Protocol-specific </ins> Properties and MUST NOT be used for vendor or implementation-specific properties.  Avoid using any of the terms listed as keywords in the protocol numbers registry as any part of a vendor- or implementation-


The optional "connectionProperties" parameter allows passing Transport Properties that control the behavior of the underlying <del> stream or connection to be created, e.g., protocol-specific properties to request specific stream IDs for SCTP or QUIC. </del>  Message Properties set on a Connection also apply only to that Connection.

The optional "connectionProperties" parameter allows passing Transport Properties that control the behavior of the underlying  <ins> stream or connection to be created, e.g., Protocol-specific Properties to request specific stream IDs for SCTP or QUIC. </ins> Message Properties set on a Connection also apply only to that Connection.


Protocol-specific Properties are defined in a transport- and implementation-specific way to permit more specialized protocol features to be used.  Too much reliance by an application on <del> protocol-specific Properties can significantly reduce the flexibility </del>  of a transport services implementation to make appropriate selection and configuration choices.  Therefore, it is RECOMMENDED that <del> Protocol Properties are used for properties common across different protocols and that Protocol-specific Properties are only used where specific protocols or properties are necessary. </del>  The application can set and query Connection Properties on a per- Connection basis.  Connection Properties that are not read-only can

Protocol-specific Properties are defined in a transport- and implementation-specific way to permit more specialized protocol features to be used.  Too much reliance by an application on  <ins> Protocol-specific Properties can significantly reduce the flexibility </ins> of a transport services implementation to make appropriate selection and configuration choices.  Therefore, it is RECOMMENDED that  <ins> Protocol-specific Properties are used for properties common across different protocols and that Protocol-specific Properties are only used where specific protocols or properties are necessary. </ins> The application can set and query Connection Properties on a per- Connection basis.  Connection Properties that are not read-only can


Message Properties can be set and queried using the Message Context: <del> These Message Properties may be generic properties or protocol- </del>  specific Properties. For MessageContexts returned by send Events (see send-events) and

Message Properties can be set and queried using the Message Context:  <ins> These Message Properties may be generic properties or Protocol- </ins> specific Properties. For MessageContexts returned by send Events (see send-events) and


In the following cases, failure should be detected during pre- establishment: <del> A request by an application for Protocol Properties that cannot be </del>  satisfied by any of the available protocols.  For example, if an application requires "perMsgReliability", but no such feature is available in any protocol on the host running the transport system this should result in an error, e.g., when SCTP is not supported by the operating system. <del> A request by an application for Protocol Properties that are in conflict with each other, i.e., the required and prohibited properties cannot be satisfied by the same protocol.  For example, if an application prohibits "reliability" but then requires </del>  "perMsgReliability", this mismatch should result in an error. To avoid allocating resources that are not finally needed, it is

In the following cases, failure should be detected during pre- establishment:  <ins> A request by an application for properties that cannot be </ins> satisfied by any of the available protocols.  For example, if an application requires "perMsgReliability", but no such feature is available in any protocol on the host running the transport system this should result in an error, e.g., when SCTP is not supported by the operating system.  <ins> A request by an application for properties that are in conflict with each other, i.e., the required and prohibited properties cannot be satisfied by the same protocol.  For example, if an application prohibits "reliability" but then requires </ins> "perMsgReliability", this mismatch should result in an error. To avoid allocating resources that are not finally needed, it is


implementation should store the properties in storage common to all protocols, and notify all protocol instances in the Protocol Stack whenever the properties have been modified by the application.  For <del> protocol-specfic properties, such as the User Timeout that applies to TCP, the Transport Services implementation only needs to update the relevant protocol instance. </del>  If an error is encountered in setting a property (for example, if the application tries to set a TCP-specific property on a Connection that

implementation should store the properties in storage common to all protocols, and notify all protocol instances in the Protocol Stack whenever the properties have been modified by the application.  For  <ins> Protocol-specific Properties, such as the User Timeout that applies to TCP, the Transport Services implementation only needs to update the relevant protocol instance. </ins> If an error is encountered in setting a property (for example, if the application tries to set a TCP-specific property on a Connection that


SHOULD be made accessible through a unified set of calls using the Transport Services API.  As a baseline, any Transport Services API SHOULD allow access to the minimal set of features offered by <del> transport protocols RFC8923. </del>  An application can specify constraints and preferences for the protocols, features, and network interfaces it will use via

URL Assuming there would be more protocols in the future and the minset functionalities will expand via extension or amendments. It would important to indicate if this architecture should is also extensible or it only supports on the minimum set referred. Definitely we haven't seen the future yet, but it would be important to express if we have considered such expansion of minimum functionalities.
To me, the current spec is based on minset that describes the common functions. So, the addition I would expect here is to say that there can be extensions and protocol-specific features.
I expect that if a common feature is added to the minset, then the architecture and API surface would also be extended to match.
LGTM modulo a nit

SHOULD be made accessible through a unified set of calls using the Transport Services API.  As a baseline, any Transport Services API SHOULD allow access to the minimal set of features offered by  <ins> transport protocols RFC8923.  If that minimal set is updated or expanded in the future, the Transport Services API ought to be extended to match. </ins> An application can specify constraints and preferences for the protocols, features, and network interfaces it will use via


setting Connection and Message Properties in Pre-Establishment) or have been omitted for brevity and simplicity.  4.1.1. Endpoint: An endpoint represents an identifier for one side of a

URL Unless there is a description the figure, with directed and non-directed lines it is very hard to interpret the figure. I would recommend to at least add some reading guidance for the lines.
LGTM, thanks!Looks fine.

setting Connection and Message Properties in Pre-Establishment) or have been omitted for brevity and simplicity. <ins> In this diagram, the lifetime of a Connection object is broken into three phases: Pre-Establishment, the Established state, and Termination. Pre-Establishment is based around a Preconnection object, that contains various sub-objects that describe the properties and parameters of desired Connections (Local and Remote Endpoints, Transport Properties, and Security Parameters).  A Preconnection can be used to start listening for inbound connections, in which case a Listener object is created, or can be used to establish a new connection directly using Initiate() (for outbound connections) or Rendezvous() (for peer-to-peer connections). Once a Connection is in the Established state, an application can send and receive Message objects, and receive state updates. Closing or aborting a connection, either locally or from the peer, can terminate a connection. </ins> 4.1.1. Endpoint: An endpoint represents an identifier for one side of a


application. Framer: A Framer is a data translation layer that can be added to <del> a Connection to define how application-layer Messages are transmitted over a Protocol Stack.  This is particularly relevant when using a protocol that otherwise presents unstructured streams, such as TCP. </del>  4.1.6.

(sorry that it took me so long) This uses some text that is also in the interface draft.
This I would like us to discuss. Well I know we have discussed this before. As I am reading the Interface document after a long while and having read it along with the architecture document, I kind of strongly feel that the architecture document lack of description on framer and the states. These are mentioned and pictured in the architecture document but haven't been clear there. Hence, I kind of feel that we need to move this two sections to architecture document. Please discuss so that I can understand the reasoning of not doing so.
Regarding section 9.1.2, the framer description: I think it's good to be clear and complete in the API document, but I agree that framers should be appropriately described in the architecture document. I have the impression that the text in the -arch document on this matter may indeed be too short, while the text in the -interface document may be too long (although a little bit of repetition surely won't hurt here, it's good for this document to be understandable and clear on its own). Maybe some of it could be moved to -arch, or repeated there? Regarding section 11, Connection states: to me, this is fine as it is. Section 4.1 / figure 4 in the architecture document make state transitions pretty clear - and section 11 / figure 2 are just a more fine-grain look at these states as a way to explain exactly which Events will occur when. This seems needed in the API document, where all other Events and Actions are defined, and I would think that this is at a too detailed / fine-grain level for the architecture document.
NAME after giving it some more thoughts, I think your suggested approach should be fine , meaning we put more description of framer in the architecture document and leave the connection states to the Interface document.
NAME did you want to take a stab at this?
Looks great!

application. Framer: A Framer is a data translation layer that can be added to  <ins> a Connection.  Framers allow extending a Connection's protocol stack to define how to encapsulate or encode outbound Messages, and how to decapsulate or decode inbound data into Messages.  In this way, message boundaries can be preserved when using a Connection object, even with a protocol that otherwise presents unstructured streams, such as TCP.  This is designed based on the fact that many of the current application protocols evolved over TCP, which does not provide message boundary preservation, and since many of these protocols require message boundaries to function, each application layer protocol has defined its own framing.  For example, when an HTTP application sends and receives HTTP messages over a byte-stream transport, it must parse the boundaries of HTTP messages from the stream of bytes. </ins> 4.1.6.


1.4. This subsection provides a glossary of key terms related to the <del> Transport Services architecture.  It provides a simple description of </del>  key terms that are later defined in this document. Application: An entity that uses the transport layer for end-to-

Feel free to approve or propose changes to improve this sentence in Arch.
BT: "I’m not convinced of the value of the glossary of terms, as it forwardrefs basically the entire document, and some of the definitions are so generic as to be potentially confusing (e.g. Event), so I think putting these up front reduces the document’s approachability and readability. I understand that some people like these (and other standards orgs make them mandatory, hi ETSI), so I won’t fight it." "Adding a sentence making it clear it’s safe to skip the glossary if you’re going to read the rest of the document would address my approachability concern completely. "

1.4. This subsection provides a glossary of key terms related to the  <ins> Transport Services architecture.  It provides a short description of </ins> key terms that are later defined in this document. Application: An entity that uses the transport layer for end-to-


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 <del> 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). </del>  Once a Connection is established, data can be sent on it in the form of Messages.  The interface supports the preservation of message

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
Aehm… that comes surprising – NAME why didn'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…

Aehm… that comes surprising – NAME why didn'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...?
NAME 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 (Generic 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 don'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.
NAME regarding half-closed connections: we don'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 doesn'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 NAME 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 (added with PR ): Current status: The current model for unidirectional streams supports half-closed connections and QUIC style unidirectional streams so far. We don't know yet whether it is sufficient to have canread/canwrite property on the connection level to model unidirectional connections We don't have pre-connection methods to create multicast sessions yet
there's a selection property for this, tagged discuss, which we haven'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 couldn'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.

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  <ins> 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). </ins> Once a Connection is established, data can be sent on it in the form of Messages.  The interface supports the preservation of message


5.2.4.  Type: Preference This property specifies whether an application would like to supply a

5.2.4. <ins> Type: Enum This property specifies whether an application wants to use the connection for sending and/or receiving data.  Possible values are: The connection must support sending and receiving data The connection must support sending data. The connection must support receiving data 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. 5.2.5. </ins> Type: Preference This property specifies whether an application would like to supply a


also send-idempotent.  This is a strict requirement.  The default is to not have this option. <del> 5.2.5. </del>  Type: Preference

also send-idempotent.  This is a strict requirement.  The default is to not have this option.  <ins> 5.2.6. </ins> Type: Preference


single underlying transport connection where possible.  This is not a strict requirement.  The default is to not have this option. <del> 5.2.6. </del>  Type: Boolean

single underlying transport connection where possible.  This is not a strict requirement.  The default is to not have this option.  <ins> 5.2.7. </ins> Type: Boolean


This property applies to Connections and Connection Groups.  The default is to have this option. <del> 5.2.7. </del>  Type: Boolean

This property applies to Connections and Connection Groups.  The default is to have this option.  <ins> 5.2.8. </ins> Type: Boolean


This property applies to Connections and Connection Groups.  The default is not to have this option. <del> 5.2.8. </del>  Type: Preference

This property applies to Connections and Connection Groups.  The default is not to have this option.  <ins> 5.2.9. </ins> Type: Preference


The default is full checksum coverage without being able to change it, and requiring a checksum when receiving. <del> 5.2.9. </del>  Type: Tuple (Enumeration, Preference)

The default is full checksum coverage without being able to change it, and requiring a checksum when receiving.  <ins> 5.2.10. </ins> Type: Tuple (Enumeration, Preference)


in the system policy.  The valid values for the access network interface kinds are implementation specific. <del> 5.2.10. </del>  Type: Enumeration

in the system policy.  The valid values for the access network interface kinds are implementation specific.  <ins> 5.2.11. </ins> Type: Enumeration


The status of the Connection, which can be one of the following: Establishing, Established, Closing, or Closed.  Transport Features of the protocols that conform to the Required and Prohibited Transport Preferences, which might be selected by the transport system during Establishment.  These features

The status of the Connection, which can be one of the following: Establishing, Established, Closing, or Closed. <ins> 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. 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. </ins> Transport Features of the protocols that conform to the Required and Prohibited Transport Preferences, which might be selected by the transport system during Establishment.  These features


Changing one of these Protocol Properties on one Connection in the group changes it for all others.  Per-Message Protocol Properties, however, are not entangled.  For example, changing "Timeout for <del> aborting Connection" (see timeout) on one Connection in a group will automatically change this Protocol Property for all Connections in the group in the same way.  However, changing "Lifetime" (see msg- </del>  lifetime) of a Message will only affect a single Message on a single Connection, entangled or not.

This is the second step towards applying our new Properties Classification. It moves up the Connection Properties and annotates most places with stuff to do.
As discussed in
Thanks for moving this forward! I only found a few nits. Also, I have a question about whether two of these Properties should maybe be changed to be Selection Properties, but that's more of a discussion and not something that needs to be done in this URL modulo NAME commentsI carefully checked it, but I find it very hard to be sure that this is 100% ok (as is usually the case IMO with diff's about text blocks being moved around). My suggestion is to land it and see.

Changing one of these Protocol Properties on one Connection in the group changes it for all others.  Per-Message Protocol Properties, however, are not entangled.  For example, changing "Timeout for  <ins> aborting Connection" (see conn-timeout) on one Connection in a group will automatically change this Protocol Property for all Connections in the group in the same way.  However, changing "Lifetime" (see msg- </ins> lifetime) of a Message will only affect a single Message on a single Connection, entangled or not.


9. <del> The application can set per-connection Protocol Properties (see protocol-props).  Certain Procotol Properties may be read-only, on a protocol- and property-specific basis.  ~~~ Connection.SetProperty(property, value) ~~~ </del>  At any point, the application can query Connection Properties.  ~~~ ConnectionProperties := Connection.GetProperties() ~~~

9.  <ins> 9.1. The application can set per-connection Properties.  Certain Connection Properties may be read-only, on a protocol- and property- specific basis.  ~~~ Connection.SetProperty(property, value) ~~~ </ins> At any point, the application can query Connection Properties.  ~~~ ConnectionProperties := Connection.GetProperties() ~~~


Depending on the status of the connection, the queried Connection Properties will include different information:  The status of the connection, which can be one of the following: Establishing, Established, Closing, or Closed.

Depending on the status of the connection, the queried Connection Properties will include different information: <ins> [TODO: turn this list into actual properties or move up into the explaining text] </ins> The status of the connection, which can be one of the following: Establishing, Established, Closing, or Closed.


domain RFC7556, measurements by the Protocol Stack, or other sources.  Slightly different from "querying", a SoftError Event can also occur, informing the application about the receipt of an ICMP error message related to the Connection.  This will only happen if the underlying

domain RFC7556, measurements by the Protocol Stack, or other sources. <ins> 9.1.1. Boolean This property specifies whether an application considers it useful to be informed in case sent data was retransmitted more often than a certain threshold.  When set to true, the effect is twofold: The application may receive events in case excessive retransmissions.  In addition, the transport system considers this as a preference to use transports stacks that can provide this notification.  This is not a strict requirement.  If set to false, no notification of excessive retransmissions will be sent and this transport feature is ignored for protocol selection. The default is to have this option. 9.1.2. Integer This property specifies after how many retransmissions to inform the application about "Excessive Retransmissions". 9.1.3. Boolean This property specifies whether an application considers it useful to be informed when an ICMP error message arrives that does not force termination of a connection.  When set to true, received ICMP errors will be available as SoftErrors.  Note that even if a protocol supporting this property is selected, not all ICMP errors will necessarily be delivered, so applications cannot rely on receiving them.  Setting this option also implies a preference to prefer transports stacks that can provide this notification.  If not set, no events will be sent for ICMP soft error message and this transport feature is ignored for protocol selection. This property applies to Connections and Connection Groups.  The default is not to have this option. 9.1.4. Integer This property specifies the part of the received data that needs to be covered by a checksum.  It is given in Bytes.  A value of 0 means that no checksum is required, and a special value (e.g., -1) indicates full checksum coverage. 9.1.5. Integer This Property is a non-negative integer representing the relative inverse priority of this Connection relative to other Connections in the same Connection Group.  It has no effect on Connections not part of a Connection Group.  As noted in groups, this property is not entangled when Connections are cloned. 9.1.6. Integer 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. 9.1.7. Enum This property specifies which scheduler should be used among Connections within a Connection Group, see groups.  The set of schedulers can be taken from I-D.ietf-tsvwg-sctp-ndata. 9.1.8. Integer (read only) This property represents the maximum Message size that can be sent before or during Connection establishment, see also msg-idempotent. It is given in Bytes. 9.1.9. Integer (read only) This property, if applicable, represents the maximum Message size that can be sent without incurring network-layer fragmentation or transport layer segmentation at the sender. 9.1.10. Integer (read only) This property represents the maximum Message size that can be sent. 9.1.11. Integer (read only) This numeric property represents the maximum Message size that can be received. 9.2. </ins> Slightly different from "querying", a SoftError Event can also occur, informing the application about the receipt of an ICMP error message related to the Connection.  This will only happen if the underlying


12. <del> Having discussed Transport Properties in connection-props and listed a number of Message Properties ("Ordered", "Idempotent" etc.) in message-props, we now provide a complete overview of a transport system's defined Transport Properties. Properties are structured in two ways: </del>  <del> By how they influence the transport system, which leads to a classification into "Selection Properties", "Protocol Properties", "Control Properties" and "Intents". </del>  <del> By the object they can be applied to: Preconnections, see connection-props, Connections, see introspection, and Messages, see message-props. Because some properties can be applied or queried on multiple objects, all Transport Properties are organized within a single namespace. </del>  Note that it is possible for a set of specified Transport Properties to be internally inconsistent, or to be inconsistent with the later

12.  <ins> Having discussed Selection Properties in selection-props, Connection Properties connection-props, and Message Properties (message-props), we now provide a complete overview of a transport system's defined Transport Properties. </ins>  <ins> Transport Properties are structured by the phase and object they are applied: - Selection Properties apply to Preconnections - see selection-props - Connections Properties apply to Connections - see connection-props - Messages Properties apply to Messages - see </ins>  <ins> All Transport Properties are organized within a single namespace. This enables setting them as defaults in earlier stages and querying them in later stages: - Connections Properties can be set on Preconnections - Message Properties can be set on Preconnections and Connections - The effect of Selection Properties can be queried on Connections and Messages. </ins> Note that it is possible for a set of specified Transport Properties to be internally inconsistent, or to be inconsistent with the later


12.2. <del> Transport Properties - whether they apply to connections, preconnections, or messages - differ in the way they affect the transport system and protocols exposed through the transport system. The classification proposed below emphasizes two aspects of how properties affect the transport system, so applications know what to expect: Whether properties affect protocols exposed through the transport system (Protocol Properties) or the transport system itself (Control Properties) Whether properties have a clearly defined behavior that is likely to be invariant across implementations and environments (Protocol Properties and Control Properties) or whether the properties are interpreted by the transport system to provide a best effort service that matches the application needs as closely as possible (Intents). </del>  12.2.1.

12.2.  <ins> [TODO: This section is mostly obsolete due to our consensus on how to structure properties - double-check whether text needs to be moved and delete this section afterwards] </ins> 12.2.1.


12.3.11. <del> Control Property [TODO: Discuss] Boolean Preconnection, Connection This property specifies whether an application considers it useful to be informed in case sent data was retransmitted more often than a certain threshold.  When set to true, the effect is twofold: The application may receive events in case excessive retransmissions.  In addition, the transport system considers this as a preference to use transports stacks that can provide this notification.  This is not a strict requirement.  If set to false, no notification of excessive retransmissions will be sent and this transport feature is ignored for protocol selection. The default is to have this option. </del>  12.3.12. <del> Control Property [TODO: Discuss] Integer Preconnection, Connection This property specifies after how many retransmissions to inform the application about "Excessive Retransmissions". </del>  12.3.13. <del> Control Property [TODO: Discuss] Boolean Preconnection, Connection This property specifies whether an application considers it useful to be informed when an ICMP error message arrives that does not force termination of a connection.  When set to true, received ICMP errors will be available as SoftErrors.  Note that even if a protocol supporting this property is selected, not all ICMP errors will necessarily be delivered, so applications cannot rely on receiving them.  Setting this option also implies a preference to prefer transports stacks that can provide this notification.  If not set, no events will be sent for ICMP soft error message and this transport feature is ignored for protocol selection. This property applies to Connections and Connection Groups.  The default is not to have this option. </del>  12.3.14.

12.3.11.  <ins> Boolean Connection Property - see conn-retrans-notify. </ins> 12.3.12.  <ins> Integer Connection Property - see </ins> 12.3.13.  <ins> Boolean Connection Property - see </ins> 12.3.14.


12.3.16. <del> Protocol Property (Generic) Integer Connection This property specifies the part of the received data that needs to be covered by a checksum.  It is given in Bytes.  A value of 0 means that no checksum is required, and a special value (e.g., -1) indicates full checksum coverage. </del>  12.3.17.

12.3.16.  <ins> Integer Connection Property - see </ins> 12.3.17.


12.3.21. <del> Protocol Property (Generic) Integer Connection This Property is a non-negative integer representing the relative inverse priority of this Connection relative to other Connections in the same Connection Group.  It has no effect on Connections not part of a Connection Group.  As noted in groups, this property is not entangled when Connections are cloned. </del>  12.3.22. [TODO: Discuss: should we remove this?  Whether we need this or the other depends on how we want to implement multi-streaming.  We don't <del> need both, so we should make a decision.] </del>  Integer Message Property - see msg-niceness.

12.3.21.  <ins> Integer Connection Property - see </ins> 12.3.22. [TODO: Discuss: should we remove this?  Whether we need this or the other depends on how we want to implement multi-streaming.  We don't  <ins> need both, so we should make a decision. @mwelzl - These are really two different things @philsbln] </ins> Integer Message Property - see msg-niceness.


12.3.23. <del> Control Property [TODO: Discuss] Integer Preconnection, Connection 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. </del>  12.3.24. <del> Protocol Property (Generic) / Control Property [TODO: Discuss] Enum Preconnection, Connection This property specifies which scheduler should be used among Connections within a Connection Group, see groups.  The set of schedulers can be taken from I-D.ietf-tsvwg-sctp-ndata. </del>  12.3.25. <del> Protocol Property (Generic) Integer Connection (read only) This property represents the maximum Message size that can be sent before or during Connection establishment, see also msg-idempotent. It is given in Bytes.  This property is read-only. </del>  12.3.26. <del> Protocol Property (Generic) Integer Connection (read only) This property, if applicable, represents the maximum Message size that can be sent without incurring network-layer fragmentation or transport layer segmentation at the sender.  This property is read- only. </del>  12.3.27. <del> Protocol Property (Generic) Integer Connection (read only) This property represents the maximum Message size that can be sent. This property is read-only. </del>  12.3.28. <del> Protocol Property (Generic) Integer Connection (read only) This numeric property represents the maximum Message size that can be received.  This property is read-only. </del>  12.3.29.

12.3.23.  <ins> Integer Connection Property - see </ins> 12.3.24.  <ins> Enum Connection Property - see </ins> 12.3.25.  <ins> Integer Connection Property (read-only) - see </ins> 12.3.26.  <ins> Integer Connection Property (read-only) - see </ins> 12.3.27.  <ins> Integer Connection Property (read-only) - see </ins> 12.3.28.  <ins> Integer Connection Property (read-only) - see </ins> 12.3.29.


used to fine-tune the eventually established connection.  These Connection Properties can also be used to monitor and fine-tune established connections.  The behavior of the selected protocol <del> stack(s) when sending Messages is controlled by Message Context Properties message-props. Collectively, Selection, Connection, and Message Context Properties can be referred to as Transport Properties.  All Transport Properties, regardless of the phase in which they are used, are organized within a single namespace.  This enables setting them as defaults in earlier stages and querying them in later stages: - Connection Properties can be set on Preconnections - Message Properties can be set on Preconnections and Connections - The effect of Selection Properties can be queried on Connections and Messages </del>  Transport Properties can have one of a set of data types:

Message Context Parameters/Properties are now Message Properties, and associated terminology cleanup. Addresses part of the resolution to .
Looks good, thanks for the cleanup!LGTM

used to fine-tune the eventually established connection.  These Connection Properties can also be used to monitor and fine-tune established connections.  The behavior of the selected protocol  <ins> stack(s) when sending Messages is controlled by Message Properties message-props. Collectively, Selection, Connection, and Message Properties can be referred to as Transport Properties.  All Transport Properties, regardless of the phase in which they are used, are organized within a single namespace.  This enables setting them as defaults in earlier stages and querying them in later stages: - Connection Properties can be set on Preconnections - Message Properties can be set on Preconnections and Connections - The effect of Selection Properties can be queried on Connections and Messages </ins> Transport Properties can have one of a set of data types:


Initiate. An InitiateError occurs either when the set of transport properties <del> and cryptographic parameters cannot be fulfilled on a Connection for </del>  initiation (e.g. the set of available Paths and/or Protocol Stacks meeting the constraints is empty) or reconciled with the local and/or remote endpoints; when the remote specifier cannot be resolved; or

Initiate. An InitiateError occurs either when the set of transport properties  <ins> and security parameters cannot be fulfilled on a Connection for </ins> initiation (e.g. the set of available Paths and/or Protocol Stacks meeting the constraints is empty) or reconciled with the local and/or remote endpoints; when the remote specifier cannot be resolved; or


Applications may need to annotate the Messages they send with extra information to control how data is scheduled and processed by the <del> transport protocols in the Connection.  A messageContext object contains parameters for sending Messages, and can be passed to the </del>  Send Action.  Note that these properties are per-Message, not per- Send if partial Messages are sent (send-partial).  All data blocks associated with a single Message share properties.  For example, it

Applications may need to annotate the Messages they send with extra information to control how data is scheduled and processed by the  <ins> transport protocols in the Connection.  A MessageContext object contains properties for sending Messages, and can be passed to the </ins> Send Action.  Note that these properties are per-Message, not per- Send if partial Messages are sent (send-partial).  All data blocks associated with a single Message share properties.  For example, it


allow the end of a Message to still be sent. The simpler form of Send that does not take any messageContext is <del> equivalent to passing a default messageContext with not values added. </del>  If an application wants to override Message Properties for a specific <del> message, it can acquire an empty messageContext Object and add all </del>  desired Message Properties to that Object.  It can then reuse the same messageContext Object for sending multiple Messages with the same properties. <del> Parameters may be added to a messageContext object only before the </del>  context is used for sending.  Once a messageContext has been used <del> with a Send call, modifying any of its parameters is invalid. </del>  Message Properties may be inconsistent with the properties of the Protocol Stacks underlying the Connection on which a given Message is

allow the end of a Message to still be sent. The simpler form of Send that does not take any messageContext is  <ins> equivalent to passing a default MessageContext with not values added. </ins> If an application wants to override Message Properties for a specific  <ins> message, it can acquire an empty MessageContext Object and add all </ins> desired Message Properties to that Object.  It can then reuse the same messageContext Object for sending multiple Messages with the same properties.  <ins> Properties may be added to a MessageContext object only before the </ins> context is used for sending.  Once a messageContext has been used  <ins> with a Send call, modifying any of its properties is invalid. </ins> Message Properties may be inconsistent with the properties of the Protocol Stacks underlying the Connection on which a given Message is


Sending a Message with Message Properties inconsistent with the Selection Properties of the Connection yields an error. <del> The following Message Context Parameters are supported: </del>  7.3.1.

Sending a Message with Message Properties inconsistent with the Selection Properties of the Connection yields an error.  <ins> The following Message Properties are supported: </ins> 7.3.1.


The following example sends a Message in two separate calls to Send. <del> All messageData sent with the same messageContext object will be treated as belonging to the same Message, and will constitute an in- order series until the endOfMessage is marked.  Once the end of the Message is marked, the messageContext object may be re-used as a new Message with identical parameters. </del>  7.5.

The following example sends a Message in two separate calls to Send.  <ins> All data sent with the same MessageContext object will be treated as belonging to the same Message, and will constitute an in-order series until the endOfMessage is marked.  Once the end of the Message is marked, the MessageContext object may be re-used as a new Message with identical parameters. </ins> 7.5.


invoke Receive again. Multiple invocations of ReceivedPartial deliver data for the same <del> Message by passing the same messageContext, until the endOfMessage </del>  flag is delivered or a ReceiveError occurs.  All partial blocks of a single Message are delivered in order without gaps.  This event does not support delivering discontiguous partial Messages.

invoke Receive again. Multiple invocations of ReceivedPartial deliver data for the same  <ins> Message by passing the same MessageContext, until the endOfMessage </ins> flag is delivered or a ReceiveError occurs.  All partial blocks of a single Message are delivered in order without gaps.  This event does not support delivering discontiguous partial Messages.


conditions that irrevocably lead to the termination of the Connection are signaled using ConnectionError instead (see termination). <del> The ReceiveError event passes an optional associated messageContext. </del>  This may indicate that a Message that was being partially received previously, but had not completed, encountered an error and will not be completed.

conditions that irrevocably lead to the termination of the Connection are signaled using ConnectionError instead (see termination).  <ins> The ReceiveError event passes an optional associated MessageContext. </ins> This may indicate that a Message that was being partially received previously, but had not completed, encountered an error and will not be completed.


RFC7657 apply. The Capacity Profile for a selected protocol stack may be modified on <del> a per-Message basis using the Transmission Profile Message Context Property; see send-profile. </del>  9.2.

RFC7657 apply. The Capacity Profile for a selected protocol stack may be modified on  <ins> a per-Message basis using the Transmission Profile Message Property; see send-profile. </ins> 9.2.


Abstract This document provides an overview of the architecture of Transport <del> Services, a system for exposing the features of transport protocols to applications.  This architecture serves as a basis for Application Programming Interfaces (APIs) and implementations that provide flexible transport networking services.  It defines the common set of terminology and concepts to be used in more detailed discussion of Transport Services. </del>  1.

Thanks for these fixes! I did a bit of reworking of the abstract, but it keeps the main part of the changes you made.
Regarding the sentence you removed, that was an adaption of an existing sentence, which I believe aimed to mention the words implementation and API to implicitly refere to the other docs (which was probably too subtle for anybody to notice anyway). However, the other change I made to that sentence was to mention one of the benefits / deployment incentives for taps (dynamic protocol and path selection). I wasn't sure about the wording here, but I think it would be good to (re-)add a sentence to the abstract saying why taps is so great and that everybody should deploy it.
Yes, the original second sentence was aimed at mentioning that there were two other documents, API and Implementation, that would be based on this one. I liked how in your revision, it did try to make things clearer than just saying "flexible transport networking services", but I felt that the specific example of dynamic path and protocol selection was a bit too specific for that one line. (I was chatting with NAME about this as I was editing, btw). My thought was that the list of features that you added in right after that, which go through the top-level bullet points of the advantages, do a more comprehensive job of summarizing the benefit.

Abstract This document provides an overview of the architecture of Transport  <ins> Services, a model for exposing transport protocol features to applications for network communication.  In contrast to what is provided by most existing Application Programming Interfaces (APIs), it is based on an asynchronous, event-driven interaction pattern; it uses messages for representing data transfer to applications; and it assumes an implementation that can use multiple IP addresses, multiple protocols, multiple paths, and provide multiple application streams.  This document further defines the common set of terminology and concepts to be used in definitions of APIs and implementations. </ins> 1.


applications adopt this interface, they will benefit from a wide set of transport features that can evolve over time, and ensure that the system providing the interface can optimize its behavior based on the <del> application requirements and network conditions. </del>  This document is developed in parallel with the specification of the Transport Services API I-D.ietf-taps-interface and Implementation I- <del> D.ietf-taps-impl documents. </del>  1.1.

applications adopt this interface, they will benefit from a wide set of transport features that can evolve over time, and ensure that the system providing the interface can optimize its behavior based on the  <ins> application requirements and network conditions, without requiring a change to the application.  Further, this flexibility does not only enable faster deployment of new feature and protocols, it can also support applications with racing and fallback mechanisms which today usually need to be implemented in each application separately. </ins> This document is developed in parallel with the specification of the Transport Services API I-D.ietf-taps-interface and Implementation I-  <ins> D.ietf-taps-impl documents.  Although following the Transport Services Architecture does of course not mean that all APIs and implementations have to be identical, agreeing on a common minimal set of features and representing them in a similar fashion improves the ability to easily port applications from one system to the another. </ins> 1.1.


3. During pre-establishment the application specifies the Endpoints to <del> 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). </del>  3.1.

Several small updates, mostly to clean things up a bit, and align property names and such.
NAME - 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 can't ask for congestion control after establishment. You can't say that you'd rather have multistreaming support after establishment. But that doesn'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 isn'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!
NAME 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 isn't clear enough (indeed it isn'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.
NAME - 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).
NAME 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?
NAME 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.
NAME we're only discussing whether it's allowed to use them as additional input or not. I agree, some (like the scheduler choice) don'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 wouldn'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 isn't super clear as they don't come with a require/prefer/... etc. qualifier, but then we just offer some freedom to implementers.
NAME 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

3. During pre-establishment the application specifies the Endpoints to  <ins> 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. 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). </ins> 3.1.


3.2. <del> The properties specified during pre-establishment has a close </del>  connection to system policy.  The implementation is responsible for combining and reconciling several different sources of preferences when establishing Connections.  These include, but are not limited to: Application preferences, i.e., preferences specified during the <del> pre-establishment such as Local Endpoint, Remote Endpoint, Path Selection Properties, and Protocol Selection Properties. </del>  Dynamic system policy, i.e., policy compiled from internally and externally acquired information about available network

3.2.  <ins> The properties specified during pre-establishment have a close </ins> connection to system policy.  The implementation is responsible for combining and reconciling several different sources of preferences when establishing Connections.  These include, but are not limited to: Application preferences, i.e., preferences specified during the  <ins> pre-establishment via Selection Properties. </ins> Dynamic system policy, i.e., policy compiled from internally and externally acquired information about available network


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 <del> of the application as specified in the Path Selection Properties and Protocol Selection Properties. </del>  4.1.1.

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  <ins> of the application as specified in the Selection Properties. </ins> 4.1.1.


multiple layers of derivation or resolution, such as DNS service resolution and DNS hostname resolution.  4.3. Implementations should sort the branches of the tree of connection

multiple layers of derivation or resolution, such as DNS service resolution and DNS hostname resolution. <ins> 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. </ins> 4.3. Implementations should sort the branches of the tree of connection


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, <del> including Protocol and Path Selection Properties, which are specified in I-D.ietf-taps-interface. </del>  In addition to the properties provided by the application, an implementation may include additional criteria such as cached performance estimates, see performance-caches, or system policy, see <del> role-of-system-policy, in the ranking.  Two examples of how the Protocol and Path Selection Properties may be used to sort branches are provided below: </del>  <del> 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. </del>  <del> Capacity Profile: An implementation may use the Capacity Profile </del>  to prefer paths optimized for the application's expected traffic pattern according to cached performance estimates, see performance-caches: <del> Interactive/Low Latency: Prefer paths with the lowest expected Round Trip Time Constant Rate: Prefer paths that can satisfy the requested Stream Send or Stream Receive Bitrate, based on observed maximum throughput </del>  <del> Scavenger/Bulk: Prefer paths with the highest expected available bandwidth, based on observed maximum throughput </del>  <del> [Note: See branch-sorting-non-consensus for additional examples related to Properties under discussion.] </del>  Implementations should process properties in the following order: <del> 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 </del>  preferred properties, and finally use avoided properties as a tiebreaker. <del> 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. </del> 4.4. The primary goal of the Candidate Racing process is to successfully

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,  <ins> including Selection Properties, which are specified in I-D.ietf-taps- interface. </ins> In addition to the properties provided by the application, an implementation may include additional criteria such as cached performance estimates, see performance-caches, or system policy, see  <ins> role-of-system-policy, in the ranking.  Two examples of how Selection and Connection Properties may be used to sort branches are provided below: </ins>  <ins> "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. </ins>  <ins> "Capacity Profile": An implementation may use the Capacity Profile </ins> to prefer paths optimized for the application's expected traffic pattern according to cached performance estimates, see performance-caches:  <ins> Scavenger: Prefer paths with the highest expected available bandwidth, based on observed maximum throughput </ins>  <ins> Low Latency/Interactive: Prefer paths with the lowest expected Round Trip Time </ins>  <ins> Constant-Rate Streaming: Prefer paths that can satisfy the requested Stream Send or Stream Receive Bitrate, based on observed maximum throughput </ins> Implementations should process properties in the following order:  <ins> 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 </ins> preferred properties, and finally use avoided properties as a tiebreaker.  4.4. The primary goal of the Candidate Racing process is to successfully


Local Endpoint is specified, the implementation should either use an ephemeral port or generate an error. <del> 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. 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. </del>  4.8.1.

Local Endpoint is specified, the implementation should either use an ephemeral port or generate an error.  <ins> 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. 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. </ins> 4.8.1.


support removing a Message from its buffer, this property may be ignored. <del> 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. </del>  Ordered: when this is false, it disables the requirement of in- order-delivery for protocols that support configurable ordering.

support removing a Message from its buffer, this property may be ignored.  <ins> Priority: this represents the ability to prioritize a Message over 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 Priority on streams of different priority. </ins> Ordered: when this is false, it disables the requirement of in- order-delivery for protocols that support configurable ordering.


as a result of racing multiple transports or as part of TCP Fast Open.  Corruption Protection Length: when this is set to any value other than -1, it limits the required checksum in protocols that allow limiting the checksum length (e.g.  UDP-Lite). <del> 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. 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). [Note: See also send-params-non-consensus for additional Send Parameters under discussion.] </del>  5.1.1.2.

as a result of racing multiple transports or as part of TCP Fast Open. <ins> Final: when this is true, it means that a transport connection can be closed immediately after its transmission. </ins> Corruption Protection Length: when this is set to any value other than -1, it limits the required checksum in protocols that allow limiting the checksum length (e.g.  UDP-Lite).  <ins> 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). 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). </ins> 5.1.1.2.


6.1. <del> Appendix A.1 of I-D.ietf-taps-minset explains, using primitives that are described in RFC8303 and RFC8304, how to implement changing the following protocol properties of an established connection with TCP and UDP.  Below, we amend this description for other protocols (if applicable): </del>  <del> Relative niceness: for SCTP, this can be done using the primitive CONFIGURE_STREAM_SCHEDULER.SCTP described in section 4 of RFC8303. Timeout for aborting Connection: for SCTP, this can be done using the primitive CHANGE_TIMEOUT.SCTP described in section 4 of RFC8303. 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. </del>  Retransmission threshold before excessive retransmission <del> notification: for TCP, this can be done using ERROR.TCP described in section 4 of RFC8303. </del>  Required minimum coverage of the checksum for receiving: for UDP- Lite, this can be done using the primitive SET_MIN_CHECKSUM_COVERAGE.UDP-Lite described in section 4 of RFC8303.  Connection group transmission scheduler: for SCTP, this can be done using the primitive SET_STREAM_SCHEDULER.SCTP described in section 4 of RFC8303.  It may happen that the application attempts to set a Protocol Property which does not apply to the actually chosen protocol.  In this case, the implementation should fail gracefully, i.e., it may

6.1.  <ins> 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. </ins>  <ins> Notification of excessive retransmissions: TODO </ins> Retransmission threshold before excessive retransmission  <ins> notification: TODO; for TCP, this can be done using ERROR.TCP described in section 4 of RFC8303. Notification of ICMP soft error message arrival: TODO </ins> Required minimum coverage of the checksum for receiving: for UDP- Lite, this can be done using the primitive SET_MIN_CHECKSUM_COVERAGE.UDP-Lite described in section 4 of RFC8303. <ins> Priority (Connection): TODO; for SCTP, this can be done using the primitive CONFIGURE_STREAM_SCHEDULER.SCTP described in section 4 of RFC8303. Timeout for aborting Connection: for SCTP, this can be done using the primitive CHANGE_TIMEOUT.SCTP described in section 4 of RFC8303. </ins> Connection group transmission scheduler: for SCTP, this can be done using the primitive SET_STREAM_SCHEDULER.SCTP described in section 4 of RFC8303. <ins> Maximum message size concurrent with Connection establishment: TODO Maximum Message size before fragmentation or segmentation: TODO Maximum Message size on send: TODO Maximum Message size on receive: TODO Capacity Profile: TODO Bounds on Send or Receive Rate: TODO TCP-specific Property: User Timeout: for TCP, this can be configured using the primitive CHANGE_TIMEOUT.TCP described in section 4 of RFC8303. </ins> It may happen that the application attempts to set a Protocol Property which does not apply to the actually chosen protocol.  In this case, the implementation should fail gracefully, i.e., it may


If the Protocol Stack includes a transport protocol that supports multipath connectivity, an update to the available paths should inform the Protocol Instance of the new set of paths that are <del> permissible based on the Path Selection Properties passed by the </del>  application.  A multipath protocol can establish new subflows over new paths, and should tear down subflows over paths that are no longer available.  If the Protocol Stack includes a transport

If the Protocol Stack includes a transport protocol that supports multipath connectivity, an update to the available paths should inform the Protocol Instance of the new set of paths that are  <ins> permissible based on the Selection Properties passed by the </ins> application.  A multipath protocol can establish new subflows over new paths, and should tear down subflows over paths that are no longer available.  If the Protocol Stack includes a transport


Many application programming interfaces (APIs) to perform transport networking have been deployed, perhaps the most widely known and <del> imitated being the BSD socket() POSIX interface.  The naming of objects and functions across these APIs is not consistent, and varies </del>  depending on the protocol being used.  For example, sending and receiving streams of data is conceptually the same for both an unencrypted Transmission Control Protocol (TCP) stream and operating on an encrypted Transport Layer Security (TLS) RFC8446 stream over <del> TCP, but applications cannot use the same socket send() and recv() calls on top of both kinds of connections.  Similarly, terminology for the implementation of transport protocols varies based on the context of the protocols themselves: terms such as "flow", "stream", "message", and "connection" can take on many different meanings. This variety can lead to confusion when trying to understand the similarities and differences between protocols, and how applications can use them effectively. </del>  The goal of the Transport Services architecture is to provide a common, flexible, and reusable interface for transport protocols.  As

Closed
I just read Arch and have the following NiTs which I think we should address: /Listeners by default register with multiple paths/ ought this to be: /Listeners, by default, register with multiple paths/ /A Framer is a data translation layer that can be added to a Connection to define how application-level Messages are transmitted over a transport protocol. / I think this should be (because I don’t think they are protocol specific) /A Framer is a data translation layer that can be added to a Connection to define how application-level Messages are transmitted over the transport service. / /to retransmit in the event of packet loss,/ better to avoid event here :-) /to retransmit when there is packet loss,/
I am just gonna add a few more nits here: The Listener object in figure 4 is a bit awkward, it appears as if the Listen() call appears out of thin air while per the API it gets called on the preconnection object like Initiate() and Rendezvous(). In section 4.1.1, there are 5 references to section 4.1.2, is it really necessary to have that many? Point 2 in section 4.2.3 only talks about required transport services, the same should probably be said about prohibited services, i.e. "both protocol stacks MUST NOT offer transport services prohibited by the application"
Let me add to this: Section 1: print send() and recv() in fixed-with font [HTML/XML issue only] Section 2 - Figure 1: socket() [with the brackets] looks odd in the figure title
NAME I fear framers may be specific to the underlaying protocol, e.g., for SIP slicing messages out of TCP stream whereby doing nothing for SCTP and UDP
In relation to frames I think I only asked to add /service/ instead of protocol... I don't understand how Phil's comment reacts to that
NAME I think protocol is correct here and would not change the sentence.
OK - so I think you are saying the framer depends only on the specific next protocol, rather than upon the transport service that was offered? - It is still not clear to me that this is correct.
NAME that is a fairly good question… The behaviour of the framer defiantly depends on the transport service provided (which may be a subset or superset of the transport service requested). A framer needs to support all possible outcomes of the transport services requested It may optimize based on the protocols it actually finds, e.g., turn into a no-op with the transport preserves message boundaries. Whether the next protocol is a sufficient representation of this is unclear to me. Maybe not, if one thinks of supporting arbitrarily large messages and UDP over IPv6 with and without fragmentation…
LGTM, thanks!

Many application programming interfaces (APIs) to perform transport networking have been deployed, perhaps the most widely known and  <ins> imitated being the BSD Socket POSIX interface.  The naming of objects and functions across these APIs is not consistent, and varies </ins> depending on the protocol being used.  For example, sending and receiving streams of data is conceptually the same for both an unencrypted Transmission Control Protocol (TCP) stream and operating on an encrypted Transport Layer Security (TLS) RFC8446 stream over  <ins> TCP, but applications cannot use the same socket "send()" and "recv()" calls on top of both kinds of connections.  Similarly, terminology for the implementation of transport protocols varies based on the context of the protocols themselves: terms such as "flow", "stream", "message", and "connection" can take on many different meanings.  This variety can lead to confusion when trying to understand the similarities and differences between protocols, and how applications can use them effectively. </ins> The goal of the Transport Services architecture is to provide a common, flexible, and reusable interface for transport protocols.  As


The traditional model of using sockets for networking can be represented as follows: <del> Applications create connections and transfer data using the socket </del>  API. <del> The socket API provides the interface to the implementations of </del>  TCP and UDP (typically implemented in the system's kernel). TCP and UDP in the kernel send and receive data over the available

The traditional model of using sockets for networking can be represented as follows:  <ins> Applications create connections and transfer data using the Socket </ins> API.  <ins> The Socket API provides the interface to the implementations of </ins> TCP and UDP (typically implemented in the system's kernel). TCP and UDP in the kernel send and receive data over the available


that care about timing; the ability to provide control of reliability, choosing which <del> messages to retransmit in the event of packet loss, and how best to make use of the data that arrived; </del>  the ability to manage dependencies between messages, when the transport system could decide to not deliver a message, either

that care about timing; the ability to provide control of reliability, choosing which  <ins> messages to retransmit when there is packet loss, and how best to make use of the data that arrived; </ins> the ability to manage dependencies between messages, when the transport system could decide to not deliver a message, either


its own, but needs a framing protocol on top to determine message boundaries. <del> Both stacks MUST offer the transport services that are required by the application.  For example, if an application specifies that it requires reliable transmission of data, then a Protocol Stack </del>  using UDP without any reliability layer on top would not be allowed to replace a Protocol Stack using TCP.  However, if the application does not require reliability, then a Protocol Stack

its own, but needs a framing protocol on top to determine message boundaries.  <ins> Both stacks MUST offer the transport services that are requested by the application.  For example, if an application specifies that it requires reliable transmission of data, then a Protocol Stack </ins> using UDP without any reliability layer on top would not be allowed to replace a Protocol Stack using TCP.  However, if the application does not require reliability, then a Protocol Stack