Goals for this meeting: - Big Picture everyone --> glossary |-> requirements `-> define the squares -> To create a document as a basis for discussion at the next face-to-face. - Contains the big picture, functionality <- top down approach (retrieve data from software; discovery brainstorm) - Existing software <- bottom-up - Scope - Merge documents (there are three, Yee & Loukik, Paul & Nicolas, Paul & Yee - Pragmatic view/implementation => we want to be able to demonstrate - Schema, but this may be a subsection of the top-down approach - Middleware needs only end-to-end measurments My points: Do we need to clear up the scope of the interest of the projects? - middleware view - discovery mechanisms For December: - Retrieve data through interface - Distributed places - What are the things we need for then?! * Glue * More * Less M9: Design M12: Interface implementation Timeline: Oct | Nov | Dec | Jan | Feb | Mar | - - - YEAR 2 - - - > -- design --->: : :test -- proto1 --->: :-- proto2 --->: : : : : :----------- - - --> : : : : Applications --> visualisation : : : : |-> to middleware : : : : |-> MP : : : : `-> intelligence (cost function) Proto1 is just something to start on, and use the mistakes in that to finess the design. The prototype can then be rebuilt or replaced for prototype 2, which should be tested at the end of March 2005. Top of the stack: Clients for the network data: -------------------- Middleware (JRA1) -> There will be some network-specific parts. Do we need to provide that, or will JRA1? -> Depending upon that, it will change the way data gets from the glue to them Grid Operation Centres (SA1) -> End-to-end, with history and visualisations Per-Domain or -Autonomous System troubleshooting Later, might need active tests, to isolate the problem. Do they need to set up alarms? If so, how, how often, etc? (For inter-domain tests and tests between end-hosts and backbone hosts, both ends must talk the same language.) Users visualisation Bottom of the stack: The measurement points -------------------- Why is there a distinction between backbone and end-sites -> the backbones are likely to have monitoring stuff, because their business is networks. They might then provide an interface for EGEE. -> the end-sites don't. We may have to provide them with an infrastructure Why did NMWG get chosen? -> because... For a network that does not implement either Perfmonit or piPES, what do we do? Perhaps we provide some classes or service that they can implement a small backend for. And finally: active test interfaces between sites and backbones, backbones and backbones, and sites and sites. This requires some discussion. Plans for tools for Perfmonit: 1) one-way delay (with all sorts of settings), two-way delay, traceroute. 2) throughput. Probably for BWCTL, which is a wrapper around Iperf. There will be a decision at M4 of GN2. Need some interaction beforehand. Communication between end-sites and the Glue: NM-WG, or R-GMA if the glue has R-GMA. We could provide a complete system for the end sites. Measurements points, database and interface Finally: Glue -------------------- It must talk NM-WG to get data from the backbones. What functions *might* the glue have? -> storage, for speed. |- Users: This may be advantageous for the visualisation. `- Middleware: will require shed-loads of data (1000 request/s). Do we put summary/caching near the middleware (i.e. for JRA1), or in the Glue. -> discovery (for getting measurements, and for making new ones?) -> what do we do about access to networks when they are not robust? Security is very important: There needs to be some discussion between GN2 and EGEE to see what is required, and what will be provided. ==================== Second half ==================== TODO: For the face-to-face: Possible summary of the requirements for the Requirements Collection milestone. TODO: talk to JRA1? Afternoon discussion: Bottom up examination ==================== Brainstorm of existing toools: Types of tool: -> software tools -> communication between the network infrastructures and JRA4 -> visualisation -> framework/infrastructure* (eg piPEs, Perfmonit, WP7) -> storage * There's a Dante document describing these terms: framework is the software, infrastructure is the software plus the deployed boxes -------------------|-------------------|-------------------|-------------------|-------------------|-------------------| Framework | Software tools | Communication | Visualisation | Storage | Available metrics | -------------------|-------------------|-------------------|-------------------|-------------------|-------------------| piPEs | OWAMP/BWCTL/NDT | NM-WG | History tables | Centralised | OWD, AvailableTCP,| | | | | propietary DB | Link util'n | -------------------|-------------------|-------------------|-------------------|-------------------|-------------------| Perfmonit | Ripe TTM, AB | NM-WG | - | Per domain DB | OWD | -------------------|-------------------|-------------------|-------------------|-------------------|-------------------| WP7 | Ping, Iperf, | R-GMA | MapCenter, | Central MySQL | All | | UDPMon, GridFTP | | history, matrices | | | -------------------|-------------------|-------------------|-------------------|-------------------|-------------------| GN2 | OWD, RTT, netflow | NM-WG (+internal) | ? | ? -> define | not yet | | TCP throughput, | | | schemas | | | passive, net | | | | | | equipment | | | | | -------------------|-------------------|-------------------|-------------------|-------------------|-------------------| GridMon | As WP7 | - | As WP7...ish | Local | | -------------------|-------------------|-------------------|-------------------|-------------------|-------------------| | | NM-WG, more... | MonaLisa | | | -------------------|-------------------|-------------------|-------------------|-------------------|-------------------| | | | Stagger Nordunet | MySQL interdomain | | -------------------|-------------------|-------------------|-------------------|-------------------|-------------------| So much of this is not very useful for us to think about here: the frameworks will just be something we recommend that people deploy. The interesting bits for us are the communication methods, and the software tools we can recommend get deployed. Steps for the demo: 1) Interface to get data from NM-WG or R-GMA, using static lookup Then (in no particular order) 2) Dynamic lookup... though perhaps this should be done much later 3) Database on top + visualisation 4) Traceroute, concatenation Actions: Prepare the draft of the big picture document For the face to face meeting: