One-Way Ping (OWAMP)
About OWAMP      |     Downloads      |     Manual Pages     |     Cookbook

OWAMP

OWAMP Version 3.1

(An implementation of the One-Way Active Measurement Protocol)
http://www.internet2.edu/performance/owamp/
$Date: 2009-01-23 12:35:41 -0500 (Fri, 23 Jan 2009) $
OWAMP is a command line client application and a policy daemon used to determine one way latencies between hosts. It is an implementation of the OWAMP protocol as defined by http://www.rfc-editor.org/rfc/rfc4656.txt. (When referring to the protocol within this document, "OWAMP" will be in italicized. In all other instances, "OWAMP" will be referring to this implementation.)

With roundtrip-based measurements, it is hard to isolate the direction in which congestion is experienced. One-way measurements solve this problem and make the direction of congestion immediately apparent. Since traffic can be asymmetric at many sites that are primarily producers or consumers of data, this allows for more informative measurements. One-way measurements allow the user to better isolate the effects of specific parts of a network on the treatment of traffic.

With the One-Way Active Measurement Protocol (OWAMP) available, network providers will be able to better know the exact behavior of their networks and apply resources where improvement is most likely. (Note: Passive observation of average link use misses the transient queues - active measurement could see them.) Users would be more informed about network performance. This would prompt a better allocation of resources by network providers, decreasing areas of congestion where possible.

The increasing availability of precise time sources allows network hosts to timestamp packets with typical errors that are substantially smaller than the delays seen on real non-LAN networks. This makes it possible for one-way measurements to be collected across a broad mesh of network paths. In addition, the open source nature of OWAMP makes it possible for one-way metrics to become as common as are round-trip metrics (from tools like ping).

The OWAMP protocol also simplifies the analysis of measurement results - explicit send and receive timestamps for every measurement packet make analysis more straightforward because one does not need to assume return path reliability, preservation of inter-packet spacing by the round-trip measurement reflector, etc. For example, packet reordering, which can have implications for TCP performance, can be measured under a variety of input scenarios, with separation of reordering on the forward and return paths.

OWAMP session control uses traditional client-server communication between a control-client and a server, using the OWAMP-Control protocol. The owampd server is implemented using the conventional accept/fork model. The two sides negotiate one-way test parameters using the OWAMP-Control protocol. This OWAMP implementation then forks additional processes to actually send and receive the OWAMP-Test formatted packets that implement the session endpoints for the Sender and Receiver roles.

Using OWAMP, it is possible to collect active measurement data sufficient to determine a broad class of singleton characteristics (e.g., loss probability, median delay, jitter, 90th percentile of delay). Non-singleton characteristics, such as the expected inter-arrival gap of packets that were sent back-to-back, can be measured as well. Note: All measurements are done with synthetic traffic; application simulation is outside of the scope of OWAMP. The protocol is not designed to be able to send a packet as soon as a response to the previous packet arrives, but can send on any predetermined schedule (including immediately after the last packet was sent).

OWAMP has been designed to be deployable on as many systems as possible. Just as it is possible to ping most hosts on the network today, widespread deployment of OWAMP would make it possible to conduct more accurate measurement sessions.

The OWAMP development team recognizes that network measurement systems become more unwieldy as their size grows. When a full-mesh measurement architecture is used, the amount of disk space and network capacity used by the system will grow as the square of the number of measurement nodes. While nothing can be done to alleviate this problem, OWAMP was designed not to introduce any new scalability problems. It allows the user to conduct only those measurement sessions desired, and to retain as much (or as little) data as desired. OWAMP also does not dictate a choice of site(s) where measurement results are stored: it is possible to have all data stored at a central site or to store data at each receiver and fetch it as needed.

The owping client is used to request a measurement session. The owping parameters allow the user to select the send schedule, direction of the test (and peer), as well as the packet size. The owping application contacts an owampd process on the peer system to request the specific one-way measurement session. owampd is responsible for implementing the policy restrictions imposed by the system administrator on that system. A more detailed description of the OWAMP architecture is available on the details page.

owampd allows a system administrator to configure any given host as an OWAMP test endpoint. Specific policy limits can be applied to specific users, and individual tests are coordinated so they will not interfere with each other. OWAMP allows the administrator to classify incoming connections based upon a user name and AES key (generated by a pass phrase) combination or, alternatively, based upon an IP/netmask. Once the connection is classified, the owampd can determine the exact test parameters that will be allowed. (More details on the policy controls can be found in the owampd.limits(8) manual page.)

Features

  • Full IPv6 support. No options needed. If the target of a test is specified by a DNS hostname, and that name has both an IPv4 and an IPv6 address defined, the owping command line application prefers the IPv6 address.
  • Configurable send schedule and packet sizes as requested by the client.
  • Resource protection as defined by the policy controls implemented in owampd.
  • Port range specification for packet receivers for firewall friendliness.
  • Wide range of statistical output formats and information.

Requirements

  • OWAMP prefers a synchronized clock for measurements to be meaningful. But, more importantly, the clock needs to be stable. If the system clock is stepped during an OWAMP session, the results can be misleading.

    OWAMP prefers that NTP (ntpd) be running to synchronize the system clock. NTP must be setup correctly on the system for NTP to calculate a reasonable estimate of the time error and for it to stabilize the clock. NTP MUST be configured with no fewer than 4 clocks for this purpose. (See details.html for more specific information on configuring NTP.) Some measurements will still be meaningful if the clocks are not synchronized. For example, jitter measurements are still valid.

    It is worth noting that OWAMP should be run on real hardware. Virtualization packages such as vmware, xen, linux "kvm", parallels will exhibit clock instability that will make most OWAMP measurements chaotic.

    Additionally, it possible power-management features of most PC hardware should be disabled. (Speeding up and slowing down the processor makes for a very instable clock.)

  • OWAMP uses NTP-specific system calls to fetch time and time error estimates from the system kernel if they are available. It will report the time as unsynchronized if it is unable to access the NTP information this way. (It is still possible that the system clock is synchronized, OWAMP is just unable to verify that.
  • gnumake may be required for the build process (see Building the Application).

Supported Systems

OWAMP has been tested on the following:
FreeBSD
5.4
6.1
Linux
2.6.9
MacOS X
10.4.8
Solaris
5.10
OWAMP has a fairly resilient set of autoconf tests incorporated into the build process. Most recent versions of UNIX should work.

Version Compatibility

The OWAMP specification has gone through several revisions since its inception. Therefore, the OWAMP software has needed to track different versions of the protocol as it has evolved. To determine which versions are compatible, look at the major version number. Whenever the application has moved to a new incompatible version of the protocol the major version number has changed. For example, version 1.6f is NOT compatible with version 2.0c, and those two versions are also NOT compatible with any version 3 implementation. (Version 3 is the first version that is actually compatible with RFC 4656.)

Recommended Hardware

OWAMP does not have any strict hardware requirements. More tasking packet send schedules will of course require more capable hardware but low bandwidth schedules with small packets can be done on fairly modest hardware. In general, the more head room your system has, the more accurate your timestamps will be. Internet2 has had good luck using the following hardware to collect data on the Abilene network:
Intel SCB2 motherboard
Inter Ethernet Pro 10/100+ (i82555) (on-motherboard)
2 x 1.266 GHz PIII, 512 KB L2 cache, 133 MHz FSB
2 x 512 MB ECC registered RAM (one/slot to enable interleaving)
2 x Seagate 18 GB SCSI (ST318406LC)

Building the Application

The OWAMP software uses the gnu autoconf tools to configure the build process. OWAMP is distributed with a pre-built configure script so the actual autoconf tools should not be needed on the target system. (Although, gnumake may be required...) The configure script can be run with the --help option to determine the full set of configurable options.

A basic build procedure would be: 

% gzip -cd owamp-$VERS.tar.gz | tar xf -
% cd owamp-$VERS
  # --prefix is only needed if you don't like the default
  #   (/usr/local on most systems)
% ./configure --prefix=/inst/root
% make
% make install
Please report any build problems to owamp-users@internet2.edu.

Configuring owampd

The basic procedure to configure owampd is to create an owampd.conf and, optionally, an owampd.limits file and an owampd.pfs file. These files need to be installed in the same directory that is specified with the -c option to owampd. The recommended directory is /inst/root/etc. (The etc directory below your install root.) There are examples of these files in the owamp-$VERS/conf  subdirectory of the distribution.

owampd.conf:
Used to configure basic operation of the daemon, such as server listening port and error logging. For a detailed description of the options available, see the owampd.conf(8) manual page.

owampd.limits:
Used to configure the policy limits for the daemon. There are two parts to this policy: 1) authentication and 2) authorization. The authentication is done by assigning a class to each new connection. Each class has a set of limits associated with it. The classes are hierarchical, so a connection must pass the limit restrictions of the assigned class as well as all parent classes. For a detailed description of the options available, see the owampd.limits(5) manual page.

owampd.pfs:
Used to associate identities with pass-phrases (shared secrets). These identities are then mapped to a class by the owampd.limits file. For a more detailed description, see the owampd.pfs(5) manual page.

Running owampd

The normal command-line to start the daemon is: 
 % owampd -c /inst/root/etc
It is possible to run the daemon without a config file directory if enough command line options are specified, but it is easier to use a config file.

To see all the available options: 

 % owampd -h
More details on running the daemon, as well as a complete description of the command line options, are available from the owampd(8) manual page.

Running owping

The basic command line for the client is: 
% owping [options] targethost
This will run a 10-second session in each direction, concurrently at a rate of 10 packets per second.

To see a list of available options: 

% owping -h
More details on running the client application, with a complete description of all command-line options, are available from the owping(1) manual page.

Mailing Lists

There are two email lists to support this software:
owamp-users
A general discussion list for users to discuss problems. It is expected that bug reports will be sent here.
owamp-announce
This list will be used to announce new versions or significant developments with regard to the software.
Information about these lists, including links to subscribe, is at https://mail.internet2.edu/wws/lists/engineering.

Related Projects

J-OWAMP
J-OWAMP is a Java implementation of the One-Way Active Measurement Protocol (OWAMP).
http://www.av.it.pt/jowamp

Authors

Jeff Boote
boote@internet2.edu
Internet2

Anatoly Karp 

$Id: index.html 1052 2009-01-23 17:35:41Z aaron $
spectrum