Network Meeting Report

This is a report on a series of three Network Working Group meetings at

the Fall Joint Computer Conference, November 16, 17 and 18 in Houston,

Texas. The meeting will be lumped together and ideas may or may not be

identified as to their originator. The meetings were chaired by Steve

Crocker.

The meetings began with a listing of topics of concern.

1) A site or group should be designated as protocol testers. As NCP's

are implemented they should be subjected to comprehensive testing by an independent group.

2) The Host-Host protocol needs reworking in several areas: error

control, overload conditions, allocation of resources, status information, and system crash problems.

3) The immediate need for specification of TELNET, the third level

program which allows people to pass through their local hosts and use remote hosts. TELNET must provide facilities to log in at a distant site, run programs, transmit files, and call for help. This call for help is likely to mean getting a systems programmer at the remote site "taking control" of the user console.

4) The documentation of systems on the network must become available to

all sites. This is to be done by the NIC with the cooperation of the other sites. Particularly useful will be on-line documentation. It is suggested that each site have an identical hard copy device (e.g. a line printer) suitable for reproducing documents.

5) The use of graphics consoles on the network will require a graphics

protocol. People interested in this problem should write position papers on such a protocol. A meeting may be held between the authors of such papers if sufficient interest develops. The papers should be distributed as NWG/RFC's before 1 January 71.

6) Some sites must account for use of their computer resources, thus

there must be some network accounting scheme. Sites can be categorized as Research Centers vs. Service Centers. The Service centers tend to have big machines, lots of users, and accounting problems; while the Research Centers tend to have specialized hardware, a small number of users, and no accounting at all.

---

Page 2

7) Some people are interested in the network as an object of study. In

particular UCLA-Computer Science, and BBN wish to perform measurements on the network. Is it appropriate to ask the NCP to keep statistics?

After this opening some discussion followed.

It was generally felt that changes to the protocol should be made in

bunches and at about six-month intervals rather than a continuous stream

of small changes. Also that a lead time of three months was not over

optimistic. The proposed change to the IMP-Host protocol to get rid of

marking was generally approved but it will not be implemented for some

time since casual changes to the protocol are undesirable. Tom

O'Sullivan suggested that perhaps new and old protocols could work

together, that is the new protocol would support the old one as well as

provide better mechanisms where possible. Steve Crocker suggested that

a new protocol might be developed as a private experimental protocol

between two or three sites.

It was stressed that it is necessary that the network be used to gain

experience, and that we should get teletype-like console use of remote

systems going before we get too involved in graphics. Perhaps the

graphics protocol should be developed by a different set of people. The

scheduling of a graphics protocol meeting was thus discouraged, but

papers should still be written. Strong feelings were expressed in

favour of first developing use of remote subsystems and file

transmission instead of worrying about graphics at this stage. It was

suggested that development of protocols at the higher levels be driven

by applications.

Documentation will be a major concern for network users. Several people

mentioned that users at their sites have already begun to inquire about

the network. As Eric Harslem put it "What does the ARPA Network have to

offer?" Some sites (Multics, SRI) keep system documentation on-line.

It was suggested that the trillion bit store be used to keep on-line

documentation of all systems.

At this point Doug Engelbart gave a presentation on the Network

Information Center (NIC). The goals or services of NIC have not been

well defined by anyone and have been left up to NIC to define. NIC has

decided that one urgent task is to make information about the network

and the host systems on the network available to users of the network.

Doug has found that some people feel threatened by the revelation of

their documentation inadequacy. Doug's project at SRI has built up a

system that allows the user to create catalogs and indices into a

collection of information. The system has a master catalog of all

information files. Each user may have a number of private (or shared)

catalogs. The system provides a means of examining on-line the catalogs

---

Page 3

and amending them. The system also provides a means to examine any

information file which happens to be on-line and for creating new

information files on-line.

Several problems will delay the NIC from coming on the network. One of

these is the switch from the XDS-940 to the PDP-10 (TENEX). The switch

is being made because the 940 system is inadequate to handle the

anticipated load. At first it was planned to offer service on the 940

and switch to the 10 when it came up, but too much effort would be

required for a very small payoff.

Doug explained the working of the Network Dialoge System. At each site

there is a communication agent and a technical liaison officer. The

agents will be trained by NIC to use the facilities of NIC to get

information about the Network and other sites. The agents will acquire

from NIC documents of interest to users at the local site, be able to

contact NIC at a toll free number, and should have an on-line console

into the network (and therefore NIC). Thus the Network Dialoge System

is a network of people (the agents).

Steve Crocker then brought us up to date on the status of the network.

He drew a picture of what is connected and what is proposed. He

discussed the level of implementation at various sites. Eric Harslem

mentioned that RAND and UCSB had conducted tests of their NCP

implementations last week (10 Nov 70) and that things worked well.

Frank Heart announced that BBN was planning the development of a

"Terminal" IMP. The Terminal IMP would support some large number of a

wide range of consoles as well as provide the normal IMP functions.

At this point we broke and scheduled to reconvene Tuesday morning.

The Tuesday meeting started with Doug giving another pass at explaining

the SRI system at a more detailed level. The basic thing to deal with

is the collection. The user can query over the collection or over sub

collections. The user can obtain bibliographic references of three

kinds: a) full references, b) first line, c) author indexed.

Information files of the collection may be on-line, in tape libraries,

or only in hard copy. It is suggested that much data could be kept at

other network sites, for example the trillion bit store and before that

perhaps on disk at UCSB. If files are kept at other sites then the

system must be able to retrieve them automatically when they are

requested. The subsystem to be used is called TODAS. TODAS is an

evolving program and the documentation of TODAS is inadequate. In

TODAS, file are organized hierarchically, each paragraph is numbered,

and it is possible to do context analysis on the text.

---

Page 4

Doug then mentioned some things about the console interaction. This

raised a question about half vs. full duplex and line oriented vs.

character oriented systems. The remainder of the meeting revolved

around this issue.

I shall try to define the terms as I understand them for purpose of

clarity in the following. Half duplex is the situation where the

console, a peripheral processor or some very low level software, echos

the character entered. The console can not be used to input data while

output is in progress. Full duplex is the situation where the character

typed is echoed by software, and input can be done at the same time as

output. In line oriented systems the user enters a complete line

terminated by an extra sensitive and of line character (e.g. carriage

return). Often the keyboard is then locked until after the next output.

In character oriented systems each character the user enters is

interpreted by software before it is echoed and the echo may be

different from the character entered. In particular after a few

character the software may guess what the user wants and complete the

line for him. The following chart will be used for clarity.

              | Half Duplex |  Full Duplex

______________|_____________|_____________
              |             |
Character     |             |
   Oriented   |   type1     |    type2
              |             |

______________|_____________|_____________
              |             |
Line          |             |
  Oriented    |   type3     |    type4
              |             |

______________|_____________|_____________

It was discovered that many people don't really know where their own

systems fit in this chart and are very vague about what it means to

interact with a system in a different than their own. Doug stated that

NIC has a system of type 2 but would try to provide service to all types

of systems. The following table shows systems with their interaction

type and categorization as to Research vs. Service Center.

---

Page 5

System Interaction Type Categorization

UCLA - Sigma-7 2 - char, full Research

UCLA - 360/91 3 - line, half Service

MIT - Multics 3 - line, half Service

SDC 3 - line, half ?

RAND 3 or 4 - line, ? ?

SRI 2 - char, full ?

Al Vezza promised to study this problem and to circulate his results as

an NWG/RFC. It was pointed out that line oriented systems usually allow

line editing of the form "delete last character" (back space) and

"delete line", however this feature does not alter their classification

as to interaction type. Concern arose over what do line oriented

systems expect to receive from the network for a connection acting as

console input to a subsystem. Steve Crocker made the suggestion that

when using a line oriented system transmission be in lines. More

precisely that transmission be in strings of the following form.

n c1 c2 ...cn

where 1 <= n <= 120 (n is eight bits)

and if ci is an "end of line" character then i = n

This suggestion was not immediately accepted and some discussion took

place regarding the significance of Host-Imp-Host message boundaries.

Doug brought up file transmission and the problem of finding the end of

the file, which provoked more discussion. At this point the meeting

broke up with a third session scheduled for 8:00 p.m. Wednesday evening.

The Wednesday meeting began with the suggestion that at future xJCC's

there be an official ARPA Network hotel with a block of rooms on one

floor and a nearby meeting room for networkers. This suggestion was

favored by all.

Steve Crocker asked how people felt about these meetings. The general

feeling was that the meetings were very useful and should occur about 3

months apart. Al Vezza pointed out that meetings this size (15 - 30

people) are good for bringing up problems but not for putting them down.

Steve proposed that 3 or 4 people be designated to solve particular

problems. Al responded that 3 people can't legislate. That any such

---

Page 6

solution must be considered in the same way as a proposal by an

individual.

Steve persuaded Peggy Karp to act as NWG/RFC editor. This is a job

independent of cataloging RFC's or assigning numbers (functions now

performed by NIC). The RFC editor will only categorize RFC as "hot

issues", current, out of date, or superseded.

The subject of Logger protocol -- that is, how to get the first

connection -- needs to be officially defined. NWG/RFC #66 suggests one

way. Eric Harslem will revise this and send it out as proposed official

protocol. Ed Myer will also send out a proposal.

Steve then opened up discussion of the topics of the previous meeting by

suggesting we talk about the following: Message boundaries, half duplex

vs. ull duplex, line oriented vs. character oriented, file

transmission, byte counts in messages, byte sizes and transactional

units. It was proposed that transactions on the command link (i.e.

between NCP's) be always in multiples of eight bits. This mean that the

length field in the ECO, ERP, and ERR commands will always have three

low order zeroes. This was approved. Steve then proposed that

connections could be established with a declared byte size and a maximum

record length in bytes. Transactional units on this type of connection

would be of the form

n c1 c2 c3 ... cn

where 0 <= n <= max record length

if n = 0 then the transactional unit acts like a semaphore. Steve

suggested that we should look into the theory of information exchange,

particularly along the lines of Richard Kaline (NWG/RFC #60). Perhaps

for each information unit sent there should be some status response.

The next question was on file transmission. In particular, how do you

find the end? Frank Heart suggested that with each portion there be a

flag indicating "this is not the end" until in the last portion the flag

is switched to indicate "this is the end". Eric Harslem suggested that

each portion should have an "opcode" field, a length field, and the text

which is length bits (bytes?) long. This appears to be like the data

types proposed at the Lincoln Lab meeting last spring. Ed Myer proposed

that two connections be used, one for the file transmission and the

other to control it. The file control connection would specify the data

connection and indicate that transmission as about to start. After the

sender had completed the file transmission he would send on the file

control link the total number of bits sent. The receiver would then

know how many bits to receive and exactly where the end of the file

should be. Bob Metcalfe was concerned that some of the proposals mixed

---

Page 7

control information with data and felt that perhaps this mixing should

be avoided.

Steve asked if anybody could suggest an advisor we might talk about

these problems. Bob Metcalfe suggested Anatol Holt. Bob Sundberg

suggested George Mealy. Eric Harslem and Peggy Karp suggested that

people who worked on the COIN System might be helpful. Frank Heart

suggested that no one has solved these problems.

Steve proposed that Service Centers offer line oriented interaction with

no echoing of the input. Any simple editing (e.g. back space) would be

done at the using site. Ed Meyer suggested that there be official

protocols for both line oriented and character oriented interaction.

Steve promised to write a NWG/RFC clarifying the issues and laying out

the arguments on full transactions, byte counts, and accumulating data

on the receive side.

It was felt that these were hard problems that needed more thought.

Thus the meeting was adjourned with the request that people circulate

any ideas or proposals as NWG/RFC's. Ed Myer took notes and agreed to

also prepare a NWG/RFC summarizing these meetings.

---

Page 8

Network Meeting Attendance List 16 - 18 Nov. 70 Houston

Name Site Sessions

 1. Dick Benjamin          MITRE                      1

  Jack Bouknight         Illinois - CAC             1,2


  Al Cocanower           MERIT                      1,3


  Steve Crocker          UCLA - SPADE               1,2,3


  Doug Engelbart         SRI - ARC                  1,2,3


  Wayne Fischer          MERIT                      3


  Richard Greenblatt     MIT - AI                   1


  Eric Harslem           RAND                       1,2,3


  Frank Heart            BBN                        1,2,3

10 Allen Joseph ORNL 1

11 Peggy Karp MITRE 1,2,3

12 William Kehl UCLA - CCN 1

13 Bob Long SDC 1,2,3

14 Jim Madden Illinois - CAC 1,2

15 Bob Metcalfe MIT - DM 1,3

16 Edwin Myer MIT Multics 1,2,3

17 Ari Ollikainen UCLA - SPADE 1,2,3

18 Tom O'Sullivan Raytheon 1,2,3

19 Jon Postel UCLA - SPADE 1,2,3

20 Chris Reeve MIT - DM 1,3

---

Page 9

Network Meeting Attendance List 16 - 18 Nov. 70 Houston

Name Site Sessions

21 Tijaart Schipper UCLA - CCN 1

22 Michael Sher Illinois - CAC 1

23 Bob Sundberg Harvard 1,2,3

24 Hal Van Zoeren CMU 1,2,3

25 Albert Vezza MIT - DM 1,2,3

26 Alfred Vorhaus MITRE 1

27 Clark Weissman SDC 1

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Gottfried Janik 02/98 ]

---