Original text:
The PTO value MUST be set to at least kGranularity, to avoid the timer expiring immediately. <del> A sender computes its PTO timer every time an ack-eliciting packet is sent.  When ack-eliciting packets are in-flight in multiple packet number spaces, the timer MUST be set for the packet number space with the earliest timeout, except for ApplicationData, which MUST be ignored until the handshake completes; see Section 4.1.1 of QUIC-TLS. Not arming the PTO for ApplicationData prevents a client from retransmitting a 0-RTT packet on a PTO expiration before confirming that the server is able to decrypt 0-RTT packets, and prevents a server from sending a 1-RTT packet on a PTO expiration before it has the keys to process an acknowledgement. </del>  When a PTO timer expires, the PTO period MUST be set to twice its current value.  This exponential reduction in the sender's rate is is no data available to send.  An endpoint MAY send up to two full- sized datagrams containing ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single lost datagram or <del> transmit data from multiple packet number spaces. </del>  In addition to sending data in the packet number space for which the timer expired, the sender SHOULD send ack-eliciting packets from skip a packet number to eliminate the ack delay. When the PTO timer expires, and there is new or previously sent <del> unacknowledged data, it MUST be sent. </del>  It is possible the sender has no new or previously-sent data to send. As an example, consider the following sequence of events: new expiration increases resilience to packet drops, thus reducing the probability of consecutive PTO events. <del> Probe packets sent on a PTO MUST be ack-eliciting.  A probe packet SHOULD carry new data when possible.  A probe packet MAY carry retransmitted unacknowledged data when new data is unavailable, when flow control does not permit new data to be sent, or to opportunistically reduce loss recovery delay.  Implementations MAY use alternative strategies for determining the content of probe packets, including sending new or retransmitted data based on the application's priorities. </del> When the PTO timer expires multiple times and new data cannot be sent, implementations must choose between sending the same payload every time or sending different payloads.  Sending the same payload

Reviewer comments:
When writing , I found some of the text organization to be odd, so this moves it some.

Revised text:
The PTO value MUST be set to at least kGranularity, to avoid the timer expiring immediately.  <ins> A sender recomputes and may need to reset its PTO timer every time an ack-eliciting packet is sent.  When ack-eliciting packets are in- flight in multiple packet number spaces, the timer MUST be set for the packet number space with the earliest timeout, except for ApplicationData, which MUST be ignored until the handshake completes; see Section 4.1.1 of QUIC-TLS.  Not arming the PTO for ApplicationData prevents a client from retransmitting a 0-RTT packet on a PTO expiration before confirming that the server is able to decrypt 0-RTT packets, and prevents a server from sending a 1-RTT packet on a PTO expiration before it has the keys to process an acknowledgement. </ins> When a PTO timer expires, the PTO period MUST be set to twice its current value.  This exponential reduction in the sender's rate is is no data available to send.  An endpoint MAY send up to two full- sized datagrams containing ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single lost datagram or  <ins> transmit data from multiple packet number spaces.  All probe packets sent on a PTO MUST be ack-eliciting. </ins> In addition to sending data in the packet number space for which the timer expired, the sender SHOULD send ack-eliciting packets from skip a packet number to eliminate the ack delay. When the PTO timer expires, and there is new or previously sent  <ins> unacknowledged data, it MUST be sent.  A probe packet SHOULD carry new data when possible.  A probe packet MAY carry retransmitted unacknowledged data when new data is unavailable, when flow control does not permit new data to be sent, or to opportunistically reduce loss recovery delay.  Implementations MAY use alternative strategies for determining the content of probe packets, including sending new or retransmitted data based on the application's priorities. </ins> It is possible the sender has no new or previously-sent data to send. As an example, consider the following sequence of events: new expiration increases resilience to packet drops, thus reducing the probability of consecutive PTO events.  When the PTO timer expires multiple times and new data cannot be sent, implementations must choose between sending the same payload every time or sending different payloads.  Sending the same payload