1. Overview of the Internet2 E2E piPEs project for EGEE-JRA4 people G.V.
Workshop:JRA4-NPM, July 22nd 2004
Overview of the Internet2 E2E piPEs project for EGEE-JRA4 people G.V.
EGEE is a project funded by the European Union under contract INFSO-RI

2. Contents piPEs goals framework architecture measurement components
infrastructure
software
AMD: an instance of the framework
interface with third-part clients
The material shown is from internet2 web
pages and several Eric L. Boyd
presentations
R-GMA workshop, July 22nd

3. Internet2 E2E piPEs
Project: End-to-End Performance Initiative Performance Environment System (E2E piPEs)
In its final form, piPEs should:
indicate performance capabilities
locate performance problems along the path between two computers (e.g. two nodes connected by the UCAID Abilene network, participating campuses, regional networks, and gigaPoPs).
(as a consequence) it will improve the likelihood that advanced Internet applications can operate at peak performance.
Approach:
Collaborative project combining the best work of many organizations, including DANTE/GEANT, Daresbury, EGEE, GGF NMWG, NLANR/DAST, UCL, Georgia Tech, etc.
R-GMA workshop, July 22nd

4. Internet2 E2E piPEs Goals
Enable end-users & network operators to:
determine E2E performance capabilities
locate E2E problems
contact the right person to get an E2E problem resolved.
Make partial path performance data publicly available
Enable remote initiation of partial path performance tests
Be interoperable with other performance measurement frameworks
“ we are trying to work very closely with Dante/Geant and EGEE to ensure interoperability (at a minimum) if not a shared code base across US and Europe”
R-GMA workshop, July 22nd

5. Framework architecture
Deployment is an inside-out approach. Start with regularly scheduled tests inside, make sure it plays well with regularly scheduled tests outside. Hope that projects working on the end nodes will meet us in the middle.
The goal of the framework architecture is to determine the performance characteristics of the complete
path by aggregating information about the segments that make up the path; problematic partial paths can
be identified and reported, with supporting data, to the appropriate network administrator.
R-GMA workshop, July 22nd

6. Framework architecture (II)
The framework developed has two strength points:
is extensible
is scaleable.
Test data might be stored in to per-administrative-domain databases
e.g. one for Abilene
other for campus or set of campuses …etc.
BUT: discovery of measurement nodes and corresponding measurement results might be a problem
R-GMA workshop, July 22nd

7. Measurement Infrastructure Components
For any given “partial path” segment (dotted black line) …
We might run regularly scheduled tests and/or on-demand tests.
This means, we require the ability to make a test request, have test results stored in a database, request those test resutls, and retrieve the test results.
Scheduled/on-demand tests.
Required the ability to:
request a test
store results in DB
request stored results
retrieve results
R-GMA workshop, July 22nd

8. Measurement Software Components
Black boxes
working and deployed
released:
BWCTL
OWAMP
NDT
prototype form:
Database, TraceRoute,
PMC,
PMP,
web service,
network monitoring
Red boxes
under development
Boxes in black working and deployed (either released or in prototype form). Boxes in red under development.
Theses are the software components that make up the piPEs measurement framework. Some are released (BWCTL, OWAMP), some are in “prototype format” (Database, Traceroute, PMP, PMC, web service, network monitoring), and some are under development (“Detective Applet”, Discovery module, Analysis module, MDI, NDT). The Measurement Domain Interface (MDI) is a web services interface that speaks the GGF NMWG Request/Report schema and handles authentication and authorization. It is being designed to be interoperable with other measurement frameworks (current and future). The Network Diagnostic Tool (NDT) is an existing tool that the original author is integrating into piPEs. It is designed to detect common problems in the first mile (the common case for most network “issues”).
This
becomes
black,
recently!
R-GMA workshop, July 22nd

9. Measurement tools
OWAMP: is an implementation of One-Way Active Measurement Protocol used to determine one-way latencies between hosts
BWCTL: Bandwidth control. It wraps Iperf, ensuring one process does not happen at the same time on either host, to determine the achievable bandwidth between a pair of hosts
NDT: Network Diagnostic Tool. It is designed to detect common problems in the first mile. Provides network configuration and performance testing to a user desktop or a laptop computer. Multi-level results allow novice and expert users to view and understand the test results.
R-GMA workshop, July 22nd

10. Abilene Measurement Domain
Internet2 has deployed an instance of the piPEs measurement framework:
the Abilene Measurement Domain (AMD)
ADM is part of the Abilene Observatory:
Regularly scheduled OWAMP (1-way latency) and BWCTL (Iperf wrapper) Tests
it gives to users “on the edge” the ability to test “to the midle”
Web pages displaying:
Latest results “Weathermap”
Worst 10 Performing Links
Data available via web service:
The E2E team is building the piPEs measurement framework.
Internet2 has deployed an instance of that framework, the Abilene Measurement Domain (AMD). AMD is part of the Abilene Observatory. Currently, the AMD consists of regularly scheduled OWAMP and BWCTL tests, plus the ability of a user “on the edge” to test “to the middle” (a crude divide-and-conquer approach to diagnosis E2E problems).
Network Monitoring is live (a prototype that will eventually be released) that allows simple analysis of network monitoring data across the backbone.
In addition, we’ve made that data available via a web service (conforming to the schemata of the GGF NMWG). Other tools, such as NLANR’s Advisor and the HENP community’s MonALISA tool can now consume that data.
R-GMA workshop, July 22nd

11. Example of data publication
R-GMA workshop, July 22nd

12. AMI Web Service
Abilene Measurement Infrastructure (AMI) measurements published as a web service.
piPEs/AMI Web Service home page:
Implementation of NMWG response schema
Data Service Implementation
Data served using perl SOAP::Lite
Both SOAP and XMLRPC services
Same back-end perl module
OGSI/WSRF server under development
Using OGSI::Lite
Also working on .NET/C#
R-GMA workshop, July 22nd

13. Database and Clients
Data pulled from same mySQL database as AMI graphs and other information on web pages.
Multiple clients have been tested
Perl, python for SOAP
Perl, Java (Advisor, Monalisa) for XMLRPC
Php for XMLRPC coming soon
Others?
R-GMA workshop, July 22nd

14. Supported Characteristics
Measured by owamp
Measured by bwctl
I have also published AMP data as path.delay.roundTrip at SOX. But the database is not regularly updated. I have listed this under future work.
R-GMA workshop, July 22nd

15. Other Inputs
Measurement Nodes by nickname (ATLA, CHIN, DNVR, HSTN, IPLS, KSCY, LOSA, NYCM, SNVA, STTL, WASH).
Type is IPv4or IPv6 at all nodes. Not case sensitive. “4” or “6” will suffice.
startTime/endTime
iso8601 is supported
Dan Gunter - “Timezones are a problem waiting to happen” - very true
Currently no support for epochSeconds
Too much opportunity for timezone confusion
R-GMA workshop, July 22nd

16. Summary of Project Phases
Phase 1: Tool Beacons
BWCTL (Complete),
OWAMP (Complete),
NDT (Complete),
Phase 2: Measurement Domain Support
General Measurement Infrastructure (Prototype)
Abilene Measurement Infrastructure Deployment (Complete),
Phase 3: Federation Support
AA (Prototype – optional AES key, policy file, limits file)
Discovery (Measurement Nodes, Databases) (Prototype – nearest NDT server, web page)
Test Request/Response Schema Support (Prototype – GGF NMWG Schema)
R-GMA workshop, July 22nd

17. Conclusions
At first sight piPEs project seems a very interesting framework for Network Performance Monitoring.
piPEs project is not yet completed but its status is well advanced
As part of JRA task we have not yet selected the criteria to make a comparison between various projects available for PM...
piPEs deserves to be deeply studied as a candidate...
R-GMA workshop, July 22nd

18. R-GMA workshop, July 22nd 2004 - 18

19. BWCTL (Jeff Boote) http://e2epi.internet2.edu/bwctl
R-GMA workshop, July 22nd

20. OWAMP (Jeff Boote) http://e2epi.internet2.edu/owamp
R-GMA workshop, July 22nd

21. NDT (Rich Carlson) Network Diagnostic Tester
Developed at Argonne National Lab
Ongoing integration into piPEs framework
Redirects from well-known host to “nearest” measurement node
Detects common performance problems in the “first mile” (edge to campus DMZ)
In deployment on Abilene:
R-GMA workshop, July 22nd

22. piPEs Deployment
R-GMA workshop, July 22nd

23. Bumps on the Road Perl is untyped. XML encoding
SOAP::Lite performs autotyping
Sometimes doesn’t do what we want!
Caused unexpected errors in java
Can over-ride but not yet done so (other priorities)
XML encoding
Defaults to RPC
Can over-ride to force Literal (again, not yet)
R-GMA workshop, July 22nd

24. Uphill Struggles
The hardest part of the implementation was decoding the XML.
There are some tools but mostly it was a time-consuming manual process.
XML::Parser
Prefer old-style Profile document or even a list of objects.
XML::Parser is a perl module. It is the closest I have found to being able to reformat the .XSD into a list of objects. Still a lot of extra junk is output. Also it doesn’t seem to handle the includes. I guess the point is in the future we won’t write clients or servers, tools will generate them from the WSDL. However, I don’t know any tools available now that I could’ve used.
R-GMA workshop, July 22nd

25. Client Side New client requires characteristic to be specified.
Partial implementation of request schema for requesting data not just measurements
Future deployment will follow request schema to request data and measurements
Only return what is asked for, previously everything available was returned.
R-GMA workshop, July 22nd

26. Example Client In perl: Wrap the request up in an object
my %request = ( networkCharacteristic => "path.delay.oneway",
subject => { source => { address => { name => "ATLA", }, },
destination => { address => { name => "LOSA", }, },
type => "IPv4", },
startTime => ” T00:00::00-5:00",
endTime => ” T23:59:59-5:00", );
my $webService = SOAP::Lite
-> uri('
->
-> NetworkMeasurementSet(\%request)
-> result;
Wrap the request
up in an object
Send it to the webservice
R-GMA workshop, July 22nd

27. Example Client Output print $webService->{version} 2004-01-15
print $webService->{networkMeasurement}->{characteristic}
path.bandwidth.achievable.TCP
R-GMA workshop, July 22nd

28. Supported Objects
Could add Memory, disk details (both can have a significant effect on performance).
Last updated field would be a useful sanity check.
Some system information can be retrieved by snmp, sysctl, currently hard coded.
Methodology has separate source and destination objects instead of single endpoint.
It is very easy to forget to update (for example) the operating system version. Particularly if it is hard coded. The last updated field would give the user the ability to judge if it is accurate.
In the Schema, the Methodology section has only a single ‘endpoint’ value. In the XML it looks reasonable but when you implement it, you find the client only gives the last value. Hence I implemented separate source and destination objects instead of the single endpoint.
R-GMA workshop, July 22nd

29. Non-Standard Objects
NetworkMeasurementSet => Help or NetworkMeasurementSet => Message
e.g. “No data matching query” or “no response from db”
Paola suggested using SOAP Failure
But not really a SOAP failure if there is no data matching the query.
Same applies for other SOAP messages
R-GMA workshop, July 22nd

30. Example piPEs Use Cases
Edge-to-Middle (On-Demand)
Automatic 2-Ended Test Set-up
Middle-to-Middle (Regularly Scheduled)
Raw Data feeds for 3rd-Party Analysis Tools
Quality Control of Network Infrastructure
Edge-to-Edge (Regularly Scheduled)
Quality Control of Application Communities
Edge-to-Campus DMZ (On-Demand)
Coupled with Regularly Scheduled Middle-to-Middle
End User determines who to contact about performance problem, armed with proof
R-GMA workshop, July 22nd