jiebi/CodeConvo huggingface dataset:
6.3. <del> This is the case for delay-based congestion controls.  The interaction between delay-based congestion controls and the delay induced by a coding mechanisms is an open research activity.  That being said, a potential approach would be that loss-based congestion control ignores the "repaired packet" signal. </del> <ins> [MICHAEL: as above, also here, the signals are discussed as going into both blocks, leading to a strange unification of things that shouldn't be together.  Let's remove this.  Also, the idea of ignoring packet loss for CC is appalling anyway.]  This is the case for delay-based congestion controls.  The interaction between delay- based congestion controls and the delay induced by a coding mechanisms is an open research activity.  That being said, a potential approach would be that loss-based congestion control ignores the "repaired packet" signal. </ins> The advantage of this solution is that coding would provided substantial benefits in cases where there are transmission losses.
7. <del> This section provides a summary on the content in previous sections. The fig:summary sums up some recommendations.  It is worth pointing out that the "coding without congestion" considers that coded packets are sent along with original data packets, in opposition with the solution where coded packets are transmitted only when there is no more original packets to transmit.  Moreover, the values indicated in this Figure consider a channel that does not exhibit a high loss pattern. </del> <ins> [MICHAEL: I'm sorry to say that I find this table to be in the same style, of wrongly mixing things together, and would like to see it removed altogether.]  This section provides a summary on the content in previous sections.  The fig:summary sums up some recommendations. It is worth pointing out that the "coding without congestion" considers that coded packets are sent along with original data packets, in opposition with the solution where coded packets are transmitted only when there is no more original packets to transmit. Moreover, the values indicated in this Figure consider a channel that does not exhibit a high loss pattern. </ins> 8.
5.4. <del> frames implicitly create a stream and carry stream data.  The Type field in the frame takes the form 0b00001XXX (or the set of values from 0x08 to 0x0f) to maximize compatibility with QUIC.  However, unlike QUIC, there are only one bit used to determine the fields that are present in the frame: The FIN bit (0x01) indicates that the frame marks the end of the stream.  The final size of the stream is the sum of the length, in bytes, of all data previously sent on this stream and the length of this frame without the length of the Stream ID. </del> <ins> frames implicitly create a stream and carry stream data. The Type field in the frame is either 0x0a or 0x0b.  This uses the same frame types as a QUIC STREAM frame with the OFF bit clear and the LEN bit set.  The FIN bit (0x01) in the frame type indicates that the frame marks the end of the stream in one direction.  Stream data consists of any number of 0x0a frames followed by a terminal 0x0b frame. frames contain the following fields: The stream ID for the stream. Zero or more bytes of data for the stream.  Empty frames MUST NOT be used unless they open or close a stream; an endpoint MAY treat an empty frame that neither starts nor ends a stream as a session error. </ins> 5.5.
ClientHello, MUST contain the ConnectionId structure.  This structure contains the CID value the client wishes the server to use when sending messages to the client.  A zero-length CID value indicates <del> that the client is prepared to send with a CID but does not wish the </del> <ins> that the client is prepared to send using a CID but does not wish the </ins> server to use one when sending. A server willing to use CIDs will respond with a "connection_id" extension in the ServerHello, containing the CID it wishes the client to use when sending messages towards it.  A zero-length value <del> indicates that the server will send with the client's CID but does not wish the client to include a CID. </del> <ins> indicates that the server will send using the client's CID but does not wish the client to include a CID when sending. </ins> Because each party sends the value in the "connection_id" extension it wants to receive as a CID in encrypted records, it is possible for
publication, the early allocation will be deprecated in favor of this assignment. <ins> A new column "DTLS-Only" is added to the registry.  The valid entries are "Y" if the extension is only applicable to DTLS, "N" otherwise. All the pre-existing entries are given the value "N". </ins> Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document describes the behavior of this extension for DTLS 1.2 only; it is not
6. dtls-example2 shows an example exchange where a connection id is used <del> uni-directionally from the client to the server. </del> <ins> uni-directionally from the client to the server.  To indicate that a connection_id has zero length we use the term 'connection_id=empty'. Note: In the example exchange the CID is included in the record layer once encryption is enabled.  In DTLS 1.2 only one handshake message is encrypted, namely the Finished message.  Since the example shows how to use the CID for payloads sent from the client to the server only the record layer payload containing the Finished messagen contains a CID.  Application data payloads sent from the client to the server contain a CID in this example as well. </ins> 7.
10. <ins> [[to-be-removed: RFC Editor: please replace RFCthis with this RFC number and remove this note.]] 10.1. </ins> IANA is requested to allocate an entry to the TLS "ContentType" registry, for the "return_routability_check(TBD2)" message defined in this document.  The "return_routability_check" content type is only applicable to DTLS 1.2 and 1.3. <ins> 10.2. </ins> IANA is requested to allocate the extension code point (TBD1) for the "rrc" extension to the "TLS ExtensionType Values" registry as described in tbl-ext. <ins> 10.3. IANA is requested to create a new sub-registry for RRC Message Types in the TLS Parameters registry IANA.tls-parameters, with the policy "expert review" RFC8126. Each entry in the registry must include: The initial state of this sub-registry is as follows: </ins> 11. Issues against this document are tracked at https://github.com/tlswg/
those datagrams are cryptographically authenticated).  On-path adversaries can, in general, pose a harm to connectivity. <ins> When using DTLS 1.3, peers SHOULD avoid using the same CID on multiple network paths, in particular when initiating connection migration or when probing a new network path, as described in path- validation, as an adversary can otherwise correlate the communication interaction across those different paths.  DTLS 1.3 provides mechanisms to ensure that a new CID can always be used.  In general, an endpoint should proactively send a RequestConnectionId message to ask for new CIDs as soon as the pool of spare CIDs is depleted (or goes below a threshold).  Also, in case a peer might have exhausted available CIDs, a migrating endpoint could include NewConnectionId in packets sent on the new path to make sure that the subsequent path validation can use fresh CIDs. Note that DTLS 1.2 does not offer the ability to request new CIDs during the session lifetime since CIDs have the same life-span of the connection.  Therefore, deployments that use DTLS in multihoming environments SHOULD refuse to use CIDs with DTLS 1.2 and switch to DTLS 1.3 if the correlation privacy threat is a concern. </ins> 10. [[to-be-removed: RFC Editor: please replace RFCthis with this RFC
active path, implementations SHOULD use T = 3xRTT. If an implementation has no way to obtain information regarding the <del> RTT of the active path, a value of 1s SHOULD be used. </del> <ins> RTT of the active path, T SHOULD be set to 1s. </ins> Profiles for specific deployment environments - for example, constrained networks I-D.ietf-uta-tls13-iot-profile - MAY specify a
Handshake messages are potentially larger than any given datagram, thus creating the problem of IP fragmentation. <del> Datagram transport protocols, like UDP, are more vulnerable to denial of service attacks and require a return-routability check with the help of cookies to be integrated into the handshake.  A detailed discussion of countermeasures can be found in dos. </del> <ins> Datagram transport protocols, like UDP, are susceptible to abusive behavior effecting denial of service attacks against nonparticipants, and require a return-routability check with the help of cookies to be integrated into the handshake.  A detailed discussion of countermeasures can be found in dos. </ins> 3.1.
error.  Note that if DTLS is run over UDP, then any implementation which does this will be extremely susceptible to denial-of-service (DoS) attacks because UDP forgery is so easy.  Thus, this practice is <del> NOT RECOMMENDED for such transports. </del> <ins> NOT RECOMMENDED for such transports, both to increase the reliability of DTLS service and to avoid the risk of spoofing attacks sending traffic to unrelated third parties. </ins> If DTLS is being carried over a transport that is resistant to forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts
datagram.  Omitting the length field MUST only be used for the last record in a datagram. <del> Implementations which send multiple records in the same datagram SHOULD omit the connection id from all but the first record; receiving implementations MUST assume that any subsequent records without connection IDs belong to the same association.  Sending implementations MUST NOT mix records from multiple DTLS associations in the same datagram.  If the second or later record has a connection ID which does not correspond to the same association used for previous records, the rest of the datagram MUST be discarded. </del> <ins> If a connection ID is negotiated, then it MUST be contained in all datagrams.  Sending implementations MUST NOT mix records from multiple DTLS associations in the same datagram.  If the second or later record has a connection ID which does not correspond to the same association used for previous records, the rest of the datagram MUST be discarded. </ins> When expanded, the epoch and sequence number can be combined into an unpacked RecordNumber structure, as shown below:
5.7.3. <ins> DTLS does not have any built-in congestion control or rate control; in general this is not an issue because messages tend to be small. However, in principle, some messages - especially Certificate - can be quite large.  If all the messages in a large flight are sent at once, this can result in network congestion.  A better strategy is to send out only part of the flight, sending more when messages are acknowledged.  DTLS offers a number of mechanisms for minimizing the size of the certificate message, including the cached information extension RFC7924 and certificate compression RFC8879. 5.7.4. </ins> DTLS 1.3 makes use of the following categories of post-handshake messages:
The basic design philosophy of DTLS is to construct "TLS over datagram transport".  Datagram transport does not require nor provide reliable or in-order delivery of data.  The DTLS protocol preserves <del> this property for application data.  Applications such as media </del> <ins> this property for application data.  Applications, such as media </ins> streaming, Internet telephony, and online gaming use datagram transport for communication due to the delay-sensitive nature of transported data.  The behavior of such applications is unchanged when the DTLS protocol is used to secure communication, since the DTLS protocol does not compensate for lost or reordered data traffic. <ins> Note that while low-latency streaming and gaming use DTLS to protect data (e.g. for protection of a WebRTC data channel), telephony utilizes DTLS for key establishment, and Secure Real-time Transport Protocol (SRTP) for protection of data RFC5763. </ins> TLS cannot be used directly in datagram environments for the following five reasons:
DTLS record MUST fit within a single datagram.  In order to avoid IP fragmentation, clients of the DTLS record layer SHOULD attempt to size records so that they fit within any PMTU estimates obtained from <del> the record layer. </del> <ins> the record layer.  For more information about PMTU issues see pmtu- issues. </ins> Multiple DTLS records MAY be placed in a single datagram.  Records are encoded consecutively.  The length field from DTLS records
probes the implementation to see how it responds to various types of error.  Note that if DTLS is run over UDP, then any implementation which does this will be extremely susceptible to denial-of-service <del> (DoS) attacks because UDP forgery is so easy.  Thus, this practice is NOT RECOMMENDED for such transports, both to increase the reliability of DTLS service and to avoid the risk of spoofing attacks sending traffic to unrelated third parties. </del> <ins> (DoS) attacks because UDP forgery is so easy.  Thus, the practice of generating fatal alerts is NOT RECOMMENDED for such transports, both to increase the reliability of DTLS service and to avoid the risk of spoofing attacks sending traffic to unrelated third parties. </ins> If DTLS is being carried over a transport that is resistant to forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts
5.8.2. <del> Though timer values are the choice of the implementation, mishandling of the timer can lead to serious congestion problems, for example if many instances of a DTLS time out early and retransmit too quickly on a congested link.  Implementations SHOULD use an initial timer value of 100 msec (the minimum defined in RFC 6298 RFC6298) and double the value at each retransmission, up to no less than 60 seconds (the RFC 6298 maximum).  Application specific profiles, such as those used for the Internet of Things environment, may recommend longer timer values.  Note that a 100 msec timer is recommended rather than the 3-second RFC 6298 default in order to improve latency for time- sensitive applications.  Because DTLS only uses retransmission for handshake and not dataflow, the effect on congestion should be minimal. </del> <ins> The configuration of timer settings varies with implementations and certain deployment environments require timer value adjustments. Mishandling of the timer can lead to serious congestion problems, for example if many instances of a DTLS time out early and retransmit too quickly on a congested link.  Implementations SHOULD use an initial timer value of 100 msec (the minimum defined in RFC 6298 RFC6298) and double the value at each retransmission, up to no less than 60 seconds (the RFC 6298 maximum).  Application specific profiles, such as those used for the Internet of Things environment, may recommend longer timer values.  Note that a 100 msec timer is recommended rather than the 3-second RFC 6298 default in order to improve latency for time-sensitive applications.  Because DTLS only uses retransmission for handshake and not dataflow, the effect on congestion should be minimal. </ins> Implementations SHOULD retain the current timer value until a message is transmitted and acknowledged without having to be retransmitted,
be quite large.  If all the messages in a large flight are sent at once, this can result in network congestion.  A better strategy is to send out only part of the flight, sending more when messages are <del> acknowledged.  DTLS offers a number of mechanisms for minimizing the size of the certificate message, including the cached information extension RFC7924 and certificate compression RFC8879. </del> <ins> acknowledged.  Several extensions have been standardized to reduce the size of the certificate message, for example the cached information extension RFC7924, certificate compression RFC8879 and RFC6066, which defines the "client_certificate_url" extension allowing DTLS clients to send a sequence of Uniform Resource Locators (URLs) instead of the client certificate. </ins> 5.8.4.
retransmissions.  Note that the client sends an empty ACK message because it can only acknowledge Record 1 sent by the server once it has processed messages in Record 0 needed to establish epoch 2 keys, <del> which are needed to encrypt to decrypt messages found in Record 1. </del> <ins> which are needed to encrypt or decrypt messages found in Record 1. </ins> ack-msg provides the necessary background details for this interaction.
peer will retransmit in any case and therefore the ACK just allows for selective retransmission, as opposed to the whole flight retransmission in previous versions of DTLS.  For instance in the <del> flow shown in Figure 11 if the client does not send the ACK message when it received record 1 indicating loss of record 0, the entire flight would be retransmitted.  When DTLS 1.3 is used in deployments with lossy networks, such as low-power, long range radio networks as well as low-power mesh networks, the use of ACKs is recommended. </del> <ins> flow shown in dtls-key-update if the client does not send the ACK message when it received record 1 indicating loss of record 0, the entire flight would be retransmitted.  When DTLS 1.3 is used in deployments with lossy networks, such as low-power, long range radio networks as well as low-power mesh networks, the use of ACKs is recommended. </ins> The use of the ACK for the second case is mandatory for the proper functioning of the protocol.  For instance, the ACK message sent by the client in Figure 13, acknowledges receipt and processing of record 4 (containing the NewSessionTicket message) and if it is not sent the server will continue retransmission of the NewSessionTicket <del> indefinitely until its transmission cap is reached. </del> <ins> indefinitely until its maximum retransmission timemout value is reached. </ins> 8.
sequence number fields in the DTLSCiphertext structure have been reduced from those in previous versions. <ins> The DTLS epoch serialized in DTLSPlaintext is 2 octets long for compatibility with DTLS 1.2.  However, this value is set as the least significant 2 octets of the connection epoch, which is an 8 octet counter incremented on every KeyUpdate.  See seq-and-epoch for details.  The sequence number is set to be the low order 48 bits of the 64 bit sequence number.  Plaintext records MUST NOT be sent with sequence numbers that would exceed 2^48-1, so the upper 16 bits will always be 0. </ins> The DTLSCiphertext structure has a variable length header. DTLSPlaintext records are used to send unprotected records and
When expanded, the epoch and sequence number can be combined into an unpacked RecordNumber structure, as shown below: <del> This 64-bit value is used in the ACK message as well as in the "record_sequence_number" input to the AEAD function. </del> <ins> This 128-bit value is used in the ACK message. </ins> The entire header value shown in hdr_examples (but prior to record number encryption, see rne) is used as as the additional data value for the AEAD function.  For instance, if the minimal variant is used, the AAD is 2 octets long.  Note that this design is different from the additional data calculation for DTLS 1.2 and for DTLS 1.2 with <del> Connection ID. </del> <ins> Connection ID.  In DTLS 1.3 the 64-bit sequence_number is used as the sequence number for the AEAD computation; unlike DTLS 1.2, the epoch is not included. </ins> 4.1.
Implementations MUST either abandon an association or re-key prior to allowing the sequence number to wrap. <del> Implementations MUST NOT allow the epoch to wrap, but instead MUST establish a new association, terminating the old association. </del> 4.2.2. When receiving protected DTLS records, the recipient does not have a full epoch or sequence number value in the record and so there is <del> some opportunity for ambiguity.  Because the full epoch and sequence number are used to compute the per-record nonce, failure to reconstruct these values leads to failure to deprotect the record, and so implementations MAY use a mechanism of their choice to determine the full values.  This section provides an algorithm which is comparatively simple and which implementations are RECOMMENDED to follow. </del> <ins> some opportunity for ambiguity.  Because the full sequence number is used to compute the per-record nonce and the epoch determines the keys, failure to reconstruct these values leads to failure to deprotect the record, and so implementations MAY use a mechanism of their choice to determine the full values.  This section provides an algorithm which is comparatively simple and which implementations are RECOMMENDED to follow. </ins> If the epoch bits match those of the current epoch, then implementations SHOULD reconstruct the sequence number by computing
include handshake messages, such as post-handshake messages (e.g., a NewSessionTicket message). <del> epoch value (4 to 2^16-1) is used for payloads protected using </del> <ins> epoch value (4 to 2^64-1) is used for payloads protected using </ins> keys from the [sender]_application_traffic_secret_N (N>0). Using these reserved epoch values a receiver knows what cipher state
successful ACK processing updates the keys of the KeyUpdate message sender, which is reflected in the change of epoch values. <ins> With a 128-bit key as in AES-256, rekeying 2^64 times has a high probability of key reuse within a given connection.  Note that even if the key repeats, the IV is also independently generated.  In order to provide an extra margin of security, sending implementations MUST NOT allow the epoch to exceed 2^48-1.  In order to allow this value to be changed later, receiving implementations MUST NOT enforce this rule.  If a sending implementation receives a KeyUpdate with request_update set to "update_requested", it MUST NOT send its own KeyUpdate if that would cause it to exceed these limits. </ins> 9. If the client and server have negotiated the "connection_id"
the "TLS Alerts" registry with value 52. IANA is requested to allocate two values in the "TLS Handshake Type" <del> registry, defined in TLS13, for RequestConnectionId (TBD), and NewConnectionId (TBD), as defined in this document.  The value for </del> <ins> registry, defined in TLS13, for request_connection_id (TBD), and new_connection_id (TBD), as defined in this document.  The value for </ins> the "DTLS-OK" columns are "Y". IANA is requested to add this RFC as a reference to the TLS Cipher
the connection establishment. With these exceptions, the DTLS message formats, flows, and logic are <del> the same as those of TLS 1.3. </del> <ins> the same as those of TLS 1.3.  DTLS implementations SHOULD not use the TLS 1.3 "compatibility mode" described in I-D.ietf-tls-tls13, Section D.4 and DTLS servers SHOULD ignore the "session_id" value generated by the client rather than sending ChangeCipherSpec messages.  Implementations MUST still ignore ChangeCipherSpec messages received during the handshake and at all other times SHOULD treat them as if they had failed to deprotect. </ins> 5.1.