Subject: [IMRG] Status of SIMR-development in IMRG

From: Carsten Schmoll <[email-masked]>
Date: Wed, 13 Nov 2002 16:15:45 +0100

Hello Mark,

I work for the Fraunhofer Institute for Open Communication Systems
(FOKUS) which is a German national research institute. We have been
working in the area of Internet measurements for quite some time. This
relates to development of metering solutions, control of distributed
measurements, data collection and evaluation. We are also active
in IPFIX and PSAMP. I read the paper which describes the ideas and setup
of the SIMR database ("A Scalable System for Sharing Internet
Measurements" by Mark Allman, Ethan Blanton, Wesley M. Eddy) and I think
it's worthwile bringing such a system into action.

Attached you find my comments and ideas for the SIMR development. I'm
not sure about the current status of the SIMR project/database? What are
the next planned steps in this direction? How can I keep up to date and
contribute?

btw:
My collegue Tanja Zseby will be at the IETF in Atlanta. She is planning
to attend the (non-official) meeting that you proposed to have there.
I'm looking forward to the results of your discussion in Atlanta.

Kind regards
Carsten.

-- 
"The difference between theory and practice is that in theory
  theory and practice are the same but in practice they are not."

Dipl.Ing. Carsten Schmoll                Fraunhofer Institute FOKUS
[email-masked]                     National Research Institute
FhI FOKUS / Global Networking (Glone)    for Open Communication Systems
Tel: +49-30-3463-7136                    Kaiserin-Augusta-Allee 31
Fax: +49-30-3463-8136                    D-10589 Berlin, Germany

Comments related to the paper:
"A Scalable System for Sharing Internet Measurements"
 by Mark Allman, Ethan Blanton, Wesley M. Eddy

The paper contributes a number of novel approaches, and I like
the new ideas it presents a lot. Especially good are the:

* separation of meta-data databases and measurement traces
* emphasis on consistency of the stored data by
  - having a basic set of required fields
  - making tool and trace data uniquely accessible
  - providing a way to check data consistency with MD5 sums
* provision of search functionality (on meta-data)
* extensibility via record-type specific additional meta-data

I think, the presented ideas build a good stable basis for
management and distribution of Internet measurement results.

Additional ideas:

There are some nice-to-have ideas that came up to my mind while
reading the paper. I give a short summary next:

* it would be nice to have some more meta-data describing the
  traffic traces such as:
  - lowest layer from which headers are included in a trace (e.g. MAC/IP/application)
  - number of captured packets
  - volume of captured traffic
  - average packet rate
  - link speed, i.e. interface type ((Fast)Ethernet, Gigabit Ethernet, ATM OC-xx, ISDN,...) 
  - indication of time stamp accuracy in packet traces
  The possibility to restrict the search on interesting traces using these
  attributes would IMHO contribute a valuable addition.
  
* regular status check for trace data + tool data (already mentioned in paper) plus
  a (user-visible) entry in the database showing the status+date+time of the last check
* maybe some kind of mirroring for the most used trace data & tools or at least the
  possibility to provide one packet trace on different locations to have the possibility
  of load-balancing. Of course this is only an issue if downloads are a bottleneck. 
* it would be a quite nice feature to have automated virus checks on tools submitted to
  the database system  (unfortunately these would surely not work on tools submitted as 
  source code. For these a human virus checker works best ;) .

---

From: Mark Allman <[email-masked]>
Date: Fri, 15 Nov 2002 07:16:21 -0500

> Attached you find my comments and ideas for the SIMR
> development. I'm not sure about the current status of the SIMR
> project/database? What are the next planned steps in this
> direction? How can I keep up to date and contribute?

From an IMRG perspective -- stay tuned.  I think there will be quite
a bit of informal discussion on this next week.  If anyone has
thoughts on the process of getting such a repository going,
populating it, etc. please send them to the list (or, directly my
way if you'd rather).

I hope to be able to send a note with some solid RG next steps soon
(in the area of measurement repositorys and other items).

Thanks for your interest!

allman

--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
_______________________________________________
IMRG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/imrg

---

From: Mark Allman <[email-masked]>
Date: Fri, 15 Nov 2002 07:38:26 -0500

>     (e.g. MAC/IP/application) 

Good point.

>   - volume of captured traffic

Still thinking on this.  One of them things we tried to stay away
from was populating the database with analyzed data.  I would argue
that the last piece above starts us on a slippery slope (if I
include "average packet rate" should I think include "average packet
size" or "average delay/RTT" or "number of TCP connections" or ...).
The first two don't seem as problematic to me and I could go either
way.  I believe that we sketched a field for the duration (in
seconds) of a trace.  So, I'd be interested to know if folks would
be more interested in a time measurement or a packet/volume count or
whether both are needed.

> Ethernet, ATM OC-xx, ISDN,...)

Yep.

>   - indication of time stamp accuracy in packet traces

Could be difficult to say, no?

> * regular status check for trace data + tool data (already
> mentioned in paper) plus a (user-visible) entry in the database
> showing the status+date+time of the last check

Um.  Yeah.  That might be handy, I suppose.  The only problem I see
here is that we envisioned that a seperate entity could conduct the
probes to verify things.  So, we'd need a way to communicate status
to the database from that entity.

The flip side is that anything in the database that is not flagged
some way (i.e., "inactive/can't find anymore/whatever") may be able
to be thought of as OK -- even if there is nothing that specifcally
says it.

Not sure where I'd fall on this one.

> * maybe some kind of mirroring for the most used trace data &
> tools or at least the possibility to provide one packet trace on
> different locations to have the possibility of load-balancing. Of
> course this is only an issue if downloads are a bottleneck.

Ah, yes.  So, the URL of a measurement could be a set of URLs.
(Which would allow the repository to punt on the actual mirroring,
but still support it.  And, if one buys the SIMR notion of things
the database really has nothing to do with data storage and was
explicitly decoupled from data storage -- in which case it should
not have any part in conducting mirroring.)

> * it would be a quite nice feature to have automated virus checks
> on tools submitted to the database system (unfortunately these
> would surely not work on tools submitted as source code. For these
> a human virus checker works best ;) .

I would point you towards the "Security Considerations" section of
our paper in which we discuss these issues.  That section concluses
as follows:

    However, in our opinion, while we may be able to somewhat
    mitigate the security problems associated with running other
    people's code, each researcher will have to remain vigilant when
    executing code that they did not write\footnote{And, in fact,
    some of us need to be careful when using code that we do
    write!}.

Thanks for the comments!

allman