| September 27 from
1:00 – 2:30 pm (CDT)
This meeting was for collaborators and contributors
of the E2Epi measurement and evaluation effort, piPEs.
Generally, the group discusses the development of piPEs, coordinates
efforts with other research groups to reduce duplication
of effort, and looks for volunteers for help with the
remaining tasks. This group encourages early adopters, contributors, and collaboration with parallel projects. At this point, the piPEs project has something that works (a set of usable tools and a framework, or “glue” to coordinate the use of these tools) and would like to focus on having more measurement points (beacons).
SPEAKERS
Jeff Boote, Internet2 [PPT]
Eric Boyd, Internet2
ATTENDEES
Bill Johnson, Tanya Brethour, Jim Ferguson, David Lapsley, Matt Zekauskas, Aaron Brown, Russ Hobby, Martin Swany, Youngseok Lee, Leobino Sampaio, Rich Carlson, Jose Suruagy Monteiro, James Deaton, Jeff Boote, David Matthews-Morgan, John Morre. George Brett, Jim Diamond, Connie Logg, Don Choi, Eric Boyd, C.R. Cheuli, Mark Poepping, Kevin Miller, Chas DiFatta, Lee Varian, Kevin Walsh, Masaki Hirabaru, Susan Evett.
Goals for piPEs
End-users shouldn’t have to be experts and they shouldn’t even necessarily have to know what the problem is that is occurring. Ideally, the end-user would determine that they are getting substandard service; using piPEs, they would quickly be provided with a probable location of the problem (with supporting data to convince an expert) and be pointed to a network administrator who could fix the problem.
A short-term goal is to enable remote initiation of partial path analysis. To do this effectively, piPEs must be interoperable with other network infrastructures. Boyd showed a slide of the system architecture as of April 2004. He noted that the system is designed to incorporate all tests (eventually) but currently uses Iperf (with the BWCTL wrapper), NDT, and OWAMP. Boyd provided a brief update on the status of the tools:
- BWCTL has a brand new release with three new features – it can be used by a third-party, as a server-less client, and the port range support makes it filter-friendly. The release also includes a number of bug fixes.
- NDT now redirects to the nearest NDT server – it is hosted at SourceForge.
- OWAMP – a new release of OWAMP is coming out next week to upgrade to the latest release of IETF specifications; it will also include port range support to make it filter-friendly and it will report hop count and other details.
Where are these tools going? BWCTL will have closer integration with the throughput tester; NDT is focusing on research in detection algorithms, extended number of conditions detected, and analyze the middle for the end-user perspective; OWAMP will be replacing the jittery system clock and eliminating the dependence on NTP calls.
Boyd reported that the group had recently released an alpha prototype, with limited documentation, which is publicly available. This release is uses the same code that runs on the AMI (http://abilene.internet2.edu/observatory/) and emphasized that it is a prototype. He elaborated to say that it is not a very flexible configuration at this time.
Boyd’s group is working on a beta prototype to support aggregation pipelining of data so databases become sources as well as sinks. At this time, the group has gained experience with:
- Their measurement framework prototype,
- Insight into the type of data that can be collected,
- The types of tools needed, and
- The communities that are interested in it.
Boyd noted that the white papers developed for this project track the learning process. (See http://e2epi.internet2.edu/library_list.html for a complete list.)
Boyd explained that the true value of a performance measurement framework scales with the square of the deployment footprint. One organization, alone, cannot create a successful measurement framework in a vacuum. The more performance measurement points (PMPs) that are brought up, the more useful the system becomes. Thus, one organization cannot build a framework and expect everyone else to want to use it – so the piPEs team has worked closely with the Global Grid Forum (GGF) in their Network Measurement Working Group (NM WG) to design a common language for requesting tests and giving responses. By designing a series of standards, the team has also been working with people working on multiple measurement frameworks to get them to be interoperable with each other and with other network frameworks.
Boyd reported on the collaboration efforts with DANTE and others over the past year. He also described the architecture requirements for various communities; authentication issues and specific, locally-determined, authorization policies are key problems. PiPEs is moving towards a role-based AA system – authorization at this time involves individual accounts and that does not scale. The focus is on having a low participation investment – wide spread deployment, where individual users can participate, and a low administration overhead (cheap to put in, run, high return on investment).
Boote presented a proposed architecture that he asked the group to comment on. Big issues under consideration include:
- Discovery (when you put up a new box, how do others know it is there?),
- Bootstrapping (multicast, well-known servers, required servers, or previously-detected servers and then it can find all the others it knows about, in a peer-to-peer approach),
- Lookup (type, community, network path, organization, type of authentication required, etc. and the response),
- Authentication,
- Test Executor (a wrapper around measurement tools),
- Resource Broker (which might be the way to centralize control over limited resources), and
- Publisher (need standards).
Boote showed a slide of architecture refinement with the full test and then he showed slides of the:
- Initialization steps (registration),
- Authentication, which will require a federated trust model (this allows PMPs to be created more quickly and with less policy investment in each one),
- Requests phase, which would allow a point to iterate the first available slot that works for both parties, and
- Brokering resources (focusing on link resources, host resources and valid parameters – one might find a broker that is hoarding resources).
Q&A
Q: Is there some overall schedule showing what tests are going on at the same time – everyone having problems and everyone begins testing at the same time.
A: No overall schedule –this will be simpler; people are only interested in shared resources and this system won’t give up the resource until it is available. The broker keeps over-use from occurring.
Q: It would be great to have the data pushed to the user – these are the tests running vs. users trying to find out what is running.<
A: The data become accessible so it is a matter of finding who needed it.
Q: What do you use for authentication?
A: In the short term, users can leave the OWAMP and BWCTL nodes open, with limitations on bandwidth and times allowed for testing. For testing to the Abilene backbone, users are given keys based on “trust” (known by Matt Zekauskas). In the long-term, the plan is to use a Shibboleth-like system. (At this time, Shibboleth doesn’t support non-web-based authentication.)
Q: You mentioned a “resource broker” – do we have to create it or is it provided?
A: It is provided but you can modify the “defaults.”
Q: Is that something you could just install?
A: Yes, that’s something we’d be writing and you could modify it if it doesn’t cover all the same stuff you need.
Q: How much time (FTEs) will it take to get this up and running?
A: We’re trying to identify that – currently, we have a system that is up and running on Abilene and we could roll that over to someone else.
Q: Are you working with CANARIE on this?
A: They are interested in the project, but don’t have resources to commit to it, in terms of development – current contributors are GÉANT2, UCL, and Internet2; CANARIE is interested in using the system when it has been fully developed.
Q: Where are you in the collaboration with GÉANT – will they be building their own tool?
A: No, we’re working together. We have many common goals but neither group has reached those goals. Our collaboration goal is to reach a common architecture we can both agree on, with perhaps some portions more necessary to one group, some to another, some to all. We’ll divide the work based on what is most important to the group (all) and then each developing portions that are more important to them. GÉANT likes BWCTL and OWAMP – they will probably accept BWCTL as is and they might use OWAMP or might use a German tool but, if they do, they will modify the tool to be interoperable. They are not building any tool like NDT so they will probably use it; we are working on the Detective issue (Internet2 or SURFnet or a combination?). The Polish research network is revaluating the tools because they don’t know what they want and want to see what this gives them.
C: What I’d like to see is having a particular professor put up a PMP at their site (more researchers than NRENs) which will push the deployment faster.
Q: Test executors – it would be useful to have an overall executor.
A: This isn’t going to be static. Large-scale deployment, portions/modules of the code can be developed as things develop.
Q: The executor is tool-by-tool based; is there a user-interface that knows where the tool executors are?
A: I forsee complex test executors that can run a grouping of tests.
After Boyd described the base services usage (see slide):
Q: Have you thought of having it tell you when it gets results?
A: Yes, that’s why there’s a subscription/publish model. If you want to know whenever a specific event occurs, it can tell you. The publisher might be a data aggregator that might be a subscriber to a range of data collectors.
Q: If you were looking at an environment and wanted to run tests across domains and there are different tools in different domains, will the test executor deal with that?
A: In the typical case, you can’t run different tools and get results. Eventually, if we can tool the Test Executor functionality correctly, we’d be able to wrap each new tool we found so that it fits into the framework – much like the Advisor framework wrappers. Partial path analysis allows you to use a range of tools as long as they use the same response schema and the data can be aggregated/analyzed.
|
