specific PvD instances or interface instances, and should be preferred over these options.  5.3. Most security parameters, e.g., TLS ciphersuites, local identity and a per-Message basis using the Transmission Profile Message Property; see send-profile.  9.2. Asynchronous introspection is also possible, via the SoftError Event.

This does the following things with the properties from the appendix, based on URL direction of communication: moved to the main text "Suggest a timeout to the Remote Endpoint": moved to the main text but explicitly described as a TCP-specific property; also changed it to contain all the parameters that UTO really has traffic category: removed. Mirja said "Let's see if there's anything in the implementation document that actually needs this information" but I figured that chances are low, and if this really happens we can still re-introduce this later. size to be sent or received: removed duration: removed send or receive bit-rate: changed this to specify an upper and/or lower bound cost preferences: kept in the appendix, but inserted mirja's comment "Not convinced cost preferences are on the right level." (NAME what did you mean with "on the right level"?)
Cost doesn't seem to mean too much for the transport layer. I guess it could e.g. make more sense to specified which link technology you prefer (e.g. wifi over cellular) (which would be on a less abstract level). However, still not sure what the right level is...
I'm not so keen on specifying link technology - a transport only knows the local link - and that can be very different to the technology of the path bottleneck. Maybe cost isn't that bad - sometimes the presence of cost IS known, or at least a decision could try to be made to minimise cost. It's hard to do more than hint at this.
Thinking about cost prefernce a bit further and with respect to NAME comment that this could part of an layer on top of taps, I would prefer to not include it expect we have some concrete implementation example guidance in the implementation draft.
NAME that all sounds very reasonable to me, thanks for clarifying! So it seems fit where the cost preferences are now in this PR - I left them in the appendix for now, with a mark saying that we'll see if there will suitable text in the implementation draft.
Thanks for doing this! I have just two suggestions about what section to place the properties in. About the Cost Preferences discussion, I think having both this and the less abstract interface preference in there makes sense, and then the implementation can map those properties to each other. The alternative would be to make this part of the "layer on top of the TAPS API", which some of the other Intents would end up on as well. If we do this, I think it might make sense to keep the other Intents in the appendix for now (instead of deleting them like this PR does).lgtm!

specific PvD instances or interface instances, and should be preferred over these options. <ins> 5.2.10. 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 unidirectional connections are not supported by the transport protocol, the system should fall back to bidirectional transport. </ins> 5.3. Most security parameters, e.g., TLS ciphersuites, local identity and a per-Message basis using the Transmission Profile Message Property; see send-profile. <ins> 9.1.13. This property specifies an upper-bound rate that a transfer is not expected to exceed (even if flow control and congestion control allow higher rates), and/or a lower-bound rate below which the application does not deem a data transfer useful.  It is given in bits per second. 9.1.14. This property specifies, for the case TCP becomes the chosen transport protocol: a time value to be advertised via the User Timeout Option (UTO) for the TCP at the remote endpoint to adapt its own "Timeout for aborting Connection" (see {#conn-timeout}) value accordingly a boolean (default false) to control whether the UTO option is enabled for a connection.  This applies to both sending and receiving. a boolean (default true) which controls whether the "Timeout for aborting Connection" (see {#conn-timeout}) may be changed based on a UTO option received from the remote peer.  This boolean becomes false when "Timeout for aborting Connection" (see {#conn-timeout}) is used. All of the above parameters are optional (e.g., it is possible to specify "User Timeout Enabled" as true, but not specify an Advertised User Timeout value; in this case, the TCP default will be used). </ins> 9.2. Asynchronous introspection is also possible, via the SoftError Event.


that an application can pass to describe its intent, requirements, prohibitions, and preferences for its networking operations.  For any system that provides generic Transport Services, these <del> properties SHOULD be defined to apply to multiple transport protocols.  Some properties are specific to a single transport protocol, and these are be exposed as non-generic interfaces (see Specific Protocol Properties preestablishment).  Properties can have a large impact on the rest of the aspects of the interface: they modify how establishment occurs, they influence the expectations around data transfer, and they determine the set of events that will be supported. </del>  Establishment (establishment) focuses on the actions that an application takes on the basic objects to prepare for data transmission is stopped, and state is torn down in the transport. The diagram below provides a high-level view of the actions taken <del> during the lifetime of a connection. </del>  4.1.1. potential connection.  It has state that describes parameters of a Connection that might exist in the future: the Local Endpoint from which that Connection will be established, the Remote Endpoint <del> (preestablishment) to which it will connect, and Path Selection Properties, Protocol Selection Properties, and Specific Protocol Properties that influence the choice of transport that a </del>  Connection will use.  A Preconnection can be fully specified and represent a single possible Connection, or it can be partially specified such that it represents a family of possible Connection objects.  It is created from a Preconnection object that specifies the type of incoming connections it will accept.  4.1.2. Endpoint: An Endpoint represents an identifier for one side of a identifier for itself that it uses for transport connections.  For example, a local IP address and port. <del> Path Selection Properties: The Path Selection Properties consist of the options that an application can set to influence the selection of paths between the local and remote systems.  These options can take the form of requirements, prohibitions, or preferences.  Examples of options that influence path selection include the interface type (such as a Wi-Fi Ethernet connection, or a Cellular LTE connection), characteristics of the path that are locally known like the Maximum Transmission Unit (MTU) or discovered like the Path MTU (PMTU), or predicted based on cached information like expected throughput or latency. Protocol Selection Properties: The Protocol Selection Properties consist of the options that an application can set to influence the selection of transport protocol, or to configure the behavior of generic transport protocol features.  These options can take the form of requirements, prohibitions, and preferences.  Examples include reliability, service class, multipath support, and fast open support. Specific Protocol Properties: The Specific Protocol Properties refer to the subset of Protocol Properties options that apply to a single protocol (transport protocol, IP, or security protocol). The presence of such Properties does not require that a specific protocol will be used when a Connection is established, but that if this protocol is employed, a particular set of options is to be used. </del>  4.1.3. multiple transport sub-flows). Candidate Path: One path that is available to an application and <del> conforms to the Path Selection Properties and System Policy. Candidate Paths are identified during the gathering phase (gathering) and can be used during the racing phase (racing). </del>  Candidate Protocol Stack: One protocol stack that can be used by an application for a connection, of which there can be several. 4.2.1. Path Selection: Path Selection represents the act of choosing one <del> or more paths that are available to use based on the Path Selection Properties provided by the application, the policies and </del>  heuristics of a Transport Services system. Protocol Selection: Protocol Selection represents the act of choosing one or more sets of protocol options that are available <del> to use based on the Protocol Properties provided by the </del>  application, and a Transport Services system's policies and heuristics.

fixes Properties Terminology and aligns them to the API adds Properties as "Basic Object" updates Figure 2
NAME comments should be addressed now. Thanks for the reviews
Reviewing the arch doc right now which talkes about path and protocol selection properties, however, the API doc now has transport properties, connection properties, and message properties... I think we need to realign the terms here....
I admit to being slightly lost now with the naming and re-organization process... so maybe this is a left-over thing that should no longer exist... but: the API draft says "Collectively, Selection, Connection, and Message Properties can be referred to as Transport Properties." Unless I'm mistaken, this is what's needed: API draft: it seems strange how the list of selection properties (from 5.2.1 onward) appears out of nowhere. There should be a new heading, 5.3, just before what is now 5.2.1, called "Selection properties"Arch draft: with some exceptions that should perhaps be removed, the API draft doesn't really distinguish between "path" and "protocol" selection properties. Can we remove this distinction from the arch draft? Because of the availability of a protocol with certain abilities, a transport system might also make a decision about a certain path, and a path selection property might lead to a decision for a path that rules out a certain protocol... so this distinction seems to me to be a bit artificial anyway.
We converged on classifying properties into Selection, Connection, and Message Properties. If that is still true, then the architecture draft should refer to these classes of properties as well. I agree that there isn't necessarily a clear distinction between Path and Protocol Selection Properties, so we can merge them into a single class in the architecture document and just state that these properties can influence both path and protocol selection. About Transport Properties as a generic term to refer to all properties, I don't recall an extensive discussion on this, but I think it's alright (and makes more sense than what is in the API doc now, which basically uses Transport Properties as a synonym for Selection Properties).
I completely agree with NAME – don't re-iterate the whole discussion, please. We definitely need to make sure properties are consistent across all drafts. That primarily requires changes to Section 4.1.2. What I definitely would like to see is a short Section in the Architecture explaining what Properties are and that they are our tool to expose "knobs" of the transport. I am willing to volunteer for this, but It may take until next week.
closed by 5b173e2
Thanks for doing this - and thanks NAME for the close look you're taking

that an application can pass to describe its intent, requirements, prohibitions, and preferences for its networking operations.  For any system that provides generic Transport Services, these  <ins> Selection Properties SHOULD be defined to apply to multiple transport protocols.  Selection Properties can have a large impact on the rest of the aspects of the interface: they modify how establishment occurs, they influence the expectations around data transfer, and they determine the set of events that will be supported. </ins> Establishment (establishment) focuses on the actions that an application takes on the basic objects to prepare for data transmission is stopped, and state is torn down in the transport. The diagram below provides a high-level view of the actions taken  <ins> during the lifetime of a connection.  Note that some actions are alternatives (e.g., whether to initiate a connection or to listen for incoming connections), others are optional (e.g., setting Connection and Message Properties in Pre-Establishment), or have been omitted for brevity. </ins> 4.1.1. potential connection.  It has state that describes parameters of a Connection that might exist in the future: the Local Endpoint from which that Connection will be established, the Remote Endpoint  <ins> (preestablishment) to which it will connect, and Selection Properties, that influence the choice of transport that a </ins> Connection will use.  A Preconnection can be fully specified and represent a single possible Connection, or it can be partially specified such that it represents a family of possible Connection objects.  It is created from a Preconnection object that specifies the type of incoming connections it will accept. <ins> Transport Properties: Transport Properties allow the application to configure the Transport System and express their requirements, prohibitions, and preferences.  There are three kinds of Transport Properties: Selection Properties are used influence connection establishment. Connection Properties are used to configure the protocol instance and control per-connection behavior of the Transport System. Message Properties are used to configure per-message control per-connection behavior of the Transport System. Connection and Message Properties can also be specified prior establishment.  If done so, they are used as a default and MAY be used as an input to path selection and protocol selection.  Some Transport Properties only apply to a single protocol (transport protocol, IP, or security protocol).  The presence of such Transport Properties does not require that a specific protocol will be used when a Connection is established, but that if this protocol is employed, a particular set of options is to be used. </ins> 4.1.2. Endpoint: An Endpoint represents an identifier for one side of a identifier for itself that it uses for transport connections.  For example, a local IP address and port.  <ins> Selection Properties: The Selection Properties consist of the options that an application can set to influence the selection of paths between the local and remote systems, to influence the selection of transport protocol, or to configure the behavior of generic transport protocol features.  These options can take the form of requirements, prohibitions, or preferences.  Examples of options that influence path selection include the interface type (such as a Wi-Fi Ethernet connection, or a Cellular LTE connection), characteristics of the path that are locally known like the Maximum Transmission Unit (MTU) or discovered like the Path MTU (PMTU), or predicted based on cached information like expected throughput or latency.  Examples of options that influence protocol selection and configuration of transport protocol features include reliability, service class, multipath support, and fast open support. </ins> 4.1.3. multiple transport sub-flows). Candidate Path: One path that is available to an application and  <ins> conforms to the Selection Properties and System Policy.  Candidate Paths are identified during the gathering phase (gathering) and can be used during the racing phase (racing). </ins> Candidate Protocol Stack: One protocol stack that can be used by an application for a connection, of which there can be several. 4.2.1. Path Selection: Path Selection represents the act of choosing one  <ins> or more paths that are available to use based on the Selection Properties provided by the application, the policies and </ins> heuristics of a Transport Services system. Protocol Selection: Protocol Selection represents the act of choosing one or more sets of protocol options that are available  <ins> to use based on the Transport Properties provided by the </ins> application, and a Transport Services system's policies and heuristics.


5.2.12.  This property specifies how long to wait before aborting a Connection during establishment. 9.1.1. <del> 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 recommended default is to have this option. 9.1.2. </del> Integer This property specifies after how many retransmissions to inform the application about "Excessive Retransmissions". <del> 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 recommended default is not to have this option. 9.1.4. </del>  Integer that no checksum is required, and a special value (e.g., -1) indicates full checksum coverage. <del> 9.1.5. </del>  Integer of a Connection Group.  As noted in groups, this property is not entangled when Connections are cloned. <del> 9.1.6. </del>  This property specifies how long to wait before deciding that a Connection has failed after establishment. <del> 9.1.7. </del>  Enum Connections within a Connection Group, see groups.  The set of schedulers can be taken from I-D.ietf-tsvwg-sctp-ndata. <del> 9.1.8. </del>  Integer (read only) before or during Connection establishment, see also msg-idempotent. It is given in Bytes. <del> 9.1.9. </del>  Integer (read only) that can be sent without incurring network-layer fragmentation or transport layer segmentation at the sender. <del> 9.1.10. </del>  Integer (read only) This property represents the maximum Message size that can be sent. <del> 9.1.11. </del>  Integer (read only) This numeric property represents the maximum Message size that can be received. <del> 9.1.12. </del>  This property specifies the desired network treatment for traffic sent by the application and the tradeoffs the application is prepared a per-Message basis using the Transmission Profile Message Property; see send-profile. <del> 9.1.13. </del>  This property specifies an upper-bound rate that a transfer is not expected to exceed (even if flow control and congestion control allow does not deem a data transfer useful.  It is given in bits per second. <del> 9.1.14. </del>  This property specifies, for the case TCP becomes the chosen transport protocol: 9.2. Asynchronous introspection is also possible, via the SoftError Event. <del> This event informing the application about the receipt of an ICMP error message related to the Connection.  This will only happen if the underlying protocol stack supports access to soft errors; however, even if the underlying stack supports it, there is no guarantee that a soft error will be signaled. </del>  10.

This and addresses a comment about soft errors by NAME in : "Notification of Excessive Retransmission" is made a Selection Property There's now an "Excessive Retransmission" Event (just like the one for Soft Errors) The preference to receive Soft Errors is also made a Selection Property
Oops sorry, will fix
NAME - the latter was exactly my thinking. if someone doesn’t want these notifications they can just ignore them.
I think we should not standardise this. I also don't think that IETF transports typically provide this control, nor do I think this is really useful to have. So I'd argue the API should be silent about these three things!
I agree with Gorry that you can probably remove them. If anything I would see it as a Connection properties, not as Selection properties. How likely is it that you will have two transport stacks to select from where one supports soft errors the other not and this is what you will want to use to make a decision? Does not seem like a strong use case.
To Gorry's point, how widely do we expect these to be supported for various protocols? And is the meaning of excessive retransmits consistent across protocols that do retransmission (TCP, SCTP, QUIC)?
I certainly agree that it seems unlikely that someone will want to insist on a transport that offers "Notification of Excessive Retransmission". Removing this selection property is fine by me. Regarding soft errors, I could agree but I'm less sure - so just to double check, are we really all sure we don't want to offer this kind of control? What if applications really want to be able to receive ICMP messages, e.g. to insist on doing their own PMTUD? NAME mentions that, if anything, they should be Connection Properties: I agree with that; they were both Connection Properties before, but with unfitting wording (fixing this was a part of this split). I think they should both be described as events, like we already have it for soft errors only: https://taps-URL We shouldn't remove them altogether: if we did, this would AFAIK be our only divergence from minset. To answer NAME question, I dont know what most implementations do about these two things - but here's a spec backtrace that talks about TCP and UDP (for other protocols, "do nothing" is a safe choice here I guess): About "Notification of Excessive Retransmission", minset's Appendix A.1 says: o Notification of Excessive Retransmissions (early warning below abortion threshold) Protocols: TCP Optimizing because it is an early warning to the application, informing it of an impending functional event. Implementation: via ERROR.TCP. Implementation over UDP: do nothing (there is no abortion threshold). RFC 8303, section 4.1 ("pass 2"), says about ERROR.TCP: "The reported conditions include at least: ICMP error message arrived and excessive retransmissions." For the soft errors bit, minset also points at ERROR.UDP(-Lite), which, in RFC 8303, is described to just return soft errors, nothing else. For both protocols, the text points back at "errorreport" from pass 1, which in TCP's case points back at section 4.2.4.1 in RFC 1122: URL The text also refers to RFC 5461 which may provide more information regarding NAME question. For soft errors from UDP, we need to look at "errorreport" in RFC 8304, which quotes section 4.1.4 or RFC1122 to say: "UDP MUST pass to the application layer all ICMP error messages that it receives from the IP layer." and goes on to explain that this is necessary to implement ICMP-based PMTUD.
As discussed in
Looks good to me. I think there was the idea to have an additional Connection Property, which allows to turn the soft errors on or off on an existing Connection. Do we want to standardize this additional Connection Property as well, or is this too much and we leave it up to the implementation whether such a thing exists? I tend towards the latter, as I consider this just a convenience function.

5.2.12. <ins> This property specifies whether an application considers it useful to be informed in case sent data was retransmitted more often than a certain threshold.  The recommended default is to have this option. 5.2.13. 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.  The recommended default is not to have this option. 5.2.14. </ins> This property specifies how long to wait before aborting a Connection during establishment. 9.1.1.  Integer This property specifies after how many retransmissions to inform the application about "Excessive Retransmissions".  <ins> 9.1.2. </ins> Integer that no checksum is required, and a special value (e.g., -1) indicates full checksum coverage.  <ins> 9.1.3. </ins> Integer of a Connection Group.  As noted in groups, this property is not entangled when Connections are cloned.  <ins> 9.1.4. </ins> This property specifies how long to wait before deciding that a Connection has failed after establishment.  <ins> 9.1.5. </ins> Enum Connections within a Connection Group, see groups.  The set of schedulers can be taken from I-D.ietf-tsvwg-sctp-ndata.  <ins> 9.1.6. </ins> Integer (read only) before or during Connection establishment, see also msg-idempotent. It is given in Bytes.  <ins> 9.1.7. </ins> Integer (read only) that can be sent without incurring network-layer fragmentation or transport layer segmentation at the sender.  <ins> 9.1.8. </ins> Integer (read only) This property represents the maximum Message size that can be sent.  <ins> 9.1.9. </ins> Integer (read only) This numeric property represents the maximum Message size that can be received.  <ins> 9.1.10. </ins> This property specifies the desired network treatment for traffic sent by the application and the tradeoffs the application is prepared a per-Message basis using the Transmission Profile Message Property; see send-profile.  <ins> 9.1.11. </ins> This property specifies an upper-bound rate that a transfer is not expected to exceed (even if flow control and congestion control allow does not deem a data transfer useful.  It is given in bits per second.  <ins> 9.1.12. </ins> This property specifies, for the case TCP becomes the chosen transport protocol: 9.2. Asynchronous introspection is also possible, via the SoftError Event.  <ins> This event informs the application about the receipt of an ICMP error message related to the Connection.  This will only happen if the underlying protocol stack supports access to soft errors; however, even if the underlying stack supports it, there is no guarantee that a soft error will be signaled. 9.3. This event notifies the application of excessive retransmissions, based on a configured threshold (see conn-excss-retransmit).  This will only happen if the underlying protocol stack supports reliability and, with it, such notifications. </ins> 10.


Connection Properties: The Connection Properties are used to configure protocol-specific options and control per-connection behavior of the Transport System.  For example, a protocol- <del> specific property on the connection can express that if UDP is used, the implementation ought to use checksums.  Note that the presence of such a property does not require that a specific protocol will be used.  In general, these properties do not explicitly determine the selection of paths or protocols, but MAY be used in this way by an implementation during connection establishment. </del>  4.1.3.

As discussed at the January interim last week
This definition is exactly right, IMO.Exactly right.

Connection Properties: The Connection Properties are used to configure protocol-specific options and control per-connection behavior of the Transport System.  For example, a protocol-  <ins> specific Connection Property can express that if UDP is used, the implementation ought to use checksums.  Note that the presence of such a property does not require that a specific protocol will be used.  In general, these properties do not explicitly determine the selection of paths or protocols, but MAY be used in this way by an implementation during connection establishment.  Connection Properties SHOULD be specified on a Preconnection prior to Connection establishment, but MAY be modified later.  Changes made to Connection Properties after establishment take effect on a best-effort basis. </ins> 4.1.3.


create a new stream on the given Connection, then attempts to clone a connection will result in a CloneError: <del> The Protocol Property "Niceness" operates on entangled Connections as in msg-niceness: when allocating available network capacity among </del>  Connections in a Connection Group, sends on Connections with higher <del> Niceness values will be prioritized over sends on Connections with lower Niceness values.  An ideal transport system implementation </del>  would assign each Connection the capacity share (M-N) x C / M, where <del> N is the Connection's Niceness value, M is the maximum Niceness value </del>  used by all Connections in the group and C is the total available <del> capacity.  However, the Niceness setting is purely advisory, and no </del>  guarantees are given about the way capacity is shared.  Each implementation is free to implement a way to share capacity that it sees fit. Integer (non-negative) <del> This property represents an unbounded hierarchy of priorities.  It can specify the priority of a Message, relative to other Messages sent over the same Connection. </del>  <del> A Message with Niceness 0 will yield to a Message with Niceness 1, which will yield to a Message with Niceness 2, and so on.  Niceness </del>  may be used as a sender-side scheduling construct only, or be used to specify priorities on the wire for Protocol Stacks supporting prioritization. Note that this property is not a per-message override of the <del> connection Niceness - see conn-niceness.  Both Niceness properties </del>  may interact, but can be used independently and be realized by different mechanisms. this property. Note that a Final Message must always be sorted to the end of a list <del> of Messages.  The Final property overrides Niceness and any other </del>  property that would re-order Messages.  If another Message is sent after a Message marked as Final has already been sent on a Connection, the Send Action for the new Message will cause a 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. and UDP.  Below, we amend this description for other protocols (if applicable): <del> Relative niceness: for SCTP, this can be done using the primitive CONFIGURE_STREAM_SCHEDULER.SCTP described in section 4 of RFC8303. </del>  Timeout for aborting Connection: for SCTP, this can be done using the primitive CHANGE_TIMEOUT.SCTP described in section 4 of

Not many text fixes needed - quite a bit of text reflected the old choice of Priority anyway and wasn't correctly updated for Niceness :-)
At 8.1.2 you say lower values have higher priorities for connPrio. But later, at msgPrio, higher values have higher priority, and in the examples where you speak of the interaction of connPrio and msgPrio, you imply that higher means higher for both properties. Please check for consistency and clarify.
Lower values having higher priorities for connPrio is a remnant that we must have missed when we flipped this, e.g. PR which I don't know... too many iterations have mangled the text.
Aha, now I see what happened: following some more PRs, also , in PR , NAME re-introduced some text saying that sends on Connections with lower-priority values will be prioritized over sends on Connections with a higher-priority value. This reverses the logic for some part of the text - I suspect that NAME (very understandably!) forgot what happened and this created this mix. We have been editing these documents for way too long!
Fine with me. The max_prio problem can be addressed separately.

create a new stream on the given Connection, then attempts to clone a connection will result in a CloneError:  <ins> The Protocol Property "Priority" operates on entangled Connections as in msg-priority: when allocating available network capacity among </ins> Connections in a Connection Group, sends on Connections with higher  <ins> Priority values will be prioritized over sends on Connections with lower Priority values.  An ideal transport system implementation </ins> would assign each Connection the capacity share (M-N) x C / M, where  <ins> N is the Connection's Priority value, M is the maximum Priority value </ins> used by all Connections in the group and C is the total available  <ins> capacity.  However, the Priority setting is purely advisory, and no </ins> guarantees are given about the way capacity is shared.  Each implementation is free to implement a way to share capacity that it sees fit. Integer (non-negative)  <ins> This property represents a hierarchy of priorities.  It can specify the priority of a Message, relative to other Messages sent over the same Connection. </ins>  <ins> A Message with Priority 0 will yield to a Message with Priority 1, which will yield to a Message with Priority 2, and so on.  Priorities </ins> may be used as a sender-side scheduling construct only, or be used to specify priorities on the wire for Protocol Stacks supporting prioritization. Note that this property is not a per-message override of the  <ins> connection Priority - see conn-priority.  Both Priority properties </ins> may interact, but can be used independently and be realized by different mechanisms. this property. Note that a Final Message must always be sorted to the end of a list  <ins> of Messages.  The Final property overrides Priority and any other </ins> property that would re-order Messages.  If another Message is sent after a Message marked as Final has already been sent on a Connection, the Send Action for the new Message will cause a 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. and UDP.  Below, we amend this description for other protocols (if applicable):  <ins> Priority (Connection): for SCTP, this can be done using the primitive CONFIGURE_STREAM_SCHEDULER.SCTP described in section 4 of RFC8303. </ins> Timeout for aborting Connection: for SCTP, this can be done using the primitive CHANGE_TIMEOUT.SCTP described in section 4 of


An Object sends an Event: An Action takes a set of Parameters; an Event contains a set of <del> Parameters: </del>  Actions associated with no Object are Actions on the abstract interface itself; they are equivalent to Actions on a per-application Messages for streaming large data is also supported (see send- partial).  7.1. The most basic form of sending on a connection involves enqueuing a For application-layer protocols where the Connection initiator also sends the first message, the InitiateWithSend() action combines <del> Connection initiation with a first Message sent. Without a message context (as in send-basic): With a message context (as in message-props): </del>  Whenever possible, a messageContext should be provided to declare the message passed to InitiateWithSend as idempotent.  This allows the

Even though all the languages we want to support don't have convenient syntax for optional parameters to functions/methods, it would be nice to note that we intend for some parameters to not be mandatory on every call.
Looks good! This approach certainly clarifies things.LGTM except for the paragraph that I commented on; I'd just delete that.Fine withe mit (with some minor knit)

An Object sends an Event: An Action takes a set of Parameters; an Event contains a set of  <ins> Parameters.  Action parameters whose names are suffixed with a question mark are optional. </ins> Actions associated with no Object are Actions on the abstract interface itself; they are equivalent to Actions on a per-application Messages for streaming large data is also supported (see send- partial). <ins> Messages are sent on a Connection using the Send action: where messageData is the data object to send.  The optional messageContext parameter supports per-message properties and is described in message-props.  The optional endOfMessage parameter supports partial sending and is described in send-partial. </ins> 7.1. The most basic form of sending on a connection involves enqueuing a For application-layer protocols where the Connection initiator also sends the first message, the InitiateWithSend() action combines  <ins> Connection initiation with a first Message sent: </ins> Whenever possible, a messageContext should be provided to declare the message passed to InitiateWithSend as idempotent.  This allows the


4.1.  Each application using the Transport Services Interface declares its preferences for how the transport service should operate using properties at each stage of the lifetime of a connection.  During Prefer, Require) for the level of preference of a given property during protocol selection; see selection-props. <del> 4.2. </del>  This document defines a language- and platform-independent interface to a Transport Services system.  Given the wide variety of languages

This PR provides usage examples of our abstract interface, to address . The examples show how an application might use Listen(), Initiate(), and Rendezvous(), send a Message, and receive a Message. There is some redundancy between these examples, and I introduces some subtle differences to make them plausible, e.g., the "server" provides its identity, and the "client" verifies the other endpoint's identity using a trust callback. Overall the section became rather long. Should we instead just stick to one example, e.g., Initiate()? (Or Rendezvous() because it covers the most aspects? Or Initiate() but with all the aspects from Rendezvous()?) Otherwise I'm particularly interested in feedback on the Rendezvous() example -- I think it's correct wrt the draft, but is there a "more plausible" port number, and should anything else be set there that is not in the Initiate() and Listen() examples?
Thanks for the review, I addressed the comments. Maybe the default for Preserve Message Boundaries should be Require as well, if we receive only complete Messages by default...
I'm good with these changes. Regarding how we show the pseudo-code, I'm not totally sure about the notation (how rigorous are we on that?), so someone else should validate it makes sense.
Similar to the way we added simple diagrams to the architecture document to make the "story" of the document more compelling, we should begin the interface document with a simple workflow for an example connection. This way, we can show concretely up front how this is simple and useful, while being quite flexible and powerful. This can also inform how we then continue to explain depth to the details.
I'm going to prepare a PR this week.
This looks good, modulo a couple of comments in the review (introduce API example notation, decide on formatting for property names). In the interests of getting this into the draft rev for Prague, though, I don't think we should block merging on these, and can clean them up in/after Prague.

4.1. <ins> The following usage examples illustrate how an application might use a Transport Services Interface to: Act as a server, by listening for incoming connections, receiving requests, and sending responses, see server-example. Act as a client, by connecting to a remote endpoint using Initiate, sending requests, and receiving responses, see client- example. Act as a peer, by connecting to a remote endpoint using Rendezvous while simultaneously waiting for incoming Connections, sending Messages, and receiving Messages, see peer-example. The examples in this section presume that a transport protocol is available between the endpoints which provides Reliable Data Transfer, Preservation of data ordering, and Preservation of Message Boundaries.  In this case, the application can choose to receive only complete messages. If none of the available transport protocols provides Preservation of Message Boundaries, but there is a transport protocol which provides a reliable ordered octet stream, an application may receive this octet stream as partial Messages and transform it into application- layer Messages.  Alternatively, an application may provide a Deframer, which is a function that transforms an octet stream into a sequence of Messages, see receive-framing. 4.1.1. This is an example of how an application might listen for incoming Connections using the Transport Services Interface, receive a request, and send a response. 4.1.2. This is an example of how an application might connect to a remote application using the Transport Services Interface, send a request, and receive a response. 4.1.3. This is an example of how an application might establish a connection with a peer using Rendezvous(), send a Message, and receive a Message. 4.2. </ins> Each application using the Transport Services Interface declares its preferences for how the transport service should operate using properties at each stage of the lifetime of a connection.  During Prefer, Require) for the level of preference of a given property during protocol selection; see selection-props.  <ins> 4.3. </ins> This document defines a language- and platform-independent interface to a Transport Services system.  Given the wide variety of languages


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 <del> on an encrypted Transport Layer Security (TLS) I-D.ietf-tls-tls13 stream over 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 functionality needed to provide a transport service across a network, as required by the abstract interface. <del> Connection Group: A set of Connections that share properties.  For multiplexing transport protocols, the Connection Group defines the set of Connections that can be multiplexed together. </del>  Path: Represents an available set of properties that a local system can use to communicate with a remote system, such as consider protocols identical only if they are of the same type and version.  For example, the same version of TLS running over two different transport protocol stacks are considered equivalent, <del> whereas TLS 1.2 and TLS 1.3 I-D.ietf-tls-tls13 are not considered equivalent. </del>  5.

Alternate proposal to address (old PR was "Add CacheContext to architecture and API", ) Define explicit Connection Groups as a way to define caching boundaries Update TLS 1.3 references to RFC 8446
This is a light-weight approach, but seems a little heavy-handed. I thought connection groups were a tool to model multi-streaming. With this PR, they become a fuzzy thing between cache context and multi-streaming abstraction. This may be the better choice, but ist definitely an Architecture decision. I liked the cache original context more.
The result of the interim discussion was that we didn't like a separate cache context object as much. Based on the discussion, we need some abstraction to say "these connections don't share state with the rest of the connections in my process, and can share between one another". The Group is a convenient way to do this. Note that you can just have one connection in its own group even. In some ways, it solves a lot of problems—it isn't sensical to say that connections in a Group can not share cache state. It I multiplex, I'm by default sharing TLS state. So if we have a separate cache context, we'll need some prohibition that you can't have multiple connections in a group have different cache contexts. Using the group as the way to define the boundary solves this.
I agree that it solves a lot of Problems and is an easy-to-use solution. The more I think about it, the more I like it. If we agree that we want to go down this road, definitely a +1 from my side modulo NAME comments. Still, if we land this one, we need to add some means of manually managing connection groups to the API in the next round.
NAME please re-review!
NAME I updated the text to avoid the implication about cloning. I didn't intend to change the behavior for Clone() being required to get multiplexing. I was more thinking that the use of the cache could be managed implicitly, while still requiring calling Clone() to actually multiplex. But, for now, I removed the text about implicit groups. Please check that this resolves your concerns!
Thanks for the reviews and input!
share NAME concerns, approving so we can submit a draft to discuss in prague...Looks good to me!LGTM! Thanks for the fixThanks – Looks good to me!

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  <ins> on an encrypted Transport Layer Security (TLS) RFC8446 stream over 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 functionality needed to provide a transport service across a network, as required by the abstract interface.  <ins> Connection Group: A set of Connections that share properties and caches.  For multiplexing transport protocols, only Connections within the same Connection Group are allowed be multiplexed together.  Applications can use their explicitly defined Connection Groups to control caching boundaries, as discussed in groups. </ins> Path: Represents an available set of properties that a local system can use to communicate with a remote system, such as consider protocols identical only if they are of the same type and version.  For example, the same version of TLS running over two different transport protocol stacks are considered equivalent,  <ins> whereas TLS 1.2 and TLS 1.3 RFC8446 are not considered equivalent. 4.2.4. By default, all stored properties of the Implementation are shared within a process, such as cached protocol state, cached path state, and heuristics.  This provides efficiency and convenience for the application, since the Transport System Implementation can automatically optimize behavior. There are several reasons, however, that an application might want to isolate some Connections within a single process.  These reasons include: Privacy concerns about re-using cached protocol state that can lead to linkability.  Sensitive state may include TLS session state RFC8446 and HTTP cookies RFC6265. Privacy concerns about allowing Connections to multiplex together, which can tell a Remote Endpoint that all of the Connections are coming from the same application (for example, when Connections are multiplexed HTTP/2 or QUIC streams). Performance concerns about Connections introducing head-of-line blocking due to multiplexing or needing to share state on a single thread. The Transport Services API SHOULD allow applications to explicitly define Connection Groups that force separation of Cached State and Protocol Stacks.  For example, a web browser application might use Connection Groups with separate caches for different tabs in the browser to decrease linkability. The interface to specify these Groups MAY expose fine-grained tuning for which properties and cached state is allowed to be shared with other Connections.  For example, an application might want to allow sharing TCP Fast Open cookies across groups, but not TLS session state. </ins> 5.


Candidate Gathering, to identify the paths, protocols, and endpoints to use, and Candidate Racing, in which the necessary protocol handshakes are conducted so that the transport system can select <del> which set to use. </del>  The most simple example of this process might involve identifying the single IP address to which the implementation wishes to connect, 4.1.1.  When an implementation responsible for connection establishment needs to consider multiple options, it should logically structure these options as a hierarchical tree.  Each leaf node of the tree A parent node may also only have one child (or leaf) node, such as a when a hostname resolves to only a single IP address. <del> 4.1.2. </del>  There are three types of branching from a parent node into one or more child nodes.  Any parent node of the tree must only use one type of branching. <del> 4.1.2.1. </del>  If a connection originally targets a single endpoint, there may be multiple endpoints of different types that can be derived from the Each of these hostnames may also resolve to one or more addresses, thus creating multiple layers of branching. <del> 4.1.2.2. </del>  If a client has multiple network interfaces available to it, such as mobile client with both Wi-Fi and Cellular connectivity, it can The list of available paths should be constrained by any requirements or prohibitions the application sets, as well as system policy. <del> 4.1.2.3. </del>  Differences in possible protocol compositions and options can also provide a branching point in connection establishment.  This allows 10. <del> The connection establishment process outlined in conn-establish is appropriate for client-server connections, but needs to be expanded in peer-to-peer Rendezvous scenarios, as follows: Gathering Local Endpoint candidates The set of possible Local Endpoints is gathered.  In the simple case, this merely enumerates the local interfaces and protocols, allocates ephemeral source ports.  For example, a system that has WiFi and Ethernet and supports IPv4 and IPv6 might gather four candidate locals (IPv4 on Ethernet, IPv6 on Ethernet, IPv4 on WiFi, and IPv6 on WiFi) that can form the source for a transient. If NAT traversal is required, the process of gathering Local Endpoints becomes broadly equivalent to the ICE candidate gathering phase RFC5245.  The endpoint determines its server reflexive Local Endpoints (i.e., the translated address of a local, on the other side of a NAT) and relayed locals (e.g., via a TURN server or other relay), for each interface and network protocol.  These are added to the set of candidate Local Endpoints for this connection. Gathering Local Endpoints is primarily a local operation, although it might involve exchanges with a STUN server to derive server reflexive locals, or with a TURN server or other relay to derive relayed locals.  It does not involve communication with the Remote Endpoint. Gathering Remote Endpoint Candidates The Remote Endpoint is typically a name that needs to be resolved into a set of possible addresses that can be used for communication.  Resolving the Remote Endpoint is the process of recursively performing such name lookups, until fully resolved, to return the set of candidates for the remote of this connection. How this is done will depend on the type of the Remote Endpoint, and can also be specific to each Local Endpoint.  A common case is when the Remote Endpoint is a DNS name, in which case it is resolved to give a set of IPv4 and IPv6 addresses representing that name.  Some types of remote might require more complex resolution.  Resolving the Remote Endpoint for a peer-to-peer connection might involve communication with a rendezvous server, which in turn contacts the peer to gain consent to communicate and retrieve its set of candidate locals, which are returned and form the candidate remote addresses for contacting that peer. Resolving the remote is _not_ a local operation.  It will involve a directory service, and can require communication with the remote to rendezvous and exchange peer addresses.  This can expose some or all of the candidate locals to the remote. Establishing Connections The set of candidate Local Endpoints and the set of candidate Remote Endpoints are paired, to derive a priority ordered set of Candidate Paths that can potentially be used to establish a Connection. Then, communication is attempted over each candidate path, in priority order.  If there are multiple candidates with the same priority, then connection establishment proceeds simultaneously and uses the transient that wins the race to be established. Otherwise, connection establishment is sequential, paced at a rate that should not congest the network.  Depending on the chosen transport, this phase might involve racing TCP connections to a server over IPv4 and IPv6 RFC8305, or it could involve a STUN exchange to establish peer-to-peer UDP connectivity RFC5245, or some other means. Confirming and Maintaining Connections Once connectivity has been established, unused resources can be released and the chosen path can be confirmed.  This is primarily required when establishing peer-to-peer connectivity, where connections supporting relayed locals that were not required can be closed, and where an associated signalling operation might be needed to inform middleboxes and proxies of the chosen path. Keep-alive messages may also be sent, as appropriate, to ensure NAT and firewall state is maintained, so the Connection remains operational. To support ICE, or similar protocols, that involve an out-of-band indirect signalling exchange to exchange candidates with the Remote Endpoint, it's important to be able to query the set of candidate Local Endpoints, and give the protocol stack a set of candidate Remote Endpoints, before it attempts to establish connections. (TO-DO: It is expected that a single abstract algorithm can be identified that supports both the peer-to-peer and client-server connection racing, allowing this text to be merged with conn- establish) 11. </del> RFC-EDITOR: Please remove this section before publication. This document has no actions for IANA. <del> 12. </del>  <del> 12.1. </del>  Implementations should avoid downgrade attacks that allow network interference to cause the implementation to select less secure, or entirely insecure, combinations of paths and protocols. <del> 12.2. </del>  See fastopen for security considerations around racing with 0-RTT data.

Restructure to address Rearrange to include Rendezvous and Environment Discovery text in connection establishment. Remove that previous section. was intended to check the ordering of sections against the other drafts and to merge . I have merged the Rendezvous text into Connection Establishment, but I haven't changed any of the text yet. I am a little concerned about creating an interdependancy in the text between derriving endpoints (name lookup) and the ICE/TURN stuff. More generally, I am not sure what to say about name resolution and proxies (ala ). TOR opens a can of privacy worms for name lookup and racing paths that I am not sure how to address.
Looks good apart from typo!
Having proxies to go through on a system (SOCKS, HTTP Connect, etc) or a set of TOR endpoints requires the implementation to do some nested/recursive work, and pass down endpoints correctly to protocol instances. The implementation document should describe this.
+1
There is already text in 4.1.3.3. Protocol Options. Is that sufficient or do we need more?
Review structure. What fits in pre-establishment. Relation system policy - cached state. Generalizes
Discussed in Singapore, we'll have more structure comments later, but we've done a lot of changes since then.
I like the change, as it makes the process much clearer and reduces the awkwardness of ICE/STUN. To model TOR, SOCKS, or other tunnelling protocols, I would refrain from seeing them as protocol stacks, but treat them as derived paths that only support these stacks. This removes the need for cupeling name resolution to the protocol stack, and looks quite natural to me as these derived paths may be available in the connection cache or need to be established for name resolution anyway before starting the real candidate racing. If we want to do so, it might be easier to talk about paths (that have one or more corresponding local endpoints), derived paths, derived remote endpoints (as result of name resolution on each path) and protocol stacks.

Candidate Gathering, to identify the paths, protocols, and endpoints to use, and Candidate Racing, in which the necessary protocol handshakes are conducted so that the transport system can select  <ins> which set to use.  This document structures candidates for racing as a tree. </ins> The most simple example of this process might involve identifying the single IP address to which the implementation wishes to connect, 4.1.1. <ins> Both Local and Remote Endpoint Candidates must be discovered during connection establishment.  To support ICE, or similar protocols, that involve out-of-band indirect signalling to exchange candidates with the Remote Endpoint, it's important to be able to query the set of candidate Local Endpoints, and give the protocol stack a set of candidate Remote Endpoints, before it attempts to establish connections. 4.1.1.1. The set of possible Local Endpoints is gathered.  In the simple case, this merely enumerates the local interfaces and protocols, allocates ephemeral source ports.  For example, a system that has WiFi and Ethernet and supports IPv4 and IPv6 might gather four candidate locals (IPv4 on Ethernet, IPv6 on Ethernet, IPv4 on WiFi, and IPv6 on WiFi) that can form the source for a transient. If NAT traversal is required, the process of gathering Local Endpoints becomes broadly equivalent to the ICE candidate gathering phase RFC5245.  The endpoint determines its server reflexive Local Endpoints (i.e., the translated address of a local, on the other side of a NAT) and relayed locals (e.g., via a TURN server or other relay), for each interface and network protocol.  These are added to the set of candidate Local Endpoints for this connection. Gathering Local Endpoints is primarily a local operation, although it might involve exchanges with a STUN server to derive server reflexive locals, or with a TURN server or other relay to derive relayed locals.  It does not involve communication with the Remote Endpoint. 4.1.1.2. The Remote Endpoint is typically a name that needs to be resolved into a set of possible addresses that can be used for communication. Resolving the Remote Endpoint is the process of recursively performing such name lookups, until fully resolved, to return the set of candidates for the remote of this connection. How this is done will depend on the type of the Remote Endpoint, and can also be specific to each Local Endpoint.  A common case is when the Remote Endpoint is a DNS name, in which case it is resolved to give a set of IPv4 and IPv6 addresses representing that name.  Some types of remote might require more complex resolution.  Resolving the Remote Endpoint for a peer-to-peer connection might involve communication with a rendezvous server, which in turn contacts the peer to gain consent to communicate and retrieve its set of candidate locals, which are returned and form the candidate remote addresses for contacting that peer. Resolving the remote is not a local operation.  It will involve a directory service, and can require communication with the remote to rendezvous and exchange peer addresses.  This can expose some or all of the candidate locals to the remote. 4.1.2. </ins> When an implementation responsible for connection establishment needs to consider multiple options, it should logically structure these options as a hierarchical tree.  Each leaf node of the tree A parent node may also only have one child (or leaf) node, such as a when a hostname resolves to only a single IP address.  <ins> 4.1.3. </ins> There are three types of branching from a parent node into one or more child nodes.  Any parent node of the tree must only use one type of branching.  <ins> 4.1.3.1. </ins> If a connection originally targets a single endpoint, there may be multiple endpoints of different types that can be derived from the Each of these hostnames may also resolve to one or more addresses, thus creating multiple layers of branching.  <ins> 4.1.3.2. </ins> If a client has multiple network interfaces available to it, such as mobile client with both Wi-Fi and Cellular connectivity, it can The list of available paths should be constrained by any requirements or prohibitions the application sets, as well as system policy.  <ins> 4.1.3.3. </ins> Differences in possible protocol compositions and options can also provide a branching point in connection establishment.  This allows 10.  RFC-EDITOR: Please remove this section before publication. This document has no actions for IANA.  <ins> 11. </ins>  <ins> 11.1. </ins> Implementations should avoid downgrade attacks that allow network interference to cause the implementation to select less secure, or entirely insecure, combinations of paths and protocols.  <ins> 11.2. </ins> See fastopen for security considerations around racing with 0-RTT data.


particular, this can avoid (re-)sending data that relies on a previous transmission that was never received.  Allowing applications to interact with messages is backwards- compatible with existings protocols and APIs, as it does not change the wire format of any protocol.  Instead, it gives the protocol Properties (datatransfer).  Message Properties can also be specified during data transfer to affect specific Messages. <del> Connection: A Connection object represents an active transport protocol instance that can send and/or receive Messages between local and remote systems.  It holds state pertaining to the underlying transport protocol instance and any ongoing data transfer.  This represents, for example, an active connection in a connection-oriented protocol such as TCP, or a fully-specified 5-tuple for a connectionless protocol such as UDP. </del>  Listener: A Listener object accepts incoming transport protocol connections from remote systems and generates corresponding

This updates the definition of a TAPS connection to allow a TAPS implementation to do connection pooling and multi-streaming. It removes the limitation from a TAPS connection to relate to exactly one underlying transport connection and hints that underlying transport connections my be created automatically. This is one result of the discussion around PR .
All comments should be addressed – ready for merge
Thanks for the changes! LGTM.
That seems OK, can we fix: / It can also represent a pool of transport protocol instance/ to be /instances/ or whatever the plural is of a transport protocol instance? Gorry
The arch definition of connection should add a sentence to say that there may be multiple flows (MPTCP, MPQUIC, or even connection pooling) below the abstraction. This was assumed but not stated.
May be fixed by PR
Solved by
LGTM modulo the small fixes pointed out by NAME

particular, this can avoid (re-)sending data that relies on a previous transmission that was never received. <ins> the ability to automatically assign messages and connections to underlaying transport connections to utilize multi-streaming and pooled connections. </ins> Allowing applications to interact with messages is backwards- compatible with existings protocols and APIs, as it does not change the wire format of any protocol.  Instead, it gives the protocol Properties (datatransfer).  Message Properties can also be specified during data transfer to affect specific Messages.  <ins> Connection: A Connection object represents one or more active transport protocol instances that can send and/or receive Messages between local and remote systems.  It holds state pertaining to the underlying transport protocol instances and any ongoing data transfers.  This represents, for example, an active connection in a connection-oriented protocol such as TCP, or a fully-specified 5-tuple for a connectionless protocol such as UDP.  It can also represent a pool of transport protocol instance, e.g., a set of TCP and QUIC connections to equivalent endpoints, or a stream of a multi-streaming transport protocol instance. </ins> Listener: A Listener object accepts incoming transport protocol connections from remote systems and generates corresponding


path, the transport system will try the path first, ignoring the preference. <del> Both Selection and Connection Properties can be added to a Preconnection to configure the selection process, and to further configure the eventually selected protocol stack(s).  They are collected into a TransportProperties object to be passed into a Preconnection object: </del>  Individual properties are then added to the TransportProperties Object: retransmission of the 0-RTT data may cause the remote application to receive the Message multiple times.  7.3.5. Boolean

This came up in a dinner among some of us yesterday: all UDP messages should be understood as being idempotent, because UDP doesn't protect the receiver against getting duplicates. This is different from unreliable transmission with, e.g., SCTP (or, probably, a future such extension of QUIC?), where you can be sure you're not getting a duplicate.
wfm

path, the transport system will try the path first, ignoring the preference.  <ins> Selection, and Connection Properties, as well as defaults for Message Properties, can be added to a Preconnection to configure the selection process, and to further configure the eventually selected protocol stack(s).  They are collected into a TransportProperties object to be passed into a Preconnection object: </ins> Individual properties are then added to the TransportProperties Object: retransmission of the 0-RTT data may cause the remote application to receive the Message multiple times. <ins> Note that for protocols that do not protect against duplicated messages, e.g., UDP, all messages MUST be marked as Idempotent.  In order to enable protocol selection to choose such a protocol, Idempotent MUST be added to the TransportProperties passed to the Preconnection.  If such a protocol was chosen, disabling Idempotent on individual messages MUST result in a SendError. </ins> 7.3.5. Boolean


Connection-oriented transport protocols), or when the first Message has been received from the Remote Endpoint (for Connectionless protocols), causing a new Connection to be created.  The resulting <del> Connection is contained within the ConnectionReceived event, and is </del>  ready to use as soon as it is passed to the application via the event.  A ListenError occurs either when the Properties of the Preconnection cannot be fulfilled for listening, when the Local Endpoint (or Remote Endpoint, if specified) cannot be resolved, or when the application is prohibited from listening by policy. <del> A Stopped event occurs after the Listener has stopped listening. </del>  6.3.

This implements what we discussed on
There should be a way to put back pressure or limits on the number of inbound connections for a listener. The two approaches are: To have a one-to-one callback for listen -> received connect To have a way to set a numeric limit of new inbound connections My preference is (2). (1) has an issue of being very impractical for servers that don't know how many connections they'll receive, and may require them to call a thousand times without any other activity. (2) is more similar to how calling on sockets work.
+1 on variant 2 - indeed it's common and known to people from sockets, and just seems like the easier and more efficient solution (albeit maybe less "beautiful", in a way).
+1 on variant 2 as well.
Do variant 2.
I believe that PR fully addresses this; hence I'm closing it.
lgtm, thanks!This is surely useful as-is. Considering the recent discussion on the list (dynamic per-IP rejection possibilities), I'm not sure it's rich enough... but it's certainly a good starting point. I'm also not sure how much of what's been discussed really should be a part of the spec.

Connection-oriented transport protocols), or when the first Message has been received from the Remote Endpoint (for Connectionless protocols), causing a new Connection to be created.  The resulting  <ins> Connection is contained within the ConnectionReceived Event, and is </ins> ready to use as soon as it is passed to the application via the event. <ins> If the caller wants to rate-limit the number of inbound Connections that will be delivered, it can set a cap using SetNewConnectionLimit().  This mechanism allows a server to protect itself from being drained of resources.  Each time a new Connection is delivered by the ConnectionReceived Event, the value is automatically decremented.  Once the value reaches zero, no further Connections will be delivered until the caller sets the limit to a higher value.  By default, this value is Infinite.  The caller is also able to reset the value to Infinite at any point. </ins> A ListenError occurs either when the Properties of the Preconnection cannot be fulfilled for listening, when the Local Endpoint (or Remote Endpoint, if specified) cannot be resolved, or when the application is prohibited from listening by policy.  <ins> A Stopped Event occurs after the Listener has stopped listening. </ins> 6.3.


Each protocol that can run as part of a Transport Services implementation defines both its API mapping as well as implementation <del> details. API mappings for a protocol apply most to Connections in which the given protocol is the "top" of the Protocol Stack.  For example, the mapping of the "Send" function for TCP applies to Connections in which the application directly sends over TCP.  If HTTP/2 is used on top of TCP, the HTTP/2 mappings take precendence. </del>  Each protocol has a notion of Connectedness.  Possible values for Connectedness are: Message lengths can be defined, and Messages can be partially reliable.  9.1. Connectedness: Connected TCP connections between two hosts map directly to Connection objects. <del> Calling "Initiate" on a TCP Connection causes it to reserve a local port, and send a SYN to the Remote Endpoint. </del>  <del> Early idempotent data is sent on a TCP Connection in the SYN, as TCP Fast Open data. </del>  A TCP Connection is ready once the three-way handshake is complete. <del> TCP can throw various errors during connection setup. Specifically, it is important to handle a RST being sent by the peer during the handshake. </del>  Once established, TCP throws errors whenever the connection is <del> disconnected, such as due to receive a RST from the peer; or </del>  hitting a TCP retransmission timeout. <del> Calling "Listen" for TCP binds a local port and prepares it to receive inbound SYN packets from peers. </del>  TCP Listeners will deliver new connections once they have replied to an inbound SYN with a SYN-ACK. equivalent parameters.  The two Connections are otherwise independent. <del> TCP does not on its own preserve Message boundaries.  Calling "Send" on a TCP connection lays out the bytes on the TCP send stream without any other delineation.  Any Message marked as Final will cause TCP to send a FIN once the Message has been completely written. </del>  <del> TCP delivers a stream of bytes without any Message delineation. All data delivered in the "Received" or "ReceivedPartial" event will be part of a single stream-wide Message that is marked Final (unless a MessageFramer is used).  EndOfMessage will be delivered when the TCP Connection has received a FIN from the peer. </del>  Calling "Close" on a TCP Connection indicates that the Connection <del> should be gracefully closed by sending a FIN to the peer and waiting for a FIN-ACK before delivering the "Closed" event. </del>  Calling "Abort" on a TCP Connection indicates that the Connection <del> should be immediately closed by sending a RST to the peer. </del>  9.2. UDP connections represent a pair of specific IP addresses and ports on two hosts. <del> Calling "Initiate" on a UDP Connection causes it to reserve a local port, but does not generate any traffic. </del>  Early data on a UDP Connection does not have any special meaning. The data is sent whenever the Connection is Ready. UDP Connections can only generate errors on initiation due to port conflicts on the local system. <del> Once in use, UDP throws errors upon receiving ICMP notifications indicating failures in the network. </del>  <del> Calling "Listen" for UDP binds a local port and prepares it to receive inbound UDP datagrams from peers. </del>  UDP Listeners will deliver new connections once they have received traffic from a new Remote Endpoint. equivalent parameters.  The two Connections are otherwise independent. <del> Calling "Send" on a UDP connection sends the data as the payload of a complete UDP datagram.  Marking Messages as Final does not change anything in the datagram's contents. </del>  <del> UDP only delivers complete Messages to "Received", each of which represents a single datagram received in a UDP packet. </del>  <del> Calling "Close" on a UDP Connection releases the local port reservation. </del>  <del> Calling "Abort" on a UDP Connection is identical to calling "Close". </del>  9.3. 9.8. <del> To support sender-side stream schedulers (which are implemented on the sender side), a receiver-side Transport System should always support message interleaving RFC8260. SCTP messages can be very large.  To allow the reception of large messages in pieces, a "partial flag" can be used to inform a (native SCTP) receiving application that a message is incomplete.  After receiving the "partial flag", this application would know that the next receive calls will only deliver remaining parts of the same message (i.e., no messages or partial messages will arrive on other streams until the message is complete) (see Section 8.1.20 in RFC6458).  The "partial flag" can therefore facilitate the implementation of the receiver buffer in the receiving application, at the cost of limiting multiplexing and temporarily creating head- of-line blocking delay at the receiver. When a Transport System transfers a Message, it seems natural to map the Message object to SCTP messages in order to support properties such as "Ordered" or "Lifetime" (which maps onto partially reliable delivery with a SCTP_PR_SCTP_TTL policy RFC6458).  However, since multiplexing of Connections onto SCTP streams may happen, and would be hidden from the application, the Transport System requires a per- stream receiver buffer anyway, so this potential benefit is lost and the "partial flag" becomes unnecessary for the system. The problem of long messages either requiring large receiver-side buffers or getting in the way of multiplexing is addressed by message interleaving RFC8260, which is yet another reason why a receivers- side transport system supporting SCTP should implement this mechanism. </del>  10.

(SCTP mapping) This uses a new approach for such text for TCP, UDP and SCTP. Also: updates appendix D of interface.
We've updated Implementation mapping details for most protocols with , but we didn't tackle SCTP yet.
I'm fine with this being assigned to me. However, it's more than just writing the SCTP text. Here's the relevant part of what I wrote in PR : I don't suggest to delete much of the text that's there but definitely amend it with the RFC reference at least for what's covered in RFC 8303. There's a very direct line from this type of text in RFC 8303 to the original specs, so I do believe that should be helpful. That's (obviously) post-Montreal though!
NAME please send a PR along these lines.

Each protocol that can run as part of a Transport Services implementation defines both its API mapping as well as implementation  <ins> details.  API mappings for a protocol apply most to Connections in which the given protocol is the "top" of the Protocol Stack.  For example, the mapping of the "Send" function for TCP applies to Connections in which the application directly sends over TCP.  If HTTP/2 is used on top of TCP, the HTTP/2 mappings take precendence. </ins> Each protocol has a notion of Connectedness.  Possible values for Connectedness are: Message lengths can be defined, and Messages can be partially reliable. <ins> Below, primitives in the style of "CATEGORY.[SUBCATEGORY].PRIMITIVENAME.PROTOCOL" (e.g., "CONNECT.SCTP") refer to the primitives with the same name in section 4 of RFC8303.  For further implementation details, the description of these primitives in RFC8303 points to section 3, which refers back the specifications for each protocol.  This back-tracking method applies to all elements of I-D.ietf-taps-minset (see appendix D of I- D.ietf-taps-interface): they are listed in appendix A of I-D.ietf- taps-minset with an implementation hint in the same style, pointing back to section 4 of RFC8303. </ins> 9.1. Connectedness: Connected TCP connections between two hosts map directly to Connection objects.  <ins> CONNECT.TCP.  Calling "Initiate" on a TCP Connection causes it to reserve a local port, and send a SYN to the Remote Endpoint. </ins>  <ins> CONNECT.TCP with parameter "user message".  Early idempotent data is sent on a TCP Connection in the SYN, as TCP Fast Open data. </ins> A TCP Connection is ready once the three-way handshake is complete.  <ins> Failure of CONNECT.TCP.  TCP can throw various errors during connection setup.  Specifically, it is important to handle a RST being sent by the peer during the handshake. </ins> Once established, TCP throws errors whenever the connection is  <ins> disconnected, such as due to receiving a RST from the peer; or </ins> hitting a TCP retransmission timeout.  <ins> LISTEN.TCP.  Calling "Listen" for TCP binds a local port and prepares it to receive inbound SYN packets from peers. </ins> TCP Listeners will deliver new connections once they have replied to an inbound SYN with a SYN-ACK. equivalent parameters.  The two Connections are otherwise independent.  <ins> SEND.TCP.  TCP does not on its own preserve Message boundaries. Calling "Send" on a TCP connection lays out the bytes on the TCP send stream without any other delineation.  Any Message marked as Final will cause TCP to send a FIN once the Message has been completely written, by calling CLOSE.TCP immediately upon successful termination of SEND.TCP. </ins>  <ins> With RECEIVE.TCP, TCP delivers a stream of bytes without any Message delineation.  All data delivered in the "Received" or "ReceivedPartial" event will be part of a single stream-wide Message that is marked Final (unless a MessageFramer is used). EndOfMessage will be delivered when the TCP Connection has received a FIN (CLOSE-EVENT.TCP or ABORT-EVENT.TCP) from the peer. </ins> Calling "Close" on a TCP Connection indicates that the Connection  <ins> should be gracefully closed (CLOSE.TCP) by sending a FIN to the peer and waiting for a FIN-ACK before delivering the "Closed" event. </ins> Calling "Abort" on a TCP Connection indicates that the Connection  <ins> should be immediately closed by sending a RST to the peer (ABORT.TCP). </ins> 9.2. UDP connections represent a pair of specific IP addresses and ports on two hosts.  <ins> CONNECT.UDP.  Calling "Initiate" on a UDP Connection causes it to reserve a local port, but does not generate any traffic. </ins> Early data on a UDP Connection does not have any special meaning. The data is sent whenever the Connection is Ready. UDP Connections can only generate errors on initiation due to port conflicts on the local system.  <ins> Once in use, UDP throws "soft errors" (ERROR.UDP(-Lite)) upon receiving ICMP notifications indicating failures in the network. </ins>  <ins> LISTEN.UDP.  Calling "Listen" for UDP binds a local port and prepares it to receive inbound UDP datagrams from peers. </ins> UDP Listeners will deliver new connections once they have received traffic from a new Remote Endpoint. equivalent parameters.  The two Connections are otherwise independent.  <ins> SEND.UDP(-Lite).  Calling "Send" on a UDP connection sends the data as the payload of a complete UDP datagram.  Marking Messages as Final does not change anything in the datagram's contents. Upon sending a UDP datagram, some relevant fields and flags in the IP header can be controlled: DSCP (SET_DSCP.UDP(-Lite)), DF in IPv4 (SET_DF.UDP(-Lite)) and ECN flag (SET_ECN.UDP(-Lite)). </ins>  <ins> RECEIVE.UDP(-Lite).  UDP only delivers complete Messages to "Received", each of which represents a single datagram received in a UDP packet.  Upon receiving a UDP datagram, the ECN flag from the IP header can be obtained (GET_ECN.UDP(-Lite)). </ins>  <ins> Calling "Close" on a UDP Connection (ABORT.UDP(-Lite)) releases the local port reservation. </ins>  <ins> Calling "Abort" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close". </ins> 9.3. 9.8.  <ins> Connectedness: Connected Data Unit: Message API mappings for SCTP are as follows: Connection objects represent a flow of SCTP messages between a client and a server, which may be an SCTP association or a stream in a SCTP association.  How to map Connection objects to streams is described in NEAT-flow-mapping; in the following, a similar method is described.  To map Connection objects to SCTP streams without head-of-line blocking on the sender side, both the sending and receiving SCTP implementation must support message interleaving RFC8260.  Both SCTP implementations must also support stream reconfiguration.  Finally, both communicating endpoints must be aware of this intended multiplexing; NEAT-flow-mapping describes a way for a Transport System to negotiate the stream mapping capability using SCTP's adaptation layer indication, such that this functionality would only take effect if both ends sides are aware of it.  The first flow, for which the SCTP association has been created, will always use stream id zero.  All additional flows are assigned to unused stream ids in growing order.  To avoid a conflict when both endpoints map new flows simultaneously, the peer which initiated the transport connection will use even stream numbers whereas the remote side will map its flows to odd stream numbers.  Both sides maintain a status map of the assigned stream numbers.  Generally, new streams must consume the lowest available (even or odd, depending on the side) stream number; this rule is relevant when lower numbers become available because Connection objects associated to the streams are closed. If this is the only Connection object that is assigned to the SCTP association or stream mapping has not been negotiated, CONNECT.SCTP is called.  Else, a new stream is used: if there are enough streams available, "Initiate" is just a local operation that assigns a new stream number to the Connection object.  The number of streams is negotiated as a parameter of the prior CONNECT.SCTP call, and it represents a trade-off between local resource usage and the number of Connection objects that can be mapped without requiring a reconfiguration signal.  When running out of streams, ADD_STREAM.SCTP must be called. If this is the only Connection object that is assigned to the SCTP association or stream mapping has not been negotiated, CONNECT.SCTP is called with the "user message" parameter.  Else, a new stream is used (see "Initiate" for how to handle running out of streams), and this just sends the first message on a new stream. "Initiate" or "InitiateWithSend" returns without an error, i.e. SCTP's four-way handshake has completed.  If an association with the peer already exists, and stream mapping has been negotiated and enough streams are available, a Connection Object instantly becomes Ready after calling "Initiate" or "InitiateWithSend". Failure of CONNECT.SCTP. TIMEOUT.SCTP or ABORT-EVENT.SCTP. LISTEN.SCTP.  If an association with the peer already exists and stream mapping has been negotiated, "Listen" just expects to receive a new message on a new stream id (chosen in accordance with the stream number assignment procedure described above). LISTEN.SCTP returns without an error (a result of successful CONNECT.SCTP from the peer), or, in case of stream mapping, the first message has arrived on a new stream (in this case, "Receive" is also invoked). Calling "Clone" on an SCTP association creates a new Connection object and assigns it a new stream number in accordance with the stream number assignment procedure described above.  If there are not enough streams available, ADD_STREAM.SCTP must be called. When this value is changed, or a Message with Message Property "Priority" is sent, and there are multiple Connection objects assigned to the same SCTP association, CONFIGURE_STREAM_SCHEDULER.SCTP is called to adjust the priorities of streams in the SCTP association. SEND.SCTP.  Message Properties such as "Lifetime" and "Ordered" map to parameters of this primitive. RECEIVE.SCTP.  The "partial flag" of RECEIVE.SCTP invokes a "ReceivedPartial" event. Close: If this is the only Connection object that is assigned to the SCTP association, CLOSE.SCTP is called.  Else, the Connection object is one out of several Connection objects that are assigned to the same SCTP assocation, and RESET_STREAM.SCTP must be called, which informs the peer that the stream will no longer be used for mapping and can be used by future "Initiate", "InitiateWithSend" or "Listen" calls.  At the peer, the event RESET_STREAM-EVENT.SCTP will fire, which the peer must answer by issuing RESET_STREAM.SCTP too.  The resulting local RESET_STREAM-EVENT.SCTP informs the transport system that the stream number can now be re-used by the next "Initiate", "InitiateWithSend" or "Listen" calls. Abort: If this is the only Connection object that is assigned to the SCTP association, ABORT.SCTP is called.  Else, the Connection object is one out of several Connection objects that are assigned to the same SCTP assocation, and shutdown proceeds as described under "Close". </ins> 10.


1.1.  The traditional model of using sockets for networking can be represented as follows: can use multiple IP addresses, multiple protocols, multiple paths, and provide multiple application streams. <del> 1.2. </del>  Originally, sockets presented a blocking interface for establishing connections and transferring data.  However, most modern applications opposed to how sockets represent network resources as file system objects that may be temporarily unavailable. <del> 1.3. </del>  Sockets provide a message interface for datagram protocols like UDP, but provide an unstructured stream abstraction for TCP.  While TCP transport services, while simplifying the application's role in parsing data. <del> 1.4. </del>  Sockets, for protocols like TCP, are generally limited to connecting to a single address over a single interface.  They also present a support initiating and receiving new streams using existing connections. <del> 2. The Transport Services architecture is based on the survey of Services Provided by IETF Transport Protocols and Congestion Control Mechanisms RFC8095, and the distilled minimal set of the features offered by transport protocols I-D.ietf-taps-minset.  These documents identified common features and patterns across all transport protocols developed thus far in the IETF. Since transport security is an increasingly relevant aspect of using transport protocols on the Internet, this architecture also considers the impact of transport security protocols on the feature-set exposed by transport services I-D.ietf-taps-transport-security. One of the key insights to come from identifying the minimal set of features provided by transport protocols I-D.ietf-taps-minset was that features either require application interaction and guidance (referred to as Functional or Optimizing Features), or else can be handled automatically by a system implementing Transport Services (referred to as Automatable Features).  Among the Functional and Optimizing Features, some were common across all or nearly all transport protocols, while others could be seen as features that, if specified, would only be useful with a subset of protocols, but would not harm the functionality of other protocols.  For example, some protocols can deliver messages faster for applications that do not require messages to arrive in the order in which they were sent. However, this functionality needs to be explicitly allowed by the application, since reordering messages would be undesirable in many cases. 2.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> 3. The goal of the Transport Services architecture is to redefine the

Based on discussion with NAME rearrange things to put a proper document overview in the intro, and split out the API Model discussion into its own section outside of the introduction.
LGTM (modulo one nit)Thank you NAME to do this - really improves the structure.

1.1. <ins> The Transport Services architecture is based on the survey of Services Provided by IETF Transport Protocols and Congestion Control Mechanisms RFC8095, and the distilled minimal set of the features offered by transport protocols I-D.ietf-taps-minset.  These documents identified common features and patterns across all transport protocols developed thus far in the IETF. Since transport security is an increasingly relevant aspect of using transport protocols on the Internet, this architecture also considers the impact of transport security protocols on the feature-set exposed by transport services I-D.ietf-taps-transport-security. One of the key insights to come from identifying the minimal set of features provided by transport protocols I-D.ietf-taps-minset was that features either require application interaction and guidance (referred to as Functional or Optimizing Features), or else can be handled automatically by a system implementing Transport Services (referred to as Automatable Features).  Among the Functional and Optimizing Features, some were common across all or nearly all transport protocols, while others could be seen as features that, if specified, would only be useful with a subset of protocols, but would not harm the functionality of other protocols.  For example, some protocols can deliver messages faster for applications that do not require messages to arrive in the order in which they were sent. However, this functionality needs to be explicitly allowed by the application, since reordering messages would be undesirable in many cases. 1.2. This document describes the Transport Services architecture in three sections: model describes how the API model of Transport Services differs from traditional socket-based APIs.  Specifically, it offers asynchronous event-driven interaction, the use of messages for data transfer, and the ability to easily adopt different transport protocols. design explains the design principles that guide the Transport Services API.  These principles are intended to make sure that transport protocols can continue to be enhanced and evolve without requiring too many changes by application developers. concepts presents the Transport Services architecture diagram and defines the concepts that are used by both the API and implementation documents.  The Preconnection allows applications to configure connection properties, and the Connection represents an object that can be used to send and receive Messages. 1.3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. 2. </ins> The traditional model of using sockets for networking can be represented as follows: can use multiple IP addresses, multiple protocols, multiple paths, and provide multiple application streams.  <ins> 2.1. </ins> Originally, sockets presented a blocking interface for establishing connections and transferring data.  However, most modern applications opposed to how sockets represent network resources as file system objects that may be temporarily unavailable.  <ins> 2.2. </ins> Sockets provide a message interface for datagram protocols like UDP, but provide an unstructured stream abstraction for TCP.  While TCP transport services, while simplifying the application's role in parsing data.  <ins> 2.3. </ins> Sockets, for protocols like TCP, are generally limited to connecting to a single address over a single interface.  They also present a support initiating and receiving new streams using existing connections.  3. The goal of the Transport Services architecture is to redefine the


and negotiations complete in order to gather metrics to influence future connections.  Similarly, an implementation may choose to hold onto fully established leaf nodes that were not the first to <del> establish for use in future connections, but this approach is not recommended since those attempts were slower to connect and may exhibit less desirable properties. </del>  4.5.1. 6.1.  When a path change occurs, the Transport Services implementation is responsible for notifying Protocol Instances in the Protocol Stack. If the Protocol Stack includes a transport protocol that supports permissible based on the Selection Properties passed by the application.  A multipath protocol can establish new subflows over new paths, and should tear down subflows over paths that are no <del> longer available.  If the Protocol Stack includes a transport protocol that does not support multipath, but support migrating between paths, the update to available paths can be used as the trigger to migrating the connection.  For protocols that do not support multipath or migration, the Protocol Instances may be informed of the path change, but should not be forcibly disconnected if the previously used path becomes unavailable.  An exception to this case is if the System Policy changes to prohibit traffic from the Connection based on its properties, in which case the Protocol Stack should be disconnected. </del>  7.

This is a follow-up issue for – As we have the ready to support connection coalescing and connection pooling, we have to describe it more closely in the Implementation.
Thanks for the fixes - I think this can be merged now.LGTM And: thanks for doing this! This can make the transport system a lot more powerful, and it's good to tell people about these interesting implementation options this draft, IMO.

and negotiations complete in order to gather metrics to influence future connections.  Similarly, an implementation may choose to hold onto fully established leaf nodes that were not the first to  <ins> establish for use as part of a Pooled Connection, see pooled- connections, or in future connections.  In both cases, keeping additional connections is generally not recommended since those attempts were slower to connect and may exhibit less desirable properties. </ins> 4.5.1. 6.1. <ins> For protocols that employ request/response pairs and do not require in-order delivery of the responses, like HTTP, the transport implementation may distribute interactions across several underlying transport connections.  For these kinds of protocols, implementations may hide the connection management and only expose a single Connection object and the individual requests/responses as messages. These Pooled Connections can use multiple connections or multiple streams of multi-streaming connections between endpoints, as long as all of these satisfy the requirements, and prohibitions specified in the Selection Properties of the Pooled Connection.  This enables implementations to realize transparent connection coalescing, connection migration, and to perform per-message endpoint and path selection by choosing among these underlying connections. 6.2. </ins> When a path change occurs, the Transport Services implementation is responsible for notifying Protocol Instances in the Protocol Stack. If the Protocol Stack includes a transport protocol that supports permissible based on the Selection Properties passed by the application.  A multipath protocol can establish new subflows over new paths, and should tear down subflows over paths that are no  <ins> longer available.  Pooled Connections pooled-connections may add or remove underlying transport connections in a similar manner.  If the Protocol Stack includes a transport protocol that does not support multipath, but support migrating between paths, the update to available paths can be used as the trigger to migrating the connection.  For protocols that do not support multipath or migration, the Protocol Instances may be informed of the path change, but should not be forcibly disconnected if the previously used path becomes unavailable.  An exception to this case is if the System Policy changes to prohibit traffic from the Connection based on its properties, in which case the Protocol Stack should be disconnected. </ins> 7.