Subject: [ippm] version -01 of the minutes, SLC IETF 52

From: "Matthew J Zekauskas" <[email-masked]>
Date: Fri, 11 Jan 2002 20:06:51 -0500

This reflects some comments received (points 3 & discussion on 4 are
slightly changed).  The minutes are due at 5pm EST on Monday
the 14th; so if you have any other comments we need them by that time.

Slides still available at http://www.advanced.org/IPPM/Meetings/ietf52/

--Matt & Merike

-=-=-=-
Minutes of the IP Performance Metrics WG (ippm)
Wednesday, 12 December 2001, 13:00 - 14:00
===================================================

The meeting was chaired by the working group chairs, Matt Zekauskas
and Merike Kaeo.  Al Morton took notes, which were edited into these
minutes by the chairs.

AGENDA

1. Agenda bashing
2. Summarizing latest radical revision of npmps draft as per the I-D 
3. Practical experience with the IPDV draft    
4. One-way Active Measurements Protocol Requirements  
5. IPPM metric management needs
6. Discussion on charter/milestones/potential new work

IETF home page: http://www.ietf.org/html.charters/ippm-charter.html
IPPM home page: http://www.advanced.org/IPPM/

2. Summarizing latest radical revision of npmps draft
   -- Al Morton, AT&T

Al Morton presented an update on the latest revision of the npmps
draft.  A poll of the audience showed that only 5 people had read the
new draft.  Al mentioned that the first 3 pages are the most important
and would like to get agreement on the modifications made to get this
latest revision.  No comments were made. Al remarked that no negative
comments was very positive; a few audience members (that attended this
meeting and previous meetings) have been vocal, so this is a
significant step forward.

Matt said a last call will be issued on the mailing list for this document.

3. Practical experience with the IPDV draft    
   -- Henk Uijterwaal, RIPE NCC

Henk Uijterwaal presented practical experience with IPDV to answer the
question 'can we measure something useful with it?'  He showed
examples of measures of delay variation (peaks and distributions) on
different paths for 1 week periods.  Two of the examples showed
effects that cannot (easily) be seen in plots of the absolute delay
between hosts.  A longer write up is being prepared for PAM2002.  He
also looked at experimental errors and concluded that this was not
really an issue - it only comes up when restarting the time-keeping
processes.  Henk's conclusion is that the draft is useful and ready to
go.  No comments were made.

Matt stated that last call will go out on this document soon.

4. One-way Active Measurements Protocol Requirements  
    - Stanislav Shalunov

Stanislav Shalunov presented an update of the OWAMP requirements draft
stating that most changes were editorial.  The two main points were:
name change from OWDP to OWAMP and a new section to explain why
requirement for only 2 specific packet types (DSCP and PHB).  The one
major change was the 'accept' byte which had 2 responses.  The
intention is to later define error codes when there is more
implementation experience since it's not yet clear what the error
codes should be.  For now, the protocol specification is virtually
frozen since we are waiting for requirements document to proceed.

A discussion followed clarifying the name change -- the protocol draft
is still called owdp, One-way Delay Protocol, but that is due to having
initial draft name and how the IETF secretariat keeps track of
documents.  The intent is to modify the name to One-Way Active
Measurement Protocol to reflect the fact that other one-way metrics
may be measured with this protocol.

There was a question from the floor asking if the protocol precludes
anything but Poisson streams. The answer was that it supports Poisson but
intent is to extend it when other metrics are standardized in the
future.

An issue was raised of having measurement capability identification
in the control protocol. In particular, if you ask for a capability,
and the response is "not supported", it is important to know why.
For example, you don't want to have to probe to find capabilities,
especially if the capability was dependant on traffic or time of day.
There was a discussion about how difficult this would be if the
results were machine-readable.  A compromise was suggested: allow an
arbitrary text field that could explain the probe's capabilities to
someone trying to configure a system.

Another comment from the floor was made in reference to operating
systems and having different constraints on different devices.  The
reply was that constraints are the same -- the protocol needs to be
implemented in general purpose and other hardware.  The comment was
clarified to say that the requirements document appears to take
into account UNIX system specifics; either the document should be
extended to other OS and hardware specifics or the references
should be removed.

The last comment from the floor was advice to avoid having a huge
number of tests which start together, to avoid oscillation in network,
especially with respect to any future periodic streams.  The reply was
that this should be sufficiently handled by randomizing start times
(which is specified in the NPMPS draft).  Not destroying the network
is definitely a requirement.

5. IPPM metric management needs 
   -- Emile Stephan, France Telecom

Finally, Emile Stephan presented his view of the requirements for
management of IPPM measurements - in particular, a proposal to both
control and report measurements using a MIB.  

This section was prefaced by Matt explaining that the chairs had read
the draft and thought it was similar to work proposed in RMONMIB.  At
Monday's RMONMIB meeting, this work was discussed; the conclusion was
that the proposed IPPM MIB had little or no relationship to the work
on TPM-MIB (transport performance measurement) and SSPM-MIB (synthetic
source performance measurement) within RMONMIB because the RMON work
focused on understanding characteristics specifically tied to an
application, not general transport characteristics.  The
recommendation from RMONMIB was that if IPPM chose to work on this
MIB, it should split the control and data reporting portions, and work
with RMONMIB to create a common metrics registry - the TPM draft, in
particular, has some reference to IPPM documents so a common registry
would be useful.

Emile emphasized that a reason to specify the MIB is to permit
different devices to perform control and measurement and get metric
measurement results.  Essentially to have many separate domains, each
having potentially different access capabilities to the measurement
information.
 
In general, the MIB would allow for both the control and reporting of
IPPM measurements.  It has an emphasis on flexibility of measurement
types, and also to flexibly report - to allow a customer of your
network to have his own view of the measurements taken.  Matt asked
who thought this was a really bad idea - no hands.  He asked how many
had read the document - about 8 hands.  

There were two comments from the floor.  First, the MIB was a good
idea, and appropriate for results but security is a concern.  Second,
we now have 2 requirement documents and perhaps we should finish the
one-way protocol requirements document before we think about a MIB
that contains control information.

6. Discussion on charter/milestones/potential new work

Discussion on Emile's topic was cut off, and we did not get to further
discuss the charter since the meeting had to adjourn for MEGACO to
start.  The chairs asked that further discussion be taken to the
mailing list.

_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm