Original text:
round trip.  During recovery, the congestion window remains unchanged irrespective of new losses or increases in the ECN-CE counter.  6.6. During the handshake, some packet protection keys might not be

Reviewer comments:
Similar to TCP as described in Section 5 of RFC 6675
Should we restrict this to retransmittable frames that were lost in the packet? If it was a small packet, can I pack to the MTU? What about pure ACKs that I've declared lost?
Those are great questions. There are two goals in my mind. The first is to ensure loss recovery is not unnecessarily slower than TCP. The second is to ensure this behavior isn't significantly more aggressive than TCP. But within those bounds, I'm inclined to not be too restrictive, if that makes sense? Suggestions welcome if you think they'd be an improvement.
Well the pedantic answer is that TCP would only detect a loss if there was something in the bytestream. the QUIC equivalents would then be any packet that contained STREAM, CRYPTO, MAXSTREAMDATA, etc, plus any packet that flipped the key update bit. But not ACK, MAX_DATA, and other things that are in the TCP header. That is obviously a dumb way to approach things. I don't actually have a strong opinion on this one way of the other, but if I read the draft correctly, the loss of an ACK-only packet will affect cwnd in QUIC but not TCP (granted, a cwnd-constrained endpoint sending pure ACKs is a corner case). So I guess I'd err on the side of permitting the packet in response to loss of an ACK, as we're already quite a bit less aggressive than TCP in that case. Anyway, do we want any normative language against, say, using this permission to send high-priority new data instead of the lost data?
Adding language against sending new data or data besides data that's been lost couples the "can I send" with "what should I send" questions more than I would like unless it's absolutely critical. FYI, to be declared lost, it must be in-flight: URL "A packet is declared lost if it meets all the following conditions: The packet is unacknowledged, in-flight, and was sent prior to an acknowledged packet."
Ah, I think we're fine then.
TCP recommends that a sender retransmit a packet immediately upon detecting the first loss in a recovery window (see Section 3.2, second para, of RFC 5681; Section 5 of RFC 6675 seems to follow the same idea). QUIC should at least allow the same. Not doing this can delay loss recovery by 0.5 RTT, which is not great. This replaces ; this is a more correct description of the problem, which is a design issue.
Discussed in ZRH. Proposed resolution is to get a PR done.

Revised text:
round trip.  During recovery, the congestion window remains unchanged irrespective of new losses or increases in the ECN-CE counter. <ins> 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. </ins> 6.6. During the handshake, some packet protection keys might not be