    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]