Subject: [ippm] Minutes for the IPPM session at IETF-53, Minneapolis

From: "Matthew J Zekauskas" <[email-masked]>
Date: Mon, 15 Apr 2002 09:57:52 -0400

IP Performance Metrics WG (ippm)
Monday, March 18 at 13:00 - 15:00
====================================

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

AGENDA:
1. Agenda bashing
2. Charter Update
3. IPPM MIB discussion
4. Discussion on packet reordering
5. Statistics of One-way Delay
6. IPMP
7. Any remaining outstanding issues

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

3. IPPM MIB discussion 
   -- Emile Stephan

   http://www.ietf.org/internet-drafts/draft-stephan-ippm-mib-02.txt

Emile Stephan presented his work on a "IPPM MIB".  The
presentation was based upon his current personal submission, which
will be split into three parts, two of which will become working
group documents.  The first will be a metrics definition document
that can be shared with RMONMIB MIB objects that wish to use IPPM
data.  The second will be a "reporting MIB" to present measurement
results.  This split is as we discussed in Salt Lake City.
Andy Bierman will be sending detailed comments to the mailing list
to help align the current ideas with the SNMP framework.

A question was asked about whether we needed to finish the OWAMP
requirements document first.  Merike replied that since we will
only be proceeding with the reporting part of the MIB, not control,
we did not need to wait for or coordinate with protocol requirements.

Matt asked that given the example of using the MIB on measurement
probes, was this a requirement?  No, you will be able to use the
MIB on a "proxy" that collects results.  However, Emile was concerned
that you might need to limit the size of history you need to keep, if
there was no proxy.

Henk Uijterwaal asked if the MIB allows you to ask for intermediate
results of a long-running tests (such as ones that the RIPE Test Traffic
machines run).

Henk made the observation that the whole document would be more
readable if move section 7 (architecture) to the front rather than
discussing MIB itself.  It would better show the interrelationships.

There was a question about time filter formats -- it will be taken
to the mailing list.

Emile asked what the group thought was more important, to pull the
results or to have a filter and push interesting results.  Henk
noted that the requirement depended on the application; if you are
investigating a problem (or a researcher) you might want raw data, where
operators would prefer summaries.  We should probably cover both. 

4. Discussion on packet reordering (20 min)

http://www.ietf.org/internet-drafts/draft-morton-ippm-nonrev-reordering-00.txt
http://www.ietf.org/internet-drafts/draft-critchley-mlas-reordering-00.txt
http://www.ietf.org/internet-drafts/draft-shalunov-reordering-definition-00.txt

Next there were two presentations on packet reordering metrics that
covered three personal submissions that occurred since the last IETF
meeting.  The first was principally on N-reordering, a metric to show
how many packets are out of order by a certain amount.  The second was
on "non-reversing sequences", which captured similar behavior to N-reordering,
and in addition added metrics to capture more information about how
far packets were out of sequence in dimensions of packets, bytes,
and time.  The third submission related to "Minimum Longest Ascending
Sequences" (MLAS), a technique to give a single number to capture a
notion of out of sequence. 

N-Reordering
  -- Stanislav Shalunov

Mark Allman commented that the metric might be useful to TCP on the fly
to adjust TCP's dupack threshold.

Stanislav commented that he thought one problem with MLAS was memory
use for long sequences, since it requires O(N) memory.

Another person commented that the interval between probe packets is
very important since reordering is dependent on load, and it should
be discussed in any document.

Non-reversing Sequences
  -- Al Morton

Al felt that just having a "percent reordered" packets was not enough,
and the drafts are sufficiently similar that the authors should
be able to work together to merge them.

This draft attempts to split the problem into two parts - first,
say if reordering has occurred and second, quantify the degree of
reordering.

Jeff Richards asked what if a packet is lost or dropped, so that the
sequence number is essentially more than one greater than the last?
Al replied that was fine, and not considered to be reordering (we have
the loss metric for that); any reordering metric should handle lost packets.
Matt Z. noted that most router testers today just report out of sequence,
so if a packet has a sequence number greater than one more than the
last packet, it is counted as out of sequence; if the next packet
fills a hole (so the sequence numbers run backward) it too is reported
out of sequence.  For example, the sequence 1,3,2,4,5 is reported as
having three out of sequence packets (3, 2, and 4).  This allows
them to have one metric to indicate both reordering and loss.  Again,
Al felt that we already had a loss metric, and we should concentrate
on reordering.

There was a discussion as to whether you can have a singleton reordering
metric.  Stanislav felt that you can only really operate on sequences,
Al felt that you do need more than one packet, but that you can define
a singleton.  They agreed to take the discussion offline.

Someone asked why we care about reordering.  Al felt that it happens
enough that we should measure it.  Later, Matt Mathis pointed out
that high-end routers exist that stripe within the router in addition
to routers that stripe over parallel connections.  A bound for how
out-of-order packets can get is a useful result.  Linux even has
code to do adaptive adjustment of the dupack threshold.

Someone formerly from BBN noted that it is important to map to
applications, and that this might require a parameterized metric;
a single number was not seen to be useful.  For some applications,
the number of TCP SACK blocks needed might be the relevant number,
but it's useless for others.

Someone from Worldcom liked the time aspects (spacing) of this
proposal; we need to illustrate where the time aspects are important.

There was general agreement to merge the three drafts, with the
authors working together.

5. Statistics of One-way Delay
-- Dale Pullin

http://www.ietf.org/internet-drafts/draft-corlett-statistics-of-packet-delays-00.txt
http://www.ietf.org/internet-drafts/draft-corlett-statistics-of-packet-delays-00.pdf

Dale Pullin presented on statistics of One-Way Packet Delay.  He
attempted to find distributions that matched his data.  Matt Zekauskas
asked whether there were lost packets or whether they were ignored?
Dale replied that the national sample data had virtually no
packets lost, and the international sample lost 1%.  Lost packets
were excluded from the analysis.

A discussion ensued regarding the use of gamma distributions.  A
member felt that gamma functions are good for approximating any
function; was there a reason it was specifically well suited for
this purpose?  Dale's response was that an exponential distribution is
a special case of gamma distribution and that the sum of independent
exponential will be a gamma variable.  However, he stated that maybe
the gamma distribution is not completely appropriate for data set over
a long time.

Someone commented that perhaps the distributions should be made over
like periods during the day; look for stationary periods.  Dale
disagreed about the cyclic nature over the time periods that were
examined.  (pdf's were over 300 second periods.)

When looking at the power spectrum over the whole dataset,
see peaks at diurnal periods, but the rest is noisy and really
shows no structure.  Within the frequency range of the chart, there
is no indication that there are inherent periods.  Perhaps
a gaussian filter should be applied to see the true spectral
behavior.

6. IPMP
   -- Tony McGregor

http://www.ietf.org/internet-drafts/draft-mcgregor-ipmp-00.txt

The final presenter was Tony McGregor who gave a brief history of IPMP
and mentioned that one vendor is ready to implement it (not one of 2
biggest ones but it's still a starting point).  The outstanding issues
are the size of field to which these records are to be inserted, 60
records for now, and what to do with regard to IPv6.  However, IPv4
seems to be right place to begin.  Tony mentioned the goal was looking
for standardization and he felt that the IPPM working group seemed a
good place to start.

There was a question as to what the protocol did.  Tony explained that
there were two parts to the protocol.  Routers add timestamps to
measurement packets.  The protocol allows the router to use any
timestamp that it has available - you can find out about the time sync
outside of the measurement path.  Also, you request from the router
what the mechanism is by which you process IPMP packet compared to how
you process other packets.  It is similar to pathtrace using
IP-options.  IP options by themselves doesn't work very well since
they are very limited in size

Another question concerned Denial of Service attacks and whether this
has been thought about.  Tony's response was that it created no
greater issue than any other IP packet -- it would be processed within
the main forwarding path so it doesn't introduce any new
opportunities.  A comment was made that there would still be a problem
when you're querying the CPU but Tony replied that the information
request can go low-priority.

Stanislav made a comment that a normal router may look at 6 bits of
header and then map all possible values - with IPMP the 6 bits turn
into 16 bytes with complex interdependencies.  Is that the case?  Tony
responded that because IPMP is packaged inside IP it would still have
the 6 bits.  If the router already using different queueing then it
would use the protocol field but router only needs to check those
things if it already was doing it as part of look-up process.

There was a question of whether IPMP would work with MPLS.  There
was no clear answer to that yet -- At present MPLS forwarding would
work, but would be invisible (like other tunnels).  This is not
a problem because IPMP doesn't require every router to insert
a path record.

There was another comment that there is a policy issue about whether
providers would want to be measured.  Tony replied that this is true,
but some realize that if they will be measured, they want to be measured
well.  This protocol does not expose any information other than IP
addresses, which are usually exposed by traceroutes anyway.  There
are extensions that allow you to return additional information if
you so desire.

The meeting ran out of time, with Matt requesting that if anyone was
interested in a protocol like IPMP to show support on the mailing list;
both pro and con comments are welcome.
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm