diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md
index 2d585a94da..89c8ab9b8f 100644
--- a/draft-ietf-quic-recovery.md
+++ b/draft-ietf-quic-recovery.md
@@ -494,19 +494,15 @@ A connection MAY use the delay between sending a PATH_CHALLENGE and receiving
 a PATH_RESPONSE to seed initial_rtt for a new path, but the delay SHOULD NOT
 be considered an RTT sample.
 
-Until the server has validated the client's address on the path, the amount of
-data it can send is limited, as specified in Section 8.1 of {{QUIC-TRANSPORT}}.
 Data at Initial encryption MUST be retransmitted before Handshake data and
 data at Handshake encryption MUST be retransmitted before any ApplicationData
-data.  If no data can be sent, then the PTO alarm MUST NOT be armed until
-data has been received from the client.
+data.
 
-Since the server could be blocked until more packets are received from the
-client, it is the client's responsibility to send packets to unblock the server
-until it is certain that the server has finished its address validation
-(see Section 8 of {{QUIC-TRANSPORT}}).  That is, the client MUST set the
-probe timer if the client has not received an acknowledgement for one of its
-Handshake or 1-RTT packets.
+Until the server has validated the client's address on the path, the amount of
+data it can send is limited, as specified in Section 8.1 of {{QUIC-TRANSPORT}}.
+If the limit has been reached when the PTO expires, a single packet containing
+a PING with no PADDING MUST be sent.  This packet elicits a full-sized Initial
+packet from the client, allowing the server to send data again.
 
 Prior to handshake completion, when few to none RTT samples have been
 generated, it is possible that the probe timer expiration is due to an
@@ -1150,18 +1146,9 @@ OnLossDetectionTimeout():
     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):
-      SendOneAckElicitingHandshakePacket()
-    else:
-      SendOneAckElicitingPaddedInitialPacket()
-  else:
-    // PTO. Send new data if available, else retransmit old data.
-    // If neither is available, send a single PING frame.
-    SendOneOrTwoAckElicitingPackets()
+  // PTO. Send new data if available, else retransmit old data.
+  // If neither is available, send a single PING frame.
+  SendOneOrTwoAckElicitingPackets()
 
   pto_count++
   SetLossDetectionTimer()
diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md
index eab7626fa1..142aeef4ea 100644
--- a/draft-ietf-quic-transport.md
+++ b/draft-ietf-quic-transport.md
@@ -1592,10 +1592,11 @@ server has successfully processed a Handshake packet from the client, it can
 consider the client address to have been validated.
 
 Prior to validating the client address, servers MUST NOT send more than three
-times as many bytes as the number of bytes they have received.  This limits the
-magnitude of any amplification attack that can be mounted using spoofed source
-addresses.  In determining this limit, servers only count the size of
-successfully processed packets.
+times as many bytes as the number of bytes they have received, except upon the
+probe timeout expiring, when servers can send a single PING-only packet.
+This limits the magnitude of any amplification attack that can be mounted
+using spoofed source addresses.  In determining this limit, servers only count
+the size of successfully processed packets.
 
 Clients MUST ensure that UDP datagrams containing Initial packets have UDP
 payloads of at least 1200 bytes, adding padding to packets in the datagram as