💾 Archived View for gemini.theuse.net › texts › zines › The_Amateur_Computerist › Supplicament-3.txt captured on 2021-12-17 at 13:26:06.
-=-=-=-=-=-=-
[3a] Part 1
From the ARPANET to the Internet
A Study of the ARPANET TCP/IP Digest
and of the Role of Online Communication
in the Transition from the ARPANET to
the Internet
by Ronda Hauben
ronda@panix.com
[Editor's Note: The following is a draft for comment of a paper
on the early beginnings of the Internet. The paper describes how
communication via the early ARPANET mailing list TCP/IP Digest
documented and helped to prepare for the cutover from the NCP
protocol to the TCP/IP protocol suite. The TCP/IP Digest also
documents the split between ARPANET and MILNET to create the
earliest Internet. The events that the early participants
documented are important to know about today to better understand
and implement the vision of an Internet, of separate but
connected networks that make possible inter-computer
communication. Comments and references to further material,
accounts of experiences during the cutover period, etc. are
welcomed as this was an important period and essential to
understand in order to carry forward the vision and reality of an
Internet. - R.H.]
"I am looking for implementations
of TCP/IP for UNIX systems,
including an interface for an IMP."
Mike Muuss
"People participating in this transition of the
ARPANET into the Internet environment are participating
in an event as exciting as the construction of
the ARPANET and I am very proud to be a part of it."
Vint Cerf
Introduction
In his book The Mythical Man Month, Frederick Brooks Jr.
describes the difficulties encountered by computer scientists
working on large scale program ming projects. "No one thing to
cause the problem..., but the accumulation of simultaneous and
interacting factors brings slower and slower motion," Brooks
explains. He poses an important problem for this era so dependent
on software development and implementation. The coordination and
communication among a number of different people working on a
similar project poses a daunting challenge. Side by side with
this problem that Brooks identifies is the achievement that the
development of the ARPANET and then its transformation into the
Internet demonstrates. Here many different projects and
researchers were able to work together and coordinate their
efforts by utilizing the network they were developing. In the
process, researchers at different sites were able to communicate,
helping each other with difficulties and working together on the
common problems. However, this was not an easy feat and there
were researchers who contributed by speaking out and raising
their voices about the problems they believed were not receiving
adequate attention. Also those researchers who encouraged and
helped to facilitate communication among the researchers on
different projects helped to make coordination and cooperation of
efforts possible.
In his book Science and Government, C. P. Snow tells the
story of the development of radar by the British government
before World War II. Snow describes how important it is when
working on a large scale project, where many people must
contribute, that there be a means of building the necessary
communication and coordination among the various participants
in the process. Commenting on this problem, C.P. Snow writes:
"To get anything done in any highly articulated
organization, you have got to carry people at all sorts of
levels. It is their decisions, their acquiescence or enthusiasm
(above all, the absence of their passive resistance), which are
going to decide whether a strategy goes through in time. Everyone
competent to judge agrees that this was how Tizard guided and
shoved the radar strategy. He had the political and
administrative bosses behind him from the start (Churchill and
Lindemann being then ineffective). He had also the Air Staff and
the Chiefs of Command. But he spent much effort on persuading
and exhorting the junior officers who would have to control the
radar chains when they were ready.
In the same way, he was persuading and exhorting the
scientists who were designing the hardware, and the
administrators who had to get it made. Like all men who
understand institutions, Tizard was always asking the questions
"Where to go to? For which job?" Often, for a real decision as
opposed to a legalistic one, the chap who is going to matter is a
long way down the line. Administrators like Hankey and Bridges
were masters of this kind of institutional understanding, and
they were there to prod and stroke, caress and jab, the relevant
parts of the English organism, so that somehow or other, in a way
that made organizational diagrams look very primitive, the radar
chain got made."(pgs. 59-61)
When there are successful achievements, it is important to
study them. Often, however, there is little documentation of how
the process was accomplished. In the early development of the
Internet, however, we are fortunate that there was an ARPANET
mailing list which was also carried on Usenet. The moderator of
the mailing list was Mike Muuss a research computer scientist at
the Ballistics Research Laboratory in Maryland (BRL). The posts
on the mailing list describe and document some of the process by
which the important change from NCP to TCP/IP was achieved. The
mailing list then describes the split between MILNET and the
ARPANET which led to the creation of the earliest Internet.
Upgrading The ARPANET
In July of 1980, a report by the Defense Communications
Agency (DCA) which administered the ARPANET during this period
documented that the ARPANET had grown to over 66 nodes and
included 4000-5000 users.
Though the report noted the success of the ARPANET project,
there were problems developing, since, as the report explained,
"The basic hardware and software are becoming obsolete." It
described how the nodes used minicomputers developed in the 1960s
which no longer had sufficient memory and other capabilities to
support the technical requirements of the network. The ultimate
goal, "of our planning," the report explained, "is to provide for
an ARPANET II which will be a virtual network and will make use
of several different networks."
The report described how in the next 3 years the ARPANET
Host Protocols Network Control Program (NCP) would be replaced
with a new DoD Standard Protocol Set. The new protocols were DoD
Standard Transmission Control Protocol (TCP) and the Internet
Protocol (IP). Also, new computers would replace the Interface
Message Processors, (IMPs) and Terminal Interface Message
Processor, (TIPs) that formed the IMP sub-network administered by
Bolt Beranek and Newman (BBN). All Honeywell equipment used for
the IMPs was to be replaced with the BBN C/30 costing $20,000 -
$35,000 each (depending on the configuration) if funding could be
obtained, and the software communication programs would run in a
virtual mode.
"The transition," according to Alex McKenzie, an ARPANET
pioneer, "was to be from software, which depended on a single
network of IMPs to software which could deal with multiple
interconnected net works, some with IMPs and others built with
other technologies." A date of January 1, 1983 was set for the
cutover to make the transition from the hardware based IMP subnet
backbone for the ARPANET, to the new form of network that would
connect different networks. The new network of networks would be
based on using a set of common protocols known as the TCP/IP
protocol suite.
This networking research was funded by the U.S. Department
of Defense and there was a simultaneous process ongoing to link
the computers within the DoD. Rather than a set of isolated and
secret activities, the work was done collaboratively under DoD
contracts and by ARPA funded university researchers doing ARPA
related research. Usenet, also developing in the early 1980s, was
a network developed by the Unix community, who were in many
instances university graduate students and researchers at the
Bell Telephone Laboratories of AT&T.
For the changes in the ARPANET proposed by the DCA,
transition had to be made from the ARPANET protocol NCP to the
Internet protocols TCP and IP. Communication among the different
sites which had to make this transition was facilitated by the
ARPANET and Usenet themselves, and in particular by a mailing
list which was available to those on the ARPANET or on Usenet.
This article will examine how the transformation was
documented and supported via the communication made possible on
the ARPANET mailing list "TCP/IP Digest". This mailing list
documents the transition not only from NCP to TPC/IP, but also
from the single network of the ARPANET to the split of the
ARPANET into two separate networks connected via IP gateways
(which was then the standard name for bridges between Internet
networks, now known as routers) and thus into an Internet made up
of two separate networks, the ARPANET and MILNET.
The Beginning of the TCP/IP Digest
The TCP/IP Digest was started by Mike Muuss a research
computer scientist at the U.S. Army Ballistics Research
Laboratory (BRL). The BRL was one of the DARPA sites charged
making the transition from NCP to TCP/IP. Active on the ARPANET
UNIX-Wizards mailing list, Muuss wrote to that mailing list on
October 2, 1981 asking what implementations for TCP/IP existed
for UNIX systems.
In a message dated October 2, 1981, Muuss wrote:
"I am looking for implementations of TCP/IP for UNIX
systems, including an interface for an IMP.
I already know of the 3Com version. Anybody with comments? I
would be most interested in hearing them!
If there is interest, I will forward a summary to the list."
-Mike
The Navy also needed to find an implementation of TCP/IP
software for their computers. They had decided to adopt the VAX
11/750s to replace their PDP 11/40 minicomputers and to go with
Berkeley TCP/IP software that would be distributed with the
4.2BSD UNIX distribution.
Describing this period, Kirk McKusick, a re searcher at the
U of C Berkeley explains that for DARPA, choosing a single
hardware vendor was impractical because of the widely varying
computing needs of the research groups and the undesirability of
depending on a single manufacturer. A memorandum published by the
DOD in March 1982 declared that the adoption of TCP/IP as the DoD
standard host-to-host protocol was mandatory and would provide
for "host-to-host connectivity across network or sub-network
boundaries."
"Military requirements for interoperability",it explains, "
security, reliability and survivability are sufficiently pressing
to have justified the development and adoption of TCP and IP in
the absence of satisfactory non-government protocol standards."
Muuss describes how he had just recovered from an earlier
mandated deadline:
"After having just about gotten over the 3-month mad dash to
switch to long leader LAST winter, I am not really looking
forwards to rushing into the conversion to TCP/IP, because of
the work involved. However, all up and down the line within the
ranks of DoD management inside both the Army and the Navy,
everybody is backing up the decision to stand firm with 1-Jan-83
for the conversion. This is putting the heat on those of us who
actually try to make these things happen, and the pressure is
uncomfortable, but we will probably be able to make it."
"This type of edict is not uncommon when working for the
DoD; some manager will stipulate that something will happen
"absolutely" by a certain date. All the technical people start
worrying, and screaming, and carrying on, claiming that "it
can't be done in time". Management usually dumps some enormous
amount of money onto the project, and wait and see. By this
time, all the tech people have lost about 20 lbs (all brown), and
are running around going crazy. Management usually gets what it
wants. Of course, there are the occasional projects where things
got cut just a bit too tight, and everything falls down in
flames...."
"I happen to feel that TCP and IP are *good* protocols, and
certainly much better than what we are using now. It seems
something of a miracle that they have been adopted as a standard;
usually standards are things like COBOL that people go out of
their way to avoid. It is merely unfortunate that the conversion
timetable is so optimistic."
"There exists AT LEAST one choice of software for UNIX
systems (all machines), T(w)enexes, Multics, and IBMs, so the
majority of the "ordinary" systems will at least be able to
talk, even if not conveniently. How we will get to MACSYMA on
MIT-MC remains a mystery, unless some brilliant MIT student with
a lot of time on his hands decides to power-code a TCP/IP
implementation for the ITS machines...."
"In another post by Muuss to the UNIX-Wizards mailing list,
he explains that the BRL "has a strong commitment to UNIX, and we
encourage discussions about UNIX." He also expresses concern to
maintain contact with those on the list who were getting access
to the list through Usenet, rather than via the ARPANET. He
writes:
"I am also concerned about the USENET participants. We
really need to be able to interact with them in a better way, yet
UUCP gateways to the ArpaNet are VERBOTEN...."
"After his query on the ARPANET UNIX-Wizards mailing list,
Muuss announces the new mailing list on the UNIX Wizards mailing
list." He writes:
"Announcing the first issue of a new digest which purports
to discuss TCP (Transmission Control Protocol) and IP (Internet
Protocol), the "DoD Standard Networking Protocols for the
Eighties". Submissions will probably center around UNIX
implementations, but ANY networking protocol or implementation
discussions too specific for HUMAN-NETS is fair game here.
Please send submissions to "TCP-IP @ BRL", requests to
"TCP-REQUEST @ BRL" or "TCP-IP-REQUEST @ BRL".
This is sort of a spur-of-the-moment thing; it started with
our trying to find out about TCP/IP implementations, and wound up
with dozens of letters asking for a report of what I found. This
list may die stillborn, or it may flourish. Only time will tell!"
Cheers,
-Mike
The first issue of TCP/IP Digest was also sent to the UNIX-
WIZARDS Mailing List and lists a number of reports on UNIX
implementations of TCP/IP.
Also various questions and offers of help in preparing for
the transition are included. Muuss notes that his site has a new
BBN C/30 computer to function as an IMP. Asking for help from
others with experience with this computer, he writes:
"Just out of curiosity, I have some questions about our nice
shinny new C/30.
1) How difficult is it to change a DISTANT host interface
to a LOCAL host interface. Is it a switch, a board, or a big
deal? Could you estimate the cost of doing this? Our liaison's
crystal ball must have been a little cloudy...
2) Just for kicks, is it possible for a C/30 to support
either (a) more than 4 modem lines, and/or (b) run the trunk
lines at more than 50Kb?
3) Is there any provision for more than one trunk to
connect between two C/30's to improve transmission between them?
We are doing a lot of planning here on networking, and are
strongly considering using TCP/IP. What can you tell me about
(or point me to) how BBN plans to proceed with TCP, and how will
this affect the ARPANET?"
Cheers,
-Mike
Forum for Internetworking Problems
Networking implementations other than TCP/IP are also
included in the Digest. In the first message of the second issue
of the Digest, Muuss writes:
"The scope of the Digest will probably exceed the rather
specific 'TCP/IP Digest' title, but that is OK by me. I see this
as a forum for discussing implementation and design problems
relating to large scale networks, and inter-networking....I would
hope that discussion will focus on IP and TCP, because this is
where much of the real action seems to be."
However, in a later issue, a post from Greg at the Navy
Personnel Research and Development Center (NPRDC) reminds Muuss
that the original purpose for the mailing list was to
particularly focus on implementations of TCP/IP to be used with
UNIX. Greg writes:
"Now that all the special interest groups have spoken, can
we get back to the original subject? In case you've forgotten,
it was Unix/ARPANET TCP problems and solutions. Although I'm
interested in the various problems/possibilities of using TCP on
other operating systems or other ethers, at a minimum, our mutual
interest is getting our machines running TCP before the deadline.
(Probably this list goes a little farther than that; to those
people, I apologize. But we are the ones with the deadline fast
approaching.) Maybe we can discuss theoretical issues later, but
I am more interested in the practical issues -- namely, who has
TCP up? How is it connected to the ARPANET (or even another
ether, if the problems/solutions are similar)? What problems
were encountered? How fast is it? How does it compare in
simplicity/ performance/transparency/ complete
ness/functionality/limitations/etc. with the other possibilities?
So far, we have heard of two real choices (assuming that we're
not going to have to buy any additional hardware): BBN and 3COM.
Who's got them up? How connected? (I am VDH, so solutions that
don't have a VDH driver are uninteresting.) Speak up; now's your
chance to brag, and you can do the rest of us a real service."
Muuss responds, maintaining his commitment for a broad focus
for the Digest:
"Actually, I had hoped that this digest could serve as a
forum for technical discussion of networking for ALL systems, but
clearly the transition to TCP for current ARPANET Hosts is the
primary motivator I hope that this list will not restrict itself
just to UNIX, though."
Another comment to the list was from Bill Joy who was
working with the Computer Systems Re search Group at Berkeley. He
writes:
"The Computer Systems Research Group at Berkeley is
enhancing the UNIX operating system with DARPA support. We are
improving UNIX memory management facilities, working on extensions
to UNIX to support better inter-process communication, and
incorporating support for both local and long haul networks. In
particular, we expect to try using the INTERNET protocols on a
number of different commercially available local network
interfaces....We have just finished about three weeks of tuning
of the BBN TCP/IP for our 3 Megabaud prototype Ethernet. We had
previously brought TCP/IP up on the Ethernet and were interested
in learning more about the internals of TCP and discovering
whether the protocol would be a bottleneck when running on a
local network. The results we have obtained suggest that this is
not the case."
Steve Bellovin, active in the UNIX community and a Usenet
pioneer who wrote the first shell script version of the Usenet
software, writes that he was working on the extension and
development of the UUCP network. Posting to the TCP/IP digest
from Usenet, he writes:
"I just read RFC754 and RFC799, and it's becoming apparent
that the ARPAnuts are setting standards which we'll have to
adhere to if we're to talk to them. And the whole uucp addressing
mess is getting out of hand -- and that says nothing of changing
topologies ....Add in ARPA, CSnet, and maybe Berknet among the
duke machines, and you have a royal mess. I'm inclined to start a
new net newsgroup to discuss mail, networking, addressing, etc.,
from a UNIX/uucp point of view -- say, net.net (fa.tcp-ip appears
to be too specialized, though I'll route a copy of this to the
moderator)."
Mark Horton, another UNIX and Usenet pioneer, agreed with
him.
"Having a newsgroup to discuss nets is different than
discussing mail. I propose net.net and net.mail. I'm not sure
net.net is needed - does fa.tcp-ip subsume it? There will
probably soon be a net.csnet, too."
Mark
Answering Bellovin's concern, Muuss maintains his commitment
to welcome broad discussion of networking issues. Also he assures
Bellovin that he could directly send his comments to the Digest
using UUCP, rather than having to depend on a gateway to the
ARPANET. Muuss wrote:
"Steve -
While the masthead 'TCP-IP Digest' is really rather
specialized, I had intended the Digest as more of a discussion on
IMPLEMENTATION issues of networking (as opposed to Philosophical
discussions as get found in HUMAN-NETS). The troubles with
multiple networks, and the variety of message formats (for mail),
and routing problems in general are all fair game for the TCP-IP
digest. You are welcome to have this networking discussion in
the TCP digest -- if the volume becomes too great I would be
willing to clone a new digest later on.
BRL polls Duke via UUCP, so messages ad dressed to
...!duke!bmd70!TCP-ip should make it to the digest (no need to go
through Berkeley). Give it a try. Our RMAIL is smart enough to
prevent acci dental gatewaying; sorry."
Cheers,
-Mike
Converting to TCP/IP
A conversion table from RFC 801 (November 1981) "TCP/IP
Conversion Timetable and Documents" appears in the Digest
outlining the proposed schedule for NCP-only hosts to begin and
then complete their conversion to TCP/IP. Included in the
scheduled milestones to be achieved were the following:
NCP/TCP Transition Plan
Milestones When:
Last NCP Conversion Begins - Jan 82
The last NCP-only host begins conversion to TCP.
Mail Relay Service - Jan 82
The SMTP (RFC 788) mail service begins to
operate and at least one mail relay host is operational,
and at least one special forwarder is operational to
provide NCP-only host to TCP-only host mail connectivity.
Normal Internet Service - Jul 82
Most hosts are TCP-capable and use TCP-based services.
Last NCP Conversion Completed - Nov 82
The last NCP-only host completes conversion to TCP.
Full Internet Service - Jan 83
All hosts are TCP-capable and use TCP-based services. NCP
is removed from service, relay services end, all services are
TCP-based.
Along with the general discussion of implementation
questions for the cutover, problems regarding the implementation
of TCP/IP on particular machines and operating systems are
raised. One such situation occurred when Mark Crispin, a staff
member at Stanford University and the author of the TOPS-20
TELNET implementation explains the difficulty of meeting the
anticipated January 1983 conversion from NCP to TCP/IP. TOPS- 20
was one of Digital Equipment Corporation's operating systems for
its DEC-20 computer. Crispin lists several reasons why his site
had found the BBN implementation for TOPS-20 unacceptable.
He proposes rewriting the code and questions how
"ARPA/DCA/whomever intends to enforce the non-use of NCP." He
writes, "The NCP/TCP conversion is of far greater complexity
than conversion from 32-bit to 96-bit leaders which took a few
days in 1978." Crispin notes that "It will be technically
difficult to enforce the non-use of NCP unless the IMPs are
somehow modified to intercept and disallow NCP messages."
Cautioning that, "There are a lot of PDP-10's on the ARPANET
right now, and they aren't about to vanish in a corner," he
observes, that "To my knowledge, there is no project at all to
implement TCP on WAITS, ITS, or TOPS-10; and the Tenex/TOPS-20
implementation has significant problems for a site which wants to
implement it."
In the same issue of the Digest, Jon Postel an ARPANET
pioneer and researcher at the Information Services Institute at
the University of Southern California (USC-ISI) who maintained
the RFCs explains the background of the TCP/IP protocols. Postel
writes:
"In recent years the ARPA Network Research Program has had
as one concern the interconnection of networks. In the course of
this research a family of protocols suitable for an internetwork
environment has emerged. The major Internet protocol documents
have been issued as RFCs."
He writes that "the situation has evolved to the point that
it is appropriate for the Internet family of protocols to replace
the old ARPANET protocols." Therefore an Internet Protocol
Handbook is being prepared by the Network Information Center
(NIC).
In a later message to the Digest, Crispin explains that he
was not opposed to TCP/IP. He is opposed to the pressure to
implement TCP/IP, not to the protocol. He writes:
"I'd like to answer a few confusions about my position
regarding the TOPS-20 implementation of TCP available from BBN. I
am not, nor have I ever been, opposed to the TCP protocol. I was
very impressed with the work done at the DoD Protocol Standards
conference a year ago. I've been urging the managers of the
Stanford local network effort to adopt TCP/IP as the local
network protocol for the past two years now. It is the software
that is presently avail able for TOPS-20 that I find distasteful."
He cautions that, "If the product DEC releases is less than
what we would like, it is because of their rush to meet the
deadline."
He continues, "It's a safe assumption that there is no way
that DEC can possibly have a rewritten TCP implementation for
TOPS-20 out in the field by the deadline date." He recommends
that other "DEC's customers are probably best off encouraging the
current project but being firm in stating that we must have a
rewrite which addresses the performance problems of BBN's TCP."
Explaining his opposition to the pressure of the January
1983 deadline, Crispin writes:
"So far as the comments on how to 'help/force people [to]
implement TCP/IP' go:"
"The whole tone of 'forcing' is itself inane. The intent of
my message was to discuss getting things moving towards solving
the software situation, not to create an anti-TCP/IP lobby. The
present TCP/IP software for TOPS-20 is unpalatable for most
sites; if 'forced' to implement TCP/IP on our systems we will
probably have to write the software ourselves. Of course that
would keep us from completing the projects our Network Sponsors
are supporting us to do..." -- Mark
In response, Postel describes how the move to TCP/IP from
NCP could be made mandatory. He describes how the IMPs could
technically be made to reject NCP protocols. Postel writes:
"There has been some talk of 'forcing' the move to TCP by
various administrative and policy measures. There was also a
claim that there was no technical way to force the abandonment of
NCP. It should be pointed out that a quite simple modification
to the IMP program would enable the IMPs to filter out and
discard all NCP traffic."
"As far as I know," he concludes, "there has been no
decision to do this, but you should be aware that it is
technically feasible."
Asking for other opinions on the criticisms of the TOPS-20
TCP/IP implementation, another contributor to the Digest writes:
"I have often heard criticisms of TOPS 20 TCP/IP
implementation, but never a defense. Does anyone from BBN or ARPA
care to defend their implementation or do they agree with the
criticisms?"
Urging all to respond to the list, the Digest includes
notices welcoming contributions. One such notice reads:
"Nearly a week has passed since the last issue, so I am
publishing the three letters that have arrived in the interim.
Considering the size of the mailing list, I can hardly imagine
that we have heard from every body who is working on networking
implementations. C'mon! Lets hear from everybody."
Cheers
Mike
Along with reports on various implementations of TCP/IP, the
TCP/IP Digest includes a report about work being done on the
TOPS-20 TCP implementations. The report explains:
"Most of our efforts during November have been directed at
TOPS-20 TCP/IP performance. In our timing experiments, we are
employing techniques such as PC sampling, control stack sampling,
and packet tracing...."
"We are also investigating another problem area that could
add significantly to the CPU-utilization of the TCP/IP: use of
1822 interfaces that transfer all 36 bits of the PDP-10 word
to/from the net, necessitating a (possibly) expensive bit-shuffle
in behalf of the 8-bit-oriented TCP. We are presently performing
experiments to determine the precise CPU-cost of this
bit-rearranging, and will publish the results when available."
The Article in ComputerWorld on Cutover
A notice appears in the December 23, 1981 issue of the
TCP/IP Digest that an article on the TCP/IP cutover appeared in
the trade magazine ComputerWorld. The notice explains:
Mike
"The 14 Dec issue of ComputerWorld has an interesting
article on the ARPANET TCP/IP cutover and it's commercial impact.
It might be of interest to TCP-IP Digest readers. Raleigh"
Also in this issue of the Digest are excerpts from the
ComputerWorld article. Bellovin includes his comments on the
ComputerWorld article in the margin of the copy. The
ComputerWorld article described the planned transition to TCP/IP,
explaining that:
"Considered the world's first packet network, ARPANET is
expected to become an Internet -- a network of networks -- ...
said an informed source, who revealed the cutover date."
Though the article noted that computer scientists were
confident in the TCP/IP protocols, "An ARPANET crash would
seriously disrupt American research and development in many
fields of science and technology, one expert maintained."
It explains that many TCP/IP developers believed the ARPANET
cutover could be achieved on Jan. 1, 1983, "but not all of them,
[an] ARPANET correspondence revealed."
The ComputerWorld article quoted some of the questions that
had been raised in the Digest about the TOPS-20 TCP/IP
implementation, explaining that, "This critic wrote, in his
ARPANET communique," that "the TCP process consumes between 40%
and 60% of the CPU. We simply cannot sacrifice that much of an
already-loaded CPU to implement a network."
The next issue of TCP/IP Digest includes discussion about
the dilemma for the mailing list of having articles published
elsewhere about issues raised in the Digest. Muuss writes:
Folks -
"It looks like somebody on this list is feeding copies of
the TCP/IP Digest to ComputerWorld magazine, which seems
delighted with this newfound source of 'inside' information.
While it is my intention that this list receive as broad a
distribution as possible, several tightropes must be carefully
tra versed:
He explains why he believes that such press coverage of
ARPANET discussions will cause a problem as it will lead to a
"marked decrease in the quantity of information that is offered.
Few of us expect our net mail to wind up published in the
commercial press," he warns, "and only the brave will knowingly
open themselves up to this kind of direct, external exposure."
The cost he proposes will be diminished information available to
those on the mailing list and "Those readers who desperately need
the information on what is happening may find their information
sources again reduced to RFC's and official notices, carefully
worded for public scrutiny." Muuss opens the issue up for
further discussion, writing:
"This digest was intended as an open forum? Is a direct
pipeline to the outside world too open? I solicit discussion on
this matter. Maybe we can reach a consensus? Happy New Year!"
-Mike Muuss
[Continued in Part 2]
[3b] Part 2
From the ARPANET to the Internet
A Study of the ARPANET TCP/IP Digest
and of the Role of Online Communication
in the Transition from the ARPANET to
the Internet
by Ronda Hauben
ronda@panix.com
[Continued from Part 1]
FA.digest-people Discussion
A discussion of the publication in ComputerWorld of
information from the TCP/IP Digest develops on FA.digest-people
available as an ARPANET mailing list and on Usenet. "My temporary
solution to this issue," Muuss proposes, "is to add the following
notice to the Masthead:
TCP/IP Digest
Thursday, 8 Oct 1981 Volume 1 : Issue 1
LIMITED DISTRIBUTION
For Research Use Only Not for Public Distribution
At least this ensures that anybody who gets fed a copy knows that
it is not supposed to be shouted to the treetops. Comments?"
A post from Christopher C Stacy at MIT disagrees with such a
publication identifier. Stacy writes:
"I think that the explicit banner on the masthead of the
Digest is a bad idea, because this will cause many people to
think that if such a banner is NOT present (i.e., on any other
Digests or on future TCP Digests) that it is alright to
redistribute the material."
Others disagree. Another article in the Digest explains: "I
don't agree. If SOMEONE uses the banner, then at least those
people who see it may stop and think about the issue, and other
digests may choose to use such a banner as well. If NO ONE uses
it, then I think we are more likely to perpetuate the kinds of
problems C Stacy mentioned earlier in his note. I think
elucidating by example is a fine thing, and one usually doesn't
wait for others to be consistent with one's good idea."
"The problem of ensuring that ARPANET mail is not
distributed outside of the network community," writes C Stacy,
"is a perpetual one because many of the users of the network are
unaware of the restrictions on the material."
Stacy describes an incident that occurred when MIT had to
fight for its continued existence on the ARPANET after an article
in the journal Datamation about the WINE-TASTERS mailing list
appeared. He also cautions about the possible liability problems
when evaluating and discussing various commercial products, as
with the INFO-TERMS mailing list which evaluated terminals.
He quotes a Defense Communications Agency (DCA) memo
restricting who could ftp files from ARPANET sites. "But laying
down the law," he writes, "is a fairly useless way of solving
this sort of problem. The problem is one of awareness, cooperation
and trust. Only if people understand and care, will they take steps
to protect a fragile institution like the ARPANET," he writes.
Another post notes that the mailing list digests "do not
exist as authorized publications." He recommends that they should
be considered "internal communications between research project
members authorized to use the net."
A message asking about the implications of the Ellsberg case
to this issue by Mike Muuse was answered by Paul Karger. Karger
writes:
"While putting a restricted distribution statement on a
digest may be a psychological limitation on distribution, there
are a couple of problems. First, since ARPA and DCA are part of
the DoD, there are specific regulations on what may or may not be
marked as FOR OFFICIAL USE ONLY."
"The regulations are in part designed to not let people
invent other kinds of markings. This dates back to the Ellsberg
case and the desire to limit the ability of government people to
conceal information from the 'public' (whoever that is)."
Karger notes that his familiarity with the regulations was
a little stale, but cautions, "I would be very careful about
developing new ways to restrict distribution of government
information."
Horton, however, points out that Usenet is a public bulletin
board system and thus that posts to it are considered to be
public. He writes:
"I just want to make sure the people on this list are aware
that each TCP digest is fed into USENET on newsgroup fa.tcp-ip.
This is sent to (currently) about 120 machines across the US and
Canada. (For those who don't know about USENET, it's a
distributed bulletin board system.) USENET specifically has a
policy that anything posted to net and fa newsgroups is public
information that can be redistributed to whoever wants it. The
point is that if you have anything you consider secret, it
probably shouldn't be mailed to the list."
"While I am under the impression that this policy is
consistent with the intent of the TCP-IP digest, if I'm wrong, it
may be necessary to remove the USENET feed from the mailing
list."
Horton continues: "It is possible that ComputerWorld got
their information from USENET, but from the wording of the
article, they seem to have gotten it from somewhere on the
ARPANET."
"It is easy to confuse private mail and public mailing
lists/newsgroups, and it seems clear that the quote from the
digest was written in a 'I'm talking privately to friends' frame
of mind. Clearly he didn't intend his words to be printed in
ComputerWorld. But it is important to remember that anything
which is mass-mailed is effectively published."
Through this discussion, concerns about limiting access to
ARPANET mailing list discussions were raised, and answered. The
limitations that the current state of relevant law would allow US
government officials to impose on access to ARPANET mailing list
discussions were considered.
This discussion demonstrates how the more limited
circulation of ARPANET mailing lists was challenged not only by
the prohibitions against government secrecy, but also by the
connection with Usenet, as Usenet made them available to broader
participation and to a broader and more open public forum.
TCP/IP Digest Adds Banner
Despite the many concerns raised in the Digest-people
discussion, the following issue of the TCP/IP Digest had a new
banner added to the issue.
LIMITED DISTRIBUTION For Research Use Only
--------
Not for Public Distribution
Explaining the reason for the banner, Muuss writes:
Folks -
"You probably noticed the new banner on the front of this
issue of the digest. While a copyright would be even better, the
Government can not hold a copyright, and the mechanics of having
somebody else copyright the Digest were just too much. So, the
notice on the front. The intention here is to warn readers of the
digest that the material contained herein is not for publication
or other forms of public distribution. At least this will
ensure that if copies get to the outside world (and they
undoubtably will), at least they will think twice before printing
it. Authors of letters to the digest who want to make a public
statement may mark their submissions accordingly. If this seems
unnecessary, we can always be more informal later."
Also, Muuss notes that though the previous Digest issue had
carried a copy of Internet Monthly that had been submitted to
him, he would "try and filter submissions from [such] unexpected
sources" like that. He explains "The intentions were all good,
but things didn't work out so well. Politics. Alas."
He then notes that though the next issue or two might
contain discussion of issues raised by the ComputerWorld article,
he hopes soon to get back to the focus of the Digest. He writes:
"In summary, then, I hope to wrap up discussion of the
administrative side of the digest in the next issue or two, and
resume our devoted discussion of Networking!"
Also he asks that those receiving the Digest at Usenet sites
contact him. He writes:
"I am interested in hearing from each USENET site which is
presently receiving the digest, to try and judge the size of the
readership. (Also from any other "multi-level indirect" network
which may be distributing the digest). Let's start hearing more
about networking concerns from the non-ARPANET sites, too."
Press Packet Proposed
Along with placing a notice on the header of the Digest, the
proposal was made to have an official press package to distribute
about TCP/IP. Muuss explains:
"Einar Stefferud <Stef@KA> and Vint Cerf <Cerf@usc-isi> have
come up with the idea of putting together a TCP/IP "Press
Package" which we could feed to Datamation and IBM and everybody
else who ought to hear about TCP/IP, but maybe hasn't. This
would be mostly a cut-and-paste job done to some of the existing
RFCs and IENs, along with descriptive text from previous digests,
and new contributions."
Muuss asks that those who want their Digest submissions to
be included in the press pack, to indicate that to him. "Only
clearly marked letters will be added to the press package file;
all others will go to the digest only," he notes.
TOPS-20 TCP/IP Implementation
In the November 23, 1982 digest, less than two months before
the cutover day, a description by Joel Golderger@USC-ISIB of the
efforts to locate the problems with the TOPS-20 TCP/IP
implementation appears in the digest. Goldberger explains:
"I can tell you what the situation is regarding IP/TCP
implementations on most DEC equipment. There are basically four
operating systems that people run on DEC 10/20's and two
operating systems that are run on VAXes.
On the 10/20's people are running:
TOPS-10
TENEX
TOPS-20
and ITS (The MIT Incompatible Timesharing
System)
"BBN has had an implementation of IP/TCP for TENEX and
TOPS-20 for some time and that is what we are running. Very few
other sites were willing to run this software though.
He described how DEC had proposed a better user-interface
for the TOPS-20 sites which "most of the TOPS-20 sites decided to
wait for." Also, he notes that although the original date that
delivery of the software was expected was July, the date was
delayed and it was now promised for December 1. However, this
would make it difficult for the code to be de bugged in time for
the cutover. He explains:
"Obviously once the code is delivered there will be some lag
before the support software gets written and debugged, and I
seriously doubt that all of that can be accomplished in the one
month before the switch over."
Other TCP/IP Implementations
Goldberger also notes that the BBN implementation of the
IP/TCP was being used by most of the TENEX sites on the ARPANET.
And that work was needed to get support programs to run under
TENEX. This work was being done at the NIC. Also, he notes that
Ken Harrenstien had been hired by MIT to implement IP/TCP on the
ITS machines (MIT AI/DM/ML/MC). However, Goldberger explains that
he knows of no other TCP/IP implementation for TOPS-10 (or WAITS)
that was either already avail able or in development.
For VAXes, he reports that people either run VMS or Berkeley
UNIX. For VMS there was a commercial product in binary with all
the usual servers and user programs (FTP/TELNET/SMTP) and a
library for establishing and controlling IP and TCP corrections.
His site at UCS-ISI had trouble using the program, but reported
the problems and would be testing the new version.
For TCP/IP for Berkeley UNIX there were two choices, one
from BBN and another from the University of California Berkeley.
His site has found both of them stable.
Preparing for the TCP/IP Cutover
In preparing for the cutover, the November 29, 1982 issue of
the TCP/IP Digest reports that ARPA held a 24-hour TCP-only test
on November 15, 1982. The test results reported were that 62% of
the number of packets that had been passed on the previous
Monday, were transported during the test. (Nov. 8, 15,283,672
packets, Nov. 15, 9,466,256 packets). The test provides a list of
packets passed on 97 nodes on the ARPANET.
The December 17, 1982 issue of the Digest reports the
results of the TCP-only tests on December 13 and 14. 89% of the
number of packets passed when compared with the packets passed
the same two weekdays the previous week. (Dec. 13 and 14,
28,446,350 packets, Dec 6 and 7, 31,802,350 packets)
The test results show the sites, but not the computers or
operating systems that were used by the hosts at those sites. A
test done a year later, on Oct 4, 1983 lists 190 hosts on the
ARPANET and reports how effective was their use of TCP/IP. This
report shows the varied computers and operating systems using the
TCP/IP protocol to communicate with each other. Several tests
were carried out, but hosts which failed the simplest test and
failed to communicate within the ARPANET using TCP/IP scored a 4.
Scores 1-3 showed varying abilities to communicate both within
the ARPANET and through gateways.
After the Cutover
The first issue of the TCP/IP Digest which appears after the
TCP Jan 1 1983 cutover is vol 2 Issue 1. It is dated Saturday
February 26, 1983. Muuss reports:
"While BRL's hosts started passing TCP traffic about 6-Jan,
we were not able to overcome all our mail difficulties until just
recently, so there have been no TCP Digest transmissions since
17-Dec-82. At this time, it should be 'business as normal' once
again.
Describing the impact of the cutover in a recent e- mail
exchange, Mark Crispin writes:
"DEC largely ignored the ARPANET at that time. There were a
few members of the TOPS-20 development team at DEC who talked
with us, but for the most part DEC was a separate world."
"DEC did not take the problem seriously until the fall of
1982. Pretty much everybody in the TOPS-20 world worked on TCP,
and nothing else, between then and the end of the year."
"I wrote the Telnet client and the SMTP client and server
for TOPS-20. There were other Telnet and mailer programs for
TOPS-20 prior to that time, but afterwards mine had more or less
a monopoly.
"In terms of other PDP-10 operating systems: some dedicated
people implemented TCP on TOPS-10, and that implementation
presently was ported to WAITS as well. TCP was also implemented
for ITS eventually. TOPS-20 had pretty much re placed TENEX by
this time, and the TCP transition was the final blow. Most TENEX
systems were shut down."
"DEC got the file system interfaced working in time. Barely.
I helped debug it, and wrote some portions of it, but the actual
author was Kevin Paetzold at DEC."
"The cutover happened on January 1, 1983 as scheduled. As I
speculated, DCA enforced the switch over from NCP to TCP by
modifying the IMPs (the equivalent of routers) to disallow NCP
messages. For about 6 months afterward the changeover there was
'reclama' which re-allowed NCP messages for certain sites -- but
they could only talk NCP to other sites with 'reclama'."
"In May of 1983, DEC canceled the PDP-10 hardware. This was
a devastating blow. It shifted the focus of subsequent software
work from 'develop new and cool things' to 'keep it working as
long as possible.' Consequently, the effort for 'new and cool
things' shifted to UNIX."
"The performance problems were never fixed in TOPS-20 TCP.
Nor were various bugs that caused periodic system crashes. It
probably would have been fixed, but as I said, DEC canceled the
PDP-10 computer 5 months after the TCP transition."
"The TOPS-20 TCP never was a very good performer. There was
some effort to retrofit some of the lessons learned from TCP on
UNIX, but it was never as thorough as it could be. PDP-10 systems
started being shut down in 1985, and this accelerated throughout
the 1980s. A couple of holdouts existed into the 1990s, but most
of those are gone as well."
"One aborted project due to the PDP-10 cancellation was a
rewrite of TOPS-20 TCP."
"Inevitable. Nobody would sink the funds for a TOPS-20 TCP
rewrite given that the machine had been killed."
"The network changed forever as a result of the cutover.
Several well-known systems died as a result. However, most
systems made the transition; and by the summer of 1983 the
transition was largely spoken of in the past tense. There were,
at that time, only a couple of hundred systems in total on the
network."
Broadening the Focus of the Digest
After the Jan 1983 cutover, Muuss broadens the topic of the
TCP/IP Digest to "Inter-Net Networking -- Design and
Implementation Issues." A new concern became the need for
updating the ARPANET host tables and the Internet gateway
entries. Explaining the need to get updated versions of the
ARPANET host tables, David Roode at SRI-NIC writes:
"With the cutover to TCP/IP on January 1, many more hosts
now have Internet capability. Besides the entries always present
in the ARPANET host table, you now will have use for Internet
Gateway entries. These are included as part of the standardized
DoD Internet Host Table originally described in RFC 810, dated 1
March 1982."
He explains that the NIC Hostnames Server (RFC 811) would
provide updated copies of the complete table. He also describes
how to TCP telnet to the NIC on the Hostname Server port to
retrieve the copies.
Muuss adds:
"[ Hosts are strongly encouraged to reload their host tables
frequently. Either when booting the system, or at certain times
during the week seems to be the best approach. -Mike ]"
Preparing for ARPANET-MILNET Split
Subsequent issues of the TCP/IP Digest begin to take up the
planned split between the ARPANET and MILNET into two separate
networks to create an Internet. The split would allow the MILNET
to be devoted to the operational activities of the Department of
Defense. And those on the ARPANET would be able to continue to
pursue network research activities. Gateways between the two
networks would provide inter-networking communication.
The Dec 3 1982 issue of the Digest carried a letter from
Col. Heidi Heinden the DDN (Defense Data Network) Program
manager. It announces:
"The existing ARPANET will be split into a network for
operational traffic (MILNET) and an experimental network which
will retain the name ARPANET."
MILNET was to have the Class A network number 26 and the
ARPANET would retain the Class A network number 10. The first
stage of the split was to take place around July 1983 utilizing a
feature of the IMPs which make it possible to create a logical
network and logically partition those on one network from having
access to those on another network. The second stage of the
split, to "involve an actual reconversion of backbone circuits,
making the separation of the networks a physical portioning," is
targeted for Jan 1984. At that time all the MILNET IMPs would
have to be relocated to "restricted locations."
In an article titled "My Own Personal Opinion", Muuss
explains that the "Internet concept makes this split an easily
accomplished thing thanks to the Internet gateways. However, the
'special' gateway is a thing which tends to diminish the value of
the split by only allowing mail traffic across it. I invite the
readers of the digest to discuss this issue."
Explaining his concerns about the restriction of traffic
between the two networks after the split, Muuss writes: "Seems
like many of the military people are scared of having University
students 'at large' on their network. There are some serious
loss-of-service issues which properly concern users of MILNET.
Discussion?"
In the June 21, 1983 Digest (Vol 2 Issue 10), further
details of the ARPANET/MILNET planned split are provided in an
excerpt from the DDN News-
letter 27. The excerpt explains:
"The existing ARPANET will soon be split into two separate
networks - the experimental ARPANET and the operational MILNET.
Hosts on the two networks will intercommunicate via mail bridges,
using the Internet gateway mechanisms to pass mail traffic
between hosts on the two networks. The mail bridges will, on a
controlled basis, provide full Internet gateway services for
MILNET hosts that request it."
The excerpt goes on to announce how the logical split which
would take place on October 4, 1983 would transform the ARPANET
into an Internet. The excerpt explains:
"Because it takes a large amount of time and effort to
physically split a network in a coherent manner, the ARPANET will
initially, on 4 October 1983, be logically partitioned by the use
of existing mechanisms in the IMPs to enforce segregation of
hosts and ACs into separate communities of interest. Each
community of interest (COI) becomes a virtual network, i.e.,
hosts (including TACS) in the same community can fully
inter-operate as is currently the case, while hosts in different
communities cannot directly intercommunicate. This, in effect,
transforms the ARPANET into an Internet in which the MILNET will
assume a new class A network number, network 26, while the
ARPANET remains network 10."
The memo explains that only hosts that had fully working
TCP/IP implementations (including ICMP, the host-gateway
protocol) would continue to have full service as only they would
be able to send (or receive) mail traffic through the mail
bridges to the hosts in the other networks. The memo notes how
important it is for hosts to convert from NCP to TCP for those
who hadn't yet completed the conversion.
Also the memo describes the physical split that would occur.
The goal is to complete the physical split in the first quarter
of 1984.
Writing in the Oct 11, 1983 issue of the Digest (Vol 2 Issue
18), Muuss describes the previous week and the initiation of the
MILNET split. Reporting on some of the problems, he writes:
"I write this letter almost a full week from the initiation
of the MILNET split, after having spent yet another night riding
shotgun on the mail queues, trying to make sure that we
re-establish connectivity before our 11-day "failed mail" timer
goes off. Most of the effort lies in running endless series of
tests to determine which hosts STILL have non-functional routing
tables between them and us."
"Sadly," he notes, "this digest will only be received by
people who are doing things right, so I have to resort to other
techniques for getting routing tables updated. Perhaps if we all
apply enough gentle persuasion, things can get tidied up in a
hurry."
"The problem," he explains, "you see, is that we at BRL have
really, truly *believed* in the viability of the Internet
concept. Of course, we still do," he continues, "although we
certainly have felt rather lonely in our little corner of the
Internet here, only being able to communicate with a 'select
few'."
He describes how one of BRL's machines was still connected
to the backbone, but to the MILNET backbone. All their other
machines were safely tucked away behind a local gateway, so that
they could develop "our own solutions to our communications
difficulties. And, therein lies the rub."
He gives credit to the PRIME gateway crew at BBN for their
work. "Pop a packet for BRLNET off to a BBN Prime gateway, and
things work perfectly (except for the MILARPA IMP blowing up
unexpectedly , but that's another story)."
He explains that the problem occurred even though only 5
Gateways had moved from the ARPANET to MILNET, and the BRL-
GATEWAY was probably one of the more noticeable ones. Many sites
had remembered to diligently update their host tables, but "not
so many sites remembered to (usually manually) extract the
current network topology from the GATEWAY section of the NIC
tables and to reflect those changes in their routing tables."
Reporting on some of the cries of distress he heard because
of the problems with the split, he writes:
"Where did our UNIX-Wizards mail go? ...."
"We heard the cries, and noticed the megabytes of
accumulation in our mail queues."
Muuss reports that his group spent the week:
"Phoning and writing to host administrators, trying to help
them figure out how to update their routing tables (a startling
number needed a good deal of help to discover what to change).
Running tests: Can we hit them from BRLNET2? BRLNET? A MILNET
host? A MILNET TAC? How about an ARPA host? Humbug."
And he adds that they observed their packet counts were down
by more than 50%.
Muuss concludes:
"TCP and IP work. We know that, it's a fact. But, there
seems to be an almost totally manual mechanism involved when it
comes time to "program" the IP routings. Disappointing. (I'd like
to note in passing that, except for loading new host tables into
all our hosts, the only thing Ron had to do was pop a new routing
table into our Gateway. Our part was easy). If somebody ever
'nukes the Internet until it glows, nothing will work. Not unless
we all take a serious look at improving the IP routing mechanisms
that exist in each and every host."
And he goes on to propose:
"I'd like to see the next few issues of the digest
concentrate on how the Internet as an integrated communications
system should "become aware" of changes in the underlying
communications configuration, so that in the future the
configuration of the network can undergo rapid changes (planned
and unplanned) and still continue operating. Think of the
flexibility this affords: responding to administrative edicts.
Government foolishness. Natural disaster. And yes, even *war*."
Recognizing Integrity of the Infrastructure
An article in a later issue of the Digest by Muuss is titled
"On the Undesirability of "Mail Bridges" as a Security Measure."
He writes:
"Seeing the last few messages brings back to mind the ugly
prospect looming ever larger: that we will not have ONE Internet,
and we will not have TWO Internets, but we will in fact have
One-and-a-Half Internets, stuck together with mail-only 'bridges'
(i.e. Data Fences), which will prevent the ARPA EXPNET and the
MILNET communities from exchanging data with each other. In my
nightmares, I see things degenerating to much the same level of
service as where the Internet touches on 'foreign' (non-TCP)
networks today. Unable to retrieve files, important data will be
shipped as mail, and will suffer the indelicacies of having
headers and trailers slapped on it, spaces and dots and tabs
munged with, etc. Reprehensible kludges like UUENCODE/UUDECODE
will have to become commonplace again. It's bad enough having to
mail files to USENET, CSNET, etc; but between the EXPNET and
MILNET? Come on!"
Continuing, he explains:
"I'm entirely in favor of separating the backbones of the
two networks; in addition to giving DCA a much greater degree of
control over engineering the MILNET portion, it also permits the
ARPANET portion to do horrible things to their IMPs, to play
partitioning experiments, and generally have enough of a reprieve
from operational considerations to be able to do meaningful
experiments again. All this is good."
He also describes why it was good that the split happened as
it ended the era of a single packet switching network and put on
the agenda solving the problems of inter-networking:
"Forcing the split was a good thing, too. It pol ished off
NCP once-and-for-all, and it demonstrated that the IP protocol
really *does* operate as claimed. Funneling all IP
communications through 'n' gate ways (n=5 at present) is good,
too. Gets people thinking about multi-path routing algorithms,
and provides a good 'safety valve', just in case there should
ever be valid military reasons for separating the networks."
He describes other benefits of having made the change. Then
he explains his concern with what is happening. He writes:
"Hiding ourselves behind mail-only bridges is only asking
for trouble, later on. Being on the MILNET isn't significantly
different from offering commercial (or AUTOVON or FTS) dial-up
service, in terms of the threat posed by an outsider trying to
get in. Now the CLASSIFIED community, that's different. But
there's none of that sort of information on the MILNET, right?"
"So, here is a loud plea from one (military) re searcher who
says 'Don't cut the lines of communication!' An emphatic YES to
security. Do it by the regulations! But don't depend on partial
network connectivity as a security measure -- it won't help, and
it sure can hurt. (Ouch!)."
Your (Civil) Servant,
-Mike Muuss
Leader, Advanced Computer Systems Team
U. S. Army Ballistic Research Laboratory
Conclusion
Vol 2 Issue 18 with this plea by Muuss is the last issue of
TCP/IP Digest that this researcher has been able to locate. But
the concerns it raises have great importance even today, 15 years
later. This last message by Muuss raises the importance of
maintaining the integrity and constructive development of the
Internet. The role played by Muuss in this mailing list and the
subsequent accomplishment of a large scale engineering
achievement, demonstrates that communication in general, and
communication between government employees and citizens, in
particular, contributes to the successful achievement of social
and engineering goals like the cutover to TCP/IP and the creation
of an Internet. Muuss's final plea to keep connectivity flowing
between those working for the U.S. government and the rest of the
world, is an important precaution to the U.S. government, and to
governments of other countries around the world as well, to
increase the access of government employees to the public on the
Internet.
Most importantly, Muuss's plea emphasizes that there is a
crucial role for open and functioning lines of communication.
They make possible engineering achievements involving a large
number of people, as did the conversion from NCP to TCP/IP and
later the split between the ARPANET and MILNET to create two
separate networks linked as part of the Internet. It is important
that such communication in successful projects be the subject of
research and study, just as the technological achievements made
possible should be the focus of study.
The U.S. government is currently planning to transfer a key
component of the Internet, the operation of the Internet root
server and directory functions, from the control and oversight of
the U.S. government into an association controlled by private
corporate interests. The difficulties encountered by Muuss in
converting his site from the ARPANET to MILNET show how important
the proper functioning of the routing tables and directory
structure is to the integrity of the Internet.
An even more significant reason for the need for research
into the early days of networking and into the vision that guided
the development of the Internet, however, is that the early
vision of an Internet connecting different networks, networks
with different purposes such as the research orientation of the
early ARPANET (EXPNET) and the operational orientation of
MILNET, presents an important model for the development of the
Internet. This early model recognized the integrity of the
different participating networks, not allowing either one to
overcome the other, but providing a way for diverse networks to
maintain communication while pursuing their own purposes. The
requirement on both networks was that they recognize and support
the integrity of the Internet as a means of communication. This
would suggest that in the future there could be RESEARCHNETs,
SCHOOLNETs, different CITYNETS, MILNETS, COMMERCIAL-NETS etc and
that no one net would dominate or determine what happens on all
the other nets. Instead all would recognize the importance of
maintaining inter-networking communication and of protecting the
integrity of that communication by guarding the accuracy and
integrity of crucial components, like the routing tables. This
research into the history and development of the Internet
provides a means for understanding the vision and practice that
has given birth to the current Internet, and the principles to
consider when planning and implementing future developments. [A
version of this draft together with footnotes and appendices is
available via e-mail from the author ronda@panix.com]
[End]