RE: [NTDP] Purpose of NTDP

"Loki Jorgenson" <> Tue, 01 August 2006 17:01 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1G7xcr-0004Fb-Qi; Tue, 01 Aug 2006 13:01:49 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1G7xcq-0004Dq-JM for; Tue, 01 Aug 2006 13:01:48 -0400
Received: from ([]) by with smtp (Exim 4.43) id 1G7xco-0003Ax-8G for; Tue, 01 Aug 2006 13:01:48 -0400
Received: from ([]) by (SMSSMTP with SMTP id M2006080110014410210 for <>; Tue, 01 Aug 2006 10:01:44 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [NTDP] Purpose of NTDP
Date: Tue, 1 Aug 2006 10:01:42 -0700
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [NTDP] Purpose of NTDP
Thread-Index: Aca0Rqlr8SP6mL+tQRyedpdrTHCrYwAdJlagACI2y4AAEIKMEA==
From: "Loki Jorgenson" <>
To: "Craig Brown \(crbrown\)" <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: define standards for the purpose of scripting of network testing equipment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Craig - let us suppose that "controlling testing devices" is related to
some methodology for detecting network conditions (possibly distinct
from the testing itself).  The testing system is applied reactively in
response to the detection of some conditions.  For example, a VoIP
management system sampling RTCP-XR data from IP phones might discover a
general degredation and send out an alarm.

Today, that is typically a user calling to complain.  However, with
continuous monitoring, app-aware network devices, adaptive applications,
etc. it is more the likely that either the "testing devices" themselves,
or some other other automated external stimulus, triggers a "controlling
of test devices" and directs them to a specific task.  Some call this
"proactive" simply because such a system responds to degraded conditions
before the end user does, potentially resulting in a break-fix before
the user is aware.

While we are barely beyond reactivity in the sense of the user
complaint, it is clear that the technologies are moving toward such a
proactive stance and we need to be able to provide a framework for
"controlling testing devices" that accepts triggers or other feeds from
non-human sources.  This might look like a simple API of
trigger/response but it should at least preserve the relationship
between the stimulus, the reaction, and the outcome.

In directing the testing devices, there should be a set of constraints
that define the nature and extent of the gathering of data.  How long?
Until what is satisified?  Indefinitely until there is an "off" trigger?

Finally, a specific set of constraints on data gathering are met (e.g.
enough data), then an analysis process should be associated with the
data.  Once again, the relationship between the initial conditions and
the analysis should be preserved.

Once the analysis is complete, some conclusion or action may be
associated with it.  Typically, that amounts to a particular signal, a
threshold against which it is compared, and an alarm sent to a human (or
at least a management system).  This is very anthro-centric insofar as
it assumes that a human (or possibly an NMS) will interpret the outcomes
of the analysis and determine appropriate actions to take.

A device/configuration management system might be invoked to remediate
or provision against a particular outcome of the analysis, with yet
another "controlling of testing devices" activity subsequently triggered
to validate the remediation/provisioning action.  Once a framework is
capable of 
   o preserving the association between 
		conditions/trigger --> testing --> analysis -->
remediation --> validation
   o associating condition sets with analyses, analysis outcomes with
remediation, remediation with validation actions
   o relating triggers/testing/analysis over time
   o  running without human intervention
then it has the potential to support fully autonomic operation.

The specifics of those associations would be what I hope we would
discuss and develop on this list.  I anticipate that the differences
between methodologies, data set content, analyses, etc. and the
challenges of associating dissimilar data/analyses will be substantial.
This parallels work undertaken by the Internet2 End-to-End project (e.g.
perfSONAR) attempting to abstract a range of well-defined testing
technologies sufficiently that they can be integrated into a single

On the other hand, it may be that the "controlling test
devices/gathering data" aspect of this larger framework is all that we
are interested in with NTDP.  It would be a layer that simply accepts
testing requests of a certain form, executes and returns the data.  The
analysis and other levels of behavior might be found in a separate
system/layer.  That would be less interesting (unless there were some
well-defined descriptions for those layers that we can reference).

Hope that helps to clarify my point, as requested.


-----Original Message-----
From: Craig Brown (crbrown) [] 
Sent: Tuesday, August 01, 2006 1:27 AM
To: Loki Jorgenson
Subject: RE: [NTDP] Purpose of NTDP


I can see the areas of controlling testing device and gathering data.
Can you expand the description of the other areas ?


NTDP mailing list