client.socket.tcpi_reordering

INTEGER, read-only.

Available inrecvdeliverlogerror

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.