jiebi/CodeConvo huggingface dataset:
Change:
builds on .
URL stream type MUST be treated as a connection error of type H3CLOSEDCRITICALSTREAM. I'd like to clarify that whether this effectively says that receiver is not allowed to send STOPSENDING. STOPSENDING is elicit RESETSTREAM that closes a stream. MUST send a RESETSTREAM frame if the stream is in the "Ready" or "Send" state. STOPSENDING itself does not close a stream, but it is an action to request a closure. I found in interop runner test, one implementation sends STOPSENDING to QPACK streams. My implementation sends RESETSTREAM when it is received as mandated by spec, and upon stream closure, the connection is closed because QPACK streams are closed, then the test fails. HTTP draft explicitly says that requesting closure for the control stream is prohibited: request that the sender close the control stream. It would be nice to add the similar statement to QPACK streams.
It's super-late in the process, but maybe the editors can see a way to squeeze an editorial change in.
Thanks Tatsuhiro. I agree, IMO the intention was always for consistent treatment of open control streams and open qpack streams when it comes to not closing them. Finding a way to address this during AUTH48 would be nice.
I agree, this was the intention -- closing the stream is treated as an error, and being asked to commit an error is itself an error. One could squint and say it's covered by the existing text -- upon receipt of the STOP_SENDING, the send is required to close the stream; closure of the stream is already required to be treated as an error. It's technically a normative change, but there's no effective change in behavior.
If it's a normative change, is it still OK to change in auth48 just with a WG consensus call or is more process required?
The AD has to decide what to do and approve this change to the RFC editor.
Since the fix includes a gentle normative change, marking this as a design issue and we'll put out a consensus call to the list.
Consensus was declared, so was merged.

Discussion:
stream.  Receipt of a second instance of either stream type MUST be treated as a connection error of type H3_STREAM_CREATION_ERROR. <del> These streams MUST NOT be closed.  Closure of either unidirectional stream type MUST be treated as a connection error of type H3_CLOSED_CRITICAL_STREAM. </del> <ins> The sender MUST NOT close either of these streams, and the receiver MUST NOT request that the sender close either of these streams. Closure of either unidirectional stream type MUST be treated as a connection error of type H3_CLOSED_CRITICAL_STREAM. </ins> An endpoint MAY avoid creating an encoder stream if it will not be used (for example, if its encoder does not wish to use the dynamic
Change:
Inspired by NAME suggestion;
Is "to the encoder" intended? Should this be "within the encoder" or might "contain" be made "limit" or something else? Original: QPACK is designed to contain the more complex state tracking to the encoder, while the decoder is relatively simple.
"Limit" is probably the closest if we want to keep the phrase as-is. Writing something de novo might be better, but I'm having trouble coming up with anything pithy.
Some alternatives (aka throwing mud at the wall) "The design of QPACK requires an encoder to implement relatively more-complex state tracking than a decoder." "QPACK's design requires state tracking in various degrees of complexity. In relative terms, encoders have complex requirements, while decoders are more simple. "QPACK is designed to put the state tracking complexity onus on encoders, resulting in relatively simple decoders."
I like the third one.
Fixed in with a variant of the third option.
LGTM

Discussion:
section.  An encoder MUST emit field representations in the order they appear in the input field section. <del> QPACK is designed to contain the more complex state tracking to the encoder, while the decoder is relatively simple. </del> <ins> QPACK is designed to place the burden of optional state tracking on the encoder, resulting in relatively simple decoders. </ins> 2.1.1.
Change:
Current text says: This is nice, but I'm wondering if it should be 65535. The max UDP payload for a QUIC packet is 65527, which is lower than both. It's nice for an implementation to only need to store 16-bit integers for max datagram size to avoid excess memory, and it's of course easy to round down from 65536 to 65535, but it just seems arbitrary to have it be 1 more than the max value for a 16-bit integer...
NAME thoughts?
That sounds reasonable, 65535 is fine by me. (as long as the 1s don't take longer to travel than the 0s )

Discussion:
connection with error PROTOCOL_VIOLATION.  Endpoints that wish to use DATAGRAM frames need to ensure they send a max_datagram_frame_size value sufficient to allow their peer to use them.  It is RECOMMENDED <del> to send the value 65536 in the max_datagram_frame_size transport </del> <ins> to send the value 65535 in the max_datagram_frame_size transport </ins> parameter as that indicates to the peer that this endpoint will accept any DATAGRAM frame that fits inside a QUIC packet.
Change:
There are several instances of lowercase "may" in this document. It is ambiguous if these are normative requirements or not.
Could you elaborate on why it's ambiguous? We have a reference to RFC 8174.
I sometimes assume typos :) If you're happy the present document is correct, I will close this issue
I'm not aware of errors like this, do you have any specific ones in mind?
Gah, fat fingered accidental close. The example that triggered opening this issue is below, I had to read this several times. Perhaps that's just a sign that editorial tweaks would help, regardless of the exact words in use
I can fix this
Thanks!

Discussion:
QUIC uses a more nuanced loss recovery mechanism than the DTLS handshake, which has a basic packet loss retransmission timer. <del> This may allow loss recovery to occur more quickly for QUIC data. </del> <ins> This can allow loss recovery to occur more quickly for QUIC data. </ins> QUIC datagrams, while unreliable, can support acknowledgements, allowing applications to be aware of whether a datagram was

Application protocols using datagrams are responsible for defining the semantics of the Datagram Data field, and how it is parsed.  If the application protocol supports the coexistence of multiple <del> entities using datagrams inside a single QUIC connection, it may need </del> <ins> entities using datagrams inside a single QUIC connection, it can use </ins> a mechanism to allow demultiplexing between them.  For example, using datagrams with HTTP/3 involves prepending a flow identifier to all datagrams, see I-D.schinazi-quic-h3-datagram.

and do not contribute to any per-flow or connection-wide data limit. The risk associated with not providing flow control for DATAGRAM <del> frames is that a receiver may not be able to commit the necessary resources to process the frames.  For example, it may not be able to store the frame contents in memory.  However, since DATAGRAM frames are inherently unreliable, they MAY be dropped by the receiver if the receiver cannot process them. </del> <ins> frames is that a receiver might not be able to commit the necessary resources to process the frames.  For example, it might not be able to store the frame contents in memory.  However, since DATAGRAM frames are inherently unreliable, they MAY be dropped by the receiver if the receiver cannot process them. </ins> 5.3. DATAGRAM frames employ the QUIC connection's congestion controller. <del> As a result, a connection may be unable to send a DATAGRAM frame </del> <ins> As a result, a connection might be unable to send a DATAGRAM frame </ins> generated by the application until the congestion controller allows it I-D.ietf-quic-recovery.  The sender implementation MUST either delay sending the frame until the controller allows it or drop
Change:
Warn against the pathological case of dropping packets due to pacing.
Early in our VPN implementation, we sent QUIC datagrams without any queueing, assuming that if a datagram gets dropped, then we exceeded the cwnd (and thus the estimated channel capacity), so it would likely not reach the peer anyways. In practice, this turned out to be a terrible idea that lead to underutilization of the channel; our implementation always does pacing, so if you don't queue the datagram, it will get dropped unless it just happens to fit into the current pacing quantum. Because pacing is RECOMMENDED for QUIC, I believe some form of queueing should be RECOMMENDED for datagrams, otherwise the users risk running into the same hard-to-debug problem that we had.
I think adding a note about pacing to the "Congestion Control" subsection makes sense to me.
+1, if you're in the bucket of implementations that have insight into their pacing algorithm, it should be reasonable to expect that you'd avoid dropping your own datagrams unless you make a queue and then build up too much in that queue.
Thanks!

Discussion:
it I-D.ietf-quic-recovery.  The sender implementation MUST either delay sending the frame until the controller allows it or drop the frame without sending it (at which point it MAY notify the <del> application). </del> <ins> application).  Implementations that use packet pacing SHOULD support delaying the transmission of DATAGRAM frames for at least the time it takes to send the paced packets allowed by the congestion controller to avoid dropping frames excessively. </ins> Implementations can optionally support allowing the application to specify a sending expiration time, beyond which a congestion-
Change:
RFC 9002 doesn't equivocate regarding whether probes are sent: ack-eliciting packet in the packet number space as a probe. This text uses "MAY", which strongly suggests that probes are discretionary. That's not true.

Discussion:
timing of these acknowledgements is not used for loss recovery. As with any ack-eliciting frame, when a sender suspects that a packet <del> containing only DATAGRAM frames has been lost, it MAY send probe packets to elicit a faster acknowledgement as described in Section 6.2.4 of RFC9002. </del> <ins> containing only DATAGRAM frames has been lost, it sends probe packets to elicit a faster acknowledgement as described in Section 6.2.4 of RFC9002. </ins> If a sender detects that a packet containing a specific DATAGRAM frame might have been lost, the implementation MAY notify the
Change:
The use of "SHOULD NOT" implies that a) this is discretionary, and b) that applications might be able to rely on it in some cases. I don't believe that either is true unless the protocol were specified entirely differently. (And that alternative specification wouldn't be practical anyway.)

Discussion:
is important to note that acknowledgement of a DATAGRAM frame only indicates that the transport-layer handling on the receiver processed the frame, and does not guarantee that the application on the <del> receiver successfully processed the data.  Thus, this signal SHOULD NOT replace application-layer signals that indicate successful </del> <ins> receiver successfully processed the data.  Thus, this signal cannot replace application-layer signals that indicate successful </ins> processing. 5.3.
Change:
Drop the text on acknowledgments. Then modify the congestion control thing to make the benefit clearer. A unified congestion controller can be more efficient.
-- URL This is not an application-layer signal. While the peer might have received the packet and processed it at the QUIC layer, this does not guarantee that the DATAGRAM frame contents were processed by the application. The draft already acknowledges this in . However, the treatment in the motivation could be misleading. Consider dropping this item.
-- URL Isn't it the case that they are acknowledged? (This one is just a nit, the next issue will be more serious.)

Discussion:
handshake, which has a basic packet loss retransmission timer. This can allow loss recovery to occur more quickly for QUIC data. <del> QUIC datagrams, while unreliable, can support acknowledgements, allowing applications to be aware of whether a datagram was successfully received. </del> <ins> QUIC datagrams are subject to QUIC congestion control.  Providing a single congestion control for both reliable and unreliable data can be more effective and efficient. </ins> <del> QUIC datagrams are subject to QUIC congestion control, allowing applications to avoid implementing their own. These reductions in connection latency, and application insight into the delivery of datagrams, can be useful for optimizing audio/video streaming applications, gaming applications, and other real-time network applications. </del> <ins> These features can be useful for optimizing audio/video streaming applications, gaming applications, and other real-time network applications. </ins> Unreliable QUIC datagrams can also be used to implement an IP packet tunnel over QUIC, such as for a Virtual Private Network (VPN).
Change:
I put this in Security Considerations, but I can see that is another good choice (perhaps a better one).
I agree this could also be its own subsection of section 5, but given that this really is just reiterating an existing requirement, it's also OK where it is.
Application protocols that use QUIC are required to define how 0-RTT is used. This draft doesn't really change that, but it does add to what 0-RTT can carry. In an abundance of caution, it should link to .

Discussion:
transmitted with the DATAGRAM frame, like the STREAM frame, MUST be protected either by 0-RTT or 1-RTT keys. <ins> Application protocols that allow DATAGRAM frames to be sent in 0-RTT require a profile that defines acceptable use of 0-RTT; see Section 5.6 of RFC9001. </ins> 7. This document registers a new value in the QUIC Transport Parameter
Change:
Thank you!
Rephrasing what I mentioned at the mic, imagine a scenario where an application uses DATAGRAM to send a single fixed message ("fire the missile"). An adversary on path can start selectively dropping packets and checking to see whether or not they're retransmitted to learn whether or not this special message was sent. (Retransmission detection could be done by looking at the size of the QUIC packet carrying the DATAGRAM, for example.) I don't claim this is easy to do in practice, or useful, but I think it does raise interesting questions about how this new frame affects QUIC's security posture. Perhaps some text in the security considerations is needed? (Issue copied from , by NAME on 2019-11-19)
from NAME on 2020-02-21: How would that be different from streams in ordinary QUIC? Here you can also drop packets and look for retransmissions of a specific size? If there is overlap, this issue belongs to QUIC transport security considerations in general.
I think the key here is that, in dropping the special datagram frame and not seeing anything retransmitted, one could learn something about what was sent.
If we take my recommendation in to always at least send out a PING frame/packet for PTOs or losses of DATAGRAM frame/packets then, it may mitigate this leakage some. There would always be something sent out on these selective losses. I'm not sure how hard it would be to determine if the lost packet was a DATAGRAM or not with this behavior. My guess is that it would be implementation dependent.
PING doesn't really cut it here, because presence and size matter.
Does the attacker have a way of knowing that the packet that was dropped contained a DATAGRAM, vs some other non-retransmitted frame, such as PADDING or PING or ACK?
Probably not, though I would say that the retransmission logic for those three frames could be different enough that the choice of frame might leak. Nothing much doing here, though we might note that retransmission logic might expose information that can be used for traffic analysis.

Discussion:
require a profile that defines acceptable use of 0-RTT; see Section 5.6 of RFC9001. <ins> The use of DATAGRAM frames might be detectable by an adversary on path that is capable of dropping packets.  Since DATAGRAM frames do not use transport-level retransmission, connections that use DATAGRAM frames might be distinguished from other frames using the different response to loss. </ins> 7. This document registers a new value in the QUIC Transport Parameter
Change:
and a bit of editorializing of thee text to match RFC 9000.
If you're receptive to this suggestion I am happy to file a PR
Oh wow I hadn't realized that we never updated to the new style. A PR would be lovely please!

Discussion:
DATAGRAM frames contain the following fields: <del> A variable-length integer specifying the length of the datagram in bytes.  This field is present only when the LEN bit is set.  If the LEN bit is not set, the datagram data extends to the end of the QUIC packet.  Note that empty (i.e., zero-length) datagrams are allowed. </del> <ins> A variable-length integer specifying the length of the Datagram Data field in bytes.  This field is present only when the LEN bit is set to 1.  When the LEN bit is set to 0, the Datagram Data field extends to the end of the QUIC packet.  Note that empty (i.e., zero-length) datagrams are allowed. </ins> The bytes of the datagram to be delivered.
Change:
From list discussion: What does "strongly associated" mean in this context? We should remove "strongly".
I agree, removing strongly seems best
Thank you!

Discussion:
5.1. DATAGRAM frames belong to a QUIC connection as a whole, and are not <del> strongly associated with any stream ID at the QUIC layer.  However, it is expected that applications will want to differentiate between </del> <ins> associated with any stream ID at the QUIC layer.  However, it is expected that applications will want to differentiate between </ins> specific DATAGRAM frames by using identifiers, such as for logical flows of datagrams or to distinguish between different kinds of datagrams.
Change:
could also do s/,/; but whatever.
I'm not qualified to handle this level of copy-editing, this sounds like something best suited for the RFC editor.

Discussion:
places a limit on the maximum size of DATAGRAM frames, that limit can be further reduced by the max_packet_size transport parameter and the Maximum Transmission Unit (MTU) of the path between endpoints. <del> DATAGRAM frames cannot be fragmented, therefore application protocols need to handle cases where the maximum datagram size is limited by other factors. </del> <ins> DATAGRAM frames cannot be fragmented; therefore, application protocols need to handle cases where the maximum datagram size is limited by other factors. </ins> 5.1.
Change:
In the introduction, it says "Reliability within QUIC is performed on a per-stream basis, so some frame types are not eligible for retransmission" Is it really per-stream? Some frames are retransmitted even though they aren't associated with a stream. Really, the detection mechanism is packet-based, the retransmission decision is made on a per-frame basis, and for stream-specific frames there is the added consideration of stream state (i.e. do not resend if reset) I suggest replacing the sentence above with "Some QUIC frame types are not eligible for retransmission."
Do you have examples? It's common for an action to be attempted again, but not for the frame to be retransmitted. That's not quite right. QUIC does not retransmit stream frames, it instead looks at stream state to see what data needs to be retransmitted - there's an important conceptual difference there: let's say you had 100 bytes left in your packet and therefore sent 98 bytes of stream data and that got lost but now you have a full 1200 payload available, you shouldn't retransmit that 100 byte STREAM frame and instead create a new STREAM frame with as much data as you want to send. states:
So I agree with everything you're saying factually; this is an editorial, semantic gripe about what it means that reliability is on a per-stream basis and what it means that a frame is retransmitted. It's true that, for example, MAX_DATA frames aren't resent verbatim, but RFC 9000 addresses them in a section called "retransmission of information" due to the common-sense meaning of the term. What are you trying to communicate by saying that reliability is "on a per-stream basis"?
I agree that this sentence is confusing. Perhaps we just remove it entirely? NAME NAME thoughts?
NAME NAME made a proposal with
LGTM modulo one commentLGTM

Discussion:
The QUIC Transport Protocol RFC9000 provides a secure, multiplexed connection for transmitting reliable streams of application data. <del> Reliability within QUIC is performed on a per-stream basis, so some frame types are not eligible for retransmission. </del> <ins> QUIC uses various frame types to transmit data within packets, and each frame type defines whether or not the data it contains will be retransmitted.  Streams of reliable application data are sent using STREAM frames. </ins> Some applications, particularly those that need to transmit real-time data, prefer to transmit data unreliably.  In the past, these

This document defines two new DATAGRAM QUIC frame types, which carry application data without requiring retransmissions. <del> Note that DATAGRAM frames are only meant for unreliable transmissions.  Reliable transmission is already supported by QUIC via STREAM frames. </del> Discussion of this work is encouraged to happen on the QUIC IETF mailing list quic@ietf.org [3] or on the GitHub repository which contains the draft: https://github.com/quicwg/datagram [4].
Change:
Section 5: says DATAGRAM frames MUST be protected with either 0-RTT or 1-RTT keys. I would suggest to add the "otherwise what happens" part. One/two like explanation will be helpful and I think that will improve the understanding of this requirement.
Almost all QUIC frame types are like this. I would suggest saying "Like STREAM frames, ..." to make this obvious for the rationale.

Discussion:
deliver the data to the application immediately, as long as it is able to process the frame and can store the contents in memory. <del> DATAGRAM frames MUST be protected with either 0-RTT or 1-RTT keys. </del> <ins> Like STREAM frames, DATAGRAM frames contain application data and MUST be protected with either 0-RTT or 1-RTT keys. </ins> Note that while the max_datagram_frame_size transport parameter places a limit on the maximum size of DATAGRAM frames, that limit can
Change:
RFC6973 Section 5.2.1 would be a better reference.
Ok, thanks URL

Discussion:
7. Clients that act upon a request to rate limit are potentially re- <del> identifiable (see Section 7.1 of DNS-PRIVACY) because they react to </del> <ins> identifiable (see Section 5.2.1 of PRIVACY) because they react to </ins> information that might only be given to them.  Note that this might apply to other fields too (e.g.  Retry-After).
Change:
According to URL there is no need to specify that information.
This text appears in relation to Item fields. By their nature Items can only occur on one field line (the proper terminology, btw), so this requirement is extraneous, and should be removed.
... and it's also on RateLimit-Policy, even though that is a List field.

Discussion:
The RateLimit-Policy field (see ratelimit-policy-field), might contain information on the associated time window. <del> This field MUST NOT occur multiple times and can be sent in a trailer section. </del> <ins> This field can be sent in a trailer section. </ins> 3.2.

These examples show multiple policies being returned: <del> This field MUST NOT occur multiple times and can be sent in a trailer section. </del> <ins> This field can be sent in a trailer section. </ins> 3.3.

The field is an Item and its value is a non-negative Integer expressed in service-limit.  Parameters are not allowed. <del> This field MUST NOT occur multiple times and can be sent in a trailer section. </del> <ins> This field can be sent in a trailer section. </ins> Clients MUST NOT assume that a positive RateLimit-Remaining field value is a guarantee that further requests will be served.

it mitigates the risk related to thundering herd when too many clients are serviced with the same timestamp. <del> This field MUST NOT occur multiple times and can be sent in a trailer section. </del> <ins> This field can be sent in a trailer section. </ins> An example of RateLimit-Reset field use is below.