As part of a broader organisational restructure, data networking research at Swinburne University of Technology has moved from the Centre for Advanced Internet Architecture (CAIA) to the Internet For Things (I4T) Research Lab.

Although CAIA no longer exists, this website reflects CAIA's activities and outputs between March 2002 and February 2017, and is being maintained as a service to the broader data networking research community.

Synthetic Packet Pairs (SPP) - Tool for passive round trip time measurement

Documentation

Concise usage information can be found in the man page for SPP

Overview

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

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.

Definitions

• RTT is the round trip time that Target Traffic experiences between two Measurement Points.
• 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.

Operation

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 RTT estimates.

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 corresponding timestamps.

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

SPP Algorithm

For a detailed explanation of the SPP algorithm see the original paper.

Features

• 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

Requirements

License

Installation

1. Download tarball.
2. Extract spp-x.x.x.tar.gz
3. Enter spp-x.x.x directory
4. Type 'make'
5. Type 'make install' to install the binary to /usr/local/bin
6. Optionally, type 'make man' to install the man page to /usr/local/man

Example Output

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.

Options

Detailed information about all options can be found in the man page for SPP

Clock Synchronisation

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

Bugs

• Remote capturing has not been tested much