Proposed change to Host-Host Protocol: Resynchronization of connection status
RFC 467

Document Type RFC - Unknown (February 1973; No errata)
Updated by RFC 492
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 467 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                       J. Burchfiel
Request for Comments: 467                                   R. Tomlinson
NIC: 14741                                       Bolt Beranek and Newman
                                                        20 February 1973

                 Proposed Change To Host-Host Protocol
                Resynchronization Of Connection Status

I. Introduction

   The current Host-Host protocol (NIC #8246) contains no provisions for
   resynchronizing the status information kept at the two ends of each
   connection.  In particular, if either host suffers a service
   interruption, or if a control message is lost or corrupted in an
   interface or in the subnet, the status information at the two ends of
   the connection will be inconsistent.

   Since the current protocol provides no way to correct this condition,
   the NCP's at the two ends stay "confused" forever.  A frequent and
   frustrating symptom of this effect is the "lost allocate" phenomenon,
   where the receiving NCP believes that it has bit and message
   allocations outstanding, while the sending NCP believes that it does
   not have any allocation.  As a result, information flow over that
   connection can never be restarted.

   Use of the Host-Host RST (reset) command is inappropriate here, as it
   destroys all connections between the two hosts.  What is needed is a
   way to reset only the affected connection without disturbing any
   others.

   A second troublesome symptom of inconsistency in status information
   is the "half-closed" connection: after a service interruption or
   network partitioning, one NCP may believe that a connection is still
   open, while the other believes that the connection is closed. (Does
   not exist.)  When such an inconsistency is discovered, the "open" end
   of the connection should be closed.

Burchfiel                                                       [Page 1]
RFC 467                                                    February 1973

II. The RCR and RCS Commands

   To achieve resynchronization of allocation, we propose the addition
   of the following two commands to the host-host protocol.

         8           8
   +-----------+-----------+
   |    RCS    |   link    |   Reset connection by sender
   +-----------+-----------+

         8           8
   +-----------+-----------+
   |    RCR    |   link    |   Reset connection by receiver
   +-----------+-----------+

   The RCS command is sent from the host sending on "link" to the host
   receiving on "link".  This command may be sent whenever the sending
   host desires to re-synch the status information associated with the
   connection.  Some circumstances in which the sending Host may choose
   to do this are:

      1.) After a timeout when there is traffic to move but no
      allocation. (Assumes that an allocation has been lost)

      2.) When an inconsistent event occurs associated with that
      connection (e.g. an outstanding allocation in excess of 2^32 bits
      or 2^16 messages.

   The mechanics of re-synchronizing the allocations is simply:

      1.) Empty all messages and allocates from the "pipeline".

      2.) Zero the variables at both ends indicating bit and message
      allocation.

      3.) Restart allocate/message exchanges in the normal way.

   This resynchronization scheme is race-free because the RCS and RCR
   commands are used as a positive acknowledgement pair.

III. Resynchronization by Sender

   To initiate resynchronization, the sending NCP should:

      1.) Put the connection in a "waiting-for-RCR-reply" state.  No
      more regular messages may be transmitted over this connection
      until the RCR reply is received.

Burchfiel                                                       [Page 2]
RFC 467                                                    February 1973

      2.) Wait until the message pipeline is empty, i.e. until a RFNM
      has been received for each regular message sent over this
      connection.  This synchronizes the control and data activity, and
      also assures that the data stream will not be corrupted during the
      control re-synchronization exchange.

      3.) Send the RCS command.

      4.) Continue to process allocates normally, updating the variables
      which indicate outstanding bit and message allocation.

   When the receiving NCP receives the RCS, it should:

      1.) Zero the variables indicating outstanding bit and message
      allocation.

      2.) Reset the connection to the state which indicates readiness to
      accept a message.

      3.) Confirm the re-synchronization by sending the RCR reply.

      4.) Reconsider bit and message allocation, and send an ALL command
      for any allocation it cares to do.

   When the sending host receives the RCR reply, it should:

      1.) Zero the variables indicating outstanding bit and message
      allocate.

      2.) Put the connection into the "ready-to-send-message" state in
Show full document text