27-Jan-2005 Internet2 Activities Toward a Global Measurement Infrastructure Matt Zekauskas Network Performance Measurement and Monitoring APAN19

27-Jan 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:

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

27-Jan 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.”

27-Jan Self-Diagnosis Backbone 1 GigaPoP A Campus GigaPoP B Backbone 2 Wall Jack host

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

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

27-Jan Partial Path Diagnosis Backbone 1 GigaPoP A Campus GigaPoP B Backbone 2 Wall Jack P P

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

27-Jan 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  Experimental deployments in Europe, Japan, Korea, Brazil (and others) We encourage you to install, test, and add to the PMP directory

27-Jan Internet2 E2E piPEs  DANTE/GEANT  Daresbury  EGEE  GGF NMWG  ITECs  NLANR/DAST  UCL  Georgia Tech  And others The End-to-End (E2E) Performance Initiative Performance Environment System (piPEs) is a collaborative project combining the best work of many organizations including:

27-Jan 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 

27-Jan 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 owdp-14.txt

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

27-Jan Performance Measurement: Current piPEs Deployment

27-Jan Global PMP Directory  In the absence of a look-up service …  … how do you find other measurement beacons?

27-Jan piPEs Measurement Infrastructure  Version 0.1 alpha prototype released Limited testing Limited configuration support   Serves as the Abilene Measurement Infrastructure  Sample deployment in Europe  Allows the configuration of a mesh of regularly scheduled tests

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

27-Jan 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”

27-Jan 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)

27-Jan 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 1.Reporting measurements 2.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!  Next GGF is March in Seoul  Any interest from this group?

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

27-Jan American / European Collaboration 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

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

27-Jan More piPES Details  all04/ piPEs-Boyd.htm  all04/ piPEs-Boyd.ppt

27-Jan Big list of URLs             General info:  Technical info:

27-Jan