From: Bo Ryu (ryu@hrl.com)
Date: Mon Jan 22 2001 - 13:35:03 PST
>
> Well, certainly any kind of fine timescale packet timing detail, like
> inter-arrival statistics. Probably any other bulk stats analysis like
> fractal-behaviour, burstiness etc.
Doing so requires requires either long traces (much longer than 90sec) or
some innovativge way of applying wavelet analysis tools directly towards
traces near on-the-fly to get rid of storage constraint.
>
> > If the interest is in having an archive of traffic to see
> > how it changes over time, then biases from short trace
> > durations would apply to both current and archived traffic.
> > This probably wouldn't hurt too much.
> >
> > As long as it is clear that one shouldn't use these 90
> > second traces to draw conclusions about the duration of
> > streaming media flows, or FTP connections through dial-up
> > modems, 90 seconds would be fine.
> >
> > It's not clear there is a trace duration that would
> > service both camps, and 90 seconds seems like a reasonable
> > compromise.
>
> Well, what can you do with 90s worth? It ought to be a reasonable sample
> of packets. You shuld see the protocol mix, and hence application mix,
> how this changes over time. It's too small to give you many, or very
> long flows, so it's not a good snapshot of that. I don't think you
> wouldn't get enough to see the size distribution of data objects being
> fetched with http for example.
>
> 24 hours would be suitable for that kind of work, would 1 hour be long
> enough? Certainly there are longer lived flows/sessions than that.
>From this discussion, it seems clear that we need to find a way to get a
long-duration trace or extend the capability of the current monitors to
achieve this without needing humongous disk storage space. I shall be
grateful if someone can tell me whether it is possible to "pipeline" the
basic data (packet timestamp and header information) on-the-fly into other
"engines" that process this data for whatever purpose we have (e.g.,
protocol mix or wavelet analysis) in real time, and delete this basic data
after they are fed into these engines to recycle the storage space.
> Well, I think the main purpose is to aid people in trace selection, so
> it is 'advertising' in some way. Presumably given just a list of trace
> files with dates, people will choose one to work on at random. By
> providing more data, like bitrates or application breakdown, we're
> hoping to give people a better idea what the trace looks like, and
> perhaps this will help people choose which one to use.
>
> Hence the question, what criteria do people use to choose traces to use
> in their analysis? Duration of trace? Mean bitrate? Time of day?
> Location? Trace filesize? I don't think we can expect to do all kinds of
> analysis on each trace that people might do themselves.
One input here is to tag each trace in terms of its "user population and
nature of business". Examples include SOHO, large-size academia (campus
wide), small size academia (department or lab wide), medium-size research
center, etc. The main motivation here is to see whether we can differentiate
user demands based on this classification in terms of user demand
characteristics both qualitatively and quantitatively. If so, this can help
provide useful insights into what traffic models to be used for his/her
particular simulation.
-Bo
>
> Stephen.
> --
> -----------------------------------------------------------------------
> Stephen Donnelly (BCMS) email: sfd@cs.waikato.ac.nz
> WAND Group Room GG.15 phone +64 7 838 4086
> Computer Science Department, University of Waikato, New Zealand
> -----------------------------------------------------------------------
This archive was generated by hypermail 2b30 : Thu Sep 27 2001 - 16:24:41 PDT