jiebi/CodeConvo huggingface dataset:
Change:
The text here mentioned the decision to use a new path twice. Also, probing packets almost always include padding frames now: we require that the datagram is full-sized when probing so that we can probe for MTU, and probing is almost certainly done with short header packets, where padding has to be inside the packet.

Discussion:
QUIC probing packets, which can be sent on multiple paths at once, are used to perform address validation as well as measure path <del> characteristics as input for the switching decision.  Probing packets cannot carry application data but may contain padding frames. Endpoints can use information about their receipt as input to congestion control for that path.  Applications could use information learned from probing to inform a decisions to switch paths. </del> <ins> characteristics.  Probing packets cannot carry application data but likely contain padding frames.  Endpoints can use information about their receipt as input to congestion control for that path. Applications could use information learned from probing to inform a decisions to switch paths. </ins> Only the client can actively migrate in version 1 of QUIC.  However, servers can indicate during the handshake that they prefer to
Change:
No real changes here, just noting that "Server Retry" isn't really a thing. Retry is, and servers use it, that's all.

Discussion:
11.3. <del> QUIC provides a Server Retry packet that can be sent by a server in response to the Client Initial packet.  The server may choose a new connection ID in that packet and the client will retry by sending another Client Initial packet with the server-selected connection ID. This mechanism can be used to redirect a connection to a different server, e.g. due to performance reasons or when servers in a server pool are upgraded gradually, and therefore may support different versions of QUIC.  In this case, it is assumed that all servers belonging to a certain pool are served in cooperation with load balancers that forward the traffic based on the connection ID.  A server can choose the connection ID in the Server Retry packet such that the load balancer will redirect the next Client Initial packet to a different server in that pool.  Alternatively the load balancer can directly offer a Retry service as further described in QUIC-LB. </del> <ins> QUIC provides a Retry packet that can be sent by a server in response to the client Initial packet.  The server may choose a new connection ID in that packet and the client will retry by sending another client Initial packet with the server-selected connection ID.  This mechanism can be used to redirect a connection to a different server, e.g., due to performance reasons or when servers in a server pool are upgraded gradually, and therefore may support different versions of QUIC. In this case, it is assumed that all servers belonging to a certain pool are served in cooperation with load balancers that forward the traffic based on the connection ID.  A server can choose the connection ID in the Retry packet such that the load balancer will redirect the next Initial packet to a different server in that pool. Alternatively the load balancer can directly offer a Retry service as further described in QUIC-LB. </ins> Section 4 of RFC5077 describes an example approach for constructing TLS resumption tickets that can be also applied for validation
Change:
Probably, but not certain Especially if you got it wrong regarding the connection ID.
If there is no connection is how would an endpoint identify connection on the same 5-tuple then (for QUICv1)?
It is possible to run multiple connections on the same tuple with trial decryption.

Discussion:
Further, as QUIC has a connection ID, it is also possible to maintain multiple QUIC connections over one 5-tuple.  However, if the <del> connection ID is zero length, all packets of the 5-tuple belong to the same QUIC connection. </del> <ins> connection ID is zero-length, all packets of the 5-tuple likely belong to the same QUIC connection. </ins> 2.4.
Change:
No client currently attempts to use UDP port 443 for HTTP/3 without first having been told to do so, most often by AltSvc or HTTPS records. Technically we can also use the URL to decide to use QUIC, but that doesn't currently happen. With HTTPS records, that might never be necessary.
This is not entirely true. As we have HTTPS records and Alternative Services, there is no case where HTTP/3 goes without a means of signaling a port number. So there is no real "default" as far as it goes. It's just that we reserved the number and we tend to use that port number by convention.
For what it's worth, NAME and I were talking about this wrt URL in MOPS, so the timing of this issue in QUIC was very helpful. Thank you for that. I'm using "by convention", at his suggestion.

Discussion:
QUIC-HTTP at the time of this writing; however, many other applications are currently being defined and deployed over QUIC, so an assumption that all QUIC traffic is HTTP/3 is not valid.  HTTP/3 <del> uses UDP port 443 by default, although URLs referring to resources available over HTTP/3 may specify alternate port numbers.  Simple assumptions about whether a given flow is using QUIC based upon a UDP port number may therefore not hold; see also Section 5 of RFC7605. </del> <ins> uses UDP port 443 by convention but various methods can be used to specify alternate port numbers.  Simple assumptions about whether a given flow is using QUIC based upon a UDP port number may therefore not hold; see also Section 5 of RFC7605. </ins> While the second-most-significant bit (0x40) of the first octet is set to 1 in most QUIC packets of the current version (see public-
Change:
NAME thank you for your help with this.
It is specifically designed to allow for multiplexing of QUIC with real-time protocols. See RFC 7983.
NAME is this issue conflating what endpoints can distinguish and what anyone else can distinguish? I'm guessing that's the case, but it would be good to be clear about this, especially in the ops drafts. Again, I'm being informed here about what NAME issue being addressed in URL in MOPS should say. So thank you for opening the issue here!
NAME you are right to point that out. If we consider this about observers, then this text is probably OK. I would say that it needs qualification to be properly correct though. We might reasonably assume that the statement applies only to "a passive observer in the network", as noted in the top of the section, but the risk that this statement be taken out of context is strong (it's a nice clear sound bite). The same section later mentions RFC 7983. That text could also be improved in this regard.

Discussion:
3.1. The QUIC wire image is not specifically designed to be <del> distinguishable from other UDP traffic. </del> <ins> distinguishable from other UDP traffic by a passive observer in the network. </ins> The only application binding defined by the IETF QUIC WG is HTTP/3 QUIC-HTTP at the time of this writing; however, many other
Change:
This is an attempt to clearly say what the problem is with NAT state timeout and what is a recommended approach.
As this is advice for network operators and middlebox vendors, this reads to me as permission to use a lower timeout. I think that it still makes sense to maintain the recommendation in RFC 4787. The advice for applications (don't rely on 2 minutes) still applies, but a 2 minute recommendation is worth sticking to.
I thought the text is pretty clear in saying that a bit later: I would rather want to keep this part because the message really is: yes we know these too short timers are implemented for UDP but please, please use at least 2 minutes for QUIC. Maybe removing some paragraph breaks would make it clearer that these parts belong together? Also this part got now edited quite extensively, so I rather not change it again...
Each of the sentences looks fine to me, but together I also have a hard time seeing the recommendation v. current experience. Here is a proposal: .
This is better. With Mirja's suggestion.

Discussion:
set long enough to also allow for short idle time during a valid transmission. <del> RFC4787 requires a timeout that is not less than 2 minutes for most UDP traffic.  However, in practice, timers are sometimes lower, in the range of 30 to 60 seconds.  In contrast, RFC5382 recommends a timeout of more than 2 hours for TCP, given that TCP is a connection- oriented protocol with well- defined closure semantics. Even though QUIC has explicitly been designed to tolerate NAT rebindings, decreasing the NAT timeout is not recommended, as it may negatively impact application performance or incentivize endpoints to send very frequent keep-alive packets.  Instead it is recommended, even when lower timers are used for other UDP traffic, to use a timer of at least two minutes for QUIC traffic. </del> <ins> RFC4787 requires a network state timeout that is not less than 2 minutes for most UDP traffic.  However, in practice, a QUIC endpoint can experience lower timeouts, in the range of 30 to 60 seconds. In contrast, RFC5382 recommends a state timeout of more than 2 hours for TCP, given that TCP is a connection-oriented protocol with well- defined closure semantics.  Even though QUIC has explicitly been designed to tolerate NAT rebindings, decreasing the NAT timeout is not recommended, as it may negatively impact application performance or incentivize endpoints to send very frequent keep-alive packets. The recommendation is therefore that, even when lower state timeouts are used for other UDP traffic, a state timeout of at least two minutes ought to be used for QUIC traffic. </ins> If state is removed too early, this could lead to black-holing of incoming packets after a short idle period.  To detect this
Change:
Add ref to RFC3449 rather than explain how this works.
The text says: “Distinguishing ACK packets is trivial in TCP,” arguably this is not trivial, since you need to handle data and ACKs and exclude implications of TCP options. I’d prefer to say “possible” than “trivial”.
It's more than possible, it's easy. I don't quite follow which TCP options you're referring to. I can only think of SACK, which just reduces the number of them. Why is this not as trivial as "If only the ACK bit is set, and there's no payload, it's an ACK." ? (Yes, truly bidirectional flows will have payload, but then I would argue they are not simple ACK packets.)
SACK adds an obvious widley deployed complication for TCP; ECN feedback also; some methods have simply used packet size. I know there are various forms ACK decimation/filtering/etc, some even delve into IP encaps to do this, I just don't want to convey a message that this "trivial" to get a good solution. The key point is that QUIC does not allow any of this without keying information.
I see. So we need a word that says it's a bit more complex than "trivial", but still reasonably simple (esp. in comparison with QUIC). "Possible" would work.
Yes, "possible" is indeed fine. Shall I make a PR? Gorry
I'd say yes.

Discussion:
Some deployed in-network functions distinguish pure-acknowledgment (ACK) packets from packets carrying upper-layer data in order to attempt to enhance performance, for example by queueing ACKs <del> differently or manipulating ACK signaling.  Distinguishing ACK packets is trivial in TCP, but not supported by QUIC, since </del> <ins> differently or manipulating ACK signaling RFC3449.  Distinguishing ACK packets is possible in TCP, but is not supported by QUIC, since </ins> acknowledgment signaling is carried inside QUIC's encrypted payload, and ACK manipulation is impossible.  Specifically, heuristics attempting to distinguish ACK-only packets from payload-carrying
Change:
NiT Fix 365 - The randomness described was a result of indiscriminate drops.

Discussion:
Further, if UDP traffic is desired to be throttled, it is recommended to block individual QUIC flows entirely rather than dropping packets <del> randomly.  When the handshake is blocked, QUIC-capable applications may failover to TCP However, blocking a random fraction of QUIC packets across 4-tuples will allow many QUIC handshakes to complete, preventing a TCP failover, but the connections will suffer from severe packet loss (see also sec-filtering).  Therefore UDP throttling should be realized by per-flow policing as opposed to per- packet policing.  Note that this per-flow policing should be stateless to avoid problems with stateful treatment of QUIC flows (see sec-stateful), for example blocking a portion of the space of values of a hash function over the addresses and ports in the UDP </del> <ins> indiscriminately.  When the handshake is blocked, QUIC-capable applications may failover to TCP However, blocking a random fraction of QUIC packets across 4-tuples will allow many QUIC handshakes to complete, preventing a TCP failover, but resulting in connections then suffering severe packet loss (see also sec-filtering). Therefore UDP throttling should be realized by per-flow policing, as opposed to per-packet policing.  Note that this per-flow policing should be stateless to avoid problems with stateful treatment of QUIC flows (see sec-stateful), for example blocking a portion of the space of values of a hash function over the addresses and ports in the UDP </ins> datagram.  While QUIC endpoints are often able to survive address changes, e.g. by NAT rebindings, blocking a portion of the traffic based on 5-tuple hashing increases the risk of black-holing an active
Change:
this addresses a comment from NAME in issue
In the interests of timely completion of the document, will go ahead and merge this; please open an issue if this doesn't work for you NAME :)
... doesn't make it clear that only the Initial from the client (and only those sent before receiving packets from the server) contain a Destination Connection ID field that can be used to decrypt the packet. Any initial from the server, or any initial sent by a client after receiving Initial packets from the server, probably won't work.
Hmm, this is the last paragraph. Too late?
More broadly, it would be nice if Sec 2.4 discussed the property that the server CID changes pretty much immediately. We wouldn't want people to bind to a 2-tuple of CIDs and have that immediately fail.
NAME I create PR based on your comment. Is that sufficient? NAME which section are you talking about?
I think will fix NAME comment here.

Discussion:
Server Hello message is obfuscated using the Initial secret. The Client Completion datagram does not expose any additional <del> information; however, recognizing it can be used to determine that a </del> <ins> information; however, as the destination connection ID is server- selected, it usually is not the same ID than in the Client Initial datagram.  Client Completion datagram can be used to determine that a </ins> handshake has completed (see sec-confirm), and for three-way handshake RTT estimation as in sec-rtt.
Change:
Addresses
... doesn't make it clear that only the Initial from the client (and only those sent before receiving packets from the server) contain a Destination Connection ID field that can be used to decrypt the packet. Any initial from the server, or any initial sent by a client after receiving Initial packets from the server, probably won't work.
Hmm, this is the last paragraph. Too late?
More broadly, it would be nice if Sec 2.4 discussed the property that the server CID changes pretty much immediately. We wouldn't want people to bind to a 2-tuple of CIDs and have that immediately fail.
NAME I create PR based on your comment. Is that sufficient? NAME which section are you talking about?
I think will fix NAME comment here.
Much better. My comment here is mostly a nit. I think that you are implicitly talking about the first packet from the client, so maybe you can avoid using the "Client Initial" thing here (if you are using the abstract concept you introduced), "client Initial" (that is, Initial packets sent by a client), or anything that might be confusing.

Discussion:
When the version has been identified as QUIC version 1, the packet type needs to be verified as an Initial packet by checking that the third and fourth bits of the header are both set to 0.  Then the <del> Destination Connection ID needs to be extracted to calculate the Initial secret using the version-specific Initial salt, as described in Section 5.2 of QUIC-TLS.  The length of the connection ID is indicated in the 6th byte of the header followed by the connection ID itself. </del> <ins> Destination Connection ID needs to be extracted from the packet.  The Initial secret is calculated using the version-specific Initial salt, as described in Section 5.2 of QUIC-TLS.  The length of the connection ID is indicated in the 6th byte of the header followed by the connection ID itself. Note that subsequent Initial packets might contain a Destination Connection ID other than the one used to generate the Initial secret. Therefore, attempts to decrypt these packets using the procedure above might fail unless the Initial secret is retained by the observer. </ins> To determine the end of the header and find the start of the payload, the packet number length, the source connection ID length, and the

Finally, an extension might define additional frame types which could be present. <del> Note that subsequent Initial packets might contain a Destination Connection ID other than the one used to generate the Initial secret. Therefore, attempts to decrypt these packets using the procedure above might fail unless the Initial secret is retained by the observer. </del> 3.5. The QUIC connection ID (see rebinding) is designed to allow a
Change:
Refers to quicwg. This also addresses /extremely limited/ ECN visibility (limited for sure, but we don't need to say "extremely"). Fixed multiple definitions of RTT Refered to metrics, etc for encrypted traffic wrt network-layer measurement via a REF.
Thanks for the suggestions from Ian and Mirjay, they were of course incorporated.

Discussion:
3.8. <del> The round-trip time of QUIC flows can be inferred by observation once per flow, during the handshake, as in passive TCP measurement; this requires parsing of the QUIC packet header and recognition of the handshake, as illustrated in handshake.  It can also be inferred during the flow's lifetime, if the endpoints use the spin bit facility described below and in Section 17.3.1 of QUIC-TRANSPORT. </del> <ins> The round-trip time (RTT) of QUIC flows can be inferred by observation once per flow, during the handshake, as in passive TCP measurement; this requires parsing of the QUIC packet header and recognition of the handshake, as illustrated in handshake.  It can also be inferred during the flow's lifetime, if the endpoints use the spin bit facility described below and in Section 17.3.1 of QUIC- TRANSPORT. </ins> 3.8.1.

on each packet sent. When in use, the latency spin bit in each direction changes value <del> once per round-trip time (RTT) any time that both endpoints are sending packets continuously.  An on-path observer can observe the time difference between edges (changes from 1 to 0 or 0 to 1) in the spin bit signal in a single direction to measure one sample of end- to-end RTT.  This mechanism follows the principles of protocol measurability laid out in IPIM. </del> <ins> once per RTT any time that both endpoints are sending packets continuously.  An on-path observer can observe the time difference between edges (changes from 1 to 0 or 0 to 1) in the spin bit signal in a single direction to measure one sample of end-to-end RTT.  This mechanism follows the principles of protocol measurability laid out in IPIM. </ins> Note that this measurement, as with passive RTT measurement for TCP, includes any transport protocol delay (e.g., delayed sending of

Limited RTT measurement is possible by passive observation of QUIC traffic; see sec-rtt.  No passive measurement of loss is possible <del> with the present wire image.  Extremely limited observation of upstream congestion may be possible via the observation of CE markings on ECN-enabled QUIC traffic. </del> <ins> with the present wire image.  Limited observation of upstream congestion may be possible via the observation of CE markings on ECN- enabled QUIC traffic. On-path devices can also make measurements of RTT, loss and other performance metrics when information is carried in an additional network-layer packet header (Section 6 of I-D.ietf-tsvwg-transport- encrypt describes use of operations, administration and management (OAM) information).  Using network-layer approaches also has the advantage that common observation and analysis tools can be consistently used by multiple transport protocols, however, these techniques are often limited to measurements within one or multiple cooperating domains. </ins> 4.2.
Change:
This would be my proposal of a few small additions based on the discussion on list and at the last meeting (IETF-112) about privacy implications after migration regarding exposure of linkable user IP addresses to the server. The text doesn't give any recommendations but at least mentions it in the relevant sections.
I left a few suggestions, but this is heading in a good direction.

Discussion:
Use of a non-zero-length connection ID for the server is strongly recommended if any clients are behind a NAT or could be.  A non-zero- <del> length connection ID is also strongly recommended when migration is supported. </del> <ins> length connection ID is also strongly recommended when active migration is supported.  If a connection is intentionally migrated to new path, a new connection ID is used to minimize linkability by network observers.  The other QUIC endpoint uses the connection ID to link different addresses to the same connection and entity if a non- zero-length connection ID is provided. </ins> The base specification of QUIC version 1 only supports the use of a single network path at a time, which enables failover use cases.

replay attacks, and randomness discussed in QUIC-TLS should be taken into account when deploying and using QUIC. <ins> Further, migration to an new address exposes a linkage between client addresses to the server and may expose this linkage also to the path if the connection ID cannot be changed or flows can otherwise be correlated.  When migration is supported, this needs to be considered with respective to user privacy. </ins> Application developers should note that any fallback they use when QUIC cannot be used due to network blocking of UDP should guarantee the same security properties as QUIC; if this is not possible, the
Change:
Currently the document uses "will". This might be a very valid assumption, but still it is an assumption hence I think it is better to use "May" instead of "Will".

Discussion:
Version Negotiation packets are used by the server to indicate that a requested version from the client is not supported (see Section 6 of QUIC-TRANSPORT.  Version Negotiation packets are not intrinsically <del> protected, but future QUIC versions will use later encrypted messages to verify that they were authentic.  Therefore, any modification of this list will be detected and may cause the endpoints to terminate the connection attempt. </del> <ins> protected, but future QUIC versions could use later encrypted messages to verify that they were authentic.  Therefore, any modification of this list will be detected and may cause the endpoints to terminate the connection attempt. </ins> Also note that the list of versions in the Version Negotiation packet may contain reserved versions.  This mechanism is used to avoid
Change:
well I don't think transport protocol will be using any of the tools rather those tools can be used to observer multiple protocols

Discussion:
encrypt describes use of operations, administration and management (OAM) information).  Using network-layer approaches also has the advantage that common observation and analysis tools can be <del> consistently used by multiple transport protocols, however, these </del> <ins> consistently used for multiple transport protocols, however, these </ins> techniques are often limited to measurements within one or multiple cooperating domains.