[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

Tweet
This is a modified version of the Internet RFC suitable for machine-translating. Original version is available here: RFC231
Ad

UNKNOWN
Network Working Group                     J. Heafner - Rand
Request for Comments  231                 E. Harslem - Rand
NIC 7648                                  21 September 1971
SERVICE CENTER STANDARDS ------------------------ FOR REMOTE USAGE--A USER'S VIEW
                    -------------------------------
INTRODUCTION ------------

This note is a statement of our views on service cen- ter
standards. It is an input to the service center panel discussion of the October Network meeting. Some areas are identified for consideration in intra-network standardiza- tion. We do not describe a methodology for analyzing com- puter systems; however, such analysis may be appropriate for solving the problems. We also do not enumerate the spectrum of services that may be required. We merely enu- merate areas where commonality of appearance and function can be of immediate value to a network user.

CAVEAT ------

It is assumed that service centers will conform to official
network standard protocols. This is essential for service centers since the effects of their practices are generally more wide-spread and are crucial to the effectiveness of minimal hosts such as TIPs.

JUSTIFICATION -------------

The generation of network standards for service centers is of
value to a very important class of people--the ultimate user community. We have such a community at Rand that is composed of research scientists and their support programmers. Certainly such users exist elsewhere, and a goal of the net- work must be to encourage their use. In the past, these researchers have relied solely on programmers to buffer them from computer detail. Standardization of services is cer- tainly a great value in expanding the community of users and eliminating the buffer.

Additionally, standards will be of benefit to those persons
responsible for implementation of resource access programs. Instances and areas of standardization are cited below to support both of these statements. -------------------------
                                                                [Page 1]

AREAS FOR STANDARDIZATION
Each host installation has its own standards for pro- gramming
and operational procedures. From a network point of view, we are only interested in standards affecting external performance--primarily required operations and documentation of procedures. Intra-network standards should allow a user to plan his network use effectively to improve the performance of his tasks and take advantage of savings in both time and money.

Remote Job Entry ----------------

One immediately apparent area for standardization is in the
access to network resources. For example, there are two remote job entry (RJE) facilities on the network at present with two different data protocols. The UCSB facility was developed early to provide timely access to their resources. The UCLA facility was developed after the Telnet and Data Transfer protocols and takes advantage of them. If these two services appeared alike to the user and to the using process, two significant advantages would be obtained. First, the using system would need only one module to access both facilities. And secondly, a user could select either facility on a dynamic basis using the conditions influencing him at any given moment without any additional knowledge of the specific site.

Login Procedures and Subsystem Access -------------------------------------

A more global example of common access to resources is the login
procedure to remote systems. All systems require basically the same information--password, identification, account number. Yet the formats are syntactically inconsis- tent. An extension to the logger generally exists at these sites in the form of a "line scanner" for the network. In general, this module also performs other transformational functions. It would certainly be reasonable for this module to translate a network standard login into whatever format was required at the site. Perhaps to a lesser extent, a similar approach could be taken to constructing a uniform access to subsystems from the supervisor. In like fashion, a network standard interrupt could be translated into the escape (e.g., control C) of the serving host to return from a subsystem.

Charging Algorithms and Accounting Protocol -------------------------------------------

To accurately forecast costs, a normalized formula for machine
                                                                [Page 2]

time estimation is needed.  Technically, an accounting protocol is
easily added at the subnet and/or NCP levels--the relevant information is the same for all nodes, thus the Net charges are readily determined by any node. More difficult is the prediction and comparison of host charges. Like the login procedure example, each host uses the same ingredients, namely storage, I/O, connect time, and CPU resources expended. Again, like the login procedure the information is handled slightly dif- ferently in each case such that estimations are difficult. For example, some charge algorithms represent I/O as counts of I/O transactions where others clock I/O time. Without significantly perturbing anyone's local accounting proce- dures, it is desirable to normalize the charge components as a step toward reasonable cost comparisons and forecast- ing.

Off-Line Services ----------------- .

Procedures need to be established for off-line services where
they are offered as a service or are an integral part of a service. Such services are graphic hardcopy, large quantities of printer output, tape or disc facilities, etc. How are such items transmitted? What guarantees or state- ments should be made about turnaround times? How should they be specified--in terms of invocation and communication with operations staffs?

Job Scheduling, Priorities and Status Information -------------------------------------------------

Extrapolating from the above rather static cost com- parisons
that a normalized formula allows, envision a small but useful process, i.e., a throughput query service, that allows the user to dynamically determine the most cost ef- fective location for a job. (Such a service is technically reasonable since some systems now offer status data such as a core map and job queues display.) Imagine the user's situation. "Let's see, I need these numbers by 4:00 and I'm willing to pay a slight dollar premium to get them; the job will run on any Tenex machine, where should I run it?" The user would like to query Tenex systems, providing as input the requirements of his program, and get answers like probable turn-around time and cost vectors for dif- ferent priorities. (Incidentally, our non-programmer users are familiar with their job parameters (time, core space, etc.) since this information is normally part of the out- put stream.)

Most of the necessary elements for such a service are readily
available in systems with which we are concerned. The query service would be a utility for users. This is the kind of a problem we should address concerning services vis-a-vis exporting Network concepts. -----------
                                                                [Page 3]

Other Areas
In addition to the above items, the user community could
immediately benefit from standards in: documentation formats and distribution, operating schedules, the extent and availability of consulting services, data transmission and storage facilities, techniques for communication with operations staffs, and abnormal procedures such as system or program failures.

Some of the above items should be described in a standard format
rather than the services themselves being standardized across the network. For example, schedules obviously vary in different time zones and each system has a different magnitude and policy for on-line storage capabilities.

To some extent these items are covered in the Resource Notebook.
It should either be expanded to become a service center standards notebook or a separate item to fulfill that function should be created. For example, a site might have resources that it wished to offer on a limited or special arrangement basis to the network community and should be included as such in the Resource Notebook. However, that site might not wish to or have the staff to conform to network service center standards. Hence, the service center notebook would describe standards for a much more rigor- ously conforming community.

SUMMARY -------

The theme of this note is that without classifying ser- vices and
analyzing operations at service nodes, there are a number of areas that can be standardized to some extent throughout the network. What is needed is a manual of service center standards and a collection of documentation on services. Perhaps the latter is the Resource Notebook.

Service centers who intend to attract a significant network user
community should be prepared to adopt a psychol- ogy appropriate to the market-oriented requirements for providing service. In the network at large, with our re- search orientation, personnel tend to have a different approach to computing than that required by a service bureau.

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by BBN Corp. under the ] [ direction of Alex McKenzie. 12/96 ]




[Page 4]


Ad
Translate documents to 日本語, svenska, Nederlands, Deutsch, français, русский, italiano, español, Tiếng Việt, polski, português, 中文, українська, català, norsk, فارسی, suomi, Bahasa Indonesia, العربية, čeština, 한국어, Bahasa Melayu, magyar, română, српски and other languages.
inserted by FC2 system