Change:
client does not yet have 1-RTT keys.  If the probe timer expires before the client has 1-RTT keys, it is possible that the client may not have any crypto data to retransmit.  However, the client MUST <del> send a new packet, containing only PADDING frames if 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. 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 discarded. </del> <ins> send a new packet to allow the server to continue sending data.  At this stage in the connection, when few to none RTT samples have been generated, it is possible that the probe timer expiration is due to an incorrect RTT estimate at the client.  To allow the client to improve its RTT estimate, the new packet that it sends MUST be ack- eliciting.  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. Initial packets and Handshake packets may never be acknowledged, but they are removed from bytes in flight when the Initial and Handshake keys are discarded. </ins> 6.3.1.

Discussion:
which discusses sending an ack-eliciting packet instead of a PADDING only packet to unblock the server.
So, currently PING frames can only be sent in 0/1-RTT as per the TLS mapping draft URL AFAICT the issue of allowing PING frames in Initial/Handshake packets was discussed in URL which was in turn fixed by URL by saying to only send PADDING frames in probe packets. But then URL came along which changed the same text by saying that probes need to be ACK-eliciting. Notably it says: In the case where no other frame needs to be sent, but 1-RTT keys are not available, an implementation can send an empty CRYPTO frame to achieve the above as suggested by NAME so I proposed an editorial change in URL to expand the suggestion in -recovery to mention that, since I think it's something that would be easy to miss (and indeed, I don't think my implementation is the only one that got this wrong). However some people seem to prefer allowing PING frames in Initial/Handshake in the first place (which is a design change), so maybe we should discuss this more. That anyone knows, is there any reason why PING frames are not allowed in Initial/Handshake? Proposed change in .
While I am fine with allowing PING frames in Initial and Handshake, I wonder what the benefit is. IIUC, the reason of sending PINGs in case of PTO is to see if a previously sent ack-eliciting packet has reached the peer. That is determined by the peer sending an ACK. However, in case of Initial and Handshake packets, the only case when PTO fires and you do not have any data to send is when the endpoints are ready to switch to the next epoch. To rephrase, I think there might be a high chance of the endpoint not receiving an ACK due to the peer dropping the Initial keys (or the Handshake keys). Considering that, I am not sure if it is a good advice to suggest endpoints send PINGs on PTO. Rather, I think it might be worthwhile to suggest that when discarding a packet number space, unconfirmed loss does not affect the CWND.

Regarding my comment above, NAME points out that there is no such issue, as because the loss would never be confirmed in such case (due to the peer never sending an ACK). I agree.
Yes, that seems right. The packets you send in the old packet number space might as well have never happened once you discard state for that space.
The case that I found interop was that my client and one packet's worth of unacknowledged data. In the 1-RTT case, I'd just send the data in the first probe and then a PING in the second probe. Since I can't do that for Handshake, I have two unattractive options: send only one probe, reducing the probability of success introduce special logic to spread out the data into two packets with a CRYPTO frame (gross)
NAME : So, you are in favor of sending PINGs in the handshake, right?
NAME IIUC, CRYPTO(off=0,len=0) can be used as a replacement for PING. There is no need to have special logic to spread out the data. So it's not as gross as it seems. That said, considering the fact that we have PING in 1-RTT even though CRYPTO(off=0,len=0) can be used instead in 1-RTT also, I do not think there is a reason to argue against having PINGs for Initial and Handshake too.
NAME It is the most straightforward way to send PTO and I see no downside, so yes. That said, I know that many of our mechanisms (e.g. discarding keys) bake in assumptions about the handshake and who sends what and when, so maybe we should examine the implications of, for example, a client sending a Handshake PING before it gets any Handshake packets from the server.
When there is nothing to send today, the text says you can send a PADDING only packet. These packets will be removed from flight when Initial keys are dropped, but it may never be acknowledged, which loses some congestion control signal, including RTT measurements. For PTO, we decided you always send a PING if PTO expires and there's nothing to send. It seems like we should say the same for the handshake case now that it's part of PTO?

This came from Ryan's comment on
Not sure that this helps all that much. Even though you might be eliciting an acknowledgment, you will still lose the packet when you discard keys, which could still happen. All you have done is increase the work that the recipient needs to perform.
It doesn't help that much, but it's a lot more consistent with the rest of the PTO design, so I think it's preferable.
In discussing our PTO strategy yesterday I realized that you only send a packet if you have something ack- eliciting outstanding. Would you not want to send that again?
Sometimes you can't send that again once the handshake is confirmed(there's an example in the text, but the easiest is something unreliable like DATAGRAM). Prior to handshake confirmation, the client needs to drive the handshake to confirmation so it may have to send something, as your PR discusses
Makes sense to me. I hadn't considered data that isn't retransmitted after loss, which is a little embarrassing.
This seems reasonable. The RTT estimate could be quite wrong at this stage in the connection, so an ack-eliciting packet can be used to improve that as well.
This looks good.Looks good to me, for what it's worth our implementation always bundles a PING in here if there is nothing else ack-eliciting to send.