RFC 231

Service Center Standards for Remote Usage--A User's View 🎀

Title block tea ☕ This is RFC 231 (NIC 7648), from the Network Working Group, written by J. Heafner (Rand) and E. Harslem (Rand), dated 21 September 1971. The header doesn't list anything it obsoletes or updates. 💜

Introduction ✨

okay bestie so this note is Rand's take on service center standards 💅. It's an input for the service center panel discussion at the October Network meeting, and it points out some areas for intra-network standardization. It does NOT describe a methodology for analyzing computer systems (though that analysis might be useful for solving the problems), and it doesn't list every service that might be needed. It just names the areas where having the same look and function is immediately valuable to a network user 🦋.

Caveat 🙈

It's assumed that service centers will conform to official network standard protocols. This is essential for service centers, because their practices tend to have wider effects, and those effects are crucial to how well minimal hosts like TIPs work. 🫶

Justification 👑

Generating network standards for service centers is super valuable to a very important group: the ultimate user community. At Rand, that's research scientists and their support programmers. Users like this exist elsewhere too, and a goal of the network has to be encouraging their use. Historically, these researchers relied only on programmers to buffer them from computer detail. Standardizing services is a huge win for growing the user community and getting rid of that buffer 🌸.

Standards also help the people who build resource access programs. Instances and areas of standardization are cited below to back up both of these points.

Areas for Standardization 💖

Each host installation has its own standards for programming and operational procedures. From a network point of view, we only care about standards that affect external performance, mainly required operations and documentation of procedures. Intra-network standards should let a user plan their network use effectively, so they can improve task performance and save time and money 🍓.

Remote Job Entry 🧚

One obvious area is access to network resources. Right now there are two remote job entry (RJE) facilities on the network, with two different data protocols. The UCSB facility was developed early to give 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 looked alike to the user and to the using process, two big things would happen. First, the using system would only need one module to access both facilities. Second, a user could pick either facility on a dynamic basis, based on whatever conditions are affecting them at any given moment, without needing any extra knowledge of the specific site 💅.

Login Procedures and Subsystem Access 🔑

A more global example of common resource access is the login procedure for remote systems. Every system needs basically the same info (password, identification, account number), but the formats are syntactically inconsistent. There's usually a "line scanner" extension to the logger at these sites for the network, and it also handles other transformational functions. It would make total sense for this module to translate a network standard login into whatever format the site needs. A similar approach could be taken, to a lesser extent, to build uniform access to subsystems from the supervisor. In the same way, a network standard interrupt could be translated into the serving host's escape (e.g., control C) for returning from a subsystem 🙌.

Charging Algorithms and Accounting Protocol 💸

To accurately forecast costs, you need a normalized formula for machine time estimation. Technically, an accounting protocol is easy to add at the subnet and/or NCP levels, because the relevant info is the same for all nodes, so Net charges can be readily determined by any node. The harder part is predicting and comparing host charges. Like the login example, each host uses the same ingredients: storage, I/O, connect time, and CPU resources. But, also like login, the info is handled slightly differently in each case, which makes estimations difficult. For example, some charge algorithms represent I/O as counts of I/O transactions, while others clock I/O time. Without significantly perturbing anyone's local accounting procedures, it's desirable to normalize the charge components as a step toward reasonable cost comparisons and forecasting 📊.

Off-Line Services 📦

Procedures need to be set up for off-line services, whether they're offered as a service or are an integral part of one. Examples are graphic hardcopy, large quantities of printer output, and tape or disc facilities. How are these items transmitted? What guarantees or statements 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 🏁

Building on those rather static cost comparisons that a normalized formula allows, imagine a small but useful process: a throughput query service. It lets the user dynamically find the most cost-effective location for a job. (This is technically reasonable, since some systems now offer status data like a core map and job queue displays.) Picture 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 query Tenex systems, providing the requirements of their program as input, and get answers like probable turn-around time and cost vectors for different priorities. (Also, our non-programmer users already know their job parameters, like time and core space, since that info is normally part of the output stream 👀.)

Most of the necessary elements for a service like this are readily available in the systems we're concerned with. The query service would be a utility for users. This is the kind of problem we should address when it comes to services vis-a-vis exporting Network concepts 💜.

Other Areas 🌈

On top of the above, 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 these items should be described in a standard format, rather than having the services themselves standardized across the network. For example, schedules obviously vary across time zones, and each system has a different magnitude and policy for on-line storage capabilities 🌍.

Some of this is already covered in the Resource Notebook. It should either be expanded to become a service center standards notebook, or a separate item should be created to do that job. For example, a site might have resources it wants to offer on a limited or special arrangement basis to the network community, and those should be included as such in the Resource Notebook. However, that site might not want to, or have the staff to, conform to network service center standards. So the service center notebook would describe standards for a much more rigorously conforming community 🧾.

Summary 🎉

The big idea here is that, without classifying services and analyzing operations at service nodes, there are a number of areas that can be standardized to some extent across the network. What's needed is a manual of service center standards and a collection of documentation on services. Maybe the latter is the Resource Notebook ✨.

Service centers that want to attract a significant network user community should be ready to adopt a psychology that fits the market-oriented requirements of providing service. In the network at large, with our research orientation, personnel tend to have a different approach to computing than what a service bureau requires 💅.

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. 🫶