Official Protocol Proffering
RFC 54

Document Type RFC - Unknown (June 1970; No errata)
Updated by RFC 57
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 54 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                               Steve Crocker (UCLA)
Request for Comments # 54                              Jon Postel (UCLA)
June 18, 1970                                     John Newkirk (Harvard)
                                                   Mike Kraley (Harvard)

                    An Official Protocol Proffering


   As advertised in NEW/RFC #53, we are submitting the protocol herein
   for criticism, comments, etc.  We intend for this protocol to become
   the initial official protocol, and will, therefore, be happiest if no
   serious objections are raised.  Nevertheless, we will entertain all
   manner of criticism until July 13, 1970, and such criticism should be
   published as a NWG/RFC or directed to the first author.

   After July 13, a decision will be made whether to adopt this protocol
   (or slight variation) or whether to redesign it and resubmit it for

Only the Protocol

   In preceding discussions of protocol, no clear distinction has been
   made between the network-wide specifications and local strategies.
   We state here that the only network-wide issues are message formats
   and restrictions on message content.  Implementation of a Network
   Control Program (NCP) and choice of system calls are strictly local

   This document is constrained to cover only network-wide issues and
   thus will not treat system calls or NCP tables; nevertheless, a
   protocol is useless without an NCP and a set of system calls, so we
   have expended a great deal of effort in deriving a protypical NCP.
   This effort is reported in NWG/RFC #55, and the reader should
   correlate the protocol presented here with the suggestions for using
   it presented there.  It is important to remember, however, that the
   content of NWG/RFC #55 is only suggestive and that competitive
   proposals should be examined before choosing an implementation.

Flow Control

   In the course of designing this current protocol, we have come to
   understand that flow control is more complex than we imagined.  We
   now believe that flow control techniques will be one of the active
   areas of concern as the network traffic increases.  We have,
   therefore, benefitted from some ideas stimulated by Richard Kaline
   and Anatol Holt and have modified the flow control procedure.
   (Defects in our scheme are, of course, only our fault).  This new

Crocker, Postel, Newkirk & Kraley                              [Page 1]
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     <link>  <space>

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

   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
Show full document text