From: Stephen Donnelly (sfd@cs.waikato.ac.nz)
Date: Mon Jan 22 2001 - 12:56:11 PST
Neil Spring wrote:
>
> > 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.
>
> Yes, the disk IO tradeoff makes sampling more attractive
> from a technical point of view. I am also curious to hear
> what sort of anaylses this scheme might prevent.
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.
> 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.
> What is the goal of presenting the graphs alongside the
> traces? Is the intent to advertise the trace in some way?
> Or to present sample analysis so that I can verify the
> function of my tools? Or are you going to do the simple
> traffic analysis "for us" so that we can use current data
> in our research without writing our own scripts?
>
> Now that I look at the graphs presented for the nzix
> traces, I have some idea of the context of your question.
> If it's not impossible, splitting the TCP traffic into the
> top four or five protocols by port might be interesting.
> Since I don't know the goals of including the graphs,
> I'm not sure what to suggest.
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.
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