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 recommend sending one IMMEDIATE_ACK per RTT #227

Closed
martinthomson opened this issue Oct 30, 2023 · 4 comments · Fixed by #278
Closed

Don't recommend sending one IMMEDIATE_ACK per RTT #227

martinthomson opened this issue Oct 30, 2023 · 4 comments · Fixed by #278
Labels

Comments

@martinthomson
Copy link
Member

Alternatively, a sender can accomplish this by sending an IMMEDIATE_ACK frame once each round trip time, although if the packet containing an IMMEDIATE_ACK is lost, detection of that loss will be delayed by the reordering threshold or requested max ack delay.

Please don't suggest this. Acknowledging once per RTT is something that a receiver should be expected to manage on their own.

@mirjak
Copy link
Contributor

mirjak commented Jan 12, 2024

This is not a recommendation but explaining the possibilities in case the receiver does not manage accordingly. This was discussed quite a lot and we ended up removing normative language (see #211) in order to not have it recommended. I don't think we should open this issue again.

@mirjak
Copy link
Contributor

mirjak commented Feb 5, 2024

@martinthomson is there anything we need to do here or can we close this issue?

@martinthomson
Copy link
Member Author

It reads as a suggestion to me. Consider rewording.

mirjak added a commit that referenced this issue Mar 1, 2024
@mirjak
Copy link
Contributor

mirjak commented Mar 1, 2024

@martinthomson I created PR #278. Is that any better?

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

Successfully merging a pull request may close this issue.

2 participants