[ippm] IPPM Minutes for IETF 60, version 0

Here is a complete cut at the minutes.  If anyone has a comment,
get it to me or the list before 3pm or so EDT on Friday (they are
due by 5pm EDT).

The presentations are all linked off of
http://people.internet2.edu/~matt/IPPM/Meetings/ietf60/

--Matt

-=-

IP Performance Metrics WG (ippm)
Monday, August 2, 2004 at 1300-1500
===================================
The meeting was moderated by the working group chairs, Henk Uijterwaal
and Matt Zekauskas.  Al Morton and Matt Zekauskas took notes,
which were edited into these minutes by the chairs.  Simon Leinen
scribed to Jabber.

AGENDA:

1. Administrivia, Milestone Status
2. One-Way Active Measurements Protocol
3. A Hardware Timestamper for One-way Delay Measurements
4. Reordering Density (RD) and Reorder Buffer-occupancy Density (RBD):
    Metrics for packet reordering
5. Packet Reordering Metric for IPPM
6. Implementation reports for RFC2678-2681:
     RIPE NCC Test Traffic Measurements (TTM)
7. Implementation report: Surveyor
8. IPPM Reporting MIB and Metrics Registry discussion

1. Administrivia, Milestone Status

We are looking for a volunteer to act as editor on link bandwidth draft,
there is some existing material to base it on.  [Note: after the
meeting, Phil Chimento volunteered to edit.]
Reviewing the rest of the milestones, OWAMP appears to be on track,
reordering schedule will depend on today's discussion.

2. One-Way Active Measurements Protocol
       http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-09.txt
     - Stanislav Shalunov

There were two wire protocol changes and a bunch of clarifications
since the last version (see slides).  Changes were made in response to
the approved requirements draft, two wire protocol changes (to expose
TTL, and a minor change in reporting lost packets, both in response to
implementation experience).  Stanislav reported that there were
pending changes to remove a feature that caused some ambiguity
(essentially "start in the past"), and a reordering of values in one
message to make it more likely that the timestamp falls on a nice word
boundary.  Stanislav mentioned that the protocol really needed a
thorough security review.

TTL is intended to count hops, was not specified before, now receiver must
report actual received value (sender uses 255).  Matt asked why 255?
Why not negotiated?  Stanislav said that it made sense to have it large
and equal.  Timmons Player asked what if an implementation cannot
set the value?  Stanislav said that then you get back what you
get back ("junk"); it should be possible to report if you know
what it is set to (so you can understand in context).

Al Morton asked a question on send scheduling for test packets.
He was wondering if there was a way to have a random start time,
then a periodic schedule after that.  It seems that the current
scheme would try to do random, periodic, and then back to random
again.  Stas believed it could be done with the current scheme;
Stas and Al will work on this afterwards.

3. A Hardware Timestamper for One-way Delay Measurements
   - Zhang Shu

Zhang Shu reported on a hardware implementation of OWAMP, in
particular, timestamping the packets in hardware, to get rid of
inaccuracies due to software overhead and timing within the
measurement node.  The limitations are that it supports
unauthenticated mode only, one measurement stream only, and on INPUT
the UDP checksum is zeroed (when the input timestamp is added).  They
showed the results of measurements in Japan using IPv4 and IPv6.  They
claim high precision (see slides).

Stanislav thought this was splendid.  He noted that they apparently
did not make use of OWAMP-CTL anywhere.  That is true.  So, they
should make it clear that they use the test versus the full OWAMP
protocol.

Matt asked about support of more than one port number or stream? not yet.
Matt also asked if before the UDP checksum was cleared, was it checked?
Right now, it is cleared.  Zhang felt that in the current internet there
isn't much chance for this to happen.

Emile Stephan asked how the test endpoints were set up without OWAMP-control.
Zhang responded that setup was performed manually.

4. Reordering Density (RD) and Reorder Buffer-occupancy Density (RBD):
     Metrics for packet reordering
       http://www.ietf.org/internet-drafts/draft-jayasumana-reorder-density-03.txt
     - Anura Jayasumana

Anura Jayasumana presented an update on his team's work on "reorder
density" (see slides).  He presented a new version of reorder density
that he says is orthogonal to loss and duplication, but it still
doesn't use the same base definitions as in the current IPPM
reordering draft.  He says that this provides a "reorder response"
similar to "impulse response" in engineering control theory, which has
a formal proof in a recent paper; they are looking to use this as a
base for a version of TCP that sets "dupthresh" automatically.  He also
said the results on individual segments are composable.  He may
be interested in submitting this as an additional work item, or move
it forward personally if the group is not interested.

Mark Allman asked what do the numbers output by these metrics say?
He didn't think the interpretation was obvious; how do you get insight
into how the network is working from the numbers?  Anura responded
that it gives insight into the nature of the reordering; they give
a distribution.

Al Morton thought the real value was the ability to measure segments and
combine.   This is a desirable quality in current IPPM reordering draft.
However,  intuitively he doesn't believe that these distributions are
independent of packet spacing.  Al would like to harmonize basic definition
of reordering (so same as what current draft is, and what others use).

Anura said that to understand the independence of spacing, look at
system theory.  You are not predicting the effect on any given packet,
but statistical nature.  With respect to the current ippm draft,
The current definitions only work with "early" or "late" packets,
don't combine the two.  You need this combination in order to get
the insight.

5. Packet Reordering Metric for IPPM
       http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-06.txt
     - Al Morton

Al Morton presented the current state of the IPPM reordering draft.
The fragmentation additions were complex enough to be confusing in
the mainline text, so the discussion has been moved to the appendix.
There were many clarification changes based on comments on the list
and at meetings.  Two groups have implemented the metric (and there
was some discussion on the list).

6. Implementation reports for RFC2678-2681:
     RIPE NCC Test Traffic Measurements (TTM)

Henk presented an template for producing an implementation report,
including what was asked for at the last IETF meeting and on the
mailing list.  The purpose of these presentations are to provide
complete examples, and encourage other implementers to contribute.

For 2679, all metrics were implemented except
Type-P-One-way-Delay-Inverse-Percentile.  For 2680, all were implemented.
2678 (connectivity) and 2681 (round trip delay) were not implemented
by this system.  Specific percentiles and averaging intervals used were
given.

7. Implementation report: Surveyor

Matt Zekauskas made a similar report for Surveyor.  For 2679, all were
implemented except the inverse percentile metric (although histograms
of delays were computed).  Matt gave more details on the "Type-P"
used, as well as transmission rates.  He also gave percentiles and
averaging intervals used.  As with the RIPE system Surveyor implemented
all of the 2680 metrics, and non of 2678 or 2681.

8. IPPM Reporting MIB and Metrics Registry discussion
      http://www.ietf.org/internet-drafts/draft-ietf-ippm-reporting-mib-06.txt
      http://www.ietf.org/internet-drafts/draft-ietf-ippm-metrics-registry-07.txt
    - Emile Stephan

Emile noted that there was a move to stop work on the MIB as a working
group item.  He also noted that in other groups he observed that there
wasn't much discussion on the respective groups.  He then noted what
made the IPPM MIB different from some others, and presented a list of
questions the group.  He also briefly updated the latest changes.

Matt presented the chairs position that there appears to be no
consensus to continue with the current document, and that the
plan will be to once again query the mailing list looking for
interest in either this MIB, or the simpler MIB; if none then
we would drop this item from the charter (and Emile would be free
to request publication as an Informational RFC).

Andy Bierman noted that perhaps because the group was interested in
measurement, not management (defining metrics, not MIBs) there was
little interest in the MIB.  Andy said that it is a very complicated
MIB, and it needs better use cases.  The packet generation is not
typical.  The idea of fast report is not typical.  There is some
overlap with TPM MIB, for some of the metrics.  Also, once you get
into views, filtering, aggregation, something like TPM already does
it.  He's of the opinion that we should not proceed with the MIB.

Phil Chimento asked if it made sense to have a general MIB at all,
or is it better to have reporting in the context of an application?
Andy agreed to the need to provide results in the context of an application.

There was some short discussion of the pros and cons of a simple
ring-buffer based MIB, and whether the update rates would just
overwhelm a simple implementation.  Was there a use case for a
simple MIB?

Finally, Matt presented the remaining open issue with the MIB
registry, whether to include branches for enterprises and "other
standards bodies".  Andy was of the opinion that a centralized place
to look for the values is enough.

_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm