Response to RFC 467
RFC 492

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

Network Working Group                                           E. Meyer
Request for Comments: 492                                    MIT-Multics
NIC: 15357                                                 18 April 1973
                          RESPONSE TO RFC 467

   Jerry Burchfiel and Ray Tomlinson of Bolt, Beranek, and Newman, Inc,
   have issued a Network Request for Comments (#467) which proposes a
   solution to two problems which have been annoying to Network users.
   This document will briefly describe the problems and proposed
   solutions, and offer comments and alternative suggestions.

BACKGROUND

   To establish a data connection between two hosts through the network,
   the Host-Host protocol requires that one host send a Request for
   Connection and that the second Host reply affirmatively.  If the
   desired socket("port") at the target host is already in use, the
   target host replies negatively.  Once a connection is established,
   data transmission may proceed, controlled by data allocation messages
   dispatched by the host at the read end of the connection.  The host
   on the write side is constrained by protocol to send only as much
   data as has been permitted by the read side.  If it exhausts the
   allocation it must wait until a new data allocation control message
   is received.  Then it can send more.

   One of the problems arises from the fact that messages apparently are
   lost somewhere in the transmission path with a low but regular
   frequency.  If an allocate control message concerning an open
   connection is lost, a situation can occur in which data transmission
   over the connection ceases permanently.  This can happen because the
   host at the send side believes it has exhausted its allocation, and
   sits holding back data to end because it is waiting for a new data
   allocation message to come from the read side.  However, the read
   side has actually sent out the allocation, but it was lost.  It
   thinks that the send side may proceed and sits waiting for data to
   come in over the connection.  This is known as the "lost allocate"
   phenomenon.  However, similar symptoms can occur if a data message is
   lost and the send side exhausts its allocation before a new
   allocation is given by the read side.  The send side waits for a new
   allocation, but the read side has not received one of the data
   messages and believes there is still some allocation left.  In either
   case, the result is a permanently blocked connection.  This appears
   to happen with enough regularity to be annoying to users who connect
   typewriters to foreign hosts through the Network.  When it happens,
   the only current solution is to disconnect and to establish a new
   connection.

Meyer                                                           [Page 1]
RFC 492                   RESPONSE TO RFC 467              18 April 1973

   The solution to this problem which RFC 467 proposes is to establish a
   pair of allocation-resetting control messages, one for use by the
   send side (RCS) and the other for the read side (RCR).  Whenever it
   wishes, either side may initiate the allocation-resetting sequence by
   setting its own allocation counter to zero and dispatching an RCS or
   RCR control message to the other side.  The host receiving it will
   set its own allocation counter for that connection to zero and send
   an RCR or RCS in reply.  Now the allocations for both sides are in
   synchronization (they are zero), and data transmission can begin
   again when a new allocation is sent by the receive side.  This
   procedure is intended to be initiated whenever either side thinks the
   connection has been quiescent for a suspiciously long time.  The
   actual specification of this control message pair in RFC 467 is more
   complex in that the pipeline between the two sides must be empty of
   data messages before the send side may dispatch an RCS control
   message.

   The second problem arises when the host at one side of an open
   connection crashes and purges its tables when it comes back up, while
   the host at the other end of the connection does not notice that
   anything has happened. (A similar situation occurs when the Network
   path temporarily fails between the two hosts, but only one host
   notices the failure and closes the connection.) If the host which
   crashed attempts to re-establish the connection, the host at the
   other end refuses to do so because the socket to which the connection
   request is targeted is seemingly already involved in an open
   connection.  Given the idiosyncrasies of the terminal support
   software of some systems, users at some consoles may be unable to
   reconnect to the distant system they were connected with when the
   local system supporting his terminal crashed.  This can continue
   indefinitely until the system which believes the original connections
   to be still open resets its internal state.  This is call the "half-