diff options
Diffstat (limited to 'doc/rfc/rfc231.txt')
| -rw-r--r-- | doc/rfc/rfc231.txt | 218 |
1 files changed, 218 insertions, 0 deletions
diff --git a/doc/rfc/rfc231.txt b/doc/rfc/rfc231.txt new file mode 100644 index 0000000..ab4ab02 --- /dev/null +++ b/doc/rfc/rfc231.txt @@ -0,0 +1,218 @@ + + + + + + +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] + |