Thinwire protocol for connecting personal computers to the Internet
RFC - Historic
(September 1984; No errata)
||RFC Editor Note
RFC 914 (Historic)
||Send notices to
Network Working Group David J. Farber
Request for Comments: 914 Gary S. Delp
Thomas M. Conte
University of Delaware
A Thinwire Protocol
for connecting personal computers
to the INTERNET
Status of this Memo
This RFC focuses discussion on the particular problems in the
ARPA-Internet of low speed network interconnection with personal
computers, and possible methods of solution. None of the proposed
solutions in this document are intended as standards for the
ARPA-Internet. Rather, it is hoped that a general consensus will
emerge as to the appropriate solution to the problems, leading
eventually to the adoption of standards. Distribution of this memo
What is the Problem Anyway ?
As we connect workstations and personal computers to the INTERNET,
many of the cost/speed communication tradeoffs change. This has made
us reconsider the way we juggle the protocol and hardware design
tradeoffs. With substantial computing power available in the $3--10K
range, it is feasible to locate computers at their point of use,
including in buildings, in our homes, and other places remote from
the existing high speed connections. Dedicated 56k baud lines are
costly, have limited availability, and long lead time for
installation. High speed LAN's are not an applicable interconnection
solution. These two facts ensure that readily available 1200 / 2400
baud phone modems over dialed or leased telephone lines will be an
important part of the interconnection scheme in the near future.
This paper will consider some of the problems and possibilities
involved with using a "thin" (less than 9600 baud) data path. A trio
of "THINWIRE" protocols for connecting a personal computer to the
INTERNET are presented for discussion.
Although the cost and flexibility of telephone modems is very
attractive, their low speed produces some major problems. As an
example, a minimum TCP/IP Telnet packet (one character) is 41 bytes
long. At 1200 baud, the transmission time for such a packet would be
around 0.3 seconds. This is equivalent to using a 30 baud line for
single character transmission. (Throughout the paper, the assumption
is made that the transmission speed is limited only by the speed of
the communication line. We also assume that the line will act as a
synchronous link when calculating speed. In reality, with interrupt,
computational, and framing overhead, the times could be 10-50%
In many cases, local echo and line editing can allow acceptable
Farber & Delp & Conte [Page 1]
RFC 914 September 1984
Telnet behavior, but many applications will work only with character
at a time transmission. In addition, multiple data streams can be
very useful for fully taking advantage of the personal
computer/Internet link. Thus this proposal.
There are several forms that a solution to this problem can take.
Three of these are listed below, followed by descriptions of possible
solutions of each form.
o As a non-solution, one can learn to live with the slow
communication (possibly a reasonable thing to do for background
file transfer and one-time inquiries to time, date, or
o Using TCP/IP, one can intercept the link level transmissions,
and try various kinds of compression algorithms. This provides
for a symmetrical structure on either side of the "Thinwire".
o One could build an "asymmetrical" gateway which takes some of
the transport and network communication overhead away from both
the serial link and the personal computer. The object would be
to make the PC do the local work, and to make the
interconnection with the extended network a benefit to the PC
and not a drain on the facilities of the PC.
The first form has the advantage of simplicity and ease of
implementation. The disadvantages have been discussed above. The
second form, compression at link level, can be exploited in two ways.
Thinwire I is a simple robust compressor, which will reduce the 41
byte minimum TCP/IP Telnet packets to a series of 17 byte update
packets. This would improve the effective baud rate from 30 baud
to 70 baud over a 1200 baud line (for single character packets).
Thinwire II uses a considerably more complex technique, and takes
advantage of the storage and processing power on either side of
the thinwire link. Thinwire II will compress packets from
Show full document text