From: Joerg Micheel (joerg@cs.waikato.ac.nz)
Date: Sat Jan 20 2001 - 14:37:40 PST
Hi Neil,
thank you for your reply. We very much appreciate you are taking
the time to respond to our questions.
On Sat, Jan 20, 2001 at 12:16:57PM -0800, Neil Spring wrote:
> > o Whether you think 90 second snapshots are sufficient (do you need
> > longer traces) ?
>
> I think I would want longer traces. If I wanted to look
> at flow length (time, number of bytes), 90 seconds seems
> too short. I'm not sure if increasing the duration of the
> snapshot while fixing the size by sampling only certain
> IP address pairs (eg. those packets with a source ending
> in .14 and a destination ending in .33) would address
> this problem. Even if it would, do you have the cycles
> to burn on matching packet information?
Ok. Longer traces. I think we have the necessary cycles to do
filtering on traces, the more since it reduces disk IO, which
I see becoming scarce. I wonder whether it is practical from
an analysis point of view.
Did you consider an Auckland or NZIX trace yet ? How long do you
think would a trace like this "last", in terms of time required
for analysis until you need the next data set ?
> > o Whether 8 samples per day are appropriate (would you rather have
> > less samples per day, only a few days per week, only one week out
> > of a month, ...) ?
>
> Fewer, longer traces would seem fine to me. I don't really
> care about daily usage patterns: only enough samples to
> convince me that what I saw was not an effect of being
> run at 5am would be sufficient.
To make it extreme, we would capture a single 24 hour trace. Ignoring
disk space constraints for a moment, lets look what impact this has
on frequency. At the moment, monitors capture 8 90 second samples
per day. This is about 12 minutes per day. About 6 hours per month.
To not increase data volume, we could only capture a one-day trace
every four month, that is three per year. I can see such sampling
as being biased by chance.
An option being considered is to let different monitors run different
trace strategies. It is also possible to "profile" measurement points,
where we do not keep the data, but some graphs on important parameters,
which allow you to check how a particular sample relates to the activity
of the rest of the day. Instead of pictures, we could keep high-level
samples about certain parameters (for instance packets/sec, megabits/sec,
flows/sec in samples of one second). This vastly decreases the amount
of information stored, but still provides a hook to evaluate the bias
for a detailed sample in correlation to a complete (long) trace.
> > o What kind of documentation/graphs would you like to see along the
> > raw traces ?
>
> I don't know, but the thought of having automatically
> generated graphs for the raw traces is interesting.
> You wouldn't be able to automatically generate some of the
> graphs from http://www.caida.org/outreach/papers/Inet98/?
> Not serious, just a wish-list item. I'm curious how figure
> 8 changes over time.
I think we are willing to go great length to match the needs for traces,
however, we may have to priorize and consider how long it takes to
implement certain features. Having an extensive set of pictures on very
few selected traces sounds like the best option to me at the moment.
Thanks, again, for all your information.
Joerg
-- Joerg B. Micheel Email: <joerg@cs.waikato.ac.nz> WAND and NLANR MOAT Email: <joerg@nlanr.net> The University of Waikato, CompScience Phone: +64 7 8384794 Private Bag 3105 Fax: +64 7 8585095 Hamilton, New Zealand Plan: PMA, TINE and the DAG's
This archive was generated by hypermail 2b30 : Thu Sep 27 2001 - 16:24:41 PDT