Re: Comparing an old flow snapshot with some packet size data

"Kent W. England" <kwe@6sigmanets.com> Fri, 09 August 1996 00:56 UTC

Received: from ietf.org by ietf.org id aa25077; 8 Aug 96 20:56 EDT
Received: from cnri by ietf.org id aa25073; 8 Aug 96 20:56 EDT
Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa17626; 8 Aug 96 20:56 EDT
Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA13731; Fri, 9 Aug 1996 10:40:53 +1000
Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA13680; Fri, 9 Aug 1996 10:34:46 +1000
Received: from burnout.cts.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id AA32269; Fri, 9 Aug 1996 10:34:44 +1000 (from kwe@6SigmaNets.com)
Received: from netguru.cts.com (netguru.cts.com [204.94.77.43]) by burnout.cts.com (8.6.12/8.6.9) with SMTP id RAA27548; Thu, 8 Aug 1996 17:33:46 -0700
Message-Id: <2.2.32.19960809003359.0073ab6c@mail.cts.com>
X-Sender: kwe@mail.cts.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 08 Aug 1996 17:33:59 -0700
To: "Karl Denninger, MCSNet" <karl@mcs.com>, Andrew Partan <asp@partan.com>
Sender: ietf-archive-request@ietf.org
From: "Kent W. England" <kwe@6sigmanets.com>
Subject: Re: Comparing an old flow snapshot with some packet size data
Cc: pferguso@cisco.com, jhawk@bbnplanet.com, big-internet@munnari.oz.au
Precedence: bulk

At 03:41 PM 8/8/96 -0500, Karl Denninger, MCSNet wrote:
>
>The trade-off IMHO has to do with the technology changes.  Cram 4470 into 
>53-byte cells for ATM, and you end up needing 85 of them for each segment!
>I suspect that some of the buffering problems we've seen with things like
>Netedge boxes can be traced to that kind of encapsulation change problem...
>
>Cut that MTU to 1500 and now you only need 29 cells for a segment.  Much
>less likely to run into trouble.

My experience with the PacBell NAP has led me to conclude that ATM performance
is best optimized with very large packets. It's better, in my opinion, to
operate with large packets over a zero cell loss ATM network than to pay the
extra 2 or 3% that smaller frame sizes cost on the padding overhead. The
Stratacom switches have plenty of buffer space and large frame sizes are
more efficient if you have large ATM buffers, explicit flow control and 
zero cell loss.  (Now, technically, we aren't talking zero cell loss but
practically speaking as near to zero as one can get.) I'm sure that other
ATM switches with large buffers and flow control work as well, but those
that don't, well, they don't quite cut it.

So, since routers work better with larger frame sizes and so do ATM switches,
then it's safe to say that increasing the MTU is a good thing.
>
>The bigger problem is that some hardware out there can't hope to keep up at
>DS-3 rates and above with very small segment sizes.  I don't know how much
>of a problem this is in the real high-end hardware, but I do know that it
>shows up instantly for those people trying to do the "cheap router in a PC
>box" solutions.  Reports from the field are that a "100Mbps" network 
>on which a PCI Pentium is sourcing or sinking traffic can not really expect 
>to see more than about 50Mbps due to the packet processing overhead in 
>this environment with a 1500 byte MTU -- but that number rises to nearly
>85Mbps with a 4470 MTU.  Its not moving the data that is killing the
>throughput -- its handling the encapsulation overhead.
>
The situation is a bit different if you can assume fixed size packets.
Right now, the only ones who can claim the prize for very high speed are
the cell switch makers. Perhaps by the end of the year, there will be a new
router that can compete with the best fixed length cell switch. If not, then
certainly some other folks will have a shot next year. But right now the
ATM switch makers have a clear path to OC-12 and beyond and the router folks
aren't there.

If we could just get the cell size up a bit to, say, 1500 bytes.  :-)

--Kent