Official Protocol Proffering (RFC0054)
Original Publication Date: 1970-Jun-18
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
S.D. Crocker: AUTHOR [+4]
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.
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.
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
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
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