On Wed, 7 Mar 2001, Samuel festus Stover wrote:

> >Beware of any vendor claiming gigabit performance using off-the-shelf
> >hardware operating in real-world environments. There is a big difference
> >between operating in an "ideal" lab scenarios using atypical packet sizes
> >and fabricated packets and operating in production environments. Buyer
> beware...
>
> I couldn't agree more. Just out of curiosity, what do you consider to
> be "typical" packet sizes? As Director of QA for Ron Gula's NSW
> division of Enterasys, I've spent a lot of time looking at packet
> distributions for some of our clients in order to create viable
> testing solutions that emulate (at least in packet size if not content
> - that's another discussion) real world traffic. I know this could
> easily lead to a PPS vs. bandwidth holy war (like this list hasn't
> ever seen that before ;), but I'm still interested in what you
> consider to be atypical: lots of big packets (low PPS/high bandwidth)
> or lots of little packets (high PPS/low bandwidth)? To further the
> question, what types of environments are you considering? Obviously a
> campus GigE network running networked database applications and VoIP
> is going to have different traffic patterns than a SOHO running
> MetaFrame/Terminal Server.

Please allow me to toss in my .03 euro, as I've been struggling with these
questions for a few years now. (this isn't necessarily directed at you,
Samuel, but rather you and the list in general) As the person who has
spear-headed Network Computing's IDS testing over the past 3 years, I can
safely say that every year these questions continue to haunt me, and I
continue to only partially address them. We're attempting to become
better educated, and perform better testing, but it's a long, long, road.

We started our latest round of testing (12 products) sometime back in
November of 2000, and are still going strong. I hope to have it completed
and published in the May/June time-frame. Without pre-releasing anything
major, our latest observations have completely and TOTALLY re-vamped my
outlook on IDS testing when it comes to traffic creation. The stuff we've
done up to this point has been child's play compared to what we are
learning now.

In short, it's hard to "do this right." A few misc. comments:

First, the great Mbps debate. This thread has come up a number of times
in the past, and I don't want to sound like a broken record here, but I'd
like to toss this out there one more time: Mbps ratings are, IMHO,
*WORTHLESS* without knowing about session numbers, and packet-per-second
(pps) numbers. Check out this chart for 10Mbps Ethernet from
O'Reilly/Spurgeon's "Ethernet: the definitive Guide" (p340):

Data Field Size Max Frames/sec Max Data Field Bits/sec
------------------------------------------------------------------------
46 (64) 14,880 5,475,840
64 (82) 12,254 6,274,084
128 (146) 7,530 7,710,720
256 (274) 4,241 8,706,048
512 (530) 2,272 9,306,112
1,024 (1,042) 1,177 9,641,984
1,500 (1,518) 812 9,744,000

Now, based on this, 100% utilization could be 64 byte frames at 14,880
pps, or 1,518 byte frames at 812 pps. Big difference. Those two are far
from equal, processing-wise. So anyone who simply says "runs at X Mbps"
is supplying less then 50% of the information.

And this is where my understanding left off in 1999 or so. Then our
university deployment hit, which schooled us once again. Add to the
packet-size / pps equation the number of sessions. Because many ID
systems have to track state, to some level, the number of sessions is a
huge factor. 14,880 pps between two hosts is VERY different then
14,880pps between 5,000 hosts. I've witnessed first-hand ID systems
melting at 6,500pps, 35Mbps with little chance of recovering BASED ON THE
NUMBER OF SESSIONS THEY ARE WATCHING. Short version: add sessions to the
equation.

Second, traffic varies GREATLY from network to network. Internal
enterprise networks might see a lot of SMB, NFS, SNA, and SQLnet traffic,
for example, while external/DMZ networks might see mostly HTTP, FTP, SMTP,
and the occasional SSH session. Move to a university, and you'll see a
ton of HTTP, FTP, SSH, SMTP, IMAP, POP, Napster, IRC, and a myriad of
other protocols you won't see in the average corp space. Move to a
carrier network, and you'll see everything from HalfLife traffic to BGP
updates, and every other protocol that goes across the net.

The point being that there isn't really an easy way to say "typical
traffic." One might be able to craft some baseline assumptions on what
university traffic looks like, what internal corp traffic looks like, what
DMZ/external corp traffic looks like, what ISP traffic might look like,
etc., but environments are so wide and varied that there is no "one size
fits all" approach to traffic modeling.

So I realize this doesn't really answer the question, but I hope that it
at least justifies some thoughts concerning:

- Number of packets per second
- Size of packets
- Types of protocols (HTTP, FTP, SMB, SMTP, etc.)
- Number of sessions/hosts

Hope this list finds some of this useful,

Greg Shipley
NWC/Neohapsis Testing Slave

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]