DATA AND FILE TRANSFER - SOME MEASUREMENT RESULTS
RFC 573

Document Type RFC - Unknown (September 1973; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 573 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         A. Bhushan
Request for Comments: 573                                         MIT-DM
NIC: 19083                                             14 September 1973

           DATA AND FILE TRANSFER - SOME MEASUREMENT RESULTS

   During the last six months, we have been monitoring (although not
   continuously) the performance of our FTP-user and FTP-server
   programs.  The purpose of this paper is to  1) discuss measurement
   criteria,  2) describe the measurement facilities, 3) report the
   relevant measurement results,  4) discuss the significance of results
   and compare them with other measurement data, and 5) ask for
   suggestions on our measurement and summarizing procedures.

I. THE MEASUREMENT CRITERIA

   The FTP (Ref. "The File Transfer Protocol", by Abhay Bhushan, NWG/RFC
   354, NIC 10596, ) may be considered a facility for data transfer
   between file systems.  The relevant measurement parameters for a data
   transfer facility are:

   1) Transfer rate (both peak and average, measured in bits per second)
   which determines the throughput of the data transfer facility.

   2) Response time or delay (measured in seconds) which determines the
   "interactibility" of the facility.

   3) Processing cost (measured in dollars or cpu-seconds per megabit
   transferred) for transferring the data between the network and the
   file system.  This is only one component of the cost of transferring
   data, the other component being the communication cost (including IMP
   processing costs) which we take as given.

   4) Failure-to-connect rate - average time elapsed between failures to
   connect to the facility (measured in hours).  Failures could be in
   the Host (processor and file system) hardware or software, or in the
   IMPs and telephone lines.

   5) Availability - the percentage of time a given facility is
   available, or alternately the probability of finding the facility
   available at a given time.

   6) Accuracy - measured by the probability of error in transferring
   bits, bytes, blocks, or files.

Bhushan                                                         [Page 1]
RFC 573                  DATA AND FILE TRANSFER           September 1973

II.  THE MEASUREMENT FACILITIES

   The MIT-CMS survey program (ref. "A Report on the Survey Project" by
   Abhay Bhushan, NWG/RFC 530, NIC 17375) measures the response-time,
   failure-to-connect rate, and availability of the Host-logger facility
   (on socket 1).  Our preliminary experiments have indicated that the
   corresponding measurement results for the FTP are very close to that
   for the logger (at least they are the same order-of-magnitude).  As
   the use of FTP and the ARPANET is increasing rapidly, most Hosts have
   their logger and FTP operational whenever their Host and NCP (Network
   Control Program) are functioning.  The response time for obtaining
   the use of FTP service is very close to that for obtaining the use of
   the logger service as both involve the use of the ICP (Initial
   Connection Protocol).

   Preliminary results from the Survey Project indicate that the average
   response time in recent months has been about 2.7 seconds.  The
   average availability has been about 85% with the failure-to-connect
   rate being about once every 10 hours.  Table I shows summary results
   for the time period August 26 through August 31, 1973, for three
   Hosts with TENEX operating systems (SRI-ARC (NIC), BBN-TENEXA, and
   USC-ISI).

   The reader is cautioned that the data below reflects the Host
   performance as seen by the MIT-DMS survey program which surveys the
   Hosts only once every twenty minutes.  Consequently, the actual host
   performance may be somewhat different.  Also, we cannot distinguish
   between IMP, telephone lines, and Host failures and the response time
   of a host is affected by its distance (number of IMP hops) from the
   MIT IMP (IMP 6).

   In the data shown in Table II, each success or fail response is
   considered to have a duration of 20 minutes, so Hosts are given the
   benefit of the doubt for the time we are not surveying.  In addition,
   the response time has been averaged only for the successful logger
   available responses.  The logger is considered available if the
   SURVEY program can establish a full-duplex connection within 20
   seconds.  The Host is considered available when it is not in the
   "DEAD" state (states in which logger is not up but the Host is
   available are logger not responding and logger rejecting).

Bhushan                                                         [Page 2]
RFC 573                  DATA AND FILE TRANSFER           September 1973

                                TABLE I

   RESPONSE TIME, AVAILABILITY, AND FAILURE RATE FOR SELECTED HOSTS
          (based on SURVEY data for 8/25/73 through 8/31/73)

            PARAMETER                      NIC     BBN     ISI
Show full document text