Draft: draft-ietf-quic-recovery

Commentary: That would actually resolve itself , because at some point , the client would send a Handshake packet with data in it , and cause all the outstanding PADDING packets to be acked . If all the client 's packets are lost and the server is stuck in deadlock , the handshake is doomed anyway . 
 It 's probably worth acknowledging the edge case and just saying that this protocol does n't do anything about that . Note that the case we 're concerned about should involve the server sending tons of data , which gives it plenty of opportunity to provide the client with an ACK that will unstick it . 
 LGTM , once you 've the note about congestion . 
 Still holding on a note about congestion . I will merge and open another issue if that does n't happen soon - ish . 
 I 'll do that today . 
 I description of why I believe this is not a problem . Conveniently , the logic is simpler than I previously stated , because of the fast Initial -Handshake transition when the client gets Handshake keys . 
 Now that I 've started a PR to combine the crypto handshake timer and PTO , I 'm concerned I chose the wrong fix for in this PR , and it would be better to allow PING in Initial . In the existing PTO case when there are bytes in flight , but nothing to send , we say " When there is no data to send , the sender SHOULD send a PING or other ack - eliciting frame in a single packet , re - arming the PTO timer . " If we allow PING in Initial , that text will work fine with a combined timer , since all Initials must be in padded datagrams . Otherwise , combining them adds a slightly odd special case . I 'd like your thoughts on this in particular . 
 Good catch ! It 's useful to go back to the principle we have in place : if we want a PTO running , we need to have an ack - eliciting packet outstanding . I do n't think there 's a strong enough argument to create an exception here , so I agree that we should change this to always sending a PING when the timer goes off and there 's nothing to send . Since the title here is quite clearly the opposite of that , in the interest of transparency , I propose that you close this PR in favor of a new one that says send PING ( and stack this new PR on top of ) . 
 Um . Ok . This is attached to an issue that is labeled and now has consensus declared on it with this PR . I 'm fried right now , but let 's discuss this before doing anything . 
 In my view the point of not sending PING early is to reduce the complexity of the early packet number spaces and allow special code to handle these . The fewer types of packets and ACK 's here the better . However , if PING ends up simplifying this logic , then certainly there is an argument for that . The question then is : would PING ' complicate ACK logic in early packet number spaces ? That would only really be the case if there were no ACK 's otherwise since PING 's are easy to handle . OTOH - if it is only a matter of cleaning up two paragraphs in the spec it may not be worthwhile to allow early PING . An exception may be the natural thing if the PTO logic is in fact separate anyway in the different PN spaces . 
 Note that I did n't include this in the changelog for -21 . It seems entirely editorial to my reading . 
 The says : PING frames are forbidden in both Initial and Handshake packets . 
 The smallest change is to only send PADDING without a PING , since the purpose here is to allow the server to send , not for the client to receive an ACK . The PING does n't really add any value . 
 Sorry for the churn . I sent out the smallest fix possible . We can also change the transport doc to allow PING in Initial and Handshake . Functionally , I do n't think it matters for recovery , but both are reasonable options in my opinion . 
 There 's this weird edge case where you might run out of cwnd , because PADDING counts towards in - flight but is not ack - eliciting , but it seems safe to ignore that one . If you do n't receive and acknowledgment for that many packets right at the beginning of the connection , something is going seriously wrong anyway .
Paragraph (version A):
Because the server could be blocked until more packets are received,
the client MUST ensure that the crypto retransmission timer is set if
there is unacknowledged crypto data or if the client does not yet
have 1-RTT keys.  If the crypto retransmission 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 send a
new packet, containing only PING or 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.
Paragraph (version B):
Because the server could be blocked until more packets are received,
the client MUST ensure that the crypto retransmission timer is set if
there is unacknowledged crypto data or if the client does not yet
have 1-RTT keys.  If the crypto retransmission 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 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.
Paragraph (version B):
Because packets only containing 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.