Ping-pong while the TLS asynchronously processes ClientHello

[kazuho]

From Transport draft; section 8.1: To prevent this deadlock, clients MUST send a packet on a probe timeout (PTO, see Section 6.2 of [QUIC-RECOVERY]).
From TLS draft; section 4.1.4: While waiting for TLS processing to complete, ... (snip). An endpoint SHOULD continue to respond to packets that can be processed during this time.

These two statements together lead to a ping-pong of packets when the server-side TLS stack takes time in generating ServerHello. That's because every time the client sends an Initial probe, the server will be acknowledging that packet immediately.

Note that there are cases where the server might actually spend time in generating ServerHello:

• the TLS stack might be slow and the public key crypto can be heavyweight (e.g., post-quantum)
• the TLS stack might have to load per-SNI setting (e.g., certificates, cipher-suites that can be used) from a remote location
• a QUIC server and the TLS backend might be positioned at different locations (something analogous to https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/)

Note: This issue has been spun off from #4183 (comment), as it is not related to PMTU.

[gloinul]

@kazuho do I understand this correctly, this is primarily an efficiency issue, as retransmissions of the initial will be going back and forth during the time until the server can send its ServerHello to the client?

So if the server wouldn't ACK the initial then the PTO timer will fire after 0.5 seconds in the client. But in case if the server ACKs then the PTO will be updated based on the actual RTT between client and server and thus occur much more frequently in most cases.

So what would be the fix, to change the recommendation on ACKing until the server hello is available on the initial?

[ianswett]

I believe this issue was discussed in the past(#3546), and the solution we reached consensus on was to not reset pto_count on the client until it knows the server has completed address validation. ie:

// Reset pto_count unless the client is unsure if
// the server has validated the client's address.
if (PeerCompletedAddressValidation()):
pto_count = 0

[kazuho]

@ianswett Thank you for pointing out that this is a duplicate of #3546 and that we have a fix. I missed the "don't reset" clause in the recovery draft.

We can close this issue.