Tuesday, July 20, 2004

SPEAKERS:
Eric Boyd, Internet2
Rich Carlson, Internet2 [HTML] | [PPT] | [Summary]
Nicolas Simar, DANTE [HTML] | [PPT] | [Summary]
Tanya Brethour, NLANR/DAST [HTML] | [PPT] | [Summary]

ATTENDEES:
57 (near capacity but not SRO)

Eric Boyd opened the meeting and introduced the focus of the meeting. He announced that, as he had already given an update on piPEs during the track session and Rich Carlson had provided instructions on setting up an NDT server, the focus of this session would be primarily on the future of the piPEs project, with regard to the tools employed, and the status of other, related efforts. Rich Carlson would focus his NDT talk on how the NDT is being modified to fit with the existing piPEs architecture. Nicolas Simar, with whom the piPEs team has been working closely and giving demonstrations of interoperability, would give an update on the GEANT measurement infrastructure. Tanya Brethour, also with whom the piPEs team has been working closely and giving demonstrations of interoperability, would give an update on the NLANR’s Performance Advisor project.


Rich Carlson discussed how he modified existing NDT code to allow it to be extensible and publicly available. He provided a list of feature enhancements (including support for configuration files, local host testing, scheduling, queuing, federation mode, and command line client). Rich has begun work on a simple server discovery protocol that allows you to work in a federated mode that are all communicating and operating with one another; when a user logs in, they are automatically redirected to the nearest node. Since most problems are near the end host, it makes more sense to run the test as close to the user’s machine as possible.

Rich gave a brief overview of:

• The queuing/scheduling support effort and how it handles incoming client requests,
• How the federation mode works (multiple serves to coordinate testing services and force a local configuration test before allowing end-to-end performance tests), and
• The command line client (a new feature, designed to have the server do all the calculations instead of the local host).

Rich reported on the five NDT servers deployed within Abilene – plus one deployed at the Ann Arbor offices of Internet2 and one deployed on Starlight that are available to a restricted audience – when a user attempts to connect, they are automatically redirected to the nearest available server. He directed attendees to the web site and noted that manual pages, downloads, and information available at: http://e2epi.internet2.edu/ndt/.

Rich provided information about some experimental features that are not turned on in the production level code but that is available to users to use or modify at their interest. He discussed how the project is open source and actively looking for shared development; the code has been moved to SourceForge to make access easier for potential developers.

Future directions for NDT include focusing on improving problem detection algorithms (i.e., duplex mismatch, link detection, and improving performance tuning messages) to ensure the number of false positives are kept low and the tool can provide data on why a particular error is likely.


Nicolas Simar gave an overview of the work DANTE is doing to develop the next generation of GEANT. As part of the effort, they are incorporating a full measurement infrastructure and working with the piPEs project to ensure interoperability with American networks. One of the challenges is that JR2 will need a multi-domain network performance measurement management platform because traffic often crosses network lines (SURFnet, NORDUnet, etc.)

They created a PERT (Peformance Enhancement Response Team – Internet2 originally planned to do this with E2Epi but decided it could not afford the FTE to provide a swat team for the Abilene network); there are:

• Measurement points;
• A “user” interface;
• A domain manager that will locate the path causing problems (from among a federation of domains), collect data from that particular domain, and identify the individual responsible to solving the problem within the problem domain;
• A path finder; and
• An AA component to provide security.

Nicolas reported on the measurement point deployment (which include DFN IPPM and RIPE TTM as well as OWAMP and BWCTL) – by September, they will be able to provide data on the network.

As part of the presentation, Nicolas provided information on the JRAI1 goals – performance management, monitoring, multi-domain framework for exchanging information, and readily retrievable information. He provided a list of the benefits they expect to see from these changes (such as better visibility for the end user, easier troubleshooting, and raised awareness about common problems). The first area on which they are working is the measurement point layer (taking existing boxes and adding new features). The next effort focuses on the data consumer layer – they need good access to the data and methods to use the data collected; the last portion (the middle layer) is the domain manager layer, which includes discovery, AA, policy, and other issues that are not yet determined.

The Internet2 piPEs / GEANT collaboration has been very helpful on both sides; GEANT is also working closely with EGEE (the e-science group in Europe) to meet their needs.

Q: What do you plan for available bandwidth?
A: The difference between link capacity and link utilization, using SNMP variables.
Q: What kind of intervals?
A: So far using averages.


Tanya Brethour gave a brief background on the Performance Advisor for those who have missed the presentations at previous Joint Techs Workshops. The Advisor is a tool that measures, displays, and analyzes network metrics, using existing diagnostic tools. The aim is to emulate a junior-level network engineer in problem solving and provide suggestions such as “this is as fast as you’re going to get – don’t bother your network engineer.” The tool is made up of a data collector, an analysis engine, GUIs (only one of which is ready), and a data collector/historical archive. (Tanya noted that everything is written in Java.)

The tool was designed for each piece to be a standalone portion; the tool is ready for download now and comes with a variety of bundled tests. Users are allowed to create their own tool bundles and/or to create scripts that specify how the system will collect specific data. All tests are on-demand and handled in the order in which they were received – there are no regularly-scheduled tests.

Tanya gave an overview of the future development efforts:

• Using the request and discovery schemas,
• Reporting cost of metrics,
• Adding bundles, and
• Investigating moving from RPC to full document/literal.

The Performance Data Historical Archiver is a new piece of the tool – a user can access historical metrics for any of the tests they are interested in running, assuming that the test has been run before. Future development is for the Archiver to link into databases, such as the Abilene Measurement Infrastructure databases, to expand the range of historical data available to the end user.

She gave an overview of the current release of the analysis engine (public release in September 2004) and the future development plans (which include engaging the network engineering community to obtain more analysis test cases). Tanya reported on the three GUIs under development, only the Expert GUI currently being available. The Analysis GUI will be available in September, to make accessing tests easier. Tanya provided a rollout schedule and asked participants to review the project and provide input.

Q: Decision tree – what is the current approach?
A: For each test definition file, a tree is constructed for that question. We’ve tried to merge the trees over several test definition files but found that this doesn’t work if the definitions differ by more than one variable.
Q: What OS’s are you planning to support in the future
A: Linux now and Windows in the near future.