💾 Archived View for gemini.bortzmeyer.org › rfc-mirror › rfc635.txt captured on 2024-06-16 at 19:03:36.
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Network Working Group Vinton G. Cerf
Request for Comments: 635 Stanford University
NIC: 30489
An Assessment of ARPANET Protocols
ABSTRACT
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
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 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
included.
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
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 acknowledgement 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
of Host/Host throughput is the "message-at-a-time" Host/Host
protocol. This means that, on a given connection between processes in
______________________________
^ Unpublished measurement experiments at UCLA run by R. Kahn and V.
Cerf confirmed this.
^^ Unpublished measurement data obtained by V. Cerf at the ARPA Network
Measurement Center, UCLA.
[Page 3]
RFC 635 An Assessment of ARPANET Protocols May 1974
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 1ogical 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 RFNM 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/Host protocol has not been changed to take advantage of the
possibility of multiple messages and is unable to achieve maximum possible
throughput. In figure 1, the time behavior of a multipacket message is
shown as it passes through several IMPs from source to destination.
------------------------------------
IMP(0) | pkt(0) | pkt(1) | ... | pkt(m-1) |
------------------------------------
| | ------------------------------------
IMP(1) | | | pkt(0) | pkt(1) | ... | pkt(m-1) |
| | ------------------------------------
| | | :
| | | :
| | | ------------------------------------
IMP(h-1)| | | | pkt(0) | pkt(1) | ... | pkt(m-1) |
|<------>| |<- ------------------------------------
\ \
\ `---> propagation delay from IMPO to IMPl
`--> packet transmission delay
Packet handling by h IMPs for an m-packet message
Figure 1
______________________________
^ currently four, this limit being imposed by IMP buffer space.
[Page 4]
RFC 635 An Assessment of ARPANET Protocols May 1974
Figure 1 is naive in several ways. First, it does not show any
interfering traffic, nor have any packets gotten out of order or been
routed on alternate paths. Second, all packets are assumed to be the
same maximum size. Furthermore, the figure does not show the transmission
delay to and from the Hosts. Thus, the results of the analysis will be
slightly optimistic.
The logical connection between Hosts will be busy only for m packet
times out of h+m-l packet times. The source IMP will be busy for m
packet transmission times sending the message to a neighboring IMP. The
last bit of the first packet will arrive at the destination IMP after h
packet transmission times (not counting propagation delay) and the re-
maining m-1 packets will complete arrival after m-l packet transmission
times. The source Host will be permitted to transmit another message
after it receives a RFNM from the destination IMP. The RFNM is actually
sent after the message has been reassembled, the first packet has been
delivered, and the destination IMP has sufficient free buffer space for
another maximum length multipacket message.^ Thus a new transmission
cannot occur until h+m-1 packet times, at least, so the fraction of busy
time is just m/(h+m-l).
The actual bandwidth between IMPs is reduced from 50 kb^^ to 40 kb
by overhead bits needed for Host/Host, IMP/IMP control. IMPs send periodic
routing messages to all their neighbors (every .640 seconds)^^^ and these
consume further bandwidth. We can estimate the nominal fraction of 50 kb/sec
bandwidth available from source to destination IMP and multiply this by the
fractional busy time per connection to obtain an optimistic bound on maximum
throughput per connection.
______________________________
^ If after 1 second no space is available, the RFNM is sent anyway.
^^ Some IMPs have 230 kb/sec lines, or 9.6 kb/sec, but most have 50 kb/sec.
^^^This interval is a function of line speed and load and may be as low as 128 ms.
[Page 5]
RFC 635 An Assessment of ARPANET Protocols May 1974
Analysis of Expected Throughput Bounds.
Let T be the number of bits of text to be transmitted by a Host
whose natural word length is W bits. The Host/Host message format
includes a 32 bit leader followed by a 40 bit prefix, followed by the
text to be sent. We will assume that a sending Host will transmit an
integral number of its words, including the 72 bits preceding the text
of the message. Furthermore, the Host/IMP interface appends a one bit
to each message, followed by as many zeroes as are needed to make the
ensemble an integral number of 16 bit IMP words (the IMP is a Honeywell
316 or 516 computer).
The total number of bits in a Host message whose text contains T
bits is given by equation 1.
M(T,W) = B1 (T) + B2 (T,W) + B3(T,W) (1)
where B1(T) = T + 72
B2(T,W) = - B1(T) mod W
B3(T,W) = 1 + (-B1(T) - B2(T,W) - 1) mod 16
B1(T) is the number of bits in the Host message including leader,
prefix, and text. B2(T,W) is the number of bits needed to make B1(T)
an integral number of Host words, and B3(T,W) is the number of bits needed
to make the total an integral number of 16 bit IMP words.
The M(T, W) bits are converted to packets in the following
way. The 32 bit leader is removed and the remaining words are divided
into packets containing no more than 1008 bits of data, each preceded
by an 96 bit header which includes the data from the 32 bit leader. When
these packets are transmitted to a neighboring IMP, they are enclosed
[Page 6]
RFC 635 An Assessment of ARPANET Protocols May 1974
in a line control envelope consisting of 48 bits of control octets and
a 24 bit cyclic checksum. We can compute the number of bits required
to carry all the packets as follows:
P(T,W) =( (M(T,W)-33)/1008 + 1 ) x 168 + M(T,W) - 32 (2)
The line transmission efficiency when transmitting T bits of Host
text is given by.
LTE(T,W) = T/P(T,W) (3)
The expected fraction of time a logical link, which is H hops long,
can be busy carrying a Host message of T text bits is given by
P(T,W)
EBF(T,W,H) = _____________________________
H*min[P(T,W) , 1176]+ max [P(T,W)-1176 ,0] (4)
EBF(T,W,H) is a refinement of the fraction computed earlier (m/(m+h-1)).
The numerator of EBF(T,W,H) is just the number of bits which must be
transmitted from the source IMP. The denominator uses the min and max
functions to deal with the case that a message is less than a full single
packet in length. In any case, it takes H hops to deliver the first
packet, and the remaining bits follow this packet until the entire message
has arrived at the destination IMP. (Note that DLE may be doubled on the
line so that this calculation assumes 'DLE' never sent as data.)
The routing messages require 1024 bits of text and 136 bits of packet
header and line control, and are sent by each IMP to all its adjacent
neighbors every .640 seconds. The bandwidth required for routing messages
is thus (1160)/.640 = 1.8 kb/sec.
Thus the bandwidth which can be expected for Host messages containing
T text bits, sent over H hops, is expressed in equation (5) below.
B(T,W,H) = EBF(T,W,H) x LTE(T,W) x (50-1.8) kb/sec (5)
B(T,W,H) ignores a number of complicating factors:
[Page 7]
RFC 635 An Assessment of ARPANET Protocols May 1974
a) delay for sending RFNM and implicit space reservation for
multipacket messages to source IMP.
b) propagation delays between Host/IMP and IMP/IMP
c) queueing delays at intermediate IMPs
d) retransmission delays
Nevertheless, B(T,W,H) offers an optimistic estimate of the bandwidth
that can be expected using the current ARPANET Host/Host protocol.
There is an implicit assumption that packets of a multipacket message
are not sent over alternate routes (e.g., two 50 kb/sec paths). Since
alternate routing in the IMP subnet is used to avoid congested areas
and not to improve bandwidth, this assumption is probably valid for the
low traffic densities presently found in the ARPANET.
B(T,W,H) has been plotted in figure 2 for a 32 bit Host (W=32), and
a range of message text lengths and Hops. As can be seen, the effect
of single message at a time transmission on a single logical connection
is very marked for longer and longer hops. The curves would be even
lower in the case of a satellite channel owing to the long propagation
delay (1/4 second up and down) for both the message and the returning RFNM.
[Page 8]
42 ||
||
40 |||
|||
38 |||8
1||78
36 12|78
12||78
34 123|678
123456 78
32 1 23456 78
1 2 3456 78
30 1 2 3 45 6 7 8
1 2 3 45 6 7 8
28 1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
26 1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
24 1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
22 1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
20 1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8 (8 Packets, 7992 bits)
18 1 2 3 4 5 6 7 (7 Packets, 7000 bits)
1 2 3 4 5 6 (6 Packets, 5976 bits)
16 1 2 3 4 5
1 2 3 4 5 (5 Packets, 4984 bits)
14 1 2 3 4
1 2 3 4 (4 Packets, 3960 bits)
12 1 2 3
1 2 3 (3 Packets, 2968 bits)
10 1 2
1 2
8 2 (2 Packets, 1944 bits)
1
6
1
4 1 (1 Packet, 952 bits)
2
1 2 3 4 5 6 7 8 9 10
Number of Hops
Single Link Source to Destination Host Throughput (32 bit word Host)
Figure 2
[Page 9]
RFC 635 An Assessment of ARPANET Protocols May 1974
The Multipacket Message Issue.
The original IMP system permitted only one message at a time on a
single link, and thus some means was needed to allow for higher bandwidth
than single packet messages could provide. This was achieved, to some
extent, by permitting up to eight packets in a single message.
It was soon discovered, however, that a Host transmitting multipackets
on separate logical links could cause a lockup condition at the destination,
and was first described by R. Kahn and W. Crowther [7].^ Essentially,
inadequate space might exist at the destination to reassemble all multi-
packets in transit on several links. The condition was self-sustaining
if the Host continued transmission, although the destination could
discard unassembled multipackets after a time-out. The condition either
backed up into the rest of the network, or at best caused loss of
messages in the network.
The solution to the multipacket reassembly lockup problem that was
eventually implemented required the source IMP to reserve reassembly
buffer space at the destination IMP before transmitting the multipacket.
Actually, this problem is just a case of a more general problem which can
be caused by the destination IMP sequencing of messages delivered to the
Host.
Ordering of Messages.
The IMP system guarantees that messages wi1l be delivered to a
destination Host in the same order that they left a source Host. This
service can cause a lockup similar to reassembly lockup if enough messages
arc in transit to the destination IMP. Single packet messages are sent
without prior reservation to the destination and, if space is available
for them, a RFNM is returned to the source IMP. In the event that no
______________________________
^ Kahn actually knew in 1967 that the condition could occur, but was unable
to convince his colleagues until he actually locked up the network by using
a message generator to flood the network in March, 1970.
[Page 10]
RFC 635 An Assessment of ARPANET Protocols May 1974
room is available, an implicit reservation request is queued at the
destination IMP. When space is available, an allocation message is sent
to the source IMP which retransmits the single packet message. The
source IMP keeps a copy of the single packet message for retransmission
until it either receives a RFNM from the first copy transmitted or an
allocate message indicating that there is now room available for a
second copy to be accepted.^
This scheme can fail if either a given Host has too many messages
in transit, or if many Hosts, served by different IMPs, have too many
messages in transit for the same destination. This is so because the
destination IMP will accept packets which arrive out of order and buffers
them until they can be re-ordered for transmission to the destination
Host.
Presently, a source IMP only permits up to four messages (regardless
of length) to be in transit for a given destination at a time. This
essentially reduces the probability of a lockup, but it is not zero,
since sufficient messages may be outstanding from different IMPs for the
same destination to cause a lockup.
Such lockups are protected against as well, by timing out undelivered
messages at the destination and discarding them. The timeout is on the
order of tens of seconds. Even though the IMP subnet can recover from
such conditions, it is apparent that Hosts must be prepared to retransmit
messages occasionally to recover from message loss caused by deliberate
discarding of messages at the destination or by catastrophic failures in
which an IMP loses all its packets upon crashing.
______________________________
^ R. Kahn, L. Kleinrock, and H. Opderbeck point out that IMPs do not accept
out-of-order packets, but do send allocates back for them. If room is also
allocated for unreceived but anticipated in-order packets, no lockup will
occur. If this step is omitted, then the implementation may fail.
[Page 11]
RFC 635 An Assessment of ARPANET Protocols May 1974
Host Retransmission, Sequencing, and Duplicate Detection.
The Host/Host protocol docs not provide for retransmission. If it
did, however, then this would require that the destination Host detect
duplicate transmissions and also verify sequencing of arriving messages
since the destination IMP cannot, in the current scheme, detect that a
Host has sent a duplicate message.
If this line of reasoning is pursued, it becomes evident that
sequencing of messages by the destination IMP is redundant and could be
eliminated. Furthermore, with the elimination of ordering, multipacket
messages could also be eliminated so long as Hosts were permitted to
transmit a sufficient number of single packet messages to achieve maximum
potential bandwidth.
Along with Host retransmission, it is necessary to introduce some
kind of end-to-end positive acknowledgment. The RFNM is currently sent
by the destination IMP to the source Host and is taken to mean that a
message has been successfully delivered to the destination Host (for
multipacket messages, the RFNM is sent after the first packet has been
delivered). It seems sensible to arrange a Host level acknowledgment
which confirms delivery. In this case, the RFNM could also be eliminated.
One might use RFNM's optionally as a debugging tool, to be turned off
and on at will.
Statistics taken from the ARPANET indicate that Host retransmission
would rarely be required on account of message loss, but this is partly
because of the retransmission and reservation facilities in the current
IMP system.
[Page 12]
RFC 635 An Assessment of ARPANET Protocols May 1974
Flow Control.
If all end-to-end retransmission, duplicate, detection, and sequencing
are performed by Hosts, then it is essential that the source and destina-
tion Hosts agree upon a maximum number of packets (or bits, octets, etc.)
that can be outstanding at one time. Otherwise, the destination Host
may experience lockup problems similar to those found now in the destination
IMP.
The current Host/Host flow control scheme has several weaknesses.
First, it requires that special control messages be sent on a control
connection which is distinct from the connection on which data is transmitted.
Second, it is an incremental scheme in which the destination Host allocates
a certain number of bits and messages which may be sent by the source.
Both source and destination Hosts decrement these counts as messages are
sent and received. To maintain throughput, the destination must periodi-
cally send allocations to the source to replenish its available buffer
space. Destinations with small amount of buffer space (e.g., Terminal
IMPs or TIPs) must do this fairly frequently and thus generate considerable
control traffic. Third, the loss of an allocation or the duplication of
one can cause loss of synchrony between source and destination.
In an earlier paper [9], the author and R. Kahn propose a more robust
flow control scheme including ideas found in the French CYCLADES network
[10]. Essentially, the receiver allocates a window representing the span
of sequence numbers that the sender may transmit. Acknowledgments from
the receiver to the sender indicate the largest sequence number received
so far (implicitly acknowledging all those preceding), and also indicate
the .current width of the window. The sender immediately knows which sequence
[Page 13]
RFC 635 An Assessment of ARPANET Protocols May 1974
numbers can be sent next. The scheme also allows for duplicate detection
and reordering of messages.
Acknowledgment and flow control information' is sent "piggy-back"
with data flowing in the reverse direction of a full duplex logical
connection so that a separate control connection is not needed for this
purpose. For example, a message is sent with sequence number M and
length L in octets. The receiver will respond with acknowledgment of
sequence number M+L and window size W. The sequence number of each
message is the sequence number of the previous message plus its length
in octets.
The receiver can vary the size of W without any serious adverse
effect, and can survive the receipt of duplicates or the loss of messages
due to the retransmission and duplicate detection permitted by the scheme.
The sender is not permitted to transmit a message whose sequence number
would exceed the sum of the last sequence number acknowledged plus the
current window size, W, modulo the maximum sequence number plus one.
Arbitrary Message Lengths.
Until now, it has been implicit that multipacket messages are unneces-
sary for maintaining high throughput, as long as sufficient packets can
be sent to fill the delay pipeline from source to destination Host. If
the IMP system were programmed with knowledge of the Host/Host protocol
so that it could create a properly formatted Host/Host header for each
packet it transmits, given the initial header of an arbitrarily long
message, then packets could be delivered out of order to the destination
Host, so long as each correctly identified the range of sequence numbers
contained in each packet. Since each octet of a message has an implicit
sequence number, this would not be difficult to compute. An idea similar
[Page 14]
RFC 635 An Assessment of ARPANET Protocols May 1974
to this is found in the Very Distant Host Reliable Transmission Package:
[appendix F, 5] in the current ARPANET, except in this case, a Host must
know about IMP packet format. It is debatable whether this would be a
good idea, since changes in Host/Host protocol would require changes in
IMP programming, but if it were implemented, then Hosts could send
arbitrarily long messages. The destination Host would receive a collec-
tion of single packet messages which it would then sequence as if they
had been sent that way by the source Host in the first place.
Simplex versus Full-Duplex Logical Connections
The present Host/Host protocol implements simplex connections. The
usage over the last five years seems to indicate that most often, two
simplex connections are set up to act as a full duplex connection.
If Host level acknowledgments and flow control are implemented, then it
is natural for them to be carried in the reverse direction of a full
duplex logical connection. Furthermore, terminal to Host connections
are necessarily full-duplex to allow for data to move in both directions.
Finally, by embedding control in the headers of returning traffic on the
full duplex connection, the need for a separate control connection could
be eliminated.
Connection Set-up.
The current Host/Host protocol uses control messages sent on a
special control connection to establish new connections,. The procedure
is called the Initial Connection Protocol or ICP [11]. The protocol is
symmetric and requires that information be exchanged by both Hosts as
to the names of the sockets at either end of the connection. This
exchange precedes any flow of data. Other control messages are exchanged
which determine the buffer space available at the receiver.
[Page 15]
RFC 635 An Assessment of ARPANET Protocols May 1974
A proposal by D. Walden [12] suggests that this is largely unnecessary,
as long as both sides can simultaneously send data identifying the source
and destination sockets (Walden calls them Ports) along with the text of
the messages.
A post office analogy is useful to describe what is intended. The
source Host writes a letter and encloses it in an envelope addressed to
the destination port with a return port address. Either the destination
port is willing to receive or it is not (e.g. it may not even be known
to the destination Host). In the former case, the letter is acknowledged
in the usual fashion. In the latter case, the letter is not acknowledged
(port unprepared to receive), or it is rejected ("address unknown").
Since port addresses may be dynamically assigned to processes in a
destination Host, it will probably be necessary to include a formal con-
trol exchange which indicates to the sender that a receive port is being
closed, and the sender would be expected to acknowledge this. Similarly,
the sender may end a transmission with the indication that the send port
is being closed and the receiver would similarly acknowledge. Since
Hosts do the sequencing, there can be no confusion as to when the closure
is to take place. The rejection of an initial transmission can be made
to look like the closure of the destination port so that the number of
distinct control messages can be kept to a minimum. This method is
similar to the one currently used in the ARPANET, but could be carried
out via control bits in the Host level messages and thus eliminate the
need for a special control connection.
[Page 16]
RFC 635 An Assessment of ARPANET Protocols May 1974
Summary.
Arguments have been presented in this paper which show that multi-
packet reassembly is not the best vehicle for achieving high throughput
from Host to Host. The elimination of IMP reassembly as well as message
sequencing by the destination IMP can permit considerable simplification
of the IMP protocols, while simultaneously placing the. burden of buffering,
duplicate detection, and sequencing of messages on the Hosts which have
the buffer space for this purpose.
Arbitrarily long messages could be sent by Hosts, at the expense of
IMP knowledge of Host protocol. Eliminating the ordering requirement
at the destination IMP also eliminates serious potential lockup conditions.
Host level positive acknowledgments can eliminate the erroneous use
of the RFNM for this purpose, and permit a more robust protocol which
need not depend upon perfect performance without message loss by the
IMP subnet.
Full duplex logical connections between ports in Hosts are more
natural than the simplex connections presently used, and facilitate the
elimination of the special control connection required in the current
Host protocol.
Unresolved Problems and Issues.
Even if a source and destination Host have adequate buffer space to
permit a large number of messages (or packets, or octets) to be outstanding
between them, the IMP subnet must have a way of combating congestion
which may result from too rapid influx of data from a source Host, or
from momentary congestion owing to the confluence of excessive traffic
heading, in the same direction, possibly to the same destination. Alternate
[Page 17]
RFC 635 An Assessment of ARPANET Protocols May 1974
routing strategies can help, but not completely solve the problem. One
possibility is to insist that source Hosts monitor actual throughput
achieved over the last few seconds (milliseconds?) and adjust output
rate accordingly. Destination Hosts can monitor this throughput as well,
and adjust the receive buffer space it allocates to the sender to reduce
unnecessary retransmissions. The IMPs can simply discard traffic which
cannot be buffered, knowing that the source will retransmit. IMPs
which discard packets to eliminate congestion could even send short
warning messages to source or destination (or both) to stimulate adjust-
ment. This is a very sticky problem and involves issues such as payment
by Hosts for retransmission. Most strategies in use today involve
limiting, a priori, the amount of data which a source Host is allowed
to send (e.g., isarhythmic network proposed by Davies [13]; maximum of
n messages allowed by ARPANET IMPs). Measurement of throughput
achieved by source and destination Hosts may be a good strategy in any
case since it serves as a measure of qua1ity of service provided by the
packet switchtng network.
In the ARPANET, the TELNET protocol [14] for terminal to Host com-
munication has needed some way of signalling the Host in which the serving
process resides that any accumulated data should be discarded up to the
point of the "interrupt signal." This facility permits a remote user
to abort or recapture control from an uncooperative serving process
which has stopped accepting data. The current scheme involves the use
of a special interrupt signal sent on the control connection, but there
is a problem of synchronizing the interrupt request with the data in the
pipeline. This signal could be carried in the control field of a Host
message and would participate in the sequence numbering of the data, thus
[Page 18]
RFC 635 An Assessment of ARPANET Protocols May 1974
providing for synchronization. Since the Host operating system would
process the message header before passing the data to the receiving port,
the interrupt could bypass processing by the receiving process and thus
provide the desired interrupt-like effect.
There are undoubtedly many other problems and issues which could
not be mentioned in the scope of this paper, and the author would be
pleased if these and the preceding commentary will stimulate discussion
and thus further the general understanding of protocol requirements for
distributed computer networks.
Acknowledgments:
Throughput and delay analysis: some of the basic ideas in this
analysis are due to J. McQuillan (Bolt, Beranek, and Newman). Single
packet re-ordering lockup: first called to the author's attention by
P. Higginson (University 6f London). Host-Host Protocol Design:
developed largely under the auspices of the International Network Working
Group (IFIP TC6.1), and the author especially acknowledges contributions
by R. Kahn, R. Metcalfe, L. Pouzin and H. Zimmerman, as well as S. Crocker,
A. McKenzie, and R. Scantlebury. Numerous omissions and misstatements
were detected by R. Kahn, L. Kleinrock and H. Opderbeck.
The author is grateful for the support of the Defense Advanced
Research Projects Agency under contract DAHC-15-73C-0435.
[Page 19]
RFC 635 An Assessment of ARPANET Protocols May 1974
References
1. McKenzie, A. "HOST/HOST Protocol for the ARPA Network," Current Network
Protocols, Network Information Center, Stanford Research Institute,
Menlo Park, California, January 1972 (NIC8246).
2. Carr, S. and S. Crocker, V. Cerf, "HOST-HOST Communication Protocol
in the ARPA Network, AFIPS 1970, SJCC Proceedings, Vol. 36, Atlantic
City, AFIPS Press, New Jersey, pp. 589-597 [somewhat out of date].
3. Crocker, S. D., and J. Heafner, R. Metcalfe, J. Postel, "Function-
Oriented Protocols for the ARPA Computer Network," AFIPS 1972 SJCC
Proceedings, Vol. 40, Atlantic City. AFIPS Press, New Jersey,
pp. 271-279.
4. Heart, F. E., and R. E. Kahn, et al, "The Interface Message Processor
for the ARPA Computer Network, AFIPS 1970 SJCC Proceedings, Vol. 36,
Atlantic City, AFIPS Press, New Jersey, pp. 551-567.
5. Bolt, Beranek and Newman, Inc., "Specification for the Interconnection
of a Host and an IMP," BBN Report 1822, April 1973 (Revised).
6. Roberts, L. and B. Wessler, "Computer Network Development to Achieve
Resource Sharing," AFIPS 1970, SJCC Proceedings, Vol. 36, Atlantic City,
AFIPS Press, New Jersey, pp. 543-549.
7. Kahn, R. E. and W. Crowther, "Flow Control in a Resource Sharing
Computer Network," Second Symposium on Problems in the Optimization of
Data Communications Systems, Palo Alto, October 1971, p. 108-116
[also IEEE Transactions on Communication, June 1972].
8. Kahn, R. E., "Resource Sharing Communication Networks," IEEE
Proceedings, Nov. 1972.
9. Cerf, V. G. and R. E. Kahn, "A Protocol for Packet Network Inter-
communication," IEEE Transactions on Communication, vol. COM-22
No. 5, May 1974 p 637-641.
[Page 20]
RFC 635 An Assessment of ARPANET Protocols May 1974
10. Pouzin, L., "Presentation and Major Design Aspects of the CYCLADES
Computer Network," Data Networks: Analysis and Design, Third Data
Communications Symposium, St. Petersburg, Florida, November 1973,
pp. 80-87.
11. Postel, J., "Official Initial Connection Protocol," Current Network
Protocols, Network Information Center, Stanford Research Institute,
Menlo Park, California, January 1972 (NIC 7101).
12. Walden, D., 'A System for Interprocess Communication in a Resource
Sharing Computer Network, Communications of the ACM, 15, 4, April 1972,
pp. 221-230 (NIC 9926).
13. Davies, D., "Communication Networks to Serve Rapid Response
Computers," Information Processing 68, Proceedings of IFIP Congress
1968, Vol. 2, Edinburgh, Scotland, 1968, North-Holland Publishing
Co., Amsterdam, 1969, p. 650-658.
14. McKenzie, A. "TELNET Protocol Specification," Current Network Protocols,
Network Information Center, Stanford Research Institute, Menlo Park,
California, August 1973 (NIC 18639, NIC 18638 - Revisions).
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Roger D. Moore, with ]
[ assistance from William M. Stewart on Figures 1 and 2,]
[ 11/2006 ]
Notes by Roger D. Moore regarding copy and formatting changes:
A] Page numbers zero and one added to text
B] Paragraph indent in pages 1-3 is five; it is four spaces in pp 4++
C] All pen marked underlining from paper copy has been discarded.
D] Footnotes: The original text used a sequence of superscript
asterisks to mark a footnote.
I have replaced all of these with the character "^" which does not
otherwise appear in the document. I have used a sequence of
underscore characters to
to seperate text and notes at bottom of pages 3 4 5 10 11.
E] Formulae: On page six I have replaced symbols of the form "B
subscript digit" with "Bdigit"
F] Forumla [2] page seven: I have rewritten this to eliminate
horizontal line (division symbol).
G] Quarter symbol: page eight (last line) had a special symbol which I
have replaced with "1/4"
H] Marginal notes: I have preserved formulae notes from page
six. Others have been discarded.
I] Page numbers: I have left two blank lines after page header. Page
footer is incomplete
but has the form [Page 9] or [Page 99]. RFCs in the archive have
some special character
between the footer and header (ASCII formfeed?). I was unable to
enter this character.
J] Reference 9: I have included page numbers since this paper is now
published.
K] Figure 2 on page nine originally contained continuous curves in
heavy pencil, redrawn in ASCII.