Host-Host Protocol for an ARPANET-Type Network
RFC - Unknown
(April 1976; No errata)
||RFC Editor Note
RFC 714 (Unknown)
||Send notices to
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
(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