Original text:
7.3. <del> While in slow start, QUIC increases the congestion window by the number of bytes acknowledged when each acknowledgment is processed, resulting in exponential growth of the congestion window. </del>  <del> QUIC exits slow start upon loss or upon increase in the ECN-CE counter.  When slow start is exited, the congestion window halves and the slow start threshold is set to the new congestion window.  QUIC re-enters slow start any time the congestion window is less than the slow start threshold, which only occurs after persistent congestion is declared. </del>  7.4. <del> Slow start exits to congestion avoidance.  Congestion avoidance uses an Additive Increase Multiplicative Decrease (AIMD) approach that increases the congestion window by one maximum packet size per congestion window acknowledged.  When a loss or ECN-CE marking is detected, NewReno halves the congestion window, sets the slow start threshold to the new congestion window, and then enters the recovery period. </del>  7.5. <del> A recovery period is entered when loss or ECN-CE marking of a packet is detected in congestion avoidance after the congestion window and slow start threshold have been decreased.  A recovery period ends when a packet sent during the recovery period is acknowledged.  This is slightly different from TCP's definition of recovery, which ends when the lost packet that started recovery is acknowledged. </del>  The recovery period aims to limit congestion window reduction to once per round trip.  Therefore during recovery, the congestion window remains unchanged irrespective of new losses or increases in the ECN- CE counter. <del> When entering recovery, a single packet MAY be sent even if bytes in flight now exceeds the recently reduced congestion window.  This speeds up loss recovery if the data in the lost packet is retransmitted and is similar to TCP as described in Section 5 of RFC6675.  If further packets are lost while the sender is in recovery, sending any packets in response MUST obey the congestion window limit. </del> 7.6. During the handshake, some packet protection keys might not be connection flow control limits and so no advantage is gained by doing so. <del> Endpoints choose the congestion controller that they use.  Though congestion controllers generally treat reports of ECN-CE markings as equivalent to loss (RFC8311), the exact response for each controller could be different.  Failure to correctly respond to information about ECN markings is therefore difficult to detect. </del>  9.

Reviewer comments:
Includes some changes suggested in (see below) ISSUE: /When a loss or ECN-CE marking is detected, NewReno halves the congestion window, sets the slow start threshold to the new congestion window, and then enters the recovery period./ The requirement is that TCP needs to reduce after CE, The RFC series does not now say it needs to halve, it could for example follow the reduction method specified in RFC8511. e.g. /When a loss or ECN-CE marking is detected, the sender must reduce the cwnd. NewReno halves the congestion window, sets the slow start threshold to the new congestion window, and then enters the recovery period. [RFC8511] specifies an alternate cwnd reduction./ ISSUE: Similar comment in 8.3: /Though congestion controllers generally treat reports of ECN-CE markings as equivalent to loss [RFC8311], the exact response for each controller could be different. / This does not seem correct. Could I suggest: /Congestion controllers respond to reports of ECN-CE by reducing their rate. Markings can be treated as equivalent to loss [RFC3168], but other responses can be specified (e.g. [RFC8511]) [RFC8311]. /
This was filed a while ago (before WGLC ended), didn't want to drop it.
Editorial, design?
There is a design issue here regarding the initial congestion window that I would like to see split out into a new issue (which can be marked design). The rest appear to be things we can address with editorial changes.
NAME I moved the IW text into , though I'm not sure I think it's worth revisiting.
Thanks :) I agree that it isn't worth re-opening, but we did sign on to at least discuss whether it is worth discussing.
Do we have a plan for this one?
So, is there a plan? (Is there even anything left to do?)
Some of these are addressed already, others are in an accidental commit(), and for some there's no need to address them in the text. The rest are in
As it stands, the recovery draft does not require the congestion window to be reduced on loss. The only part that talks about this is in Section 7.4, which says: We need to require this reduction for the controller to be a NewReno controller.
To clarify, this isn't a change in what we're describing, you just want to add normative language?

Revised text:
7.3.  <ins> While in slow start, a NewReno sender increases the congestion window by the number of bytes acknowledged when each acknowledgment is processed, resulting in exponential growth of the congestion window. </ins>  <ins> A sender MUST exit slow start and enter recovery when a loss is detected or when the ECN-CE counter reported by the peer increases. A sender re-enters slow start any time the congestion window is less than the slow start threshold, which only occurs after persistent congestion is declared. </ins> 7.4.  <ins> A NewReno sender in congestion avoidance uses an Additive Increase Multiplicative Decrease (AIMD) approach that MUST increase the congestion window by no more than one maximum datagram size per congestion window acknowledged. A sender MUST exit congestion avoidance and enter recovery when a loss is detected or when the ECN-CE counter reported by the peer increases. </ins> 7.5.  <ins> A NewReno sender enters the recovery period when it detects loss or an ECN-CE mark is received.  A recovery period ends when a packet sent during the recovery period is acknowledged. On entering a recovery period, a sender MUST set the slow start threshold to half the value of the congestion window at the moment that loss is detected.  The congestion window MUST be set to the reduced value of the slow start threshold before exiting the recovery period. Implementations MAY set the congestion window immediately on entering a recovery period or use other mechanisms, such as Proportional Rate Reduction (PRR), to reduce it more gradually.  If the congestion window is reduced immediately, a single packet can be sent prior to reduction.  This speeds up loss recovery if the data in the lost packet is retransmitted and is similar to TCP as described in Section 5 of RFC6675. </ins> The recovery period aims to limit congestion window reduction to once per round trip.  Therefore during recovery, the congestion window remains unchanged irrespective of new losses or increases in the ECN- CE counter.  7.6. During the handshake, some packet protection keys might not be connection flow control limits and so no advantage is gained by doing so.  <ins> Endpoints choose the congestion controller that they use.  Congestion controllers respond to reports of ECN-CE by reducing their rate, but the response may vary.  Markings can be treated as equivalent to loss (RFC3168), but other responses can be specified, such as (RFC8511) or (RFC8311). </ins> 9.