Re: [quicwg/base-drafts] Allow endpoints to generate traffic keys asynchronously (#3874)

[Martin Thomson <[e-mail]>]

@martinthomson commented on this pull request.



> @@ -518,14 +518,20 @@ or when Initial or Handshake keys are discarded. This ensures the PTO is always
 set based on the latest RTT information and for the last sent packet in the
 correct packet number space.
 
+When setting the PTO timer, the ApplicationData packet number space (Section
+4.1.1 of {{QUIC-TLS}}) MUST be ignored until the handshake completes. PTO is not
+armed because issues other than packet loss might prevent an endpoint from
+receiving an acknowledgement. A receiver might lack the keys necessary to
+process packets, or the sender might lack the keys necessary to process
+acknowledgments. This occurs when the client sends 0-RTT packets as the server
+might not accept 0-RTT and the client will not have 1-RTT keys for processing
+acknowledgments until the handshake completes. This occurs for 1-RTT packets as
+either endpoint might not have the ability to read until the handshake is
+complete or confirmed.

```suggestion
complete.
```

Confirmation tells us that our peer has a completed handshake.  This is not a useful state here, because we are talking about a specific endpoint and their ability to read doesn't depend on confirmation.

I was questioning whether we should block probing more.  That is, until the handshake is confirmed.  That has performance implications, because you don't probe for longer, but it does mean that you never probe without being sure that the probe can be answered.

I suspect that there is a trade-off here.  Waiting for handshake complete is not perfect, but it is close enough that it is good enough.  Ideally we could run experiments to tell us when spurious losses due to keys not being available and set a policy based on that.  Because that is ultimately what this is: a policy that we use to protect the core recovery algorithm.

Maybe that suggests a different answer: we are going to pick a point at which we recommend that probing starts.  That will be imperfect and that's OK.  To that end, this MUST seems like a problem.

-- 
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/3874#pullrequestreview-445275426