One-way Ping (OWAMP)
The OWAMP specification has now been released as a Standards Track RFC: http://www.rfc-editor.org/rfc/rfc4656.txt.

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.
• 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

FreeBSD

5.4

6.1

Linux

2.6.9

MacOS X

10.4.8

Solaris

5.10

---

Version Compatibility

---

Recommended Hardware

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

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

---

Configuring owampd

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

 % owampd -c /inst/root/etc

To see all the available options:

 % owampd -h

---

Running owping

% owping [options] targethost

To see a list of available options:

% owping -h

---

Mailing Lists

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.

---

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

Anatoly Karp

$Id: index.html,v 1.21 2007/02/24 11:50:05 boote Exp $