=====================================================
Diagnostic Tool Brainstorming Session (EGEE JRA4 F2F)
=====================================================

Date:  9th May 2005
Venue: DANTE, Cambridge

Glossary
========

MP = Monitoring Point


Actions
=======

[LK] Investigate whether Mark can have access to the GN2:JRA1
     questionaire responses.

[ML/RA/AKP] Have a discussion on how results are distributed around
            the target time in the timeperiod specified by the NMWG
            specification (need clarification, especially about what
            happens with asymetric -ve and +ve time tolerences).


General Discussion
==================

Mark would like to have access to questionaire responses to the
GN2:JRA1 document that investigated NOC/GOC's metric
requirements. There was a very high response rate to this
questionaire. Loukik will look into this.


Existing Tools
==============

Ratna showed examples of two currently available analysis UIs to
performance data:
  * NLANR Performance Advisor
  * Traceanal

ML said that Advisor was not really suitable for users, and could be
thought of as being a front end to the Mediator.

Generally Traceanal was thought to be good because of its use of
graphs.


Query
=====

max results is useful to limit the size of the results a user gets
back. Such limits make sense when the user submits a query that would
return a lot of data.

When submitting a query, a user should choose the format in which the
output from their results should be displayed to them.

Robert showed a web page (from RipeTTM) that displayed a matrix of TCP
(?) throughput between RipeTTM boxes. This matrix displays a last and
current measurement value. This web page allows a user to drill down
into one of the elements of the matrix to get more information. The
drill down information showed graphs for the throughput over a set of
time periods.

Robert said that such overview matricies were very useful. To be able
to build such matricies user must able to specify more than one request
at a time.

For source and destination, a user should be able to select from a
drop down list of MP names and IPs. This is valid because a NOC/GOC
user will know the MP or will be able to work it out from the name of
the MP and the source or destiniation they are investigating.

The choice of characteristics the user can query for should be limited
to those available from the source destination pair chosen by the
user.

The client should be able to get available MP names and available
characteristics from the Mediator.

The statistics that would be useful to users are:
  min/max,
  stddev/mean/median,
  percentile (parameterised by percentile group).

Users should enter time periods as one of:
  start and end dates; or
  fixed period from a specific date/time (e.g. 24hrs, 7 days, 14 days,
  1 month).

There was a discussion about the distribution of results about a time
period when the maximum number of results is specified. (Reminder:
time periods are specified in NMWG as: target time with +ve and -ve
time tolerence). No real conclusion was arrived at. Mark said that
data should be grouped around the target time, but was not sure what
happens when -ve and +ve tolerences are asymeteric.

Submission
==========

There should be a cancel. It was noted that this would not actually
cancel the request on the server (there is no way to do this), it
would just free up the client.


Displaying Results
==================

Graphs should be provided for display. Type of graph depends on
measurement. Line graphs used for throughput and histograms for delay
data.


Analysis
========

Following analysis items were mooted:

  * metrics from different src/dests on same plot;
  * correlation plots (e.g. RTT against TCP);
  * network closeness
  * thresholds - to display data outside thresholds
  * alarms

RA 11/05/2005