Movatterモバイル変換

Network Working Group                                          J. PostelRequest for Comments: 77                                            UCLANIC 5604                                                20 November 1970Network Meeting ReportThis is a report on a series of three Network Working Group meetings atthe Fall Joint Computer Conference, November 16, 17 and 18 in Houston,Texas.  The meeting will be lumped together and ideas may or may not beidentified as to their originator.  The meetings were chaired by SteveCrocker.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.J. Postel                                                       [Page 1]

RFC 77                   Network Meeting Report         20 November 19707) 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 inbunches and at about six-month intervals rather than a continuous streamof small changes.  Also that a lead time of three months was not overoptimistic.  The proposed change to the IMP-Host protocol to get rid ofmarking was generally approved but it will not be implemented for sometime since casual changes to the protocol are undesirable.  TomO'Sullivan suggested that perhaps new and old protocols could worktogether, that is the new protocol would support the old one as well asprovide better mechanisms where possible.  Steve Crocker suggested thata new protocol might be developed as a private experimental protocolbetween two or three sites.It was stressed that it is necessary that the network be used to gainexperience, and that we should get teletype-like console use of remotesystems going before we get too involved in graphics.  Perhaps thegraphics protocol should be developed by a different set of people.  Thescheduling of a graphics protocol meeting was thus discouraged, butpapers should still be written.  Strong feelings were expressed infavour of first developing use of remote subsystems and filetransmission instead of worrying about graphics at this stage.  It wassuggested that development of protocols at the higher levels be drivenby applications.Documentation will be a major concern for network users.  Several peoplementioned that users at their sites have already begun to inquire aboutthe network.  As Eric Harslem put it "What does the ARPA Network have tooffer?"  Some sites (Multics, SRI) keep system documentation on-line.It was suggested that the trillion bit store be used to keep on-linedocumentation of all systems.At this point Doug Engelbart gave a presentation on the NetworkInformation Center (NIC).  The goals or services of NIC have not beenwell defined by anyone and have been left up to NIC to define.  NIC hasdecided that one urgent task is to make information about the networkand the host systems on the network available to users of the network.Doug has found that some people feel threatened by the revelation oftheir documentation inadequacy.  Doug's project at SRI has built up asystem that allows the user to create catalogs and indices into acollection of information.  The system has a master catalog of allinformation files.  Each user may have a number of private (or shared)catalogs.  The system provides a means of examining on-line the catalogsJ. Postel                                                       [Page 2]

RFC 77                   Network Meeting Report         20 November 1970and amending them.  The system also provides a means to examine anyinformation file which happens to be on-line and for creating newinformation files on-line.Several problems will delay the NIC from coming on the network.  One ofthese is the switch from the XDS-940 to the PDP-10 (TENEX).  The switchis being made because the 940 system is inadequate to handle theanticipated load.  At first it was planned to offer service on the 940and switch to the 10 when it came up, but too much effort would berequired for a very small payoff.Doug explained the working of the Network Dialoge System.  At each sitethere is a communication agent and a technical liaison officer.  Theagents will be trained by NIC to use the facilities of NIC to getinformation about the Network and other sites.  The agents will acquirefrom NIC documents of interest to users at the local site, be able tocontact NIC at a toll free number, and should have an on-line consoleinto the network (and therefore NIC).  Thus the Network Dialoge Systemis 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.  Hediscussed the level of implementation at various sites.  Eric Harslemmentioned that RAND and UCSB had conducted tests of their NCPimplementations 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 awide 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 explainingthe SRI system at a more detailed level.  The basic thing to deal withis the collection.  The user can query over the collection or over subcollections.  The user can obtain bibliographic references of threekinds: 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 atother network sites, for example the trillion bit store and before thatperhaps on disk at UCSB.  If files are kept at other sites then thesystem must be able to retrieve them automatically when they arerequested.  The subsystem to be used is called TODAS.  TODAS is anevolving program and the documentation of TODAS is inadequate.  InTODAS, file are organized hierarchically, each paragraph is numbered,and it is possible to do context analysis on the text.J. Postel                                                       [Page 3]

RFC 77                   Network Meeting Report         20 November 1970Doug then mentioned some things about the console interaction.  Thisraised a question about half vs. full duplex and line oriented vs.character oriented systems.  The remainder of the meeting revolvedaround this issue.I shall try to define the terms as I understand them for purpose ofclarity in the following.  Half duplex is the situation where theconsole, a peripheral processor or some very low level software, echosthe character entered.  The console can not be used to input data whileoutput is in progress.  Full duplex is the situation where the charactertyped is echoed by software, and input can be done at the same time asoutput.  In line oriented systems the user enters a complete lineterminated by an extra sensitive and of line character (e.g. carriagereturn).  Often the keyboard is then locked until after the next output.In character oriented systems each character the user enters isinterpreted by software before it is echoed and the echo may bedifferent from the character entered.  In particular after a fewcharacter the software may guess what the user wants and complete theline 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 ownsystems fit in this chart and are very vague about what it means tointeract with a system in a different than their own.  Doug stated thatNIC has a system of type 2 but would try to provide service to all typesof systems.  The following table shows systems with their interactiontype and categorization as to Research vs. Service Center.J. Postel                                                       [Page 4]

RFC 77                   Network Meeting Report         20 November 1970System                     Interaction Type           CategorizationUCLA - Sigma-7             2 - char, full             ResearchUCLA - 360/91              3 - line, half             ServiceMIT - Multics              3 - line, half             ServiceSDC                        3 - line, half                ?RAND                       3 or 4 - line, ?              ?SRI                        2 - char, full                ?Al Vezza promised to study this problem and to circulate his results asan NWG/RFC.  It was pointed out that line oriented systems usually allowline editing of the form "delete last character" (back space) and"delete line", however this feature does not alter their classificationas to interaction type.  Concern arose over what do line orientedsystems expect to receive from the network for a connection acting asconsole input to a subsystem.  Steve Crocker made the suggestion thatwhen using a line oriented system transmission be in lines.  Moreprecisely that transmission be in strings of the following form.                       n c1 c2 ...cnwhere 1 <= n <= 120   (n is eight bits)and if ci is an "end of line" character then i = nThis suggestion was not immediately accepted and some discussion tookplace regarding the significance of Host-Imp-Host message boundaries.Doug brought up file transmission and the problem of finding the end ofthe file, which provoked more discussion.  At this point the meetingbroke up with a third session scheduled for 8:00 p.m. Wednesday evening.The Wednesday meeting began with the suggestion that at future xJCC'sthere be an official ARPA Network hotel with a block of rooms on onefloor and a nearby meeting room for networkers.  This suggestion wasfavored by all.Steve Crocker asked how people felt about these meetings.  The generalfeeling was that the meetings were very useful and should occur about 3months apart.  Al Vezza pointed out that meetings this size (15 - 30people) are good for bringing up problems but not for putting them down.Steve proposed that 3 or 4 people be designated to solve particularproblems.  Al responded that 3 people can't legislate.  That any suchJ. Postel                                                       [Page 5]

RFC 77                   Network Meeting Report         20 November 1970solution must be considered in the same way as a proposal by anindividual.Steve persuaded Peggy Karp to act as NWG/RFC editor.  This is a jobindependent of cataloging RFC's or assigning numbers (functions nowperformed by NIC).  The RFC editor will only categorize RFC as "hotissues", current, out of date, or superseded.The subject of Logger protocol -- that is, how to get the firstconnection -- needs to be officially defined.  NWG/RFC #66 suggests oneway.  Eric Harslem will revise this and send it out as proposed officialprotocol.  Ed Myer will also send out a proposal.Steve then opened up discussion of the topics of the previous meeting bysuggesting we talk about the following: Message boundaries, half duplexvs.  ull duplex, line oriented vs. character oriented, filetransmission, byte counts in messages, byte sizes and transactionalunits.  It was proposed that transactions on the command link (i.e.between NCP's) be always in multiples of eight bits.  This mean that thelength field in the ECO, ERP, and ERR commands will always have threelow order zeroes.  This was approved.  Steve then proposed thatconnections could be established with a declared byte size and a maximumrecord length in bytes.  Transactional units on this type of connectionwould be of the form                  n c1 c2 c3 ... cnwhere 0 <= n <= max record lengthif n = 0 then the transactional unit acts like a semaphore.  Stevesuggested that we should look into the theory of information exchange,particularly along the lines of Richard Kaline (NWG/RFC #60).  Perhapsfor each information unit sent there should be some status response.The next question was on file transmission.  In particular, how do youfind the end?  Frank Heart suggested that with each portion there be aflag indicating "this is not the end" until in the last portion the flagis switched to indicate "this is the end".  Eric Harslem suggested thateach portion should have an "opcode" field, a length field, and the textwhich is length bits (bytes?) long.  This appears to be like the datatypes proposed at the Lincoln Lab meeting last spring.  Ed Myer proposedthat two connections be used, one for the file transmission and theother to control it.  The file control connection would specify the dataconnection and indicate that transmission as about to start.  After thesender had completed the file transmission he would send on the filecontrol link the total number of bits sent.  The receiver would thenknow how many bits to receive and exactly where the end of the fileshould be.  Bob Metcalfe was concerned that some of the proposals mixedJ. Postel                                                       [Page 6]

RFC 77                   Network Meeting Report         20 November 1970control information with data and felt that perhaps this mixing shouldbe avoided.Steve asked if anybody could suggest an advisor we might talk aboutthese problems.  Bob Metcalfe suggested Anatol Holt.  Bob Sundbergsuggested George Mealy.  Eric Harslem and Peggy Karp suggested thatpeople who worked on the COIN System might be helpful.  Frank Heartsuggested that no one has solved these problems.Steve proposed that Service Centers offer line oriented interaction withno echoing of the input.  Any simple editing (e.g. back space) would bedone at the using site.  Ed Meyer suggested that there be officialprotocols for both line oriented and character oriented interaction.Steve promised to write a NWG/RFC clarifying the issues and laying outthe arguments on full transactions, byte counts, and accumulating dataon 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 circulateany ideas or proposals as NWG/RFC's.  Ed Myer took notes and agreed toalso prepare a NWG/RFC summarizing these meetings.J. Postel                                                       [Page 7]

RFC 77                   Network Meeting Report         20 November 1970        Network Meeting Attendance List 16 - 18 Nov. 70 HoustonName                       Site                   Sessions 1. Dick Benjamin          MITRE                      1 2. Jack Bouknight         Illinois - CAC             1,2 3. Al Cocanower           MERIT                      1,3 4. Steve Crocker          UCLA - SPADE               1,2,3 5. Doug Engelbart         SRI - ARC                  1,2,3 6. Wayne Fischer          MERIT                      3 7. Richard Greenblatt     MIT - AI                   1 8. Eric Harslem           RAND                       1,2,3 9. Frank Heart            BBN                        1,2,310. Allen Joseph         ORNL                       111. Peggy Karp           MITRE                      1,2,312. William Kehl         UCLA - CCN                 113. Bob Long             SDC                        1,2,314. Jim Madden           Illinois - CAC             1,215. Bob Metcalfe         MIT - DM                   1,316. Edwin Myer           MIT Multics                1,2,317. Ari Ollikainen       UCLA - SPADE               1,2,318. Tom O'Sullivan       Raytheon                   1,2,319. Jon Postel           UCLA - SPADE               1,2,320. Chris Reeve          MIT - DM                   1,3J. Postel                                                       [Page 8]

RFC 77                   Network Meeting Report         20 November 1970        Network Meeting Attendance List 16 - 18 Nov. 70 HoustonName                       Site                   Sessions21. Tijaart Schipper     UCLA - CCN                 122. Michael Sher         Illinois - CAC             123. Bob Sundberg         Harvard                    1,2,324. Hal Van Zoeren       CMU                        1,2,325. Albert Vezza         MIT - DM                   1,2,326. Alfred Vorhaus       MITRE                      127. Clark Weissman       SDC                        1       [ This RFC was put into machine readable form for entry ]       [ into the online RFC archives by Gottfried Janik 02/98 ]J. Postel                                                       [Page 9]