Discuss Application-Limited Sending

draft-ietf-quic-recovery.md

@@ -984,6 +984,15 @@ The recovery period limits congestion window reduction to once per round trip.
 During recovery, the congestion window remains unchanged irrespective of new
 losses or increases in the ECN-CE counter.
 
+## Ignoring Loss of Undecryptable Packets
+
+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.
+
 ## Probe Timeout
 
 Probe packets MUST NOT be blocked by the congestion controller.  A sender MUST
@@ -1049,23 +1058,6 @@ acknowledgements, due to pacing.  In this case, the sender should not consider
 themselves application limited and should allow the congestion window to
 increase.
 
-## Discarding Packet Number Space State
-
-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.
-
 ## Pseudocode
 
 ### Constants of interest {#cc-consts-of-interest}