Browse Prior Art Database

Modularity and efficiency in protocol implementation (RFC0817)

IP.com Disclosure Number: IPCOM000003866D
Original Publication Date: 1982-Jul-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 24 page(s) / 46K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D.D. Clark: AUTHOR

Abstract

Many protocol implementers have made the unpleasant discovery that

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 7% of the total text.

RFC: 817

MODULARITY AND EFFICIENCY IN PROTOCOL IMPLEMENTATION

David D. Clark

MIT Laboratory for Computer Science

Computer Systems and Communications Group

July, 1982

1. Introduction

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

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 ...