===========================
NPM Metrics (EGEE JRA4 F2F)
===========================

Date:  9th May 2005
Venue: DANTE, Cambridge

Actions
-------

[ML/RS] look at definition of available bandwidth to check if udpmon
        satisfies it.

[ML/RS] check with NOCs and GOCs to see if a 5 minute old traceroute
        would be current enough for NOCs and GOCs.

[ML] find out if it is feasable for the diagnostic tool to present
     network topology to the user. Will need to investigate sources of
     network topology. DANTE are in the process of building a number
     of different topology databases (see Anand and Loukik).

[RA] Ensure IPerf packet re-ordering is covered within WP6.1


General Discussion
------------------

UDP ping is used on the backbone, between routers.

UDP ping will not be available in GN2:JRA1 for the end of June. Layer
3 available bandwidth, capacity and utilisation will be available.

The aim is to add more tools to GN2:JRA1 at some point in time:
  IPPM based one way delay
  WCTL available bandwidth layer 4
  netflow statistics
  passive monitoring

round trip time and one way delay are both useful for endsite and
backbone measurements, but RTT is generally an end site measurement,
and OWD is generally a backbone measurement.

Connectivity at more than best efforts is a low priority.

There was a discussion on the relevance of historical traceroute - it
was generally thought that on-demand traceroute was more
important. Though it is possible that this could be simulated by
performing traceroutes every 5 minutes (so the oldest traceroute is
only 5 minutes old). This is something that should be asked of NOCs
and GOCs.

When capturing traceroute, it was pointed out that it only makes sense
to capture the traceroute output when the route has changed. This
places less overhead on the database storing the traceroutes.

The requirement for Network Load doesn't really make sense - it
doesn't map to a measurement. The closest would be capacity on the
backbone.

I appears that the network topology requirement will be difficult to
satisfy. Creating topology databases is usually manual process. For
JRA4 to have access to topology, information would need to be put
together from a number of different sources - such as boarder gateway
protocol and SA2 databases.

With respect to Application Protocols, this is a requirement that we
don't intend to satisfy in general. The closest we will come is to put
an NM-WG interface on top of the gridftp log information gathered by
James Casey's group.

It was pointed out that it does not make sense to deploy all
monitoring tools on every end site - some of the tools don't apply on
some sites. Kostas said we have to have all the tools deployed to
ensure that the mediator can take the software developed by JRA4 is
can survive the amount of data generated.

The LCG data challenges may be deploying RipeTTM boxes.

It was noted that packet re-ordering is a metric that currently is not
on our list, but should be. Also it should be easy to gather with
IPerf. This should be investigated and added to our list of metrics to
add (WP6.1).

RA 11/05/2005