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

From: Alessandro Ghedini <[email-masked]>
Date: Sun, 15 Sep 2019 04:06:41 -0700

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 23 Sep 2019 19:35:23 -0700

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 determine 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.

-- 
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#issuecomment-534362384

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 23 Sep 2019 22:48:29 -0700

Regarding my comment above, @janaiyengar 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.

-- 
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#issuecomment-534399583

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Sep 2019 22:53:57 -0700

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.

-- 
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#issuecomment-534400961