Assessment of ARPANET protocols
RFC 635

Document Type RFC - Unknown (April 1974; No errata)
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 635 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        Vinton G. Cerf
Request for Comments: 635                               Stanford University
NIC: 30489

                  An Assessment of ARPANET Protocols


This paper presents some theoretical and practical
motivations for the redesign of the ARPANET communication
protocols. Issues concerning multipacket messages,
Host retransmission, duplicate detection, sequencing,
and acknowledgment are discussed. Simplifications
to the IMP/IMP protocol are proposed on the assumption
that new Host level protocols are adopted. Familiarity
with the current protocol designs is probably necessary
since many of the arguments refer to details in the
present protocol design.

                               [Page 0]

RFC  635           An Assessment of ARPANET Protocols              May 1974


     The history of the Advanced Research Project Agency resource
sharing computer network (ARPANET) [6] is in many ways a history of
the study, development, and implementation of protocols. During the
early development of the network many important concepts were dis-
covered and introduced into the protocol design effort. Protocol
layering (functional separation of different levels of network trans-
mission), the notion of bilateral rendezvous to set up Host-to-Host
connections [l,2], and the definition of a Network Virtual Terminal
to aid in the specification of a Terminal-to-Host protocol [3,14] are
all examples of important early ideas. The tasks facing the ARPANET
design teams were often unclear, and frequently required agreements
which had never been contemplated before (e.g., common protocols to
permit different operating systems and hardware to communicate). The
success of the effort, seen in retrospect, is astonishing, and much
credit is due to those who were willing to commit themselves to the job
of putting the ARPANET together.

     Over the intervening five years since the ARPANET was first begun,
we have learned a great deal about the design and behavior of the proto-
cols in use. The Imp-to-Imp protocol [4] has undergone continuous re-
vision, and the HOST/IMP interface specification [5] has been modified
slightly. In retrospect and in the light of experience, it seems
reasonable to reconsider some of the aspects of the designs and implemen-
tations currently in use. Furthermore, the rapid development of national

                               [Page 1]

RFC  635           An Assessment of ARPANET Protocols              May 1974

computer network projects around the world emphasizes the need for
international cooperation in the design of communication protocols so
that international connections can be accomplished.

     This paper deals with the motivations for the redesign of the
HOST-to-HOST, IMP-to-IMP, and HOST/IMP communication protocols in the
ARPANET. Analyses of theoretical throughput and delay available from
existing protocols, and a discussion of some weaknesses in them, are

     The basic conclusions reached in this report are:

     a) Multipacket message facilities can be eliminated without loss
        of potential throughput, and with a concurrent simplification of
        IMP software. [8]  

     b) Ordering by the destination IMP of messages delivered to a destina-
        tion HOST can lead to a lockup condition similar to the reassembly
        lockup experienced in an earlier version of the IMP protocol in
        connection with multipacket message reassembly [7]. Hosts must
        order arriving messages anyway, so the IMP need not do it.

     c) HOST/IMP protocol could be changed to allow arbitrarily long
        messages to be sent from HOST to IMP, as long as the destination
        IMP need not reassemble or re-order the arriving packets before
        delivery to the HOST.

     d) Host level retransmission, positive end-to-end acknowledgments,
        error detection, duplicate detection, and message ordering, can
        eliminate the need for many of these features in the IMP/IMP
        protocol, and the Request for next Message (RFNM) facility in the
        present HOST/IMP protocol.

                               [Page 2]

RFC  635           An Assessment of ARPANET Protocols              May 1974

     e) The flow control mechanism in the current HOST-HOST protocol can
        lose synchronization owing to message loss or duplication.

     f) Host level connections should be full duplex.

     g) The need for a separate HOST/HOST control connection can be
        eliminated by carrying control information in the header of each
        Host transmission.
Throughput Considerations.

     In spite of the fact that the IMP subnet can deliver up to 80 kb/sec
between pairs of Hosts^, virtually no application using Host software
has achieved this figure. An experiment between Tinker and McClellan
Air Force Bases in 1971 achieved burst rates as high as 40 kb/sec, but
Show full document text