1 / 26

Internet2 Activities Toward a Global Measurement Infrastructure

Internet2 Activities Toward a Global Measurement Infrastructure. Matt Zekauskas <matt@internet2.edu> Network Performance Measurement and Monitoring APAN19. Why global interoperable measurement?. Peering quality control (continuing tests) Infrastructure to debug problems (on-demand tests)

jerica
Download Presentation

Internet2 Activities Toward a Global Measurement Infrastructure

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Internet2 Activities Toward aGlobal Measurement Infrastructure Matt Zekauskas <matt@internet2.edu> Network Performance Measurement and MonitoringAPAN19

  2. Why global interoperable measurement? • Peering quality control (continuing tests) • Infrastructure to debug problems (on-demand tests) • Base to allow users to locate the source of problems themselves (Vision: via automated tools) • In general prevent the following for a scientific experiment that crosses continents:

  3. No other complaints Everything is AOK Talk to the other guys System Administrator LAN Administrator LAN Administrator System Administrator Campus Networking Campus Networking Backbone Gigapop Gigapop The Problem Hey, this is not working right! Others are getting in ok Not our problem Applications Developer Applications Developer The computer Is working OK Looks fine All the lights are green How do you solve a problem along a path? We don’t see anything wrong The network is lightly loaded

  4. Self-Diagnosis • Find a measurement server “near me”. • Detect common tests in “first mile”. • Don’t need to be a network engineer. • Instead of: • “The network is broken.” • Hoped for result: • “I don’t know what I’m talking about, but I think I have a duplex mismatch problem.”

  5. Campus Backbone 1 Backbone 2 Campus GigaPoP A GigaPoP B Self-Diagnosis Wall Jack host host Wall Jack

  6. Partial Path Diagnosis (1) • Identify end-to-end path. • Discover measurement nodes “near / representative of” hops along the route. • Authenticate to multiple measurement domains (local-defined policies). • Initiate tests between remote hosts. • See test data for already run tests.

  7. Partial Path Diagnosis (2) • Instead of: • “Can you give me an account on your machine?” • “Can you set up and leave up and Iperf server?” • “Can you get up at 2 AM to start up Iperf?” • “Can you make up a policy on the fly for just me?” • Hoped for result: • Regular means of authentication • Measurement peering agreements • No chance of polluted test results • Regular and consistent policy for access and limits

  8. Campus Backbone 1 Backbone 2 Campus GigaPoP A GigaPoP B Partial Path Diagnosis Wall Jack P P Wall Jack

  9. Example: e-VLBI • David Lapsley, formerly of MIT Haystack Observatory • Started regular tests among e-VLBI sites in the US, Japan, and Sweden • Monitor paths, watch for changes • Ensure meet minimum requirements • Prior to big test last July, was only getting 1Mbps over a path from Onsala to Haystack, needed O(50) Mbps • Used bwctl servers in the US and Europe to locate problematic path segment • Link near Haystack upgraded; successful test

  10. Internet2 Activities • Initially identified problem, surveyed existing solutions, and developed it’s own tools (owamp, bwctl) to satisfy requirements • Developed with community input, open source • Only a first step • These tools, along with NDT, are deployed on Abilene nodes • You can test to them, see “procedures for peering” sections in http://e2epi.internet2.edu/pipes/ami/pmp-info.html • Experimental deployments in Europe, Japan, Korea, Brazil (and others) • We encourage you to install, test, and add to the PMP directory

  11. BWCTL • What is it? A resource allocation and scheduling daemon for arbitration of iperf tests • Typical Solution • Run “iperf” or similar tool on two endpoints and hosts on intermediate paths • Typical road blocks • Need permissions on all systems involved • Need to coordinate testing with others • Need to run software on both sides with specified test parameters • http://e2epi.internet2.edu/bwctl/

  12. OWAMP • What is it? • Measures one-way latency • Control connection used to broker test request based upon policy restrictions and available resources. (Bandwidth/disk limits) • Specification • http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-14.txt • http://e2epi.internet2.edu/owamp/

  13. NDT • “Single shot” diagnostic tool that doesn’t use historical data • Measures performance to users desktop • Combines numerous Web100 variables to analyze connection • Develops network signatures for ‘typical’ network problems • End-user based view of network • Doesn’t require user to load any new software • Can identify performance bottlenecks (could be host problem) • Provides some ‘hard evidence’ to users and network administrators to reduce finger pointing • http://e2epi.internet2.edu/ndt/

  14. Performance Measurement: Current piPEs Deployment

  15. Global PMP Directory • In the absence of a look-up service … • … how do you find other measurement beacons? • http://e2epi.internet2.edu/pipes/pmp/pmp-dir.html

  16. piPEs Measurement Infrastructure • Version 0.1 alpha prototype released • Limited testing • Limited configuration support • http://e2epi.internet2.edu/pipes • Serves as the Abilene Measurement Infrastructure • Sample deployment in Europe • Allows the configuration of a mesh of regularly scheduled tests

  17. piPEs Measurement Infrastructure Features • Regularly scheduled and on-demand tests co-exist • Regularly scheduled tests are implemented as regularly requested on-demand tests • Distributed control enables inter-domain testing

  18. Creating a Federation of Measurement Frameworks • Why a Federation? • Multiple measurement frameworks currently exist or are under development (piPES, NLANR Advisor, NLANR AMP, GEANT2 JRA1, etc.) • Open cooperation and the development of standards will promote the development of best practice measurement frameworks and interoperability, with local control. • Future measurement frameworks can be built on the shoulders of current efforts. • We need to be able to use measurements of each others’ networks to solve research application performance problems that cross multiple networks • ~”The value of a performance measurement framework scales with the square of the deployment footprint”

  19. Federation Achievements • Broad Achievements to Date • We can speak the same (albeit evolving) measurement language (based on GGF NMWG schemas) • Numbers are growing though we are not yet at critical mass. • Important Next Steps • We can find each other • We can verify each other’s identity (and apply restrictions based on role or identity)

  20. GGF NMWG: Anyone going to Seoul? • Precondition to using measurements is understanding the data • GGF Network Measurement Working Group is working on standard schemas for • Reporting measurements • Asking for measurements to be taken • At this point, feel (1) pretty close to completion, but would welcome more scrutiny from interested people in the APAN region. Please review! • http://www-didc.lbl.gov/NMWG/ • Next GGF is March 13-16 in Seoul • Any interest from this group?

  21. American / European Collaboration Goals • Awareness of ongoing Measurement Framework Efforts / Sharing of Ideas (Good / Not Sufficient) • Interoperable Measurement Frameworks (Minimum) • Common means of data extraction • Partial path analysis possible along transatlantic paths • Open Source Shared Development (Possibility, In Whole or In Part) • End-to-end partial path analysis for transatlantic research communities • VLBI: Haystack, Mass.  Onsala, Sweden • HENP: Caltech, Calif. CERN, Switzerland

  22. American / EuropeanCollaboration Status • Working on a joint architecture with GEANT2 JRA1 (see Nicolas Simar’s talk) • At a very high level: • Based on “services architecture” • Services: lookup, authentication, measurement point, archive, resource protection (authorization), aggregation • Goal of developing implementation in open source model • Modular: use what you can, replace what you don’t like, (contributing changes back), add functions • If you are interested in participating in the architecture discussions, see me, Nicolas, or Eric Boyd <eboyd@internet2.edu>

  23. Measurement Peering Agreements • Is it time to augment network peering agreements with “measurement peering agreements”? • Make explicit • Points of contact • Points that you are allowed to use • Limitations or conditions of use • Regular periodic test meshes • Extend to agreements with application communities (e-VLBI, HENP, …) • We think it is time to develop this idea

  24. More piPES Details • http://www.internet2.edu/presentations/fall04/20040930-piPEs-Boyd.htm • http://www.internet2.edu/presentations/fall04/20040930-piPEs-Boyd.ppt

  25. Big list of URLs • http://abilene.internet2.edu/observatory/ • http://abilene.internet2.edu/ami/webservices.html • http://e2epi.internet2.edu/pipes/pmp/pmp-dir.html • http://e2epi.internet2.edu/pipes/ • http://e2epi.internet2.edu/bwctl/ • https://mail.internet2.edu/wws/info/bwctl-announce • http://e2epi.internet2.edu/owamp/ • https://mail.internet2.edu/wws/info/owamp-announce • http://e2epi.internet2.edu/ndt/ • https://mail.internet2.edu/wws/info/bwctl-announce • http://people.internet2.edu/~eboyd/transatlantic_workshop.html • General info: pipes-interest@internet2.edu • Technical info: pipes-users@internet2.edu

More Related