Internet2 End-to-End Performance Initiative: piPEs

1. Internet2 End-to-End Performance Initiative: piPEs Eric Boyd, eboyd@internet2.edu Matt Zekauskas, matt@internet2.edu Internet2 InternationalTask Force Meeting

2. Performance Measurement and Monitoring Architectures • What are we (Internet2) planning? piPEs (performance monitoring framework) • How can we interoperate? Common input/output schemas/interfaces (GGF NMWG) Common tool development (Open source; under discussion) • How are we collaborating internationally? (DANTE/GEANT, UCL, HENP)

3. What is “piPES”? • End-to-End Performance Initiative Performance Environment System (E2E piPES) • Goal: To allow end-users and network operators to determine performance capabilities, locate problems, and contact the right person to get a problem resolved. • Approach: Collaborative project combining the best work of many organizations, including DANTE/GEANT, NLANR/DAST, SLAC, UCL.

4. Sample Use Vision • User has a perceived problem (or wants to pre-test an end-to-end path) • Bring up Web page on end point • Input kind of application and other endpoint • Ask (local) piPES testing and analysis engine, “Will it work?”[Domain Interface]

5. What’s in the network?Using Internet2 as an example • Within Abilene, deploy test points at every router node • They run a full mesh of periodic tests (latency, traceroute, throughput) • They have access to local utilization data and sampled flow data • Similar points in gigaPoPs and then campuses • They run periodic tests among each other (depending on local preferences) • They run occasional tests into backbone nodes

6. Sample Use Vision, continued • Testing & analysis engine discovers performance measurement points along the path, determines a set of test results required • It uses the results of periodic testing • It schedules a local test to nearest test point, and any other tests where the data is stale • The results are used to “divide and conquer”, pointing to a suspect network segment and a contact point • The contact is given the results to further investigate the problem

7. Where are we now?(What is Internet2 implementing?) • Backbone router measurement points • Recurring testing written into database;IPv6 and IPv4 • On-demand testing • Web and “web services” output • Enough for knowledgeable human, or consumption by other projects (including those aimed at user interface)

8. Role of Internet2 • Membership contributing; work on holes • Provide central support where it makes sense, for example • Backbone viewpoints, architecture • Central knowledge repository • Help with path problems, connection with University/gigaPoP networking personnel

9. E2Epi Work • piPEs architecture (collaborative) • One-way measurement tools (e.g. OWAMP) • For intermediate servers • Scheduling • Database • Authentication • Export data via web service • Specific reference servers or beacons

10. Aside: Other E2Epi Work • Understand applications and their performance requirements • Technical Advisory Group • Provide best practices/experience for network operators • Collecting Performance Stories • Campus Network Infrastructure Guide • Pointers to relevant projects

11. Aside:Reference Servers / Beacons • (TCP) Performance debugging • Conjecture: 80% of problems related to • Host tuning (mostly buffers) • Duplex mismatch [path] • Other physical connection problem [path] • NDT: http://miranda.ctd.anl.gov:7123/ • H.323 conferencing • Goal: portable machines that tell you if system likely to work (and if not, why?) • http://e2epi.internet2.edu/Beacon/BeaconOverview.html • ViDeNet Scout, http://scout.video.unc.edu/

12. E2E piPEs Architecture

13. E2E piPEs Architecture v1.0

14. Intra-‘PMP’-Module Protocol

15. piPEs + Abilene Measurement Rollout (ongoing)

16. piPEs / AMI Rollout (ongoing)

17. piPEs / AMI Rollout (near future)

18. E2E piPEs Architecture (Grid)

19. Coordinating Interoperably • A few levels • Awareness of other projects • Cooperate on architecture development • Ensure important interfaces are shared/publisheduse our data! • Share code • Install each others nodes • Please comment on architecture • TF-NGN focus on inter-domain issues

20. Coordinating • Measurement Schema(lots of work in GGF) • Authentication and Authorization • Roles for access (End user, test buddy, NOC) • For us, try Shibboleth for implementation • How discover PMP/domain interface

21. Coordinating (help) • Debugging algorithms using data • Designing system to scale • Balance centralization and distributed database requirements

22. References • http://e2epi.internet2.edu • http://abilene.internet2.edu/observatory/

24. Intra-‘PMP’ Module Components • Domain Interface: Web Service Interface to Request Performance Data • Performance Measurement Controller (PMC): Schedules Tests • Performance Measurement Point (PMP): Performs Tests, Stores Results in Database • Source: Initiates Test Request • Target: Accepts Test Request & Starts Test

25. Domain Interface • Request Interface: • Accepts External Result Requests • Compares Requestor Role to Policy • Rejects Request or Queries Response Interface • Response Interface: • Accepts Result/Tool Requests • Compares Requester Identity, Source Role to Policy • Decides if Tool is Available • Rejects Request or Supplies ‘Capability’

26. Initiator / Acceptor Performance Measurement Controller • Initiator PMC: • Supplies Capability, Identity, Tool • Acceptor PMC: • Accepts/Rejects/Delays Request Based on Policy • Contacts Target PMP to Initiate Test • Accepts/Rejects Request Based on PMP Response

27. Target / Source Performance Measurement Point • Source PMP: • Accepts/Rejects Requests to Start Test based on Identity • Starts Tests • Target PMP: • Accepts Test from Source PMP • Stores Results Locally • Sends Data to DB Gatekeeper

28. Database Gatekeper • Accepts/Rejects Requests to Store Data based on Identity • Accepts/Rejects Requests to Release Data based on Role, Identity • Supplies Performance Data

29. piPEs Tool Deployment on Abilene • All tests on IPv4 and IPv6 • OWAMP: Deployed on 10/11 nodes (nms4) • IPERF – UDP: In deployment beta on 2 nodes (nms1) • IPERF – TCP: In deployment beta on 2 nodes (nms1) • Traceroute: In deployment beta on 2 nodes (nms4) • Router Data: Deployed on all 11 nodes (router interface) • Flow Data: Deployed on 10/11 nodes (nms3)

30. Goal of this talk • Performance Measurement and Monitoring Architectures: What are networks planning and how can we coordinate interoperability? [DELETE THIS SLIDE WHEN DONE]