jiebi/CodeConvo huggingface dataset:
Using a value for "N" that is small, but at least 1 (for example, 1.25) ensures that variations in round-trip time do not result in <del> under-utilization of the congestion window.  Values of 'N' larger than 1 ultimately result in sending packets as acknowledgments are received rather than when timers fire, provided the congestion window is fully utilized and acknowledgments arrive at regular intervals. </del> <ins> under-utilization of the congestion window. </ins> Practical considerations, such as packetization, scheduling delays, and computational efficiency, can cause a sender to deviate from this
If a path has been validated to support ECN (RFC3168, RFC8311), QUIC treats a Congestion Experienced (CE) codepoint in the IP header as a signal of congestion.  This document specifies an endpoint's response <del> when its peer receives packets with the ECN-CE codepoint. </del> <ins> when the peer-reported ECN-CE count increases; see Section 13.4.2 of QUIC-TRANSPORT. </ins> 7.2.
the congestion window. The minimum congestion window is the smallest value the congestion <del> window can decrease to as a response to loss, ECN-CE, or persistent congestion.  The RECOMMENDED value is 2 * max_datagram_size. </del> <ins> window can decrease to as a response to loss, increase in the peer- reported ECN-CE count, or persistent congestion.  The RECOMMENDED value is 2 * max_datagram_size. </ins> 7.3.
cause a sender to increase their send rate.  This increase could result in congestion and loss. <del> A sender MAY attempt to detect suppression of reports by marking occasional packets that they send with ECN-CE.  If a packet sent with ECN-CE is not reported as having been CE marked when the packet is acknowledged, then the sender SHOULD disable ECN for that path. </del> <ins> A sender can detect suppression of reports by marking occasional packets that it sends with an ECN-CE marking.  If a packet sent with an ECN-CE marking is not reported as having been CE marked when the packet is acknowledged, then the sender can disable ECN for that path by not setting ECT codepoints in subsequent packets sent on that path RFC3168. </ins> Reporting additional ECN-CE markings will cause a sender to reduce their sending rate, which is similar in effect to advertising reduced
14. <del> The QUIC packet size includes the QUIC header and protected payload, but not the UDP or IP headers. </del> <ins> A UDP datagram can include one or more QUIC packets.  The datagram size refers to the total UDP payload size of a single UDP datagram carrying QUIC packets.  The datagram size includes one or more QUIC packet headers and protected payloads, but not the UDP or IP headers. The maximum datagram size is defined as the largest size of UDP payload that can be sent across a network path using a single UDP datagram. </ins> QUIC depends upon a minimum IP packet size of at least 1280 bytes. This is the IPv6 minimum size (IPv6) and is also supported by most <del> modern IPv4 networks.  Assuming the minimum IP header size, this results in a QUIC maximum packet size of 1232 bytes for IPv6 and 1252 bytes for IPv4. </del> <ins> modern IPv4 networks.  Assuming the minimum IP header size of 40 bytes for IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this results in a maximum datagram size of 1232 bytes for IPv6 and 1252 bytes for IPv4. The maximum datagram size MUST be at least 1200 bytes. </ins> <del> The QUIC maximum packet size is the largest size of QUIC packet that can be sent across a network path using a single packet.  Any maximum packet size larger than 1200 bytes can be discovered using Path Maximum Transmission Unit Discovery (PMTUD; see pmtud) or Datagram Packetization Layer PMTU Discovery (DPLPMTUD; see dplpmtud). </del> <ins> Any maximum datagram size larger than 1200 bytes can be discovered using Path Maximum Transmission Unit Discovery (PMTUD; see pmtud) or Datagram Packetization Layer PMTU Discovery (DPLPMTUD; see dplpmtud). </ins> Enforcement of the max_udp_payload_size transport parameter (transport-parameter-definitions) might act as an additional limit on <del> the maximum packet size.  A sender can avoid exceeding this limit, </del> <ins> the maximum datagram size.  A sender can avoid exceeding this limit, </ins> once the value is known.  However, prior to learning the value of the transport parameter, endpoints risk datagrams being lost if they send <del> packets larger than the smallest allowed maximum packet size of 1200 bytes. </del> <ins> datagrams larger than the smallest allowed maximum datagram size of 1200 bytes. </ins> UDP datagrams MUST NOT be fragmented at the IP layer.  In IPv4 (IPv4), the DF bit MUST be set if possible, to prevent fragmentation
14.1. A client MUST expand the payload of all UDP datagrams carrying <del> Initial packets to at least the smallest allowed maximum packet size (1200 bytes) by adding PADDING frames to the Initial packet or by coalescing the Initial packet; see packet-coalesce.  Sending a UDP </del> <ins> Initial packets to at least the smallest allowed maximum datagram size (1200 bytes) by adding PADDING frames to the Initial packet or by coalescing the Initial packet; see packet-coalesce.  Sending a UDP </ins> datagram of this size ensures that the network path from the client to the server supports a reasonable Path Maximum Transmission Unit (PMTU).  This also helps reduce the amplitude of amplification
that it chooses. A server MUST discard an Initial packet that is carried in a UDP <del> datagram with a payload that is less than the smallest allowed maximum packet size of 1200 bytes.  A server MAY also immediately </del> <ins> datagram with a payload that is smaller than the smallest allowed maximum datagram size of 1200 bytes.  A server MAY also immediately </ins> close the connection by sending a CONNECTION_CLOSE frame with an error code of PROTOCOL_VIOLATION; see immediate-close-hs.
validation. An endpoint MUST NOT increase PMTU based on ICMP messages; see <del> Section 3, clause 6 of DPLPMTUD.  Any reduction in the QUIC maximum packet size in response to ICMP messages MAY be provisional until </del> <ins> Section 3, clause 6 of DPLPMTUD.  Any reduction in QUIC's maximum datagram size in response to ICMP messages MAY be provisional until </ins> QUIC's loss detection algorithm determines that the quoted packet has actually been lost.
PADDING frame implement "Probing using padding data", as defined in Section 4.1 of DPLPMTUD. <del> Endpoints SHOULD set the initial value of BASE_PMTU (see Section 5.1 of DPLPMTUD) to be consistent with the minimum QUIC packet size.  The MIN_PLPMTU is the same as the BASE_PMTU. </del> <ins> Endpoints SHOULD set the initial value of BASE_PLPMTU (Section 5.1 of DPLPMTUD) to be consistent with QUIC's smallest allowed maximum datagram size.  The MIN_PLPMTU is the same as the BASE_PLPMTU. </ins> <del> QUIC endpoints implementing DPLPMTUD maintain a maximum packet size (DPLPMTUD MPS) for each combination of local and remote IP addresses. </del> <ins> QUIC endpoints implementing DPLPMTUD maintain a DPLPMTUD Maximum Packet Size (MPS, Section 4.4 of DPLPMTUD) for each combination of local and remote IP addresses.  This corresponds to the maximum datagram size. </ins> 14.3.1. From the perspective of DPLPMTUD, QUIC is an acknowledged <del> packetization layer (PL).  A sender can therefore enter the DPLPMTUD BASE state when the QUIC connection handshake has been completed. </del> <ins> Packetization Layer (PL).  A QUIC sender can therefore enter the DPLPMTUD BASE state (Section 5.2 of DPLPMTUD) when the QUIC connection handshake has been completed. </ins> 14.3.2. <del> QUIC provides an acknowledged PL, therefore a sender does not implement the DPLPMTUD CONFIRMATION_TIMER while in the SEARCH_COMPLETE state; see Section 5.2 of DPLPMTUD. </del> <ins> QUIC is an acknowledged PL, therefore a QUIC sender does not implement a DPLPMTUD CONFIRMATION_TIMER while in the SEARCH_COMPLETE state; see Section 5.2 of DPLPMTUD. </ins> 14.3.3.
PMTU probes are ack-eliciting packets. Endpoints could limit the content of PMTU probes to PING and PADDING <del> frames as packets that are larger than the current maximum packet size are more likely to be dropped by the network.  Loss of a QUIC packet that is carried in a PMTU probe is therefore not a reliable indication of congestion and SHOULD NOT trigger a congestion control reaction; see Section 3, Bullet 7 of DPLPMTUD.  However, PMTU probes consume congestion window, which could delay subsequent transmission by an application. </del> <ins> frames, since packets that are larger than the current maximum datagram size are more likely to be dropped by the network.  Loss of a QUIC packet that is carried in a PMTU probe is therefore not a reliable indication of congestion and SHOULD NOT trigger a congestion control reaction; see Section 3, Bullet 7 of DPLPMTUD.  However, PMTU probes consume congestion window, which could delay subsequent transmission by an application. </ins> 14.4.1.
intermediary not acting as a tunnel) MUST NOT forward a malformed request or response.  Malformed requests or responses that are detected MUST be treated as a stream error (errors) of type <del> H3_GENERAL_PROTOCOL_ERROR. </del> <ins> H3_MESSAGE_ERROR. </ins> For malformed requests, a server MAY send an HTTP response indicating the error prior to closing or resetting the stream.  Clients MUST NOT
The payload of this packet contains CRYPTO frames and could contain PING, PADDING, or ACK frames.  Handshake packets MAY contain CONNECTION_CLOSE frames of type 0x1c.  Endpoints MUST treat receipt <del> of Handshake packets with other frames as a connection error. </del> <ins> of Handshake packets with other frames as a connection error of type PROTOCOL_VIOLATION. </ins> Like Initial packets (see discard-initial), data in CRYPTO frames for Handshake packets is discarded - and no longer retransmitted - when
control across the entire connection, QUIC has the capability to improve the performance of HTTP compared to a TCP mapping.  QUIC also incorporates TLS 1.3 (TLS13) at the transport layer, offering <del> comparable security to running TLS over TCP, with the improved connection setup latency of TCP Fast Open (TFO). </del> <ins> comparable confidentiality and integrity to running TLS over TCP, with the improved connection setup latency of TCP Fast Open (TFO). </ins> This document defines a mapping of HTTP semantics over the QUIC transport protocol, drawing heavily on the design of HTTP/2.  While
The use of ALPN in the TLS and QUIC handshakes establishes the target application protocol before application-layer bytes are processed. <del> Because all QUIC packets are encrypted, it is difficult for an attacker to control the plaintext bytes of an HTTP/3 connection, which could be used in a cross-protocol attack on a plaintext protocol. </del> <ins> This ensures that endpoints have strong assurances that peers are using the same protocol. This does not guarantee protection from all cross-protocol attacks. Section 21.5 of QUIC-TRANSPORT describes some ways in which the plaintext of QUIC packets can be used to perform request forgery against endpoints that don't use authenticated transports. </ins> 10.3.
A PATH_RESPONSE frame received on any network path validates the path on which the PATH_CHALLENGE was sent. <del> If the PATH_CHALLENGE frame that resulted in successful path validation was sent in a datagram that was not expanded to at least 1200 bytes, the endpoint can regard the address as valid.  The endpoint is then able to send more than three times the amount of </del> <ins> If an endpoint sends a PATH_CHALLENGE frame in a datagram that is not expanded to at least 1200 bytes, and if the response to it validates the peer address, the path is validated but not the path MTU.  As a result, the endpoint can now send more than three times the amount of </ins> data that has been received.  However, the endpoint MUST initiate another path validation with an expanded datagram to verify that the <del> path supports required MTU. </del> <ins> path supports the required MTU. </ins> Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate validation, since the acknowledgment can be
authenticated negotiation of an application protocol (TLS uses ALPN ALPN for this purpose) <del> Endpoints can use packets sent during the handshake to test for Explicit Congestion Notification (ECN) support; see ecn.  An endpoint verifies support for ECN by observing whether the ACK frames acknowledging the first packets it sends carry ECN counts, as described in ecn-validation. </del> The CRYPTO frame can be sent in different packet number spaces (packet-numbers).  The offsets used by CRYPTO frames to ensure ordered delivery of cryptographic handshake data start from zero in
shown with a '*'.  Once completed, endpoints are able to exchange application data. <del> An endpoint validates support for Explicit Congestion Notification (ECN) by observing whether the ACK frames acknowledging the first packets it sends carry ECN counts, as described in ecn-validation. </del> <ins> Endpoints can use packets sent during the handshake to test for Explicit Congestion Notification (ECN) support; see ecn.  An endpoint validates support for ECN by observing whether the ACK frames acknowledging the first packets it sends carry ECN counts, as described in ecn-validation. </ins> Endpoints MUST explicitly negotiate an application protocol.  This avoids situations where there is a disagreement about the protocol
A token allows a server to correlate activity between the connection where the token was issued and any connection where it is used. <del> Clients that want to break continuity of identity with a server MAY </del> <ins> Clients that want to break continuity of identity with a server can </ins> discard tokens provided using the NEW_TOKEN frame.  In comparison, a token obtained in a Retry packet MUST be used immediately during the connection attempt and cannot be used in subsequent connection
The next bit (0x40) of byte 0 is set to 1.  Packets containing a zero value for this bit are not valid packets in this version and <del> MUST be discarded. </del> <ins> MUST be discarded.  A value of 1 for this bit allows QUIC to coexist with other protocols; see RFC7983. </ins> The next two bits (those with a mask of 0x30) of byte 0 contain a packet type.  Packet types are listed in long-packet-types.
The next bit (0x40) of byte 0 is set to 1.  Packets containing a zero value for this bit are not valid packets in this version and <del> MUST be discarded. </del> <ins> MUST be discarded.  A value of 1 for this bit allows QUIC to coexist with other protocols; see RFC7983. </ins> The third most significant bit (0x20) of byte 0 is the latency spin bit, set as described in spin-bit.
newer encryption level are available. An endpoint cannot discard keys for a given encryption level unless <del> it has both received and acknowledged all CRYPTO frames for that encryption level and when all CRYPTO frames for that encryption level have been acknowledged by its peer.  However, this does not guarantee that no further packets will need to be received or sent at that </del> <ins> it has received all the cryptographic handshake messages from its peer at that encryption level and its peer has done the same. Different methods for determining this are provided for Initial keys (discard-initial) and Handshake keys (discard-handshake).  These methods do not prevent packets from being received or sent at that </ins> encryption level because a peer might not have received all the <del> acknowledgments necessary to reach the same state. </del> <ins> acknowledgments necessary. </ins> Though an endpoint might retain older keys, new data MUST be sent at the highest currently-available encryption level.  Only ACK frames
21.13. Deployments should limit the ability of an attacker to target a new <del> connection to a particular server instance.  This means that client- controlled fields, such as the initial Destination Connection ID used on Initial and 0-RTT packets SHOULD NOT be used by themselves to make routing decisions.  Ideally, routing decisions are made independently of client-selected values; a Source Connection ID can be selected to route later packets to the same server. </del> <ins> connection to a particular server instance.  Ideally, routing decisions are made independently of client-selected values, including addresses.  Once an instance is selected, a connection ID can be selected so that later packets are routed to the same instance. </ins> 21.14.
The endpoint uses RTT samples and peer-reported host delays (see Section 13.2 of QUIC-TRANSPORT) to generate a statistical description of the network path's RTT.  An endpoint computes the following three <del> values for each path: the minimum value observed over the lifetime of the path (min_rtt), an exponentially-weighted moving average (smoothed_rtt), and the mean deviation (referred to as "variation" in the rest of this document) in the observed RTT samples (rttvar). </del> <ins> values for each path: the minimum value over a period of time (min_rtt), an exponentially-weighted moving average (smoothed_rtt), and the mean deviation (referred to as "variation" in the rest of this document) in the observed RTT samples (rttvar). </ins> 5.1.
5.2. min_rtt is the sender's estimate of the minimum RTT observed for a <del> given network path.  In this document, min_rtt is used by loss detection to reject implausibly small rtt samples. </del> <ins> given network path over a period of time.  In this document, min_rtt is used by loss detection to reject implausibly small rtt samples. </ins> min_rtt MUST be set to the latest_rtt on the first RTT sample. min_rtt MUST be set to the lesser of min_rtt and latest_rtt (latest-
in compliance with RFC6437, unless the local API does not allow setting IPv6 flow labels. <del> The IPv6 flow label SHOULD be a pseudo-random function of the source and destination addresses, source and destination UDP ports, and the Destination Connection ID field.  The flow label generation MUST be designed to minimize the chances of linkability with a previously used flow label, as a stable flow label would enable correlating activity on multiple paths; see migration-linkability. A possible implementation is to compute the flow label as a cryptographic hash function of the source and destination addresses, source and destination UDP ports, Destination Connection ID field, and a local secret. </del> <ins> The flow label generation MUST be designed to minimize the chances of linkability with a previously used flow label, as a stable flow label would enable correlating activity on multiple paths; see migration- linkability. RFC6437 suggests deriving values using a pseudorandom function to generate flow labels.  Including the Destination Connection ID field in addition to source and destination addresses when generating flow labels ensures that changes are synchronized with changes in other observable identifiers.  A cryptographic hash function that combines these inputs with a local secret is one way this might be implemented. </ins> 10.
QUIC begins every connection in slow start with the congestion window set to an initial value.  Endpoints SHOULD use an initial congestion window of 10 times the maximum datagram size (max_datagram_size), <del> limited to the larger of 14720 bytes or twice the maximum datagram size.  This follows the analysis and recommendations in RFC6928, increasing the byte limit to account for the smaller 8-byte overhead of UDP compared to the 20-byte overhead for TCP. </del> <ins> while limiting the window to the larger of 14720 bytes or twice the maximum datagram size.  This follows the analysis and recommendations in RFC6928, increasing the byte limit to account for the smaller 8-byte overhead of UDP compared to the 20-byte overhead for TCP. </ins> If the maximum datagram size changes during the connection, the initial congestion window SHOULD be recalculated with the new size.
If the recipient permits the migration, it MUST send subsequent packets to the new peer address and MUST initiate path validation (migrate-validate) to verify the peer's ownership of the address if <del> validation is not already underway. </del> <ins> validation is not already underway.  If the recipient has no unused connection IDs from the peer, it will not be able to send anything on the new path until the peer provides one; see migration-linkability. </ins> An endpoint only changes the address to which it sends packets in response to the highest-numbered non-probing packet.  This ensures
SHOULD begin processing partial HTTP messages once enough of the message has been received to make progress.  If a client-initiated stream terminates without enough of the HTTP message to provide a <del> complete response, the server SHOULD abort its response with the error code H3_REQUEST_INCOMPLETE; see errors. </del> <ins> complete response, the server SHOULD abort its response stream with the error code H3_REQUEST_INCOMPLETE; see errors. </ins> A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the
data received, as specified in Section 8.1 of QUIC-TRANSPORT.  If no additional data can be sent, the server's PTO timer MUST NOT be armed until datagrams have been received from the client, because packets <del> sent on PTO count against the anti-amplification limit.  Note that the server could fail to validate the client's address even if 0-RTT is accepted. </del> <ins> sent on PTO count against the anti-amplification limit. When the server receives a datagram from the client, the amplification limit is increased and the server resets the PTO timer. If the PTO timer is then set to a time in the past, it is executed immediately.  Doing so avoids sending new 1-RTT packets prior to packets critical to the completion of the handshake.  In particular, this can happen when 0-RTT is accepted but the server fails to validate the client's address. </ins> Since the server could be blocked until more datagrams are received from the client, it is the client's responsibility to send packets to
An endpoint MUST include the value from the Source Connection ID field of the packet it receives in the Destination Connection ID <del> field.  The value for Source Connection ID MUST be copied from the Destination Connection ID of the received packet, which is initially randomly selected by a client.  Echoing both connection IDs gives clients some assurance that the server received the packet and that the Version Negotiation packet was not generated by an attacker that is unable to observe packets. </del> <ins> field.  The value for the Source Connection ID field MUST be copied from the Destination Connection ID field of the received packet, which is initially randomly selected by a client.  Echoing both connection IDs gives clients some assurance that the server received the packet and that the Version Negotiation packet was not generated by an attacker that is unable to observe packets. </ins> An endpoint that receives a Version Negotiation packet might change the version that it decides to use for subsequent packets.  The
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 <del> 14 BCP14 when, and only when, they appear in all capitals, as shown here. </del> <ins> 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> This document uses the variable-length integer encoding from QUIC- TRANSPORT.
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 <del> 14 BCP14 when, and only when, they appear in all capitals, as shown here. </del> <ins> 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> Definitions of terms that are used in this document: