jiebi/TextFlow huggingface dataset:
Original text:
of allowed, currently open, and currently used streams when determining how to map data to streams. <del> QUIC assigns a numerical identifier to each stream, called the Stream </del>  ID.  While the relationship between these identifiers and stream types is clearly defined in version 1 of QUIC, future versions might change this relationship for various reasons.  QUIC implementations should expose the properties of each stream (which endpoint initiated the stream, whether the stream is unidirectional or bidirectional, <del> the Stream ID used for the stream); applications should query for these properties rather than attempting to infer them from the Stream </del>  ID. The method of allocating stream identifiers to streams opened by the application might vary between transport implementations.  Therefore, an application should not assume a particular stream ID will be assigned to a stream that has not yet been allocated.  For example, <del> HTTP/3 uses Stream IDs to refer to streams that have already been opened, but makes no assumptions about future Stream IDs or the way </del>  in which they are assigned Section 6 of QUIC-HTTP). 4.1.

Reviewer comments:
This is the editorial convention we adopted for connection ID and what the RFC editor correctly inferred also.

Revised text:
of allowed, currently open, and currently used streams when determining how to map data to streams.  <ins> QUIC assigns a numerical identifier to each stream, called the stream </ins> ID.  While the relationship between these identifiers and stream types is clearly defined in version 1 of QUIC, future versions might change this relationship for various reasons.  QUIC implementations should expose the properties of each stream (which endpoint initiated the stream, whether the stream is unidirectional or bidirectional,  <ins> the stream ID used for the stream); applications should query for these properties rather than attempting to infer them from the stream </ins> ID. The method of allocating stream identifiers to streams opened by the application might vary between transport implementations.  Therefore, an application should not assume a particular stream ID will be assigned to a stream that has not yet been allocated.  For example,  <ins> HTTP/3 uses stream IDs to refer to streams that have already been opened, but makes no assumptions about future stream IDs or the way </ins> in which they are assigned Section 6 of QUIC-HTTP). 4.1.
Original text:
2.5. <del> [Editor's note: text needed.] 2.6. </del> Version negotiation is not protected, given the used protection mechanism can change with the version.  However, the choices provided in the list of version in the Version Negotiation packet will be

Reviewer comments:
Section 2.5 needs content.
This actually seems to be superceded by §8.4 in transport-13

Revised text:
2.5.  Version negotiation is not protected, given the used protection mechanism can change with the version.  However, the choices provided in the list of version in the Version Negotiation packet will be
Original text:
QUIC supports connection migration by the client.  If an IP address changes, a QUIC endpoint can still associate packets with an existing <del> transport connection using the destination connection ID field (see also connid) in the QUIC header, unless a zero-length value is used. This supports cases where address information changes, such as NAT rebinding, intentional change of the local interface, or based on an indication in the handshake of the server for a preferred address to be used. </del>  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-

Reviewer comments:
You can associate packets with connections without a connection ID. So rather than say something that is factually incorrect, let's just leave the next paragraph to establish the right impression (that a connection ID is highly recommended). This text works without talking about zero-length connection IDs.

Revised text:
QUIC supports connection migration by the client.  If an IP address changes, a QUIC endpoint can still associate packets with an existing  <ins> transport connection using the Destination Connection ID field (see also connid) in the QUIC header.  This supports cases where address information changes, such as NAT rebinding, intentional change of the local interface, or based on an indication in the handshake of the server for a preferred address to be used. </ins> 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-
Original text:
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>  Only the client can actively migrate in version 1 of QUIC.  However, servers can indicate during the handshake that they prefer to

Reviewer comments:
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.

Revised text:
QUIC probing packets, which can be sent on multiple paths at once, are used to perform address validation as well as measure path  <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
Original text:
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>  Section 4 of RFC5077 describes an example approach for constructing TLS resumption tickets that can be also applied for validation

Reviewer comments:
No real changes here, just noting that "Server Retry" isn't really a thing. Retry is, and servers use it, that's all.

Revised text:
11.3.  <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
Original text:
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>  2.4.

Reviewer comments:
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.

Revised text:
Further, as QUIC has a connection ID, it is also possible to maintain multiple QUIC connections over one 5-tuple.  However, if the  <ins> connection ID is zero-length, all packets of the 5-tuple likely belong to the same QUIC connection. </ins> 2.4.
Original text:
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>  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-

Reviewer comments:
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.

Revised text:
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  <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-
Original text:
3.1. The QUIC wire image is not specifically designed to be <del> distinguishable from other UDP traffic. </del>  The only application binding defined by the IETF QUIC WG is HTTP/3 QUIC-HTTP at the time of this writing; however, many other

Reviewer comments:
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.

Revised text:
3.1. The QUIC wire image is not specifically designed to be  <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
Original text:
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>  If state is removed too early, this could lead to black-holing of incoming packets after a short idle period.  To detect this

Reviewer comments:
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.

Revised text:
set long enough to also allow for short idle time during a valid transmission.  <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
Original text:
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>  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

Reviewer comments:
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.

Revised text:
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  <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
Original text:
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>  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

Reviewer comments:
NiT Fix 365 - The randomness described was a result of indiscriminate drops.

Revised text:
Further, if UDP traffic is desired to be throttled, it is recommended to block individual QUIC flows entirely rather than dropping packets  <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
Original text:
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>  handshake has completed (see sec-confirm), and for three-way handshake RTT estimation as in sec-rtt.

Reviewer comments:
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.

Revised text:
Server Hello message is obfuscated using the Initial secret. The Client Completion datagram does not expose any additional  <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.