Transatlantic Performance Monitoring Workshop 2004 Eric L. Boyd (& Nicolas Simar) 2 January 2019

Transatlantic Performance Monitoring Workshop 2004 March 17, 2004 CERN, Switzerland Hosted by: Internet2 E2Epi DANTE / GEANT2 EGEE Overview: E2E piPEs GEANT2 JRA1 Demo GGF NMWG Perf. Meas. Arch. WS Tools OWAMP BWCTL IPPM SCAMPI CNM Consumers Advisor MonALISA EGEE Group Discussion 1/2/2019

Internet2 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 Interoperable with other performance measurement frameworks 1/2/2019

Measurement Infrastructure Components For any given “partial path” segment (dotted black line) … We might run regularly scheduled tests and/or on-demand tests. This means, we require the ability to make a test request, have test results stored in a database, request those test resutls, and retrieve the test results. 1/2/2019

Sample piPEs Deployment Deployment is an inside-out approach. Start with regularly scheduled tests inside, make sure it plays well with regularly scheduled tests outside. Imagine the “cloud” is Abilene (but stress that it need not be), the regional node might be a GigaPoP, the end nodes might be a user’s laptop, a web server, etc. A cloud can also conceivably interconnect networks Nodes inside of Abilene An Abilene node to a regional node An Abilene node to a node in Europe The power here is that the framework developed is extensible and scaleable Regularly scheduled test data across the network backbone might go in to per-administrative-domain databases. We have one for all of Abilene (11 nodes). A campus or set of campuses (e.g. CENIC, various Ohio universities, various North Carolina universities) might set up their own measurement domain consisting of regional nodes, nodes at campus edges, and possibly internal network edges (e.g. edge of CS dept.). They might store regional test data in a database. Members of a distributed research community (e.g. astronomers of VLBI community) might have a small set of distributed servers across the globe they regularly test between … they might store data in an application domain test database. 1/2/2019

piPEs Deployment 1) Abilene Backbone Deployment (Complete) Hawaii 2) Hawaii Campus Deployment (Complete) OSU NC State Europe UCSD 3) In Progress Campus and European Deployment (Q1 2004) Abilene Backbone deployment in Green. Campus deployment in Solid Red. In progress roll-out to Campuses and European partners in Dotted Red. “Europe” in this case means a handful of nodes scattered across the GEANT backbone and some nodes at CERN. We are trying to work very closely with DANTE/GEANT and EGEE to ensure interoperability (at a minimum) if not a shared code base across the US and Europe. This is important as many scientists in the US routinely ship data across the Atlantic and thus their E2E concerns are international in nature. 1/2/2019

Abilene Measurement Domain Part of the Abilene Observatory: http://abilene.internet2.edu/observatory Regularly scheduled OWAMP (1-way latency) and BWCTL (Iperf wrapper) Tests Web pages displaying: Latest results http://abilene.internet2.edu/ami/bwctl_status.cgi/TCP/now “Weathermap” http://abilene.internet2.edu/ami/bwctl_status_map.cgi/TCP/now Worst 10 Performing Links http://abilene.internet2.edu/ami/bwctl_worst_case.cgi/TCP/now Data available via web service: http://abilene.internet2.edu/ami/webservices.html The E2E team is building the piPEs measurement framework. Internet2 has deployed an instance of that framework, the Abilene Measurement Domain (AMD). AMD is part of the Abilene Observatory. Currently, the AMD consists of regularly scheduled OWAMP and BWCTL tests, plus the ability of a user “on the edge” to test “to the middle” (a crude divide-and-conquer approach to diagnosis E2E problems). Network Monitoring is live (a prototype that will eventually be released) that allows simple analysis of network monitoring data across the backbone. In addition, we’ve made that data available via a web service (conforming to the schemata of the GGF NMWG). Other tools, such as NLANR’s Advisor and the HENP community’s MonALISA tool can now consume that data. 1/2/2019

GN2 JRA1 - Performance Monitoring and Management 3 year project, starting in September 2004 (15 European NRENs and DANTE involved). Development of a Performance Monitoring infrastructure operating across multiple domains User can access data from different domains in a uniform way and start on-demand tests. 1/2/2019

GN2 JRA1 Goals Make network management and performance information from different domains available to various authorised user communities GÉANT, NRENs, Regional networks NOCs PERT - Performance Enhancement Response Team high data volume transfer users (as GRID) end-user who would like to see or understand the E2E behaviour of R&D networks. 1/2/2019

GN2 JRA1 Goals Multi-domain focus, interoperable with other frameworks. Tailor data representation for a subset of users. Modify existing tools and integrate them within the infrastructure. 1/2/2019

GN2 Framework Layers 1/2/2019

GN2 JRA1 Measurement Points and Metrics Activity will focus in five areas: One-way delay, IPDV and traceroute Available Bandwidth (IP for sure, TCP/UDP less sure) Flow Based Traffic Measurement Passive Monitoring Network Equipment information Quite IP-centric. 1/2/2019

GN2 JRA1 Starting Point Starts from GN1 Performance Monitoring framework (data retrieval, storage and export using a well define interface) and take into account other experiences. Uses NRENs experience in tool development. Need to take into account the variety of tools and metric existing across the NRENs 1/2/2019

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: Onsala, Sweden  Haystack, Mass. HENP: CERN, Switzerland  Caltech, Calif. 1/2/2019

American/European Demonstration Goals Demonstrate ability to do partial path analysis between “Caltech” (Los Angeles Abilene router) and CERN. Demonstrate ability to do partial path analysis involving nodes in the GEANT network. Compare and contrast measurement of a “lightpath” versus a normal IP path. Demonstrate interoperability of piPEs and analysis tools such as Advisor and MonALISA 1/2/2019

Demonstration Details Path 1: Default route between LA and CERN is across Abilene to Chicago, then across Datatag circuit to CERN Path 2: Announced addresses so that route between LA and CERN traverses GEANT via London node Path 3: “Lightpath” (discussed earlier by Rick Summerhill) Each measurement “node” consists of a BWCTL box and an OWAMP box “next to” the router. 1/2/2019

All Roads Lead to Geneva 1/2/2019

Results BWCTL: http://abilene.internet2.edu/ami/bwctl_status_eu.cgi/BW/14123130651515289600_14124243902743445504 OWAMP: http://abilene.internet2.edu/ami/owamp_status_eu.cgi/14123130651515289600_14124243902743445504 MONALISA NLANR Advisor 1/2/2019

Insights (1) Even with shared source and a single team of developer-installers, inter-administrative domain coordination is difficult. Struggled with basics of multiple paths. IP addresses, host configuration, software (support source addresses, etc.) Struggled with cross-domain administrative coordination issues. AA (accounts), routes, port filters, MTUs, etc. Struggled with performance tuning measurement nodes. host tuning, asymmetric routing, MTUs We had log-in access … still struggled with IP addresses, accounts, port filters, host tuning, host configuration (using the proper paths), software. Port filters, MTUs. 1/2/2019

Insights (2) Connectivity takes a large amount of coordination and effort; performance takes even more of the same. Current measurement approaches have limited visibility into “lightpaths.” Having hosts participate in the measurement is one possible solution. 1/2/2019

Insights (3) Consider interaction with security; lack of end-to-end transparency is problematic. Security filters are set up based on expected traffic patterns Measurement nodes create new traffic Lightpaths bypass expected ingress points 1/2/2019

Status Update We can do partial path analysis, although making sense of the results is still a big issue. We can speak the same measurement language, although it’s still evolving. We are working together in growing numbers, but we need critical mass (become de facto standard). We need to be able to find each other. We need to be able to verify each other’s identity. 1/2/2019

Summary Presentations found here: You are welcome to join mailing list http://people.internet2.edu/~eboyd/program.html You are welcome to join mailing list Sub-groups beginning work on areas of common interest American / European collaboration proceeding full steam ahead 1/2/2019

1/2/2019