jiebi/CodeConvo huggingface dataset:
Code change:
data, unless priorities specified by the application indicate otherwise (see stream-prioritization). <ins> Even though a sender is encouraged to assemble frames containing up- to-date information every time it sends a packet, it is not forbidden to retransmit frames of lost packets as they are.  A receiver MUST accept packets containing an outdated frame, such as a MAX_DATA frame carrying a smaller maximum data than one found in an older packet. </ins> Upon detecting losses, a sender MUST take appropriate congestion control action.  The details of loss detection and congestion control are described in QUIC-RECOVERY.

Related discussion:
text: For example if an ACK is required to ack packet 4000 + 1E9 and you have 500 gaps that has arrived the last RTT/4 and really should be included. Resulting in an ACK frame that is at least 1000 bytes large, possibly bigger.
There are a few things this precludes, and we we should understand those before doing this. 1) A very limited implementation(ie: hardware) can't always send only one ACK block without giving up on reordered packets. I don't have such an implementation, but at some point I remember discussing this idea with people who seemed interested in it. 2) One cannot do multipath with QUIC v1 and it means the multipath design will have to use a PN space per path, as described in Christian's draft: URL I think that's likely the right choice for other reasons, but I'm hesitant to make that decision now. 3) An RTT sample can only be taken based on the largest acked. Therefore, if there is a large amount of reordering(ie: 1RTT), you don't get any RTT samples for an RTT. If we care about this, we can probably solve it a different way in the recovery draft, but that likely means using ack delay sometimes and not others. In regards to Martin's comment, I thought we already had text that said ACKs with lower packet numbers than the largest ACK packet number should be ignored, since they're old?
NAME regarding your question. "In regards to Martin's comment, I thought we already had text that said ACKs with lower packet numbers than the largest ACK packet number should be ignored, since they're old?" At least when it comes to ECN, the editors have been working hard to reformulate which has resulted in that there is nothing that applies this from the PN increasing for the ACKs. So to solve the ECN part, I think (re-)introducing that aspect into the text is the simpliest fix for ECN. But there clearly are other aspects here.
NAME The problem doesn't go away if you ignore acks that are lower than largest_acked. The problem is that the receiver sent the acks in the wrong order because packets were received in the wrong order, but ECN counts are going up. But you raise good points. This is a corner case.
Code change:
data, unless priorities specified by the application indicate otherwise (see stream-prioritization). <ins> Even though a sender is encouraged to assemble frames containing up- to-date information every time it sends a packet, it is not forbidden to retransmit frames of lost packets as they are.  A receiver MUST accept packets containing an outdated frame, such as a MAX_DATA frame carrying a smaller maximum data than one found in an older packet. </ins> Upon detecting losses, a sender MUST take appropriate congestion control action.  The details of loss detection and congestion control are described in QUIC-RECOVERY.

Related discussion:
text: I think that with the current spec, under these conditions, ECN gets turned off since validation fails. I think that's a reasonable outcome, and I'm fine with it. NAME
ECN Validation as I currently understand it will not fail if the sender to receiver reordering happens as long as the ACKs from the receiver to sender are not reordered. So to my understanding what is missing is a requirement for the sender to no process verfication for out of order ACKs. It will not fail if the largest acknowledge is not increasing as the comparison is done on number of newly ACKed packets versus counts change. The current sentence in Section 13.3.2 (-17): "Counts MUST NOT be verified if the ACK frame does not increase the largest received packet number at the endpoint." Which I interpret to mean that what PN the ACK reference (sender-receiver direction), rather than the PN of the receiver to sender direction. Can NAME or NAME fix that?
I think is enough to address the original problem, so I'd like to close this issue. I think and are enough. NAME sound ok?
Yes, the ECN related issue is resolved. What I don't know if it is resolved fully is the implementation requirements is that a sender MUST be capable of handling an ACK frame with Largest Acknowledged that is smaller than highest received? From my perspective there are good and valid arguments why this may be required, however I think consensus needs to be established on that.
NAME I am not sure if I'm following the context, but my understanding is that a sender MUST be capable of that, because we allow an endpoint to simply retransmit the payload of a packet that is being deemed lost; see .
Just a stray thought: is this requirement really strictly needed? It would complicate trasnmitters that split work into multiple processing units which might not be fully synced on the latest ACK'ed.
NAME what NAME says. Also, a sender needs to be able to simply deal with reordering on the ack path. Did you mean something else?
My concern was primarily about the clearness of this behavior in the specification text. In transport I find the following which indicates this but are not explicit. : To limit receiver state or the size of ACK frames, a receiver MAY limit the number of ACK Ranges it sends.
Code change:
data, unless priorities specified by the application indicate otherwise (see stream-prioritization). <ins> Even though a sender is encouraged to assemble frames containing up- to-date information every time it sends a packet, it is not forbidden to retransmit frames of lost packets as they are.  A receiver MUST accept packets containing an outdated frame, such as a MAX_DATA frame carrying a smaller maximum data than one found in an older packet. </ins> Upon detecting losses, a sender MUST take appropriate congestion control action.  The details of loss detection and congestion control are described in QUIC-RECOVERY.

Related discussion:
text: : Largest Acknowledged: A variable-length integer representing the largest packet number the peer is acknowledging; this is usually the largest packet number that the peer has received prior to generating the ACK frame. I think there are strong hints, with the above "usually the largest" indicating that it is not always. I would have made this explicit in 19.3, but then I prefer being more explicit than not. I think it is possible interop issue point. Anywhere else this is more explicit? (I have read github master version) NAME I think there are strong points for allowing an ACK frame to acknowledge only a part of the range between highest received and confirmed to be have been ACKed. The two main reasons I see. high rate flows suffering an packet loss burst so that the number of ACK ranges becomes to large to fit a single QUIC packet. Low complexity receivers ACKing a single range of received packets and doing this for reordered packets.
NAME As suggested by NAME in , might be the correct place. I am advocating for describing the design principle the PR, but we might (or might not) be interested in expanding how ACK could look like.
So results in certain implications, that an ACK could arrive that addresses older state, thus resulting in acknowledging some PNs that was previously unacknowledged. As 13.2 is about retransmissions, I think there are other desing principle aspects of ACKs that probably should be covered, but then earlier in 13.1.
We're in the process of making our implementation accept smaller largest_acked values, so I'm wonder if we're any closer to consensus(one way or the other) on this issue?
I think this is mostly addressed and what's left is OBE. There's text in the draft now that says: "Processing counts out of order can result in verification failure. An endpoint SHOULD NOT perform this verification if the ACK frame is received in a packet with packet number lower than a previously received ACK frame. Verifying based on ACK frames that arrive out of order can result in disabling ECN unnecessarily." This would be adequate, but there's other text (thanks to ) that says old ACKs can be resent. I think we simply add a note about that in the para above, which should be adequate.
Discussed in London: NAME to prepare a PR for those remaining bits
NAME any progress here?
Code change:
data, unless priorities specified by the application indicate otherwise (see stream-prioritization). <ins> Even though a sender is encouraged to assemble frames containing up- to-date information every time it sends a packet, it is not forbidden to retransmit frames of lost packets as they are.  A receiver MUST accept packets containing an outdated frame, such as a MAX_DATA frame carrying a smaller maximum data than one found in an older packet. </ins> Upon detecting losses, a sender MUST take appropriate congestion control action.  The details of loss detection and congestion control are described in QUIC-RECOVERY.

Related discussion:
text: I think the conclusion here is close with no further action, but it'd be good for NAME to confirm.
I've added , which I believe addresses what's left of this issue.
Note that we agreed that proposal-ready would be used when there were approvals for PRs (or at least apparent agreement, as determined by editors).
NAME : Yeah, my bad.
This gets fixed by , so marking this issue as well.
Fixed by .
Code change:
watch for increasing numbers of end users uploading significant amounts of content. <ins> 2.6. The causes of unpredictable usage described in sec-unpredictable were more or less the result of human choices, but we were reminded during a post-IETF 107 meeting that humans are not always in control, and forces of nature can cause enormous fluctuations in traffic patterns. In his talk, Sanjay Mishra Mishra reported that after the CoViD-19 pandemic broke out in early 2020, Comcast's streaming and web video consumption rose by 38%, with their reported peak traffic up 32% overall between March 1 to March 30 Comcast, AT&T reported a 28% jump in core network traffic (single day in April, as compared to pre stay-at-home daily average traffic), with video accounting for nearly half of all mobile network traffic, while social networking and web browsing remained the highest percentage (almost a quarter each) of overall mobility traffic ATT, and Verizon reported similar trends with video traffic up 36% over an average day (pre COVID-19) Verizon. We note that other operators saw similar spikes during this time period.  Craig Labowitz Labovitz reported Weekday peak traffic increases over 45%-50% from pre-lockdown levels, A 30% increase in upstream traffic over their pre-pandemic levels, and A steady increase in the overall volume of DDoS traffic, with amounts exceeding the pre-pandemic levels by 40%. (He attributed this increase to the significant rise in gaming-related DDoS attacks (LabovitzDDoS), as gaming usage also increased.) </ins> 3. 3.1.

Related discussion:
text: This is based on the post-IETF 107 MOPS meeting where we talked about this. I chased some more references.
We should try to improve this reference - it's a long page, additions are at the top, so we have to either scroll for a long time or search for the date to get the relevant part of the page. Maybe reach out to ATT to get fragment tags that work?
Code change:
See iana-error-codes for details of registering new error codes. <ins> In defining these error codes, several principles are applied.  Error conditions that might require specific action on the part of a recipient are given unique codes.  Errors that represent common conditions are given specific codes.  Absent either of these conditions, error codes are used to identify a general function of the stack, like flow control or transport parameter handling. Finally, generic errors are provided for conditions where implementations are unable or unwilling to use more specific codes. </ins> 20.1. Application protocol error codes are 62-bit unsigned integers, but

Related discussion:
text: This just writes down what was proposed in .
Looks fine, but what about some guidance on stream vs connection errors? And also the principle of nearly always choosing a hard protocol violation error, or a more granular error with same effect?
Stream vs. connection is something that application protocols (like HTTP) need to worry about. The transport only concerns itself with connection errors. The idea that you pick the most helpful error is not something that we need to codify (in my view).
Isn't that worth mentioning? Or do we already have such text?
This is already discussed in Section 11, which makes me wonder if it would make more sense for text on this PR to be placed there too.
This I do not disagree with. I was merely suggesting that we explain why, as a general rule, a hard error is preferred as a design principle, not the nature of the error message which I do think should have a large degree of freedom.
Maybe there is a followup needed for the HTTP draft. If the principles are generally the same, we can copy the text and then add some more to cover the idea that we make most errors fatal to the connection rather than the stream.
I like Lucas suggestion of adding this text to the existing and already fairly complete text in section 11.
I moved the second paragraph up to the error handling section, but the text about how codes are selected really belongs with the codes themselves.
We don't really have any real principles that we agree on for deciding what error codes we are describing. Proposal: if the error carries distinct semantics (like stream rejection in HTTP), then it gets a new error code if the error is frequent or particularly significant, then it gets a new error code otherwise, target a more generic error code that identifies the broad area of the protocol finally, if there is no more specific applicable error code, use PROTOCOL_VIOLATION
is example of an issue discussed where it would have been useful to have principles.
Code change:
Context (optional).  This parameter sets the Default Base URI under which the request's links are to be interpreted.  The <del> specified URI MUST NOT have a path component of its own, but MUST be suitable as a base URI to resolve any relative </del> <ins> specified URI typically does not have a path component of its own, and MUST be suitable as a base URI to resolve any relative </ins> references given in the registration.  The parameter is <del> therefore of the shape "scheme://authority" for HTTP and CoAP URIs.  In the absence of this parameter the scheme of the protocol, source address and source port of the registration request are assumed.  This parameter is mandatory when the directory is filled by a third party such as an commissioning tool.  If the endpoint uses an ephemeral port to register with, it MUST include the con parameter in the registration to provide a valid network path.  If the endpoint which is located behind a NAT gateway is registering with a Resource Directory which is on the network service side of the NAT gateway, the endpoint MUST use a persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests. </del> <ins> therefore usually of the shape "scheme://authority" for HTTP and CoAP URIs.  In the absence of this parameter the scheme of the protocol, source address and source port of the registration request are assumed.  This parameter is mandatory when the directory is filled by a third party such as an commissioning tool.  If the endpoint uses an ephemeral port to register with, it MUST include the con parameter in the registration to provide a valid network path.  If the endpoint which is located behind a NAT gateway is registering with a Resource Directory which is on the network service side of the NAT gateway, the endpoint MUST use a persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests. Endpoints that register with a con that contains a path component need to carefully consider the rules of relative URI resolution.  Typically, links submitted by such an endpoint are of the "path-noscheme" form. </ins> Additional registration attributes (optional).  The endpoint can pass any parameter registered at iana-registry to the

Related discussion:
text: I thus propose to generalize "con" to be any base URI that will be applied to all relative links an endpoint registered. If there is a conflict with a deployed mechanism, we could look into adopting "anchor" and let RD use it similarly to "con", but allowing full base URIs (including paths). Or we align with RFC 8288 altogether and replace "con" with "anchor": URL Ciao, Matthias
Code change:
in RFC5888.  addTrack attempts to minimize the number of transceivers as follows: if the PeerConnection is in the "have-remote-offer" state, the track will be attached to the first compatible transceiver <del> that was created by the most recent call to setRemoteDescription() and does not have a local track.  Otherwise, a new transceiver will be created, as described in sec.addTransceiver. </del> <ins> that was created by the most recent call to setRemoteDescription and does not have a local track.  Otherwise, a new transceiver will be created, as described in sec.addTransceiver. </ins> 4.1.3.

Related discussion:
text: Various fixes for 60.2: Removed parens from API names, removed comment. - put the term stable in quotes, removed comment. - put the term sess-id in angle brackets to match SDP spec, removed comment. - made the tls-id attribute consistent with other SDP attributes, removed comment. - removed quotes from IceRestart option, removed comment.

"IceRestart" option / IceRestart option Justin: LGTM
tls-id value / "a=tls-id" value Justin: The source RFC seems to prefer "tls-id" when discussing values.
During the editing of the Cluster 238 docs, it was decided that it's author's choice when formatting SDP attributes. Although RFC 8842 uses the format '"tls-id" attribute', this document more consistently uses "a=attribute-name" format for SDP attributes, which is the format that the SDP spec [RFC8866] uses. I'll update this document to consistently use "a=tls-id"
sess-id / (Section 5.2.1, second bullet item) Justin: LGTM
the stable state (1 instance) / the "stable" state (3 instances) >(Also, should 'the previous stable state' be 'a previous stable state' (per Section 5.7) or 'the previous "stable" state'?) Justin: The quoted form is preferred, including the case of "previous stable state".
[Breaking up issue /60 into smaller bites] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Justin: There seems to be a pretty clear preponderance for the non-parenthetical form, so let's keep that. W3C also does not use (). Jean: We'll remove the parens (camelCase is sufficient formatting).
Code change:
Universal Time, or might be defined relative to some other timestamp or timeticks counter. <del> We now walk through a number of hypothetical examples of how a solution might be built.  This list is not intended to be complete, but is just representative enough to highlight various timing considerations. </del> <ins> Using the table above, a number of hypothetical examples of how a solution might be built are illustrated below.  a solution might be built.  This list is not intended to be complete, but is just representative enough to highlight various timing considerations. </ins> 15.1.

Related discussion:
text: only the most essential items: added three more timestamp types based on TUDA, trying to generalize it a bit added a few periods to text that seems to express sentences
Code change:
Finally QUIC-VN provides two mechanisms for endpoints to negotiate the QUIC version to use.  The "incompatible" version negotiation <del> method can support switching from any initial QUIC version to any other version with full generality, at the cost of an additional round-trip at the start of the connection.  "Compatible" version negotiation eliminates the round-trip penalty but levies some restrictions on how much the two versions can differ semantically. </del> <ins> method can support switching from any QUIC version to any other version with full generality, at the cost of an additional round-trip at the start of the connection.  "Compatible" version negotiation eliminates the round-trip penalty but levies some restrictions on how much the two versions can differ semantically. </ins> QUIC version 2 is meant to mitigate ossification concerns and exercise the version negotiation mechanisms.  The only change is a

Related discussion:
text: The correct term from the VN document would be "original version" but just removing the word initial avoids the confusion
Fewer words means fewer nits
Code change:
10.8.6. This design permits servers operating in Split Mode to forward <del> connections directly to backend origin servers, thereby avoiding unnecessary MiTM attacks. </del> <ins> connections directly to backend origin servers.  The client authenticates the identity of the backend origin server, thereby avoiding unnecessary MiTM attacks. </ins> <del> 10.8.7. Assuming ECH records retrieved from DNS are authenticated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a server operating in Split Mode is not possible.  See plaintext-dns for more details regarding plaintext DNS. </del> <ins> Conversely, assuming ECH records retrieved from DNS are authenticated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a client-facing server operating in Split Mode is not possible.  See plaintext-dns for more details regarding plaintext DNS. </ins> Authenticating the ECHConfigs structure naturally authenticates the included public name.  This also authenticates any retry signals from <del> the server because the client validates the server certificate against the public name before retrying. </del> <ins> the client-facing server because the client validates the server certificate against the public name before retrying. </ins> <del> 10.8.8. </del> <ins> 10.8.7. </ins> This design has no impact on application layer protocol negotiation. It may affect connection routing, server certificate selection, and client certificate verification.  Thus, it is compatible with <del> multiple protocols. </del> <ins> multiple application and transport protocols.  By encrypting the entire ClientHello, this design additionally supports encrypting the ALPN extension. </ins> 10.9.

Related discussion:
text: We use a mix of sentence case and title case in the document. The RFC style guide says to use title case. This PR aligns with that. URL Additionally, the ESNI criteria document has changed slightly since the comparison against criteria section was written. I've aligned the titles with the final wording in RFC8744. RFC8744 has also merged "Proper security context" and "Split server spoofing", so I've done the same here. "Support Multiple Protocols" also now talks about transport protocols and ALPN, so I've added a few words about that.