Host-Host Protocol for an ARPANET-Type Network
RFC 714

Document Type RFC - Unknown (April 1976; 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 714 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        A. McKenzie
Request for Comments: 714                                        BBN-NCC
NIC: 35144                                                    April 1976

            A Host/Host Protocol for an ARPANET-Type Network

   Recently we have been involved in the planning of a network, which,
   if implemented, would use ARPANET IMPs without modification, but
   would allow re-specification of Host/Host (and higher level)
   Protocol.  The remainder of this document is a slightly edited
   version of our recommendation for Host/Host protocol; we thought that
   it might be of interest to the ARPANET Community.


   The Host/Host Protocol for the ARPANET was the first such protocol
   designed for use over a packet-switched network.  The current version
   has been in existence since early 1972 and has provided for the
   transportation of billions of bits over tens or hundreds of thousands
   of connections.  Clearly, the protocol is adequate for the job; this
   does not mean that it is ideal, however.  In particular, the ARPANET
   Host/Host protocol has been criticized on the following grounds
   (among others):

   (1) It is specified as a simplex protocol.  Each established
       connection is a simplex entity, thus two connections (one in each
       direction) must be established in order to carry out an exchange
       of messages.  This provides great generality but at a perhaps
       unacceptable cost in complexity.

   (2) It is not particularly robust, in that it cannot continue to
       operate correctly in the face of several types of message loss.
       While it is true that the ARPANET itself rarely loses messages,
       messages are occasionally lost, both by the network and by the

   (3) Partly because of the simplex nature of connections, the flow
       control mechanisms defined in the ARPANET protocol do not make
       efficient use of the transactional nature of much of data
       processing.  Rather than carrying flow control information (in
       the form of permits, or requests for more information) in the
       reverse traffic, a separate channel is set up to convey this
       information.  Thus, for transactional systems, up to twice as
       many messages are exchanged (half for flow control information
       and half for data) as would be needed for data alone.

McKenzie                                                        [Page 1]
RFC 714     A Host/Host Protocol for an ARPANET-type Network  April 1976

   (4) Prohibition against the multiple use of a connection termination
       point makes the establishment of communication with service
       facilities extremely cumbersome.

   The International Federation for Information Processing (IFIP)
   Working Group 6.1 (Packet-switched Network Internetworking) has
   recently approved a proposal for an internetwork end-to-end protocol.
   The IFIP Protocol is based on experience from the ARPANET, the
   (French) Cyclade Network, and the (British) NPL Network, as well as
   the plans of other networks.  Thus, one would expect that it would
   have all of the strengths and few (or none) of the weaknesses of the
   protocols which are in use on, or planned for, these networks.

   In fact, the IFIP Protocol avoids the deficiencies of the ARPANET
   protocol mentioned above.  Connections are treated as full-duplex
   entities, and this decision permits flow control information to be
   carried on the reverse channel in transaction-oriented systems where
   there is reverse channel traffic occurring naturally.  In addition,
   the IFIP Protocol is to some extent self synchronizing; in
   particular, there is no type of message loss from which the Protocol
   does not permit recovery in a graceful way.

   The IFIP Protocol makes a minimal number of assumptions about the
   network over which it will operate.  It is designed to permit
   fragmentation, as a message crosses from one network to another,
   without network reassembly.  It anticipates duplication, or non-
   delivery, of messages or message fragments and provides ways to
   recover from these conditions.  Finally, it permits delivery of
   messages at their destination Host in a completely different order
   from the order in which they were input by the source Host.
   Unfortunately, it achieves these advantages at a relatively high
   overhead cost in terms of transferred bits.  The complete source and
   destination process addresses are carried in every message, 24-bits
   of fragment identification are carried with each fragment and 16-bits
   of acknowledgement information are else carried in every message.

   When considering channel capacities of hundreds of kilobits (or
   more), message overhead of a few hundred bits is a modest price to
   pay in order to achieve great flexibility and generality.  However,
   for a stand-alone network of the type under consideration, and
Show full document text