[802.3AZ] about trace files

[Mike Bennett <mjbennett@xxxxxxx>]

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