|One-Way Ping (OWAMP)|
- LHC-Testing Challenges
- REDDnet's Distributed Storage Challenges
- BroadbandCensus Uses NDT
- eVLBI Over Advanced Networks
OWAMP Version 3.3
$Date: 2012-04-18 10:33:21 -0400 (Wed, 18 Apr 2012) $
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.)
- 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.
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).
OWAMP has been tested on the following:
OWAMP has a fairly resilient set of autoconf tests incorporated into the build process. Most recent versions of UNIX should work.
- MacOS X
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.)
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)
A basic build procedure would be:
Please report any build problems to email@example.com.% 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
The basic procedure to configure owampd is to create an
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
(The etc directory below your install root.) There are examples
of these files in the owamp-$VERS/conf subdirectory of the
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.
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.
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.
The normal command-line to start the daemon is:
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.% owampd -c /inst/root/etc
To see all the available options:
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.% owampd -h
The basic command line for the client is:
This will run a 10-second session in each direction, concurrently at a rate of 10 packets per second.% owping [options] targethost
To see a list of available options:
More details on running the client application, with a complete description of all command-line options, are available from the owping(1) manual page.% owping -h
There are two email lists to support this software:
- A general discussion list for users to discuss problems. It is expected that bug reports will be sent here.
- This list will be used to announce new versions or significant developments with regard to the software.
J-OWAMP is a Java implementation of the One-Way Active Measurement Protocol
$Id: index.html 1095 2012-04-18 14:33:21Z alake $