Connecting computers to MLC ports
The limits of connecting hosts through terminal interfaces
McKenzie, A.M., "Connecting computers to MLC ports", RFC 241, DOI 10.17487/RFC0241, September 1971, <https://www.rfc-editor.org/info/rfc241>.
@misc{rfc241,
series = {Request for Comments},
number = 241,
howpublished = {RFC 241},
publisher = {RFC Editor},
doi = {10.17487/RFC0241},
url = {https://www.rfc-editor.org/info/rfc241},
author = {A.M. McKenzie},
title = {{Connecting computers to MLC ports}},
pagetotal = 2,
year = 1971,
month = sep,
} RFC text
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
§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.