Showing papers on "The Internet published in 1982"

Grapevine: an exercise in distributed computing

Abstract: Grapevine is a multicomputer system on the Xerox research internet. It provides facilities for the delivery of digital messages such as computer mail; for naming people, machines, and services; for authenticating people and machines; and for locating services on the internet. This paper has two goals: to describe the system itself and to serve as a case study of a real application of distributed computing. Part I describes the set of services provided by Grapevine and how its data and function are divided among computers on the internet. Part II presents in more detail selected aspects of Grapevine that illustrate novel facilities or implementation techniques, or that provide insight into the structure of a distributed system. Part III summarizes the current state of the system and the lesson learned from it so far.

Words that Wound: A Tort Action for Racial Insults, Epithets, and Name-Calling

Abstract: One of the first articles to discuss the problem of hate speech, Words That Wound discusses the harms of racist speech before proposing a new tort enabling its victims to recover damages from the utterer. I later expanded the article into a book with Jean Stefancic. Entitled Understanding Words That Wound, the book covers a range of recent problems including hate speech on the Internet, campus hate speech codes, and child porn.

Window and Acknowledgement Strategy in TCP

Abstract: This RFC describes implementation strategies to deal with two mechanisms in TCP, the window and the acknowledgement. It also presents a particular set of algorithms which have received testing in the field, and which appear to work properly with each other. With more experience, these algorithms may become part of the formal specification, until such time their use is recommended.

Modularity and efficiency in protocol implementation

Abstract: This RFC will discuss some of the commonly encountered reasons why protocol implementations seem to run slowly.

Internet broadcasting

Abstract: Broadcasting should be a standard addressing mode of all packet-switched computer networks Further, when networks are interconnected to form an internet, a broadcast mechanism is also required Broadcasting is the delivery of a packet to all hosts in a network; unicasting is the delivery of a packet to one specific host They are distinct forms of interprocess communication; functions that are simple to do with one are difficult to do using only the other A broadcast is used when you don't know whom specifically to address There are two situations where this occurs: (1) when you are searching for some information but you don't know who to ask (for example, standing up in a theatre and saying "Is there a doctor in the house?"), and (2) when you possess some information of use to others but you don't know specifically who (for example, standing up in a theatre and yelling "Fire!") A network should give its best efforts to deliver a copy of a broadcast packet to each host, but perfectly reliable delivery is not required It is sufficient that most hosts receive a broadcast and that the same hosts not miss retransmissions Just as with unicasting, higher-level protocols can be used to improve the reliability of the basic broadcast delivery mechanism, if required Such an "unreliable" broadcast mechanism is straightforward to implement in all types of packet-switched networks In an internet composed of possibly thousands of networks and millions of hosts, a full internet-wide broadcast, the obvious internet analog to broadcasting in a single network, is seldom the right choice A directed broadcast, delivery of a packet to all hosts on any single network in an internet, is simpler to implement, closer to what most users need, and sufficient to construct many forms of broadcast-based interprocess communication, including an internet-wide broadcast

Exterior Gateway Protocol (EGP)

Abstract: This RFC is proposed to establish a standard for Gateway to Gateway procedures that allow the Gateways to be mutually suspicious. This document is a DRAFT for that standard. Your comments are strongly encouraged.

Domain naming convention for Internet user applications

Abstract: This RFC is an attempt to clarify the generalization of the Domain Naming Convention, the Internet Naming Convention, and to explore the implications of its adoption for Internet name service and user applications.

DoD Internet host table specification

Abstract: This RFC specifies a new host table format applicable to both ARPANET and Internet needs. In addition to host name to host address translation and selected protocol information, we have also included network and gateway name to address correspondence, and host operating system information. This RFC obsoletes the host table described in RFC 608.

DARPA Internet gateway

Abstract: This RFC is a status report on the Internet Gateway developed by BBN. It describes the Internet Gateway as of September 1982. This memo presents detailed descriptions of message formats and gateway procedures, however, this is not an implementation specification, and such details are subject to change.

Use of Multiple Networks in the Xerox Network System

Abstract: Managing information is an integral part of today's office, and Xerox's Network System is a distributed office information system that provides tools for doing this. With these tools, office personnel can create, store, retrieve, display, modify, reproduce, and share information in ways that encourage creativity and increase productivity. Workstations like Star help to simplify creation, modifiying, and displaying information. I Electronic filing, printing, database, and mail systems simplify storing, retrieving, reproducing, and sharing information. With the continuing improvements in the price/performance ratio of computing and communications, the structure of computerized office information systems is changing. We no longer need large centralized systems to realize economies of scale. Instead, we can push intelligence back into the workstation, and decentralize resources by function into dedicated servers to create a system that is a collection of loosely coupled elements tied together by a communication network. The Network System is just such a system, in which expensive resources are shared and information is exchanged among users. Within an organization, we typically find natural localities of activity and interaction. Interaction between localities generally decreases as they are farther apart. While the nature and characteristics of the interaction between close and distant stations are different, both are essential to the functioning of an organization. The Ethernet local computer network24 provides digital transmission of data, and satisfies most of the requirements for local office communications. The Ethernet, however, was designed in the context of an overall network architecture and is viewed as one component of an internetwork communication system that serves many diverse devices connected to many different kinds of networks.5-8 An internetwork architecture allows the communication system to be reconfigured to satisfy the immediate and future requirements of the user. For example, the Network System may have only one Ethernet initially and then be expanded (without software modification) to contain two or more Ethernets, which are interconnected directly or via other communication media, whose choice depends on the volume, frequency, and dispersion ofcommunications. Public and private packet-switching facilities can be used to carry higher dispersions of low-volume office communication, and as facilities for lower cost, higher rate, modemless digital transmission become available, they can be used to carry higher volumes of data. Of concern in this article are the major features of the Network System's internetwork communication system, in particular, its ability to use different kinds of networks (Figure 1). Protocol layers above the internetwork communication system permit different kinds of office services to be added as the need arises, thereby allowing an organization to minimize the initial purchase cost and to control any system expansion. The article also describes how the Network System can be connected to systems (network-based or stand-alone) from other vendors that obey different protocols by using protocol conversion gateways at different levels.

Perspective on the ARPANET reference model.

Abstract: This RFC is primarily intended as a perspective on the ARM and points out some of the differences between the ARM and the ISORM which were expressed by members in NWG general meetings, NWG protocol design committee meetings, the ARPA Internet Working Group, and private conversations over the intervening years. Originally published as M82-47 by the MITRE Corporation, Bedford, Massachusetts.

Name, addresses, ports, and routes

Abstract: This RFC gives suggestions and guidance for the design of the tables and algorithms necessary to keep track of these various sorts of identifiers inside a host implementation of TCP/IP.

Perspective on the ARPANET reference model

Abstract: This RFC is primarily intended as a perspective on the ARM and points out some of the differences between the ARM and the ISORM which were expressed by members in NWG general meetings, NWG protocol design committee meetings, the ARPA Internet Working Group, and private conversations over the intervening years. Originally published as M82-47 by the MITRE Corporation, Bedford, Massachusetts.

Computer mail meeting notes

Abstract: This RFC consists of notes from a meeting that was held at USC Information Sciences Institute on 11 January 1982, to discuss addressing issues in computer mail. The major conclusion reached at the meeting is to extend the "username@hostname" mailbox format to "username@host.domain", where the domain itself can be further strutured.

Distributed system for Internet name service

Abstract: This RFC proposes a distributed name service for DARPA Internet. Its purpose is to focus discussion on the subject. It is hoped that a general consensus will emerge leading eventually to the adoption of standards.

Gateways, architectures, and heffalumps

Abstract: This RFC is a discussion about the role of gateways in an internetwork, especially the problems of translating or mapping protocols between different protocol suites. The discussion notes possible functionality mis-matches, undesirable routing "singularity points", flow control issues, and high cost of translating gateways. Originally published as M82-51 by the MITRE Corporation, Bedford, Massachusetts.

CRONUS Virtual Local Network

Abstract: The purpose of this note is to describe the CRONUS Virtual Local Network, especially the addressing related features. These features include a method for mapping between Internet Addresses and Local Network addresses. This is a topic of current concern in the ARPA Internet community. This note is intended to stimulate discussion. This is not a specification of an Internet Standard.

Don't Get Taken Every Time: The Ultimate Guide to Buying or Leasing a Car, in the Showroom or on the Internet

Abstract: From the Publisher: Don't Get Taken Every Time takes you inside the world of the auto business and exposes all the ways dealers try to trick car buyers out of their money. From shopping and negotiating to financing, this book exposes scams and gives you step-by-step negotiating techniques for getting the best possible deal. Remar Sutton will show you how to beat the dealers and turn the Web into a powerful tool against them -- and save thousands of dollars in the process!

Illusion of vendor support

Abstract: This memo takes issue with the claim that international standards in computer protocols presently provide a basis for low cost vendor supported protocol implementations. Originally published as M82-49 by the MITRE Corporation, Bedford, Massachusetts.

Community corrections: is it just another way of tinkering with the criminal justice system?*

Abstract: This article discusses the theory underlying community corrections, problems involved in implementing it, and describes two recent evaluations of comprehensive community corrections, one in Minnesota and one in Oregon. Among the issues addressed are whether or not it has achieved the intended goals of reducing incarceration in state prisons at less cost, and whether or not it has widened the net of social control.

Performance of end-to-end and gateway-to-gateway flow control procedures in internet environments

Abstract: A performance comparison between end-to-end flow control (EEFC) and gateway-to-gateway flow control (GGFC) in internet environments is presented. The performance is measured in terms of average delivery delay of packets. First, a new technique for computing the average delivery delay across a network is introduced. It is shown that, for a given input rate to the network, there exists an optimum time-out which minimizes the average delivery delay. Then the performance is evaluated for EEFC and GGFC in an internet environment. It is observed that when the networks are in tandem, GGFC offers a better performance over that of EEFC. However, in general configurations where there is a high degree of traffic bifurcation between the networks, only under adaptive routing does GGFC result in a lower average delivery delay than that of EEFC. Finally, routing and flow control in internets are discussed.

Who talks TCP

Abstract: This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 14-Dec-82.

ARPANET Routing Algorithm Improvements, Volume 2

Abstract: : This report covers the work performed during the second year of the extension to the ARPANET Routing Algorithm Improvements Contract. The ARPANET simulator developed during the first year of the extension is used to investigate the performance and behavior of a number of routing algorithms, including the current ARPANET SPF algorithm. Results from the simulator are compared to measurements of SPF running on a small test network, measurements of the line protocol on the operational ARPANET, and the predictions of a stability model developed during the original contract. The simulation was run on a 14- node network using fixed single-path, fixed multi-path, and SPF (adaptive) routing. The performance of each routing method as a function of network load is compared to the predictions of a queueing model. As part of the design of an Internet, this report discusses design issues in the implementation of gateways, including the host interface to the Internet, interoperability of autonomous gateway systems, congestion control, and logical addressing.

How to Write Better Business Letters

Abstract: Updated to reflect uses of current word processing software and Internet communication, as well as to review standard business correspondence formats, this book instructs on how to write effective examples of every kind of business letter. It presents about 75 model letters in categories that include credit applications, letters of inquiry, orders of goods and services, formal business announcements, letters of recommendation, and sales promotional letters of the type used by direct marketers. This book also features examples of different letter formatting styles. The newly expanded chapter on e-mail correspondence includes discussion of effective presentation of Internet r (c)sum (c)s.

A telex gateway for the Internet

Abstract: : The design of a gateway connecting one of the networks of the MIT Laboratory for Computer Science to the telex network is discussed. A description of the telex network is given. The relationship of the gateway to other resources of the network environment is considered to obtain directions for the implementation of new resources. The implementation of the gateway on the UNIX operating system outlined. (Author)