Raise max TCP segment queue length #52
Merged
Conversation
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.
Out-of-order TCP segments are queued in the reassembly queue until the missing in-sequence segments arrive. As a DoS mitigation, the length of this queue is limited, with a default of 100. Since TCP allows a whole window to be in-flight at once, there can be up to 1448 to 11586 segments arriving before the sender expects an ACK, depending on the configured max receive buffer size and negotiated window size. The limit of 100 is not usually an issue in wired networks, because segments seldom arrive out of order. However, reordering and/or losses are more frequent with wireless networks and more complex networks, so the low default limit can cause a lot of segments to be discarded.
Raise the limit to 1448, which allows a full window to be queued in the default configuration.
See following ticket: https://redmine.ixsystems.com/issues/43558
The text was updated successfully, but these errors were encountered: