1. Eric L. Boyd – Internet2 Nicolas Simar – Dante
Performance Measurement and Monitoring Internet2 Fall Member Meeting Philadelphia, PA
Eric L. Boyd – Internet2
Nicolas Simar – Dante

2. Agenda Internet2/G2 JRA1/ESnet Interaction Update
Internet2 Performance Activities
GÉANT2-JRA1 Performance Activities
Next Steps / Open Issues

3. perfSONAR: Overview
Joint effort of ESnet, GÉANT2 JRA1 and Internet2 PAT
Webservices network performance framework
Network measurement tools
Network measurement archives
Distributed scheduling/authorization
Multi-domain policy

4. perfSONAR: Accomplishments
Architecture document (Fall ’04)
Framework Design document (Spring ’05)
Prototype (Summer – Fall ’05)
Workshops in Brussels (09/04), Zurich (04/05), Ann Arbor (05/05) and Poznan (08/05)
Development Environment (05/05)
Communications:
Paper submissions (e2emon, TNC05 and ICSOC05)
TNC05 presentation

5. perfSONAR: Current Work
Current work is focused on developing a prototype that will allow interface utilization data to be shared.
Relatively simple use case, but demonstrates the feasibility of sharing data across multiple administrative domains.

6. perfSONAR: Services (1)
Measurement Point Service (MP)
Measurement Archive Service (MA)
Look-up Service (LS)
Authentication Service (AS)
Transformation Service (TS)
Topology Service (ToS)
Resource Protector Service (RP)
The services are stackable

7. perfSONAR: Services (2)
Lookup Service
Allows the client to discover the existing services and other LS services.
Dynamic: Services registration themselves to the LS and mention their capabilities, they can also leave or be removed if a service gets down.
Authentication Service
Internet2 MAT, GN2-JRA5
Authentication functionality for the framework
Users can have several role, the authorisation is done based on the user role.
Trust relationship between networks
The services register themselves to the LS and indicate their capabilities. They can also leave or be removed from a LS if a service gets down (keepalives).

8. perfSONAR Services (3) Transformation Service Topology Service
Transform the data (aggregation, concatenation, correlation, translation, etc).
Topology Service
Make the network topology information available to the framework.
Find the closest MP, provide topology information for visualisation tools
Resource protector
Arbitrate the consumption of limited resources.

9. Useful graph
Useful graph
Client
Token MA
Here is who I am, I’d like to access MA B
Here is who I am, I’d like to access MA A
a,b,c : Network A, MA A, AS A
Token MB
Where Link utilisation along - Path a,b,c?
Get link utilisation a, b, c
AS A
Here you go
Get Link utilisation a,b,c
Get link utilisation c,d,e,f
AS B
Here you go.
Here you go
a,b,c: Network A – LS A,
c,d,e,f : Network B, MA B, AS B
Where Link utilisation along - Path a,b,c,d,e,f?
LS A
LS B
MA B
MA A a b f e c d
Network A
Network B

10. Agenda Internet2/G2 JRA1/ESnet Interaction Update
Internet2 Performance Activities
GÉANT2-JRA1 Performance Activities
Next Steps / Open Issues

11. Current Projects Performance Tools Performance Measurement Framework
BWCTL
NDT
OWAMP
Thrulay
Performance Measurement Framework
piPEs -> perfSONAR
GGF NMWG
Member Outreach
Network Performance Measurement Workshops
Performance Tool Cookbooks
Bulk Transport
Design Space
Prototype

12. OWAMP (1-way ping)
LOTS of new deployments (Network Performance Workshop Attendees)
New “developers” release to support latest version (14) of owdp spec
TTL (hop count)
Early terminated sessions handled more gracefully
Sender will skip sending “late” records and shares that information with receiver

13. BWCTL (Bandwidth Test Controller)
LOTS of new deployments (Network Performance Workshop Attendees)
New alpha release
Bug fixes
Ported to Solaris, OS X
NTP dependency eliminated

14. NDT and Thrulay NDT Thrulay Duplex Mismatch Detection
Grant from NIH / NLM
Thrulay
UDP Mode
Google Summer of Code enhancements

15. GGF NMWG Version 1 of the schema “all but done”
Employed by piPEs, Advisor, AMP, MonALISA, and SLAC
Version 2 of the schema continues to evolve
perfSONAR work benefits from and informs this project

16. Network Performance Measurement Workshops (1)
Goals
Installed base of BWCTL/Iperf, OWAMP, and NDT at GigaPoP and regional campuses.
Begin integration into IT support processes.
Create and installed base for perfSONAR deployment.
Give each participant tool-specific cookbooks.

17. Network Performance Measurement Workshops (2)
Completed
SOX / GaTech (03/05)
CENIC / UCLA (06/05)
JT – Vancouver (07/05)
MAGPI / FMM (09/05)
Planned
OARNet / OSU (09/05)
APAN (01/06)
Under Consideration
MERIT, MAX, Winter Joint Techs, …

18. Other Outreach Next Generation Measurement Panel/BoF (07/05)
Bridging the Gap Workshop (08/05)
Application-Community-Specific Network Performance Workshops (mini-version of the workshop, focusing on use of tools, not installation) being developed

19. Bulk Transport Tool (1)
Killer App for High Performance Networks (i.e. why else do we need fat pipes)
Remedies for TCP’s maladies
Tuning: buffers, window scaling, timestamps, SACK
Use multiple streams
Something Else
Replace the kernel and use different congestion control
Replace all the routers and kernels

20. Bulk Transport Tool (2)
Many alternative TCP/IP congestion control algorithms
Modified kernels are incompatible with regular kernel security patches
Get the benefits of kernel-level modifications to TCP/IP congestion control algorithms in a user level tool, avoiding security issue with alternate kernels

21. Bulk Transport Tool (3) Design Space Document Early Stage Prototype
Google Summer of Code efforts

22. Agenda Internet2/G2 JRA1/ESnet Interaction Update
Internet2 Performance Activities
GÉANT2-JRA1 Performance Activities
Next Steps / Open Issues

23. GÉANT2 JRA1
15 European NRENs putting resources together to work on multi-domain monitoring and on performance measurements.
Arnes (SI), Belnet (BE), Carnet (HR), Cesnet (CZ), DFN (DE), FCCN (PT), GARR (IT), GRnet (GR), ISTF (BG), Uninett (NO), PSNC (PL), redIRIS (ES), Renater (FR), Surfnet (NL), SWITCH (CH), DANTE.
Works with
The Performance Enhancement Response Team.
The multi-domain L2 circuits activity
to provide them multi-domain measurement data.

24. Requirements
Questionnaires sent to NRENs, Projects and End-users (system administrators).
45 answers received (15 each).
Requirements
Strong interests to access monitoring information form multiple networks.
Readiness to open access to measurement data varies greatly.
On-demand capability (to and from other domains).
Be able to monitor the services deployed.
IP QoS, IPv4/v6, multicast
Great variety of tools deployed.

25. Requirements [2] Requirements Monitoring Information: RTT and OWD.
Bandwidth Utilisation and achievable TCP throughput.
RTT and OWD packet loss.
Delay variation.
Interfaces error and drops.
Routing/path information.

26. Tools
Work on the integration of few selected measurement tools into the framework.
Evaluate the different tools before selecting one.
DFN IPPM (OWD), BWCTL/iperf, RRD – December 05.
Enhancement of those measurement tools.
Investigate netflow and packet capture uses.
Make use of existing visualisation tools
NEMO (Uninett), CNM (DFN).
Will build (new) visualisation tools based on users feedback.

27. Other tasks Work on data aggregation and concatenation.
Deployment of a test infrastructure.
Multi-domain L2 circuit monitoring (SDH and Ethernet based circuits).

28. Agenda Internet2/G2 JRA1/ESnet Interaction Update
Internet2 Performance Activities
GÉANT2-JRA1 Performance Activities
Next Steps / Open Issues

29. perfSONAR: Prototype Phase 0 Phase 1 Phase 2 Phase 3 (Dec 05)
Simplistic client which requests data to a MA (RRD filesystem) using web-services (Done)
Phase 1
Include simplistic LS web-services (on-going)
Visualisation – map based (on-going)
Phase 2
Request additional data (OWD, packet drops)
Dynamic registration to LS
Ping MP
Phase 3 (Dec 05)
Handel attributes for other services
Distributed LS data across several domains
MP get’s on-demand capability (BWCTL)
Make use of the attributes to offer different functionalities to the users
Prototype – Phase 0
For phase 0 of the prototype we will have the most simplistic client possible. It will have a fixed request for data that the MA will respond to.
Likewise, the MA will be as simple as possible as well. Much of the work to implement this first service will be usable by the other services we create.
- Implement a basic Measurement Archive Service around existing RRD filesystem. Implement a basic client which can retrieve data for a fixed request.
- Setup a Web Service for the Measurement Archive Service
- Measurement Archive Service design should yield an abstract design of the service which can be used for other services
- Create a simple Web Service client which has a fixed request in xml and saves response in xml
Prototype – Phase 1
RRD files will have a MA interface wrapped around them and the client will directly ask for data from the RRD MA. LS and AA will be as trivial as possible - There will only be one AA server and it can have a simple passwd file implementation. (could even skip AA initially to jump-start.) LS will be found using DNS - there will be only one, and no authentication will be required to access any of the data. Data should be fetched using DataHandles.
- Client - will contact LS/AA in addition to MA
- AA - will accept requests for authentication and issue tokens. (Only authN/ no authZ)
- LS - Flat file, no registration yet - just lookups. Information populated manually
- MA - Check Auth information
Prototype – Phase 2
From a user's point of view, the new thing here is that we can request additional SNMP variables that are not currently being collected through this interface and make it available through the MA-RRD archive. The visualization/analysis front end will need to be extended to graph/analyze additional variables. Perhaps even add the ability to query the MP to find out what types of variables can be requested. (But, I don't think we have discussed a message type for that...)
- AA - Extend to manage "real" identities including the ability to store attributes about those identities. User A is a network engineer etc.
- LS - Extend to have services dynamically register and deregister information instead of hard-coding it.
- MP - Accept tests for some "OTHER" metrics that the MRTG/Cricket tool is not currently doing and use the MP TO configure a new metric data feed to be sent to whatever "subscriber" interface passed in. (Initially this will be a "special" subscriber handle indicating that the MRTG tool should just use its own back-door data propagation.)
Prototype – Phase 3
From a user's point of view the main addition here is authZ. Also, the client will be passing in "real" subscription handles for the Data propagation from the MP. This means the client can get a direct feed of the data, or it can request a subscription handle from the MA before contacting the MP. Once this interaction is working, it should be possible to create other types of MA's (SQL based instead of RRD based). This phase will be key to determining how dynamic and resilient the framework can be. Once this step is complete, it should be possible to start adding additional services without too much difficulty, and we should be able to make future development from here on more parallel.
- AA - Manage identities as before, but now handle attribute requests from RP services so they can perform the authZ function.
- LS - Start looking at how to distribute the LS data across multiple LS servers. The hard part here will be for "protected" data. Protected data should probably not be distributed, but a reference to the "home" location(s) of the protected portion could be included.
- MP - Start taking full subscription handles as part of a measurement request, and send data directly there instead of into the RRD files of the MRTG tool. (Could go back to the client or perhaps to a MA.)
- MA - Start accepting archive requests and returning subscription handles. This could be passed onto a MP so data from a measurement request could be passed directly into a MA subscriber. (Or a client subscriber.)
- RP - Start looking at requests and basing acceptance of resource consumption based not only upon the "class" the requester is in but on their individual attributes by making attribute requests back to the AA server.

30. What’s Next? Current Status:
Regular discussions
Development is underway
About to use perfSONAR to provide data to an international project (link capacity and link utilisation).
We are at a key moment of the collaboration:
Distributed development process emerging
Making compromises between the vision and the technology
Where should we cut corners on the prototype?
Does the prototype form the basis of the deployed system?

31. Questions? Eric Boyd, Internet2 (eboyd@internet2.edu)
Nicolas Simar, DANTE / GÉANT2 – JRA1