=====================================
Minutes from NPM Interfaces Meeting
EGEE JRA4 Face to Face (July 2005)
=====================================

Date:  12th July 2005
Venue: NeSC, Edinburgh

Present:
  DANTE: Loukik Kudarimoti (LK)
  DL:    Mark Leese (ML)
  UEDIN: Ahmed Abdelrahim (AA), Ratnadeep Abrol (RA),
         Alistair Phipps (AKP)

Apologies:
  DFN:   Robert Stoy (RS)


Glossary
========

DT    = Diagnostic Tool
f2f   = face 2 face
MP    = monitoring point
PS    = PerfSONAR (GN2:JRA1 tool)
TL    = Translation Layer (to GN2:JRA1)
TLS   = Transport Level Security
wrt   = with respect to
WS    = Web Service


Actions
=======

[ALL] For the future, try to workout how we could filter list of MPs
      based on domain in which MPs exist.

[RA]  Work out if DT could filter MPs

[AKP] Replace usage of "stream" in interface with "path"

[RA/AKP] Func spec should make it clear which interface methods
         through which faults.


Decisions
=========
* Leave dynamic discovery to EGEE-22.

* Leave hops in interface even though aggregation is not likely to be
  implemented.

* Use statistics instead of results to return results.

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

Array of hops
-------------

Submission takes an optional array of hops. This parameter will be
kept even if aggregation is not supported - if aggregation is not
supported supplying this parameter it is an error.

Response time interval
----------------------

Response time interval will always be smaller than the requested time
interval.  The time interval makes no guarantees on whether the
measurements are contiguous within that time period (i.e. there may be
gaps in the measurements).

Some discussion took place about how useful exact time information
would be (i.e. list to time periods for which contiguous data exists).

ML: Request for exact time information is not useful at the moment,
    because:
      * processing is equivalent to answer request for raw data for
        the same time period; and
      * working out time intervals need extra work which needs extra
        knowledge i.e. calculate whether measurement data is
        contiguous needs to know the granularity.e.g. granularity for
        scheduled measurements.
E.g.
   operation                 time taken
   ---------                 ----------
   Which metrics?             10 ms
   RTT yesterday             100 ms
   Total                     110 ms

   operation                 time taken
   ---------                 ----------
   which metrics + time      100 ms
   RTT yesterday             100 ms
   Total                     200 ms

ML: Monitoring points can keep basic information (characteristics and
statistics) as static hard coded info.

LK: But if you can give this info you are giving more useful info.

Consensus: Time information should be static, but it is up to
           frameworks if they return non-static data.

AKP: Can return time information and frequency of measurements - both
     optional. Both just when data was meant to be available
     (i.e. doesn't take into account times when framework goes down).

ML: Point of adding all these extra bits of info is to help user
    decide on the quality of the data they are getting. It is also
    possible for response to include number of pieces of data a
    statistic was calculated on. Therefore user can determine if
    statistic is worthwhile.

AA: Putting too much onus on user to determine the quality of returned
    data.
ML: Not possible for frameworks to return data and give quality
    indication. If automation of this is required it should be done in
    tooling given to user (e.g. DT).


MP Discovery
------------

ML: Interface isn't as had been considered before. It was assumed that
    one MP could talk to any other MP. The problem with the intended
    interface is that too much data could be returned, because there
    is no way to filter to reduce the number of MPs being returned.
    People thought that selecting an MP would be filtered on the
    domain within which the monitoring point existed. **BUT** no-one
    was sure as to how this would happen.

ML: In the future we need some way of determining how to limit MPs to
    those in a particular domain. Maybe NOCs should name MPs in such a
    way that allows this.

LK: PS lookup service does not have a means of limiting/filtering the
    number of MPs.

ML: Is anything written down about the lookup service?
LK: No. Are working on it. Have 5 developers (from 12 participants)
    working on GN2:JRA1 services. They are currently looking at the
    measurement archive service and creating a first implementation of
    the service).

Current interface works for DT. Could DT filter MPs for user?

Dynamic Discovery will be left to EGEE-2.

Faults
------

Some of the listed faults are not applicable at the client/mediator layer.


Time Interval
-------------

* where max results are specified, this limits the number of results
  around the focus time.
* for sampling - ask for all the data and then up to client to sample
  based on the results.


Statistics vs. Results
----------------------

Use statistics because results are not complete.


RA 15/07/2005