Synthetic Packet Pairs (SPP) - Tool for passive round trip time measurement
Concise usage information can be found in the man page for SPP
Regular and frequent measurements of round trip time
(RTT) are important in test networks or overlay networks
(e.g. to evaluate network protocols), and they are also
becoming increasingly important in operational networks, such
as the Internet (e.g. to assess the quality of service for
highly interactive real-time applications).
Active probing techniques are possible but problematic. The
extra packet traffic imposed by active probes along a network
path can modify the behaviour of the network under test. In
addition, estimated RTT results may be misleading if the
network handles active probe packets differently to regular IP
In contrast, SPP provides frequently updated RTT
measurements using IP traffic already present in the network. SPP
measures the RTT between two measurement points without
requiring precise time synchronisation between each point. SPP
accurately measures the RTT experienced by any application's
traffic without needing modifications to the application itself or
the routers along the path. In addition, SPP works with
applications that do not exhibit symmetric client-server packet
exchanges (such as many online multiplayer games) and
applications generating IP multicast traffic.
This software is a flexible, standalone implementation of
the SPP algorithm and works on Linux or FreeBSD. RTT calculations
can be generated from saved PCAP format files (e.g. from tcpdump or Wireshark)
or local or remote network interfaces in real time.
- RTT is the round trip time that Target Traffic experiences between two
- A Measurement Point is an interface on which Target Traffic is captured.
- Target Traffic consists of a user nominated subset of traffic that flows
past both Measurement Points. (At present, tcpdump can be used to filter PCAP files
for offline analysis, but for rel-time measurements Target Traffic is limited
to any traffic between two specified IP addresses)
- Reference Point - Commonly refers to the Measurement Point that is
local to the user.
- Monitor Point - Commonly refers to the Measurement Point that is remote
from the user's perspective.
SPP estimates RTT between two measurement points along a network path.
Traffic is observed at both measurement points, and the RTT between the two measurement points is estimated from pairs of packets seen travelling in each direction.
Data can be collected from measurement points in two ways. The simplest
method is for the user to collect data at both monitor points manually
before running SPP. This can be achieved using tcpdump on the
measurement point interface. SPP can then read these PCAP files to
estimate RTT. Of course this method can only provide retrospective
Alternatively, when near real time RTT estimates are required, SPP can
passively monitor live network interfaces. Generally, the two
measurement points are geographically separate, requiring SPP to be run
on two separate hosts. The most common setup for near real time
measurements involves an 'SPP master' and 'SPP slave'. The SPP master actually
processes the data and outputs RTT estimates. The SPP slave
simply observes data and sends relevant
information to the SPP master. The relevant information in conveyed with
the SPP Sample Frames (SSF) protocol. These are UDP packets which contain enough
information to reconstruct IDs of observed packets and their
(NOTE: Live remote capture is currently experimental.)
In this implementation, target traffic is specified as packets flowing
between two hosts. IP addresses of these hosts must be entered on
the command line. The path between these two hosts must pass by the two
measurement points. It may be that the measurement points reside on the
hosts generating the target traffic, but this is not required.
Usage example 1
Target traffic is flowing between two endpoints (10.1.0.1 and 10.2.0.1). Two other machines are connected on the path via hubs. These machines use tcpdump to observe the target traffic travelling through the hub to which they are connected. RTT estimates can then be calculated for the path between the two hubs.
Usage example 2
Here, the measurement points reside on the machines generating the target traffic. With this configuration, RTT estimates can be calculated for the entire path of the target traffic.
A number of usage examples are described in more detail here.
For a detailed explanation of the SPP algorithm see the original paper.
- Process PCAP files captured at both measurement points
- Calculate round trip times from live interface capture
- Experimental remote capture slave support
- Packet identification hashes can be generated from a number of common IP/TCP/UDP fields
FreeBSD 6,7,8 or 9
- Run successfully under 6.2-RELEASE, 7.0-RELEASE, 8.1-RELEASE, and 9.0-RELEASE
- Expected to run on versions with the same major release number
- Tested on PC-BSD 8.1 (64-bit)
- Confirmed to compile and run successfully under
openSUSE 12.2 (x86_64)
Note: Linked to system threading library with -pthread
- PCAP library and header files are required
- Included in a 'Developer' FreeBSD installation
- Tested with base system libpcap 0.9.4, 0.9.8 and 1.0.0
SPP is released under version 2 of the General Public License
- Download tarball.
- Extract spp-x.x.x.tar.gz
- Enter spp-x.x.x directory
- Type 'make'
- Type 'make install' to install the binary to /usr/local/bin
- Optionally, type 'make man' to install the man page to /usr/local/man
Below is the output from spp that is processing PCAP files captured on two hosts on a LAN.
- spp -f ref.pcap -a 10.0.0.1 -F mon.pcap -A 10.0.0.2 -cp
The output of SPP follows the following format:
[pair count] timestamp rtt [spt]
Both 'pair count' and 'server processing time' are optional.
||Running total of packet pairs
||Time that a particular round trip time occurred (in seconds since January 1 1970)
|Round Trip Time
||Round trip time in seconds for a packet pair (sum of the time it took for the first packet to travel from the reference point to the monitor point and the time it took for the second packet to travel from the reference point to the monitor point).
|Server Processing Time
||Time difference in seconds between the first packet of a packet pair arriving at the monitor point and the second packet of a pair leaving the monitor point (both packets may belong to different flows).
Detailed information about all options can be found in the man page for SPP
SPP does not require any clock synchronisation, but for processing efficiency it
is beneficial if machines used for capturing have roughly synchronised clocks (within
a couple seconds). If you find SPP is not generating RTT estimates, it is
most likely due to system clocks being outside this range.
If you know the clock offset between the capture machines, SPP can take the
offset into account. The offset can be specified in seconds using the
-o option, where the value refers to the offset at the monitor point
with respect to the reference point.
In addition, the option '-d' can be used to specify the maximum tolerance in seconds
for clocks that are out of sync. See man page for SPP for details.
- Remote capturing has not been tested much