Original text:
samples, estimated using a mean variation. The calculation of smoothed_rtt uses RTT samples after adjusting them <del> for acknowledgement delays.  These delays are computed using the ACK Delay field of the ACK frame as described in Section 19.3 of QUIC- </del>  TRANSPORT. The peer might report acknowledgement delays that are larger than the cases, an endpoint SHOULD subtract such local delays from its RTT sample until the handshake is confirmed. <del> smoothed_rtt and rttvar are computed as follows, similar to RFC6298. </del>  <del> When there are no samples for a network path, and on the first RTT sample for the network path: </del>  <del> Before any RTT samples are available, the initial RTT is used as rtt_sample.  On the first RTT sample for the network path, that sample is used as rtt_sample.  This ensures that the first measurement erases the history of any persisted or default values. </del>  On subsequent RTT samples, smoothed_rtt and rttvar evolve as follows: The packet is unacknowledged, in-flight, and was sent prior to an acknowledged packet. <del> Either its packet number is kPacketThreshold smaller than an </del>  acknowledged packet (packet-threshold), or it was sent long enough in the past (time-threshold). 7. <del> This document specifies a congestion controller for QUIC similar to TCP NewReno (RFC6582). </del>  The signals QUIC provides for congestion control are generic and are <del> designed to support different algorithms.  Endpoints can unilaterally choose a different algorithm to use, such as Cubic (RFC8312). </del>  <del> If an endpoint uses a different controller than that specified in this document, the chosen controller MUST conform to the congestion </del>  control guidelines specified in Section 3.1 of RFC8085. Similar to TCP, packets containing only ACK frames do not count

Reviewer comments:
Addresses .
This issue will list a number of minor editorial things that should be checked and likely addressed with some editorial fixes: Section 5.3: "These delays are computed using the ACK Delay field of the ACK frame as described in Section 19.3 of [QUIC-TRANSPORT]." This text implies that the computation of the delay is described in Section 19.3 of QUIC-TRANSPORT. However, I don't think it is described the calculation, only the definition of the field. Please reformulate to imply only field definition not calculation. Section 5.3: "On the first RTT sample for the network path, that sample is used as rttsample. This ensures that the first measurement erases the history of any persisted or default values." I think this intended to cover cases where path changes are detected. But it is not well expressed. Does this need a reformulation and a reference into QUIC-TRANSPORT where it states when such a reset should occur? Section 6.1: "Either its packet number is kPacketThreshold smaller than an acknowledged packet" Nitpicking, assuming no PN gaps in transmission. Does that need a note? Section 6.2.4: "An endpoint MAY send up to two full-sized datagrams containing ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single lost datagram or transmit data from multiple packet number spaces." This last part, I assume intended to generate additional datagrams to prevent single loss to impact. However, due to coalescing this is unclear in this context. Section 7: "Endpoints can unilaterally choose a different algorithm to use, such as Cubic ([RFC8312])." I think this sentence should be explicit that in needs to be sender-based algorithms. I think we need to have the requirement on performing congestion control on the sender unless there has been explicit agreement with the receiver that they will do it. Section 7.2: "Endpoints SHOULD use an initial congestion window of 10 times the maximum datagram size (maxdatagramsize), limited to the larger of 14720 bytes or twice the maximum datagram size." "maximum datagram size" is not used in Transport there need to be alignment here of what name to use. Transport has Maximum Packet Size, which appears to match the definition in the appendix of maxdatagram_size.
Thanks for your careful review, NAME -- these are good finds! I've addressed your comments below and in . I'll address point 6 in a separate PR. Section 19.3 has the following text, which does tell how to compute acknowledgement delay from the ACK Delay field: I've replaced "computed" with "decoded" in the recovery document to make it clearer. Coalescing applies to packets, not to datagrams. We've explicitly stated that a sender could send 2 datagrams to avoid any effects of coalescing. I think the text is pretty clear on this: "An endpoint MAY send up to two full-sized datagrams containing ack-eliciting packets". I've added "sender-side" to make the controller more explicit. To your point about making this a sender requirement, that is covered in the transport doc (end of ):
Based on and , labeling this as "editorial"
I think these issues are resolved once the two PRs are completely ready.
In Section 5.3: "When there are no samples for a network path, and on the first RTT sample for the network path: smoothedrtt = rttsample rttvar = rttsample / 2 Before any RTT samples are available, the initial RTT is used as rttsample. On the first RTT sample for the network path, that sample is used as rttsample. This ensures that the first measurement erases the history of any persisted or default values." First of all this text uses "rttsample" while other places with the exception of the pseudo code uses latestrtt variable. There are two issues with that. First that the value of rttsample is state dependent. If there exist an latestrtt then that is used, if not the initial rtt. As the initial RTT is defined in Section 6.2.2 I think a forward reference is in place. Finally, should this calculation in cases where latestrtt exists be using minackdelay?
I like to add that there are some structural issues in Section 6.2.1 and 6.2.2 where the initial value depends on both section.
Based on , labeling this as "editorial"
The PR resolves this issue.
OK, thanks GitHub for saving and duplicating my comments...Looks good and appear to resolve the uncertainties I had.

Revised text:
samples, estimated using a mean variation. The calculation of smoothed_rtt uses RTT samples after adjusting them  <ins> for acknowledgement delays.  These delays are decoded from the ACK Delay field of ACK frames as described in Section 19.3 of QUIC- </ins> TRANSPORT. The peer might report acknowledgement delays that are larger than the cases, an endpoint SHOULD subtract such local delays from its RTT sample until the handshake is confirmed.  <ins> Similar to RFC6298, smoothed_rtt and rttvar are computed as follows. </ins>  <ins> An endpoint initializes the RTT estimator during connection establishment and when the estimator is reset during connection migration; see Section 9.4 of QUIC-TRANSPORT.  Before any RTT samples are available for a new path or when the estimator is reset, the estimator is initialized using the initial RTT; see pto-handshake. </ins>  <ins> smoothed_rtt and rttvar are initialized as follows, where kInitialRtt contains the initial RTT value: RTT samples for the network path are recorded in latest_rtt; see latest-rtt.  On the first RTT sample after initialization, the estimator is reset using that sample.  This ensures that the estimator retains no history of past samples. On the first RTT sample after initialization, smoothed_rtt and rttvar are set as follows: </ins> On subsequent RTT samples, smoothed_rtt and rttvar evolve as follows: The packet is unacknowledged, in-flight, and was sent prior to an acknowledged packet.  <ins> The packet was sent kPacketThreshold packets before an </ins> acknowledged packet (packet-threshold), or it was sent long enough in the past (time-threshold). 7.  <ins> This document specifies a sender-side congestion controller for QUIC similar to TCP NewReno (RFC6582). </ins> The signals QUIC provides for congestion control are generic and are  <ins> designed to support different sender-side algorithms.  A sender can unilaterally choose a different algorithm to use, such as Cubic (RFC8312). </ins>  <ins> If a sender uses a different controller than that specified in this document, the chosen controller MUST conform to the congestion </ins> control guidelines specified in Section 3.1 of RFC8085. Similar to TCP, packets containing only ACK frames do not count