Measuring one-way latency with OWAMP

Introduction to OWAMP

Collecting one-way active measurements, such as latency, packet loss, and jitter, is the optimal way to monitor the performance of a network infrastructure. Tools like ping and TWAMP (two-way active measurement protocol) measure the time that it takes for a packet to reach and come back from a destination host. The problem is that, when troubleshooting latency increases, we don’t know in what direction is happening. Having both way’s individual measurements overcomes this limit. 

The challenge with running one-way measurements is there’s not a common protocol as ICMP to do that. The One-Way Active Measurement Protocol (OWAMP) aims at bridging that gap, hoping that one-way measurements will be collected across a far broader mesh of Internet paths than is currently possible. 

What is OWAMP?

OWAMP is an advanced network utility that tests and measures latency, packet loss, and jitter between two hosts. OWAMP was defined by IETF in RFC 4656 in an effort to promote an open standard for interoperability in one-way latency measurements. 

The protocol defines several functions, such as support for authentication and authorization, ability to configure tests, configurable packet sizes, ability to start/stop tests, and retrieve their results. It can also retrieve results of partial tests.

OWAMP Architecture

The OWAMP architecture is client-server. The server has a broker process that handles incoming requests and spawns child processes as needed. The architecture is scalable, has security built in features, a scheduler, and resource control. 

How OWAMP Works

The client (owping) contacts the server using an open, authenticated, or encrypted communication and requests resources to run a test as a sender or receiver. The OWAMP server (resource broker) spins a child process that exchanges control messages with the client before then spawning a child process that will run the actual test. The process running the test is called, on both OWAMP server and client side, OWD Test Endpoint.

Source: https://software.internet2.edu/owamp/owamp-cookbook.pdf

Use Cases for OWAMP

Network Troubleshooting

When troubleshooting network issues, OWAMP provides insights that traditional round-trip tools like ping cannot. Many connectivity problems, such as one-way latency, asymmetric routing, or intermittent packet loss, remain hidden when only round-trip metrics are considered. OWAMP isolates traffic in each direction, allowing network engineers to detect delays or losses specific to a single path. 

For instance, a VoIP call might sound distorted only for users in one office because the return path experiences congestion or jitter. By using OWAMP, administrators can measure one-way latency and packet loss with millisecond accuracy, identify which side of the connection is degraded, and take corrective action quickly. This precision makes OWAMP an indispensable tool for diagnosing complex network performance problems in large distributed environments.

Performance Monitoring in Real-Time Applications

Real-time applications like VoIP, video conferencing, and online collaboration tools are extremely sensitive to latency, jitter, and packet loss. Even minor fluctuations can cause audio dropouts, frozen video, or degraded call quality. OWAMP enables continuous, one-way performance monitoring that captures these subtle impairments as they occur. 

Unlike passive monitoring, which only observes existing traffic, OWAMP actively measures end-to-end performance, providing quantifiable metrics that reflect real user experience. Network operations teams can use these measurements to establish performance baselines, detect emerging problems before users notice them, and monitor service-level agreements (SLAs) with ISPs or cloud providers. 

In short, OWAMP empowers organizations to maintain high-quality real-time communications by turning invisible one-way network issues into actionable data.

Running OWAMP on NetBeez

NetBeez supports running owping tests as part of a custom command. The team at perfsonar released a version of owamp that includes both the server owampd and the client owping. The source code is available, under the Apache License, at https://github.com/perfsonar/owamp. 

Requirements for OWAMP Setup

I tested owamp on a NetBeez Gigabit Ethernet agent running the NetBeez agent version 15.1.2 and Raspbian GNU/Linux 11 (bullseye). The installation was done via the console interface from the NetBeez dashboard.

Before proceeding with owamp, I had to install the following dependencies so I could build and install the package:

sudo apt install -y build-essential automake autoconf libtool pkg-config libssl-dev libpcap-dev git

I also had to install the i2util as a dependency:

cd /tmp
git clone https://github.com/perfsonar/i2util.git
cd i2util/I2util/I2util/
./bootstrap
./configure
make
sudo make install
ldconfig

I then installed the owping package from github. On a host you can install the client and server the following way (omit  –enable-owampd in the configure step to only install the client owping):

cd /tmp
git clone https://github.com/perfsonar/owamp.git
cd owamp/owamp/owamp/
./bootstrap

./configure --enable-owampd
make
make install

In general, I would recommend not to run the server on a NetBeez agent, unless proper hardening and security measures are implemented.

Running the server (owampd)

In my test, I ran the server on another NetBeez agent. Since I was in a lab environment, I used the open connection method. If I were running the owamp server in a public or open network, I would have definitely used authentication at minimum, and probably even encryption. This would limit the risk of agents being used as DDoS sources.

First of all, using sudo, I created the owamp server configuration file at /etc/owamp/owamp-server.conf with the following content:

# Minimal OWAMP server configuration
# Directory where owamp stores session data
vardir     /var/lib/owamp
# Directory containing the owampd.pfs keys (auto-generated if missing)
datadir    /var/lib/owamp
# The user owampd should drop privileges to after starting as root
user       nobody
# Network interface / IP address to listen on
srcnode    0.0.0.0

Then I ran the server:

sudo owampd -c /etc/owamp/owamp-server.conf -Z

To conclude, if you are planning to host an OWAMP server, ensure to review the recommendations from the owamp cookbook. It’s a great resource for those interested in deepening their knowledge of the protocol and service in general.

Running the client (owping)

To run the client you can simply type owping followed by the IP address of the owamp server:

$ owping 192.168.1.45
Approximately 12.9 seconds until results available

--- owping statistics from [192.168.1.48]:8923 to [192.168.1.45]:50084 ---
SID:    c0a8012decbb9c3a5c32bb20f6df0f8a
first:  2025-11-09T18:03:24.923
last:   2025-11-09T18:03:34.751
97 sent, 0 lost (0.000%), 0 duplicates
one-way delay min/median/max = -1.26e+03/-1.25e+03/-1.24e+03 ms, (err=0.423 ms)
one-way jitter = 6.7 ms (P95-P50)
hops = 0 (consistently)
no reordering


--- owping statistics from [192.168.1.45]:40774 to [192.168.1.48]:9276 ---
SID:    c0a80130ecbb9c3b9bdb171210eda2fb
first:  2025-11-09T18:03:24.612
last:   2025-11-09T18:03:34.777
100 sent, 0 lost (0.000%), 0 duplicates
one-way delay min/median/max = 1.25e+03/1.26e+03/1.26e+03 ms, (err=0.423 ms)
one-way jitter = 5.7 ms (P95-P50)
hops = 0 (consistently)
no reordering

The client has a vast range of options. Here is an example of owping arguments for the test section:

owping:
usage: owping [arguments] testaddr [servaddr]
[arguments] are as follows:

             [Test Args]

   -h             print this message and exit
   -c count       number of test packets
   -D DSCP        RFC 2474 style DSCP value for TOS byte
   -f | -F file   perform one-way test from testhost [and save results to file]
   -i wait        mean average time between packets (seconds)
   -L timeout     maximum time to wait for a packet before declaring it lost (seconds)
   -P portrange   port range to use during the test
   -s padding     size of the padding added to each packet (bytes)
   -t | -T file   perform one-way test to testhost [and save results to file]
   -z delayStart  time to wait before executing test (seconds)

...

Best Practices for OWAMP Implementation

Time accuracy

OWAMP is as accurate as the level of synchronization between the client and the server. Ideally, both ends have access to a GPS source that provides accurate timing. In alternative, it’s necessary to get a good stable NTP configuration.

In my testing, I ensured that my agents had NTP configured. I used chrony, which is a versatile Linux time synchronization based on NTP.

Security

Security is a major concern for those hosting an OWAMP server. Like for any service being offered to the public, or a semi public network, it’s important to implement the usual best practices:

• Keep the server patched and up-to-date from a security perspective
• Limit the running services to those strictly necessary to perform its function
• Implement a host firewall (e.g. iptables or ufw) to restrict access
• Change default passwords where applicable

OWAMP offers a way to limit resources utilized by the service. This is also important to avoid the service being used for a DDoS attack. It’s also possible to authenticate owping clients with AES key pairs.

NetBeez Custom Command Script

The custom command enables the execution of bash and python scripts on NetBeez network monitoring agents. The results are then passed to the dashboard for display, analysis, and alerting.

The owamp custom command script

I (vibe) coded the following script which executes owping tests against the owamp server, collecting and reporting the results to the NetBeez dashboard. The metrics collected are latency, packet loss, and jitter for both the client-to-server and server-to-client directions.

#!/usr/bin/env bash

# Run owping command
output=$(owping 192.168.1.45 2>/dev/null)

# Split client and server sections using awk
client_section=$(awk '/^--- owping statistics/{i++} i==1{print}' <<< "$output")
server_section=$(awk '/^--- owping statistics/{i++} i==2{print}' <<< "$output")

# Extract metrics from client section
client_packet_loss=$(grep -Eo '[0-9]+\.[0-9]+%|\([0-9]+\.[0-9]+%\)' <<< "$client_section" | head -n1 | tr -d '()%')
client_median_latency=$(grep -Eo 'one-way delay.*' <<< "$client_section" | awk -F'=' '{print $3}' | awk '{print $1}' | sed 's/nan//')
client_jitter=$(grep -Eo 'one-way jitter = [^ ]+' <<< "$client_section" | awk '{print $4}' | sed 's/nan//')

# Extract metrics from server section
server_packet_loss=$(grep -Eo '[0-9]+\.[0-9]+%|\([0-9]+\.[0-9]+%\)' <<< "$server_section" | head -n1 | tr -d '()%')
server_median_latency=$(grep -Eo 'one-way delay.*' <<< "$server_section" | awk -F'=' '{print $3}' | awk '{print $1}' | sed 's/nan//')
server_jitter=$(grep -Eo 'one-way jitter = [^ ]+' <<< "$server_section" | awk '{print $4}' | sed 's/nan//')

# Output results
echo "client_ploss=${client_packet_loss:-N/A}"
echo "client_latency=${client_median_latency:-N/A}"
echo "client_jitter=${client_jitter:-N/A}"
echo
echo "server_ploss=${server_packet_loss:-N/A}"
echo "server_latency=${server_median_latency:-N/A}"
echo "server_jitter=${server_jitter:-N/A}"

Once pasted, it’s important to map the output schema to the script output results so the dashboard can process and display them.

Displaying OWAMP Results on the NetBeez Dashboard

Once the owamp package is installed and the script is loaded via a custom command, we finally start getting results into the server dashboard. The following screenshot shows the results from one NetBeez agent, displaying results for both agent-to-server and server-to-agent.

Comparing OWAMP with Other Active Measurement Tools

The following table briefly compares the pros and cons of three active measurement tools that have similar characteristics: owamp, ping, and twamp.

Conclusion on OWAMP

OWAMP (One-Way Active Measurement Protocol) bridges a critical gap in network monitoring by measuring latency, jitter, and packet loss independently in each direction. Unlike ping or TWAMP, it reveals one-way performance issues and asymmetric paths that affect real-time traffic such as VoIP and video conferencing.

When combined with NetBeez, OWAMP enables automated one-way active measurements across distributed locations, helping teams quickly pinpoint where latency or packet loss occurs. In today’s cloud and hybrid networks, OWAMP delivers the accuracy and visibility needed to ensure consistent performance and meet user expectations.