January 27 , 2004 from 11:50 am - 1:30 pm

SPEAKERS
Jeff Boote, Internet2 [PPT]
Eric Boyd, Internet2 [PPT]
Rich Carlson, Internet2
Hyungseok Chung [PPT]


ATTENDEES
TBD


BWCTL
Jeff Boote described the bandwidth control tool developed for use with Iperf to regularly schedule and on-demand Iperf tests to keep them from interfering with one another. It is a resource allocation and scheduling daemon for arbitration of Iperf tests. It checks with both your local side and from the end-testing point.

This avoids some of the typical roadblocks - authorization/permissions on all the different systems involved, the need to coordinate testing with others and need to run software on both sides with specified test parameters (regimenting). You still need to have software on all test systems.

BWCTL accepts or rejects requests for "Iperf"-like tests including timeslot and parameters for test. If you miss your slot, you have to reapply. Both sides get the test results and can validate the data. Resource allocation model - trying to set it up so that there are spheres of control that the BWCTL control daemon lets you know that the test is approved and it asks for approval at a higher level for authorization (until it determines authorization). That way a network would be able to control the amount/number o f tests allowed from any outside entity.

GGF NM-WG Update
Eric Boyd discussed the hierarchy of network performance characteristic and the test request/response schema that is under review by the GGF. Standard set of network characteristics, network classification hierarchy and aimed at being a Grid applications service STANDARD.

To describe a network measurement, need the characteristic being measured and the entity being measured. Eric briefly described the topology representation. There are many different ways to do this work and the idea of the schema is to make interoperability a possibility. He briefly described the test/data request and response protocol schema. He provided URLs for the requirements document and some examples of using the schema.

Detective Integration of NDT and E2E piPEs
Rich Carlson noted that he is a new addition to the E2E piPEs team; he is focusing on getting to the desktop. Based on the piPEs architecture cloud, you want to have repetitive tests in the network but you can't have repetitive tests to the hosts (unless requested by the host owner). Focus has been on getting the backbone infrastructure monitored; new focus is on a topologically close location to the desktop. Looking for configuration and performance problems. Would like to run specialized packet flows to analyze what is going on. No historical data because you are not running regular tests.

Problems: tool many not be installed, test program may not be available on your OS, authority/authorization questions (security and storage of results). Want to enhance the existing Internet2 Detective to go to the core of the network and identify E2E problems. Rich provided an overview of the benefits and problems with NDT, which is aimed at identifying the "last mile" problems. Taking features from the Detective, you can minimize the problems (consume some of the piPEs data to help it analyze the data). User would need to know the location of 1 of the 11 nodes nearest you (form your home); the server gets your IP address from the network packet that came in and resets you to the closest measurement node on the network. You know the one at home and visit Hawaii, for example; it automatically resets the closest node to be the one closest to your current physical location. Hopefully, this will enhance the diagnostic, drill down, and reporting functions.

Rich gave an overview of the Detective operations. This uses the "divide and conquer" approach to diagnostic and troubleshooting procedures. Serious desktop configuration problems will be found quickly with little impact on the backbone network. Detective will provide a single point of contact for the E2E piPEs framework.

Wise TrafView Tool
Hyungseok Chung discussed the Wise TrafView tool, a flow-based measurement and analysis system being developed via APAN. He talked about why the common flow tools are not enough: non-flow measurements are not enough to capture packets in current networks (because of many problems, including P2P traffic) but the need for flow-based measurement is growing in direct proportion to the inability to measure the flows.

They apply a classification system to applications to allow them to recognize the application types.