Set a Delay Budget for Real-Time Traffic over a VPN
Start from the deadline the app must meet, then measure one-way delay and jitter with stated conditions. An average with no late threshold proves nothing.
Real-time VPN complaints need a deadline to fail against, and "low latency" is not one. Decide what the conversation or remote session must deliver, then measure the path against that requirement under stated conditions. Without a late-packet threshold, every result is arguable. The allocation below is a design decision, and it exists so the measurement has something to answer.
Write the deadline before you touch a probe
The deadline comes from the application and its users, not from a vendor's marketing page. A live voice call, a remote desktop session and a nightly backup tolerate completely different waiting times, and the failure that matters is usually the tail rather than the median. Write the number down with the workload it belongs to.
Then allocate it. Capture and packetization consume part of the budget, the access link and tunnel consume another part, the receiver's de-jitter buffer holds packets on purpose, and application processing takes the rest. Naming those stages keeps tunnel encryption in proportion instead of making it the default suspect for every slow packet.
Finally define the measurement contract in four lines: endpoints and direction, traffic shape, conditions during the run, and the outcome you will report. A quiet Sunday sample and a loaded Tuesday sample answer different questions, so state which one you collected. If you cannot fill in all four lines, the run is not ready to start. That checklist is also what makes two reports comparable months later, when nobody remembers what else the link was carrying.
Split the budget across every stage
The table is a planning aid, not captured data. Fill in the owner for each row before the first probe, because the owner is who you call when that stage exceeds its share.
| Stage | What it contributes | Who owns it |
|---|---|---|
| Capture and packetization | Encoder frame size, aggregation | Application owner |
| Tunnel and transit | Encryption, queueing, path length | Network owner |
| Receiver buffer | Deliberate waiting to absorb variation | Application owner |
| Application processing | Decode and render time | Application owner |
Two rows usually surprise people. The receiver buffer is not a fault when it adds delay, because it is doing the job it was configured to do. And the tunnel's share is often smaller than the queue in front of it, especially on an uplink that saturates during uploads.
When a stage has no owner, the budget is fiction. Assign one before you measure, or you will spend the next meeting arguing about whose number is wrong.
Measure one-way delay with an honest clock
One-way delay is the number the deadline cares about, and it needs synchronized clocks at both ends. The one-way delay metric requires you to report synchronization method, resolution and estimated skew alongside the result. Two unsynchronized hosts can produce a very precise number for the wrong quantity.
Capture a few hundred packets rather than a handful, and record the clock state at the same time:
$ ntpq -p
$ owping -c 300 -i 0.2 10.90.0.1
$ ping -c 200 -i 0.2 10.90.0.1 | tail -n 3Round-trip time is a separate measurement, not two one-way values added together. Halving an RTT assumes symmetric paths and symmetric queues, and a tunnel over a mobile uplink breaks both assumptions routinely. Report RTT as RTT and keep it out of the one-way budget.
Report the tail and the late packets
Summarize the distribution: median, 95th and 99th percentile, worst case, loss, and the count of packets that arrived later than the deadline allows. The average is the least useful of those numbers for a real-time workload, because a smooth average can hide a tail that ruins every third call.
Delay variation feeds directly into receiver buffering. More buffering hides variation and adds waiting, so a stream can look stable while exceeding its deadline. Choose a variation formulation, state the interval you measured over, and keep it consistent between runs.
Repeat the run with representative cross-traffic. A path that meets the budget when idle and misses it during a backup window has told you something useful about scheduling, which no single quiet measurement would reveal. Record the conditions next to the result, because the next engineer will otherwise compare two samples that were never comparable.
Accept the design when the measured tail fits the budget under the workload you actually run, and reject it with the stage that overran named in the report.