Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

don't delay acknowledgement by max_ack_delay during the handshake #4279

Closed
marten-seemann opened this issue Jan 29, 2024 · 0 comments · Fixed by #4288
Closed

don't delay acknowledgement by max_ack_delay during the handshake #4279

marten-seemann opened this issue Jan 29, 2024 · 0 comments · Fixed by #4288

Comments

@marten-seemann
Copy link
Member

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant