home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 200s / rfc231.txt < prev    next >
Text File  |  1997-03-04  |  10KB  |  219 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                     J. Heafner - Rand
  8. Request for Comments  231                 E. Harslem - Rand
  9. NIC 7648                                  21 September 1971
  10.  
  11.  
  12.                         SERVICE CENTER STANDARDS
  13.                         ------------------------
  14.                     FOR REMOTE USAGE--A USER'S VIEW
  15.                     -------------------------------
  16.  
  17. INTRODUCTION
  18. ------------
  19.  
  20.      This note is a statement of our views on service cen- ter
  21. standards.  It is an input to the service center panel discussion of
  22. the October Network meeting.  Some areas are identified for
  23. consideration in intra-network standardiza- tion.  We do not describe
  24. a methodology for analyzing com- puter systems; however, such analysis
  25. may be appropriate for solving the problems.  We also do not enumerate
  26. the spectrum of services that may be required.  We merely enu- merate
  27. areas where commonality of appearance and function can be of immediate
  28. value to a network user.
  29.  
  30. CAVEAT
  31. ------
  32.  
  33.      It is assumed that service centers will conform to official
  34. network standard protocols.  This is essential for service centers
  35. since the effects of their practices are generally more wide-spread
  36. and are crucial to the effectiveness of minimal hosts such as TIPs.
  37.  
  38. JUSTIFICATION
  39. -------------
  40.  
  41.      The generation of network standards for service centers is of
  42. value to a very important class of people--the ultimate user
  43. community.  We have such a community at Rand that is composed of
  44. research scientists and their support programmers.  Certainly such
  45. users exist elsewhere, and a goal of the net- work must be to
  46. encourage their use.  In the past, these researchers have relied
  47. solely on programmers to buffer them from computer detail.
  48. Standardization of services is cer- tainly a great value in expanding
  49. the community of users and eliminating the buffer.
  50.  
  51.      Additionally, standards will be of benefit to those persons
  52. responsible for implementation of resource access programs.  Instances
  53. and areas of standardization are cited below to support both of these
  54. statements.
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. AREAS FOR STANDARDIZATION
  61. -------------------------
  62.  
  63.      Each host installation has its own standards for pro- gramming
  64. and operational procedures.  From a network point of view, we are only
  65. interested in standards affecting external performance--primarily
  66. required operations and documentation of procedures.  Intra-network
  67. standards should allow a user to plan his network use effectively to
  68. improve the performance of his tasks and take advantage of savings in
  69. both time and money.
  70.  
  71. Remote Job Entry
  72. ----------------
  73.  
  74.      One immediately apparent area for standardization is in the
  75. access to network resources.  For example, there are two remote job
  76. entry (RJE) facilities on the network at present with two different
  77. data protocols.  The UCSB facility was developed early to provide
  78. timely access to their resources.  The UCLA facility was developed
  79. after the Telnet and Data Transfer protocols and takes advantage of
  80. them.  If these two services appeared alike to the user and to the
  81. using process, two significant advantages would be obtained.  First,
  82. the using system would need only one module to access both facilities.
  83. And secondly, a user could select either facility on a dynamic basis
  84. using the conditions influencing him at any given moment without any
  85. additional knowledge of the specific site.
  86.  
  87. Login Procedures and Subsystem Access
  88. -------------------------------------
  89.  
  90.      A more global example of common access to resources is the login
  91. procedure to remote systems.  All systems require basically the same
  92. information--password, identification, account number.  Yet the
  93. formats are syntactically inconsis- tent.  An extension to the logger
  94. generally exists at these sites in the form of a "line scanner" for
  95. the network.  In general, this module also performs other
  96. transformational functions.  It would certainly be reasonable for this
  97. module to translate a network standard login into whatever format was
  98. required at the site.  Perhaps to a lesser extent, a similar approach
  99. could be taken to constructing a uniform access to subsystems from the
  100. supervisor.  In like fashion, a network standard interrupt could be
  101. translated into the escape (e.g., control C) of the serving host to
  102. return from a subsystem.
  103.  
  104. Charging Algorithms and Accounting Protocol
  105. -------------------------------------------
  106.  
  107.      To accurately forecast costs, a normalized formula for machine
  108.  
  109.  
  110.  
  111.                                                                 [Page 2]
  112.  
  113. time estimation is needed.  Technically, an accounting protocol is
  114. easily added at the subnet and/or NCP levels--the relevant information
  115. is the same for all nodes, thus the Net charges are readily determined
  116. by any node.  More difficult is the prediction and comparison of host
  117. charges.  Like the login procedure example, each host uses the same
  118. ingredients, namely storage, I/O, connect time, and CPU resources
  119. expended.  Again, like the login procedure the information is handled
  120. slightly dif- ferently in each case such that estimations are
  121. difficult.  For example, some charge algorithms represent I/O as
  122. counts of I/O transactions where others clock I/O time.  Without
  123. significantly perturbing anyone's local accounting proce- dures, it is
  124. desirable to normalize the charge components as a step toward
  125. reasonable cost comparisons and forecast- ing.
  126.  
  127. Off-Line Services
  128. -----------------                             .
  129.  
  130.      Procedures need to be established for off-line services where
  131. they are offered as a service or are an integral part of a service.
  132. Such services are graphic hardcopy, large quantities of printer
  133. output, tape or disc facilities, etc.  How are such items transmitted?
  134. What guarantees or state- ments should be made about turnaround times?
  135. How should they be specified--in terms of invocation and communication
  136. with operations staffs?
  137.  
  138. Job Scheduling, Priorities and Status Information
  139. -------------------------------------------------
  140.  
  141.      Extrapolating from the above rather static cost com- parisons
  142. that a normalized formula allows, envision a small but useful process,
  143. i.e., a throughput query service, that allows the user to dynamically
  144. determine the most cost ef- fective location for a job.  (Such a
  145. service is technically reasonable since some systems now offer status
  146. data such as a core map and job queues display.) Imagine the user's
  147. situation.  "Let's see, I need these numbers by 4:00 and I'm willing
  148. to pay a slight dollar premium to get them; the job will run on any
  149. Tenex machine, where should I run it?" The user would like to query
  150. Tenex systems, providing as input the requirements of his program, and
  151. get answers like probable turn-around time and cost vectors for dif-
  152. ferent priorities.  (Incidentally, our non-programmer users are
  153. familiar with their job parameters (time, core space, etc.) since this
  154. information is normally part of the out- put stream.)
  155.  
  156.      Most of the necessary elements for such a service are readily
  157. available in systems with which we are concerned.  The query service
  158. would be a utility for users.  This is the kind of a problem we should
  159. address concerning services vis-a-vis exporting Network concepts.
  160.  
  161.  
  162.  
  163.  
  164.                                                                 [Page 3]
  165.  
  166. Other Areas
  167. -----------
  168.  
  169.      In addition to the above items, the user community could
  170. immediately benefit from standards in: documentation formats and
  171. distribution, operating schedules, the extent and availability of
  172. consulting services, data transmission and storage facilities,
  173. techniques for communication with operations staffs, and abnormal
  174. procedures such as system or program failures.
  175.  
  176.      Some of the above items should be described in a standard format
  177. rather than the services themselves being standardized across the
  178. network.  For example, schedules obviously vary in different time
  179. zones and each system has a different magnitude and policy for on-line
  180. storage capabilities.
  181.  
  182.      To some extent these items are covered in the Resource Notebook.
  183. It should either be expanded to become a service center standards
  184. notebook or a separate item to fulfill that function should be
  185. created.  For example, a site might have resources that it wished to
  186. offer on a limited or special arrangement basis to the network
  187. community and should be included as such in the Resource Notebook.
  188. However, that site might not wish to or have the staff to conform to
  189. network service center standards.  Hence, the service center notebook
  190. would describe standards for a much more rigor- ously conforming
  191. community.
  192.  
  193. SUMMARY
  194. -------
  195.  
  196.      The theme of this note is that without classifying ser- vices and
  197. analyzing operations at service nodes, there are a number of areas
  198. that can be standardized to some extent throughout the network.  What
  199. is needed is a manual of service center standards and a collection of
  200. documentation on services.  Perhaps the latter is the Resource
  201. Notebook.
  202.  
  203.      Service centers who intend to attract a significant network user
  204. community should be prepared to adopt a psychol- ogy appropriate to
  205. the market-oriented requirements for providing service.  In the
  206. network at large, with our re- search orientation, personnel tend to
  207. have a different approach to computing than that required by a service
  208. bureau.
  209.  
  210.        [ This RFC was put into machine readable form for entry ]
  211.        [ into the online RFC archives by BBN Corp. under the   ]
  212.        [ direction of Alex McKenzie.                   12/96   ]
  213.  
  214.  
  215.  
  216.  
  217.                                                                 [Page 4]
  218.  
  219.