Monday, July 19, 2004
SPEAKERS:
Eric Boyd, Internet2 [PPT]
Eric provided an update on the pipes project. He noted that, in the past, he talked about what had been done to the piPEs software over the past quarter; this time, he focuses on what users can do with piPEs. Eric talked about the overarching project goal – being able to pinpoint a problem location, present information to the expert responsible for the domain, and convince them solve the problem – but noted that several interim goals appeared during the tool creation process, including the need for partial path analysis and baseline data against which to compare test results.
piPEs has setup a full-mesh of regularly scheduled bandwidth and latency tests along Abilene, while still allowing users to schedule on-demand tests – this allows the end user to have baseline data against which to compare results as well as tests on an immediate problem. Eric identified the three different phases of the project
- Setup tool beacons for OWAMP, BWCTL, and NDT;
- Measurement domain support (both general and network specific); and
- Federation support (AA, discovery, and test request/response schema).
He gave URLs for the tool beacons (all online and readily available via the navigation bar at: http://e2epi.internet2.edu/). With regard to measurement domain support, Eric noted that the Abilene Measurement Infrastructure is fully deployed and there is a general measurement infrastructure prototype for use at various campuses. There are also prototypes and web pages for the AA, discovery and test request/response schema materials.
Eric reported on the current piPEs deployment in the U.S., Europe (via GEANT), and Asia (via APAN). He reported that Rich Carlson gave a talk on the Network Diagnostic Tool (NDT) at an earlier session – NDT represents the “last mile” portion of piPEs. It is a lightweight tool that allows the user to test from their own laptop into a network (many test locations are available) to see if there is a problem from their own location. Eric reported that there are a series of NDT servers (http://e2epi.internet2.edu/ndt/ndt-server-list.html) and, in time, Internet2 is creating a federation of NDT servers. He reminded attendees that the code is open source, and emphasized that it is a shared development environment. Eric gave an overview of the future direction for NDT from the point of view of Internet2’s piPEs project.
Then, Eric talked about how people can participate – initially, piPEs needs people to put up tool beacons (preferably at the campus edge plus another, internal location) at various places within their network domain and publish where the boxes are located. Eric reported that Internet2 has compiled a group of case/use studies that describe how folks have solved problems and asked attendees to a) submit more stories (either online or via discussion with E2Epi staff) and b) review the existing stories, commenting especially on the usefulness of the information provided.
Eric quickly described how one uses piPEs to “divide and conquer” via tests: a) edge-to-middle, b) middle to middle, c) edge to edge, and d) edge to campus edge. He reported on a BWCTL success story in the e-VLBI community – David Lapsley (MIT Haystack) needed to setup simultaneous real-time data collection from two radio telescopes (in different countries) on two occasions and discovered problems quickly enough to solve the end-to-end problems using BWCTL. David helped create a use study, which was available in hardcopy at the meeting and online at: http://e2epi.internet2.edu/case-studies/VLBI/index.html, describing how this tool helped him not have to be a network engineer; he create a web page that displays all the network data and points engineers to that page!
Q: On Abilene, are they (NDT, OWAMP, BWCTL) on separate machines – or all on one machine?
A: What we found on Abilene was that we consume almost all the bandwidth on one machine for Iperf so we’re going to add a second machine strictly for on-demand testing. At this time, on campus, you still need to have each of the tools on separate machines so they don’t compete with each other; this is being worked on so that campuses will be able to keep all the beacons on single machines.
Q: Those keys you’re sending out to run tests – will I have to get different keys from each campus network?
A: At this point, we give you a key for Abilene (only) but realize that this is not a very robust AA system; we’d like to create an automated system to hand out keys in the background but that’s in the phase three portion of our work.
|
