Modularity and efficiency in protocol implementation (RFC0817)
Original Publication Date: 1982-Jul-01
Included in the Prior Art Database: 2019-Feb-14
Internet Society Requests For Comment (RFCs)
This RFC will discuss some of the commonly encountered reasons why protocol implementations seem to run slowly.
MODULARITY AND EFFICIENCY IN PROTOCOL IMPLEMENTATION
David D. Clark MIT Laboratory for Computer Science Computer Systems and Communications Group July, 1982
Many protocol implementers have made the unpleasant discovery that
their packages do not run quite as fast as they had hoped. The blame
for this widely observed problem has been attributed to a variety of
causes, ranging from details in the design of the protocol to the
underlying structure of the host operating system. This RFC will
discuss some of the commonly encountered reasons why protocol
implementations seem to run slowly.
Experience suggests that one of the most important factors in
determining the performance of an implementation is the manner in which
that implementation is modularized and integrated into the host
operating system. For this reason, it is useful to discuss the question
of how an implementation is structured at the same time that we consider
how it will perform. In fact, this RFC will argue that modularity is
one of the chief villains in attempting to obtain good performance, so
that the designer is faced with a delicate and inevitable tradeoff
between good structure and good performance. Further, the single factor
which most strongly determines how well this conflict can be resolved is
not the protocol but the operating system.
2. Efficiency Considerations
There are many aspects to efficiency. One aspect is sending data
at minimum transmission cost, which is a critical aspect of common
carrier communications, if not in local area network communications.
Another aspect is sending data at a high rate, which may not be possible
at all if the net is very slow, but which may be the one central design
constraint when taking advantage of a local net with high raw bandwidth.
The final consideration is doing the above with minimum expenditure of
computer resources. This last may be necessary to achieve high speed,
but in the case of the slow net may be important only in that the
resources used up, for example cpu cycles, are costly or otherwise
needed. It is worth pointing out that these different goals often
conflict; for example it is often possible to trade off efficient use of
the computer against efficient use of the network. Thus, there may be
no such thing as a successful general purpose protocol implementation.
The simplest measure of performance is throughput, measured in bits
per second. It is worth doing a few simple computations in order to get
a feeling for the magnitude of the problems involved. Assume that data
is being sent from one machine to another in packets of 576 bytes, the
maximum generally acceptable internet packet size. Allowing for header
overhead, this packet size permits 4288 bits in each packet. If a
useful throughput of 10,000 bits per second is desired, then a data
bearing packet must leave the sending host about every 430 milliseconds,
a little over two per second. This is clearly not difficult to achieve.