Original text:
6.4. <del> To correctly implement congestion control, a QUIC sender tracks every ack-eliciting packet until the packet is acknowledged or lost.  It is expected that implementations will be able to access this information by packet number and crypto context and store the per-packet fields (sent-packets-fields) for loss recovery and congestion control. After a packet is declared lost, it SHOULD be tracked for an amount of time comparable to the maximum expected packet reordering, such as 1 RTT.  This allows for detection of spurious retransmissions. Sent packets are tracked for each packet number space, and ACK processing only applies to a single space. 6.4.1. The packet number of the sent packet. A boolean that indicates whether a packet is ack-eliciting.  If true, it is expected that an acknowledgement will be received, though the peer could delay sending the ACK frame containing it by up to the MaxAckDelay. A boolean that indicates whether the packet counts towards bytes in flight. A boolean that indicates whether the packet contains cryptographic handshake messages critical to the completion of the QUIC handshake.  In this version of QUIC, this includes any packet with the long header that includes a CRYPTO frame. The number of bytes sent in the packet, not including UDP or IP overhead, but including QUIC framing overhead. The time the packet was sent. 6.5. 6.5.1. Constants used in loss recovery are based on a combination of RFCs, papers, and common practice.  Some may need to be changed or negotiated in order to better suit a variety of environments. Maximum reordering in packets before packet threshold loss detection considers a packet lost.  The RECOMMENDED value is 3. Maximum reordering in time before time threshold loss detection considers a packet lost.  Specified as an RTT multiplier.  The RECOMMENDED value is 9/8. Timer granularity.  This is a system-dependent value.  However, implementations SHOULD use a value no smaller than 1ms. The RTT used before an RTT sample is taken.  The RECOMMENDED value is 100ms. 6.5.2. Variables required to implement the congestion control mechanisms are described in this section. Multi-modal timer used for loss detection. The number of times all unacknowledged CRYPTO data has been retransmitted without receiving an ack. The number of times a PTO has been sent without receiving an ack. The time the most recent ack-eliciting packet was sent. The time the most recent crypto packet was sent. The packet number of the most recently sent packet. The largest packet number acknowledged in the packet number space so far. The most recent RTT measurement made when receiving an ack for a previously unacked packet. The smoothed RTT of the connection, computed as described in The RTT variance, computed as described in The minimum RTT seen in the connection, ignoring ack delay. The maximum amount of time by which the receiver intends to delay acknowledgments, in milliseconds.  The actual ack_delay in a received ACK frame may be larger due to late timers, reordering, or lost ACKs. The time at which the next packet will be considered lost based on exceeding the reordering window in time. An association of packet numbers to information about them. Described in detail above in tracking-sent-packets. 6.5.3. At the beginning of the connection, initialize the loss detection variables as follows: 6.5.4. After a packet is sent, information about the packet is stored.  The parameters to OnPacketSent are described in detail above in sent- packets-fields. Pseudocode for OnPacketSent follows: 6.5.5. When an ACK frame is received, it may newly acknowledge any number of packets. Pseudocode for OnAckReceived and UpdateRtt follow: 6.5.6. When a packet is acknowledged for the first time, the following OnPacketAcked function is called.  Note that a single ACK frame may newly acknowledge several packets.  OnPacketAcked must be called once for each of these newly acknowledged packets. OnPacketAcked takes one parameter, acked_packet, which is the struct detailed in sent-packets-fields. Pseudocode for OnPacketAcked follows: 6.5.7. QUIC loss detection uses a single timer for all timeout loss detection.  The duration of the timer is based on the timer's mode, which is set in the packet and timer events further below.  The function SetLossDetectionTimer defined below shows how the single timer is set. This algorithm may result in the timer being set in the past, particularly if timers wake up late.  Timers set in the past SHOULD fire immediately. Pseudocode for SetLossDetectionTimer follows: 6.5.8. When the loss detection timer expires, the timer's mode determines the action to be performed. Pseudocode for OnLossDetectionTimeout follows: 6.5.9. DetectLostPackets is called every time an ACK is received and operates on the sent_packets for that packet number space.  If the loss detection timer expires and the loss_time is set, the previous largest acknowledged packet is supplied. Pseudocode for DetectLostPackets follows: 6.6. </del> The majority of constants were derived from best common practices among widely deployed TCP implementations on the internet. Exceptions follow. sender should not consider itself application limited if it would have fully utilized the congestion window without pacing delay. <del> 7.10. 7.10.1. Constants used in congestion control are based on a combination of RFCs, papers, and common practice.  Some may need to be changed or negotiated in order to better suit a variety of environments. The sender's maximum payload size.  Does not include UDP or IP overhead.  The max packet size is used for calculating initial and minimum congestion windows.  The RECOMMENDED value is 1200 bytes. Default limit on the initial amount of data in flight, in bytes. Taken from RFC6928.  The RECOMMENDED value is the minimum of 10 * kMaxDatagramSize and max(2* kMaxDatagramSize, 14600)). Minimum congestion window in bytes.  The RECOMMENDED value is 2 * kMaxDatagramSize. Reduction in congestion window when a new loss event is detected. The RECOMMENDED value is 0.5. Number of consecutive PTOs required for persistent congestion to be established.  The rationale for this threshold is to enable a sender to use initial PTOs for aggressive probing, as TCP does with Tail Loss Probe (TLP) TLP RACK, before establishing persistent congestion, as TCP does with a Retransmission Timeout (RTO) RFC5681.  The RECOMMENDED value for kPersistentCongestionThreshold is 2, which is equivalent to having two TLPs before an RTO in TCP. 7.10.2. Variables required to implement the congestion control mechanisms are described in this section. The highest value reported for the ECN-CE counter by the peer in an ACK frame.  This variable is used to detect increases in the reported ECN-CE counter. The sum of the size in bytes of all sent packets that contain at least one ack-eliciting or PADDING frame, and have not been acked or declared lost.  The size does not include IP or UDP overhead, but does include the QUIC header and AEAD overhead.  Packets only containing ACK frames do not count towards bytes_in_flight to ensure congestion control does not impede congestion feedback. Maximum number of bytes-in-flight that may be sent. The time when QUIC first detects a loss, causing it to enter recovery.  When a packet sent after this time is acknowledged, QUIC exits recovery. Slow start threshold in bytes.  When the congestion window is below ssthresh, the mode is slow start and the window grows by the number of bytes acknowledged. 7.10.3. At the beginning of the connection, initialize the congestion control variables as follows: 7.10.4. Whenever a packet is sent, and it contains non-ACK frames, the packet increases bytes_in_flight. 7.10.5. Invoked from loss detection's OnPacketAcked and is supplied with the acked_packet from sent_packets. 7.10.6. Invoked from ProcessECN and OnPacketsLost when a new congestion event is detected.  May start a new recovery period and reduces the congestion window. 7.10.7. Invoked when an ACK frame with an ECN section is received from the peer. 7.10.8. Invoked by loss detection from DetectLostPackets when new packets are detected lost. </del> 8. 8.1.

Reviewer comments:
This seems like an unwieldy PR, so I'll state what I've done. I've simply moved all pseudocode to the appendix with no changes to text, except for the addition of a single sentence at the beginning of the appendices. It might be easier to see the rendered draft . Subsequent PRs will clean each part up.
This is a good start. I expect some of the text in the pseudocode sections will need to move up, but one step at a time.

Revised text:
6.4.  The majority of constants were derived from best common practices among widely deployed TCP implementations on the internet. Exceptions follow. sender should not consider itself application limited if it would have fully utilized the congestion window without pacing delay.  8. 8.1.