Douglas C. Engelbart Bibliography

"Computer Network Meeting of October 9-10, 1967,"Elmer B. Shapiro, November1967. (NLS Document)
Notes by Michael Friedewald in Blue  

0 (ebsmp4) Computer Network Meeting of October 9-10, 1967

0a EBS (= Elmer B. Shapiro) 19 OCT 67

0b Distribution: 5890-1 File, DCE (=Douglas C. Engelbart), WKE (=William K. English), JFR (=Johns F. Rulifson) , Dave Brown, Bert Raphael, Stanford University

1a At the request of Larry Roberts of ARPA, meetings were held at the Pentagon, Washington, D.C., on October 9 and 10, 1967, attended by interested ARPA contractors to discuss the ARPA computer network. A list of attendees is provided in Appendix A.

1b The major topics covered in the meetings were:

1b1 communication facilities

1b2 routing procedures

1b3 network protocols

1b4 interface message processor (IMP) specifications

1b5 IMP to host computer interface

1b6 control of access to the network.

1c The SRI traffic estimates, requested in Roberts' September 22 letter, were passed to Roberts. The AHI estimate is included here as Appendix B, while the APL estimate is Appendix C.

2a Roberts explained that communication circuits should be procured under the auspices of the GSA contract with the common carriers, thereby reducing costs appreciably, compared with services obtained at normal commercial rates. It developed that full-time leased circuits for the network could well be more attractive economically than circuit switched circuits; hence the operation of the network was directed toward the leased concept.

2b Also, 50 kilobit per second transmission rates could be achieved without incurring undue cost. Roberts estimated, for instance, that a network entirely of 2400 b/s circuits would cost $33K monthly versus $107K monthly for 50 kb/s service. The overwhelming expression of the attendees was to push for 50 kb/s circuits in order to achieve short response times, even if circuit loadings were small (less than 10 percent).

2c These costs assume that, in general, each IMP would be served with 5 circuits of 2400 b/s service or 3 circuits of 50 kb/s service. The possibility was not precluded of both types of circuits serving a given IMP.

3a It is anticipated that extremely dynamic traffic routing procedures will be employed, implemented by programs in each IMP. In particular a version of the Baran (of RAND) hot potato method may he employed. The notion of the packet (an entity of 1000 bits maximum) was introduced, where a given message could be composed of many packets. The routing mechanism would deal with the packet, thus packets of the same message may traverse different routes from source to destination. The problem now arises of packets of common message arriving at their common destination out of time sequence.

3b A multiple priority scheme was still considered desirable in which at lease one priority class could preempt a circuit, thus a short message might be transmitted "through" a longer message already using the circuit, The loss of time sequence, here at the message level, can also occur.

3c The parameters, tables, etc., used by the routing schemes, might well be continually calculated at one node of the network and distributed via the network to the IMP's. Such a scheme, however, is required to permit autonomous IMP operation in case of the failure of the calculating node. Traffic statistics would be gathered by the IMP's and transmitted to the calculating node under some form of control from the latter. This control could well extend to the connection and disconnection of circuit switched circuits throughout the network.

4a The second version of the network protocol was reviewed. This protocol was concerned with IMP-to-IMP communication. The advisability of applying the ASCII standard to such communication was intensively reviewed. No firm decision evolved. Use of a transparent binary mode of operation was also investigated--in particular, a form employing an 8-bit character frame without a horizontal parity bit. Error detection depends upon two cyclic redundancy characters. The inadequacy of ASCII in this area was noted and tended to open the floodgates of criticism regarding that standard.

4b The structure of the packet header was examined. To facilitate the reordering of packets received out of time sequence, a packet number was introduced. Also, the notion of a variable length header was developed to improve the utilization of message bits. Thus, short headers could be used with short, simple messages, and long headers with long, complex ones.

5a The IMP was viewed conceptually as consisting of a network part and a host part. This partition applied particularly to the allocation of IMP core storage space. On the network side would be located programs, tables, and buffers required to support communication with the remainder of the network, regardless of the nature of the host machine. On the host side would be programs, etc., peculiar to the host installation, where such storage is inconvenient to provide in the host machine.

5b A list of proposed IMP functions was generated:

5b1 effecting traffic routing discipline

5b2 message header generation and analysis

5b3 controlling network circuit reconfiguration

5b4 controlling acknowledgments, retransmissions, and error detection

5b5 controlling I/O and interrupts with the host machine

5b6 effecting network measurement procedures

5b7 providing translation for transparent binary operation

5b8 providing a monitor to handle IMP multiprogramming

5b9 providing character code translation

5b10 controlling priorities

5b11 providing buffer space for messages, packets, and headers.

6a There was no desire to establish a standard host-IMP interface. What was proposed was the existence of a very high speed, (5 to 10 megabit per second) completely serial interface for data transfers between host and IMP. If such an interface was unsuitable for a given host, then other transfer mechanisms could be employed. The use of asynchronous control was desired.

6b On some host machines, such as the SDS940, parallel transmission might be used to pass control information, such as headers, between host and IMP.

6c The need for a "dead" electrical interface was expressed. Such an interface would allow the host or the IMP to completely ignore the other during times of system checkout and maintenance. Essentially, such an interface would not generate spurious signals during such periods.

6d No I/O devices were deemed necessary on the IMP. Programs would be entered in the IMP from the host or the network. This presented a problem regarding the reloading of an IMP program into an IMP with a cleared or garbage filled core.

6e The users of the host machine should be able to reprogram the IMP, particularly to modify the programs in the host side of the IMP core. Such reprogramming should occur infrequently. It was felt an IMP assembler, to run on one or most host machines, and not necessarily on the IMP, would suffice.

7a Since the facilities of the network are for the exclusive use of ARPA-related activities, it is essential that all host machines screen network access requests to assure that the ARPA criterion is met.

7b It became clear that each host machine will need to limit the use of its storage and processing capacity to the network users. The administrative and logical methods that can be employed need to be explored.

7c Also, there is a need for a host machine to provide a valid user access to files and programs and to deny access to an invalid user. Such requests would arrive at the host machine via the network.

7d The possibility was explored of providing a valid user access to the network from any host machine at the network. Thus, a user, normally at UCB with files there, might be able to enter the network at a BBN console and still get his UCB files, etc.

LIST OF ATTENDEES
 

G. Bell	Carnegie Institute of Technology	Attended October 10 only
A. Bhushan	Massachusetts Institute of Technology
W. Clark	Washington University, St. Louis	Attended October 10 only
G. Culler	University of California, Santa Barbara
L. Gallenson	System Development Corporation
R. Kahn	Bolt, Beranek & Newman
L. Kleinrock	University of California, Los Angeles
M. Langtry	California Institute of Technology	Attended October 9 only
H. Magnuski	Bell Telephone Laboratories	BTL is not an ARPA contractor, only an interested observer
M. Pirtle	University of California, Berkeley
L. Roberts	ARPA
E. Shapiro	Stanford Research Institute
R. Stotz	Massachusetts Institute of Technology
T. Strollo	Bolt, Beranek & Newman
B. Wessler	ARPA
F. Westervelt	University of Michigan

Appendix B

Estimated Network Traffic
Gross Guesses, Estimated for Mid 1969

From (organization): Stanford Research Institute - AHI Center

Name of individual at your location principally concerned with Network activities: Dr. D. C. Engelbart

Number of computers likely to be inter-connected at your location: 1

Number of typewriter consoles on-line to these computers: 16

Number of scope consoles on-line to these computers: 12

Total, average character rate to other network participants: 100ch/sec daytime average

Breakdown of Outgoing Network: Traffic
 

Participant	Location	% of your Network traffic
Dartmouth	Hannover NH	6
MIT	Cambridge, Mass.	8
BBN	Cambridge, Mass.	3
Harvard	Cambridge, Mass.	8
Lincoln Lab	Lexington, Mass.	4
Bell Tel Lab	Murray Hill, NJ	4
ARPA	Washington, DC	3
Carnegie	Pittsburgh, PA	6
U o Mich.	Ann Arbor, Mich.	7
U o Illinois	Urbana, Ill.	7
Washington U	St. Louis, Mo.	5
U o Utah	Salt Lake City, Ut.	5
U o Calif, Berkeley	Berkeley, CA	11
SRI	Menlo Park, CA
Stanford Univ.	Stanford, CA	7
U o Calif., Santa Barbara	Santa Barbara, CA	5
UCLA	Los Angeles, CA	5
RAND	Santa Monica CA.	3
SDC	Santa Monica CA	3

Appendix C

Estimated Network Traffic
Gross Guesses, Estimated for Mid 1969

From (organization): APL- SRI (not including SEL940)

Name of individual at your location principally concerned with Network activities: Bertram Raphael

Number of computers likely to be inter-connected at your location: 2 (940 + Linc-8)

Number of typewriter consoles on-line to these computers: 17

Number of scope consoles on-line to these computers: 1

Total, average character rate to other network participants: 5

Breakdown of Outgoing Network: Traffic
 

Participant	Location	% of your Network traffic
Dartmouth	Hannover NH
MIT	Cambridge, Mass.	10
BBN	Cambridge, Mass.	20
Harvard	Cambridge, Mass.	5
Lincoln Lab	Lexington, Mass.
Bell Tel Lab	Murray Hill, NJ	5
ARPA	Washington, DC	10
Carnegie	Pittsburgh, PA	5
U o Mich.	Ann Arbor, Mich.
U o Illinois	Urbana, Ill.
Washington U	St. Louis, Mo.
U o Utah	Salt Lake City, Ut.
U o Calif, Berkeley	Berkeley, CA	20
SRI	Menlo Park, CA
Stanford Univ.	Stanford, CA	20
U o Calif., Santa Barbara	Santa Barbara, CA
UCLA	Los Angeles, CA
RAND	Santa Monica CA.
SDC	Santa Monica CA	5

Michael Friedewald, November 1997