TXT

rfc101

By Evelyn Griffin,2014-10-18 15:36
7 views 0
rfc101

    Network Working Group Richard W. Watson Request for Comments: 101 SRI-ARC NIC: 5762 February 23, 1971

     NOTES ON THE NETWORK WORKING GROUP MEETING

Wednesday Evening, February 17

     Mike Sher opened by welcoming the group to Urbana and briefly

     indicated that ILLIAC IV was expected to be running this summer. The

     ILLIAC IV Project has been split into two projects; one on basic

     system hardware and software, and the other on applications. Their

     IMP is not yet connected to their PDP-11.

     Steve Crocker asked for topics to be discussed at this meeting; these

     are indicated below.

     Peggy Karp of Mitre has been summarizing the old RFC's. She has a

     list of about 30 topics and is summarizing their present status. She

     expects to finish around the end of February. See RFC #100,

     NIC(5761). It was suggested that someone write an RFC indicating

     which ones are obsolete. It was also suggested that the Network

     Information Center (NIC) help sites in organizing their hardcopy

     material.

     There then followed brief discussions of experiences in using the

     Network. John Melvin (SRI-ARC) summarized SRI's experience in using

     the Utah PDP-10 to help in SRI's transfer from an XDS 940 to a PDP-

     10. In April-May 1970 it was clear that SRI was headed toward a

     PDP-10 in order to have the capacity and reliability to fulfill their

     role as the Network Information Center. They had had some previous

     experience in connecting with Utah, and so it seemed logical to try

     to use the Utah 10 to aid the transfer.

     In June use of the Network began. SRI uses higher level languages

     extensively, so the first task was to transfer the compiler-

     compiler Tree Meta. Source code was generated on the 940 to run

     on the PDP-10. Binaries were then transmitted to Utah and run

and

     debugged. Patches were performed where possible, and source

     changes accumulated. A new source and binaries would then be made

     periodically.

    Watson [Page 1]

    RFC 101 NOTES ON THE NETWORK WORKING GROUP MEETING February 1971

     Once Tree Meta was running, a new high level language (called L-

     10) for programming the On-Line System (NLS) was implemented in

     the same way. When L-10 was running the core device independent

     parts of NLS were rewritten and debugged. NLS was completely

     reorganized during the transfer.

     At the SRI and Utah ends a control program allowing three users to

     connect to Utah was written, which ran as a user process and

     allowed character interaction and files to be transmitted. The

     scheme worked well and much useful work was accomplished in the

     July--December period with some people on 4-5 hours per day. The

     voice link was used when something would go wrong in trying to

     determine where the problem existed and to reset. At times they

     would go 2 weeks with no problems. SRI has an IMP interface

     diagnostic which ran as a T/S process.

     Generally, echoing was handled at the SRI end. DDT was used at

     Utah end. Round trip character delays of 4 seconds were not

     uncommon, and at certain points delays of 8 or 10 minutes were

     experienced. These delays were the result of the implementation

     used which involved multiple processes at each end, each to be

     scheduled. Utah was heavily loaded at 2:00 PM and the SRI people

     took to running at night and on weekends.

     When the SRI PDP-10 came in in December, use of the Network

     slowed.

     Users would have liked a more constant response time instead of

     the widely varying one so that their work habits could adapt to it

     even if it was slow.

     Gerry Cole reported on some results of measurements made during the

     SRI-Utah work. Measurements were also made at SRI to help in

     interpreting the data obtained by UCLA. Gerry wrote a paper

     summarizing these statistics which is available from him care of SDC.

     Gerry requested that when people are set up to use the Network,

     they inform him so that he can gather statistics. UCLA will

     eventually have a program to scan the Network for utilization,

but

     if people could tell him when they were going to use the Network,

     it would be easier to measure meaningful things and interpret the

     data from a knowledge of type of usage.

     Bob Kahn indicated that BBN is interested in the Statistics on

     overall flow to see if the Network is configured properly. Gerry

     said that UCLA is interested in the statistics for Network modeling

     studies. Measurements are taken by remote control by use of a

     feature designed into the IMP's by BBN for such a function.

    Watson [Page 2]

    RFC 101 NOTES ON THE NETWORK WORKING GROUP MEETING February 1971

     Jim White of UCSB said that UCSB and RAND had begun to experiment in

     use of the Network for the climate study at RAND. The UCSB NCP has

     been up the last 3 or 4 weeks during the day. A document, NIC (5480)

     is available in the NIC collection describing it. UCSB is also using

     their NCP for local interprocess communication experiments. RAND is

     using the Remote Job Entry facility of the UCSB 360-75. They are

     using UCSB to check out their NCP. Now that UCSB is running their

     NCP during normal usage hours, they have uncovered some bugs in their

     hardware interface to their IMP. The software at both UCSB and RAND

     seems to be working. Typical jobs being sent back and forth are just

     test jobs of a few source statements. The UCSB NCP is about 39K

     bytes and runs in a 60K byte partition. Users access it through

     assembly language, Fortran or PL/I calls.

     Steve Crocker now returned to the discussion of the agenda for the

     meeting and longer range organization of the NWG. Steve felt that

     Working committees on various topics were required as the open

     meeting was good for bringing up problems, general discussion and

     education, but was too large to prepare detailed specifications on

     various topics.

     The following topics requiring work were listed:

     1. Graphics

     2. Data Transformation Languages

     3. Host-Host Protocol -- long range study

     4. Host-Host Protocol -- Short term maintenance and modifications

     5. Accounting

     6. Logger Protocol

     7. Typewriter connection protocol

     8. Documentation

     9. Data Management

     In #1 Al Vezza of MIT is organizing an NWG meeting in graphics April

     25-27 which can accommodate 31 people. People desiring to come

     should prepare for their institution a working paper. Al sees three

     classes of problems:

     i) two hosts, each with computing and graphics facilities,

     wanting to use special facilities at the other

    Watson [Page 3]

    RFC 101 NOTES ON THE NETWORK WORKING GROUP MEETING February 1971

     ii) one host with graphic facilities but no number crunching

     facilities wanting to use computing capabilities of a second host

     iii) a node with a graphic terminal not having picture processing

     or computing capability desiring to obtain these from other nodes.

     With respect to #2 John Heafner of RAND indicated RAND wants to

     provide data rearrangement services of the type indicated in RFC #83,

     NIC (5621). More on this topic below.

     With respect to #3 a group under A. N. Habermann of CMU has been

     formed to look at the Host-Host protocol. Toward the end of March

     they are planning a paper discussing their ideas. The group consists

     of:

     A. N. Habermann, CMU

     G. B. Hansen, CMU

     W. Wulf, CMU

     R. Chen, CMU

     R. Kalin, Lincoln Lab

     The group welcomes suggestions of topics.

     With respect to #4 a group is to be set up to evaluate present

     protocol and produce needed changes to the protocol. The group is to

     be conservative and produce only changes needed to solve known

     problems and leave esthetic changes until later.

     With respect to the other problems discussion was put off until later

     (see below).

     Two people interested in the Network who were observers at the

     meeting spoke briefly.

     C. D. (Terry) Shepard of the Computer Communication Task Force,

     Canadian Government, outlined the goals of his group. These goals

     are:

     1) establish a plan to link up various Canadian computers and

     establish a network

     2) develop what the needs of Canada are for such a network

    Watson [Page 4]

    RFC 101 NOTES ON THE NETWORK WORKING GROUP MEETING February 1971

     3) see that the benefits of such a network are distributed

     throughout Canada

     4) prevent control of computing in Canada from being totally

     dependent on foreign sources.

     5) see that critical computer facilities exist in Canada.

     Doug McKay of IBM then described briefly a network project started

     in IBM about 2 years ago. Basic network is completed. Users are

     coming on. The network is to be used heavily to send files back

     and forth for program updating. IBM is trying to look at the

     network as a multiprocessor machine. They are trying to handle

     all IBM system possibly heterogeneous such as 360's, 370's, CP '

     67, the 91, a 44, and a NYU CDC 6600.

     There is another project linking TSS systems using a 91 for remote

     job entry. IBM has taken a centralized control point of view

     using one central machine for control and flow distribution. They

     are not entirely happy with this approach and are moving toward a

     more decentralized approach like the ARPA Network. IBM presently

     has about 14 people involved in the project.

Thursday morning, February 18

     Thursday morning started with the various sites reporting their

     status. Alex McKenzie of BBN prepared a status form later in the day

     which was filled out by the representatives of the sites Thursday

     evening. BBN and NIC will prepare a procedure for keeping this

     information at the sites and up to date.

     STATUS

     BBN, TENEX PROJECT: Final stage of incorporating NCP in TENEX. A

     connection was attempted to Utah, but some bugs were found. The NCP

     treats the network as a file in a way integral with other types of

     files. The NCP includes a teletype interface. They hope to

     incorporate the NCP in SRI'S TENEX system by the end of the month.

     BBN, NETWORK GROUP: reported that they were working on three areas

     1. Improving the current network

     2. Working on a 316 version of the IMP and as a Terminal Interface

     Processor (TIMP)

     3. Accounting

    Watson [Page 5]

Report this document

For any questions or suggestions please email
cust-service@docsford.com