Network monitoring: distinguish packet loss, latency and application delay

A user reports that the order system is slow. The network dashboard shows a burst of packet loss, while the application team sees a database queue. Both observations may be correct. The useful question is which event explains the failed transaction and what evidence would distinguish the possible causes.

Network monitoring works best when measurements describe a specific path and are connected to an application journey. A site-wide average or an isolated ping result can tell you where to look. It rarely provides enough evidence to close the incident.

Use three terms precisely

Packet loss describes packets that do not arrive within the measurement’s defined conditions. Latency is delay, which may be measured in one direction or as a round trip. Delay variation, often called jitter, describes how delay changes between packets. These are different observations and should not be merged into one unexplained quality score.

RFC 2680 explains why a loss measurement needs context such as packet type, the threshold for treating a packet as lost and the measured path. A round-trip result also includes the return journey. It cannot by itself identify which direction caused the problem.

RFC 3393 defines an IP packet delay variation metric and notes that “jitter” is used in different ways. When comparing tools, ask for the calculation behind the label. Two dashboards can disagree because they summarise different measurements, not because one is broken.

Record the measurement before interpreting it

Keep these fields with the result rather than in an engineer’s memory. They make comparisons possible between a supplier’s evidence, a local probe and the user’s complaint.

Do not turn one acceptable average into a universal threshold. A background copy, a voice session and a multi-step transaction tolerate different patterns of delay. Agree useful limits with the service owner and validate them against observed behaviour.

Build a short investigation sequence

First, identify an affected transaction and its timestamp. Confirm the client, location, destination name and network path. Compare an affected user with an unaffected user performing the same work. Differences in access network, resolver, address family or application instance help narrow the investigation.

Second, separate the transaction into stages where the tooling permits it: name resolution, connection establishment, security negotiation and application response. A long wait before a connection starts points to a different investigation from a delay after the request reaches the service.

Third, align network and application evidence on a common timeline. Look at interface errors and discards, queue behaviour, flow changes, wireless conditions and service-side processing. Treat coincidence as a lead to test, not proof of causation.

For example, a hypothetical file transfer might saturate a branch uplink while a business application becomes slow. If pausing that transfer during an approved test restores the transaction and the queue evidence agrees, there is a stronger case for capacity or traffic-policy work. If response time remains poor on an unaffected path, the investigation should remain open.

Use synthetic and real traffic together

For wireless complaints, check client capabilities and the Wi-Fi pilot conditions before attributing the problem to the WAN or the application.

A lightweight probe can reveal a change before users report it. It should not be assumed to reproduce every application. Supplement reachability checks with a representative transaction that uses the production name, authentication route and service endpoint where appropriate.

Control the load and privileges of synthetic tests. A test account should perform only the work necessary to establish service availability, and it should not create uncontrolled business transactions. Record which parts of the journey the probe intentionally omits.

For dual-stack services, deliberately test both families. The IPv6 migration acceptance process should leave monitoring that can distinguish the two, rather than relying on whichever route a client selects.

Give the next team enough evidence to act

An escalation should contain the impact, time range, affected and unaffected examples, measurement settings, relevant changes and the evidence already collected. Include the actual question: for example, whether a carrier observed congestion on a named circuit during the same interval.

Retain raw observations long enough to investigate the incident, with access and retention appropriate to their contents. Aggregated charts are useful for trends, but they can remove the detail needed to explain a short failure.

When evaluating SD-WAN path selection, reuse this evidence format. The team should be able to explain why traffic moved and whether the application recovered. That is a more useful monitoring outcome than adding another dashboard whose red indicator nobody can interpret.