RE: [ippm] Review of: draft-ietf-ippm-reordering-12.txt

Al Morton <acmorton@att.com> Tue, 25 April 2006 15:53 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYPqY-0008Ox-3z; Tue, 25 Apr 2006 11:53:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYPqW-0008Os-Eh for ippm@ietf.org; Tue, 25 Apr 2006 11:53:00 -0400
Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FYPqW-0006OF-4H for ippm@ietf.org; Tue, 25 Apr 2006 11:53:00 -0400
X-VirusChecked: Checked
X-Env-Sender: acmorton@att.com
X-Msg-Ref: server-5.tower-120.messagelabs.com!1145980378!10493538!1
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 12453 invoked from network); 25 Apr 2006 15:52:59 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-5.tower-120.messagelabs.com with SMTP; 25 Apr 2006 15:52:59 -0000
Received: from acmt.att.com (acmt.mt.att.com[135.16.251.35](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20060425155258gw1001009oe>; Tue, 25 Apr 2006 15:52:58 +0000
Message-Id: <6.2.1.2.0.20060425110831.08ac6390@postoffice.maillennium.att.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Tue, 25 Apr 2006 11:52:58 -0400
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, ippm@ietf.org
From: Al Morton <acmorton@att.com>
Subject: RE: [ippm] Review of: draft-ietf-ippm-reordering-12.txt
In-Reply-To: <6.2.1.2.0.20060423103143.022fb7c8@postoffice.maillennium.a tt.com>
References: <AAB4B3D3CF0F454F98272CBE187FDE2F0A5F7370@is0004avexu1.global.avaya.com> <6.2.1.2.0.20060423103143.022fb7c8@postoffice.maillennium.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc:
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=subscribe>
Errors-To: ippm-bounces@ietf.org

IPPM,

After several off-list exchanges with Bert and Dan, we have a better
statement of the issues Bert raised w.r.t. reordering metrics Sec 4.5:

1. Metrics with multiple output parameters are somewhat problematic
for NM systems, and a simple MetricName:value relationship is desired.

If we defined two metrics in Sec 4.5, they could be called:
      Type-P-Packet-Reordering-Gap-Stream
      Type-P-Packet-Reordering-GapTime-Stream
and then we could easily refer to them in the IANA section,
and get a metric number assigned to each one in the registry.

However, I see that we would have to do the same thing in Sec 4.6.
There are four output parameters that we defined, so we would
need a new metric name for each one:
      Type-P-Packet-Reordering-Free-Run-x-numruns-Stream
      Type-P-Packet-Reordering-Free-Run-q-squruns-Stream
      Type-P-Packet-Reordering-Free-Run-p-numpkts-Stream
      Type-P-Packet-Reordering-Free-Run-a-accpkts-Stream

An alternative to adding all these new metric names would
be to simply revise the (new) IANA section to reflect the existence
of output parameters, but this seems less straightforward.

So the current plan is to add the new metric names and corresponding
entries in the IANA section. (Also, it's possible to revise the
text of section 4.5 to make it more clear the GapTime is optional,
and we'll make those changes while in that neighborhood.)


Back to Bert's Issues:
2. When a metric is reported in units of time, it's much easier
to compare the results between systems if the same resolution
is used, and some standard solution should be developed.

My conclusion is that all the "time" metrics in the current
IPPM registry RFC 4148 would not necessarily be reported
with a standard resolution because IPPM has allowed flexibility
in this area (and even the units might differ: seconds vs. millisec).
In order for the registry to be useful, more standardization
is needed, and the need is larger than the reordering draft.
I believe we need an agreement/solution that covers all
our metrics as pertains to their values stored and reported in the
context of the metric registry.

Also, Randy Presuhn observed that we have have not explicitly
specified the units of time in the reordering draft, possibly
because we been using the word "time" synonymously with "seconds".
This is easily corrected in sections 4.3 and 4.5, where we
would specify units of seconds explicitly.

Constructive comments on any of these issues would be welcome.

Al


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