RFC 241 UNKNOWN ARCHITECTURE · INFRASTRUCTURE

Connecting computers to MLC ports

The limits of connecting hosts through terminal interfaces

On rfc-editor.org ↗
PUBLISHED
September 1971
AUTHORS
A.M. McKenzie
STREAM
Legacy
STANDARD HOST-IMP CABLE LENGTH
Up to 30 feet (or up to 2000 feet with Distant Host option)
ASSUMED HOST-IMP ERROR RATE
Error-free
TERMINAL MLC DESIGN
For terminals over phone lines
TERMINAL MLC ERROR CONTROL
None in hardware or software
DOI
10.17487/RFC0241

RFC text

Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                           A. McKenzie
RFC # 241                                       BBN
NIC # 7671                                      29 September 1971
Categories: B.1, C.1, I.1
Updates: none
Obsoletes:  Our Previous Verbal Comments



                   CONNECTING COMPUTERS TO MLC PORTS
                   ---------------------------------

        Several times we have been asked if computers can be con- nected
   through serial communication lines to ports on the Terminal IMP's
   Multi-Line Controller (MLC) [related questions about the level of
   software support provided by the Terminal IMP to such a connection,
   have also been raised].  In the past we have said, "Please don't!" We
   now say, "Sure, but will that really help you the way you think it
   will?"


        (1) Connections between computers and IMPs (i.e., the Host
   interfaces) have been assumed to be error-free.  This assumption is
   justifiable on the basis that the IMP and Host computers were
   expected to be either in the same room (up to 30 feet of cable) or,
   via the Distant Host option, within 2000 feet on well- controlled,
   shielded cables.  A connection through common carrier facilities is
   not comparably free of errors.  Usage of common- carrier lines for
   connecting a terminal to an IMP, including the assumption of a human
   at the terminal, is a situation in which the typical errors which do
   occur can be accommodated.  Usage of the same wire, with the same
   typical errors, for a computer-to- computer connection is likely to
   be a situation in which the errors are unacceptable.  The present
   version of the Terminal IMP does not provide error control either
   within its hardware or within its software on any ports of the
   Multi-Line Controller.  Further, we feel that computer-to-computer
   connections over common carrier circuits should employ strong error
   control, such as that

RFC # 241




   used on the IMP/IMP circuits, and that attempts to use minimal error
   control (e.g., character parity) is an undesirable technical choice.
   Strong error control, with its retransmission scheme, not only would
   imply significant changes in the Terminal IMP, but a non-trivial
   hardware/software implementation at the remote computer end of the
   circuit.


        (2) Because the Terminal IMP has many obligations, the share of
   its bandwidth which can be given to a Host coming in over the MLC
   will be small.


        (3) The command language provided at a port of the Multi- Line
   Controller was designed with terminals and people in mind.  It
   provides very few of the capabilities which a computer requires in
   order to effectively utilize the communication network.  For example,
   only a single pair of connections can be made from a given Terminal
   TMP port; Host computers generally desire a larger number of
   simultaneous connections to other Hosts on the network.  Assuming the
   present Host/Host protocols, such a Host could not conveniently act
   as a server.


        If, despite these potential difficulties, connection of a
   computer to the network through an MLC port appears to be useful, BBN
   has no objection.  In fact, we would be extremely interested in
   hearing about actual experience with this type of network connection.



   AMcK:jm

         [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by BBN Corp. under the   ]
         [ direction of Alex McKenzie.                   12/96   ]

AI ELI5

On this page
PROBLEMPeople ask whether a host computer can connect to the ARPANET through a Terminal IMP's Multi-Line Controller, as an alternative to a direct host-to-IMP interface.
MECHANISMBBN explains that while it is technically possible, the approach has significant drawbacks: the connection lacks error control, bandwidth is limited, and the terminal-oriented command language does not support the full range of host-to-host operations.
POSSIBLE BUT NOT IDEALBBN permits the arrangement but cautions that it is unlikely to work well in practice, and invites feedback from anyone who tries it.

§1The Question and the Constraint

Host computers normally connect to an IMP (Interface Message Processor) via a direct, error-free connection over short, shielded cables. The ARPANET relies on the assumption that host-to-IMP connections are reliable.

Some people ask whether a host can instead connect through a Terminal IMP's Multi-Line Controller (MLC), which is designed to handle connections over phone lines from remote terminals. BBN has historically said no, but this RFC changes that to a conditional yes.

The network was designed so big computers connect directly with no mistakes. Some people want to use the phone-line system instead, which was not designed for that.

§2The Practical Problems

The Terminal IMP's MLC lacks error control. It was designed for human operators at terminals, where occasional character errors can be fixed or retried. A host-to-host connection will see the same errors but cannot tolerate them the same way.

Phone lines introduce errors that a direct cable does not, and the present Terminal IMP hardware and software provide no error recovery. Strong error control, like the system used for IMP-to-IMP links, would require major changes to both the Terminal IMP and the remote host.

Additionally, the Terminal IMP has limited bandwidth to share among its many connections, and the command language is designed for interactive terminals, not for the multiple simultaneous connections a host typically needs.

Phone lines make mistakes, the little box was not built to fix them, and even if you connect, the box will not let you do many of the things a host needs.

§3BBN's Position

BBN says it has no objection to the arrangement and is even interested in hearing about real experience if someone tries it. However, people should understand the constraints and limitations up front. If the connection works well for a particular use case, that would be valuable feedback. If it does not, the technical reasons will be clear.

Feel free to try it, but do not be surprised if it does not work well. If it does, please tell us.