Packets within a burst have arrived out of their original sequence.
- Review your applications to consider whether or not they are susceptible to reordering. Most applications are not susceptible to reordering.
- If reordering is excessive or applications are overly sensitive to reordering, consider reconfiguring multi-link load-balanced networks. Note that most load balancers reorder more frequently as traffic loads increase. Also, the amount of reordering can fluctuate depending on which queuing algorithms are being used by the network equipment manufacturer.
Because packets travel through a network path independently, they may not arrive in the order in which they were sent. In multi-link load-balanced networks, data can become reordered, especially during high-traffic periods. Some applications are more susceptible to reordering than others. For example, the quality of VoIP calls can be affected by reordering. Other legacy protocols cannot handle reordering whatsoever.
TCP is responsible for verifying the correct delivery of data, and will present the data to the application in the order it was sent. Even though TCP corrects reordered packets, there is an overhead that is induced. For example, a block of data delivered in 4 packets can be presented to the application with only one call from TCP. However, if two of these packets were out of order, e.g. if the second and third packets are reversed in transit, TCP must issue four calls to the application to deliver the same block of data.
Possible secondary messages
- "Relatively low levels should not affect network performance"
- "Excessive levels may cause performance degradation in some applications"
- "Intermediate device CPU effect only - not present on end-to-end path"