1 O (ebsmp4) Computer Network Meeting of October 910, 1967
Oa ERS I9 OCT 67
Ob Distribution: 58901 File, DCE, WKE, JFR, Dave Brown, Bert Raphael, Stanford University
1 Introduction
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.
2 Communication Facilities
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 fulltime 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 o£ 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.
3 Routing Procedures
3a It is anticipated that extremely dynamic traffic routing procedures will
2 be employed, implemented by programs in each IMP. In particular a version of the Baran (of RAND) hot potato method may be 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.
4 Network Protocols
4a The second version of the network protocol was reviewed. This protocol was concerned with IMPtoIMP 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 investigatedin particular, a form employing an 8bit 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 hits. Thus, short headers could be used with short, simple messages, and long headers with long, complex ones.
5 IMP Specifications
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
3 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.
6 IMP to Host Computer Interface
6a There was no desire to establish a standard hostIMP 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 SDS 940, 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.
7 Network Access
7a Since the facilities of the network are for the exclusive use of ARPArelated 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.
4 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.
Appendix A
LIST OF ATTENDEES
G. Bell [1] Carnegie Institute of Technology
A. Bhushan Massachusetts Institute of Technology
W. Clark [1] Washington University, St. Louis
G. Culler University of California, Santa Barbara
L. Gallenson System Development Corporation
Kahn Bolt, Beranek & Newman
L. Kleinrock University of California, Los Angeles
M. Langtry [2] California Institute of Technology
H. Magnuski [3] Bell Telephone Laboratories
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
[1] Attended October 10 only [2] Attended October 9 only [3] BTL is not an ARPA contractor, only an interested observer
APPENDIX B
ARPA 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 interconnected at your location: 1
Number of typewriter consoles online to these computers: 16
Number of Scope consoles online to these computers: 12
Total, average character rate to other network participants: 100 ch/sec daytime average
Breakdown of Outgoing Network Traffic
Participant Location % of your Network Traffic
Dartmouth Hanover, N.H. 6 MIT Cambridge, Mass. 8 BBN Cambridge, Mass. 3 Harvard Cambridge, Mass. 8 Lincoln Lab Lexington, Mass. 4 Bell Tel Lab Murray Hill, N.J. 4 ARPA Washington, D.C. 3 Carnegie Pittsburgh, Pa. 6 Univ. of Mich. Ann Arbor, Mich. 7 Univ. of Illinois Urbana, Ill. 7 Washington, Univ. St. Louis, Mo. 5 Univ. of Utah Salt Lake City, Utah 5 U of Calif. Berkeley, Calif. 11 Berkeley SRI Menlo Park, Calif. Stanford Univ. Stanford, Calif. 7 Univ. of Calif. Santa Barbara, Calif. 5 Santa Barbara UCLA Los Angeles, Calif. 5 RAND Santa Monica, Calif. 3 SDC Santa Monica, Calif. 3
Appendix C
ARPA Network Traffic Gross Guesses, Estimated for Mid 1969
From (organization):[handwritten] APL-SRI (Not including SEL 940)
Name of individual at your location principally concerned with Network activities: [handwritten] Betram Raphael
Number of computers likely to be interconnected at your location: [handwritten] 2 (940 + Linc-8)
Number of typewriter consoles online to these computers: [handwritten] 17
Number of Scope consoles online to these computers: [handwritten] 1
Total, average character rate to other network participants: [handwritten] 5
Breakdown of Outgoing Network Traffic
Participant Location % of your Network Traffic
Dartmouth Hanover, N.H. MIT Cambridge, Mass. 10 BBN Cambridge, Mass. 20 Harvard Cambridge, Mass. 5 Lincoln Lab Lexington, Mass. Bell Tel Lab Murray Hill, N.J. 5 ARPA Washington, D.C. 10 Carnegie Pittsburgh, Pa. 5 Univ. of Mich. Ann Arbor, Mich. Univ. of Illinois Urbana, Ill. Washington, Univ. St. Louis, Mo. Univ. of Utah Salt Lake City, Utah U of Calif, Berkeley Berkeley, Calif. 20 SRI Menlo Park, Calif. Stanford Univ. Stanford, Calif. 20 Univ of Calif, Santa Santa Barbara, Calif. Barbara UCLA Los Angeles, Calif. RAND Santa Monica, Calif. SDC Santa Monica, Calif. 5
STANFORD RESEARCH INSTITUTE
To: M. Pirtle, University of California/Berkeley S. Russell, Stanford University From: E. Shapiro, SRI
Subject: Meeting with Western Union
Date: June 1, 1967
Location:
Answering:
I met with two Western Union representatives on May 24th to explore Bay Area communication aspects of the ARPA Computer Network. Attached to this note are copies of some of the material they left with me.
Colter and Miller (see page 1 of the attached material) did not seem fully informed of WU's present or future communication offerings.
Page 3 provides the "dialup" charges for 2kc and 4kc service; note (page 2) that the minimum charge per connection is that of one minute. After the initial minute, charges accrue in onetenth minute increments. No 48kc charge schedule is available.
The Automatic Calling Unit Type 12405A is a very new item (note the handwritten entry). No other information is available regarding this unit.
The 2400 baud, synchronous unit is the Western Electric Data Set Model No. 201B. WU data sets for Schedule II circuits cannot be used on Schedule I circuits.
The leftmost two columns of page 4 are now served by Schedules I and II service. In the near future (perhaps within a year), the remaining cities will also be served. If your terminal is outside such a city you are obligated to pay Circuit Extension charges (page 3), measured from the city limits of the served city. When demand in an area is sufficiently great, WU can install concentrators, thus reducing the customer's charges.
The seven cities marked with a star, all in the leftmost, are to have dialup 48kc service at some distant future date. This service will allow simultaneous 40.8 kb/s data and voice traffic on the same circuit. It is expected that the Western Electric Data Set, Model 301B, will be used here.
Colter and Miller offered to talk with any and all of us to answer, as best they can, any questions we may have. They estimate that 60day delivery of Schedule II service, w ith Automatic Answering and Automatic Calling units, is possible. (I wonder!)
I am checking with Pacific Telephone regarding leased circuits in California, considering the Bay Area and links to the Los Angeles area. It is not too difficult to establish traffic sensitive breakpoints for determining switched versus leased service.
0 ARPA Computer Network Meeting of May 18, 1967
0a E. B. Shapiro 25 MAY 67
Ob Distribution: 58901 File, Engelbart, English, Rulifson, Shapiro
1 The meeting was held at the Pentagon, convening at 10:30 a.m. and adjourning at 4:30 p.m. L. Roberts of ARPA chaired the session attended by:
1a A. Oettinger, Harvard 1b L. Kleinrock, UCLA 1c F. Westervelt, University of Michigan 1d G. Bell, Carnegie 1e R. Mills, Project MAC 1f J. Licklider, Project INTREX 1g M. Pirtle, UC, Berkeley 1h S. Russell, Stanford University 1i E. Shapiro, SRI 1j E. Pearson, BTL (observer) 1k H. Maguski, BTL (observer) 1l M. Langtry, CIT 1m R. Taylor, ARPA (part time) 1n L. Roberts, ARPA
2 Conventions and technical problems of the network were discussed; Westervelt's proposed "standard" of May 12, 1967, and W. Clark's message switching proposal (appended to Taylor's letter of April 24, 1967 to Engelbart)were reviewed. The group accepted the following notions:
2a The bit streams exchanged between network centers would use the 8bit ASCII frame. When text was being transferred, the ASCII code would be observed. When "binary" information was being transferred, special procedures, compatible with ASCII, would cause the data to be handled in 6bit units; these 6 bits would be part of the 8bit frame.
2b All centers should have a "dialup" capability and operate the communication channels in a full duplex mode. The preferred data rate is 2400 bits per second. Western Union may be preferred as the network carrier for this service.
2c The maximum block length may be limited to 256 characters.
2d The notion of a communication processor to couple a CPU to the network was viewed as a reasonable approach. Store and forward operation by the network may be used.
3 The environment created by these four notions made it necessary to extensively revise Westervelt's proposed "standard." Such a revision, indeed an expansion of that document, is to be undertaken by Westervelt and Mills. The revised work will be submitted to the group for review.
4 It was emphasized by Roberts that we were dealing with "conventions" not standards, and the contractors could still make special arrangements among themselves where the need is indicated.For instance, fulltime leased circuits (in addition to the basic dialup facilities) are possible.
5 Consideration of traffic showed that we were all very uncertain as to the potential volumes.
6 Roberts is considering contracting the entire network job (communication processor specification, procurement, programming and installation, network design, establishment and operation) to a single contract of(ARPA or nonARPA). He requested comments on this notion.
|
  |