RFC 54 (rfc54) - Page 2 of 9

Official Protocol Proffering

Alternative Format: Original Text Document


RFC 54              An Official Protocol Proffering        18 June 1970


   procedure has demonstrable limitations, but has the advantages that
   it is more cleanly implementable and will support initial network
   use.  This is the only substantive change from the protocol already
   agreed upon.

   The new flow control mechanism requires the receiving host to
   allocate buffer space for each connection and to notify the sending
   host of how much space in bits is available.  The sending host keeps
   track of how much room is available and never sends more text than it
   believes the receiving host can accept.

   To implement this mechanism, the sending host keeps a counter
   associated with each connection.  The counter is initialized to zero,
   increased by control commands sent from the receiving host, and
   decremented by the text length of any message sent over the
   connection.  The sending host is prohibited from sending text longer
   than the value of the counter, so the counter never goes below zero.

   Ideally, the receiving host will allocate some buffer space as soon
   as the connection is established.  The amount allocated must never
   exceed what the receiver can guarantee to accept.  As text arrives,
   it occupies the allocated buffer space.  When the receiving process
   absorbs the waiting text from the buffer, the NCP fires back a new
   allocation of space for that connection.  The NCP may allocate space
   even if the receiving process has not absorbed waiting text if it
   believes that extra buffer space is appropriate.  Similarly, the NCP
   may decide not to reallocate buffer space after the receiving process
   makes it available.

   The control command which allocates space is

                   ALL       

   This command is sent only from the receiving host to the sending
   host.

   This formulation of flow control obviates the RSM and SPD commands in
   NWG/RFC #36, and the Host-to-Imp message type 10 and Imp-to-Host
   message types 10 and 11 in the current revision of BBN Report 1822.

   The obvious limitation in this scheme is that the receiving host is
   not permitted to depend upon average buffer usage -- worse case is
   always assumed.  If only a few connections are open, it is unlikely
   that there would be much savings.  However, for more than a few
   connections, average buffer usage will be much less than allocated
   buffer space.  We have looked at extensions of this protocol which
   would include adaptive allocation, and we believe this to be
   feasible.  For the present this limited scheme seems best, and we



Crocker, Postel, Newkirk & Kraley

Web Standards & Support: