Draft: draft-ietf-quic-recovery

Commentary: Clarifies the cases when the PTO needs to be recomputed and possibly reset . This was not in a single place before . 
 : merging this so it makes -28 . Filing a separate issue for the leftover editorial fix . 
 ( deleted comment , because the initially mentioned problem was incorrect . the requirement to arm the PTO timer after the handshake finishes is in Section 5.2.2 ) 
 There 's some architectural inconsistency around the treatment of 1RTT PTOs at the end of the handshake . On the one hand , we are not supposed to set the PTO timer for 1RTT before the handshake is complete . This is to prevent us from retransmitting stuff the peer may not be able to process . On the other hand , we are supposed to arm the PTO timer when the handshake is confirmed . This is the point where we 're guaranteed that the peer has receive keys . So there is a weird gap between handshake complete and handshake confirmed where new 1RTT packets will arm the PTO , but outstanding  or 1RTT packets from before handshake complete will not have an active PTO timer . This is n't the end of the world -- the connection will recover -- but it does n't make any sense , and could result in either excessive PTO delays , or 1RTT probes that the peer ca n't decode . 
 can we get a status update ? 
 The PTO is always armed when there are bytes in flight(except when the loss timer is armed ) , it 's just a matter of what PN spaces it can be armed for at a given point in time . Once the connection is handshake complete , it 's immediately allowed to arm it for inflight 1 - RTT ack - eliciting packets . Re - reading the text , I could n't find anything explicitly calling out that the alarm may need to be recomputed and reset in the handshake confirmed case , though it is stated for discarding keys . As clarified in when the client is handshake complete but not confirmed , it is unsure whether the server has Handshake keys or ApplicationData keys , but it 's very unlikely to have both . As such , sending something ack - eliciting from both PN spaces is safest .
Paragraph (version A):
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.
Paragraph (version A):
When a PTO timer expires, the PTO backoff MUST be increased,
resulting in the PTO period being set to twice its current value.
The PTO period is set based on the latest RTT information after
receiving an acknowledgement.  The PTO backoff is reset upon
receiving an acknowledgement unless it's a client unsure if the the
server has validated the client's address.  Not resetting the backoff
during peer address validation ensures the client's anti-deadlock
timer is not set too aggressively when the server is slow in
responding with handshake data.
Paragraph (version B):
A sender recomputes and may need to reset its PTO timer every time an
ack-eliciting packet is sent or acknowledged, when the handshake is
confirmed, or when Initial or Handshake keys are discarded.  This
ensures the PTO is always set based on the latest RTT information and
for the last sent packet in the correct packet number space.
Paragraph (version B):
When ack-eliciting packets in multiple packet number spaces are in
flight, the timer MUST be set for the packet number space with the
earliest timeout, with one exception.  The ApplicationData packet
number space (Section 4.1.1 of QUIC-TLS) MUST be ignored until the
handshake completes.  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.
Paragraph (version B):
When a PTO timer expires, the PTO backoff MUST be increased,
resulting in the PTO period being set to twice its current value.
The PTO backoff factor is reset when an acknowledgement is received,
except in the following case.  A server might take longer to respond
to packets during the handshake than otherwise.  To protect such a
server from repeated client probes, the PTO backoff is not reset at a
client that is not yet certain that the server has finished
validating the client's address.  That is, a client does not reset
the PTO backoff factor on receiving acknowledgements until it
receives a HANDSHAKE_DONE frame or an acknowledgement for one of its
Handshake or 1-RTT packets.