Handshake processing delays and impact on recovery

[Jana Iyengar <[e-mail]>]

I'd like to bring this slightly tricky issue under the wg's eyes.
Discussions so far have yielded a strategy that I propose further below.
This summarizes conversations in 3821
<https://github.com/quicwg/base-drafts/issues/3821> and 3874
<https://github.com/quicwg/base-drafts/pull/3874> (and the outcomes might
touch 3889 <https://github.com/quicwg/base-drafts/issues/3889>). The
purpose of this email is to see if we can agree on the strategies outlined
here, so we can move forward on the PR there and/or other associated issues
and PRs.

Problems:

During the handshake, an endpoint can receive packets (carrying data or
acknowledgements) that it cannot decrypt because the requisite keys are not
yet available. This can happen because the crypto machinery at the endpoint
is waiting for earlier packets to be received to yield the keys. Similarly,
a client might not be able to read 1-RTT packets received from the server
because it is waiting for certificate validation to complete.

1.

The assumption in the TLS specification is that when an endpoint is busy
doing something (certificate validation or key generation for instance), it
won't be able to respond to received packets with acknowledgements (Section
4.1.4
<https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#section-4.1.4-1>).

Contrary to the assumption in the spec, Chrome and Firefox both process the
certificate chain asynchronously, and therefore acks handshake packets
immediately, even the ones that arrive after they have started verifying
the certificate chain. But they buffer 1-RTT packets, and therefore the
issue exists for 1-RTT packets.

As a result, there's potential delay, sometimes significant, in responding
to some packets during the handshake. There are two side effects of this.

S1.

First, this means that an endpoint that runs a PTO timer and retransmits
data for 0-RTT and 1-RTT packets while the handshake is still in progress
might be doing this quite unnecessarily. The peer may well have received
this data and have queued it, waiting to be able to decrypt it.

S2.

Second, acks for these packets that are buffered and then later decrypted
and read can be sent much later than when the packets were received at the
peer, causing the ack_delay to potentially be much higher than the
advertised max_ack_delay. The endpoint ignores ack_delay larger than
max_ack_delay, and this inflates the smoothed_rtt and rtt_variance,
potentially inflating the PTO significantly (which can cause handshakes to
fail if the endpoint employs a "handshake timeout" period).


Proposed Solutions:

S1.

To solve the first problem, we already have a condition in the recovery
draft to _not_ arm the PTO on 1-RTT data until the handshake is
complete (Section
6.2.1
<https://quicwg.org/base-drafts/draft-ietf-quic-recovery.html#section-6.2.1-6>).
This is not quite adequate, since it still allows a client to arm a PTO
timer on 1-RTT data on sending a CFIN and 1-RTT data, before ensuring that
the server has received the CFIN. The proposed solution here is to change
this condition from "handshake complete" to "handshake confirmed". Meaning
that an endpoint only arms a PTO timer on 0-RTT or 1-RTT data when it knows
that the peer has the keys necessary to read and write in 1-RTT, and can
therefore respond with an ACK.

We think this holds up, but we'd like to get this under everyone's eyes, to
ensure that the discussion isn't missing subtle deadlock issues.

S2.

To solve the second problem, the proposal is to use ack_delay as reported
by the endpoint that buffers the data appropriately. ack_delay is the
amount of the time the information (regardless of that being the packet
itself or the acknowledgement) being buffered intentionally. For this, we
need the following:

- endpoints MUST report an ack_delay that is the sum of the controlled
delay (i.e. the duration of the data and the ack being buffered)

- endpoints ignore max_ack_delay for acknowledgements of packets that were
sent prior to handshake confirmation. Those are the ones that might have
been buffered at the peer until keys were ready.

In addition, we explicitly recommend endpoints that asynchronously process
handshake messages to buffer 1-RTT packets, instead of dropping them, as
dropping packets has significant impact on congestion control. Note that
this matches what those implementations already do.



Thoughts?


- jana