Subject: [quicwg/base-drafts] Prioritize Handshake probe packet over Short packet (#3583)

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Tue, 14 Apr 2020 23:55:17 -0700

The packet number space that endpoint should send probe packet is
determined by GetEarliestTimeAndSpace function.  It chooses
packet number space where the latest packet has earliest dispatch
time.

Suppose client sent 2 packets: Handshake(client_handshake#0) and
Short packet(client_short#0).

Somehow it didn't get any ACK for them, on first PTO timeout, it
resent Handshake (client_handshake#1).  This makes Short packet
number space becomes the earliest packet number space and next
PTO timeout, client sent Short probe packet assuming that
IsHandshakeCompleted() means handshake completion not handshake
confirmation.  I think it should instead send Handshake probe
packet in this case.  We have unified PTO timer and sending probe
in alternate manner is a bit strange.

-- 
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/3583

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 Apr 2020 00:09:24 -0700

I agree that this is weird.  It's worse than you describe because the exponent on the intervals between Handshake packets is 4, not 2.  We send probes (just a PING) when probing the short packet as recommended, so it isn't too, too bad, but it is also not that great.

I looked into this in mozilla/neqo#448 if people want more context.  I didn't have the time to think through what the ideal solution might be.

-- 
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/3583#issuecomment-613858546

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Wed, 15 Apr 2020 06:23:27 -0700

As discussed in neqo issue thread, which packet number spaces should be chosen depends on the situation.
ngtcp2 sends Initial and Handshake probes at the same time if server sees they are in-flight when PTO timer fires so that it can coalesce them and also handle the situation that client might drop Initial key.  This is a deviation from the draft-27.
For the particular situation that this issue describes, I think client can just send Handshake probe packet.  If server still has Handshake key, it will respond with Handshake packet.  If not, then it will send HANDSHAKE_DONE frame in Short packet, and client confirms handshake completion.
Sending Short probe with Handshake packet might reduce the time before client reacts the lost Short packet, but might be discarded if server does not have appropriate key.

-- 
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/3583#issuecomment-614037710

---

From: ianswett <[email-masked]>
Date: Thu, 23 Apr 2020 13:04:35 -0700

In this case, I believe alternating is the right thing to do, because the server either has Handshake receive keys or 1-RTT receive keys, and the client doesn't know which.  Because of HANDSHAKE_DONE, the client will eventually complete the handshake and drop the Handshake PN space as long as the client's Handshake packet(containing the finished) gets to the server.

However, this case is an excellent motivation for this text:
> In addition to sending data in the packet number space for which the timer expired, the sender SHOULD send ack-eliciting packets from other packet number spaces with in-flight data, coalescing packets if possible.

This text was written prior to HANDSHAKE_DONE, but I think there may be other reasons to use handshake complete and not confirmed in this case, so I would be very hesitant to change it without a lot of consideration.

Is there a part of mozilla/neqo#448  I should focus on?  The text talks a lot about packets being marked as lost when the PTO timer fires, which makes me very confused, since QUIC doesn't mark packets as lost when the PTO fires.

-- 
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/3583#issuecomment-618634815

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Apr 2020 21:47:59 -0700

Leaving aside that recommendation for the moment (which I agree is close to mandatory), the experience is pretty poor if there is only one key.  You just moved to a 4x exponent on the PTO timer rather than a 2x timer.  I guess that's why we have the recommendation.

(For reference, neqo tells the frame sending apparatus that it lost some data when a PTO timer fires.  That causes those older frames to be sent again rather than trying to find fresh data to send.  That's on the principle that older data is more important.  But that isn't relevant to this discussion.  The main comment to look at is [this one](https://github.com/mozilla/neqo/pull/448#issuecomment-590001888), which shows how the interleaving can be a little janky.)

I realize that we haven't reconciled this with the requirement not to arm the application data PTO when there are handshake/initial packets outstanding.  That might limit this to the one case of interleaving Initial and Handshake.

-- 
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/3583#issuecomment-618799323

---

From: ianswett <[email-masked]>
Date: Fri, 24 Apr 2020 13:40:25 -0700

Yes, you move to 4x instead of 2x, but it's worth understanding what packets need to be lost for the 2x vs 4x to come into play.

1) The client's Handshake packet is lost twice in a row.  Not that unlikely, but it's known the Client Finished blocks the server from processing 1-RTT packets, so I think there's an understanding of its importance.
2) (case from this issue) The client's Handshake packet is delivered, but the ACK is lost so the client retransmits it then that packet is lost AND both the first HANDSHAKE_DONE packet and its retransmission are lost.

I'm sure there are many other permutations of these, but the first case seems a lot more likely than the second case.

In this case, the HANDSHAKE_DONE does a nice job of mitigating some potential issues.

-- 
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/3583#issuecomment-619228874

---

From: ianswett <[email-masked]>
Date: Tue, 28 Apr 2020 15:30:51 -0700

Closed #3583 via #3597.

-- 
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/3583#event-3282368838