| September 30 from
8:45 – 10:00 am (CDT)
SPEAKERS
Eric Boyd, Internet2 [PPT]
Join the Federationof Network Measurement Infrastructures piPEs Update
Eric Boyd introduced himself to the group and presented the agenda. The goal of this session is for participants to be sufficiently intrigued to want to begin the process of setting up a measurement infrastructure at their home location.
Boyd began with a problem statement – the need for a finger point tool, ability to do tests in the middle, tests to the middle, etc. “The network is broken” is the phrase none of us want to hear; not only is this usually not correct, it also doesn’t help solve the problem. Can the average user easily discover if there is something broken in the machine or wall jack and can the more sophisticated user determine the location of the problem via partial path analysis?
- Average user: The approach is self-diagnosis – a) find a measurement server “near me,” and b) detect common tests in first mile. The user should not need be a network engineer. Instead of ‘network is broken’, the hoped for result is ‘the tool you pointed me to says I have a duplex mismatch. Can you fix it?’
- Sophisticated user: The approach is to make it easy for them to identify the end-to-end path, discover measurement nodes “near” hops along the route, authenticate to multiple measurement domains (based on locally-defined policies), and initiate tests between remote hosts. At the completion of these tests, the sophisticated user can see test data for previously run (from other test-requesters) and on-demand tests. Instead of a) ‘Can I have an account on your machine or can you setup and leave up an Iperf server so I can run tests when I need them?’ or b) ‘Can you get up at 2 a.m. to startup Iperf?’ or c) ‘Can you make up a policy on the fly just for me?’ the hoped for result is a regular means of authentication, measurement peering agreements between locations, no chance of polluted tests (because the tests cannot be running at the same time with this system), and regular and consistent testing to establish baselines.
Example: Recently, Abilene received a request from the University of Michigan to run a test to the middle of the network – a year ago, the response would have been ‘sure, we know you. We’ll set it up at x time,’ whereas now the response is ‘here’s an account to run tests; when you make a request, the system will find the first available slot for you.’ A Use Policy has been developed and implemented, with limitations to frequency and duration of tests based on a range of potential ‘roles.’
Boyd covered the status of efforts in three phases of the project:
- Phase 1 (Tool Beacons) – BWCTL, OWAMP, and NDT – all tools are complete and ready for deployment.
- Phase 2 – Measurement Domain Support
- Phase 3 – Federation Support
- AA (prototype – optionally AES key, policy file, limits file)
- Discovery (measurement nodes, dbases) (prototype – nearest NDT server, web page)
- Test request/response schemal support (prototype – ggf NMWG schema)
What is BWCTL? Resource allocation and scheduling daemon for arbitration of Iperf tests – Iperf is a command line tool that doesn’t limit the bandwidth you request for a test. BWCTL is a wrapper around it and allows the test-granter to establish limits on time and resources. New features include: 1) the ability to set up 3-party communication (a user can request tests between two other hosts), 2) authentication across multiple domains (with different authentication policies), 3) no local BWCTL daemon is required (it spawns its own on the machine without the BWCTL daemon for the period of the tests) and 4) port ranges can be specified (to allow users to get around firewall problems).
What is OWAMP? This tool is built using the IETF specifications for a one-way active measurement protocol. It controls the connection used to broker tests, and, like BWCTL, it allows you to control bandwidth, frequency, and timing of test requests. New features include providing the hop count and allowing the user to specify port ranges.
What is NDT? NDT is a single-shot diagnostic tool that runs tests from the local end-user’s desktop to the ‘nearest’ identified server. The tool is designed to be user-friendly but also provides data sufficient for more sophisticated users to solve problems. This is a SourceForge-based open source development project.
Where is piPEs? Currently, piPEs software is deployed at locations shown below:
A Global PMP Directory is available – the value of each of these PMPs is increased by the number of participants. Boyd described what a participant would need to do to join the PMP listing – 1) setup a policy (however restrictive) for running tests to your location, 2) fill out the form, and 3) email it to: measurement-domain-registrar@internet2.edu. The piPEs team will list it and people who want to test to your location can contact your contact person. You can find locations from the list and contact other administrators.
A major goal of piPEs is solving the ‘first/last mile’ problem – piPEs has installed the measurement instruments on the backbone network; Boyd gave several suggestions as to how session participants could help the effort:
- Have individual campuses setup NDT serves next to the campus edge.
- Quality control of the network backbone (see results from the regularly-scheduled tests). Currently, web-services allows users to consume that data (several projects are already so doing).
- Join a federation of networks – become a peering point between networks!
- Extend quality control from the campus edge out to the GigaPoPs.
- Set up a mesh of regularly-scheduled tests and allow users to schedule on-demand tests.
Boyd reported on American/European collaboration goals – Internet2’s piPEs team has been working with the GEANT2 JRA1 team, who share many of the same goals (desire for many similar types of measurements, need for interoperable frameworks so that transatlantic partial path analysis can be possible, etc.). Currently, the goal is for an open source shared development project. Coordinated demonstrations have included:
A white paper on the architecture reconciliation is in progress and due in December 2004 – the final architecture will probably be services-based so that individual nodes can come on line and “announce” themselves. Boyd gave an example of how piPEs is being used – the e-VLBI community has need for very large data transfers over very long distances. They wanted to setup an experimental real-time data transfer from Onsala, Sweden to Haystack, MA, USA. They needed to run on Abilene, GEANT, and others and they wanted to be able to do partial path analysis to determine optimum speeds for transfers. Using BWCTL, they were able to quickly set up a network of beacons, determine the existence of a bottleneck link, and get the link replaced before the public test was run.
This worked so well for them that, when they were setting up for the TSEV8 experiment from MIT Haystack to Kashima, Japan, they decided to put in BWCTL measurement points along the route because installation was very easy and had been useful in the past. In the week up to the experiment, the network showed extremely poor throughputs of less than 1 Mbps! Instead of the traditional pair-wise Iperf testing between hosts along the transfer path, step-by-step analysis of the results, and slow troubleshooting that would have taken weeks to accomplish, they used the BWCTL measurement points along the path and scheduled tests between each of the points. They discovered the problem in a mere four hours and were able to solve the problem so that, in the end, the VLBI data was transferred in a total of two hours, down from the 21 hours that would have been necessary with the un-optimized path.
|
