Re: [quicwg/base-drafts] Desirable behavior when it takes time to derive the traffic keys for the next PN space (#3821)

[ianswett <[e-mail]>]

> @ianswett
> 
> > But what if there are no Initial ACKs received and ACK with the large ack_delay is the first ACK of the connection? I guess you're stuck with one bad sample and hope the next is better?
> 
> That's correct. The resolution proposed by @janaiyengar does not mitigate that issue. By including queuing delay of unencryptable packets into ack_delay, the proposed resolution improves the quality of RTT samples. But as you say, it does not mitigate the case where that would be the first sample.
> 
> > It doesn't seem onerous to add a "SHOULD process all packets in the current datagram and all buffered packets before sending an ACK to avoid generating multiple inflated RTT samples" to me?
> 
> I'm not sure if doing that mitigates the problem. The proposed resolution recommends endpoints to send ACK for a handshake message before spending time to process it. As an example, a client would ack the Handshake packets before starting to verify the certificate chain. And after that, it would send a Handshake packet (that contains ClientFinished only, no ack will be included), and a 1-RTT packet acking the 0.5-RTT data sent by the server.

I agree that if you have both sets of keys, the transport should send an ACK and not wait for all async crypto processing to complete.  This is similar to receiving a GET request at a proxy.  The proxy acknowledges the GET immediately even if it has to go to a backend to respond.  But that doesn't prevent greatly inflated RTT samples when the keys aren't immediately available.

-- 
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/3821#issuecomment-668095002