David C. Walden

The ARPA network design decisions

Abstract A number of key decisions made in the design of the ARPA network over a five-year period serve as the context for an analysis of the fundamental properties and requirements of packet-switching networks and formulation of the fundamental criteria for evaluating network performance. The decisions described fall into the three major areas of network equipment design, store-and-forward subnetwork system design, and source-to-destination system design, and each decision is examined in detail.

A system for interprocess communication in a resource sharing computer network

A system of communication between processes in a time-sharing system is described and the communication system is extended so that it may be used between processes distributed throughout a computer network. The hypothetical application of the system to an existing network is discussed.

Issues in packet switching network design

The goals of this paper are to identify several of the key design choices that must be made in specifying a packetswitching network and to provide some insight in each area. Through our involvement in the design, evolution, and operation of the ARPA Network over the last five years (and our consulting in the design of several other networks), we have learned to appreciate both the opportunities and the hazards of this new technical domain.

An operational system for computer resource sharing

Users and administrators of a small computer often desire more service than it can provide. In a network environment additional services can be provided to the small computer, and in turn to the users of the small computer, by one or more other computers. An operational system for providing such “resource sharing” is described; some “fundamental principles” are abstracted from the experience gained in constructing the system; and some generalizations are suggested.

Some considerations for a high performance message-based interprocess communication system

We continue to be concerned with interprocess communications systems (such as those described in references 1, 2, and 3 and called “thin-wire” communications systems in reference 4) which are suitable for communication between processes that are not co-located in the same operating system but rather reside in different operating systems on different computers connected by a computer communications network. Further, the systems with which we are concerned are assumed to communicate using addressed messages (e.g., reference 5) which are multiplexed onto the logical communications channel between the source process and the destination process, rather than using such traditional methods as shared memory (an impossibility for distributed communicating processes) or dedicated physical communications channels between pairs of processes desiring to communicate (which is considered to be prohibitively expensive).

Reliability issues in the ARPA network

Since the inception of the ARPA Network1 in 1969, we have been part of the group responsible for the development of that networks communications subnet. This role has provided us with a unique opportunity for study of the problems of network reliability and the effects of attempted improvements, particularly in the context of rapid network growth. Our overall philosophy for this effort has been that the network should be fault-tolerant with respect to individual component errors, and that the IMPs themselves should be fault-tolerant with respect to local failures. Along with this concern, we feel that the program should provide as much diagnostic information as possible. Component failures are of several kinds: hardware or software; solid, intermittent, or one-time. As we will discuss in the following sections, our attention has shifted in the last few years from handling circuit errors and failures to handling more difficult problems in the IMPs themselves: first intermittent problems, and recently even solid failures of major components.

A note on Cheney's nonrecursive list-compacting algorithm

Cheneys list-compacting algorithm [1] goes into an infinite loop when it traces a circular list consisting exclusively of non-items. While it may be reasonable to say that such lists should not exist, it would be very difficult to legislate out of existence programs which illegally create such lists because of bugs, and it would not do for the garbage collector to break down in this instance.

Designing electronic mail systems that people will use

Physical Messages. When many system designers say electronic mall, they mean a modem equivalent for message-switching. For these people, modern electronic mall systems simulate the message-switching systems of old, station delivery is the norm, and the system is responsible for holding messages until deliverable. These systems have the great advantage of being able to replace existing systems or run in parallel with current systems without impact on the u~r. These systems focus very heavily on the location of the stations, the location of storage, and the location of sites. This is primarily the point of view of physical message delivery.

Proprietary reports on electronic mail

The rest of this issue has now been processed. Thanks to Brian Kernighan, the other contributors, and the ACM staff, the first issue reached Atlanta in time for the AFIPS Office Automation Conference--one of the best meetings I have attended in many years. Vendors complained that the sessions were too good for people to find enough time for the booths (which were very good and well staffed too). The mix of disciplines, from mftware and graph theoretic and other mathematical techniques to the mechanical engineering of bursters, the diversity of user occupations, the varied physics and chemistry of display devices, the human factors and social consequences, the legal problems and the educational demands, the high technology and the nitty gritty of optimal office arrangements and clerical support (which may have new roles created by automation) give new challenges and opportunities to interdisciplinary effort.

Applications and extensions of the TENEX operating system

The TENEX system was developed in 1969 to serve as a powerful, flexible, yet inexpensive research facility. It provides virtual memory, a hierarchy of processes within each job, a pseudointerrupt system for interprocess communication, and a highly human-engineered command language. This system has become such a popular research tool that there are (as of January 1974) 12 TENEX systems in operation. Ten of these TENEX systems are hosts on the ARPANET, a national computer resource sharing network developed by the D.O.D. Advanced Research Projects Agency.