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

[Kazuho Oku <[e-mail]>]

Just FWIW, I might point out that we are actually making the design streamlined, by improving consistency in how we handle ack delay. The new rule is:
* The receiver reports the sum of the controlled delays by using the delay field of an ACK frame.
* When the sender knows what the maximum of that controlled delay is, the sender ...
    * uses that value (i.e. max_ack_delay) to arm the PTO timer, and
    * uses that value (i.e. max_ack_delay) to calculate the RTT, because if the value of the delay field is greater than the known maximum, the difference is considered as uncontrolled delay and therefore has to be accounted as part of the path delay.
* When the sender does *not* know what the maximum of that controlled delay is, the sender ...
    * does not arm the PTO timer, because it does not know when it can expect an ACK to arrive, and
    * calculates the RTT without the capability of detecting uncontrolled delay.

It's simply that up until now, we have misused max-ack-delay in the last bullet point case.

-- 
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-658728956