path: root/doc/rfc/rfc215.txt

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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L