Send ACK_FREQUENCY frames intelligently rather than spamming IMMEDIATE_ACK #1656
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Ralith
force-pushed
the
intelligent-ack-frequency
branch
3 times, most recently
from
bd03260 to
65a5aee
Compare
djc
approved these changes
Sep 8, 2023
|
I'm honestly not completely confident I understand all the nuance here, but it seems like a nice simplification and looks like we got decent test coverage of what's going on. |
Replaces "advancing to Instant { ... }" with e.g. "advancing to 10ms"
This behavior was redundant to intelligent transmission of ACK_FREQUENCY frames when RTT change is observed.
Ralith
force-pushed
the
intelligent-ack-frequency
branch
from
65a5aee to
be696c0
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Alternative to #1654. Reduces the amount of communication required compared to the status quo when the RTT is not varying wildly.
This preserves the pre-existing behavior where
max_ack_delayis effectively clamped below the current RTT. It might be useful to also offer an escape hatch to force it higher, although such a configuration is contrary to the "SHOULD" recommendation of the ack frequency draft.