Movatterモバイル変換

Network Working Group                              Mike Kraley (Harvard)Request for Comments #57                          John Newkirk (Harvard)                                                   June 19, 1970Thoughts and Reflections on NWG/RFC #54       In the course of writing NWG/RFC #54 several new ideas becameapparent.  Since these ideas had not previously been discussed by theNWG, or were sufficiently imprecise, it was decided not to include themin the official protocol proffering.  We thought, however, that theymight be proper subjects for discussion and later inclusion in thesecond level protocol.I.  Errors and Overflow       In line with the discussion in NWG/RFC #48, we felt that twotypes of errors should be distinguished.  One is a real error, such asan RFC composed of two send sockets.  This type of error can only begenerated by a broken NCP.  In the absence of hardware and softwarebugs, these events should never occur; the correct response upondetection of such an event was outlined in the description of the ERRcommand in NWG/RFC #54.       The other "error" is an overflow condition arising becausefinite system resources are exhausted.  An overflow condition couldoccur if an RFC was received, but there was no room to create therequisite tables and queues.  This is not a real error, in the sensethat no one has done anything incorrect (expect perhaps the systemplanners in not providing sufficient table space, etc.)  Further, a                                                                [Page 1]

RFC 57          Thoughts and Reflections on NWG/RFC #54        June 1970recovery procedure can be well defined, and simply entails repeating therequest at a future time.  Thus, we believe an overflow condition shouldbe distinguished from a real error.       In NWG/RFC #54 an overflow condition was reported by returninga CLS, as if the connection had been refused.  This sequence performsthe necessary functions, and leaves the connection in the correct state,but the initiating user is misinformed.  He is deluded into thinkingthat he was refused by the foreign process, when, in fact, this was notthe case.  In certain algorithms this difference is crucial.       In further defining error conditions, we felt that it wouldbe helpful to specify why the error was detected, in addition tospecifying what caused the error.  While writing the pseudo-Algolprogram mentioned in NWG/RFC #55 we differentiated 9 types of errors(listed below).  We would, therefore, like to propose the extension ofthe ERR message to include an 8-bit field following the op code todesignate the type of error.  This would be followed by the length andtext fields, as before.  We propose these error types;       0.  UNSPECIFIED ERROR       1.  HOMOSEX  (invalid send/rcv pair in an RFC)       2.  ILLEGAL OP CODE       3.  ILLEGAL LEADER (bad message type, etc.)       4.  ILLEGAL COMMAND SEQUENCE       5.  ILLEGAL SOCKET SPECIFICATION - COMMAND       6.  ILLEGAL COMMAND LENGTH (last command in message was too short)       7.  CONNECTION NOT OPEN - DATA       8.  DATA OVERFLOW (message longer than advertised available           buffer space)       9.  ILLEGAL SOCKET SPECIFICATION - DATA (socket does not exist)                                                                [Page 2]

RFC 57          Thoughts and Reflections on NWG/RFC #54        June 1970       In light of the other considerations mentioned earlier, wewould also like to propose an additional control command to singifyoverflow:        +-------------+-------------------+---------------------+        |     OVF     |     my socket     |     your socket     |        +-------------+-------------------+---------------------+The format of the message is similar to that of the CLS message, whichit replaces in this context.  The socket numbers are 32 bits long andcorrespond to the socket numbers in the RFC which is being rejected.The semantics of an incoming OVF should be indentical to an incomingCLS; in addition, the user should be informed that he has not beenrefused but rather has overtaxed the foreign host's resources.       An alternative to creating a separate control command can berealized by considering the similarity between a CLS and an OVF.Conceivably, an eight-bit field could be added to the CLS command todefine its derivation.  We believe, however, that this alternative isconceptually inferior and practically more difficult to implement.       Overflow does not require serious consideration if it is asignificantly rare occurrence.  We do not believe this will be the case,and we further believe that its absence will be an unnecessaryrestriction upon the user.                                                                [Page 3]

RFC 57          Thoughts and Reflections on NWG/RFC #54        June 1970II.  Host Up and Host Down       Significant problems can arise when a host goes down and thenattempts to restart.  Two cases can easily be distinguished.  The firstis a "soft" crash, where the system has prior notice that the machine isgoing down; sufficient time is available to execute pre-recoveryprocedures.  The other case can be termed a "hard" crash, often theresult of a system failure.  Insignificant warning is usually given; butmore important, the state of the machine after recovery is rarelypredictable.       When a host returns from a hard crash, the network will bein an undefined state.  Very probably the NCP's data structures aredestroyed or are meaningless.  The network has declared the host dead --but only to processes which attempted data transmission and wererefused.  The only alternative for the crashed host is re-initializationof its tables.  What are the alternatives for the foreign hosts?       We would like to propose the addition of two control commands:RESET (RST) and RESET REPLY (RSR).  Each would consist solely of an opcode with no parameters.  Upon receipt of an RST, a host wouldimmediately terminate all connections with the sending host, but wouldnot issue any CLS's.  The receiver of the RST would also note that theoriginator of the RST was alive, and would then echo an RSR to thesender.  When a host receives an RSR, he sould then note that theechoing host is alive.  (The function of RST can be partially simulatedif a host will immediately close all relevant table entries upondiscovering that another host is down.)       Thus, after a hard crash, all connections and request forconnections are terminated.  The RST also informs all foreign hosts thatwe are again alive, and an RSR is received from every functioning NCP.A host live table (see NWG/RFC #55) can easily be                                                                [Page 4]

RFC 57          Thoughts and Reflections on NWG/RFC #54        June 1970assembled, and establishment of connections can resume.       Related problems also crop up when we consider attemptingto synchronize the network, which may still be carrying messagesgenerated prior to the crash, with an NCP which has an initializedenvironment.  We lack the facilities for unblocking links, discardingmessages, etc. -- facilities which this proposal will necessitate.Further interaction with BBN should resolve these difficulties.       The problems associated with "soft" crashes are not nearlyas pressing, and they demand more sophisticated (i.e., complex)solutions.  Our preliminary experimentation with the networkdemonstrates that a good initialization and recovery protocol are farmore necessary.       Many of the ideas presented herin wre germinated and/orjelled through conversations with Steve Crocker and Jon Postel.  Wewould also like to acknowledge the assistance of Jim Balter and CharlesKline of UCLA, who devoted a great deal of effort toward helping developthe pseudo-Algol program which was the predecessor of much of our recentdocumentation.       [ This RFC was put into machine readable form for entry ]       [ into the online RFC archives by  Katsunori Tanaka 2/98 ]                                                                [Page 5]