When a network feels slow, several different delays are often compressed into one description. Name resolution, connection establishment, path latency, packet loss, server processing, and available capacity can each produce a similar user report.
Start with a narrow question
“Is the network healthy?” is difficult to measure. “Did DNS latency increase for clients in this location?” or “Is loss concentrated after a particular hop?” leads to comparable observations.
Measure the layers separately
- Naming: resolver used, response time, returned addresses, and cache state.
- Connection: TCP or QUIC setup time and whether retries occurred.
- Path: round-trip distribution and loss over repeated samples.
- Application: time to first byte and total transfer time.
- Capacity: throughput over a long enough interval to leave slow start behind.
A clean result at one layer does not clear the others. A successful ping says little about DNS, and a fast bulk transfer can coexist with latency that makes interactive work unpleasant.
Keep time of day and percentiles
Networks are shared systems. Compare like with like: the same endpoint, access network, protocol, sample duration, and approximate time. Keep a distribution rather than only an average; the slow tail is often where intermittent problems live.
Collect a small healthy sample before an incident. Measurements without a normal reference are observations, not yet a baseline.
Record enough context to repeat it
Store the source location, destination name and address, protocol, tool version, resolver, interface, and timestamp. A result that cannot be reproduced is hard to compare and easy to overinterpret.
Small baseline checklist
- Resolve the destination and record every returned address.
- Measure connection time separately from application response.
- Collect repeated latency and loss samples.
- Test IPv4 and IPv6 independently when both are published.
- Repeat during a known busy interval.
- Keep raw output beside the summary.