Original text:
at any encryption level, whereas those associated with transferring data can only appear in the 0-RTT and 1-RTT encryption levels: <del> PADDING frames MAY appear in packets of any encryption level. </del>  CRYPTO and CONNECTION_CLOSE frames MAY appear in packets of any encryption level except 0-RTT.

Reviewer comments:
This is an alternative to .
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.
This may duplicate a previous issue, but there has been a lot of aggressive closing. Instead of using "quic hp", etc. we should use a label that reflects the QUIC version. Assuming I am counting correctly, we can do: "qxxxxxxxx hp" where xx is the version in hex. This would match TLS practice.
My expectation was that we would have "quic" and then "quic2", etc... Maybe that doesn't have the effect that is desired, because it's less obvious, but I prefer to proceed as though this were the only version.
Martin's suggested plan SGTM.
I don't strongly object, but it seems like if we know this is v1, we might want to indicate that, but ultimately I agree it's a matter of taste
Tokyo conclusion: NAME and NAME will sort this out.
London discussion: NAME and NAME to resume work
If the expansions are revised, could we get rid of spaces then?
I don't think that would be advisable. We should keep this as close to TLS practice as possible.
Discussed in Montreal, close with no action
Looks good to me. I think PING should be allowed everywhere.

Revised text:
at any encryption level, whereas those associated with transferring data can only appear in the 0-RTT and 1-RTT encryption levels:  <ins> PADDING and PING frames MAY appear in packets of any encryption level. </ins> CRYPTO and CONNECTION_CLOSE frames MAY appear in packets of any encryption level except 0-RTT.