Received at
NIC
22-APR-74
Network Worlring Group
Request for Comments
#635
NIC
3Y30489
RECE~VED
MAY
0
1
1974
Po=
An Assessment of ARPANET Protocols
Vinton
G.
Cerf
Stanford University
ABSTMCT
This
pa$cr
presents some theoretical and practical
/
motivations for the redesign of the ARPANET communication
protocols.
Issues concerning
rnult
ipacket tnessages,
Host
rotra.nsnission, duplicate 'detection, sequencing,
L
.and acknowl.edgment are discussed. Simplifications
to the
IhIP/IMP protocol are propose'd on the assumption
that new Host level protocols are adopted. Familiarity
~5th the current protocol designs
is
probably necessary
since many of the arguments refer to
dctnils in the
present protocol design.
An
Assessment of ARPAKET Protocols
Vinton
G
.
Cerf
Stanford University
Introduction
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
developmert of the network mahy important concepts
Gere
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
[1,2], ~nd 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
fecing the ARPANET
design teams were often unclear,
~nd frebuently required ~greements
which h~d 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, end 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
ARIJAhTET was first begun,
we
have learned a great deal about the design ~nd behavior of the proto-
cols in use. The
Imp-to-I,mp protocol [4] has undergone continuous re-
visicn, and the MOST/IhfP
interface
specification [5] has been modified
slightly. In retrospect,
and
in the light of experience,
it
see~ns
reasonnble to reconsider some of the aspects of
the
designs and implemen-
tations currently in use. Furthermore, the
rapid development
of
national
computer network projects around the world emphasizes the need for
international
coopcration 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.
~nal~se; of theoretical throughput and delay available from
existing protocols, and a discussion of some weaknesses in them, are
included.
The basic conclusions reached in this
regort are:
-.
a)
Multipacket message facilities can be eliminated without loss
of potential throughput, and
kith a concurrent simplification of
IMP software.
[8]
-
b) Ordering by the.destination IhIP of messages delivered to a destina-
tion HOST can lead to a lockup condition sim.ilar to the reassembly
lockup
experienced..in an earlier. version of the IMP protocol in
.
connectioll.with multipacket message reassembly
171.
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 befsre
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 Requcst for next Message
(RFNM)
facility in the
present
IIOST/IhfP protocol.
e)
The flow control mechanism in the current HOST-HOST protocol can
lose synchronization pwing 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 Cons
idera
t
ions
In spite of the fact that the IMP
subnet can deliver yp 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
this was achieved by the use of a non-standard
Host/Host protocol which
-.
transmitted data over multiple logical connections, and which used Host
level re-assembly and acknowledgment to achieve reliable, ordered trans-
* *
mission
.
The following analysis shows-that the current Host/Host
protocol cannot offer more than
40
kb/sec on a single connection owing
to message format overhead, and that this figure drops hyperbolically
if the communicating Hosts are separated by several
IMPS.
The single major reason for the distance (hop) dependent behavior
11
of Host/Host throughput
is
the
message-at-a-time"
Host/~ost
protocol. This means that, on
a
given connection between processes in
*
Unpublished measurement experiments at
UCU
run by
R.
Kahn and
V.
Cerf confirmed this.
**
Unpublished measurement data obtained by
V.
Cerf at the ARPA Network
Measurement
Ccnter
,
UCLA
.
the Hosts, only a single message ranging from
0-8063
bits of data can
be
outstanding at any moment. When the Host/Host protocol was originally
designed, the
IMPS provided up to
256
simplex logical links between pairs
of Hosts. If a message was sent over
a
link (there was a one to one
relationship between a link and a connection), the link was blocked until
a
RFNAI
was received from the destination IMP indicating that the message
-
.had been delivered to the Host. Of course, the mechanism was protected
by
a time-out in case the RFNM'failed to appear.
The IMP protocol has since
been.changed considerably and now permits
.
,
*
up to
n
messages to be outstanding between pairs of IMPs, regardless
-
of the links used,. and regardless of which Hosts are communicating.
This last point means that there can be some interference among Hosts
.
connected to the same IMP if the Hosts are communicating with the same
destination IMP.
The
Host/Hos-t protocol has not been changed to take advantage of the
possibility of multiple messages and
is
6nable to achieve maximunl possible
throughput.
In figure
1,
the time behavior of a multipacket message
is
shown'as
it
passes through several IMPs fron source to destination.
'-7'e
propagation delay from
IMP^
to
IMP
I
packet transmission delay
Packet
handling
by
h
IMPs
for
an
m-packet
message
Figure
1
-
.-.-
*currently Sour, this lirril; bcing imposed by IMP buffcr space.
评论0