Re: [802.3AZ] about trace files
Dear all,
As much as I admire the idea and I believe such data should be collected and used in the project, there is already plenty of trace data available publicly.
Please check http://pma.nlanr.net/Traces/ and see whether it fits Your needs. I found it useful. They do have various interfaces available. I am also confident that if You do decide to go ahead with the traffic capture, they would be more than happy to help You. The project's staff is very helpful.
Just my small contribution to the overall discussion.
BR
Marek Hajduczenia (141238)
NOKIA SIEMENS Networks S.A.
System Architect - COO BBA DSLAM R&D
Rua Irmãos Siemens, 1, Ed. 1, Piso 1
Alfragide, 2720-093 Amadora, Portugal
* marek.hajduczenia@nsn.com
(+351.21.416.7472 4+351.21.424.2337
-----Original Message-----
From: ext Hays, Robert [mailto:robert.hays@INTEL.COM]
Sent: terça-feira, 22 de Abril de 2008 17:13
To: STDS-802-3-EEE@LISTSERV.IEEE.ORG
Subject: Re: [802.3AZ] about trace files
Mike,
Your proposal looks good. Removing payload and keeping the MAC, IP, TCP
packet headers with corresponding time-stamps and frame lengths gives us
enough information to model system/network performance vs. energy
consumption (for LPI and subset PHY).
If possible, it might be valuable to collect some additional bytes from
the payload for future study of the potential benefits of treating
applications (e.g. HTTP, DNS, VOIP)differently via EEE policy decisions
aligned with QoS priorities. The TCP/IP headers won't be enough to
infer the application but logging some number of bytes from the payload
should allow us to reconstruct most of the application-layer headers
without compromising data privacy.
Thanks,
Rob
-----Original Message-----
From: Mike Bennett [mailto:mjbennett@LBL.GOV]
Sent: Monday, April 21, 2008 2:09 PM
To: STDS-802-3-EEE@LISTSERV.IEEE.ORG
Subject: [802.3AZ] about trace files
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