Explain asymmetric confirmation condition

draft-ietf-quic-recovery.md

@@ -589,6 +589,14 @@ necessary, to allow the server to continue sending data. If Handshake keys
 are available to the client, it MUST send a Handshake packet, and otherwise
 it MUST send an Initial packet in a UDP datagram of at least 1200 bytes.
 
+If the handshake is complete, but not confirmed (see Section 4.1.1 and Section
+4.1.2 of {{QUIC-TLS}}), in addition to sending unacknowledged CRYPTO data in a
+probe packet, endpoints SHOULD send an ack-eliciting 1-RTT packet.  This can be
+coalesced with Handshake packets, even if there is sufficient unacknowledged
+CRYPTO data outstanding to consume the entire PMTU.  Sending an ack-eliciting
+1-RTT packet provides a peer with the opportunity to confirm the handshake and
+allow all state associated with Handshake packets to be discarded.
+
 Because Initial packets containing only PADDING do not elicit an
 acknowledgement, they may never be acknowledged, but they are removed from
 bytes in flight when the client gets Handshake keys and the Initial keys are
@@ -1221,17 +1229,18 @@ OnLossDetectionTimeout():
   if (loss_time != 0):
     // Time threshold loss Detection
     DetectLostPackets(pn_space)
-    SetLossDetectionTimer()
-    return
-
-  if (endpoint is client without 1-RTT keys):
-    // Client sends an anti-deadlock packet: Initial is padded
-    // to earn more anti-amplification credit,
-    // a Handshake packet proves address ownership.
-    if (has Handshake keys):
-      SendOneHandshakePacket()
-    else:
+  if (endpoint is client &&
+      handshake is not confirmed):
+    // Client sends an anti-deadlock packet
+    if (does not have Handshake keys):
+      // Pad Initial to earn more anti-amplification credit.
       SendOnePaddedInitialPacket()
+    else if (has 1-RTT keys):
+      // Send Handshake coalesced with 1-RTT.
+      SendOneHandshakePacketAnd1Rtt()
+    else:
+      // Send a Handshake packet.
+      SendOneHandshakePacket()
   else:
     // PTO. Send new data if available, else retransmit old data.
     // If neither is available, send a single PING frame.

draft-ietf-quic-tls.md

@@ -391,6 +391,15 @@ sent with 1-RTT keys, and the highest value of the Largest Acknowledged field
 in any received 1-RTT ACK frame: once the latter is higher than or equal to the
 former, the handshake is confirmed.
 
+Note:
+
+: Unless ack-eliciting packets protected by 1-RTT keys are sent by an endpoint,
+  the handshake might never be confirmed by an endpoint.  If the peer does
+  confirm the handshake, this could result in perpetual transmission of
+  Handshake packets, which cannot be acknowledged.  To avoid this problem, in
+  addition to retransmitting Handshake packets, endpoints can send ack-eliciting
+  packets after the handshake is complete until the handshake is confirmed.
+
 
 ### Sending and Receiving Handshake Messages