jiebi/CodeConvo huggingface dataset:
Change:
Opening this to follow up on a comment by NAME on that is now closed. "Simultaneous" and "Staggered" would be better names than "Immediate" and "Delayed". Just from these terms, I would normally think that "Immediate" means to start racing right away, whereas "Delayed" means that nothing would happen for some time. So these two terms are slightly misleading in my opinion.)
I agree this would be an improvement.
LGTM (of course :-) )Thanks, looks good!

Discussion:
There are three different approaches to racing the attempts for different nodes of the connection establishment tree: <del> Immediate </del> <ins> Simultaneous </ins> <del> Delayed </del> <ins> Staggered </ins> Failover Each approach is appropriate in different use-cases and branch types. However, to avoid consuming unnecessary network resources, <del> implementations should not use immediate racing as a default </del> <ins> implementations should not use simultaneous racing as a default </ins> approach. The timing algorithms for racing should remain independent across

4.2.1. <del> Immediate racing is when multiple alternate branches are started </del> <ins> Simultaneous racing is when multiple alternate branches are started </ins> without waiting for any one branch to make progress before starting the next alternative.  This means the attempts are effectively <del> simultaneous.  Immediate racing should be avoided by implementations, since it consumes extra network resources and establishes state that might not be used. </del> <ins> simultaneous.  Simultaneous racing should be avoided by implementations, since it consumes extra network resources and establishes state that might not be used. </ins> 4.2.2. <del> Delayed racing can be used whenever a single node of the tree has </del> <ins> Staggered racing can be used whenever a single node of the tree has </ins> multiple child nodes.  Based on the order determined when building the tree, the first child node will be initiated immediately, followed by the next child node after some delay.  Once that second

initiated, or one of the child nodes successfully completes its negotiation. <del> Delayed racing attempts occur in parallel.  Implementations should </del> <ins> Staggered racing attempts occur in parallel.  Implementations should </ins> not terminate an earlier child connection attempt upon starting a secondary child.
Change:
Get a better/more formal explanation of Interactive mode for multipath based on our experience with Siri, etc.
Proposal from Christoph Paasch: The connection should attempt to minimize the latency for interactive traffic patterns by transmitting data across multiple paths. The goal of minimizing the latency will be balanced against the cost fo each of these paths, meaning that depending on the cost of the lower latency path the scheduling might choose to use a higher latency path. Finally, the scheduling of the traffic can be done such that data may be transmitted on multiple paths in parallel to achieve the lowest latency possible.
Thanks for following up on this one.LGTM

Discussion:
actual thresholds to declare a path unusable are implementation specific. <del> The connection should attempt to use multiple paths in parallel in order to minimize loss and delay.  The actual strategy is implementation specific. </del> <ins> The connection should attempt to minimize the latency for interactive traffic patterns by transmitting data across multiple paths when it is beneficial to do so.  The goal of minimizing the latency will be balanced against the cost of each of these paths, meaning that depending on the cost of the lower-latency path, the scheduling might choose to use a higher-latency path.  Traffic can be scheduled such that data may be transmitted on multiple paths in parallel to achieve the lowest latency possible.  The specific scheduling algorithm is implementation-specific. </ins> The connection should attempt to use multiple paths in parallel in order to maximize bandwidth and possibly overcome bandwidth
Change:
Removed phrasing that implies 0-RTT data is just one packet and added a reference to the Maximum Message Size with Connection Establishment property. Added a sentence on how/when an implementation can set this property.
The opening para reads to me like there is just one first packet. ... or is this actually more than one packets before the handshake complete?
It is one packet for TCP, but it can be more for QUIC, TLS 1.3 (etc)
Reference Connection Property "Maximum Message Size Concurrent with Connection Establishment"
Seems like a useful addition that resolves my issue.

Discussion:
5.3. Several protocols allow sending higher-level protocol or application <del> data within the first packet of their protocol establishment, such as TCP Fast Open RFC7413 and TLS 1.3 RFC8446.  This approach is referred to as sending Zero-RTT (0-RTT) data.  This is a desirable property, but poses challenges to an implementation that uses racing during connection establishment. </del> <ins> data during their protocol establishment, such as TCP Fast Open RFC7413 and TLS 1.3 RFC8446.  This approach is referred to as sending Zero-RTT (0-RTT) data.  This is a desirable property, but poses challenges to an implementation that uses racing during connection establishment. The amount of data that can be sent as 0-RTT data varies by protocol and can be queried by the application using the "Maximum Message Size Concurrent with Connection Establishment" Connection Property.  An implementation can set this property according to the protocols that it will race based on the given Selection Properties when the application requests to establish a connection. </ins> If the application has 0-RTT data to send in any protocol handshakes, it needs to provide this data before the handshakes have begun.  When
Change:
NAME PTAL
sec 5.2.12 Using temporary local addresses may break various mechanisms that prove address ownership (e.g QUIC resumption tokens) and therefore impair performance as the client has to re-verify its address.
The default is to use a temporary address for client local address; and to not use it for a server local address. This is the same as most socket APIs. What are you suggesting in the text, NAME
right, a QUIC resumption token will generally contain the client's IP address so that future connections no longer have to go through Retry and anti-amplification mechanisms, which reduce throughput. so IIUC 5.2.12 could say something like "Clients that use temporary local addresses might invalidate server-provided tokens that validate the client's IP addresses (e.g. Sec 8.1.3 of quic-transport), increasing latency."
Add a one-sentence warning that using a temporary address has a potential performance impact on resumption.
Do we wish to refer to RFC 7721?
This looks pretty close ... check these words and submit.

Discussion:
use of temporary local addresses, sometimes called "privacy" addresses RFC4941.  Temporary addresses are generally used to prevent linking connections over time when a stable address, sometimes called <del> "permanent" address, is not needed.  Note that if an application Requires the use of temporary addresses, the resulting Connection cannot use IPv4, because temporary addresses do not exist in IPv4. </del> <ins> "permanent" address, is not needed.  There are some caveats to note when specifying this property.  First, if an application Requires the use of temporary addresses, the resulting Connection cannot use IPv4, because temporary addresses do not exist in IPv4.  Second, temporary local addresses might involve trading off privacy for performance. For instance, temporary addresses can interfere with resumption mechanisms that some protocols rely on to reduce initial latency. </ins> 5.2.13.
Change:
I should have said: I approve this, modulo the changes requested by NAME
Thanks for incorporating my suggested changes. I think this can be merged now.

Discussion:
Preference is of type Boolean, with "true" indicating that the Selection Property has been applied. <ins> Tuple: An ordered grouping of multiple value types.  In this this document, it is written as a list in brackets, e.g., "(Enumeration, Preference)" The composition of types and their order depends on the property and is fixed for the property.  The actual representation is implementation-dependent. Collection: An unordered grouping of one or more values of the same type.  The actual representation, e.g. as a set or an array, is implementation-dependent. </ins> For types Integer and Numeric, special values can be defined per property; it is up to implementations how these special values are represented (e.g., by using -1 for an otherwise non-negative value).

interface <del> Set (Preference, Enumeration) </del> <ins> Collection of (Preference, Enumeration) </ins> <del> Empty set (not setting a preference for any interface) </del> <ins> Empty (not setting a preference for any interface) </ins> This property allows the application to select any specific network interfaces or categories of interfaces it wants to "Require",

pvd <del> Set (Preference, Enumeration) </del> <ins> Collection of (Preference, Enumeration) </ins> <del> Empty set (not setting a preference for any PvD) </del> <ins> Empty (not setting a preference for any PvD) </ins> Similar to interface instances and types (see prop-interface), this property allows the application to control path selection by

underlying transport security protocols.  When not specified, these algorithms should use known and safe defaults for the system.  Parameters include: ciphersuites, supported groups, and <del> signature algorithms. </del> <ins> signature algorithms.  These parameters take a collection of supported algorithms as parameter. </ins> Pre-Shared Key import: Used to install pre-shared keying material established out-of-band.  Each pre-shared keying material is
Change:
I found the relationship between streams and connections to be extremely murky throughout the draft, and left it not really sure how I would control a streamed transport. Section 6.4 hints suggests that opening additional streams is an alternative implementation of Clone() for transports that can do so. Does this imply that if the peer stream limit does not allow new streams, the transport should open a connection instead? How does SetNewConnectionLimit() in Sec 6.2 relate to streamed transport -- are there two levels of listener: a stream listener and a connection listener? How would opening "stream listeners" relate to the maximum number of streams the peer could open (i.e. do I have to call listen() 8 times to allow the client to open 8 streams)? Or are there no stream listeners and these "connections" just sort of appear? Skimming the -impl draft, I can see there's some text here but it is not fitting together for me. There are at least three streamed transports and it would be helpful to explain how the API conceptualizes this, perhaps in a new section.
To clarify, Listen() is called once and keeps receiving streams within the NewConnectionLimit. The main thing to clarify is how the NewConnectionLimit applies to streams of a multiplexed transport. We could look at having a limit of connections per endpoint in a group from a listener.
Add a property to section 7.1.
Also make sure to have an early section being very explicit about the overall interaction model.
In section 4.1, we could add an example for explicit group management via clone, etc.
Sigh, I will never self-assign an issue again before its discussion :-) but it's ok... I'll do it

Discussion:
4.1.1. This is an example of how an application might listen for incoming <del> Connections using the Transport Services Interface, receive a </del> <ins> Connections using the Transport Services Interface, and receive a </ins> request, and send a response. 4.1.2. <del> 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. </del> <ins> This is an example of how an application might open two Connections to a remote application using the Transport Services Interface, and send a request as well as receive a response on each of them. </ins> 4.1.3.

the remote peer.  This boolean becomes false when "Timeout for aborting Connection" (see conn-timeout) is used. <ins> 7.2.4. groupConnLimit Numeric (with special value "Unlimited") Unlimited This property controls the number of Connections that may arrive from a peer as new members of the Connection's group.  Similar to SetNewConnectionLimit(), this limits the number of ConnectionReceived Events that will occur, but constrained to the group of the Connection associated with this property.  In case of a multi- streaming transport, this takes the role of a limit on the number of allowed streams. </ins> 7.3. During the lifetime of a connection there are events that can occur
Change:
I would reword this text in §5.1: such that the tradeoff is listed in a (new) privacy considerations section, leaving the description of the reduced connection setup latency in early binding here as a functional justification.
LGTM (note: accept 1 nit fix before pressing Merge)

Discussion:
The transport services API resolves names internally, when the Initiate(), Listen(), or Rendezvous() method is called to establish a <del> Connection.  The API explicitly does not require the application to resolve names, though there is a tradeoff between early and late binding of addresses to names.  Early binding allows the API implementation to reduce connection setup latency, at the cost of potentially limited scope for alternate path discovery during Connection establishment, as well as potential additional information leakage about application interest when used with a resolution method (such as DNS without TLS) which does not protect query confidentiality. </del> <ins> Connection.  Privacy considerations for the timing of this resolution are given in privacy-security. </ins> The Resolve() action on Preconnection can be used by the application to force early binding when required, for example with some Network

and fallback or re-establishment is supported in the transport system. <ins> The interface explicitly does not require the application to resolve names, though there is a tradeoff between early and late binding of addresses to names.  Early binding allows the API implementation to reduce connection setup latency, at the cost of potentially limited scope for alternate path discovery during Connection establishment, as well as potential additional information leakage about application interest when used with a resolution method (such as DNS without TLS) which does not protect query confidentiality. </ins> These communication activities are not different from what is used today.  However, the goal of a TAPS transport system is to support such mechanisms as a generic service within the transport layer.
Change:
says: What happens if a ReceivedPartial event is dispatched on an unreliably connection, but the rest of the message never shows up? Is it the case that another call to Receive will result in two events being sent: Received (or ReceivedPartial) for the new message, and a ReceiveError for the original message? Or can two messages effectively be interleaved and delivered in whatever order the constituent packets arrive?
Could you elaborate on the error case that's on your mind? Because it's unclear to me - I would say that ordering obviously needs to be preserved within a message, while inter-message ordering is a different issue (controlled by the msgOrdered Message Parameter). How is this not clear from saying that delivering discontiguous partial Messages is not supported?
Let's say you send the following: M1 M2 M3 N1 N2 N3 where M=M1.M2.M3 is one message and N=N1.N2.N3 is another message. The receiver subsequently gets: M1 N1 N2 N3 My reading of the draft is that the receiver will see ReceivedPartial ReceivedPartial ReceivedPartial Received If M2 and M3 subsequently arrive, it sounds like the receiver will never get ReceivedPartial or Received because "this event does not support delivering discontiguous partial Messages." But what makes the receiving TAPS logic decide not to wait for M2 or M3 and to start delivering N?
This is not how I would have interpreted the sentence. It talks about the message itself being discontiguous - so, e.g., delivering M1 followed by M3 would never happen. I don't see a reason why a different message couldn't be delivered, in pieces or not, after a ReceivedPartial call - every receive call comes with a message context, so the messages can be separated. I can try to make this clearer, maybe by adding an example like yours here to the draft....

Discussion:
Message by passing the same MessageContext, until the endOfMessage flag is delivered or a ReceiveError occurs.  All partial blocks of a single Message are delivered in order without gaps.  This event does <del> not support delivering discontiguous partial Messages. </del> <ins> not support delivering discontiguous partial Messages.  If, for example, Message A is divided into three pieces (A1, A2, A3) and Message B is divided into three pieces (B1, B2, B3), the ReceivedPartial may deliver them in a sequence like this: A1, B1, B2, A2, A3, B3, because the messageContext allows the application to identify the pieces as belonging to Message A and B, respectively. However, a sequence like: A1, A3 will never occur. </ins> If the minIncompleteLength in the Receive request was set to be infinite (indicating a request to receive only complete Messages),
Change:
… and move the group limit connection property to the right place (it was misplaced). Note that section 8.2.7 ("Priority in TAPS") already clarifies that a Connection Priority choice doesn't guarantee a certain outcome; this just adds another sentence in the paragraph describing the Connection property to make it clearer (less easy to miss).
Looks ready to merge to me.

Discussion:
Group.  As noted in groups, this property is not entangled when Connections are cloned, i.e., changing the Priority on one Connection in a Connection Group does not change it on the other Connections in <del> the same Connection Group.  See priority-in-taps. </del> <ins> the same Connection Group.  No guarantees of a specific behavior regarding Connection Priority are given; a transport system may ignore this property.  See priority-in-taps for more details. </ins> 7.1.3.

7.1.9. <ins> groupConnLimit Numeric (with special value "Unlimited") Unlimited This property controls the number of Connections that can be accepted from a peer as new members of the Connection's group.  Similar to SetNewConnectionLimit(), this limits the number of ConnectionReceived Events that will occur, but constrained to the group of the Connection associated with this property.  For a multi-streaming transport, this limits the number of allowed streams. 7.1.10. </ins> The following generic Connection Properties are read-only, i.e. they cannot be changed by an application. <del> 7.1.9.1. </del> <ins> 7.1.10.1. </ins> zeroRttMsgMaxLen

before or during Connection establishment, see also msg- safelyreplayable.  It is given in Bytes. <del> 7.1.9.2. </del> <ins> 7.1.10.2. </ins> singularTransmissionMsgMaxLen

Packet Size (MPS) as described in Datagram PLPMTUD I-D.ietf-tsvwg- datagram-plpmtud. <del> 7.1.9.3. </del> <ins> 7.1.10.3. </ins> sendMsgMaxLen

This property represents the maximum Message size that an application can send. <del> 7.1.9.4. </del> <ins> 7.1.10.4. </ins> recvMsgMaxLen

the remote peer.  This boolean becomes false when "Timeout for aborting Connection" (see conn-timeout) is used. <del> 7.2.4. groupConnLimit Numeric (with special value "Unlimited") Unlimited This property controls the number of Connections that may arrive from a peer as new members of the Connection's group.  Similar to SetNewConnectionLimit(), this limits the number of ConnectionReceived Events that will occur, but constrained to the group of the Connection associated with this property.  In case of a multi- streaming transport, this takes the role of a limit on the number of allowed streams. </del> 7.3. During the lifetime of a connection there are events that can occur
Change:
My first try to make a PR from the web interface. Maybe this compiles without problems?
Aha, the error appears even when doing it over the web interface.
I think I am missing something ... how do endpoints know a route exists (is present)? My thinking from NEAT was that endpoints only knew this was established when there was some "confirmation" from the remote endpoint. Do you mean something else?
NAME this is for UDP, nothing is sent to the other end until the application sends data. it was the same in neat, our open call in neat just returned immediately for UDP.
True - for UDP, as you say, you basically know the Interface is up (and often not much more), but the words "established" sounds more like what happened when you get the first packet back... Maybe I could live with this, but it doesn't immediately inspire the right sense...
Yes, "connectivity is established" is not good at all, this is why I said the proposed update made it worse :) Or you mean that "local port reservations has been established" also triggers the wrong idea because of "established"? How about "... any necessary state like local port reservations is available/has been allocated." Or just remove that part all together.
In Sec 4.5 of taps-impl: "An implementation should consider such a protocol stack to be established as soon as a local route to the peer endpoint is confirmed." What does this mean for an unconnected protocol? That there is an entry in the route table, or that it's received a packet?
Good catch: This appears to be rough sentence. The term "confirmed" occurs only once, and a "local route" is something quite different to what is intended! We do talk about establishing connectivity with a remote endpoint... maybe that might work?

Discussion:
attempts in parallel, "unconnected" protocols such as raw UDP do not offer a way to validate the presence of a peer or the usability of a Connection without application feedback.  An implementation should <del> consider such a protocol stack to be established as soon as a local route to the peer endpoint is confirmed. </del> <ins> consider such a protocol stack to be established as soon as the Transport Services system has selected a path on which to send data. </ins> However, if a peer is not reachable over the network using the unconnected protocol, or data cannot be exchanged for any other
Change:
The implementation draft should explain that a framer can go into a passthrough/inactive mode once it has finished (like SOCKS, STARTTLS, CONNECT).

Discussion:
Before an implementation marks a Message Framer as ready, it can also dynamically add a protocol or framer above it in the stack.  This <del> allows protocols like STARTTLS, that need to add TLS conditionally, to modify the Protocol Stack based on a handshake result. </del> <ins> allows protocols that need to add TLS conditionally, like STARTTLS RFC3207, to modify the Protocol Stack based on a handshake result. A Message Framer might also choose to go into a passthrough mode once an initial exchange or handshake has been completed, such as the STARTTLS case mentioned above.  This can also be useful for proxy protocols like SOCKS RFC1928 or HTTP CONNECT RFC7230.  In such cases, a Message Framer implementation can intercept sending and receiving of messages at first, but then indicate that no more processing is needed. </ins> 6.2.