[quicwg/base-drafts] Allow PING in Initial/Handshake? (#3034)

[Alessandro Ghedini <[e-mail]>]

So, currently PING frames can only be sent in 0/1-RTT as per the TLS mapping draft
https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#rfc.section.4

AFAICT the issue of allowing PING frames in Initial/Handshake packets was discussed in https://github.com/quicwg/base-drafts/issues/2640 which was in turn fixed by https://github.com/quicwg/base-drafts/pull/2642 by saying to only send PADDING frames in probe packets. But then https://github.com/quicwg/base-drafts/pull/2912 came along which changed the same text by saying that probes need to be ACK-eliciting.

Notably it says:

> To allow the client to improve its RTT estimate, the new packet that it sends MUST be ack-eliciting.  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.

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 @tatsuhiro-t, so I proposed an editorial change in https://github.com/quicwg/base-drafts/pull/3033 to expand the suggestion in -recovery to mention that, since I think it's something that would be easy to miss (and indeed, I don'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?

(I'll make a PR shortly to help discussion)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3034