13-Oct-2003 Internet2 End-to-End Performance Initiative: piPEs Eric Boyd, Matt Zekauskas, Internet2 International Task Force Meeting

Internet2 Measurement Architecture for End to End Performance13-Oct 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)

Internet2 Measurement Architecture for End to End Performance13-Oct 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.

Internet2 Measurement Architecture for End to End Performance13-Oct 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]

Internet2 Measurement Architecture for End to End Performance13-Oct 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

Internet2 Measurement Architecture for End to End Performance13-Oct 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

Internet2 Measurement Architecture for End to End Performance13-Oct 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)

Internet2 Measurement Architecture for End to End Performance13-Oct 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

Internet2 Measurement Architecture for End to End Performance13-Oct 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

Internet2 Measurement Architecture for End to End Performance13-Oct 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

Internet2 Measurement Architecture for End to End Performance13-Oct 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:  H.323 conferencing Goal: portable machines that tell you if system likely to work (and if not, why?) – –ViDeNet Scout,

Internet2 Measurement Architecture for End to End Performance13-Oct E2E piPEs Architecture

Internet2 Measurement Architecture for End to End Performance13-Oct E2E piPEs Architecture v1.0

Internet2 Measurement Architecture for End to End Performance13-Oct Intra-‘PMP’-Module Protocol

Internet2 Measurement Architecture for End to End Performance13-Oct piPEs + Abilene Measurement Rollout (ongoing)

Internet2 Measurement Architecture for End to End Performance13-Oct piPEs / AMI Rollout (ongoing)

Internet2 Measurement Architecture for End to End Performance13-Oct piPEs / AMI Rollout (near future)

Internet2 Measurement Architecture for End to End Performance13-Oct E2E piPEs Architecture (Grid)

Internet2 Measurement Architecture for End to End Performance13-Oct Coordinating Interoperably  A few levels Awareness of other projects Cooperate on architecture development Ensure important interfaces are shared/published use our data! Share code Install each others nodes  Please comment on architecture  TF-NGN focus on inter-domain issues

Internet2 Measurement Architecture for End to End Performance13-Oct 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

Internet2 Measurement Architecture for End to End Performance13-Oct Coordinating (help)  Debugging algorithms using data  Designing system to scale  Balance centralization and distributed database requirements

Internet2 Measurement Architecture for End to End Performance13-Oct References  

Internet2 Measurement Architecture for End to End Performance13-Oct

Internet2 Measurement Architecture for End to End Performance13-Oct 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

Internet2 Measurement Architecture for End to End Performance13-Oct 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’

Internet2 Measurement Architecture for End to End Performance13-Oct 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

Internet2 Measurement Architecture for End to End Performance13-Oct 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

Internet2 Measurement Architecture for End to End Performance13-Oct Database Gatekeper  Accepts/Rejects Requests to Store Data based on Identity  Accepts/Rejects Requests to Release Data based on Role, Identity  Supplies Performance Data

Internet2 Measurement Architecture for End to End Performance13-Oct 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)

Internet2 Measurement Architecture for End to End Performance13-Oct Goal of this talk  Performance Measurement and Monitoring Architectures: What are networks planning and how can we coordinate interoperability? [DELETE THIS SLIDE WHEN DONE]