Packet loss is detected above a certain threshold. The threshold varies based on measured characteristics of the network path.
- If one or more diagnostic messages has been generated, take the recommended course of action for each message. Start with the diagnostic message with the highest certainty value.
- If no diagnostic messages were generated, or if certainty values are low (e.g. < 50%), attempt to re-run the test with a higher number of Iterations.
- If you receive multiple diagnostic messages with similar certainty values, you may want to adjust Packets per Burst to get higher certainty values. Higher Packets per Burst drive the device under test harder, and may shake out configuration errors. Lower Packets per Burst (e.g. 5) should be attempted if a rate limiting queue technique is suspected. If this action makes packet loss disappear, you can be certain that a rate limiting queue has been implemented.
- If you still do not have a satisfactory diagnostic message, try testing the problem link using a faster path. Usually this involves moving a monitoring point, or using a different monitoring point that is located closer to the problem link. For example, a duplex conflict tested through a T1 link usually results in approximately 3% packet loss, and no diagnostic messages. When testing across a T3 link, diagnostic messages usually appear with low certainty values. When testing across a 100Mbps network, diagnostic messages are precise, and higher certainty values are obtained.
- If still unable to generate diagnostic messages with significant certainty values, see below for action required for specific secondary messages.
Packet loss will adversely affect application performance.
In Delivery monitoring, packets are considered to be lost if they are not acknowledged (reply packets are not received back) within an internal timeout period. Delivery monitoring will only report a packet lost after an extended wait, to ensure that reported packet loss is as accurate as possible.
A router generally drops packets due to congestion, either because its buffer space for queuing packets has filled up, or because it has been set up with rate limiting queue. Packets can also be lost in transit due to media errors, duplex mismatches, MTU conflicts and device failures.
By design, normal TCP traffic will result in low levels of random packet loss. This message identifies that packet loss along the test path exceeds normal patterns, and requires further investigation.
Possible secondary messages
- "Exceeds reasonable tolerances for this network path"
- "Weak loss may contain regular pattern - consider re-running test with more packets per burst to resolve diagnosis" Overall packet loss is low but a pattern of loss affecting certain packets has been detected, i.e. the packet loss is not random but highly selective in that it appears to be selectively affecting certain types of packets. Delivery monitoring is unable to determine what the pattern is due to the low levels. Recommended action: Changing the test configuration may help resolve the pattern so that Delivery monitoring can identify it and make a diagnosis. For example, increasing the number of packets per burst can often trigger a dysfunction to reveal itself more clearly. Using a monitoring point with higher Total Capacity access to the root cause of loss may also trigger the behavior more clearly.
- "Intermediate device CPU effect only - not present on end-to-end path"
- "Limited impact on data throughput at small latencies"
- "Primarily small packets with limited impact on data throughput"