E2E piPEfitters A Collaborative, Services-based Approach to a Measurement Framework

1
E2E piPEfittersA Collaborative, Services-based
Approach to a Measurement Framework

• Eric L. Boyd
• Jeff W. Boote

2
Outline

• Overview
• Why a measurement framework?
• What is piPEs?
• Status Update
• Whats new / Whats coming?
• American / European Collaboration
• Service-based Architecture
• Requirements
• Proposal

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

4
System Architecture (Apr 04)
5
piPEs Current Measurement Points

• BWCTL / Iperf
• Throughput, Loss, Jitter
• NDT
• Detects common first mile conditions
• OWAMP
• Latency, Hop Count

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 v3.0.20 (1 week old)
• Hosted at Sourceforge
• Redirects to nearest NDT server
• Bug Fixes
• OWAMP v2.0? (next week)
• Upgrade to latest release of OWAMP specification
• Port Range support to make it filter friendly
• Report Hop Count information in addition to 1-way
  Latency
• Bug Fixes

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

9
Going Forward

• To date, weve 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

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

11
American / European Collaboration Achievements

• UCL E2E Monitoring Workshop 2003
• http//people.internet2.edu/eboyd/ucl_workshop.ht
  ml
• Internet2, DANTE, CANARIE biannual meetings
  (12/03, 07/04, 01/05)
• Transatlantic Performance Monitoring Workshop
  2004
• http//people.internet2.edu/eboyd/transatlantic_w
  orkshop.html
• Caltech lt-gt CERN Demo
• Haystack, USA lt-gt Onsala, Sweden

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

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
• eboyd_at_internet2.edu

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

15
System Architecture (Apr 04)
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

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

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

19
Base Services
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

21
Lookup Service (II)

• Lookup is not simply by name
• Type (type of measurement, type of service)
• Community
• Network path
• Organization
• Type of authentication required
• Other
• Response contains
• Contact information
• Available services
• Authentication required
• Other

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.

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.

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.

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

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.

27
Derived Functionality
28
Regular Measurements

• A configurable entity that makes requests at some
  pre-defined intervals to multiple test executors
  to instrument a network.

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.

30
NOC Alarm

• Subscribes to data matching some specific
  pattern.
• Performs some pre-defined action when the pattern
  matches.

31
Domain Proxy

• Allows for dumb clients.

32
Process Flow (Tool Beacon)

• Register with lookup service.
• Find possible controlling resource broker.
• Handle requests.
• Execute tests and possibly publish results.

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.

34
Architecture Refinement (Full Test)
35
Architecture Refinement (Initialization)
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

37
Architecture Refinement (Request Phase)
38
Architecture Refinement (Brokering Resources)
39
Summary

• Short-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

40
Invitation to participate

• Architecture being refined
• Drawings represent a work in progress
• Feedback, contributions welcome
• eboyd_at_internet2.edu
• Join at an individual level or an institutional
  level

41
(No Transcript)