Thoughts and Reflections on NWG/RFC 54
RFC 57

Document Type RFC - Unknown (June 1970; Errata)
Updates RFC 54
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 57 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                              Mike Kraley (Harvard)
Request for Comments #57                          John Newkirk (Harvard)

                                                   June 19, 1970

                Thoughts and Reflections on NWG/RFC #54

       In the course of writing NWG/RFC #54 several new ideas became
apparent.  Since these ideas had not previously been discussed by the
NWG, or were sufficiently imprecise, it was decided not to include them
in the official protocol proffering.  We thought, however, that they
might be proper subjects for discussion and later inclusion in the
second level protocol.

I.  Errors and Overflow

       In line with the discussion in NWG/RFC #48, we felt that two
types of errors should be distinguished.  One is a real error, such as
an RFC composed of two send sockets.  This type of error can only be
generated by a broken NCP.  In the absence of hardware and software
bugs, these events should never occur; the correct response upon
detection of such an event was outlined in the description of the ERR
command in NWG/RFC #54.
       The other "error" is an overflow condition arising because
finite system resources are exhausted.  An overflow condition could
occur if an RFC was received, but there was no room to create the
requisite tables and queues.  This is not a real error, in the sense
that no one has done anything incorrect (expect perhaps the system
planners in not providing sufficient table space, etc.)  Further, a

                                                                [Page 1]
RFC 57          Thoughts and Reflections on NWG/RFC #54        June 1970

recovery procedure can be well defined, and simply entails repeating the
request at a future time.  Thus, we believe an overflow condition should
be distinguished from a real error.
       In NWG/RFC #54 an overflow condition was reported by returning
a CLS, as if the connection had been refused.  This sequence performs
the necessary functions, and leaves the connection in the correct state,
but the initiating user is misinformed.  He is deluded into thinking
that he was refused by the foreign process, when, in fact, this was not
the case.  In certain algorithms this difference is crucial.
       In further defining error conditions, we felt that it would
be helpful to specify why the error was detected, in addition to
specifying what caused the error.  While writing the pseudo-Algol
program mentioned in NWG/RFC #55 we differentiated 9 types of errors
(listed below).  We would, therefore, like to propose the extension of
the ERR message to include an 8-bit field following the op code to
designate the type of error.  This would be followed by the length and
text fields, as before.  We propose these error types;

       1.  HOMOSEX  (invalid send/rcv pair in an RFC)
       2.  ILLEGAL OP CODE
       3.  ILLEGAL LEADER (bad message type, etc.)
       6.  ILLEGAL COMMAND LENGTH (last command in message was too short)
       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, we
would also like to propose an additional control command to singify

        |     OVF     |     my socket     |     your socket     |

The format of the message is similar to that of the CLS message, which
it replaces in this context.  The socket numbers are 32 bits long and
correspond to the socket numbers in the RFC which is being rejected.
The semantics of an incoming OVF should be indentical to an incoming
CLS; in addition, the user should be informed that he has not been
refused but rather has overtaxed the foreign host's resources.
       An alternative to creating a separate control command can be
realized by considering the similarity between a CLS and an OVF.
Conceivably, an eight-bit field could be added to the CLS command to
define its derivation.  We believe, however, that this alternative is
conceptually inferior and practically more difficult to implement.
       Overflow does not require serious consideration if it is a
significantly rare occurrence.  We do not believe this will be the case,
and we further believe that its absence will be an unnecessary
restriction upon the user.

                                                                [Page 3]
RFC 57          Thoughts and Reflections on NWG/RFC #54        June 1970
Show full document text