X-VirusChecked: Checked
X-Env-Sender: ljorgenson at apparentnetworks.com
X-Msg-Ref: server-13.tower-121.messagelabs.com!1228755277!24935304!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [209.139.228.52]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-AuditID: ac108108-00000e4c00000774-d5-493d514d1d00
Subject: RE: [PMOL] WGLC on pmol-metrics-framework-01
Date: Mon, 8 Dec 2008 08:54:35 -0800
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
thread-topic: [PMOL] WGLC on pmol-metrics-framework-01
thread-index: AclUuJeWbGY6AyloRw+sWjN4K8ltvABneGJgAL/HSyA=
From: "Loki Jorgenson" <ljorgenson at apparentnetworks.com>
To: "Al Morton" <acmorton at att.com>
X-Brightmail-Tracker: AAAAAA==
Al - any reason why my post to PMOL did not make it onto the list?
Loki Jorgenson
Apparent Networks
t 604 433 2333 ext 105
m 604 250-4642
-----Original Message-----
From: Loki Jorgenson
Sent: Thursday, December 04, 2008 16:49
To: pmol at ietf.org
Cc: Alan Clark
Subject: RE: [PMOL] WGLC on pmol-metrics-framework-01
Pardon my late comments as I have been unavailable for PMOL
participation as of late.
One request for clarification as well as some tidying of prose.
1) Is there any value in defining the relationship of this framework to
active or passive measurement methodologies?
Originally I had thought not. It appeared that this document was
intended to be high-level and agnostic to active or passive
methodologies, and therefore said nothing differentiate between the two.
However, there is a reference in Section 6 (Security Considerations)
that states that "security considerations that apply to any active
measurements of live networks are relevant here" with a pointer to
IPPM-developed RFC4656, OWAMP. IPPM thus far limits itself to active
methodologies. This very mildly suggests that this framework is
specific to active techniques.
In Purpose and Scope, the reference is "for... metrics... that can be
used to characterize traffic on live networks and services" - which
sounds distinctly passive, insofar as "traffic" suggests applications
and not active probing.
And, various cross-references to other IPPM drafts and RFCs have been
directly incorporated (e.g. compagg in at least Section 3.3). However,
examples to the Telchemy burst-loss algorithm and RFC 4546 may be
applied to either passive or active.
Further, if passive is included, then security considerations specific
to passive should apply in Section 6 as well (e.g. anonymization). I
don't have a handy sample reference for that.
Not to make more of it than necessary, but maybe it is worth addressing
explicitly. Perhaps a sentence or two within the Purpose and Scope
section declaring its applicability with regard to common measurement
methodologies.
2) Awkward sentence:
Section 3.4.2 (v)
"Short intervals or frequent sampling provides a richer source of
information that can be helpful in assessing application performance
however can lead to excessive measurement data."
It is comprehensible but somewhat awkward. Suggest a couple of changes:
"A SHORT SAMPLING INTERVAL or frequent sampling provides a richer source
of information that MAY be helpful in assessing application performance
BUT MAY ALSO lead to excessive measurement data."
(Capitals indicate changes, not use of capitals in the document - e.g.
MAY here is not the usual IETF directive convention)
3) Ambiguous sentence:
Section 3.4.2 (v)
"Long measurement or sampling intervals reduce that amount of reported
and collected data however may be insufficient to truly understand
application performance or service quality if this varies with time."
Semantically challenged although more or less readable. Suggest:
"Long measurement or sampling intervals reduce THE amount of reported
and collected data SUCH THAT IT may be insufficient to ___ understand
application performance or service quality INSOFAR AS THE MEASURED
QUANTITY MAY vary SIGNIFICANTLY with time."
4) Awkward sentence:
Section 3.4.3 (iv)
"For example, if the metric is a short term running average packet delay
variation (e.g. PPDV as defined in RFC3550) however this value is
reported at intervals of 6-10 seconds this results in a sampling model
which may have limited accuracy if packet delay variation is
non-stationary."
A very long sentence with missing or awkward conjunction. Suggest:
"For example, if the metric is a short term running average packet delay
variation (e.g. PPDV as defined in RFC3550) AND (YET) this value is
reported at intervals of 6-10 seconds, THE RESULTING MEASUREMENT may
have limited accuracy WHEN packet delay variation is non-stationary."
5) Typographic error:
Section 3.4.5 (Measurement Timing:)
"... due to time-of-day load network load changes."
Suggest:
"... due to time-of-day changes in network load."
6) Inconsistent notation:
Section 3.5.1
"... a 10 percent variation ..." (two instances)
Could using number word and "percent" for all instances or numeric value
and '%'. Suggest:
"... a 10% variation ..." (two instances)
End of Comments
------------------------------------------------------------------------
-------------
Message: 1
Date: Tue, 02 Dec 2008 10:11:00 -0500
From: Al Morton <acmorton at att.com>
Subject: [PMOL] WGLC on pmol-metrics-framework-01
To: pmol at ietf.org
Cc: bmwg at ietf.org, ippm at ietf.org
PMOL WG,
cc IPPM and BMWG WGs,
This message begins a WG Last Call on the following draft:
Title : Framework for Performance Metric Development
Author(s) : A. Clark
Filename : draft-ietf-pmol-metrics-framework-01.txt
Pages : 14
Date : 2008-11-02