# Baseline delay, loss, and delay variation before a network complaint becomes guesswork > Network quality needs defined paths, packet types, intervals, clocks, and statistics. Build directional baselines for delay, loss, and delay variation before users report a vague slowdown. - Canonical URL: https://update.dsesecurity.com/updates/baseline-network-delay-loss-delay-variation/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-17T13:18:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 4 minutes ## What you need to know Network quality needs defined paths, packet types, intervals, clocks, and statistics. Build directional baselines for delay, loss, and delay variation before users report a vague slowdown. ## Potentially affected WAN and internet circuits; LAN paths; VPNs; voice and video; cloud applications; network monitoring; synthetic probes; timestamps; service-level reporting; and escalation workflows. ## DSE recommendation Define representative measurement paths and methods, synchronize clocks, collect directional delay, loss, and variation over business cycles, use distributions rather than one average, annotate change, and retain raw evidence. ## Article ## Source facts: performance metrics require defined measurement conditions [RFC 2330](https://www.rfc-editor.org/info/rfc2330) establishes a framework for IP performance metrics. It emphasizes clearly defined metrics, measurement methods, repeatability, statistical treatment, and the conditions under which observations are made. The framework warns against presenting a measurement without enough context to understand what was actually tested. RFC 3393 defines IP packet delay variation metrics, including concepts used to describe differences in one-way delay between selected packets. RFC 7680 defines one-way packet loss metrics. These documents use precise packet streams, source and destination points, timing, and statistical samples. They do not reduce network quality to one universal “jitter” or “packet loss” value. Round-trip ping can be a useful operational test, but it combines two directions, can receive different treatment than application traffic, and may be rate limited or deprioritized. One-way measurements need synchronized clocks. Synthetic probes do not necessarily follow the same path or policy as user traffic. An average can hide bursts, tails, directionality, and time-of-day behavior that make a service unusable. ## DSE recommendation: build a baseline that can survive an escalation Begin with the business service and its path. The objective is evidence that can show when and where experience changed, not the largest possible collection of unrelated telemetry. - Define the service question. Identify the application, sites, user populations, traffic direction, service hours, critical transactions, expected dependencies, and the decision the measurement should support. Separate availability, response time, throughput, loss, delay, and delay variation. - Choose representative endpoints. Place probes on the actual sides of meaningful boundaries: user LAN, WAN edge, data center, cloud region, VPN termination, voice gateway, or provider handoff. Record routing, tunnels, quality-of-service policy, and address translation that may affect the path. - Document the method. Record protocol, packet size, marking, interval, timeout, sample selection, one-way or round-trip interpretation, clock source, tool version, and retention. Test whether network policy treats the probe differently from the application before claiming equivalence. - Collect a business-cycle baseline. Measure weekdays, weekends, maintenance periods, backups, shift changes, busy hours, and known low-use windows. Preserve distributions and percentiles, not only averages. Keep direction-specific delay and loss where the method supports them. - Correlate context. Annotate carrier incidents, routing changes, interface errors and discards, utilization, queue drops, wireless health, VPN changes, security inspection, cloud status, and application events. A coincident metric is a lead to investigate, not proof of causation. - Set evidence-based thresholds. Use observed normal ranges, application tolerance, and contractual targets. Define duration and sample requirements so a single unusual packet does not create noise, while sustained degradation and short severe bursts remain visible. - Preserve escalation evidence. Retain raw samples or sufficient aggregates, timestamps, endpoint health, path information, configuration versions, and event annotations. Give providers the exact affected direction, interval, method, baseline comparison, and supporting interface or path data. Validate the monitor itself. During a controlled window, create a known amount of representative traffic, introduce a safe rate limit or path change where authorized, and compare the expected effect with the recorded samples. Confirm that the probe reports its own health, a missing sample is not converted to zero loss or zero delay, clock problems are visible, and maintenance suppression does not erase the underlying evidence. Revalidate after probe, routing, tunnel, quality-of-service, or collector changes. Factual boundary: Delay, loss, and delay variation measurements describe the selected packets between selected points under selected conditions. They do not by themselves locate the fault or prove that a carrier, firewall, application, or endpoint caused it. Route asymmetry and traffic treatment can limit inference. Track baseline coverage for critical services, probe availability, clock quality, directional loss, tail latency, delay variation, threshold events, unresolved path changes, and time to isolate a fault domain. When a user says “the network is slow,” the team should be able to compare the complaint with a defined, recent normal state and decide the next diagnostic step. ## Official references - IETF, [Framework for IP Performance Metrics](https://www.rfc-editor.org/info/rfc2330), RFC 2330. - IETF, [IP Packet Delay Variation Metric for IP Performance Metrics](https://www.rfc-editor.org/info/rfc3393/), RFC 3393. - IETF, [A One-Way Loss Metric for IP Performance Metrics](https://www.rfc-editor.org/info/rfc7680/), RFC 7680. ## Primary reference - Name: IETF RFC 2330: Framework for IP Performance Metrics - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/info/rfc2330 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Baseline delay, loss, and delay variation before a network complaint becomes guesswork,” DSE Security, https://update.dsesecurity.com/updates/baseline-network-delay-loss-delay-variation/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.