SPP - Synthetic Packet Pairs

Documentation

Concise usage information can be found in the Man page for SPP 0.3.2

Overview

Regular and frequent measurement of round trip time (RTT) between points on the Internet is becoming increasingly important for a range of 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 estimates using IP traffic already present in the network. SPP estimates the RTT between two measurement points without requiring precise time synchronisation between each point. SPP accurately estimates 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 packet processor that implements the SPP algorithm. RTT calculations can be generated from saved PCAP format files or local or remote 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, 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 Measuremet 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 involes an 'SPP master' and 'SPP slave'. At one measurement point, SPP is run as the master. At this point, SPP actually processes the data and outputs RTT estimates. At the other measurement point, SPP is run as a slave. It simply observes data and sends relevant information to the SPP master. The relevant information in conveyed with SPP Sample Frames (SSF). 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.

SPP Conceptual Diagram

A diagram of a network suitable for use with SPP is shown below. Target traffic is flowing between two endpoints (10.1.0.1 and 10.2.01). 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.


Simplified Diagram

Here, a simpler scenario is shown, with the measurement points residing on the machines generating the target traffic. With this configuration, RTT estimates can be calculated for the entire path of the target traffic.


SPP Algorithm

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

Features

  • Process PCAP files captured at both measurement points
  • Calculate round trip times from live interface capture
  • Experimental remote capture slave support
  • Idenfication hashes can be generated from a number of common IP/TCP/UDP fields

Requirements

  • FreeBSD 6,7 or 8
    • Run successfully under 6.2-RELEASE, 7.0-RELEASE, and 8.1-RELEASE
    • Expected to run on versions with the same major release number
    • Tested on PC-BSD 8.1 (64-bit)
  • Linux Support
    • Linux not yet supported
  • PCAP
    • 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
    • Note: Linked to system threading library with -pthread

    Licence

    SPP is released under version 2 of the General Public 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.

    Pair Count Running total of pairs the program has created
    Timestamp The time that a particular round trip time is said to have been experienced (in seconds since January 1 1970)
    Round Trip Time The time in seconds that it would have taken for a packet to travel from the reference point to the monitor point and back.
    Server Processing Time A synthetic measurement of the time it takes for server processing. It is actually the time difference between an incoming packet arriving at the monitor point and an outgoing packet leaving the point (regardless of what flow each packet belongs). The smaller this value, the more accurate the RTT estimates.

    Options

    General Options

    -a IP address of target host near the reference point
    -A IP address or target host the monitor point
    -s Put into slave mode and send to the specified address
    -o Offset in seconds of clocks at the monitor point with respect to the reference point.
    -d Max difference of timestamps in seconds allowed between matching packets. This value should be greater than expected RTT (plus any clock offset when not specifying a fixed offset with the -o option). (Default: 5)
    -v Verbosity Level (Default: 0) Determines information that is displayed on the console. The verbosity level is the total of the IDs of each required detail as listed below:
    • 1 Queue Size
    • 2 Thread Details
    • 4 Pair Info
    • 8 Record Info
    • 16 Instance Info
    • 32 Packet Info
    • 64 RTT COUNT - "checksum"
    • 128 Network Details
    • 1024 Verbose Network Details

    Source Options

    -f File to be read for the reference point (PCAP format)
    -F File to be read for the monitor point (PCAP format)
    -i Reference point live capture interface
    -I Monitor point live capture interface
    -r Reference point remote slave name/address
    -R Monitor point remote slave name/address

    Network Options

    -l Length of the timestamp field in bytes [1 - 4] (Default: 2)
    -g Granularity of timestamps in microseconds (Default: 100)
    -t Network update timeout - Maximum time in seconds between slave sending spp sample frames to the master (Default: 1)

    Output options

    -c Output 'Pair Count' (Running total of pairs the program has generated)
    -m Calculate timestamps from monitor point clock rather than the reference point clock (Output timestamps are the average of the packet's timestamps that were combined to make the pair)
    -p Output 'Server Processing Times' (The time between matched packets seen at the monitor point)

    Packet Matching Options

    -# code

    The # option maybe used to set which fields are used in the packet matching process.

    The value of 'code' is the total of all the required field IDs as listed below:

    IP fields
    1 Source Address
    2 Destination Address
    4 Protocol
    8 Identification
    TCP/UDP fields
    16 Source Port
    32 Destination Port
    TCP fields
    64 Sequence Number
    128 Acknowledgement Number
    256 Checksum
    UDP Fields
    1024 Checksum

    Additional advanced compile time options can be found in config.h in the 'src' directory.

    Clock Synchronisation

    Machines used for capture should have synchronised clocks (within a couple seconds). If you find SPP is not generating estimates, it is most likely due to system clocks which are outside this range.

    If you know that your captures have a fixed offset, SPP can take the offset into account. The offset can be specified in seconds using the -o option, where the value referes 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 link on the 'Publication and Presentations' page for more details on 't delta'.

    Bugs

    Known Issues in SPP 0.3.2
    • Remote capture has not received much testing
    • SIGINT may not quit when using remote monitoring
    © Swinburne | CRICOS number 00111D | Contact Us | Copyright and disclaimer | Privacy; | Feedback | Accessibility Information | - Smaller Font | + Larger Font
    Last Updated: Friday 15-Apr-2011 12:12:02 EST | Maintained by: Amiel Heyde (amiel@swin.edu.au) | Authorised by: Grenville Armitage (garmitage@swin.edu.au)