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
- [ippm] Review of: draft-ietf-ippm-reordering-12.t… Wijnen, Bert (Bert)
- Re: [ippm] Review of: draft-ietf-ippm-reordering-… Al Morton
- Re: [ippm] Review of: draft-ietf-ippm-reordering-… Mark Allman
- Re: [ippm] Review of: draft-ietf-ippm-reordering-… Al Morton
- Re: [ippm] Review of: draft-ietf-ippm-reordering-… Mark Allman
- RE: [ippm] Review of: draft-ietf-ippm-reordering-… Romascanu, Dan (Dan)
- RE: [ippm] Review of: draft-ietf-ippm-reordering-… Romascanu, Dan (Dan)
- RE: [ippm] Review of: draft-ietf-ippm-reordering-… Al Morton
- Re: [ippm] Review of: draft-ietf-ippm-reordering-… Randy Presuhn
- RE: [ippm] Review of: draft-ietf-ippm-reordering-… Al Morton
- RE: [ippm] Review of: draft-ietf-ippm-reordering-… Wijnen, Bert (Bert)