jiebi/CodeConvo huggingface dataset:
multiple layers of derivation or resolution, such as DNS service resolution and DNS hostname resolution. <ins> For example, if the application has indicated both a preference for WiFi over LTE and for a feature only available in SCTP, branches will be first sorted accord to path selection, with WiFi at the top. Then, branches with SCTP will be sorted to the top within their subtree according to the properties influencing protocol selection. However, if the implementation has cached the information that SCTP is not available on the path over WiFi, there is no SCTP node in the WiFi subtree.  Here, the path over WiFi will be tried first, and, if connection establishment succeeds, TCP will be used.  So the Selection Property of preferring WiFi takes precedence over the Property that led to a preference for SCTP. </ins> 4.3. Implementations should sort the branches of the tree of connection
Local Endpoint is specified, the implementation should either use an ephemeral port or generate an error. <del> If the Path Selection Properties do not require a single network interface or path, but allow the use of multiple paths, the Listener object should register for incoming traffic on all of the network interfaces or paths that conform to the Path Selection Properties. The set of available paths can change over time, so the implementation should monitor network path changes and register and de-register the Listener across all usable paths.  When using multiple paths, the Listener is generally expected to use the same port for listening on each. If the Protocol Selection Properties allow multiple protocols to be used for listening, and the implementation supports it, the Listener object should register across the eligble protocols for each path. This means that inbound Connections delivered by the implementation may have heterogeneous protocol stacks. </del> <ins> If the Selection Properties do not require a single network interface or path, but allow the use of multiple paths, the Listener object should register for incoming traffic on all of the network interfaces or paths that conform to the Properties.  The set of available paths can change over time, so the implementation should monitor network path changes and register and de-register the Listener across all usable paths.  When using multiple paths, the Listener is generally expected to use the same port for listening on each. If the Selection Properties allow multiple protocols to be used for listening, and the implementation supports it, the Listener object should register across the eligble protocols for each path.  This means that inbound Connections delivered by the implementation may have heterogeneous protocol stacks. </ins> 4.8.1.
support removing a Message from its buffer, this property may be ignored. <del> Niceness: this represents the ability to de-prioritize a Message in favor of other Messages.  This can be implemented by the system re-ordering Messages that have yet to be handed to the Protocol Stack, or by giving relative priority hints to protocols that support priorities per Message.  For example, an implementation of HTTP/2 could choose to send Messages of different niceness on streams of different priority. </del> <ins> Priority: this represents the ability to prioritize a Message over other Messages.  This can be implemented by the system re-ordering Messages that have yet to be handed to the Protocol Stack, or by giving relative priority hints to protocols that support priorities per Message.  For example, an implementation of HTTP/2 could choose to send Messages of different Priority on streams of different priority. </ins> Ordered: when this is false, it disables the requirement of in- order-delivery for protocols that support configurable ordering.
as a result of racing multiple transports or as part of TCP Fast Open. <ins> Final: when this is true, it means that a transport connection can be closed immediately after its transmission. </ins> Corruption Protection Length: when this is set to any value other than -1, it limits the required checksum in protocols that allow limiting the checksum length (e.g.  UDP-Lite). <del> Immediate Acknowledgement: this informs the implementation that the sender intends to execute tight control over the send buffer, and therefore wants to avoid delayed acknowledgements.  In case of SCTP, a request to immediately send acknowledgements can be implemented using the "sack-immediately flag" described in Section 4.2 of RFC8303 for the SEND.SCTP primitive. Instantaneous Capacity Profile: when this is set to "Interactive/ Low Latency", the Message should be sent immediately, even when this comes at the cost of using the network capacity less efficiently.  For example, small messages can sometimes be bundled to fit into a single data packet for the sake of reducing header overhead; such bundling should not be used.  For example, in case of TCP, the Nagle algorithm should be disabled when Interactive/ Low Latency is selected as the capacity profile.  Scavenger/Bulk can translate into usage of a congestion control mechanism such as LEDBAT, and/or the capacity profile can lead to a choice of a DSCP value as described in I-D.ietf-taps-minset). [Note: See also send-params-non-consensus for additional Send Parameters under discussion.] </del> <ins> Transmission Profile: TBD - because it's not final in the API yet. Old text follows: when this is set to "Interactive/Low Latency", the Message should be sent immediately, even when this comes at the cost of using the network capacity less efficiently.  For example, small messages can sometimes be bundled to fit into a single data packet for the sake of reducing header overhead; such bundling should not be used.  For example, in case of TCP, the Nagle algorithm should be disabled when Interactive/Low Latency is selected as the capacity profile.  Scavenger/Bulk can translate into usage of a congestion control mechanism such as LEDBAT, and/ or the capacity profile can lead to a choice of a DSCP value as described in I-D.ietf-taps-minset). Singular Transmission: when this is true, the application requests to avoid transport-layer segmentation or network-layer fragmentation.  Some transports implement network-layer fragmentation avoidance (Path MTU Discovery) without exposing this functionality to the application; in this case, only transport- layer segmentation should be avoided, by fitting the message into a single transport-layer segment or otherwise failing.  Otherwise, network-layer fragmentation should be avoided--e.g. by requesting the IP Don't Fragment bit to be set in case of UDP(-Lite) and IPv4 (SET_DF in RFC8304). </ins> 5.1.1.2.
6.1. <del> Appendix A.1 of I-D.ietf-taps-minset explains, using primitives that are described in RFC8303 and RFC8304, how to implement changing the following protocol properties of an established connection with TCP and UDP.  Below, we amend this description for other protocols (if applicable): </del> <ins> Appendix A.1 of I-D.ietf-taps-minset explains, using primitives from RFC8303 and RFC8304, how to implement changing some of the following protocol properties of an established connection with TCP and UDP. Below, we amend this description for other protocols (if applicable) and extend it with Connection Properties that are not contained in I- D.ietf-taps-minset. </ins> <del> Relative niceness: for SCTP, this can be done using the primitive CONFIGURE_STREAM_SCHEDULER.SCTP described in section 4 of RFC8303. Timeout for aborting Connection: for SCTP, this can be done using the primitive CHANGE_TIMEOUT.SCTP described in section 4 of RFC8303. Abort timeout to suggest to the Remote Endpoint: for TCP, this can be done using the primitive CHANGE_TIMEOUT.TCP described in section 4 of RFC8303. </del> <ins> Notification of excessive retransmissions: TODO </ins> Retransmission threshold before excessive retransmission <del> notification: for TCP, this can be done using ERROR.TCP described in section 4 of RFC8303. </del> <ins> notification: TODO; for TCP, this can be done using ERROR.TCP described in section 4 of RFC8303. Notification of ICMP soft error message arrival: TODO </ins> Required minimum coverage of the checksum for receiving: for UDP- Lite, this can be done using the primitive SET_MIN_CHECKSUM_COVERAGE.UDP-Lite described in section 4 of RFC8303. <ins> Priority (Connection): TODO; for SCTP, this can be done using the primitive CONFIGURE_STREAM_SCHEDULER.SCTP described in section 4 of RFC8303. Timeout for aborting Connection: for SCTP, this can be done using the primitive CHANGE_TIMEOUT.SCTP described in section 4 of RFC8303. </ins> Connection group transmission scheduler: for SCTP, this can be done using the primitive SET_STREAM_SCHEDULER.SCTP described in section 4 of RFC8303. <ins> Maximum message size concurrent with Connection establishment: TODO Maximum Message size before fragmentation or segmentation: TODO Maximum Message size on send: TODO Maximum Message size on receive: TODO Capacity Profile: TODO Bounds on Send or Receive Rate: TODO TCP-specific Property: User Timeout: for TCP, this can be configured using the primitive CHANGE_TIMEOUT.TCP described in section 4 of RFC8303. </ins> It may happen that the application attempts to set a Protocol Property which does not apply to the actually chosen protocol.  In this case, the implementation should fail gracefully, i.e., it may
If the Protocol Stack includes a transport protocol that supports multipath connectivity, an update to the available paths should inform the Protocol Instance of the new set of paths that are <del> permissible based on the Path Selection Properties passed by the </del> <ins> permissible based on the Selection Properties passed by the </ins> application.  A multipath protocol can establish new subflows over new paths, and should tear down subflows over paths that are no longer available.  If the Protocol Stack includes a transport
Many application programming interfaces (APIs) to perform transport networking have been deployed, perhaps the most widely known and <del> imitated being the BSD socket() POSIX interface.  The naming of objects and functions across these APIs is not consistent, and varies </del> <ins> imitated being the BSD Socket POSIX interface.  The naming of objects and functions across these APIs is not consistent, and varies </ins> depending on the protocol being used.  For example, sending and receiving streams of data is conceptually the same for both an unencrypted Transmission Control Protocol (TCP) stream and operating on an encrypted Transport Layer Security (TLS) RFC8446 stream over <del> TCP, but applications cannot use the same socket send() and recv() calls on top of both kinds of connections.  Similarly, terminology for the implementation of transport protocols varies based on the context of the protocols themselves: terms such as "flow", "stream", "message", and "connection" can take on many different meanings. This variety can lead to confusion when trying to understand the similarities and differences between protocols, and how applications can use them effectively. </del> <ins> TCP, but applications cannot use the same socket "send()" and "recv()" calls on top of both kinds of connections.  Similarly, terminology for the implementation of transport protocols varies based on the context of the protocols themselves: terms such as "flow", "stream", "message", and "connection" can take on many different meanings.  This variety can lead to confusion when trying to understand the similarities and differences between protocols, and how applications can use them effectively. </ins> The goal of the Transport Services architecture is to provide a common, flexible, and reusable interface for transport protocols.  As
The traditional model of using sockets for networking can be represented as follows: <del> Applications create connections and transfer data using the socket </del> <ins> Applications create connections and transfer data using the Socket </ins> API. <del> The socket API provides the interface to the implementations of </del> <ins> The Socket API provides the interface to the implementations of </ins> TCP and UDP (typically implemented in the system's kernel). TCP and UDP in the kernel send and receive data over the available
its own, but needs a framing protocol on top to determine message boundaries. <del> Both stacks MUST offer the transport services that are required by the application.  For example, if an application specifies that it requires reliable transmission of data, then a Protocol Stack </del> <ins> Both stacks MUST offer the transport services that are requested by the application.  For example, if an application specifies that it requires reliable transmission of data, then a Protocol Stack </ins> using UDP without any reliability layer on top would not be allowed to replace a Protocol Stack using TCP.  However, if the application does not require reliability, then a Protocol Stack
implementation to communicate control data to the remote endpoint that can be used to parse Messages. <ins> Similarly, when a Message Framer generates a "Stop" event, the framer implementation has the opportunity to write some final data or clear up its local state before the "Closed" event is delivered to the Application.  The framer implementation can indicate that it has finished with this. </ins> At any time if the implementation encounters a fatal error, it can also cause the Connection to fail and provide an error. <ins> Should the framer implementation deem the candidate selected during racing unsuitable it can signal this by failing the Connection prior to marking it as ready.  If there are no other candidates available, the Connection will fail.  Otherwise, the Connection will select a different candidate and the Message Framer will generate a new "Start" event. </ins> Before an implementation marks a Message Framer as ready, it can also dynamically add a protocol or framer above it in the stack.  This allows protocols like STARTTLS, that need to add TLS conditionally,
Upon receiving this event, a framer implementation is responsible for performing any necessary transformations and sending the resulting <del> data to the next protocol.  Implementations SHOULD ensure that there is a way to pass the original data through without copying to improve </del> <ins> data back to the Message Framer, which will in turn send it to the next protocol.  Implementations SHOULD ensure that there is a way to pass the original data through without copying to improve </ins> performance. To provide an example, a simple protocol that adds a length as a
discard a header once the content has been parsed). To deliver a Message to the application, the framer implementation <del> can either directly deliever data that it has allocated, or deliver a </del> <ins> can either directly deliver data that it has allocated, or deliver a </ins> range of data directly from the underlying transport and <del> simulatenously advance the receive cursor. </del> <ins> simultaneously advance the receive cursor. </ins> Note that "MessageFramer.DeliverAndAdvanceReceiveCursor" allows the framer implementation to earmark bytes as part of a Message even
A specialized feature could be required by an application only when using a specific protocol, and not when using others.  For example, <del> if an application is using UDP, it could require control over the checksum or fragmentation behavior for UDP; if it used a protocol to frame its data over a byte stream like TCP, it would not need these options.  In such cases, the API ought to expose the features in such a way that they take effect when a particular protocol is selected, but do not imply that only that protocol could be used.  For example, if the API allows an application to specify a preference to use a partial checksum, communication would not fail when a protocol such as TCP is selected, which uses a checksum covering the entire payload. </del> <ins> if an application is using TCP, it could require control over the User Timeout Option for TCP; these options would not take effect for other transport protocols.  In such cases, the API ought to expose the features in such a way that they take effect when a particular protocol is selected, but do not imply that only that protocol could be used.  For example, if the API allows an application to specify a preference to use the User Timeout Option, communication would not fail when a protocol such as QUIC is selected. </ins> Other specialized features, however, could be strictly required by an application and thus constrain the set of protocols that can be used.
Connection Properties: The Connection Properties are used to configure protocol-specific options and control per-connection behavior of the Transport Services system; for example, a <del> protocol-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 can be used in this way by an implementation during connection </del> <ins> protocol-specific Connection Property can express that if TCP is used, the implementation ought to use the User Timeout Option. 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 can be used in this way by an implementation during connection </ins> establishment.  Connection Properties are specified on a Preconnection prior to Connection establishment, and can be modified on the Connection later.  Changes made to Connection
will never show up when queuing the value of a preference - the effective preference must be returned instead. <del> Internally, the transport system will first exclude all protocols and paths that match a Prohibit, then exclude all protocols and paths that do not match a Require, then sort candidates according to </del> <ins> The implementation MUST ensure a consistent outcome given the same Selection Properties.  Internally, it MUST exclude all protocols and paths that match a Prohibit and exclude all protocols and paths that do not match a Require.  It MUST then sort candidates according to </ins> Preferred properties, and then use Avoided properties as a <del> tiebreaker.  Selection Properties that select paths take preference over those that select protocols.  For example, if an application indicates a preference for a specific path by specifying an interface, but also a preference for a protocol not available on this path, the transport system will try the path first, ignoring the protocol preference. </del> <ins> tiebreaker. Note that the protocols and paths which are available on a specific system may vary, such that application preferences may conflict with each other.  For example, if an application indicates a preference for a specific path by specifying an interface, but also a preference for a protocol, a situation might occur in which the preferred protocol is not available on the preferred path.  In such cases, implementations MUST ensure a deterministic outcome by prioritizing Selection Properties that select paths over those that select protocols.  Therefore, the transport system MUST try the path first, ignoring the protocol preference if the protocol does not work on the path. </ins> Selection and Connection Properties, as well as defaults for Message Properties, can be added to a Preconnection to configure the
protocols and paths without requiring major changes to the application. <del> design explains the design principles behind the Transport </del> <ins> requirements explains the fundamental requirements for a Transport </ins> Services API.  These principles are intended to make sure that transport protocols can continue to be enhanced and evolve without <del> requiring too many changes by application developers. </del> <ins> requiring significant changes by application developers. </ins> concepts presents the Transport Services architecture diagram and defines the concepts that are used by both the API and
D.ietf-taps-transport-security. As described above in equivalence, if a Transport Services system <del> races between two different Protocol Stacks, both SHOULD use the same security protocols and options.  However, a Transport Services system MAY race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. </del> <ins> races between two different Protocol Stacks, both need to use the same security protocols and options.  However, a Transport Services system can race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. </ins> Applications need to ensure that they use security APIs appropriately.  In cases where applications use an interface to
QUIC, and applications ought not to use private keys intended for server authentication as keys for client authentication. <del> Moreover, Transport Services systems MUST NOT automatically fall back </del> <ins> Moreover, Transport Services systems must not automatically fall back </ins> from secure protocols to insecure protocols, or to weaker versions of <del> secure protocols.  For example, if an application requests a specific version of TLS, but the desired version of TLS is not available, its connection will fail.  Applications are thus responsible for implementing security protocol fallback or version fallback by creating multiple Transport Services Connections, if so desired. Alternatively, a Transport Services system MAY allow applications to specify that fallback to a specific other version of a protocol is allowed. </del> <ins> secure protocols (see equivalence).  For example, if an application requests a specific version of TLS, but the desired version of TLS is not available, its connection will fail.  Applications are thus responsible for implementing security protocol fallback or version fallback by creating multiple Transport Services Connections, if so desired.  Alternatively, a Transport Services system MAY allow applications to specify that fallback to a specific other version of a protocol is allowed. </ins>
4.2.1. <del> Immediate, or simultaneous, racing should be avoided by implementations.  This approach can consume network resources and establish state that will not be used. </del> <ins> Immediate racing is when multiple alternate branches are started without waiting for any one branch to make progress before starting the next alternative.  This means the attempts are effectively simultaneous.  Immediate racing should be avoided by implementations, since it consumes extra network resources and establishes state that might not be used. </ins> 4.2.2.