Subject: [quicwg/base-drafts] Ping-pong while the TLS asynchronously processes ClientHello (#4217)

From: Kazuho Oku <[email-masked]>
Date: Thu, 15 Oct 2020 02:31:15 -0700

>From [Transport draft; section 8.1](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-8.1-5): _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](https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#section-4.1.4-3): _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:
* a QUIC server might be slow and the public key crypto can be heavyweight (e.g., post-quantum)
* a QUIC server might have to lead 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 https://github.com/quicwg/base-drafts/issues/4183#issuecomment-708886097, as it is _not_ related to PMTU.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 15 Oct 2020 06:33:00 -0700

@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? 

-- 
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/4217#issuecomment-709327326

---

From: ianswett <[email-masked]>
Date: Thu, 15 Oct 2020 07:50:27 -0700

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`

-- 
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/4217#issuecomment-709378242

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 15 Oct 2020 16:04:25 -0700

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

-- 
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/4217#issuecomment-709634666

---

From: ianswett <[email-masked]>
Date: Thu, 15 Oct 2020 16:29:48 -0700

Closed #4217.

-- 
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/4217#event-3883956972