Re: [802.3AZ] about trace files
Greetings Mike,
One thing to bear in mind is that changing the rate will greatly
change the packet arrival process, because TCP will react.
I saw a paper saying "if we reduced the link rate using policy X, we'd
get huge packet backlogs" because it was simply using layer-2 packet
traces.
It would be good if your capture included enough payload to be able to
reconstruct TCP sessions, the way Tmix does.
Cheers,
Lachlan
On 22/04/2008, Mike Bennett <mjbennett@lbl.gov> wrote:
> Folks,
>
> A number of people have been talking about the use of trace files to
> understand the nature of the link utilization for various types of networks.
> Before I start a campaign to build a library of trace files, I'd like to
> make sure my assumptions are correct so we get a useful set of files. Once
> I get agreement from folks on what we need, I will start collecting traces.
> Bruce Nordman has volunteered to be the capture file "librarian".
>
> Here are my assumptions (based on my experience and Bruce's input):
>
> * We only need to capture enough of the frame to get the time-stamp
> and frame size (frame capture length is 14 Bytes).
> o We minimize security policy issue with sharing the captures
> if we limit the content of the frame captures.
> * Most open source capture tools support the packet capture library
> (libpcap) so trace files should be saved in that file format.
> * We need to balance the duration of the capture period with the
> size of the packet capture file. Based on some tests I've run, a
> moderately utilized 10G link will generate approximately an 4 GB
> capture file in 2 hours. I believe 2 hours is long enough to tell
> us something about the nature of the utilization of the link. If
> you want to characterize a particular link for a longer period
> then the capture should be restarted to limit the file sizes.
> o we could capture in 1 hour increments - it would cut the
> file sizes down. Let me know if you have a preference.
> * Meta data on the packet captures should include:
> o Date of collection
> o Name and company of individual who collected the trace
> o Link speed and type, e.g. 1000BASE-T, 10BGASE-LR, etc.
> o Type of devices at the ends of the link, e.g.,
> router-switch, desktop-switch, switch-switch, etc.
> o General usage, such as department file server, desktop PC in
> office, HPC cluster node, etc.
>
> This should be enough to help us determine how EEE will behave under the
> conditions of the capture. It won't be perfect but it will help. Please
> ask your questions or point out what you think is missing or needs to be
> changed by the end of this week.
>
> Regards,
>
> Mike
>
--
Lachlan Andrew Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603
http://netlab.caltech.edu/lachlan