Subject: [quicwg/base-drafts] Server sends Handshake probe packet which does not attribute to any progress (#3582)

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

Suppose the following situation:

- Upon reception of client Initial, server sent Handshake(server_handshake#0) and Short(server_short#0) packets.
- server_short#0 was lost.
- client received server_handshake#0 and sent packet containing ClientFinished Handshake(client_handshake#0)
- client_handshake#0 was lost.
- server resent Handshake(server_handshake#1)
- client received server_handshake#1 and sent packet containing ACK only Handshake(client_handshake#1)
- server received client_handshake#1

At this point, server has still bytes_in_flight > 0 because it
has in-flight Short packet.  According to the current recovery
draft, OnLossDetectionTimeout instructs server to send Handshake
probe packet because handshake has not completed yet.  I'm not
sure what this packet is intended for. server has no in-flight
data for Handshake packet number space.  Client will send ACK for
it, but it does not progress any handshake state.

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Apr 2020 23:42:17 -0700

Presumably the server will be probing for server_short[0] here.  The handshake probe is recommended, but I agree that if the handshake is done, there is no need for it, but it isn't mandatory.

-- 
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/3582#issuecomment-613848060

---

From: ianswett <[email-masked]>
Date: Thu, 23 Apr 2020 12:48:12 -0700

Q: I assume the server sent and the client received server_initial#0 as well in this example?

The interesting text is:
> When ack-eliciting packets are in-flight in multiple packet number spaces, the timer MUST be set for the packet number space with the earliest timeout, except for ApplicationData, which MUST be ignored until the handshake completes; see Section 4.1.1 of {{QUIC-TLS}}. Not arming the PTO for ApplicationData prevents a client from retransmitting a 0-RTT packet on a PTO expiration before confirming that the server is able to decrypt 0-RTT packets, and prevents a server from sending a 1-RTT packet on a PTO expiration before it has the keys to process an acknowledgement.

In this case, the text says to not arm PTO for ApplicationData until handshake complete and there's nothing in flight in Initial or Handshake, so I don't believe the PTO alarms should be set, so "server resent Handshake(server_handshake#1)" would never occur.

Admittedly, this text can be hard to read(it's certainly hard to write), so if you have any editorial suggestions, that'd be welcome.

-- 
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/3582#issuecomment-618624984

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Tue, 28 Apr 2020 02:30:24 -0700

The text looks good.  It looks like the pseudo code does not capture it though.  Currently, it says:

```py
  if (no ack-eliciting packets in flight &&
      PeerCompletedAddressValidation()):
```

There is no condition to check handshake completion there.  I'm not sure how the pseudo code should be precise in this regard.

-- 
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/3582#issuecomment-620491017

---

From: ianswett <[email-masked]>
Date: Tue, 28 Apr 2020 13:36:06 -0700

Good point, I tried to fix that in #3604 

-- 
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/3582#issuecomment-620840416