home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 1 / rfc0150.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  27.5 KB  |  609 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Richard Bl. Kalin                            Network Working Group
  8. MIT Lincoln Laboratory                       Request for Comments #150
  9. 5 May 1971                                   NIC 6754
  10.  
  11.  
  12. THE USE OF IPC FACILITIES
  13.  
  14. ***A WORKING PAPER***
  15.  
  16. This material has not been reviewed for public release and is intended
  17. only for use within the ARPA network. It should not be quoted or cited
  18. in any publication not related to the ARPA network.
  19.  
  20. INTRODUCTION
  21.  
  22.       It is our hypothesis that the goals of interprocess communication
  23. are more complex than commonly realized, and that until this complexity
  24. is more fully understood, there will be no satisfactory implementations.
  25. The objective of an IPC design must be more than that of providing a
  26. facility for moving bits between otherwise independent user programs, a
  27. variety of other constraints must also be satisfied.
  28.  
  29.       These constraints are dictated by the eventual usage of the
  30. facility. Any design that will sustain this usage pattern can be a
  31. satisfactory one. If it does so efficiently, it will be said to be well
  32. designed. Furthermore, it is unimaginable that a large design effort,
  33. undertaken without a complete understanding of the usage it must serve,
  34. will ever be well designed or even satisfactorily designed.
  35.  
  36.       This paper undertakes the exposition of the types of usage to
  37. which an IPC facility would be subjected, in hopes that such a
  38. discussion will clarify the goals being pursued and will provide a
  39. benchmark for gauging various implementation strategies. The difficulty
  40. of this task should not be underestimated. The only experience available
  41. for us to draw upon is from very primitive and overly constrained IPC
  42. implementations. Extrapolation from this limited usage environment to
  43. more general notions has as yet no basis in real experience. Such
  44. speculation is therefore subject to enormous oversight and misguided
  45. perspective.
  46.  
  47.       In compiling this paper, it was necessary to imagine what services
  48. a process might want from an IPC facility. The areas recognized include:
  49.  1) the exchange of bit encoded information via channels.
  50.  2) the establishment, deletion, and reassignment of these channels.
  51.  3) the ability to debug errors and suspected errors.
  52.  4) the potential to improve running efficiency.
  53.  5) the capacity to avoid storage allocation deadlocks.
  54.  6) the aided recovery from transmission errors.
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. RFC #150                 Use of IPC Facilities                5 May 1971
  61.  
  62.  
  63. This list is known to be incomplete. Some areas, such as understood to
  64. be intelligently discussed. In other cases, omissions should be blamed
  65. on simple oversight.
  66.  
  67.       Because of these obvious problems, one should not consider any
  68. document of this kind as either authoritative or final. For this reason,
  69. this paper is being kept as a computer based textfile, and so will
  70. remain subject to editting and rerelease whenever new insights become
  71. understood. We hope that it can remain an accurate and up to date
  72. statement of the goals to which any group of IPC implementers can aspire
  73. and, as such, can be a guidebook to the problems that must be faced.
  74.  
  75.       For several reasons no attempt shall be made here to design
  76. suitable solutions to the problems raised. To be useful, such solutions
  77. must be machine dependent. A so called 'general solution' would actually
  78. be too clumsy and inefficient to be of any value. Secondly, we take the
  79. point of view of the user, who need not be aware of the manner in which
  80. his demands are carried out, so long as they can be accomplished.
  81. Finally, we are trying to stay aloof from the eccentricities of present
  82. day machine organization.
  83.  
  84. In our attempt to be implementation independent, we are admittedly
  85. treading a fuzzy line. Our characterization of usage patterns presumes
  86. both a system/process software organization and a computing milieu
  87. capable of supporting it. Although this does not appear to significantly
  88. affect the generality of the document, some care must be exercised in
  89. the selection of host machines.
  90.  
  91.                *****
  92.  
  93.       In the rest of this paper, we attempt to characterize the types of
  94. usage that should be anticipated by an IPC facility. The organization is
  95. into titled sections, each section discussing some aspect of the
  96. expected usage.
  97.  
  98. ABILITY TO USE VARIOUS SOURCES OF WAKEUP INFORMATION
  99.  
  100.       Most processes exhibit preferences toward certain quantities of
  101. input data. This preference is reflected in the amount of computing time
  102. that can be expended for a given amount of input. For example, a
  103. character translation routine might prefer eight bit quantities of
  104. input. With seven or less bits no processing is possible, but once a
  105. complete character is available an entire translation cycle can
  106. commence. This preference is independent of the function of the routine.
  107. Otherwise equivalent routines could be written that would accept one bit
  108. at a time. In other examples, a command interpreter might require a
  109. complete line of input, a linking loader a complete file.
  110.  
  111.  
  112.  
  113.  
  114.                                                                 [Page 2]
  115.  
  116. RFC #150                 Use of IPC Facilities                5 May 1971
  117.  
  118.  
  119.       Every executive system must face the problem of deciding at what
  120. times enough input is available for a given routine for it to run
  121. efficiently. This decision can not be taken lightly. Issuing a wakeup to
  122. a dormant process carries with it considerable overhead -- room in core
  123. storage must be made available, the program must be swapped into memory,
  124. tables must be updated, active registers exchanged, and the entire
  125. procedure done in reverse once the process has finished. To issue a
  126. wakeup when there is insufficient input for the program is inefficient
  127. and wasteful. The amount of computing that can be done does not justify
  128. the overhead that must be expended.
  129.  
  130.       The problem of determining a priori the best time to issue a
  131. wakeup has no general solution. It depends critically upon the
  132. relationship between waiting costs and running costs. Attempts to make
  133. reasonable predictions must contend with the tradeoff between accuracy
  134. and overhead. The more system code that must be run, the more overhead
  135. incurred and the less the final prediction means.
  136.  
  137.       Although there is no general solution, help is available to the
  138. scheduler in specific cases. A commonly found instance is that of using
  139. the receiving process to specify the number of bits that it is
  140. expecting. Thus, a process may inform the supervisor/scheduler that it
  141. requires fifty bits of input from some source before it is able to
  142. continue. The process can then go into the shade and it will be awakened
  143. when the required input is available.
  144.  
  145.       In cases where input lengths are predetermined, this technique is
  146. quite satisfactory. Elsewhere, problems arise. In the case of unknown
  147. input sizes, too short a prediction will give rise to the inefficiencies
  148. of premature scheduling, and too long a prediction may produce input
  149. deadlocks.
  150.  
  151.       Under these circumstances it is common to have the process tell
  152. the scheduler a simple criterion that can be applied to determine if
  153. there is sufficient input -- the appearance of a carriage return in the
  154. teletype input stream, for example. The criterion is tested either by
  155. system routines or by a low overhead user supplied routine (which in
  156. turn must have a criterion of its own for being awakened).  Once the
  157. criterion is met, the main routine is awakened and processing continues.
  158.  
  159.       Sometimes the system and user criteria work in conjunction with
  160. one another. A user may specify an maximum character count,
  161. corresponding to available buffer size, and the system may look for line
  162. terminators. Wakeups to the user process may appear from either source.
  163. At other times the system may preempt the user's criterion. For example,
  164. if a process while trying to put a single character into a full buffer
  165. is forced into shade, it will typically not be awakened again until
  166. buffer has been almost emptied. Even though the user program only wished
  167.  
  168.  
  169.  
  170.                                                                 [Page 3]
  171.  
  172. RFC #150                 Use of IPC Facilities                5 May 1971
  173.  
  174.  
  175. room for a single character, the system imposed a much stronger
  176. criterion, namely room for N characters, on the assumption other calls
  177. to output characters will follow. Thus the program is forced into
  178. outputting in bursts and, rather than going into the shade and being
  179. awakened N times, each time when there is only room to output one
  180. character, the program is awakened once and sends N characters. Program
  181. efficiency is appropriately improved.
  182.  
  183.       A third source of criteria for deciding when to awaken the user
  184. process is the device or routine that is producing the input data. This
  185. source is frequently utilized in hardware design. Many computer
  186. peripherals have the ability to send an end of record indication. For
  187. variable length uninterpreted records this is an absolute necessity. For
  188. fixed length records it is a convenient double check. In the world of
  189. interprocess communication an analogous feature should be available. If
  190. the routine that is generating the data knows how much the receiving
  191. routine will require, then this information should be made available for
  192. scheduling purposes. Implementing this requires a standardized way of
  193. denoting logical boundaries on the stream of data flowing, through a
  194. communication channel. The markers must be recognizable by the
  195. scheduler/supervisor in the receiving host computer so that wakeups can
  196. be issued as desired. To simplify the task of input interpretation,
  197. marker pacement should also be visible to the receiving process.
  198.  
  199.       The data between boundaries we shall call a logical message, since
  200. it is a natural unit of information exchange and since the markers
  201. travel with the data through the channel. The additional information the
  202. markers provide about data flow yield many useful consequences.
  203. Consider, for example, two processes that always exchange 100 bit long
  204. logical messages. If the receiving process is able to determine the
  205. length of each logical message that arrives, there is available a simple
  206. facility for error detection. If a 99 bit message arrives, it is obvious
  207. that a bit has been dropped somewhere.
  208.  
  209.       It should be noted that it is not always possible for the
  210. receiving process to compute the positions of boundary markers in the
  211. input stream. there is no reason that the information implicit is marker
  212. position must also be found as part of the coded input data. Even in
  213. cases in which there is coding redundancy, it may be more difficult to
  214. extract boundary information from the rest of the input than it is to
  215. use the markers explicitly.
  216.  
  217. ABILITY TO SEND PARTS OF LOGICAL MESSAGES
  218.  
  219.       Any IPC facility, in which user storage is at all constrained, can
  220. not require a process to send an entire logical message at one time. The
  221. concept is only introduced to facilitate the issuing of wakeups to a
  222. receiving process. What are convenient input quanta for the receiving
  223.  
  224.  
  225.  
  226.                                                                 [Page 4]
  227.  
  228. RFC #150                 Use of IPC Facilities                5 May 1971
  229.  
  230.  
  231. process may not be convenient output quanta for the sending one.
  232. consider the case of a process running on a small machine and sending
  233. messages to a process on a large task-multiplexed machine. For
  234. efficiency, the receiving process requires large quantities of input
  235. data at a time. Buffer space in the address space of the sending process
  236. can not hold much data. The only answer is to allow the sending process
  237. to dump its logical message in parts and with the last part to indicate
  238. that it is the end of a message.
  239.  
  240. ABILITY TO RECEIVE A LOGICAL MESSAGE IN PARTS
  241.  
  242.       In the reverse of the above situation, a receiving process may not
  243. have sufficient buffer space available to accept an entire message at
  244. once. It should be possible under these circumstances to elect to accept
  245. the message in parts. This is also necessary in the case of messages
  246. that are too long to be buffered by the system. Unless part of the
  247. message is accepted by the receiving process, the transmission can never
  248. be completed. This device also serves for the removal of very long
  249. messages that appear by error in the input stream.
  250.  
  251. ABILITY TO FIND OUT IF A MESSAGE CAN BE SENT
  252.  
  253.       If left unchecked, a routine can easily generate messages faster
  254. than they can be consumed. Since any given amount of buffer capacity can
  255. be quickly exhausted, there must be a way for the system to limit the
  256. rate at which a process produces messages. This implies that at times a
  257. process trying to send a message may be prevented from doing so because
  258. of buffer inavailability. If the process is forced into the shade, the
  259. pause should not come without warning. There should be a way for the
  260. process to learn in advance if the message can be sent. A program may
  261. have better things to do than wait for a buffer to become available.
  262.  
  263. ABILITY TO GET A GUARANTEE OF OUTPUT BUFFER SPACE
  264.  
  265.       A process should be able to get guarantee from the system that a
  266. message of a certain size can be sent. This allows the process to know
  267. before a computation is made that the results can be successfully
  268. output. This allocation should remain either until it is depleted or
  269. until it is changed by another allocation request.
  270.  
  271.       This particular user option is sure to raise the wrath of legions
  272. of system programmers. From their point of view, the empty buffer space
  273. that is being preallocated is necessarily being wasted. For although it
  274. contains no messages, it is not available for other uses. The user, on
  275. the other hand, does not correlat    In compilh 'wasteful' nor 'full'
  276. with 'efficient'. A process needs empty output buffers as much as it
  277. needs full input ones. Both are resources necessary to sustain
  278. processing.
  279.  
  280.  
  281.  
  282.                                                                 [Page 5]
  283.  
  284. RFC #150                 Use of IPC Facilities                5 May 1971
  285.  
  286.  
  287. ABILITY TO FIND OUT ABOUT OUTSTANDING MESSAGES
  288.  
  289.       A process that is sending messages over a channel should be able
  290. to find out how many of those messages have not yet been accepted by the
  291. user process at the far end and whether or not this number can decrease.
  292. Ideally, it should also be able to determine the number of bits left in
  293. any partially accepted message, but the overhead necessary to implement
  294. this on conventional systems may be too great to be tolerated.
  295.  
  296.       The count returned can be useful both dynamically and for post
  297. mortems. Used in debugging a remote process, it allows inputs on
  298. normally concurrent channels to be presented one at a time and in any
  299. given order. In this way one could, for example, verify that the same
  300. results are produced regardless of the order in which the inputs arrive.
  301.  
  302.       If there is a failure of a receiving process, this mechanism
  303. allows a sending process to determine the last input accepted before the
  304. process died. Even between operational processes it provides a user
  305. managed way for the transmitting process to slow down and let the
  306. receiver catch up with it. By pinpointing bottlenecks, it can be used to
  307. detect design mismatches.
  308.  
  309.       Unless the channel has no outstanding messages or it is dead,
  310. there is the possibility that concurrently with the request the
  311. receiving process will accept another message. This being the case, the
  312. count returned can not be assumed to be exact but must be considered as
  313. only an upper bound.
  314.  
  315. ABILITY TO GET WAKEUPS WHEN MESSAGES ARE ACCEPTED
  316.  
  317.       In conjunction with the above it should be possible for a user
  318. process to be alerted when the number of messages that have been sent
  319. over a particular channel and not accepted at the far end falls below a
  320. specified threshold. Thus a process, upon discovering that twenty
  321. messages are still outstanding, can elect to enter the shade until this
  322. number has fallen to less than five. By doing so the process can run in
  323. 'burst mode'. Rather than being swapped in and out of core fifteen times
  324. and each time being allowed to send one message, it is loaded once and
  325. sends fifteen messages. There is no penalty for doing this since the
  326. bottleneck on throughput is at the receiving process. If swapping costs
  327. for the local process are significant, there may be considerable
  328. economic advantage to this mode of operation.
  329.  
  330.       If the remote process dies or issues a channel 'close', the count
  331. of undelivered messages becomes frozen. If the receiving process is
  332. expecting this type of wakeup, it should get one at this time even
  333. though the count has not reached the desired threshold. The process is
  334. thus alerted to do a postmortem on the channel.
  335.  
  336.  
  337.  
  338.                                                                 [Page 6]
  339.  
  340. RFC #150                 Use of IPC Facilities                5 May 1971
  341.  
  342.  
  343. ABILITY TO LEARN ABOUT MESSAGES QUEUED FOR INPUT
  344.  
  345.       A process should be able to learn of the status of the Nth logical
  346. message queued on a given input channel. It should a least be able to
  347. determine if it is available, whether or not it is complete, how long it
  348. is and what it contains.
  349.  
  350.       This facility allows a program to make general preparations before
  351. accepting a message. It offers some escape from being put into the
  352. awkward position of having accepted input and not being able to dispose
  353. of it. If for example, it is known that processing the message will
  354. result in two more messages being sent, then it is advantageous to get
  355. guarantees that the output can be generated before the input is
  356. accepted.
  357.  
  358.       Under circumstances in which one end of a channel is moved from
  359. one process to another, for example, moving a teletype connection
  360. between a user program and a debugging program, this ability to scan
  361. ahead in the input stream allows a process to check whether or not
  362. pending input is really meant for it. If it is, the input will then be
  363. accepted normally, otherwise, the end of the channel must be first moved
  364. to another receiving process.
  365.  
  366.       Accepting input should be viewed as a grave responsibility, not to
  367. be undertaken unless there is reasonable assurance that the input can be
  368. processed. One of the first rules of asynchronous system design is to
  369. detect errors as soon as possible. If propagated, the tangled results
  370. may be hopeless to unravel.
  371.  
  372. ABILITY TO LEARN HOW MANY MESSAGES ARE WAITING
  373.  
  374.       A process should be able to determine how many messages are
  375. left to be processed on a given input channel. Two uses are readily
  376. thought of. Given pending inputs on several channels a process should be
  377. able to exercise preference. One decision might be to take input first
  378. from the channel with the most messages queued. This might have the
  379. effect of increasing throughput since by freeing message buffers the
  380. remote transmitting process might be allowed to run. Another possibility
  381. might be that the receiving process has some control over the sending
  382. process and, upon observing the backlog on inputs, it could tell that
  383. process to slow down.
  384.  
  385.       Assuming that the remote process is still able to send messages,
  386. the number of inputs reported is only a lower bound. New inputs may be
  387. added concurrently. If the foreign process has died or has otherwise
  388. closed the connection then the bound can be made exact. The local
  389. process should be able to learn when it is exact.
  390.  
  391.  
  392.  
  393.  
  394.                                                                 [Page 7]
  395.  
  396. RFC #150                 Use of IPC Facilities                5 May 1971
  397.  
  398.  
  399. GUARANTEE THAT INPUT WILL STAY AVAILABLE
  400.  
  401.       This requirement states that if a process has been told that it is
  402. able to receive N messages on a given channel, that those messages are
  403. really available and buffered within the host machine. If promised to a
  404. user process, messages should not mysteriously become unavailable. An
  405. example of how this might happen is illustrated in RFC60.  There, during
  406. a panic for buffer space, messages are destroyed and reported as being
  407. in error. They are later recovered from backup copies contained in the
  408. foreign host.
  409.  
  410. ABILITY TO RECEIVE A WAKEUP WHEN INPUTS ARRIVE
  411.  
  412.       A process should be able to enable a wakeup when the number of
  413. messages queued on an input channel exceeds a specified value or has
  414. reached its maximum value. This allows a program to process input in a
  415. burst mode fashion and to economize on swapping costs. It also permits
  416. inputs to be combined in a simple manner. If, for example, two inputs
  417. are needed before anything can be done, then the appropriate interrupt
  418. can be easily generated.
  419.  
  420.       The same interrupt should be generated if the maximum number of
  421. inputs have been received. Two cases are distinguished. Either the
  422. foreign process has closed the channel and is therefore not sending more
  423. messages, or the system will not allocate more buffers until some input
  424. is accepted. In this way the process can be informed that there is no
  425. point in waiting for the condition it anticipates.
  426.  
  427. ABILITY TO SPECIFY SPECIAL WAKEUPS
  428.  
  429.       A process, when trying to run efficiently, should be able to
  430. specify arbitrarily complicated wakeup conditions. This allows a user
  431. managed way of minimizing the number of premature wakeups. This
  432. generality is perhaps most easily provided for by allowing the main
  433. process to designate a small low overhead interrupt driven routine that
  434. will check for the desired conditions and issue a wakeup to the main
  435. process whenever they are met.
  436.  
  437. ABILITY TO MEASURE CHANNEL CAPACITY
  438.  
  439.       There has been much discussion about the measure of a data stream
  440. and in the heat of committee, much confusion has been generated. It is
  441. our feeling that, within the present domain of discussion, there is no
  442. single measure of the capacity of a message channel. Two completely
  443. orthogonal concepts must be measured -- 1) the number of messages
  444. buffered and 2) the number of bits of encoded data represented. The
  445. system overhead associated with each is very much implementation
  446. dependent and hence no general equation can express the measure of one
  447.  
  448.  
  449.  
  450.                                                                 [Page 8]
  451.  
  452. RFC #150                 Use of IPC Facilities                5 May 1971
  453.  
  454.  
  455. in terms of the other. By making an arbitrary assumption (eg. a message
  456. boundary equals 100 bits of buffer), a system runs the risk of excluding
  457. new nodes that are unable to meet the old criterion.
  458.  
  459. ABILITY TO FIND OUT MAXIMUM CHANNEL CAPACITY
  460.  
  461.       There should be provided a system call that enables a user process
  462. to learn of the maximum current capacity of any given channel. This
  463. should be reported as a pair of numbers, namely the maximum bit count
  464. and the maximum message count.
  465.  
  466. ABILITY TO CONSTRAIN CHANNEL CAPACITY
  467.  
  468.       A process using a channel should be able to set new bounds on the
  469. capacity of a given channel. If possible the system should try to meet
  470. this bound. It should be noted that the actual bounds imposed must meet
  471. the constraints of at least four different sources -- local and remote
  472. user process, local and remote system -- by setting a arbitrarily high
  473. bound, no guarantee is made that it can be met. Similarly, a low bound
  474. can not always be met until buffered messages are consumed.
  475.  
  476.       Thus a receiving process, by setting the current message bound to
  477. zero, effectively disables the transmission of new messages. Thus,
  478. without the cooperation of the transmitting process, message generation
  479. can be temporarily disabled, while outstanding message buffers are
  480. flushed. Later the message allocation can be raised to its original
  481. limit and transmission can be resumed.
  482.  
  483. ABILITY TO CLOSE A CHANNEL AT ANY TIME
  484.  
  485.       A process should be able to close down a channel at any time. If
  486. the process has died, the system should be able to close all open
  487. channels for it. For channels over which the process was receiving data,
  488. pending input should be thrown away and indications returned to the
  489. transmitting system marking the channel as dead and identifying the last
  490. data item accepted. This identification will be in terms of the number
  491. of logical messages discarded and the number of bits left in the oldest
  492. message.
  493.  
  494.       If a process closes a channel over which it had been sending,
  495. buffered output should be sent normally, and with it should be sent an
  496. indication that this is all of the input that will ever appear.
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.                                                                 [Page 9]
  506.  
  507. RFC #150                 Use of IPC Facilities                5 May 1971
  508.  
  509. ABILITY TO GIVE AWAY CHANNEL PRIVILEGES
  510.  
  511.       The right to perform any of the operations discussed here is
  512. normally reserved by the process that established the channel. At times
  513. that process may wish to transfer some of its delegated power to another
  514. process, especially in an environment where one process may spawn
  515. another and resources must be passed to the newly created process.
  516.  
  517.       Schemes for such reassignment can become arbitrarily complicated.
  518. One could, for example, assign each of the various aspects of usage
  519. individually and then separately assign the various rights of
  520. reassignment. Fortunately it is not always necessary that it become so
  521. elaborate, it is expected that in most cases the following simple
  522. strategy can suffice. The ability to close a channel is retained
  523. exclusively by the process that established the channel. If the channel
  524. is still open when the process dies, it is automatically closed by the
  525. system. All other uses of the channel remain outside system control. The
  526. channel is known by name and all processes to which the name has been
  527. given may make use of the channel. It is left to user level coordination
  528. to insure that only one process is actually making use of it at any one
  529. time.
  530.  
  531. ABILITY TO INITIATE CHANNEL CREATION
  532.  
  533.       For most cases channel establishment can be handled quite simply.
  534. A process announces to its local system that it listening on a 
  535. specified channel. It is connected to the first remote process that
  536. 'dials' the right number. Identification of the caller takes place
  537. only after the channel has been established. In the event of a wrong
  538. number, the channel can be closed and the listening resumed. Callers
  539. trying to reach preestablished channels will get a 'busy signal'.
  540.  
  541.       To 'dial' a remote process a process must specify a channel on
  542. which it is listening and a remote number. The system will then
  543. attempt to establish the connection. The channel will become 'busy'
  544. during this time.
  545.  
  546.       For processes that prefer to avoid the complications of
  547. identifying remote callers, an additional feature can be added. By
  548. specifying both the local and remote channel identifiers a process can
  549. transfer to the system the responsibility for screening callers for
  550. the proper identification. The connection will only be accepted from
  551. the caller specified.
  552.  
  553.  
  554.                                                                 [Page 10]
  555.  
  556. RFC #150                 Use of IPC Facilities                5 May 1971
  557.  
  558.  
  559. ABILITY TO REPORT TRANSMISSION ERRORS
  560.  
  561.       If after prescanning an input message a process should decide
  562. that it contains some sort of transmission error, it should be able to
  563. reject the message. The system should then invoke any internal error
  564. recovery mechanism that it may have implemented.
  565.  
  566. POSTSCRIPT
  567.  
  568.       The author welcomes any comments, questions, or corrections to
  569. this document. Even the most informal note or telephone call will be
  570. appreciated. Especially of interest are opinions about the usefulness
  571. of the discussion and wether or not there should be more papers
  572. directed at other of the basic questions of computer networking. If
  573. the consensus tends to the affirmative, then others are encouraged to
  574. contribute working papers on the problems of flow control, error
  575. handling, process ownership, accounting, resource control, and the
  576. like.
  577.  
  578.  
  579. RBK/TX2
  580.  
  581.  
  582.          [ This RFC was put into machine readable form for entry ]
  583.          [ into the online RFC archives by Michael Baudisch 9/97 ] 
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.                                                                 [Page 11]
  607.  
  608.  
  609.