Subject: Re: [quicwg/base-drafts] Don't send PING in Initial or Handshake (#2642)

From: Martin Thomson <[email-masked]>
Date: Thu, 09 May 2019 02:28:02 -0700

Still holding on a note about congestion.  I will merge and open another issue if that doesn't happen soon-ish.

-- 
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/pull/2642#issuecomment-490829596

---

From: ianswett <[email-masked]>
Date: Thu, 09 May 2019 12:07:05 +0000 (UTC)

I'll do that today.

-- 
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/pull/2642#issuecomment-490876017

---

From: ianswett <[email-masked]>
Date: Thu, 09 May 2019 06:22:05 -0700

@ianswett pushed 1 commit.

48515326114d51844be3d6c3e7a4538bf9dbadf1  Add an explanation for why this PADDING-only is ok

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2642/files/6450287646cac4f23bd72be6e11d1babbb8af1d9..48515326114d51844be3d6c3e7a4538bf9dbadf1

---

From: ianswett <[email-masked]>
Date: Thu, 09 May 2019 06:24:12 -0700

I added  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.

-- 
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/pull/2642#issuecomment-490902721

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 09 May 2019 13:03:46 -0700

kazuho approved this pull request.

-- 
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/pull/2642#pullrequestreview-235795690

---

From: ianswett <[email-masked]>
Date: Fri, 10 May 2019 01:16:46 -0700

Now that I've started a PR to combine the crypto handshake timer and PTO, I'm concerned I chose the wrong fix for #2640 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.

@janaiyengar I'd like your thoughts on this in particular.

-- 
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/pull/2642#issuecomment-491202104

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 10 May 2019 17:36:47 -0700

janaiyengar commented on this pull request.

> @@ -538,11 +538,14 @@ 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.
+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.
+
+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.

Suggested rewording:
"Because the server will eventually discard Initial and Handshake keys, and because packets containing only PADDING frames do not elicit an acknowledgement, it is possible that no acknowledgement is ever received for these additional packets.  They are however eventually removed from the count of bytes in flight when the client discards the corresponding keys (see {{discarding-keys}})."

-- 
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/pull/2642#pullrequestreview-236353686

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 10 May 2019 17:48:46 -0700

@ianswett: 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 don'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 #2655).

-- 
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/pull/2642#issuecomment-491465487

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 10 May 2019 19:23:17 -0700

Um. Ok. This is attached to an issue that is labeled `transport` and now has consensus declared on it with this PR. I'm fried right now, but let's discuss this before doing anything.

-- 
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/pull/2642#issuecomment-491471865

---

From: MikkelFJ <[email-masked]>
Date: Fri, 10 May 2019 23:11:58 -0700

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. An exception may be the natural thing if the PTO logic is in fact separate anyway in the different PN spaces.

-- 
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/pull/2642#issuecomment-491483383

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 14 May 2019 15:14:46 -0700

Merged #2642 into master.

-- 
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/pull/2642#event-2341596654