Make a difference. Get involved in one of the many Internet2 community working or special interest groups.
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.
OWAMP has been tested most extensively on Red Hat Linux 5 and 6 systems, but most recent versions of UNIX or OS X should work.
The basic command line for the client is:
Running The OWAMP Client
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
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
Configuring The OWAMP server
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:
Running The OWAMP Server
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
A basic build procedure would be:
Please report any build problems to firstname.lastname@example.org.% tar xzf owamp-$VERS.tar.gz % 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
There are two email lists to support this software:
- perfsonar-users: This is a general discussion list for users to discuss problems. This list is monitored as bug reports should be sent here.
- perfsonar-announce: This list is 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
Aaron Brown (email@example.com)
The following individuals have greatly aided in the development, testing, or
debugging of OWAMP:
- Jeff Boote (Sandia) - Initial Developer
- Anatoly Karp