Original text:
6.2.1.2. <del> As described in Section 17.5.1 of QUIC-TRANSPORT, endpoints stop sending and receiving Initial packets once they start exchanging Handshake packets.  At this point, all loss recovery state for the Initial packet number space is also discarded.  Packets that are in flight for the packet number space are not declared as either acknowledged or lost.  After discarding state, new Initial packets will not be sent. </del>  6.2.2. 7.5.  Probe packets MUST NOT be blocked by the congestion controller.  A sender MUST however count these packets as being additionally in flight, since these packets adds network load without establishing is functionally similar to a sender's response on a Retransmission Timeout (RTO) in TCP RFC5681. <del> 7.6. </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> 7.7. </del>  A sender becomes idle if it ceases to send data and has no bytes in flight.  A sender's congestion window MUST NOT increase while it is A sender MAY implement alternate mechanisms to update its congestion window after idle periods, such as those proposed for TCP in RFC7661. <del> 7.8. When keys for a packet number space are discarded, any in-flight packets sent with those keys are removed from the count of bytes in flight.  Loss recovery state is also discarded, so no loss events will occur for any in-flight packets from that space (see discard- initial).  Note that it is expected that keys are discarded after those packets would be declared lost, but Initial secrets are destroyed earlier. When 0-RTT is rejected, all in-flight 0-RTT packets are removed from the count of bytes in flight.  Loss recovery state is also discarded, so no loss events will occur for any in-flight 0-RTT packets. If a server accepts 0-RTT, but does not buffer 0-RTT packets that arrive before Initial packets, early 0-RTT packets will be declared lost, but that is expected to be infrequent. </del> 7.9. 7.9.1.

Reviewer comments:
Ignore the loss of Handshake, 0-RTT, and 1-RTT packets if the peer doesn't have the keys to process them. Also unifies the text on discarding keys and no longer implies that 0-RTT has it's own packet number space. Replaces
merging this one as well to get this in -18.
A few comments, editorial.

Revised text:
6.2.1.2.  <ins> When packet protection keys are discarded (see Section 4.9 of QUIC- TLS), all packets that were sent with those keys can no longer be acknowledged because their acknowledgements cannot be processed anymore.  The sender considers them no longer in flight.  That is, the sender SHOULD discard all recovery state associated with those packets and MUST remove them from the count of bytes in flight. Endpoints stop sending and receiving Initial packets once they start exchanging Handshake packets (see Section 17.2.2.1 of QUIC- TRANSPORT).  At this point, recovery state for all in-flight Initial packets is discarded. When 0-RTT is rejected, recovery state for all in-flight 0-RTT packets is discarded. If a server accepts 0-RTT, but does not buffer 0-RTT packets that arrive before Initial packets, early 0-RTT packets will be declared lost, but that is expected to be infrequent. It is expected that keys are discarded after packets encrypted with them would be acknowledged or declared lost.  Initial secrets however might be destroyed sooner, as soon as handshake keys are available (see Section 4.10 of QUIC-TLS). </ins> 6.2.2. 7.5. <ins> During the handshake, some packet protection keys might not be available when a packet arrives.  In particular, Handshake and 0-RTT packets cannot be processed until the Initial packets arrive, and 1-RTT packets cannot be processed until the handshake completes. Endpoints MAY ignore the loss of Handshake, 0-RTT, and 1-RTT packets that might arrive before the peer has packet protection keys to process those packets. 7.6. </ins> Probe packets MUST NOT be blocked by the congestion controller.  A sender MUST however count these packets as being additionally in flight, since these packets adds network load without establishing is functionally similar to a sender's response on a Retransmission Timeout (RTO) in TCP RFC5681.  <ins> 7.7. </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> 7.8. </ins> A sender becomes idle if it ceases to send data and has no bytes in flight.  A sender's congestion window MUST NOT increase while it is A sender MAY implement alternate mechanisms to update its congestion window after idle periods, such as those proposed for TCP in RFC7661.  7.9. 7.9.1.