[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Louis Breit
Expires: July 22,1997
January 22, 1997

            Network Tuning for Efficiency and Throughput

Status of this Memo

This document is an Internet Draft.  Internet Drafts are working documents of
the Internet Engineering Task Force IETF), its Areas, and its Working Groups.
Note that other groups may also distribute working documents as Internet Drafts.

Internet Drafts are draft documents valid for a maximum of six
months.  Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time.  It is not appropriate to use Internet Drafts as
reference material or to cite them other than as a "working draft" or "work in

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the internet-drafts Shadow Directories

ftp.is.co.za (Africa)
nic.nordu.net (Europe)
ds.internic.net (US East Coast)
ftp.isi.edu (US West Coast)
munnari.oz.au (Pacific Rim)


Network tuning is usually performed after the network design is completed, but
should also be done at intervals during the life cycle of the network.  There
are four basic areas that directly affect the efficiency of the network and its
associated throughput:

Frame and packet size optimization
Segmentation avoidance or limitation
Minimization of device delay
Window sizing to avoid degradation

This draft has been written to document for the internet community a basic
overview of network tuning and its benefits.


Much of this memo is taken from my personal experience in designing and
analyzing local and wide area networks.

I would also like to extend my appreciation to my colleagues at work for their
time and assistance; without their daily contributions, none of the knowledge
we have gathered together could be applied as effectively as it has been.

Basic Network Tuning

1.  Frame and Packet Size

In all packet switched networks, packet or frame size has a direct effect on
overhead and throughput.  Smaller packets (each containing a small amount of
data) have more overhead than larger ones, since the ratio of overhead (header
and control information, etc. - which tend to be fixed in size) is
proportionally higher to the amount of data passed. As a result, the data
throughput of the line decreases (throughput being defined as the quantity of
data a user can pass across a given circuit or device).  However, small packets
have a reduced chance of retransmission, better response time, and are less
likely to contain errors.

Larger packet sizes have a better ratio of overhead to data, which increases
throughput.  However, buffer and transmission delays and the resulting
retransmissions can act to degrade throughput.

This leads us to the "U" curve, where throughput increases as packet size
increases but then begins to degrade.  The ideal packet size is at the crest of
the inverted "U".  For example, an IP network suffers from low throughput with
very small packet sizes, but will also degrade when packet sizes are too large
(due to segmentation).  The goal is to increase packet size to just below the
point where segmentation is needed, and increase buffers accordingly to
compensate for transmission delays.

This will vary by packet service; in networks where each node must read an
entire frame before transmission (frame relay, etc.), very large packets should
be avoided.  As always, the best approach is to "try and tune"; my suggestion
is to begin with a packet size of 1500 bytes and assess performance as it is
increased and decreased.

2. Segmentation

Segmentation should be avoided at all points in the network to increase
throughput. Keep in mind that when IP addressing is used on higher level
application protocols, file sizes can exceed the maximum data unit size
permitted by IP.  Fragmentation or the cutting of single files into multiple
packets results in additional overhead.  Ethernet, with an MTU of approx. 1500
bytes is similar to IP.  However, applications which routinely generate large
packets (NFS, etc.) can create delays.  If possible, set higher level protocols
to limit their packet size to what is supported at the network (IP) layer.

3. Delay

When vendors rate the PPS (or packets per second) supported by a specific
device, they often do so using the minimum packet size to increase throughput.
Whenever data is passed at a lower PPS than what is supported on the device,
throughput is reduced by the difference.  For example, if data is passed at
10,000 PPS through a device which offers a PPS of 20,000 PPS, the amount of
overhead is 50%.  Larger packet sizes will tend to account for some of the
difference, but an attempt should be made to match the rated PPS as closely as
possible for the appropriate packet size. If a packet size of 1500 bytes is
ideal for the network, then the PPS rating of the device using 1500 byte
packets should be the goal.

4. Windowing

Window sizes can be tuned within each node of a packet switched network, or
within TCP (at the user access point).  The window size can be increased on
reliable networks and decreased on error prone lines in a packet switched node
(X.25, etc.).  TCP will dynamically adjust its window size based on
throughput.  By examining the trending in window size, network performance
problems can be isolated and additional capacity added where needed.

It is important to note that window size should never be manually increased as
a means to boost performance until a thorough study is done of hardware
buffers, memory etc.  Larger windows consume more resources.

Author's  Address:

Louis Breit
34 Shadow Lane
Staten Island, NY 10306

Phone: 718-983-8472

EMail: louis_breit@jh.com

Expires: July 22, 1997