Original text:
6. <del> This document specifies a Reno congestion controller for QUIC RFC6582. </del>  The signals QUIC provides for congestion control are generic and are designed to support different algorithms.  Endpoints can unilaterally 6.2. <del> QUIC begins every connection in slow start and exits slow start upon loss or upon increase in the ECN-CE counter.  QUIC re-enters slow start any time the congestion window is less than ssthresh, which only occurs after persistent congestion is declared.  While in slow start, QUIC increases the congestion window by the number of bytes acknowledged when each acknowledgment is processed. </del>  6.3. <del> Slow start exits to congestion avoidance.  Congestion avoidance in NewReno 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 is detected, NewReno halves the congestion window and sets the slow start threshold to the new congestion window. </del>  6.4.  A recovery period is entered when loss or ECN-CE marking of a packet is detected.  A recovery period ends when a packet sent during the recovery period is acknowledged.  This is slightly different from round trip.  During recovery, the congestion window remains unchanged irrespective of new losses or increases in the ECN-CE counter. <del> 6.5. </del>  During the handshake, some packet protection keys might not be available when a packet arrives.  In particular, Handshake and 0-RTT that might arrive before the peer has packet protection keys to process those packets. <del> 6.6. </del>  Probe packets MUST NOT be blocked by the congestion controller.  A sender MUST however count these packets as being additionally in acknowledgement is received that establishes loss or delivery of packets. <del> 6.7. </del>  When an ACK frame is received that establishes loss of all in-flight packets sent over a long enough period of time, the network is response on a Retransmission Timeout (RTO) in TCP RFC5681 after Tail Loss Probes (TLP) RACK. <del> 6.8. </del>  This document does not specify a pacer, but it is RECOMMENDED that a sender pace sending of all in-flight packets based on input from the of a flow pacer, implementers are referred to the Fair Queue packet scheduler (fq qdisc) in Linux (3.11 onwards). <del> 6.9. </del>  When bytes in flight is smaller than the congestion window and sending is not pacing limited, the congestion window is under-

Reviewer comments:
Clarifies a few points and moves the initial window recommendation from the pseudocode to the text. I could take this a bit farther, but I'd like suggestions on what's currently missing in this PR.
LGTM
It starts like this: The next sections below roughly describe the behavior of different phases of congestion control. More concrete pseudo-code is only given in the Appendix later on but it's not linked from the original section. On first reading, I missed the Appendix and felt the text lacking for concrete enough explanations to implement the feature. The question is what to describe where and what the authoritative definitions should be. If you know the NewReno RFC by heart you can probably make the right inferences to figure out how everything should work in comparison but is that how it should be? An alternative (more convenient for the reader / skimmer) approach could be to mention NewReno only in passing and then provide a complete and self-contained description of the algorithms in the congestion control section directly, maybe even inlining the pseudo-code. If that is deemed to verbose and would bore readers that know enough about those algorithms already, it would be good to provide some guidance how to read the algorithm and what the assumptions are in the introductory paragraph about congestion control.
The intent is that the text is complete without reading the referenced RFCs or pseudocode, so I think this section needs more text and possibly some inlined pseudo-code.
Hi NAME I wrote which fixes some obvious errors I found, but I think more could be done. Can you take a look and tell me what other points you'd like added or moved up from the pseudocode?
Looks good! Thanks!

Revised text:
6.  <ins> This document specifies a congestion controller for QUIC similar to TCP NewReno RFC6582. </ins> The signals QUIC provides for congestion control are generic and are designed to support different algorithms.  Endpoints can unilaterally 6.2.  <ins> QUIC begins every connection in slow start with the congestion window set to an initial value.  Endpoints SHOULD use an initial congestion window of 10 times the maximum datagram size (max_datagram_size), limited to the larger of 14720 or twice the maximum datagram size. This follows the analysis and recommendations in RFC6928, increasing the byte limit to account for the smaller 8 byte overhead of UDP compared to the 20 byte overhead for TCP. The minimum congestion window is the smallest value the congestion window can decrease to as a response to loss, ECN-CE, or persistent congestion.  The RECOMMENDED value is 2 * max_datagram_size. </ins> 6.3.  <ins> 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. 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. </ins> 6.4. <ins> 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 and sets the slow start threshold to the new congestion window. 6.5. </ins> A recovery period is entered when loss or ECN-CE marking of a packet is detected.  A recovery period ends when a packet sent during the recovery period is acknowledged.  This is slightly different from round trip.  During recovery, the congestion window remains unchanged irrespective of new losses or increases in the ECN-CE counter.  <ins> 6.6. </ins> During the handshake, some packet protection keys might not be available when a packet arrives.  In particular, Handshake and 0-RTT that might arrive before the peer has packet protection keys to process those packets.  <ins> 6.7. </ins> Probe packets MUST NOT be blocked by the congestion controller.  A sender MUST however count these packets as being additionally in acknowledgement is received that establishes loss or delivery of packets.  <ins> 6.8. </ins> When an ACK frame is received that establishes loss of all in-flight packets sent over a long enough period of time, the network is response on a Retransmission Timeout (RTO) in TCP RFC5681 after Tail Loss Probes (TLP) RACK.  <ins> 6.9. </ins> This document does not specify a pacer, but it is RECOMMENDED that a sender pace sending of all in-flight packets based on input from the of a flow pacer, implementers are referred to the Fair Queue packet scheduler (fq qdisc) in Linux (3.11 onwards).  <ins> 6.10. </ins> When bytes in flight is smaller than the congestion window and sending is not pacing limited, the congestion window is under-