Subject: [dtn-users] Management statistics in DTN2 database

From: Ewerton Salvador <[email-masked]>
Date: Wed, 11 Apr 2012 16:15:52 +0100

Hi!

My name is Ewerton Salvador, I'm a Brazilian PhD student and my current
research topic is DTN management.

I'm planning to extend the Bundle Protocol MIB (
http://tools.ietf.org/html/draft-sims-dtnrg-bpmib-01), or maybe to propose
another separated MIB, for providing means to allow one to access
statistics concerning the performance of the Bundle Protocol in different
time periods (statistics from the last day, the last week, the last month,
etc.). In order to do this, I'll need to store these statistics in a
persistent storage, and the first idea is to store those statistics in the
same database that DTN2 uses to keep the bundles records and other related
stuff. What do you think? Do you see any problem coming from this? If you
have any thoughts on this matter, they will be most welcome!

Cheers,

Ewerton

---

From: "Clark, Gilbert" <[email-masked]>
Date: Wed, 11 Apr 2012 11:45:22 -0400

Hi Ewerton:

A few thoughts --

* Given the wide variety of devices upon which DTN implementations are
expected to run, and the different methods used to collect / analyze
management data, I really don't think the core BP MIB is the right place
to describe aggregate day / week / month data.  Instead, I'd argue for
leaving aggregation to the collector.

* MIBs are nice for ground stations, but as far as DTNs concerned, I'm not
sure I personally believe they're the best way to go.  Something a little
easier for managed nodes to parse might be better, especially given that
the MIBs can be used as a schema for encoding / decoding the data.

* Performance is kind of a loaded word, I think.  What kind of performance
are we talking about here?  What kind of network?  Note that rolling
averages might not be useful in situations where a link is expected to be
down for 72 hours, then up for 72 hours, then Š you get the idea.
Instead, a language to define these kind of statistics in a way that makes
sense to the managed node could be useful.

* I believe some folks at NASA were working on this kind of thing with
DTN2 a few years back.  I did the same thing with ION, but my
instrumentation was pretty limited :)

* Have you read about RMON / RMON2?  They are very relevant to this kind
of thing, *especially* if you're looking to instrument DTN2 directly as
part of your research.

--Gilbert

From:  Ewerton Salvador <[email-masked]>
Date:  Wed, 11 Apr 2012 11:15:52 -0400
To:  "[email-masked]" <[email-masked]>
Subject:  [dtn-users] Management statistics in DTN2 database

Hi!

I'm planning to extend the Bundle Protocol MIB
(http://tools.ietf.org/html/draft-sims-dtnrg-bpmib-01), or maybe to
propose another separated MIB, for providing means to allow one to access
statistics concerning the performance of the Bundle Protocol in different
time periods (statistics from the last day, the last week, the last month,
etc.). In order to do this, I'll need to store these statistics in a
persistent storage, and the first idea is to store those statistics in the
same database that DTN2 uses to keep the bundles records and other related
stuff. What do you think? Do you see any problem coming from this? If you
have any thoughts on this matter, they will be most welcome!

Cheers,

Ewerton

---

From: Zack Sims <[email-masked]>
Date: Tue, 17 Apr 2012 15:10:15 -0400

I believe I only responded to Gilbert... sorry. Message below
------------
'm late to it, but I've been meaning to release a new version of the MIB
draft.  Statistics were considered in the original design, but extending
the MIB seemed like a poor decision.  We felt it was a better idea to
create a second MIB, or perhaps a DTN-Statistics MIB.  In the case of TCP,
for instance, where predictable connection times are known, collecting
buckets of information into a database seemed like a perfectly sound idea.
The collection intervals, reporting times, and compounding intervals can be
intuitively determined in a way that satisfies most applications.  However,
shifting paradigms to a system with unknown delays and connection times
causes user-specific requirements to arise.

The draft makes reference to secondary MIB(s) that ought to be used for
finding trends or for gathering bulk data.  This was an idea that we mulled
around within our research lab; but have yet to design/develop.  Some
important considerations/motivations:

* All MIBs for DTN related protocols (LTP, BP, etc...) will experience the
same condition where user-defined requirements arise for extended
statistics gathering

* RMON has a paradigm that is relevant, but not entirely recycle-able.  An
idea that we have relates to creating a generic DTN MIB that will
control/store compounding data, data trends, data bucket, and storage rules
for any MIB managed over a DTN.

* Using the integrated database for DTN2 may be an effective technique for
storing long-term data, but I might suggest integrating statistic
collection as an option (to remove bloated use of persistent storage where
not needed)

* In certain embedded applications, MIB language may not be the best way to
represent managed information on the managed entity, but a MIB is still
relevant.  Instrumentation of the MIB and the management protocol will
determine how the data is collectable (however the MIB definitions are
still a fairly standard and readable formant for today's managed systems).

I'll be working to finish up the new draft later next week (so this is good
timing for us). Please feel free to contact me and offer suggestions,
comments, and otherwise.  Also, I'd like to stay in the loop on your
techniques for collecting/managing statistics.  A cooperative approach to
design might give us some better results.

Thanks

On Wed, Apr 11, 2012 at 11:45 AM, Clark, Gilbert <[email-masked]> wrote:

> _______________________________________________
> dtn-users mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-users
>

-- 
*Zack Sims
Engineering Intern at NASA GRC
MTI Systems, Inc.
Graduate Assistant with IRG
Ohio University*