Performance improvement in ARPANET file transfers from Multics
RFC 662

Document Type RFC - Unknown (November 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 662 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                               Raj Kanodia
Request for Comments: 662                                      Project MAC, MIT
NIC #31386                                                            Nov. 1974

       PERFORMANCE IMPROVEMENT IN ARPANET FILE TRANSFERS FROM MULTICS

With the growth of Multics usage in the ARPA Network community, users often 
need to transfer large amounts of data from Multics to other systems. However,
Multics performance in this area has been less than optimal and there clearly
exists a need to improve the situation. Even within Project MAC there are users
who regularly ship files back and forth between Multics and other Project MAC
computer systems. Recently the Cambridge Information Systems Laboratory (CISL)
development Multics system was connected to the ARPA Network. This has
generated considerable interest among the members of the CSR (Computer Systems
Research) and CISL groups in using the Multics file transfer facility for tran-
smission of Multics system tapes (MST) from one Multics system to the other.
At currently realizable data transfer rates, transmission of a typical MST,
(approximately 12 million bits), takes about half an hour. The usefulness of
the present file transfer system is severely limited by its low bandwidth.

One of the reasons for such a poor performance is the output buffering strategy
in the Multics IMP DIM (IMP Device Interface Manager.) With the hope of making
a significant performance improvement, we recently changed the IMP DIM buffer-
ing strategy. To assess the effects of this change an experiment was conducted
between the service machine (MIT Multics) and the development machine (CISL
Multics.) This memo reports the experiment and its results.

PROBLEM

Due to reasons that are of historical interest only, the output buffers in the
IMP DIM have been very small; each buffer can accommodate up to 940 bits only.
With the addition of a 72 bit long header, the resulting message has a maximum
length of 1012 bits, which in the Network terminology is a single packet
message. Due to this buffer size limit, Multics can transmit single packet
messages only, even though the network can accept up to 8096 bit long messages.
This results in increased overhead in the set up time for transmission of large
number of bits.

An old version of the IMP-to-Host protocol requires that a host may not transmit
another message on a network connection unless a Request-for-Next-Message (RFNM)
has been received in response to the previous message. Even though this
restriction has now been relaxed, the protocol does not specify any way to
recover from transmission errors that occur while more than one RFNM is pending
on the same connection. If the constraint of transmitting only one message at a
time is observed there is at least some potential for recovery in case of an
error. 8eing reliability conscious, Multics observes the constraint imposed by
the old protocol. Following the old protocol introduces delays in the
transmission of successive messages on the same link and therefore the overall
bandwidth per connection is reduced.

                                      -1-


SOLUTION

At least one method of improving the file transfer bandwidth is obvious.
Increasing the size of IMP DIM output buffers will allow us to transmit
significantly larger messages<s1>s This will result in fewer RFNMs and delays and
improved bandwidth. We have made two assumptions here. The first assumption is
that the delay introduced by RFNMs does not increase with the size of the
message.<s2>s Our experience with the network tends to support this assumption.
The second assumption is that actual time taken to transmit a message increases,
at best, linearly with the size of message. This second assumption does not
hold for a heavily loaded network. But for our purpose we may assume it to be
essentially correct.

There is another advantage in transmitting large messages. For a given amount
of data, fewer messages will be transmitted, fewer RFNMs will be read, and
therefore time spent in the channel driver programs will be reduced. Since the
channel sits idle during at least some of this time, the idle time for the
channel will be reduced, resulting in improved channel bandwidth.

EXPERIMENT

We changed the IMP DIM to implement two kinds of output buffers. One kind of
output buffer is short and can hold single packet messages only. The other kind
of buffer is, naturally enough, large and can hold the largest message allowed
by the network. If the number of bits to be transmitted is low (this is mostly
the situation with interactive users,) a small buffer is chosen and if it is
large (for example, file transfers,) a large buffer is chosen.

The new IMP DIM was used in an experimental Multics system on the development
machine at CISL. The service machine at MIT had the old version. Large files
were transmitted from the development system to the service system and the file
Show full document text