RFC 492 (rfc492) - Page 1 of 7

Response to RFC 467

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