You are here: irt.org | RFCs | RFC215 [ previous next ]
Network Working Group A. McKenzie Request for Comments: 215 BBN NIC #7545 30 August 1971 Categories: C.2, D.1, D.3, G.1 Updates: none Obsoletes: none NCP, ICP, and TELNET: The Terminal IMP Implementation By early December there will be six Terminal IMPs incorporated into the network, with additional Terminal IMPs scheduled for delivery at a rate of about one per month thereafter. For this reason the implementation of network protocols (and deviations from them) may be of interest to the network community. This note describes the choices made by the Terminal IMP system programmers where choices are permitted by the protocols, and documents some instances of non-compliance with protocols. Most of the choices made during protocol implementation on the Terminal IMP were influenced strongly by storage limitations. The Terminal IMP has no bulk storage for buffering, and has only 8K of 16- bit words available for both device I/O buffers and program. The program must drive up to 64 terminals which generally will include a variety of terminal types with differing code sets and communication protocols (e.g., the IBM 2741 terminals). In addition, the Terminal IMP must include a rudimentary language processor which allows a terminal user to specify parameters affecting his network connections. Since the Terminal IMP exists only to provide access to the network for 64 terminals, it must be prepared to maintain 128 (simplex) network connections at any time; thus each word stored in the NCP tables on a per-connection basis consumes a significant portion of the Terminal IMP memory. It should be remembered that the Terminal IMP is designed to provide access to the network for its users, not to provide service to the rest of the network. Thus the Terminal IMP does not contain programs to perform the "server" portion of the ICP; in fact, it does not have a "logger" socket. [Page 1]
RFC #215 The Terminal IMP program currently implements only the NCP, the ICP, and the TELNET protocol since these are of immediate interest to the sites with Terminal IMPs. It is anticipated that portions of the data transfer protocol will be implemented in the future; the portions to be implemented are not yet clearly defined, but will probably include the infinite bit stream (first) and the "transparent" mode (later). Developments in the area of data transmission protocol will be documented in the future. The remainder of this note describes, and attempts to justify, deviations from the official protocols and other design choices of interest. Although written in the present tense, there are some additional known instances of deviation from protocol which will be corrected in the near future. A) Deviations from Protocols 1) The Terminal IMP does not guarantee correct response to ECO commands. If some Host A sends a control message containing ECOs to the Terminal IMP, and the message arrives at a time when a) the Terminal IMP has a free buffer and b) the control link from the Terminal IMP to Host A is not blocked then the Terminal IMP will generate a correct ERP for each ECO. In all other cases the ECO commands will be discarded. (All control messages sent by the Terminal IMP begin with a NOP control command, so if Host A sends a control message consisting of 60 ECO commands, the Terminal IMP will answer (if at all) with a 121-byte message -- 1 NOP and 60 ERPs.) The reason for this method of implementation is that to guarantee correct response to ECO in all cases requires an infinite amount of storage. For example, suppose Host A sends control messages, each containing an ECO command, to Host B at the rate of one per second, but that Host A accepts messages from the network as slowly as possible (one every 39 seconds, say). Then Host B has only three choices which do not violate protocol: a) Declare itself dead to the network (i.e., turn off its Ready line), thereby denying all its users use of the network. [Page 2]
RFC #215 b) Refuse to accept messages from the network faster than the slowest possible foreign Host (i.e., about one every 39 seconds). If Host B is a Terminal IMP, this is almost certainly slow enough to soon reach a steady state of no users. c) Implement "infinite" storage for buffering messages. Since it is clear that none of the "legal" solutions are possible, we have decided to do no buffering, which should (we guess) satisfy the protocol well over 99% of the time. 2) The Terminal IMP does not guarantee to issue CLS commands in response to "unsolicited" RFCs. There are currently several ways to "solicit" an RFC, as follows: a) A terminal user can tell the Terminal IMP to perform the ICP to the TELNET Logger at some foreign Host. This action "solicits" the RFCs defined by the ICP. b) A terminal user can send an RFC to any particular Host and socket he chooses. This "solicits" a matching RFC. c) A terminal user can set his own receive socket "wild." This action "solicits" an STR from anyone to his socket. Similarly, the user can set his send socket "wild" to "solicit" an RTS. If the Terminal IMP receives a "solicited" RFC it handles it in accordance with the protocol. If the Terminal IMP receives a control message containing one or more "unsolicited" RFCs it will either issue CLS commands or ignore the RFCs according to the criteria described above for answering ECOs (and for the same reasons). Further, if the Terminal IMP does issue a CLS in response to an unsolicited RFC it will not wait for a matching CLS before considering the sockets involved to be free for other use. 3) After issuing a CLS for a connection, the Terminal IMP will not wait forever for a matching CLS. There are two cases: [Page 3]
RFC #215 a) The Terminal IMP has sent an RFC, grown tired of waiting for a matching RFC, and therefore issued a CLS b) The Terminal IMP has sent a CLS for an established connection (matching RFCs exchanged) In either of these cases the Terminal IMP will wait for a matching CLS for a "reasonable" time (probably 30 seconds to one minute) and will then "forget" the connection. After the connection is forgotten, the Terminal IMP will consider both sockets involved to be free for other use. Because of program size and table size restrictions, the Terminal IMP assigns socket numbers to a terminal as a direct function of the physical address of the terminal. Thus (given this socket assignment scheme) the failure of some foreign Host to answer a CLS could permanently "hang" a terminal. It might be argued that the Terminal IMP could issue a RST to the offending Host, but this would also break the connections of other terminal users who might be performing useful work with that Host. 4) The Terminal IMP ignores all RET commands. The Terminal IMP cannot buffer very much input from the network to a given terminal due to core size limitations. Accordingly, the Terminal IMP allocates only one message and a very small number of bits (currently 120 bits; eventually some number in the range 8-4000, based on the terminal's speed) on each connection for which the Terminal IMP is the receiver. Given such small allocations, the Terminal IMP attempts to keep the usable bandwidth as high as possible by sending a new allocation, which brings the total allocation up to the maximum amount, each time that: a) one of the two buffers assigned to the terminal is empty, and b) the allocations are below the maxima. Thus, if a spontaneous RET were received, the reasonable thing for the Terminal IMP to do would be to immediately issue a new ALL. However, if a foreign Host had some reason for issuing a first [Page 4]
RFC #215 spontaneous RET, it would probably issue a second RET as soon as it received the ALL. This would be likely to lead to an infinite (and very rapid) RET-ALL loop between the two machines, chewing up a considerable portion of the Terminal IMP's bandwidth. Since the Terminal IMP can't "afford" to communicate with such a Host, it ignores all RETs. 5) The Terminal IMP ignores all GVB commands. Implementation of GVB appears to require an unreasonable number of instructions and, at the moment at least, no Host appears to use the GVB command. If we were to implement GVB we would always RET all of both allocations and this doesn't seem very useful. 6) The Terminal IMP does not handle a total bit- allocation greater than 65,534 (2^16-2) correctly. If the bit-allocation is ever raised above 65,534 the Terminal IMP will treat the allocation as infinite. This treatment allows the Terminal IMP to store the bit allocation for each connection in a single word, and to avoid double precision addition and subtraction. Our reasons for this decision are: a) A saving of more than 100 words of memory which would be required for allocation tables and for double precision addition/subtraction routines. b) Our experience, which indicates that very few Hosts (probably one at most) ever raise their total bit allocation above 65,534 bits. c) Our expectation that any Host which ever raises its bit allocation above 65,534 probably would be willing to issue an infinite bit allocation if one were provided by the protocol. Once the bit allocation is greater than about 16,000, the message allocation (which the Terminal IMP handles correctly) is a more powerful method of controlling network loading of a Host system than bit allocation. We believe that Hosts which have loading problems will recognize this. 7) The Terminal IMP ignores the "32-bit number" in the ICP. When the Terminal IMP (the "user site") initiates the Initial Connection Protocol the actual procedure is to send the required RTS to the logger [Page 5]
RFC #215 socket of the user-specified foreign Host and simultaneously to set the terminal user's send and receive sockets in a state where each will accept any RFC from the specified Host. The 32-bit socket number transmitted over the logger connection is ignored, and the first RTS and STR addressing the user's sockets will be accepted (and answered with matching RFCs). The ICP allows the foreign Host to transmit the RFCs involving Terminal IMP sockets "U+2" and "U+3" at any time after receipt of the RFC to the (foreign Host's) logger socket. In particular, the RFCs may arrive at the Terminal IMP before the 32-bit number. In the case of a "normal" foreign Host, the first incoming RFCs for sockets U+2 and U+3 will come from the sockets indicated by the 32-bit number, so it doesn't matter if the number is ignored. In the case of a pathologic foreign Host, a potentially infinite number of "wrong" RFCs involving U+2 and U+3 may arrive at the Terminal IMP before the 32-bit number is sent. The Terminal IMP would be required to store this stream of RFCs pending arrival of the 32-bit number, then issue CLS commands for all "wrong" RFCs. However, the Terminal IMP does not have infinite storage available for this purpose (it is also doubtful that a terminal user really wants to converse with a pathologic foreign Host) so the Terminal IMP assumes that the foreign Host is "normal" and ignores the 32-bit number. B) Other Design Choices Related to Protocol 1) The Terminal IMP ignores incoming ERR commands and does not output ERR commands. 2) The Terminal IMP assumes that incoming messages have the format and contents demanded by the relevant protocols. For example, the byte size of incoming TELNET messages is assumed to be 8. The major checks which the Terminal IMP does make are: a) If an incoming control message has a byte count greater than 120 then it is discarded. [Page 6]
RFC #215 b) If a control command opcode greater than 13 is found during the processing of a control message then the remainder of the control message is discarded. c) If an incoming data message has a byte count indicating that the bit allocation for the connection is exceeded (based on the assumed byte size) then the message is discarded. 3) If one control message contains several RST commands only one RRP is transmitted. If several control messages, each containing RST commands, arrive "close together" only one RST is returned. [The actual implementation is to set a bit each time a RST is found (in "foreground") and to reset the bit when a RRP is sent (in "background").] 4) Socket numbers are preassigned based on the hardware "physical address" (in the terminal multiplexing device) of the terminal. The high order 16 bits of the socket number give the device number (in the range 0-63) and the low order bits are normally 2 or 3 depending on the socket's gender (zero is also used during ICP). [We would be pleased to see socket number length reduced to 16 bits; in that case the high order 8 bits would be mapped to the device and the low order 8 bits would contain 2 or 3.] 5) During ICP, with the Terminal IMP as the user site, the Terminal IMP follows the "Listen" option rather than the "Init" option (as described at the top of page 3, NIC #7170). In other words, the Terminal IMP does not issue the RFCs involving sockets U+2 and U+3 except in response to incoming RFCs involving those sockets. In this context, we will mention that the "deadlock" mentioned in NWG-RFC #202 does not exist, since the ICP does not give the server the "Listen" option (see NIC #7170, page 2). [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Randy Dunlap 5/97 ] [Page 7]