Draft: draft-ietf-quic-tls

Commentary: This is an alternative to . 
 So , currently PING frames can only be sent in 0/1 - RTT as per the TLS mapping draft AFAICT the issue of allowing PING frames in Initial / Handshake packets was discussed in which was in turn fixed by by saying to only send PADDING frames in probe packets . But then 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 so I proposed an editorial change in to expand the suggestion in -recovery to mention that , since I think it 's something that would be easy to miss ( and indeed , I do n'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 , 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 ca n'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 ) 
 : So , you are in favor of sending PINGs in the handshake , right ? 
 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 . 
 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  is the version in hex . This would match TLS practice . 
 My expectation was that we would have " quic " and then "  " , etc ... Maybe that does n'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 do n'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 : and will sort this out . 
 London discussion : and to resume work 
 If the expansions are revised , could we get rid of spaces then ? 
 I do n'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 .
Paragraph (version A):
PADDING frames MAY appear in packets of any encryption level.
Paragraph (version B):
PADDING and PING frames MAY appear in packets of any encryption
level.