Supplement Controversy Over the Internet July, 1998

Who Are the Stakeholders in

the DNS Controversy Over

the Future of the Internet?

On June 5, 1998 the U.S. government issued a White Paper elaborating its plans and position to fundamentally change the control and ownership over the Domain Name System (DNS) that is the nerve center of the Internet. The basic premise of the White Paper is that the DNS must be put into private hands.

Such changes are very important issues for the public of the U.S. and around the world to consider and discuss as the Internet, in the words of Judge Dalzell of the U.S. Federal District Court, is: "a far more speech enhancing medium than print, the village green or the mails"

In the court case of ACLU vs. Reno over the Communications Decency Act, the Federal Court Judges wrote that "The Internet is... a unique and wholly new medium of worldwide communication."

In his opinion in that case, Judge Dalzell goes on to direct the U.S. government saying, "We should also protect the autonomy that such a medium confers to ordinary people as well as media magnates.

Does the White Paper issued by the U.S. govern
ment undertake to protect the autonomy that the Internet confers to ordinary people? Will placing the DNS into private hands (most likely dominated by powerful corporate entities) be a way that the U.S. government can fulfill on its obligation to ordinary people?

This special issue of the Amateur Computerist provides some of the kinds of discussion and research that is important in considering the plans of the U.S. government. First we include a discussion that oc
curred on the Netizens mailing list over what would be a position toward the plans of the U.S. government

Table of Contents

Stakeholders in the DNS Controversy	Page 1

Netizen List DNS Discussion	Page 2

Study of the ARPAnet TCP/IP Digest	Page 10

An Introduction to TCP/IP	Page 22

that would reflect the interests of Netizens, i.e. of those who contribute to the Net to help it grow and flourish as a means of global communication. This online discussion raises issues about the Framework that U.S. government advisors have created to make the Internet into a Commercenet, rather than creating a "Framework for the Net as a New Means of Interna
tional Communication," that a government would be creating if it were to uphold its obligation to protect the autonomy of the ordinary people, as the U.S. Federal District Court mandated.

Also in this issue is an article describing the cut-
over from NCP to TCP/IP on the ARPAnet in 1983 and the following split between the ARPAnet and MILNET into two separate but interconnected Nets as the earliest version of an Internet. This article demon
strates the vision for the development of the Internet as a network of diverse nets with no one net dominat
ing the others. This helps to clarify the model pre
sented by Vint Cerf for the development of an Internet in 1978. In that document he explains:

"The basic objective of this project is to establish a model and a set of rules which will allow data networks of varying internal operation to be intercon
nected, permitting users to access remote resources and to permit inter-computer communication across the connected networks."

The rush to give the nerve center of the Internet, the DNS functions which include the root server over to some private interests, in a to be created organiza
tion which doesn't even have a public proposal for its founding 4 months before it is to get control of key Internet functions, is a very serious change of direc
tion from the obligations that a government has to its citizens.

Also in this issue is an article about the nature of TCP and IP and how they provide for communication among diverse networks.

Given that the originating conception of the Internet was to be a Net of Networks and that no one network was to dominate others, it is imperative that these origins be discussed and understood and actions like that proposed by the U.S. government Green and White papers be widely discussed and challenged. Can any private sector organization even begin to protect the "autonomy of ordinary people" to have the ability to communicate globally? Isn't that is an obligation for government/s who have a social obliga
tion to their peoples?

We hope this special issue will serve to raise some of the important questions surrounding the plans by various groups and interests for the future of the Net. We don't want to be going backward to a single Net, to an ARPAnet, but this time one that is devoted to buying and selling and to commercial activities. Instead we want to go forward to the further develop
ment and flourishing of the Internet as "a unique and new means of worldwide communication." We hope this special issue will help to encourage the discussion and activities that will make this vision more and more a reality.

Netizen List DNS Discussion

From: rh120@columbia.edu (Ronda Hauben)

Newsgroups: alt.society.netizens

Subject: [netz] Internet as Communications Medium - Need for Discussion

Date: 20 Mar 1998 11:07:07 -0500

I welcome comments and discussion on the following draft and on the issues it is raising.

Internet as a Communication Medium

and How That is not Reflected in the

Proposal to Restructure the DNS

There is currently a proposal by the U.S. govt to change the way that Internet domain (site) names are given out, and thus to affect in an important way the future of the Internet.

The proposal is at:

http://www.ntia.doc.gov/ntiahome/domainname/ domainname130.htm

March 23 is the end of the time that one can submit comments on it to the NTIA and comments up till then can be submitted electronically.

It is interesting to look at the Framework that Ira Magaziner, the advisor to the President, has created looking at the future of the Internet.

In the document called Framework, he fails to mention or consider that the Internet is an important new *communication* medium. Instead he substitutes the word *commerce* for *communication* and sets out a framework for making the Internet into an important new means of commerce.

In two sentences at the beginning of his document he says that "the Internet empowers citizens and democratizes societies" and then he goes on and spends the next 24 pages describing changes that have to come about to make the Internet into an electronic marketplace for business.

Nowhere in the "Framework" does he discuss the fact that Netizens are those who come on line to contribute to the growth and the development of the Net. Instead Magaziner sees the Internet as "being driven... by the private sector."

If the "Framework" has *no* understanding of the ways that the Internet and Usenet contribute to and make possible new forms of *communication* between people, then there is no way that the proposal he has made for changing the DNS (domain name system), that assigns address and maintains the lookup tables, can help to facilitate the communication that is so important as the essence of the Internet. The Proposal "Improvement of Technical Management of Internet Names and Addresses: Proposed Rule" is listed in the February 20, 1988 Federal Register. (And one can make comments on it till March 23. It is also online at the NTIA web site.)

Instead of examining how this *communication* has been developed and why it is so important, Magaziner is rushing to replace the current system (which was also developed without any analysis of the importance of the communication aspects of the Internet) with a "privatized" new form.

In this "privatized" new form, he has proposed creating a "membership association" that will repre
sent Internet users. So Internet users are not to repre
sent themselves, but the U.S. government is proposing creating a rubber stamp organization to promote its attempt to change the Internet from a medium for human-to-human communication into something that only conceives of users as "customers" of unregulated advertisers and other forms of business.

This is hostile to the whole nature and develop
ment of the Internet. Magaziner claims that the "marketplace, not governments should determine technical standards." What he seems to have no knowledge of is how government support for a standards process that wouldn't be dominated by the most powerful corporations, is some of how helpful standards have been developed. Instead Magaziner is trying to recast the standards development process to mirror the unhealthy situation that develops when the supposed "marketplace" is allowed to set standards.

Magaziner is proposing creating a supposed "not for profit" corporation to take over the domain name system functions currently being administered by IANA (the root system and the appropriate databases). This new corporation he proposes will have a board of directors which will be made up of 5 members who are commercial users. There are proposed two direc
tors from "a membership association of regional number registries", two members designated by the Internet Architecture Board (IAB) and two members from an association he is proposing be created repre
senting domain name registries and registrars, and 7 members from the membership organization he is creating. (Of which he says at least one of those board seats could be designated for an individual or entity engaged in non-commercial, not-for-profit use of the Internet, and one for individual end users. The remain
ing seats could be filled by commercial users, includ
ing trademark holders.) Thus he is basing his proposal on to-be-created associations that will not be based on the Internet, but created to provide for commercial control of the domain naming system.

The proposal is an effort to change the nature and character of the Internet from a means of communica
tion to a means of "commerce." It is almost like claiming that the advertisers in a newspaper should have an organization that will assure their control of the newspaper, and ignoring the fact that the newspa
per exists to present the news, editorials, etc.

The Internet has been developed and continues to be for most of its users, a place where one can com
municate with others, whether by email, posting to Usenet newsgroups, putting up a WWW site, etc. As such it is the nature of this communication that has to be understood and protected in any proposals to change key aspects of how the Internet is adminis
tered.

Also the Internet makes possible communication with people around the world. Thus creating a board where commercial businesses are the main controlling interests is hostile to facilitating this communication. While Magaziner's proposal is being distributed electronically, it gives no indication of where it came from, and why it fails to be based on the most essen
tial aspects of the Internet. Why doesn't the advisor making up such a proposal ask for discussion on line and participate in the discussion so as to be able to create a proposal that will reflect the needs and interests of those who are online rather than a narrow group of commercial interests. The Judges in the Federal District Court in Philadelphia hearing the CDA case (the Communications Decency Act) and the Supreme Court Judges affirming their decision recognized that the Internet is an important new means of mass communication. The Judges in the Federal District Court case wrote: "The Internet is... a unique and wholly new medium of worldwide com
munication."

Judge Dalzell, in his opinion, wrote explaining how "The Internet is a far more speech-enhancing medium than print, the village green, or the mails.... We should also protect the autonomy that such a medium confers to ordinary people as well as media magnates.... There is also a compelling need for public education about the benefits and dangers of this new medium and Government can fill that role as well."

However, there is no indication in either of Magaziner's proposals, the longer "Framework" proposal, or the specific proposal to restructure the DNS, that he is interested in or has considered the benefits of the Internet for the public of the U.S. or elsewhere around the world. Instead he is only putting forward the wishes of certain commercial entities who want to grab hold of the Internet for their own narrow purposes. By restructuring the domain naming system in a way that can put it up for control by a few com
mercial interests, Magaziner's proposal is failing to protect the autonomy that the medium confers to ordinary people, as the court decision in the CDA case directed U.S. government officials.

The ARPAnet and Internet (up till 1995) devel
oped because of an Acceptable Use Policy encourag
ing and supporting communication and limiting and restricting what commercial interests were allowed to do. As such it developed as an important means of people being able to utilize the regenerative power of communication to create something very new and important for our times.

Pioneers with a vision of the future of the Internet called for it to be made available to all as a powerful education medium, not for it to be turned into some
thing that would mimic the worst features of a so called "democratic nation" which reduces the rights and abilities of its citizens to those of so called "cus
tomers" of unregulated and unaccountable commercial entities.

The Internet and the Netizens who populate the Internet have created something much more important than the so called commercial online "marketplace" that the Framework is trying to create. Netizens have created an online international marketplace of ideas and discussion which is needed to solve the complex problems of our times. The process of "privatizing" what is a public trust will only result in more prob
lems and fights among the commercial entities that are vying for their own self interest, rather than having any regard for the important communications that the Internet makes possible.

Both the government processes and purposes in proposing the DNS restructuring do not ground themselves on the important and unique nature of the Internet. Proposals and practices to serve the future of the Internet and the Netizens who contribute to that future, can only be crafted through a much more democratic process than that which led to the current proposal. There is a need to examine the processes that have actually given birth to and helped the Net to grow and flourish, and to build on those processes in creating the ways to solve the problems of the further development of the Net. Sadly Magaziner's proposal has ignored that process, and thus we are left with a proposal that doesn't reflect the democratic and communicative nature of the Internet and so can only do harm to its further development and cause ever more problems.

Ronda Hauben

ronda@panix.com

Comments and Discussion needed!

Netizens: On the History and Impact of Usenet and the Internet

http://www.columbia.edu/~hauben/netbook/

and in print edition ISBN # 0-8186-7706-6

From: markus.kruggel@uni-duisburg.de (Markus Kruggel)

Newsgroups: alt.society.netizens

Subject: Re: [netz] Internet as Communications Medium - Need for Discussion

Date: 20 Mar 1998 16:28:50 -0500

Hello Ronda,

On 20-Mar-98 17:05:11, Ronda Hauben wrote:

>There is currently a proposal by the U.S. govt to

> change the way that Internet domain (site) names

> are given out, and thus to affect in an important

> way the future of the Internet.

Thanks for pointing it out to me. After reading this document and your draft, I think this document is a good starting point to discuss two crucial matters of the future of the Internet: who will control and set standards and in which way will the Netizens be represented.

>This is hostile to the whole nature and

> development of the Internet. Magaziner claims

> that the "marketplace, not governments should

>determine technical standards." What he seems to

> have no knowledge of is how the government

> support for a standards process that wouldn't be

> dominated by the most powerful corporations, is

> some of how helpful standards have been

> developed. Instead Magaziner is trying to recast

> the standards development process to mirror the

> unhealthy situation that develops when the

> supposed "marketplace" is allowed to set

> standards.

As setting the standards of something is a power
ful means to determine its future development, setting the Internet standards can't be done by markets as long there's still an agreement that the net has more than the commercial function, and especially when the social implications of the net are stressed. Social interests can't be managed through a market mecha
nism as social interests always need a reconciliation of the strong and the weak that the market simply cannot accomplish: the means of communication on a market is money and so the strong ("rich") can gladly ignore any opposition of the weak ("poor") as those don't have the means of getting through to the arena of the market. In our case that means that any standards set by "markets" will not promote any social interests that are opposing the commercial interests.

That brings me to the second point: the social interests as well as the commercial interests regarding the net have to be identified as well as their possible connections to Internet standards. To explain what I mean: in the early 80s a communication system called BTX was introduced in Germany (quite similar to Minitel in France and other systems) that used the phone line and the TV to give electronic information to the user. This system had a channel bias, that means the channel from the network to the user was much bigger than the channel from the user to the network (I think it was 1200 bps vs. 75 bps). Possible net standards nowadays could go into a similar direc
tion, converting it into a one way street that serves the needs of commercial interests while those pedestrians can still find their way on the sidewalk.

To actually fight against such a threat, it is IMO vital that both interests are identified and translated into "standard matters", to prevent that we discover afterwards that a change of a standard led to a advan
tage of the commercial interests on cost of the social interests.

>Magaziner is proposing creating a supposed "not

> for profit" corporation to take over the domain

> name system functions currently being

> administered by IANA (the root system and the

> appropriate databases). This new corporation he

> proposes will have a board of directors which (...)

>7 members from the membership organization he

> is creating. (Of which he says at least one of those

> board seats could be designated for an individual

> or entity engaged in non-commercial, not-for-

>profit use of the Internet, and one for individual

> end users. The remaining seats could be filled by

> commercial users, including trademark holders."

Here's the other point why I think the proposal could have very negative effects on the net's future: representation is mainly built on who is paying. In such a board the "non-commercial, not-for-profit" voice would only be heard - if at all - but would not be able to influence any of the decision made. Such a model of representation would be another means of ensuring a domination of commercial interest in crucial matters of net administration.

And if it is applied in the case of the DNS admin
istration, why shouldn't this be the model for other areas: a few technicians, many commercial users and one "non-commercial, not-for-profit" voice.

>The proposal is an effort to change the nature and

> character of the Internet from a means of

> communication to a means of "commerce."

I agree wholeheartedly to this comment.

>While Magaziner's proposal is being distributed

> electronically, it gives no indication of where it

> came from, and why it fails to be based on the

> most essential aspects of the Internet. Why doesn't

>the advisor making up such a proposal ask for

> discussion on line and participate in the

> discussion so as to be able to create a proposal

> that will reflect the needs and interests of those

>who are online rather than a narrow group of

> commercial interests.

Indeed. A more open and democratic way of discussing these matters is needed. Somehow our interests have to find their way into the discussion but I'm quite unsure how this could be solved. Hopefully, as Ronda pointed this document out to us, we are able to discuss the implications of this proposal and make them more public on the net (that is, if this isn't the case already).

Bye,

*Markus Kruggel, 40217 Duesseldorf, Germany*

markus.kruggel@unidui.uni-duisburg.de

http://online-club.de/members1/rp10930/

From: astingsh@ksu.edu (kerry)

Newsgroups: alt.society.netizens

Subject: Re: [netz] Internet as Communications Medium - Need for Discussion Date: 21 Mar 1998 18:48:58 -0500

The Proposal seems to contradict itself several times. In itemizing the reasons for change, it's clear that the concept of "government" as exactly the stabilizing force required in society has lost out to "Government" as merely an entrenched bureaucracy. The initial premise that the Net *should* be completely commer
cialized is maintained, despite the fact that it is "increasing commercial value" of domain names which leads to trademark conflicts, while the "wide
spread dissatisfaction" exists only among those who see a *commercial* opportunity in DN registration.

Again, "Certain technical management functions require coordination. In these cases, responsible, private-sector action is preferable to government control." - but, "we divide the name and number functions into two groups, those that can be moved to a competitive system and those that should be coordi
nated." How private-sector coordination is to differ from private-sector competition is not explained., or, if "objective criteria" are found, what the means are of bringing them into wide acceptability if the first guess proves faulty.

One is reminded of the proposed Multilateral Agree
ment on Investment, which would give corporations the power of nations, with all the benefits of govern
ment with none of the disadvantages, like equal representation or free speech. Perhaps that's all one should expect of a concoction of the OECD and the cohorts of international business, but it's a bit alarm
ing to see the USG, the bastion of democracy, ignor
ing - indeed actively dismantling - its own fundamen
tal principles.

kerry

========

www.ntia.doc.gov/ntiahome/domainname/domainna
me130.htm

From: ronda@panix.com

Newsgroups: alt.society.netizens

Subject: Re: [netz] Internet as Communications Medium

Hello Markus and others on the Netizens Mailing list.

I wrote an answer to this on March 23, but somehow it got lost, and then things got very hectic and I haven't had a chance till now to respond. But I did want to respond so please excuse how late the response is.

>From: markus.kruggel@uni-duisburg.de (Markus

> Kruggel)

>Newsgroups: alt.society.netizens

>Subject: Re: [netz] Internet as Communications

> Medium - Need for Discussion

>Date: 20 Mar 1998 16:28:50 -0500

> Hello Ronda,

>On 20-Mar-98 17:05:11, Ronda Hauben wrote:

>>There is currently a proposal by the U.S. govt to

>> change the way that Internet domain (site) names

>> are given out, and thus to affect in an important

>> way the future of the Internet.

>Thanks for pointing it out to me. After reading this

> document and your draft, I think this document is

> a good starting point to discuss two crucial

> matters of the future of the Internet: who will

> control and set standards and in which way will

> the Netizens be represented.

I agree that there is a need to discuss the two topics you mention:

1) who will control and set standards

2) in which way will the Netizens be represented.

There is one other topic I think very important, which is

3) what is the nature of the Net as a new medium of international communication and how to nourish and continue to develop it.

>As setting the standards of something is a

> powerful means to determine its future

> development, setting the Internet standards can't

> be done by markets as long there's still an

>agreement that the net has more than the

>commercial function, and especially when the

> social implications of the net are stressed. Social

> interests can't be managed through a market

>mechanism as social interests always need a

> reconciliation of the strong and the weak that the

> market simply cannot accomplish: the means of

Yes the social implications and importance of the Net need to be considered. This is more important than any commercial function. There is only market dysfunction in reality. What the market means in the U.S. is the development of unregulated, govt support for monopolies like Microsoft.

>communication on a market is money and so the

> strong ("rich") can gladly ignore any opposition of

> the weak ("poor") as those don't have the means...

Interesting. But why do you say "the means of communication on a market is money" ?

I agree that money (or some other form of power) is what functions to determine who wins and who loses, but I am interested in why you say this is communication.

>of getting through to the arena of the market. In

> our case that means >that any standards set by

> "markets" will not promote any social interests

>that are opposing the commercial interests.

Yes this is helpful. "Standards" cannot be set by a "market" mechanism as it only makes what the most powerful wants the "standard".

>That brings me to the second point: the social

> interests as well as the commercial interests re-

>guarding the net have to be identified as well as

>their possible connections to Internet standards. To

>explain what I mean:

This is helpful- I agree that the social interests have to be identified.

How do we work to have that happen?

In the U.S. at least, the government is *only* interested in what the commercial interests want, and not at all interested in what the people or Netizens want.

Somehow we need to find a way to not just react to the government support for the commercial sector, but we need to find a way to define what are the social interests and how to work to have them developed.

I was thinking perhaps to try to develop a "Framework for the Net as a New Means of Interna
tional Communication" as opposed to the Magaziner Framework of the Net for Commerce.

But I don't know if that is the way forward.

However, I do think it is important to try to identify the communication aspects of the Net and then how to continue to support and spread the advantage this makes possible more broadly.

>in the early 80s a communication system called

> BTX was introduced in Germany (quite similar to

> Minitel in France and other systems) that used

>the phone line and the TV to give electronic

> information to the user. This system had a channel

> bias, that means the channel from the network to

> the user was much bigger than the channel from

> the user to the network (I think it was 1200 bps

> vs. 75 bps). Possible net standards nowadays

>could go into a similar direction, converting it into

> a one way street that serves the needs of

> commercial interests while those pedestrians can

> still find their way on the sidewalk.

This is a very helpful example.

I am interested in what you think is the way we should try to go forward to have the broader social interests with regard to the Net discussed and brought onto the public agenda.

>To actually fight against such a threat, it is IMO

> vital that both interests are identified and

> translated into "standard matters", to prevent that

> we discover afterwards that a change of a standard

> led to a advantage of the commercial interests on

> cost of the social interests.

I am trying to understand how we do this.

>>Magaziner is proposing creating a supposed "not

>> for profit" corporation to take over the domain

>> name system functions currently being

>> administered by IANA (the root system and the

>> appropriate databases). This new corporation he

>> proposes will have a board of directors which

>>(...) 7 members from the membership

>> organization he is creating. (Of which he says at

>> least one of those board seats could be

>> designated for an individual or entity engaged in

>> non-commercial, not-for-profit use of the

>> Internet, and one for individual end users. The

>> remaining seats could be filled by commercial

>> users, including trademark holders."

>Here's the other point why I think the proposal

> could have very negative effects on the net's

>future: representation is mainly built on who is

>paying. In such a board thee "non-commercial,

> not-for-profit" voice would only be heard - if at all

> - but would not be able to influence any of the

>decision made. Such a model of representation

> would be another mean of ensuring a domination

> of commercial interest in crucial matters of net

>administration.

Yes - Magaziner's proposal was only to take a crucial aspect of the Internet – the DNS (Domain Name System) and give it over to the commercial sector. This will create a real problem as the commer
cial interests have a very different agenda with regard to Internet development than the Netizen or user agenda.

It seems important to find some way to work to challenge such a power grab and also the whole backhanded way this is all being done. Magaziner didn't come online and ask for comments and discus
sion on what should be done regarding the DNS -- and there are U.S. govt newsgroups where he could have done so.

Instead he seems to have responded to the pro
posals by the commercial interests to give them this important aspect of the Internet. There does seem to be a lot of opposition to what Magaziner is doing -- it is a problem for many so it would be good to see if there could be a common battle, or some alliance of all those who will be harmed by this proposal.

>And if it is applied in the case of the DNS

> administration, why shouldn't this be the model

> for other areas: a few technicians, many

> commercial users and one "non-commercial,

> not-for-profit" voice.

Yes - and in fact the Net then to made into mainly a vehicle for commerce. I noticed recently that some of the search engines mainly list commercial listings when you search for something, rather than the broad view of what they used to list.

>>The proposal is an effort to change the nature and

>> character of the Internet from a means of

>> communication to a means of "commerce."

>I agree wholeheartedly to this comment.

I wonder if it would be worth trying to write a framework for the Internet as a means of communica
tion.

>>While Magaziner's proposal is being distributed

>> electronically, it gives no indication of where it

>> came from, and why it fails to be based on the

>> most essential aspects of the Internet. Why

>> doesn't the advisor making up such a proposal

>> ask for discussion on line and participate in the

>> discussion so as to be able to create a proposal

>> that will reflect the needs and interests of those

>>who are online rather than a narrow group of

>> commercial interests.

>Indeed. A more open and democratic way of

>discussing these matters is needed. Somehow our

> interests have to find their way into the discussion

> but I'm quite unsure how this could be solved.

>Hopefully, as Ronda....

I wonder if there are mailing lists where govt officials are discussing these issues with the commer
cial interests - in the past the com-priv (commercial
ization - privatization) functioned to provide for such discussion (but it doesn't seem to do so much lately) But if one tried to bring up social interests, one was attacked.

But there seems to be a need for a Netizen framework for the future of the Net - and then to apply this in responding to the commercial frame
work.

>pointed this document out to us, we are able to

> discuss the implications of this proposal and make

> them more public on the net (that is, if this isn't >the case already).

I didn't see much discussion of the DNS on Usenet - actually I don't know what newsgroups would be discussing it.

I wonder if anyone on the Netizens list knows of where such discussion has taken place online.

But in any case, it hasn't been open and obvious.

>*Markus Kruggel, 40217 Duesseldorf, Germany*

>markus.kruggel@unidui.uni-duisburg.de

Ronda

ronda@panix.com

Date: Sun, 31 May 1998 18:06:46 -0400 (EDT)

From: markus.kruggel@uni-duisburg.de

Subject: [netz] Internet as a Means of Communication - Need for Discussion

Hi all,

sorry for this late reply, but my workload here was tremendous, and I wanted to write a decent answer as I find the topic quite important.

On 08-Apr-98 03:35:08, Ronda Hauben wrote:

>>>There is currently a proposal by the U.S. govt to

>>> change the way that Internet domain (site) names

>>> are given out, and thus to affect in an important

>>> way the future of the Internet.

>>Thanks for pointing it out to me. After reading this

>> document and your draft, I think this document is

>> a good starting point to discuss two crucial matters

>> of the future of the Internet: who will control and

>> set standards and in which way will the Netizens

>> be represented.

>I agree that there is a need to discuss the two topics

> you mention:

>

>1) who will control and set standards

>2) in which way will the Netizens be represented.

>

>There is one other topic I think very important,

> which is:

>

>3) what is the nature of the Net as a new medium of

> international communication and how to nourish

> and continue to develop it.

I agree. But IMO 3. comes before 1. and 2. as the answer(s) to this question will determine possible answers to 1. and 2.

>>As setting the standards of something is a powerful

>> means to determine its future development, setting

>> the Internet standards can't be done by markets as

>> long there's still an agreement that the net has

>> more than the commercial function, and especially

>> when the social implications of the net are

>> stressed. Social interests can't be managed through

>> a market mechanism as social interests always

>> need a reconciliation of the strong and the weak

>> that the market simply cannot accomplish: the

>> means of communication on a market is money

>> and so the strong ("rich") can gladly ignore any

>> opposition of the weak ("poor") as those don't have

>> the means

>Interesting. But why do you say "the means of

> communication on a market is money" ? I agree that

> money (or some other form of power) is what

>functions to determine who wins and who loses, but

> I am interested in why you say this is communica-

>tion.

I was a bit unclear here, I suppose. What I meant was that communication on a market is realized by setting (seller) and offering (buyer) prices. What's communicated on market are plans: plans to sell or to buy at a certain price. So, it's probably better to say that all market communication *refers* to money instead of saying the money is the *means* of com
munication on a market. However, both lead to same result: whatever can't be formulated in terms of quantities and prices can't be communicated on market.

>>That brings me to the second point: the social

>> interests as well as the commercial interests

>> regarding the net have to be identified as well as

>>their possible connections to Internet standards. To

>> explain what I mean:

>This is helpful- I agree that the social interests have

> to be identified.

>

>How do we work to have that happen?

I think those who have the interests have to formulate them. I see that this bears another problem, because the broad majority of people around the world who have *no* access to the Internet would be ex
cluded from this process. If this happens, chances are that interests that those people have would be ex
cluded, too.

>In the U.S. at least, the government is *only* inter-

>ested in what the commercial interests want, and not

> at all interested in what the people or Netizens want

> which is what is in the best interest of the society.

Same here in Germany, I'm afraid.

>Somehow we need to find a way to not just react to

> the government support for the commercial sector,

> but we need to find a way to define what are the

> social interests and how to work to have them

> developed.

I think this mainly goes via influencing the public agenda. My idea concerning this are described a little bit further down.

>I was thinking perhaps to try to develop a "Frame-

>work for the Net as a New Means of International

> Communication" as opposed to the Magaziner

> Framework of the Net for Commerce.

>

>We need to try to figure out what is a way forward.

I don't think that such an extensive framework should *oppose* the framework for commerce. IMO commerce has to get it's place on the Internet, too, but it shouldn't rule. So it seems to me that the best approach is to incorporate social and commercial interests in some way and to find a compromise between both. But I probably misunderstood you and what you had in mind was a not a comprehensive framework but one that concentrates on social inter
ests. It's probably best for us to develop the latter as I'm sure that Magaziner is not alone and others are happily developing concept with a commercial bias right now.

>>in the early 80s a communication system called

>> BTX was introduced in Germany (quite similar to

>> Minitel in France and other systems) that used

>>the phone line and the TV to give electronic infor-

>>mation to the user. This system had a channel bias,

>> that means the channel from the network to the

>> user was much bigger than the channel from the

>> user to the network (I think it was 1200 bps vs. 75

>> bps). Possible net standards nowadays could go

>> into a similar direction, converting it into a one

>> way street that serves the needs of commercial

>> interests while those pedestrians can still find their >>way on the sidewalk.

>This is a very helpful example.

>

>I am interested in what you think is the way we

> should try to go forward to have the broader social

> interests with regard to the Net discussed and

> brought onto the public agenda.

One way to do this seems to make use of the conventional mass media. The problem that I see here is, that Netizens are a minority within the society and as long as this state remains, it will be quite hard to interest a broader public for this topic, simply because it won't make a story on conventional mass media.

Another way I could think of would be to sensibilize more or less prominent and public figures to realize what power over standards can mean for the future of communication. Sayings of those public figures would be perceived more probably than any statement that is made by us - on this list, for exam
ple.

A third way, and probably the most promising one, is to point out the importance of the topic to non-
governmental organizations (NGOs) of different kinds and not only the EFF and the like. I think the NGOs could be helpful because they are benefitting a lot from the Internet (in fact, already the fax machine was a powerful tool for them) and hence they would be harmed from processes that exclude social interests. NGOs could probably advocate Netizens' interests best and they could start immediately and they could do it on world scale as they already work together. IMO the last is a really huge advantage.

>>Here's the other point why I think the proposal

>> could have very negative effects on the net's

>> future: representation is mainly built on who is

>>paying. In such a board thee "non-commercial,

>> not-for-profit" voice would only be heard - if at

>> all - but would not be able to influence any of

>>the decision made. Such a model of

>> representation would be another mean of

>>ensuring a domination of commercial interest in

>> crucial matters of net administration.

>Yes - Magaziner's proposal was only to take a

> crucial aspect of the Internet – the DNS

> (Domain Name System) and give it over to the

>commercial sector. This will create a real problem

> as the commercial interests have a very different

> agenda with regard to Internet development than

> the Netizen or user agenda.

>

>It seems important to find some way to work to

> challenge such a power grab and also the whole

> backhanded way this is all being done.

The only way I see is to make such developments public. If the regarding persons and institutions don't do this themselves it has to be done by those who take note of it. One tool we have to accomplish this is the net itself. Obviously, a simple web site wouldn't do the trick, instead the discussion has to be spread to inform as many people as possible - carried into newsgroups and mailing lists for example.

>There does seem to be a lot of opposition to what

> Magaziner is doing – it is a problem for many so

> it would be good to see if there could be a

> common battle, or some alliance of all those who

> will be harmed by this proposal.

Where is this opposition forming up at the moment? Is there any news?

>>And if it is applied in the case of the DNS

>> administration, why shouldn't this be the model

>> for other areas: a few technicians, many

>> commercial users and one "non-commercial,

>> not-for-profit" voice.

>Yes - and in fact the Net then to made into mainly

> a vehicle for commerce. I noticed recently that

> some of the search engines mainly list commercial

> listings when you search for something, rather

> than the broad view of what they used to list.

That's an interesting observation. Do you have any further info on this?

(...)

>Perhaps what is needed is a Netizen framework for

> the future of the Net - and then to apply this in

> responding to the commercial framework.

Yes, I really think that developing this framework should be the next step. The first things that I'm aware of now and which should be included in this frame
work are:

- - the Net's nature from the Netizens' point of view

- - a plan for the future development of the Net

- - other possible plans (commercial ones, for exam
ple)

- - which development ideas exclude each other

- - the levers to influence the Net's development (standards, ...)

- - how these levers can be used to realize the above future plan

- - in which ways the levers can be used to the Netizens' disadvantage

Of course this list is far from being complete or detailed. But IMO it should be completed before the framework is worked out.

Bye,

- --

*Markus Kruggel, 40217 Duesseldorf, Germany*

markus.kruggel@unidui.uni-duisburg.de

http://online-club.de/members1/rp10930/

(To Be Continued)

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 cut-over 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 cut-over 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 participat
ing 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 imple
mentation. 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 demon
strates. 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 communica
tion 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 communi
cation and coordination among the various partici
pants 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 de
scribe 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 Commu
nications 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 require
ments 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 cut-over 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 activi
ties, 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 univer
sity 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 communica
tion made possible on the ARPAnet mailing list "TCP/IP Digest". This mailing list documents the transition not only from NCP to TCP/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 Ballis
tics 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 imple
mentations 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 inter-operably",it explains, " security, reliability and survivability are sufficiently pressing to have justified the development and adoption of TCP and IP in the absence of satisfac
tory 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 conver
sion to TCP/IP, because of the work involved. How
ever, 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 work
ing for the DoD; some manager will stipulate that something will happen "absolutely" by a certain date. All the technical people start worrying, and scream
ing, 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 conve
niently. 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 partici
pants. 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 Stan
dard Networking Protocols for the Eighties". Submis
sions will probably center around UNIX implementa
tions, but ANY networking protocol or implementa
tion 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 func
tion 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 transmis
sion between them?

We are doing a lot of planning here on network
ing, 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 implementa
tion 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 imple
mentations 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 approach
ing.) 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 encoun
tered? How fast is it? How does it compare in simplicity/performance/transparency/completeness/ functionality/limitations/etc. with the other possibili
ties? So far, we have heard of two real choices (as
suming that we're not going to have to buy any addi
tional 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 exten
sions to UNIX to support better inter-process commu
nication, 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 inter
nals of TCP and discovering whether the protocol would be a bottleneck when running on a local net
work. 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 becom
ing 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 Docu
ments" appears in the Digest outlining the proposed schedule for NCP-only hosts to begin and then com
plete their conversion to TCP/IP. Included in the scheduled milestones to be achieved were the follow
ing:

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 connec
tivity.

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 implementa
tion questions for the cut-over, 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 Equip
ment 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 conver
sion 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 know-
ledge, 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 mea
sures. 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 implementa
tion or do they agree with the criticisms?"

Urging all to respond to the list, the Digest in
cludes 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 implementa
tions. 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 Cut-
over

A notice appears in the December 23, 1981 issue of the TCP/IP Digest that an article on the TCP/IP cut-over appeared in the trade magazine Com
puterWorld. The notice explains:

Mike

"The 14 Dec issue of ComputerWorld has an interesting article on the ARPAnet TCP/IP cut-over 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 cut-over date."

Though the article noted that computer scientists were confident in the TCP/IP protocols, "An ARPA
net 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 cut-over could be achieved on Jan. 1, 1983, "but not all of them, [an] ARPAnet correspon
dence 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 discus
sion 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 inten
tion 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 prob
lem as it will lead to a "marked decrease in the quan
tity 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

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 restric
tions 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 communica
tions between research project members authorized to use the net."

A message asking about the implications of the Ellsberg case to this issue by Mike Muuss was an
swered 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 regula
tions was a little stale, but cautions, "I would be very careful about developing new ways to restrict distribu
tion 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 Com
puterWorld 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 gov
ernment 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 Di
gest-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 distribu
tion. 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 state
ment 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 distribut
ing the digest). Let's start hearing more about net
working 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 cut-over day, a description by Joel Goldberger@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 cut-over. 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 implementa
tion 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 Univer
sity of California Berkeley. His site has found both of them stable.

Preparing for the TCP/IP Cut-over

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 comput
ers 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 show
ed varying abilities to communicate both within the ARPAnet and through gateways.

After the Cut-over

The first issue of the TCP/IP Digest which appears after the TCP Jan 1 1983 cut-over 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 cut-over 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 develop
ment 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 cut-over 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 possi
ble.' 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 com
puter 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 cancella
tion 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 cut-over. 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 cut-over, 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 cut-over 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 sys
tem, 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 net
work for operational traffic (MILNET) and an experi
mental network which will retain the name ARPAnet."

MILNET was to have the Class A network num
ber 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 recon
version 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. Discus
sion?"

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 Newsletter 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 logi
cally 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 intercommuni
cate. 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 re
ceived 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 persua
sion, 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 unexpect
edly, 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 manu
ally) 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 configura
tion, 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 degen
erating 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 mingled 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 communica
tion!' 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 develop
ment 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. govern
ment, and to governments of other countries around the world as well, to increase the access of govern
ment 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 con
necting 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 recog
nized 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 compo
nents, 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 princi
ples 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]

An Introduction to TCP/IP

by Jay Hauben

jrh29@columbia.edu

I. Introduction

The Internet as we know it in 1998, although vast, is still a new and developing communications technol
ogy. It is based on a number of ingenious engineering accomplishments. This article will look at one of the most important, the Transmission Control Protocol and Internet Protocol suite, known as TCP/IP.

Any quantitative description of the Internet includes the number of networks interconnected (hence the name Internet from internetworking), the number of computers among which electronic data can be exchanged and ultimately the number of people who can communicate with this vast computer and network resource and also with each other. The elements that comprise the Internet are computers and networks of computers. These being physical entities, in order to perform reliably, require careful design based on solid engineering principles. The Internet itself is more than the sum of its elements. It too requires careful and evolving design based on princi
ples similar to those for computers and networks and some unique to the Internet.

II The Internet

The Internet is the successful interconnecting of many different networks to give the illusion of being one big computer network. What the networks have in common is that they all use packet switching technol
ogy(1). On the other hand, each of the connected networks may have its own addressing mechanism, packet size, speed etc. Any of the computers on the connected networks no matter what its operating system or other characteristics can communicate via the Internet if it has software implemented on it that conforms to the set of protocols which resulted from open research funded by the Advanced Research Projects Agency (ARPA) of the United States Depart
ment of Defense in the late 1970s(2). That set of protocols is built around the Internet Protocol (IP) and the Transmission Control Protocol (TCP). Informally, the set of protocols is called TCP/IP (pronounced by saying the names of the letters T-C-P-I-P).

The Internet Protocol is the common agreement to have software on every computer on the Internet add a bit of additional information to each of packets that it sends out. Without such software a computer can not be connected to the Internet even if Internet traffic passes over the network that the computer is attached to. A packet that has the additional information required by IP is called an IP datagram. To each IP datagram the computer adds its own network address
ing information. The whole package is called a network frame. It is network frames containing IP datagrams rather than ordinary packets that a com
puter must send onto its local packet switching network in order to communicate with a computer on another network via the Internet.

If the communication is between computers on the same network the network information is enough to deliver the frame to its intended destination computer. If the communication is intended for a computer on a different network, the network information directs the frame to the closest computer that serves to connect the local network with a different network. Such a special purpose computer is called a router (some
times a gateway). It is such routers that make inter
networking possible.

The Internet is not a single giant network of computers. It is hundreds of thousands of networks interconnected by routers. A router is a high speed, electronic, digital computer very much like all the other computers in use today. What makes a router special is that it has all the hardware and connections necessary to be able to connect to and communicate on two or more different networks. It also has the software to create and interpret network frames for each network it is attached to. In addition it must have capabilities require by IP. It must have software that can remove network information from the network frames that come to it and read the IP information in the datagrams. Based on the IP information it can add new network information to create a an appropriate network frame and send it out on that different net
work. But how does it know where to send that the IP datagram?

The entire process of Internet communication requires that each computer participating in the Internet has a unique digital address. The unique addresses of the source and destination are part of the IP information added to packets to make IP data
grams. The unique number assigned to a computer is its Internet Protocol or IP address. The IP address is a binary string of 32 digits. Therefore the Internet can provide communication among 2 to the 32nd power or about 4 billion 300 million computers (two unique addresses for every three people in the world). Internet addresses are written for example like 128.59.40.130. Each such address has two parts, a network ID and a host ID. In this example 128.59 (network ID) identi
fies that this computer is part of a Columbia Univer
sity network and 40.130 (the host ID) identifies which particular computer (on the cunix cluster) it is.

A router's IP software examines the IP information to determine the destination network from the net
work ID of the destination address. Then the software consults a routing table to pick the next router to send the IP datagram to so that it takes the "shortest" path. A path is short only if it is active and it is not con
gested. Ingenious software programs called routing daemons send and receive short messages among adjacent routers characterizing the condition on each path. These messages are analyzed and the routing table is continually up dated. In this way IP datagrams pass from router to router over different networks until they reach a router connected to their destination network. That router puts network information into the network frame that delivers the datagram to its destination computer. The IP datagram is unchanged by this whole process. Each router has put next router information along with the IP datagram into the next network frame. When the IP datagram finally reaches its destination it has no information how it got there and different packets from the original source may have taken different paths to get to the same destina
tion.

IP as described above requires nothing of the interconnected networks except that they are packet switching networks with IP compliant routers. If a transmitting network uses a very small frame size, the IP software can even fragment an IP datagram into a few smaller ones to fit the network's frame size. It is this minimum requirement by the Internet Protocol that makes it possible for a great variety of networks to participate in the Internet. But this minimum requirement also results in little or no error detection. IP arranges for a best-effort process but has no guar
antee of reliability. The remainder of the TCP/IP set of protocols adds a sufficient level of reliability to make the Internet useful.

There are problems that IP does not solve. For example, interspersed network frames from many computers can sometimes arrive faster than a router can route them. A small backlog of data can be stored on most routers but if too many frames keep arriving some must be discarded. This possibility was antici
pated. On most computers on the Internet except routers software behaving according to the Transmis
sion Control Protocol (TCP) is installed. When IP datagrams arrive at the destination computer, the TCP compliant software scans the IP information put into the IP datagram at the source. From this information the software can put packets, if they are all there, back together again. If there are duplications the software will discard all but the first copy of such packets to have arrived. But what if some IP datagrams have been lost?

As a destination computer receives data, the TCP software sends a short message back over the Internet to the original source computer specifying what data has arrived. Such a message is called an "acknowledg
ment". Every time TCP and IP software send out data, TCP software starts a timer (sets a number and de
creases it periodically using the computer's internal clock) and waits for an acknowledgment. If an ac
knowledgment arrives first, the timer is canceled. If the timer expires before an acknowledgment is re
ceived back the TCP software retransmits the data. In this way missing data can usually be replaced at the destination computer in a reasonable time. To achieve efficient data transfer the timeout interval can not be preset. It needs to be longer for more distant destina
tions and for times of greater network congestion and shorter for closer destinations and times of normal network traffic. TCP automatically adjusts the timeout interval based on current delays and on the distance it calculates according to the network address of desti
nation. This ability to dynamically adjust the timeout interval contributes greatly to the success of the Internet.

Having been designed together and engineered to perform two separate but related and needed tasks, TCP and IP complement each other. IP makes possi
ble the travel of packets over different networks but it and thus the routers are not concerned with data loss or data reassembly. The Internet is possible because so little is required of the intervening networks. TCP makes the Internet reliable by detecting and correcting duplications, out of order arrival and data loss using an acknowledgment and time out mechanism with dynamically adjusted timeout intervals.

III Conclusion

The Internet is a wonderful engineering achieve
ment. Since January 1, 1983, the cutoff date of the old ARPAnet protocols, TCP/IP technology has success
fully dealt with tremendous increases in usage and in the speed of connecting computers. This is a testament to the success of the TCP/IP protocol design and implementation process. Douglas Comer high-lighted the features of this process as follows:

* TCP/IP protocol software and the Internet were designed by talented dedicated people.

* The Internet was a dream that inspired and chal
lenged the research team.

* Researchers were allowed to experiment, even when there was no short-term economic payoff. Indeed, Internet research often used new, innovative technologies that were expensive compared to exist
ing technologies.

* Instead of dreaming about a system that solved all problems, researchers built the Internet to operate efficiently

* Researchers insisted that each part of the Internet work well in practice before they adopted it as stan
dard.

* Internet technology solves an important, practical problem; the problem occurs whenever an organiza
tion has multiple networks.

(from The Internet Book)

The high speed, electronic, digital, stored program controlled computer and the TCP/IP Internet are major historic breakthroughs in engineering technol
ogy. Every such breakthrough in the past like the printing press, the steam engine, the telephone, the airplane have had profound effects on human society. The computer and the Internet have already begun to have such effects and this promises to be just the beginning. In the long run, despite the growing pains and dislocations every great technological break
through serves to make possible a more fulfilling and comfortable life for more people. The computer and the Internet have the potential to speed up this process although it may take a hard fight for most people to experience any of the improvement. We live however in a time of great invention and great potential.

The TCP/IP Internet is a major historical achieve
ment. It provides human society with a new global communications technology with great promise and potential. This Internet has sustained unprecedented growth both in the number of its users and the vol
ume of messages it handles daily. In the 15 years since the cutover from the NCP ARPAnet to the TCP/IP Internet, the Internet has proven itself founded on solid principles. But there can be setbacks and false steps.

As proposals for further development of the Internet are made, it would be proper to expect that they reaffirm and build on the proven principles. But there is, for example, research currently being under
taken to "make IP more reliable." Since the principle of minimal requirement on component networks is IP's strength, such research if implemented would be a fundamental change for the Internet. In exchange for reliability, IP has made possible the interconnec
tion of the most diverse of networks. To require greater reliability at the IP level could be an imposi
tion of undue conformity on the component networks. That would be a backwards step. When today's Internet is developed and improved, the principles of TCP and IP will in all likelihood play crucial roles in that development.

Bibliography

Comer, Douglas E. Internetworking with TCP/IP Vol I: Principles, Protocols, and Architecture 2nd Edi
tion. Englewood Cliffs, NJ. Prentice Hall. 1991.

Comer, Douglas E. The Internet Book. Englewood Cliffs, NJ. Prentice Hall. 1995.

Hauben, Michael and Ronda Hauben. Netizens: On the History and Impact of Usenet and the Internet. Los Alamitos, CA. IEEE Computer Society Press. 1997

Lynch, Daniel C. and Marshall T. Rose. Editors. Internet Systems Handbook. Reading, MA. Addi
son-Wesley. 1993.

Stevens, W. Richard. TCP/IP Illustrated, Vol 1 Protocols. Reading, MA. Addison-Wesley. 1994.

Strandh, Sigvard. The History of the Machine. New York. Dorset Press. 1989 (Copyright 1979, AB NORDBOK, Gothenburg, Sweden).

Notes:

1. See part IV of "The Computer and the Internet", the longer version of this paper accessible at http://www .umcc.umich.edu/~jrh/paper.s98.html or by e-mail from the author at jrh@umcc.umich.edu.

2. ibid.