Internet2
Site Index | Internet2 Searchlight |
About Us | Members | Partnerships | Events | Newsroom
Initiatives | Applications | Security | Middleware | Networks
| E2Epi Home

End-to-End Performance Initiative
About piPEs
>Architecture
>FAQs
>Downloads
>IP
>Suggestions
Manual Pages
  >Installation Instructions
Links
>pipes-announce list
>pipes-users list
Network Performance
> perfSONAR
> BWCTL
> OWAMP
> NDT
> Thrulay
> Workshops
> NPToolkit
> Measurement Point Directory
> Internet2 Results
Community Engagement
> Working Groups
> Collaborations

E2E piPEs

piPEs Version 0.1a (alpha)


http://e2epi.internet2.edu/pipes/




piPEs is a number of different things depending upon the context:
  • It is a project spear-headed by the Internet2 Performance Architecture Team for the End-to-End Performance Initiative.
  • It is a collection of network testing and diagnostic tools:
  • It is a software package to facilitate intra-domain and inter-domain testing between multiple network test points. This software package includes software to:
    • Manage a collection of test endpoint hosts.
    • Collect results from the tests endpoints in a database.
    • Make those results available to others via a webservices interface.
    • Expose specific data views of that data via a web site.

This document deals primarily with the third aspect of piPEs; a software package used to facilitate network tests.

The main difference between the piPEs measurement framework and others is that the piPEs was designed from the beginning to deal with the idea of coexisting regularly scheduled tests and on-demand tests. Most other measurement frameworks specialize in either regularly scheduled or on-demand. piPEs does this by basically considering all regularly scheduled tests as simply an agent invoked on-demand test. Therefore, the scheduling of these "agents" is the way regularly scheduled tests occur.

There are several advantages and disadvantages to this methodology. The main advantages are that control can be distributed. The main disadvantage is also that control is distributed. However, a major design goal of piPEs is to enable inter-domain testing, therefore distributed control is a design requirement. The current architecture does not provide all the functionality required to provide for inter-domain testing. However, it was designed with enhancements in those directions in mind.

The image below represents the current architecture. Each cloud represents an administrative domain with respect to the piPEs software. The test results from any given test are sent to one, and only one database. Because the piPEs software has allowed on-demand tests from the beginning, the single domain data flow has not been as much of a problem as it might have been. Each administrative entity can run a test at regular intervals from one of its measurement points to a measurement point in another domain (given authentication/authorization) and save the results to its own database.


There are many limitations to this architecture, but it is reasonable from the point of view of a single administrative domain running tests between hosts within that domain. The software that makes this work can be broken down into a few different functional areas:

 
Tool Beacons allows on-demand tests of a specific type to be negotiated.
Test Controller runs tests from a single end-point to a tool beacon and reports the results back to a database.
Data Collector listens for connections from test controllers and receives new data. Also responsible for aggregating the data in the database.
Data Views Collection of programs that run on the database host that analyzes and makes plots of the data. Additionally, a webservices front-end has been written to allow direct export of the data to other tools that understand the GGF NMWG request/response schema's (this is in prototype condition).

Each Test Beacon is configured with a set of policy definitions that tell the beacon how extensive a test may be for particular users. The Test Beacons are used to facilitate any on-demand test. If these tests would be destructive to each other, then it must maintain scheduling information.

Each Test Controller is configured with the set of tests it should run including all test parameters and frequency as well as all test partners (test partners are implemented as Test Beacons). Additionally, each Test Controller is configured with a single Data Collector it should send the results to.

The Data Collector is configured with the full set of Test Controllers that will contact it. It also has configuration information to determine how to aggregate the data as more data comes in. The aggregation of the piPEs data is not done based upon the current time, but rather it is based upon how much data has been received.

The Data Views portion of piPEs is basically just a collection of cgi scripts. Most of them are used to give the user (web browser) a graphical view of some of the data. However, there is a webservices front end as well that can understand the GGF NMWG request schema and return the results that have been requested.

For a view of where we intend to take the software please see the piPEs white paper [pdf] and the most recent presentation [ppt].

Requirements

  • Linux or FreeBSD
  • Perl-5.8.0 or newer release
    1. Perl DBI module
    2. The software has only been tested with MySQL as the RDBMS, so DBD:mysql is required for MySQL. If you are interested in using another RDBMS, you may need to debug the database logging on your own. The mailing pipes-users@internet2.edu mailing list may be a good resource for discussing alternative RDBMS backends. You will also almost certainly have to edit some of the source where the DBD:mysql module has been specified.
    3. The sleepycat db3 (or greater) libraries are required for Perl to compile one of its database libraries. If these libraries are not compiled and installed, the appropriate Perl module will not be built even though the rest of Perl will be installed. This library is installed an available on most machines, but the library libdb.so (or something similar) should be in a path like /usr/lib and the header file "db.h" should be in /usr/lib.
    4. At this time, Debian 3.0 (woody) ships with old libraries and an old default Perl (Perl 5.6.1); this MUST be upgraded, otherwise you will get many, many problems.
    5. Properly configured MySQL, which has the MySQL local socket in the same location as the configuration file for MySQL specifies. NOTE: This misconfiguration occurs in some installations. If this socket is not in the same location as the Perl DBI modules think it is, the visualization CGI's and the collector software will not work.
  • OWAMP
    1. Having consistent file systems on all OWAMP beacons makes it easier when creating owmesh.conf and adding new beacons.
    2. Make the install locations for OWAMP and the filesystems used by these tools for data files consistent across all nodes for a particular test. All the OWAMP beacons should have the same data directory and var directory.
    3. Use the same user and group names for running the tests and the master and collector processes.
  • BWCTL
    1. Having consistent file systems on all BWCTL beacons makes it easier when adding new beacons.
    2. Use the same user and group names for running the tests and the master and collector processes.
  • Iperf (BWCTL currently requires Iperf)

Supported Systems

Tested most extensively on FreeBSD 4.7 and Linux 2.4.20 but most recent versions of UNIX should work.

Recommended Hardware

No strict hardware requirements. See the OWAMP and BWCTL pages for recommended hardware for these tools. Internet2 has had good luck using the hardware listed in this PDF document as a database server for collecting performance data on the Abilene network.

Building the Application

See the installation guide.

Please report any build problems to pipes-users@internet2.edu.

Mailing Lists

There are two email lists to support this software:
pipes-users
A general discussion list for users to discuss problems. We will monitor this list as we expect bug reports to be sent here.
pipes-announce
This list will be used to announce new versions or significant developments with regard to the software.

Information about these lists, including links to subscribe, is at https://mail.internet2.edu/wws/lists/engineering.

Authors

Eric Boyd
boyd@internet2.edu J

Jeff Boote
boote@internet2.edu
Internet2