Change:
By not arming the alarm, we avoid the possibility of having the alarm expire, send nothing, and then be immediately re-armed over and over again. We've hit bugs like that a few times in our implementation, which is why I prefer this structure of not setting the alarm if you can't send anything.
From NAME in , this is not a nit: than three times as many bytes as the number of bytes they have received. I think that the intent was that the server limit its sending, including PTO.
Discussed in ZRH. Proposed resolution is "yes".
Repeating what I said earlier: it's not clear to me that not being able to arm the PTO timer when at the limit implies that PTO packets count against the amplification limit. The reason is that you could have already armed the PTO timer at the time you hit the limit. E.g., you might be streaming 0.5RTT and so send Initial, Handshake, arm timer, 0.5RTT.
NAME the PTO should be updated when an ack-eliciting packet is sent, since the right edge moves, so that case should already be handled correctly. I'll write an editorial PR to try to make all this extra clear. Actually, the PTO section already has "A sender computes its PTO timer every time an ack-eliciting packet is sent."
Not sure how to split the difference between the limit applying to the packet that was just sent (causing PTO to be armed) or the packet that arming the PTO timer implies. Personally, I would have put the test at the point that you send a packet, but that's not how this is structured, and you do have "because packets sent on PTO count against the anti-amplification limit", which captures the important concept neatly.

Discussion:
pto-handshake) for a new path, but the delay SHOULD NOT be considered an RTT sample. <del> Until the server has validated the client's address on the path, the amount of data it can send is limited to three times the amount of data received, as specified in Section 8.1 of QUIC-TRANSPORT.  If no data can be sent, then the PTO alarm MUST NOT be armed until datagrams have been received from the client. 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, and has not received a HANDSHAKE_DONE frame. </del> 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 incorrect RTT estimate at the client.  To allow the client to

keys indicates forward progress and the loss detection timer might have been set for a now discarded packet number space. <ins> 5.2.2.1. Until the server has validated the client's address on the path, the amount of data it can send is limited to three times the amount of data received, as specified in Section 8.1 of QUIC-TRANSPORT.  If no additional data can be sent, the server's PTO alarm MUST NOT be armed until datagrams have been received from the client, because packets sent on PTO count against the anti-amplification limit.  Note that the server could fail to validate the client's address even if 0-RTT is accepted. 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, and has not received a HANDSHAKE_DONE frame. </ins> 5.2.3. When a server receives an Initial packet containing duplicate CRYPTO