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

2. 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

3. 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

4. System Architecture (Apr 04)
8/4/2019

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

6. piPEs Measurement Advancements
BWCTL v1.1b (2 weeks old)
3 Party
Serverless Client
Port Range support to make it filter friendly
Bug Fixes
NDT v (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

7. 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

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

9. 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

10. 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

11. American / European Collaboration Achievements
UCL E2E Monitoring Workshop 2003
Internet2, DANTE, CANARIE biannual meetings (12/03, 07/04, 01/05)
Transatlantic Performance Monitoring Workshop 2004
Caltech <-> CERN Demo
Haystack, USA <-> Onsala, Sweden
8/4/2019

12. 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

13. 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
8/4/2019

14. 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

15. 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

16. 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

17. 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

18. 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

19. Base Services
8/4/2019

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. Derived Functionality
8/4/2019

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

29. 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

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

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

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

33. 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

34. Architecture Refinement (Full Test)
8/4/2019

35. Architecture Refinement (Initialization)
8/4/2019

36. 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

37. Architecture Refinement (Request Phase)
8/4/2019

38. Architecture Refinement (Brokering Resources)
8/4/2019

39. 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

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

41. 8/4/2019