On the sender side, we don't use the max_ack_delay before the handshake is confirmed. This means that we arm the PTO timer based on RTT (and RTT variance) alone. On connections with short RTTs, this means that we don't wait very long until we retransmit (Initial and Handshake) packets.
However, on the receiver side, the max_ack_delay is used during the handshake, for all packets after the first packet in a packet number space. This means that the acknowledgement for all but the first packet are delayed, and if the RTT is short enough, this will trigger the peer's PTO timer.
According to RFC 9002, we should send out an acknowledgement immediately. I'm a bit concerned that this will make us send out too many ACKs if packets are received in short succession. A middle ground might be to delay acknowledgements by the timer granularity (1ms).
On the sender side, we don't use the max_ack_delay before the handshake is confirmed. This means that we arm the PTO timer based on RTT (and RTT variance) alone. On connections with short RTTs, this means that we don't wait very long until we retransmit (Initial and Handshake) packets.
However, on the receiver side, the max_ack_delay is used during the handshake, for all packets after the first packet in a packet number space. This means that the acknowledgement for all but the first packet are delayed, and if the RTT is short enough, this will trigger the peer's PTO timer.
According to RFC 9002, we should send out an acknowledgement immediately. I'm a bit concerned that this will make us send out too many ACKs if packets are received in short succession. A middle ground might be to delay acknowledgements by the timer granularity (1ms).