Doug Kingston (dpk@BRL.ARPA)
Sun, 22 Mar 87 9:51:45 EST
[Disclaimer: The following represent my personal professional opinion
and does not necessarily represent the opinions of BRL or the DoD.]
Concerning Connections between TCP/IP and PC's
There are several possible connections between TCP/IP and PC's.
There are several implementations of the DOD protocol suite
for PC, both public domain (MIT & by Phil Karn for HAM packet radio)
and vendor supported (FTP Software in Mass., maybe others as well, check
with the NIC's vendor list). In addition there is TCP/IP support
for PC's by means of smart interface cards that put TCP/IP into
firmware. I believe there are several of these as well, 3Com being
the one that comes immediately to mind. More details can be be
dragged out of the NIC and the industry magazines. Try looking
at Ungerman-Bass, Micom/Interlan, CMC, Network Solutions?
PC's are now fairly easily tied into a network of Super-Mini's to
Supercomputers using TCP/IP from any of these sources. This can even
include true remote file systems using the Sun Microsystems NFS software
for the PC (it uses the 3Com hardware as a base).
A variety of vendors now make TCP/IP virtual terminal servers which
provide a means to easily access other hosts via RS232 as a terminal.
While this does not make a PC a real host on the network, it can be
a cheap way for several PC's to access the network by sharing a terminal
server and using it much like a modem.
UNIX is becoming the second operating system of the PC and most versions
of UNIX already support the TCP/IP protocol suite.
Opinion and Caveat
[in the following read "ISO" to mean protocols referenced in the GOSIP]
My position on this is a pragmatic one. I feel there is undoubtedly
potential benefit to migration to (a possibly modified or amended) ISO
protocol suite in the future. However, now is not the time to be purchasing
ISO protocols for production use as the GOSIP is indicating. There is
at least a decade of research in the TCP/IP protocol suite. This includes
not only the investigation of the architectural features, but also the
algorithms used in the actual operation of a large internet. These are
lessons that are not necessarily transferable to the ISO protocol suite
due to differences in design. These kinds of lessons can only be learned
over time with controlled introduction, first into an experienced research
community and then into larger communities as the specifications and
unspecified algorithms solidify. You must keep the initial communities
small because there will changes necessary, and you need fast turnaround
between recommendation and implementation. I work in a research lab, and
I expect us to start experimentation and testing of the ISO protocols to
start this year at our institution. I don't expect them to work or to be
complete. My gut feeling is that five years from now is the earliest
time to expect reasonably robust and complete ISO protocol suite
The government cannot afford to turn itself into an alpha or beta test
site which is what would undoubtedly happen. As any consumer can tell
you there is always a danger in buying the first units of a new product.
If you are interested in reliability and predictable performance, you
wait for the second printing, the next model year, or the later revision
of the product.
In short, I am not anti-ISO, but adoption of ISO on large scale at this
time is a costly mistake. It will prove to be buggy, incomplete, and
there will be unforseen incompatablities, and since its never been
used on a large scale it will have scaling problems as systems are
interconnected for the first time. The government should hold off
widespread usage in production usage until the ISO suite has had a chance
to mature, stabilize, and "prove itself" in the R&D community.
I would be happy to talk to you further by phone or mail, and to help
review your article for correctness regarding the TCP/IP suite. I feel
its critical that people get the correct information about this.
Internet: <DPK @ BRL.ARPA>
Douglas P. Kingston III
Advanced Computer Systems Team
Systems Engineering and Concepts Analysis Division
U.S. Army Ballistic Research Laboratory
Attn: SLCBR-SECAD (Kingston)
APG, MD 21005
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:37:45 GMT