ArticlePDF Available

Abstract

This paper reviews the history, the goals, the organization he components, and the status of CSNET. December 1982 CSD-TR-424 Authors addresses: Peter J. Denning, Computer Sciences Department, Purdue University, West Lafayette, IN 47907; - t Anthony Hearn, The Rand Corporation, Santa Monica, CA 90406; C. William Kern, Computer Science Section, Na ional Science Foundation, Washington, DC 20550. The work reported herein was supported through NSF by awards to Purdue University, The Rand Corporation, The University of Delaware, and the University of Wisconsin
HISTORY AND OVERVIEW OF CSNET
Peter J. Denning
1
Anthony Hearn
1
1
A
C. William Kern
bstract: CSNET is the acronym for the Computer Science Research
n
Network, a project supported by NSF to provide advanced computer
etwork services to the computer research community. CSNET is a
s
"logical net" -- a high-level communication environment spanning
everal physical nets, including the ARPANET, Phonenet, and
,
t
Telenet. This paper reviews the history, the goals, the organization
he components, and the status of CSNET.
December 1982
CSD-TR-424
1
Authors addresses: Peter J. Denning, Computer Sciences Department, Purdue University, West Lafayette, IN 47907;
-
t
Anthony Hearn, The Rand Corporation, Santa Monica, CA 90406; C. William Kern, Computer Science Section, Na
ional Science Foundation, Washington, DC 20550. The work reported herein was supported through NSF by awards
to Purdue University, The Rand Corporation, The University of Delaware, and the University of Wisconsin.
This is a preprint of a paper to be presented in a session about the CSNET Project at the ACM SIGCOMM symposi-
um on data communications, March 8-9, 1983.
ACM SIGCOMM, March 1983, 138-145.
CSNET Overview (12/1/82)
C
-2-
SNET stands for the Computer Science Research Network, a project sponsored by NSF to pro-
n
vide advanced computer network services to the computer research community. CSNET is a "logical
et" -- a high-level communication environment spanning several physical nets, including the
s
t
ARPANET, Phonenet, and X.25 public packet-switched networks (e.g., Telenet). This paper review
he history, the goals, the organization, the components, and the status of CSNET as of Fall 1982.
Background
2
The seeds of CSNET were planted in May 1979. L. H. Landweber arranged a special meeting at
b
the University of Wisconsin to discuss how computer network services like those of ARPANET could
ecome available to the entire community of computer science researchers. The ARPANET served
only a dozen university sites and DARPA was unable to include the rest of the community.
It was clear to the participants that mail, le transfer, and remote login services had greatly
t
w
enhanced research productivity and had generated a strong community spirit among ARPANET sites. I
as also clear that the ARPANET experiment had produced a split between the "haves" of the
e
m
ARPANET and the "have-nots" of the rest of the computer science community. The participants at th
eeting wanted to unify the computer research community and to improve research conditions for all
its members.
Each participant at the meeting had previous, favorable experience with computer-based mail ser-
vices for a small research community. One was "THEORYNET", a mailbox facility on a machine at
2
More detailed information on the background and history of CSNET can be found in the article by Comer [1]. More
detailed information about CSNET’s multinet architecture can be found in the paper by Landweber and Solomon [2].
CSNET Overview (12/1/82)
t
-3-
he University of Wisconsin accessible via Telenet login to some 200 theoretical computer scientists.
s
Another was "SAMNET", a mailbox facility on a machine at the University of Toronto accessible to
ome 50 performance analysts. A third was "SYMBOLNET", a network linking four sites comprising
r
A
researchers in symbolic computation; the goal was a network based on Telenet with services to mirro
RPANET (but to be independent of ARPANET). Each of these primitive electronic mail services had
s
signicantly aided its special community. Each community was anxious to obtain the more advanced
ervices of machine-to-machine mail transfer, le transfer, and remote login.
f
T
Also present at this meeting were observers from NSF and DARPA. The NSF was the sponsor o
HEORYNET and SYMBOLNET and, on the advice of its advisory panel, had been alert for possible
-
p
extensions of network services to the rest of the community. DARPA was interested in furthering com
uter science research and believed that network services might be a step of high leverage. These
observers offered advice and encouragement.
The group determined to submit a proposal to the NSF. They envisaged a network available to
r
c
all members of the computer science community. The network would have low entry costs and othe
osts proportional to usage. Public packet-switched networks, notably Telenet, would be the underlying
m
medium. (At the time, a DARPA IMP cost about $90K per year, a price well beyond the means of
ost computer science departments. Moderate speed Telenet connections were then available for entry
fees of about $20K per year.)
In November 1979 the University of Wisconsin submitted a proposal to NSF containing the above
d
plan on behalf of a consortium of universities (Georgia Tech, Minnesota, New Mexico, Oklahoma, Pur-
ue, UC-Berkeley, Utah, Virginia, Washington, Wisconsin, and Yale). The cost would be $3 million
n
M
over a ve-year period. The NSF had the proposal reviewed and returned comments to the proposers i
arch 1980.
The reviews revealed a much higher level of skepticism than the proposers had anticipated. The
skepticism had three roots. One was a belief that the CSNET project was proposing to reinvent
-4- )
A
CSNET Overview (12/1/82
RPANET technology; this perception was reinforced by the lack of any gateway between the
n
g
ARPANET and the proposed CSNET. The second was a belief that insufcient attention had bee
iven to project management and task distribution. The third was a belief that NSF might have to
F
c
obtain funds for CSNET by reducing basic research budgets. On the basis of these reviews the NS
ould not fund the project as proposed.
But the NSF’s advisors and some of the reviewers adamantly maintained that CSNET would so
h
improve research productivity that the potential diversion of funds from basic research would pay off
andsomely in the long run. Accordingly, the NSF offered to fund a thorough study of the CSNET
a
s
concept. The purpose of the study was to determine the most cost-effective architecture, to develop
ound management plan, and to assess the extent of community support. With sufciently strong peer
approval, CSNET would be possible.
During the summer of 1980, Landweber convened a CSNET planning committee comprising
r
n
nineteen computer scientists, a cross section of leaders of the community who had extensive compute
etwork experience. Two major new factors entered the discussion. One was the existence of MMDF,
D
software for "multi-channel memo distribution facility," under development at the University of
elaware [3]. MMDF is a UNIX-based mail transport system that sends and receives mail over a
"
variety of channels including ARPANET and telephone. (The latter is functionally similar to the
uucp" facility of UNIX.) With MMDF, CSNET could bring a large number of sites online in a short
period at low cost.
The second factor was DARPA’s decision to proceed with "internet protocols" (IP) that permit a
c
host in one net to communicate with a host in a different net. With the internet protocols, CSNET
ould be regarded as a logical organization of users on different nets. DARPA offered to make its new
-
i
protocol software (TCP/IP) available to the CSNET project. In return, DARPA expected that the exist
ng ARPANET university community would be a component of CSNET at no cost to DARPA.
nThe planning committee quickly reached a consensus. CSNET would include subnets based o
-5- )
A
CSNET Overview (12/1/82
RPANET, X.25 nets, and Phonenet (the MMDF service). The internet protocols would hide these
s
components from their users. CSNET would develop an interface between ARPANET’s protocol
oftware (IP) and the X.25 public networks (initially Telenet); this would make the standard ARPANET
T
u
services available to non-DARPA hosts. CSNET would provide a name server that registers all CSNE
sers and quickly locates the mailbox of any registered user. CSNET would initially receive full sup-
port from NSF, but would become self supporting within ve years via dues and usage fees.
A proposal containing this plan was submitted by Wisconsin on behalf of a consortium of institu-
r
tions (Wisconsin, Purdue, Utah, Delaware, and The Rand Corporation) in November, 1980. It was
eviewed by late December, 1980 and then submitted to the National Science Board, which approved
m
the project in January 1981. The Board stipulated that the NSF would provide a full time project
anager for the rst two years but would withdraw from project management by February, 1983, when
W
the CSNET organization would be strong enough to take over. Contracts for CSNET were let to
isconsin, Purdue, Delaware, and Rand in late spring, 1981. After 20 months, the seeds of CSNET
G
had begun to sprout. The real work lay ahead.
oals
The goals of CSNET are summarized in Figure 1. The net is to be open to all computer
l
p
researchers throughout the United States (later, the world). It is to be self-supporting. Its users wil
ay xed annual dues plus usage fees. (The dues for 1983 are shown in the bottom part of the table.)
e
CSNET will initially comprise three subnets -- ARPANET, Telenet, and Phonenet -- but will be
xpandable to others as they become available, e.g., other X.25 public nets and satellite nets. CSNET
e
n
will initially provide the same services as ARPANET -- mail, le transfer, remote login, and an on-lin
ame server. Later, it will provide additional services such as messages containing voice segments,
software libraries, technical report repositories, and an on-line journal.
-6- )CSNET Overview (12/1/82
COMPUTER SCIENCE RESEARCH NETWORK GOALS
Open to all computer researchers.
sLogical net comprising physical subnet
(initially ARPANET, Telenet, Phonenet).
Advanced network services
(initially mail, le transfer, remote
login, name server).
Self-governing, -sustaining, and -supporting
Low entry fee
DUES FOR CALENDAR 1983
Industry site -- $30,000
0Government site -- $10,00
Non-Prot site -- $10,000
N
University site -- $5,000
ote: Sites with a very small number of researchers can negotiate lower dues.
F
Goals and Dues Structure of CSNET.
IGURE 1:
The four project teams must carry out these goals within two important constraints. First, the
o
c
total project budget, $5 million over ve years, places a severe limit on the number of personnel wh
an be hired. It also means that satisfactory service must be available by 1983 to permit collection of
n
N
dues. Second, the project must develop its own stable management organization by Spring 1983, whe
SF withdraws ofcially from project management.
Users who have accounts at ARPANET hosts already have the full services of CSNET except for
h
the name server. Until Telenet sites are operational, all other users are at Phonenet sites; they will not
ave le transfer or remote login services and will interact with the name server by mail. At the start
h
of the project, mailboxes are also provided on a machine called the CSNET Public Host for users who
ave no accounts at ARPANET or Phonenet sites; this service is not heavily used.
C -7-SNET Overview (12/1/82)
i
CSNET protocol and name-server software development is limited to the Berkeley UNIX operat-
ng system on VAX computers. The MMDF software works with Berkeley UNIX and Bell Labs’ Ver-
m
sion 7 UNIX. CSNET is encouraging vendors to develop compatible software and hardware for other
achines and operating systems.
3
Technical Projects
Figure 2 lists the three technical subprojects of CSNET: Phonenet, Name Server, and Protocols.
s
i
The following subsections give overviews of these projects. Companion papers describe these project
n detail [1,2,3].
Phonenet
The Phonenet project is being conducted jointly at the University of Delaware and the Rand Cor-
o
poration. Its rst goal is to set up and operate mail relay computers on the east coast (at the University
f Delaware) and on the west coast (at the Rand Corporation). Its second goal is to provide each
s
m
CSNET site with the MMDF mail transport to permit automatic mail exchange between that site’
achine and the nearest relay.
Each relay will route mail to the destination site via ARPANET, Telenet, Phonenet, and possibly
p
the other relay. CSNET sites can poll the relays as often as they desire and are willing to pay tele-
hone line charges. Phonenet messages can incur usage charges if they are routed over paths for which
3
For example, the IBM Corporation has an agreement with the University of Wisconsin to develop CSNET-compatible
e
protocols for IBM machines running the VM operating system. Also, a Pascal version of the Phonenet software has
nabled Phonenet participation by users of DEC VMS and IBM VM operating systems.
)CSNET Overview (12/1/82-8-
PROJECT INVESTIGATORS GOAL
Phonenet D. Farber (Delaware)
A. Hearn (Rand)
Install and operate mail relays (VAX
d
b
11/750) at Delaware and Rand, connecte
y phone, Telenet, and ARPANET. Distri-
P
bute copies of MMDF software to CSNET
honenet sites. Goal is 100 operational
Name Server
sites by 1983.
L. Landweber (Wisconsin)
M. Solomon (Wisconsin)
Develop the CSNET name server, a data-
t
base of all CSNET users, and install it on
he CSNET Service Host. Final version
.
Protocol
distributed to CSNET sites by end of 1983
D. Comer (Purdue)
)
T
P. Denning (Purdue
. Korb (Purdue)
Construct interface between ARPA’s Inter-
w
net Protocol (IP) and the X.25 public net-
ork protocol to permit using X.25 nets
-
s
for full ARPANET services. Working ver
ion available for distribution by 1983.
F
Technical Subprojects of CSNET.
IGURE 2:
.CSNET must pay, e.g., telephone lines or Telenet
The design goals of MMDF have been reported at the 1979 Data Communications Symposium
r
c
[3]. They are: 1) a mail transport that provides a high-level, channel-independent interface, 2) erro
hecking of message formats, and 3) robustness under load. The main components of MMDF are illus-
trated in Figure 3.
The rst goal is achieved by implementing the delivery mechanism as a process that takes mes-
s
o
sages one at a time from its work queue and sends them over one of several channels connected to it
utput. The incoming messages must consist of a body and a header in a standard (internal) format.
h
c
The delivery process uses the address in the header to select a channel for sending the message. Eac
hannel is a driver that sends the message in the protocol of a particular network, e.g., local delivery,
C -9-SNET Overview (12/1/82)
ARPANET, UUCP, or Phonenet.
The second goal is met by requiring that every user mail environment contain a certied "submit"
h
subprogram for interacting with the MMDF delivery process. When a user forms an address in the
eader of a message, the submit subprogram converts it to the standard internal form and checks with
W
the delivery process to verify its validity; if the address is invalid, the user is immediately notied.
hen the user completes the message body, the submit subprogram deposits the ready message with
validated address in the work queue of the delivery process.
Mail incoming on any channel is also placed in the work queue of the delivery process, which
will eventually deposit it in a local mailbox via the local delivery channel.
The third goal is met by storing the work queue of the deliver process on secondary storage,
which can allow it to become quite large without overloading the system.
CSNET soon encountered difculties on account of an essential incompatibility between the
e
r
MMDF transport and the one already in the UNIX operating system at each of the Phonenet sites. Th
egular UNIX mailer programs do no address checking; instead, the delivery process parses and inter-
e
M
prets addresses of many formats. There is no simple way to convert these mailers to interact with th
MDF delivery process directly. Because of this, many Phonenet sites had to deal with two mail sys-
w
tems -- the one already in their UNIX operating systems and the new one provided by MMDF. This
as a major inconvenience that created many complaints.
r
m
To provide a temporary solution, the Purdue and Delaware contractors cooperated on mino
odications of delivery processes of Berkeley UNIX and MMDF. The outgoing ARPANET channel
A
on the Berkeley delivery process was replaced with a driver that hands mail intended for the
RPANET to the MMDF delivery process, which in turn routes it to its destination via the Phonenet
e
M
channel. (Because Phonenet sites cannot send directly to the ARPANET, this loses no function.) Th
MDF local delivery channel was modied to store mail in the mailboxes and in the formats expected
eby the Berkeley mail programs. The disadvantage of this solution is that it requires each Phonenet sit
-10- )
t
CSNET Overview (12/1/82
o install and maintain two mail transport systems.
A long-term solution is being discussed between CSNET and the Berkeley UNIX developers.
m
a
The goal is a single mail transport that incorporates the best features of Berkeley’s current mail syste
nd MMDF. This system would be distributed with releases of Berkeley UNIX.
Name Server [4]
The name server is a database of all CSNET users held online at a site called the CSNET Service
n
Host. (This machine is now at the University of Wisconsin.) Each record of this database contains the
ame, mailbox identier, and descriptive keywords of a registered CSNET user. CSNET sites can
-
w
query the name server to obtain the mailbox address of any user. CSNET users can update the key
ords in their records at any time. The name server project is also implementing the programs to be
installed at each CSNET site for the proper protocols with the name server.
The user interface with the name server consists of commands to implement these operations:
u
register
nregister
w
move
hois
update
-
m
The "register" command is used by a user to enter a new record in the database; the "unregister" com
and is used to remove a record; the "move" command is used to change the eld in a record indicat-
m
ing the location of the user’s mailbox. A password scheme prevents unauthorized use of these com-
ands. The "whois" command is used to retrieve a set of records matching keywords; for example
whois Peter Denning
-11- )
a
CSNET Overview (12/1/82
nd
whois past ACM president
a
l
will return the same record. The mailbox identier eld of this record can be extracted and put in
ocal alias table so that future queries can be bypassed. The "update" operation is used by a user to
n
p
alter the descriptive keywords in his record of the database; the system requires him to present his logi
assword before installing any changes.
Future versions of the name server software distributed to CSNET sites will automatically
e
w
encache information locally to reduce trafc with the name server. For example, a user’s alias tabl
ill hold pairs (nickname, mailbox-identier) to help avoid unneeded invocations of the whois com-
u
mand by that user. A system table will encache pairs (mailbox-identier, internet address) so that
nneeded requests for the internet address of a given site can be omitted. Messages will be automati-
cally forwarded to users whose mailboxes have been moved.
Users at Phonenet sites will have to conduct the above interactions by sending mail to the name
P
server. The name server will, by return mail, send records matching a whois query.
rotocols [5]
The IP-to-X.25 protocol project is the least visible component of CSNET. Its goal is an interface
l
between the datagram-oriented DARPA Internet Protocol (IP) and the virtual-circuit-oriented X.25 pub-
ic packet network protocol. This interface will enable the high-level ARPA Transport Control Protocol
v
(TCP) to work with X.25 nets, which in turn will allow CSNET users full access to ARPANET ser-
ices. Because all user services interact with TCP, any new DARPA network services will become
available throughout all of CSNET with new software distributions.
-12- )CSNET Overview (12/1/82
DARPA’s protocol design relies on the TCP layer in one machine to establish a process-to-
-
s
process channel with a corresponding TCP layer on another machine. The sender’s TCP breaks a mes
age into packets, which are handed over to its IP for transmission as independent datagrams over the
m
ARPANET. The receiver’s IP hands the received datagrams to its TCP, which reassembles them into
essages. Purdue’s modication extends IP so that it can selects the Purdue X.25 interface when the
recipient host’s internet address is on Telenet.
Because Telenet charges for opening virtual circuits in X.25, the Purdue interface cannot transmit
t
an IP datagram simply by opening a circuit, sending a packet containing the datagram, and then closing
he circuit. Instead, it must leave open a circuit to the target host as long as it or the target is actively
m
c
using that circuit. An algorithm resembling a page replacement algorithm for a virtual memory syste
loses an open circuit when IP requires a new circuit beyond the maximum number Telenet permits a
given host to open.
The Purdue interface is connected to an Interactive Systems INcard, which is a board that con-
e
nects the Telenet modem to the VAX backplane. A future project is to provide the X.29 protocol
xtension of X.25; this will allow the INcard to connect to a login port of UNIX so that authorized
users can access the machine by ordinary Telenet remote login. Interactive Systems is considering
-13- )
e
CSNET Overview (12/1/82
xtending the design of its INcard to include X.29 on the board.
Organization of the Project
The CSNET management structure provides central management over a project whose com-
ponents are at different locations. Figure 4 outlines the management components.
PROJECT DIRECTOR
R. Adrion (NSF)
5
MANAGEMENT COMMITTEE
L. Landweber, Chair
R. Adrion
P. Denning
R. Edmiston
D. Farber
A. Hearn
C. W. Kern
SUPPORT GROUPS
)Policy (L. Landweber, Chair
Technical (D. Farber, Chair)
)
C
Organization (A. Hearn, Chair
oordination & Information Center (R. Edmiston, Director)
F CSNET Management Structure.IGURE 4:
The Management Committee consists of the principal investigator of each contract, the director of
5
Until October 1982, C. W. Kern of NSF was the project director.
)CSNET Overview (12/1/82-14-
s
e
the Coordination and Information Center (CIC), and the NSF project manager. This committee meet
very six to eight weeks to review the status of the project, settle policy questions, and give guidance to
c
the technical subprojects. It is responsible for keeping the entire project on schedule and for initiating
orrective action when needed. Until a separate CSNET organization is established in 1983, the NSF
project director can overrule the committee on any matter.
The Policy Support Group consists of the Management Committee plus other senior computer
e
g
scientists.
6
It meets as needed (but at least once a year) to review the status of the entire project, giv
eneral guidance to the Management Committee, and determine overall policies for CSNET. When
M
CSNET becomes a separate corporation, this group will be replaced by a board of directors and the
anagement Committee will be replaced by an executive committee.
g
C
The Technical Support Group meets from time to time to consider technical problems facin
SNET and recommend solutions to the Management Committee.
7
It consists of the principal investi-
r
gators of each project (or their designees) plus other computer scientists whose technical areas are
elevant to the project.
The Organization Support Group has been studying models for the CSNET organization -- e.g.,
a
c
consortium of universities, embedding in an existing consortium, or separate corporation.
8
It drafted
onstitution and bylaws that is serving as the charter of CSNET until a formal organization is esta-
-
d
blished. After considering the alternatives proposed by this committee, the NSF decided that embed
ing CSNET into an existing organization would be the best choice; it issued a program solicitation in
6
As of September 1982, the other members of the Policy Support Group were A. Aho (Bell), B. Arden (Princeton), J.
(
Birnbaum (HP), F. Corbato (MIT), K. Curtis (NSF), R. Eckhouse (DEC), N. Habermann (Carnegie-Mellon), R. Kahn
DARPA), L. Kleinrock (UCLA), M. Marcus (FCC), R. Miller (Georgia Tech), R. Ritchie (Washington), H. Schorr
7
(IBM), R. Spinrad (Xerox), and S. Sedelow (Kansas).
As of September 1982, the members of the Technical Support Group were E. Allman (Berkeley), V. Cerf (MCI), D.
L
Crocker (Delaware), P. Enslow (Georgia Tech), J. Feldman (Rochester), L. Hollaar (Utah), J. T. Korb (Purdue), K.
antz (Stanford), M. O’Brien (Rand), J. Postel (USC), L. Rowe (Berkeley), F. Schneider (Cornell), and M. Solomon
8
(Wisconsin).
As of September 1982, the members of the Organization Support Group were A. Batson (Virginia), W. Franta (Min-
nesota), M. Harrison (Berkeley), G. Heller (EDUCOM), L. Travis (Wisconsin), and K. Uncapher (USC).
CSNET Overview (12/1/82)-15-
.October 1982 inviting potential host organizations to submit proposals
The Coordination and Information Center is to provide the management services needed to regis-
n
ter and install new users and sites, distribute CSNET software, provide documentation and regular
ewsletters, and answer users’ questions. After a public announcement in Fall 1981, NSF received and
s
f
reviewed proposals. A contract was awarded to Bolt Beranek and Newman of Cambridge, MA, for thi
unction. The CIC became operational in July 1982.
The CIC has been advising the Management Committee on possible methods of accounting for
d
b
CSNET use and billing sites their fair shares of these charges. The accounting problem is complicate
y several factors: a) Some messages will travel through several subnets each with different charging
y
t
policies. For example, an east coast Phonenet site will communicate with a west coast Phonenet site b
wo phone calls (site to Delaware relay, Rand relay to site) and a Telenet call (relay to relay). b) It is
-
v
impractical for the relays to provide itemized lists of load generated by each user at a site. It can pro
ide a total of load generated by a site. The site will have to allocate the cost of that load locally
h
D
among its users; CSNET will provide accounting software for this purpose. c) By agreement wit
ARPA, CSNET will not charge ARPANET users for CSNET use. Assuming that trafc from CSNET
b
to the ARPANET is approximately the same as trafc from ARPANET to CSNET, an approach would
e to charge CSNET users twice the cost of the CSNET leg of their messages to ARPANET users. d)
c
Duplex telephone and Telenet circuits can be used by a receiver to send mail back to a caller -- at the
aller’s expense. Special controls may be needed if some frequently called sites are found not to be
paying usage fees proportional to their actual outbound trafc.
-16- )
S
CSNET Overview (12/1/82
tatus of the Project
As of October 1982 both the Rand and Delaware relays were operational. The two relays com-
S
municated by telephone and ARPANET, and will communicate by Telenet as soon as practicable.
ome 76 Phonenet sites were operational or about to become so, as shown by the CSNET map in Fig-
ure 5.
As of September 1982, a preliminary version of the name server software was being tested at the
c
contractors’ sites. All users at all operational CSNET sites were registered in the database. All the
ommands in the user interface were implemented. Later versions making use of the alias facility and
of encaching internet addresses were under development but were not yet under test.
As of September 1982, the protocol software was under test and was being installed at each of
l
u
the other contractor’s machines. During the test period, all communication among the contractors wil
se Telenet instead of ARPANET. Around January 1983 this software will be available for other
d
t
CSNET sites to install if and when they obtain the necessary Telenet connections. Initial tests reveale
hat Telenet window restrictions limited effective throughput to less than 1200 baud even on lines rated
at 9600 baud. Negotiations with Telenet were initiated to loosen these restrictions.
As of July 1982 Bolt Beranek and Newman had been accepted under contract to provide the
e
a
Coordination and Information Center. Complete plans for documentation and software distribution wer
pproved by the Management Committee and were being implemented. A hotline phone number was
-
s
operational for any CSNET user or site having questions or comments (617-497-2777). The CIC per
onnel had assisted the management committee in devising a dues structure and were assisting in the
development of accounting and billing procedures.
As of September 1982 the Policy Support Group had approved a draft of the constitution and
s
t
bylaws of CSNET. Until CSNET is converted to a separate organization, this document will serve a
he charter. In October 1982, the NSF issued a formal solicitation for an institution to serve as host for
CSNET, Inc., during the next period.
-17- )CSNET Overview (12/1/82
As of September 1982 the Management Committee had received approval from NSF for the dues
b
structure (Figure 1) and was proceeding to its implementation. During 1983 member institutions will
egin paying dues and usage fees. The Coordination and Information Center has provided estimates of
m
the annual usage costs that can be expected by each type of site. Examples of costs from these esti-
ates are summarized in Figure 6.
E
Initial Annual Annual
quipment Connect Usage Annual
Site Type Cost Charges Charges COST
PHONENET 1500 250
Moderate (1) 8750 9000
0
T
Heavy (2) 24250 2450
ELENET 10000 12000
0
H
Moderate (1) 3250 1525
eavy (2) 9000 21000
ARPANET -- 107,000 -- --
(
(1) Moderate = 10 moderate users plus 10 heavy users.
2) Heavy = 20 moderate users plus 30 heavy users.
F Example Usage Cost Estimates.IGURE 6:
(These examples assume a moderate user will generate about $250/year charges at Phonenet sites and
d
$
$75/year at Telenet sites; they assume a heavy user will generate about $625/year at Phonenet sites an
250/year at Telenet sites.) Phonenet usage charges are a combination of telephone line charges and
e
s
Telenet packet charges for messages that have Telenet legs in their journeys. For a sufciently activ
ite, Telenet is cheaper than Phonenet. Moreover, Telenet gives interactive access to CSNET services;
v
Phonenet does not. The ARPANET gures are included for comparison: CSNET will be able to pro-
ide similar services at much lower cost to many members of the computer research community.
-As of September 1982 the Management Committee had admitted to membership only U.S. institu
-18- )
t
CSNET Overview (12/1/82
ions conducting or directly supporting computer research. Several industrial applications from rms
t
u
engaged in product development had been deferred until the CSNET organization is more stable and ne
se policies have been set forth. Several applications from foreign research sites (in Canada, Israel, and
C
Europe) had been deferred until the U.S. government’s policies on transborder ow in respect to
SNET can be ascertained.
Acknowledgements
We are grateful to the many colleagues with whom we have interacted during the formative
o
t
stages of CSNET, to the people at NSF and DARPA for their constant advice and encouragement, t
he National Science Board for its faith in computer community, and to the computer community for its
a
continued support for this project. Three persons in government played critical key roles. Bob Kahn
nd Vinton Cerf of DARPA gave constant support and a major commitment of DARPA resources.
F
a
Kent Curtis of NSF spent uncounted hours behind the scenes selling the concept of CSNET to the NS
dministration, to OMB, and to DARPA; his insistence on wide community support signicantly
y
L
strengthened the project and assured its success. We are also grateful to Fred Schneider and Larr
andweber for comments on this manuscript.
1
References
. Comer, D. E., "The Computer Science Research Network CSNET -- A History and Status
2
Report," submitted to Communications of ACM, August 1982.
. Landweber, L., and Solomon, M., "Use of Multiple Networks in CSNET," Proc. IEEE COMP-
C -19-SNET Overview (12/1/82)
3
CON (February 1982).
. Crocker, D. H., Szurkowski, E. S., and Farber, D. J., "An Inter-Network Memo Distribution Capa-
2
bility -- MMDF," Proc. Sixth Data Communications Symposium, ACM SIGCOMM (1979), 18-
5.
4. Landweber, L., Litzkow, L., Neuhengen, D., and Solomon, M., "Architecture of The CSNET
s
i
Name Server," Proc. Symposium on Data Communications, ACM SIGCOMM (March 1983), thi
ssue.
5. Comer, D. E., and Korb, J. T., "CSNET Protocol Software: The IP-to-X.25 Interface," Proc. Sym-
posium on Data Communications, ACM SIGCOMM (March 1983), this issue.
... Recognizing the value that the DOD-contracting universities were deriving from their participation in the ARPANET effort, wanting to expand beyond the smallerscale network arrangements upon which they were already depending [6], and concerned that 'the ARPANET experiment had produced a split between the "haves" of the ARPANET and the "have-nots" of the rest of the computer science community' [9], a consortium of US computer science departments partnered with the National Science Foundation and other groups to put together a proposal for the Computer Science Research Network, or CSNET. CSNET integrated multiple different network technologies, with a store-and-forward email system over regular phone lines as the base level of participation, but leased line and X.25 networking available for higher performance connections. ...
Article
Full-text available
div class="page" title="Page 1"> What is the Internet like, and how do we know? Less tendentiously, how can we make general statements about the Internet without reference to alternatives that help us to understand what the space of network design possibilities might be? This paper presents a series of cases of network alternatives which provide a vantage point from which to reflect upon the ways that the Internet does or does not uphold both its own design goals and our collective imaginings of what it does and how. The goal is to provide a framework for understanding how technologies embody promises, and how these both come to evolve. </div
... Ova fondacija je formirala Naučnu kompjutersku mrežu (Computer Science Network -CSNET) koja je povezivala akademske mreže širom SAD. To je bila alternativa ARPANET-u (Denning, 1983). Godine 1983. ...
... Education: Fairfield College Prep, 1960Manhattan College, BEE, 1964;Massachusetts Institute of Technology, MS, 1965;MIT, PhD, 1968. Professional Experience: Princeton University, 1968-1972Purdue University, 1972-1983NASA-Ames RIACS, 1983-1991George Mason University, 1991- 2002Naval Postgraduate School, 2002 to present. ...
Article
Full-text available
A leading scientist in computing since his graduation from Massachusetts Institute of Technology in 1968, Peter J. Denning is best known for his pioneering work in virtual memory, especially for inventing the working-set model for program behavior, which eliminated thrashing in operating systems and became the reference standard for all memory management policies. He is also known for his work on the principles of operating systems, operational analysis of queuing network systems, the design and implementation of the Computer Science Network, CSNET, ACM digital library, and codifying the principles of computing. In this interview, Denning discusses his career path and his efforts to promote computer science education and help the field flourish.
Conference Paper
CSnet & Bitnet were two important contemporaneous networks that succeeded once and failed to continue in the end. Whether they were successful or frustrated, they were similar and relative in their burgeoning, flourishing and merging. First, the two networks both arose from some existing networks: the CSnet was established by some non-ARPAnet universities to serve the rest of computer science community, which was mainly supported by the National Science Foundation of USA, and the CSnet was built on some experience of the ARPAnet; the Bitnet was developed from the VNET. Second, the two networks both succeeded in attaining enough users, who used their service and validated the values of the networks. The sufficient users were also the reasons that the two networks could exist for a period of time at the age. Third, in the end, the two networks both had to merge because of their disadvantages: the CSnet lacked effective organization to support its finance; the techniques of the Bitnet dropped behind the contemporaneous networking techniques. The above three similarities between the CSnet and the Bitnet draw our emphasis on three factors: techniques and experience of previous network, users, and development potential. The three factors are most important for developing networks and the development potential includes continuable financial support and innovating techniques. Besides, the different disadvantages and advantages of the two networks made their complementarities possible, and their merger proved such possibility in the end. Thus, as the history said, the users chose the two networks to come into the world, flourish, merge and fall into disuse.
Article
Full-text available
So that the routers forward an IP packet with his destination, they are running a forwarding decision on an incoming packet to determine the packet's next-hop router. This is achieved by looking up the longest matching prefix with a packet destination address in the routing tables. Therefore, one major factor in the overall performance of a router is the speed of the IP address lookup operation due to the increase in routing table size, in this paper, a new IP address lookup algorithm based on cache routing-table is proposed, that contains recently used IP addresses and their forwarding information to speed up the IP address lookups operation in the routers. We evaluated the performance of our proposed algorithm in terms of consultation time for several sets of IP addresses, the results of performance evaluation show that our algorithm is efficient in terms of the lookup speed since search can be immediately finished when the input IP address is found in the cache routing table.
Article
Full-text available
The growth of the World Wide Web (WWW) has seen it evolve into a rich information resource. It is constantly traversed with the aid of crawlers so as to harvest web content. When collecting data, crawlers have the potential of causing service denial to web servers. This paper proposes the application of sampling as a selection strategy in the design of structural analysis web crawlers. This has the benefit of alleviating the problems of bandwidth costs to web servers whilst retaining the quality of the data that is mined by crawlers. The initial results of this study are promising and are presented in this paper.
Article
Full-text available
Web server logs stores click stream data which can be useful for mining purposes. The data is stored as a result of user's access to a website. Web usage mining an application of data mining can be used to discover user access patterns from weblog data. The obtained results are used in different applications like, site modifications, business intelligence, system improvement and personalization. In this study, we have analyzed the log files of smart sync software web server to get information about visitors; top errors which can be utilized by system administrator and web designer to increase the effectiveness of the web site.
Article
Full-text available
The major challenge to design and deployment of mobile ad hoc networks (MANETs) is its dynamic nature, which carries with itself a set of security measures to be resolved. In this paper, we compare the behavior of three routing protocols DSDV, DSR and AODV under security attack, where the investigation is carried out with respect to two types of node misbehavior. The parameters taken into consideration for evaluation of network performance are normalized throughput, routing overhead, normalized routing load and average packet delay, when a certain percentage of nodes misbehave. It could be established through simulation results that DSDV is the most robust routing protocol under security attacks as compared to the other two. In addition, it reveals that a proactive routing protocol reduces the impact of security attack by excluding the misbehaving nodes in advance.
Article
CSNET is built on the Department of Defense network (ARPANET), public packet-switched physical networks (Telenet), and a telephone-based relay network (Phonenet). Some CSNET sites have direct connections to ARPANET, some have direct connections to Telenet, and some have connections only to telephone-based relay machines. The chief objective of CSNET is to provide a network interconnection for all groups engaged in Computer Science Research. CSNET has adopted TCP/IP as its standard transport level protocols. The Transmission Control Protocol (TCP) [POST81] is an end-to-end protocol. It establishes communications between two processes that are running on different machines, detects and corrects errors, controls data flow, and provides reliable communications. Application programs call TCP to transfer data across the network. TCP, in turn, uses the Internet Protocol (IP) [POST81] to send data to the appropriate network. CSNET communications such as file transfer, remote login, and process-to-process communication over the network assume that a TCP interface is available at CSNET sites. Since ARPANET sites are required to support the TCP/IP protocols, CSNET sites connected directly to the ARPANET automatically have access to TCP/IP. Phonenet relays connect directly to the ARPANET; they too have access to TCP to relay mail onto the ARPANET. Telenet does not use the TCP/IP protocols. Consequently, CSNET sites that are connected only to Telenet need additional software before they can communicate on CSNET. That software is described in this paper -- it provides an interface between the public packet - switched protocol X.25 [CCITT78] and TCP/IP. Although the design outlined here is applicable to any vendor's system, our implemention is for a Digital Equipment Corporation VAX running the Western Electric UNIX [UNIX78] operating system as modified by the University of California at Berkeley. This report focuses on the technical issues involved in building software to interface TCP/IP and X.25. The tariff structure for public networks is discussed only to the extent that it influences our design. Other issues such as access control, and protocol selection are beyond the scope of this report.
Article
An important function of CSNET is to simplify communication by electronic mail. To this end, a Name Server facility is being implemented, which will free users from having to understand the complexities of inter-network mail addressing. The Name Server includes a database and accessing software on a central Service Host machine, as well as programs and data structures on CSNET member hosts. We describe the architecture of the Name Server and discuss considerations that lead to its design.
Article
CSNET is built on the Department of Defense network (ARPANET), public packet-switched physical networks (Telenet), and a telephone-based relay network (Phonenet). Some CSNET sites have direct connections to ARPANET, some have direct connections to Telenet, and some have connections only to telephone-based relay machines. The chief objective of CSNET is to provide a network interconnection for all groups engaged in Computer Science Research. CSNET has adopted TCP/IP as its standard transport level protocols. The Transmission Control Protocol (TCP) [POST81] is an end-to-end protocol. It establishes communications between two processes that are running on different machines, detects and corrects errors, controls data flow, and provides reliable communications. Application programs call TCP to transfer data across the network. TCP, in turn, uses the Internet Protocol (IP) [POST81] to send data to the appropriate network. CSNET communications such as file transfer, remote login, and process-to-process communication over the network assume that a TCP interface is available at CSNET sites. Since ARPANET sites are required to support the TCP/IP protocols, CSNET sites connected directly to the ARPANET automatically have access to TCP/IP. Phonenet relays connect directly to the ARPANET; they too have access to TCP to relay mail onto the ARPANET. Telenet does not use the TCP/IP protocols. Consequently, CSNET sites that are connected only to Telenet need additional software before they can communicate on CSNET. That software is described in this paper -- it provides an interface between the public packet - switched protocol X.25 [CCITT78] and TCP/IP. Although the design outlined here is applicable to any vendor's system, our implemention is for a Digital Equipment Corporation VAX running the Western Electric UNIX [UNIX78] operating system as modified by the University of California at Berkeley. This report focuses on the technical issues involved in building software to interface TCP/IP and X.25. The tariff structure for public networks is discussed only to the extent that it influences our design. Other issues such as access control, and protocol selection are beyond the scope of this report.
Article
In 1981, the National Science Foundation started a five-year project totaling nearly $5 million to construct a computer science research network, CSNET, connecting all groups engaged in computer science research. For an NSF division with an annual budget of $25 million, the award represents an unusual commitment to a single project; only a handful of such large awards have been made. What is CSNET? Why is it receiving such attention? How will it benefit the community? When will it be completed? Who are the architects and implementors?
An internetwork memo distribution capability—MMDF, Proceedings of the sixth symposium on Data communications
  • H David
  • Edward S Crocker
  • David J Szurkowski
  • Farber