The TCP stack's measure of the frequency of packet reordering
experienced on the path to the client. Connections with a higher than
default value of
client.socket.tcpi_reordering are on paths that have
exhibited unusual levels of packet reordering in the past. The higher reordering
threshold will mitigate spurious TCP retransmissions at the cost of
slower recovery to real packet loss. The default value of this
variable is 3.
When the TCP stack receives new acknowledgment packets that continue
to acknowledge the same sequence number, these are considered duplicate
acknowledgments. Duplicate acknowledgments tell the TCP stack that some
data continues to arrive at the peer, but the next expected packet in the
flow has not yet arrived (e.g., there is a hole) when the
acknowledgment was generated. The sender needs to decide whether a
packet loss created the hole, signaling the need for data
retransmission, or the outstanding packets were just reordered on the
way to the peer. The value of
client.socket.tcpi_reordering is the number of
consecutive duplicate acknowledgments that trigger the
loss logic and initiate the retransmission without waiting
for a timer (a.k.a., fast retransmit).
The value of the reordering variable may be altered on a per-path basis via the kernel based on runtime feedback after retransmission when those retransmissions are later determined to have been superfluous. When this happens, the kernel can dynamically raise the reordering threshold which makes it more conservative in determining when to send retransmissions in the future. The new threshold applies to the path and is cached so that it also applies to new connections.
User contributed notes
We welcome comments that add use cases, ideas, tips, and caveats. All comments will be moderated before publication. To post support questions, visit our support center and we'll find you the help you need.