E2E piPEfitters A Collaborative, Services-based Approach to a Measurement Framework Eric L. Boyd Jeff W. Boote 4 August 2019

Outline Overview Status Update Service-based Architecture Why a measurement framework? What is piPEs? Status Update What’s new / What’s coming? American / European Collaboration Service-based Architecture Requirements Proposal 8/4/2019

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. Enable remote initiation of partial path performance tests Make partial path performance data publicly available Be interoperable with other performance measurement frameworks 8/4/2019

System Architecture (Apr 04) 8/4/2019

piPEs Current Measurement Points BWCTL / Iperf Throughput, Loss, Jitter NDT Detects common first mile conditions OWAMP Latency, Hop Count 8/4/2019

piPEs Measurement Advancements BWCTL v1.1b (2 weeks old) 3 Party Serverless Client Port Range support to make it filter friendly Bug Fixes NDT v3.0.20 (1 week old) Hosted at Sourceforge Redirects to “nearest NDT server” OWAMP v2.0? (next week) Upgrade to latest release of OWAMP specification Report Hop Count information in addition to 1-way Latency 8/4/2019

piPEs Measurement Futures BWCTL Closer Integration with Throughput Tester NDT Research into detection algorithms Extend number of conditions detected Analyze “middle” from end user perspective OWAMP Replace jittery Unix system clock with better clock based on CPU instruction counter Eliminate dependence on NTP system calls 8/4/2019

piPEs Measurement Framework piPEs v0.1 alpha prototype Limited release over summer Now publicly available Same code that runs on Abilene Measurement Infrastructure http://e2epi.internet2.edu/pipes/ Prototype Limited documentation Not very flexible configuration piPEs v0.2 beta prototype Planned for Q4 2004 (Short-Term) Support aggregation pipelining of data Databases become sources as well as sinks 8/4/2019

Going Forward To date, we’ve gained experience with our measurement framework prototype It has given us insights into: Data Community Tools Now that we have some experience … Iterate the design to match our experience Our vision was high-level Now we need to implement the vision 8/4/2019

Metcalf’s Law Our version: The value of a performance measurement framework scales with the square of the deployment footprint One organization cannot create a successful measurement framework in a vacuum GGF NMWG: Enable multiple measurement frameworks to work together MonALISA, Advisor: Demonstrate interoperability of our measurement framework GEANT2 JRA1: Shared goal of building a next generation measurement framework 8/4/2019

American / European Collaboration Achievements UCL E2E Monitoring Workshop 2003 http://people.internet2.edu/~eboyd/ucl_workshop.html Internet2, DANTE, CANARIE biannual meetings (12/03, 07/04, 01/05) Transatlantic Performance Monitoring Workshop 2004 http://people.internet2.edu/~eboyd/transatlantic_workshop.html Caltech <-> CERN Demo Haystack, USA <-> Onsala, Sweden 8/4/2019

American / European Collaboration In Progress piPEs Software Evaluation PSNC (Poland) deploying BWCTL, OWAMP, piPEs Measurement Framework v0.1 alpha prototype Architecture Requirements / Design Reconciliation Internet2 E2Epi and GEANT2 JRA1, JRA5 8/4/2019

American / European Collaboration Going Forward Anticipated Outcomes: Open Source Shared Development Sourceforge-based Sub-Projects Modified Berkeley Licensing Common Service-based Architecture (more on this later in talk) Architecture spans superset of deployment use cases ~Quarterly face-to-face meetings ~Weekly phone conferences Split development according to interest, resources Additional Contributors Welcome eboyd@internet2.edu 8/4/2019

Beginning Architecture Refinement Account for: New insights based upon Abilene prototype framework experience New insights gained from inter-domain framework test experience Additional use cases envisioned by collaborators Members, GEANT2 JRA1, GGF NMWG 8/4/2019

System Architecture (Apr 04) 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. 8/4/2019

Goals (As Previously Stated) Enable end-users & network operators to: Determine E2E performance capabilities Locate E2E problems Contact the right person to get an E2E problem resolved Enable remote initiation of partial path performance tests Make partial path performance data publicly available 8/4/2019

Architecture Requirements Enable tests within and across administrative domains Announcement / Discovery of Measurement Points, Performance Data Repositories Enable virtual organizations to run tests (VO is an organized community of those individual users) Individual and/or Role-based Authentication Authorization to initiate tests (regular or on-demand), recover results Low Participation Investment Wide scale deployment across “campus” Individual users can participate (VO of one) Low administration overhead Flexible measurement results Store performance data Facilitate aggregation of data 8/4/2019

Architecture Proposal Services Oriented Architecture In a simple scenario, each domain consists of a set of services. All services are well defined and independent. Services within a domain represent the domain with the help of AA – they respond to requests only if the AA service of the domain has authorized it 8/4/2019

Base Services 8/4/2019

Lookup Service Initial discovery Multicast Well known servers Required servers (by administrative configuration) Previously detected servers (organized in a P2P network – lookup services find out about other lookup services… 8/4/2019

Lookup Service (II) Lookup is not simply by name Response contains Type (type of measurement, type of service) Community Network path Organization Type of authentication required Other… Response contains Contact information Available services Authentication required 8/4/2019

Authentication Still a service like any other (may require prior authentication just to use this one). Client requests some “kind” of authentication token based upon what the lookup listing said was required. Authentication protocol for determining what “role/identity” a given request will receive. (This is how federated authentication can fit). Authentication service will grant a time-limited token that can be used to request service from agreeable service providers. 8/4/2019

Test Executor Service to wrap measurement tools. Interacts with resource brokers to protect shared resources. Registers with lookup service and specifies the authentication credentials required to interact. Registers with lookup service to indicate types of tests it can perform. If a given test produces data – it must also implement the publisher service. 8/4/2019

Resource Broker Used to enable more centralized control of resources. Multiple test executors interact with a given resource broker to limit the resources that are shared between them. Resource brokers can be chained hierarchically to control aggregations of resources across larger frameworks. 8/4/2019

Publisher Used to push data matching a specific subscription out to a Data Subscriber. A data subscriber might have requested a specific subset, or a specific component could be configured to always send data to a given subscriber. (push or pull). 8/4/2019

Subscriber A data client would create this service to accept data from a data publisher. Requests some set of data from a Publisher using a subscription. 8/4/2019

Derived Functionality 8/4/2019

Regular Measurements A configurable entity that makes requests at some pre-defined intervals to multiple test executors to instrument a network. 8/4/2019

Data Archive Implements both the publisher and subscriber services. Subscribes to some set of data – can do aggregation on that data. Publishes the derived data sets. 8/4/2019

NOC Alarm Subscribes to data matching some specific pattern. Performs some pre-defined action when the pattern matches. 8/4/2019

Domain Proxy Allows for “dumb” clients. 8/4/2019

Process Flow (Tool Beacon) Register with lookup service. Find possible controlling resource broker. Handle requests. Execute tests and possibly publish results. 8/4/2019

Process Flow (User Client) Discovery. Find lookup servers. Use lookup servers to find tool beacons for a given problem. (On correct path, with acceptable authentication requirements, with acceptable tools/measurements.). Authentication. Authenticate to correct auth servers that are needed for desired test executors. Test execution. Implement subscriber to accept results. Make test requests presenting credentials and reference to subscriber interface for returned data. 8/4/2019

Architecture Refinement (Full Test) 8/4/2019

Architecture Refinement (Initialization) 8/4/2019

Architecture Refinement (Authentication) Federated trust will be needed Allow new measurement points to be created as easily as possible Allow new data consumers access as easily as possible 8/4/2019

Architecture Refinement (Request Phase) 8/4/2019

Architecture Refinement (Brokering Resources) 8/4/2019

Summary Short-Term Medium-Term Long-Term We have working measurement points We have a prototype measurement framework Focus is on widescale deployment Medium-Term Design a services-based measurement framework Build a prototype services-based measurement framework Use case validation Long-Term Deploy a services-based measurement framework 8/4/2019

Invitation to participate Architecture being refined Drawings represent a work in progress Feedback, contributions welcome eboyd@internet2.edu Join at an individual level or an institutional level 8/4/2019

8/4/2019