the Problem is 1/2 the Solution
Internet2’s piPEs has four goals:
When a user experiences a performance problem with an application
that employs long-distance, high-speed Internet connections,
it can be very difficult to locate the cause of the problem.
Even if the problem can be located, finding the right person
and convincing them to fix it is even harder. This is primarily
due to the decentralized design of the Internet, where each
network operator can run their network with very little coordination
from other network operators. While this approach has created
great flexibility and independence in building the Internet,
and is one of the main reasons the Internet has grown large
so quickly, it has also hampered the provision of any services
that need to be coordinated across operating domains. Currently, little or no operational information is externally
available about a network domain, which makes it particularly
difficult to locate problems.
- Enable end-users and network operators to determine E2E performance capabilities, locate E2E problems, and contact the right person to get an E2E problem resolved.
- Enable remote initiation of partial path performance tests.
- Make partial path performance data publicly available.
- Be interoperable with other performance measurement frameworks.
“In the ideal
world, network users would have a tool that could tell a user
where a problem is, what type of problem it is, and the person
to contact for the resolution of the problem.”
-- James D. Bruce (former Vice President for Information Systems,
MIT) in from "Beyond Bandwidth" (EDUCAUSE Review,
With Internet2’s piPEs, the average user would have a tool to locate not only the problem but also the individual responsible for its solution. In its final form, piPEs can determine the performance characteristics of the complete path by aggregating information about the segments that make up the path; problematic partial paths can be identified and reported, with supporting data, to the appropriate network administrator.
A battery of regularly scheduled active tests provides information on loss, jitter, throughput, and one-way latency data. If the necessary data is not included in the database, a test can be scheduled on demand. For example:
- The end user is experiencing problems; he requests information, specifying end points and type of application.
- The request is scrutinized to determine whether the requestor has the authority to make such requests and whether the two end-points share the same tool. If the answer to either of these is “no”, the request is rejected.
- If the answers are “yes”, piPEs checks the database to determine if the request can be met by regularly scheduled tests. If not, a test is scheduled on-demand.
- The test results are gathered and stored in a distributed centralized database. Then, piPEs analyzes the data and provides the user: a) the likely place to start looking for failure, b) contact information for the individual responsible for that administrative domain, and c) data to provide to the contact with sufficient cause to investigate the complaint.
The aim of this system is to reduce the “signal to noise ratio.” NOTE: piPEs, as described above, is the final product; at this time, work on the project is focusing on the database, web-based display engine, the analysis engine, and performance measurement points. The regularly scheduled tests include latency (OWAMP), bandwidth (BWCTL), and traceroute.
The initial deployment, which includes the Abilene backbone network and a few campuses, has been demonstrated at several workshops, including: TIP 2004, GNEW 2004, the Transatlantic Performance Monitoring Workshop, and the CANARIE-GEANT-Internet2 Lightpath Workshop. These demonstrations have included transcontinental, transpacific, and transatlantic paths; they have also demonstrated the ability of other tools to use the data provided by piPEs – both NLANR’s The Performance Advisor and the HENP-funded MonALISA project are able to display data collected by piPEs.