diff options
Diffstat (limited to 'doc/rfc/rfc77.txt')
| -rw-r--r-- | doc/rfc/rfc77.txt | 507 |
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc77.txt b/doc/rfc/rfc77.txt new file mode 100644 index 0000000..e8c0d51 --- /dev/null +++ b/doc/rfc/rfc77.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group J. Postel +Request for Comments: 77 UCLA +NIC 5604 20 November 1970 + + 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. + + + + +J. Postel [Page 1] + +RFC 77 Network Meeting Report 20 November 1970 + + +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 + + + +J. Postel [Page 2] + +RFC 77 Network Meeting Report 20 November 1970 + + +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. + + + + + +J. Postel [Page 3] + +RFC 77 Network Meeting Report 20 November 1970 + + +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. + + + + + + + + + +J. Postel [Page 4] + +RFC 77 Network Meeting Report 20 November 1970 + + +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 + + + +J. Postel [Page 5] + +RFC 77 Network Meeting Report 20 November 1970 + + +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 + + + +J. Postel [Page 6] + +RFC 77 Network Meeting Report 20 November 1970 + + +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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +J. Postel [Page 7] + +RFC 77 Network Meeting Report 20 November 1970 + + + Network Meeting Attendance List 16 - 18 Nov. 70 Houston + +Name 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,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 + + + + + + + + +J. Postel [Page 8] + +RFC 77 Network Meeting Report 20 November 1970 + + + 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 ] + + + + + + + + + + + + + + + + + + + + + + + + + + +J. Postel [Page 9] + |