diff options
author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
---|---|---|
committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc573.txt | |
parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc573.txt')
-rw-r--r-- | doc/rfc/rfc573.txt | 451 |
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc573.txt b/doc/rfc/rfc573.txt new file mode 100644 index 0000000..c7dd50e --- /dev/null +++ b/doc/rfc/rfc573.txt @@ -0,0 +1,451 @@ + + + + + + +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 + + Average Response-time (sec.) 2.7 2.4 3.0 + + Host Availability 93% 85% 87% + + Logger Availability 91% 79% 83% + + Failure-to-connect rate + + for Host (hours) 18.2 9.4 18.1 + + Failure-to-connect rate + + for logger (hours) 16.0 6.0 10.0 + + The details on the above measurements will be reported in a forth- + coming paper. This paper will focus on the remaining parameters of + transmission rate, processing costs and accuracy, as measured by the + MIT-DMS File Transfer Measurement facility. + + The FTP measurement facility exists in the MIT-DMS CALICO subsystem. + Each time the MIT-DMS FTP-user or FTP-server program in the CALICO + subsystem is used to transfer files (and data) via the ARPANET, it + records in a local disk file the following transfer parameters: the + remote Host involved, the date and time the transfer is initiated, + the total number of bits transferred, the real time taken (in + seconds) for the transfer, the CPU time (in micro-seconds) used by + the program, whether the program is the server or user, and the FTP + parameter settings for byte size (BYTE), representation type (TYPE), + transfer mode (MODE), and the file structure (STRU). Programs exist + in CALICO to display and summarize this data. + + It should be noted that no measurements are recorded when the non- + CALICO FTP-user and FTP-server programs are used for transferring + files. Therefore it should be pointed out that the measurement + represents a small subset of our total FTP-usage. The CALICO FTP- + server was operated only till May 1973, when we switched to the non- + CALICO FTP-server. (The switch was made because CALICO still + undergoing development is somewhat less reliable. As CALICO + stabilizes we may again operate the CALICO server and continue + measuring data transfer.) In addition many users prefer to use the + simpler (involving fewer system resources) stand-alone FTP-user + + + +Bhushan [Page 3] + +RFC 573 DATA AND FILE TRANSFER September 1973 + + + program. The measurement does include the data transferred when FTP + is used indirectly by such commands as "copy", "print", "listf", and + "mail.file" in the CALICO NETWRK subsystem. + +III. THE MEASUREMENT RESULTS + + The measurement facility has been operational (though not + continuously) since 25 February 1973. It has recorded the transfer + of 304 files consisting of 57.6 million bits. Over 90% of the bits + transferred (but only 75% of the files)used the more efficient + Image-36 stream mode (TYPE I, BYTE 36, MODE S) of transfer. The + remainder of the files were transferred using the ASCII-8 stream mode + (TYPE A, BYTE 8, MODE S). It should be noted that even though block + mode was available, it was never used by our users (primarily because + many FTP-servers do not implement it, and it is less efficient to + use). All the files had a sequential non-record file structure (STRU + F). A summary of the measurement results is shown in Table II. + + TABLE II + + SUMMARY OF FTP MEASUREMENT RESULTS + + Subset of data # Files # bits Av. File Speed CPU-use + Mbits Kbits Kbps sec/Mb + + Total 304 57.6 189 7.56 4 + + Image 36 mode 223 53.6 240 9.35 3 + + ASCII-8 mode 81 4.0 49 2.09 19 + + Server sending 62 3.8 61 7.50 2 + + Server receiving 110 19.8 180 7.44 1 + + User receiving 83 22.8 276 7.92 6 + + User sending 49 11.1 225 7.09 4 + + The entire display of the measurement data and the summaries shown in + Table II are generated by the "PFTPST" (Print FTP Statistics) + program in the CALICO subsystem. A sample of the data displayed is + shown in Table III. The BPS (bits per second) and the M/B (CPU + microseconds per bit or CPU seconds per Megabit) information is + calculated by the displaying program. The largest file transferred + was 5.03 Mbits, a "STOR" by the FTP-user to MIT-AI. The transfer + took 10 minutes of real time for a transfer rate of a little over 10 + Kbps. The highest data transfer rate recorded was 27.8 Kbps, a + + + +Bhushan [Page 4] + +RFC 573 DATA AND FILE TRANSFER September 1973 + + + "RETR" from BBN-TENEXA to MIT-DMS FTP-server. The length of the file + in the above case was 28 Kbits. Needless to say that both of the + above transfers used the more efficient Image-36 mode for transfer. + The smallest file and the smallest transmission rate recorded was an + 80 bit "MLFL" to MIT-ML (using ASCII-8) which took 7 seconds real + time for 11 bps transfer rate. + + TABLE III + + SAMPLE DISPLAY OF FTP MEASUREMENT DATA + + -#- ---HOST--- COMM --DATE-- --TIME-- --BITS-- -BPS- M/B T BY PRG + + 2 sri-arc STOR 73/08/09 18:19:49 121392 1395 21 I 36 U + 198 mit-ml STOR 73/08/15 15:00:30 50688 5336 8 I 36 U + 198 mit-ml RETR 73/08/15 15:01:14 50688 10137 12 I 36 U + 198 mit-ml STOR 73/08/15 15:02:33 255456 8808 7 I 36 U + 198 mit-ml RETR 73/08/15 15:03:58 258048 8601 12 I 36 U + 134 mit-ai STOR 73/08/15 15:13:17 286720 1898 29 A 8 U + 134 mit-ai RETR 73/08/15 15:18:39 258048 9557 14 I 36 U + 134 mit-ai STOR 73/08/15 15:19:42 258048 6974 7 I 36 U + 2 sri-arc RETR 73/08/15 15:31:20 7236 3618 22 I 36 U + 2 sri-arc STOR 73/08/15 15:32:55 49428 8238 31 I 36 U + 2 sri-arc RETR 73/08/15 15:34:56 49428 3530 15 I 36 U + 2 sri-arc STOR 73/08/15 15:38:09 49428 7061 8 I 36 U + 2 sri-arc STOR 73/08/20 15:18:26 35460 2364 9 I 36 U + 2 sri-arc RETR 73/08/20 16:08:09 58832 426 153 A 8 U + 2 sri-arc RETR 73/08/22 12:46:10 10512 166 247 A 8 U + 2 sri-arc RETR 73/08/23 16:29:37 320 64 369 A 8 U + 2 sri-arc RETR 73/08/24 12:25:38 9992 262 254 A 8 U + 2 sri-arc RETR 73/08/24 12:27:26 9992 454 250 A 8 U + 198 mit-ml STOR 73/08/29 10:40:58 768924 7538 7 I 36 U + 198 mit-ml STOR 73/08/29 10:44:09 166572 5552 7 1 36 U + 198 mit-ml STOR 73/08/29 10:54:32 166572 7932 7 I 36 U + 198 mit-ml STOR 73/08/29 13:48:18 158040 12156 7 I 36 U + 69 bnn-tenexa MLFL 73/08/29 22:30:55 5600 1866 51 A 8 U + 69 bbn-tenexa MLFL 73/08/29 22:31:42 5600 2800 50 A 8 U + 86 usc-isi MLFL 73/08/29 22:33:55 5600 1400 54 A 8 U + 69 bbn-tenexa MLFL 73/08/29 22:36:15 5600 2800 48 A 8 U + 69 bbn-tenexa MLFL 73/08/29 22:36:54 5600 2800 49 A 8 U + + It should be pointed out that recent measurement data for ASCII-8 + transfer includes retrieval of "NIC Journal" documents + ("<Xjournal>xxxxx.nls;xnls" files) from SRI-ARC. SRI-ARC converts + these "xnls" files from NLS to sequential form on the "fly" and this + takes considerable time giving a low transfer rate for these + transfers. + + + + +Bhushan [Page 5] + +RFC 573 DATA AND FILE TRANSFER September 1973 + + + In transferring files we found the ARPANET and the FTP to be quite + reliable. On numerous occasions we transferred complete listing of + our operating system (about 6 million bits), reassembled it and ran + it with no problem. No data lossage problems have been reported to + us as yet. + +IV. THE SIGNIFICANCE OF MEASUREMENT RESULTS + + First of all let me state my complete agreement with Barry Wessler + (Ref. "Revelations in Network Host Measurements" NWG/RFC 557, NIC + 18457) that the measurement results should be taken in the spirit: + "Here is a place to make the Network better" rather than: "Look, + isn't the Network terrible." We take these measurements in the same + spirit and have found the measurement effort to be quite fruitful. + In several instances, with the aid of our measurement facilities, we + have been able to improve the performance of our Network programs by + an order-of-magnitude (just as Don Allen at BBN improved Greg Hicks' + RJS program). + + Our measurement results are in close agreement with the BBN FTP + measurements (8.2 cpu seconds/Mb for 8-bit byte and 2 CPU seconds/Mb + for 36-bit byte transfers). We also find the 36-bit byte transfer to + be an order-of-magnitude more efficient than 8-bit byte transfer. + The processing cost (assuming $6.00 per CPU minute) for transferring + a Megabit of information comes to about $1.90 for ASCII-8 mode as + compared to only $0.30 for Image-36 mode. The difference in + transfer rate is equally astounding being 9.4 Kbps for Image-36 as + compared to only 2 Kbps for ASCII-8. + + It is therefore recommended that Image-36 mode be used as much as + possible to transfer data between PDP-10s (of which there are many on + the ARPANET). It is strongly urged that protocols and programs allow + (and use) the Image-36 mode for all data transfers including mailing + files (MLFL), listing directories (LIST, NLST), and + sending/retrieving NIC Journal documents. Many of the MID-DMS user + programs such as "COPY" and "FTP" take advantage of the fact that the + remote Host is a PDP-10 (there is a table of PDP-10's in "COPY") and + use the more efficient Image-36 mode. Such a procedure is highly + recommended. + + The effective IMP-IMP data transfer rate is about 37.5 Kbps over the + 50 Kbps telephone line (Ref. McQuillan John M., "Throughput in the + ARPA Network--Analysis and Measurement," BBN Report 2491, NIC 14188, + January 1971). The Host-to-Host data transfer measurement performed + by BBN (above reference, p. 28) have indicated a transfer rate of + 30-35 kbps BBN-to-BBN (0 IMP hops) and 12-16 Kbps BBN-to-SRI (5 hops) + using single link. As FTP transfers data via a single link, a + maximum transfer rate between 12 and 35 Kbps (depending on number of + + + +Bhushan [Page 6] + +RFC 573 DATA AND FILE TRANSFER September 1973 + + + IMP hops) can be expected if that file transfer is the only activity + going on. In this light our maximum transfer rate of 27 Kbps to BBN + (2 hops) is probably the most one can expect out of any program. The + average transfer rate of 9.4 Kbps (for Image-36) transfer also + appears reasonable in view of the fact that during many of the + transfers other network activity is also going on, and that many of + the transfers are performed when the respective computer systems are + quite heavily loaded. Our measurement data does reveal that transfer + rate is appreciably higher during the times a computer is likely to + be lightly loaded. + + The above does not mean that improvements are not possible or not + required in the state of the ARPANET data transfer. Our measurement + data has revealed areas in which improvements can be and should be + made. For example, the transfer of data to other MIT Hosts (0 IMP + hops) and back to ourselves should be faster than what we currently + achieve (transfer to BBN is faster!). The probable reason for the + above discrepancy is that our allocation (Host-Host protocol) is very + small (2944 bits) as compared to that provided by BBN (17724 bits). + This means that to transfer data our Network Control Program (NCP) + has to wait for an allocation many more times while communicating to + an ITS system than to a TENEX system. Large allocations are always + desirable but even more so while transferring files. NCP designers + can (and should) modify NCP's to allow large allocates (larger NCP + buffers) for file transfer even at the expense of smaller allocates + for other types of connections (such as a terminal connected to a + computer system) which do not require or use the larger allocation. + In addition, a new allocate should be sent as soon as data is read by + the receiving program (the NCP should not wait for the allocation to + become zero before sending the new allocate). + + We also observed that small files are transferred at a significantly + lower transfer rate than large files but beyond a file size of 40 + Kbits, the file size makes little difference in transfer rate or + processing cost per bit transferred. The figure of 40 Kbits is + probably related to the size of sending and receiving buffers used by + the programs. In general, for most practical values of buffer size, + the larger the buffer size and allocations, the faster and more + efficient will be the transfer. Unfortunately, large NCP buffers are + not easily available in many systems and come at a premium. The + information on average file size (240 Kbits for Image and 40 Kbits + for ASCII files) may be helpful in optimum allocation of buffer + space. + + + + + + + + +Bhushan [Page 7] + +RFC 573 DATA AND FILE TRANSFER September 1973 + + +V. REQUEST FOR COMMENTS AND SUGGESTIONS + + It is hoped that the above measurement results and our FTP and SURVEY + measurement facilities will help ARPANET users plan their modes of + Network usage and help Network programmers in making the Network + better. This RFC is indeed a Request For Comments and your + suggestions on the way we collect, store, and display measurement + data will be greatly appreciated. We can break the measurement data + by Hosts and will be happy to provide the information if it is + considered desirable. Please let me know what other parameters we + should record or display. You may communicate with me via the + ARPANET (AKB at MIT-DMS (Host 70), NIC Ident AKB), via telephone + (617-253-1428 or 1449), or US mail (Rm. 208, 545 Tech Square, + Cambridge, Mass 02139). + + + [ This RFC was put into machine readable form for entry ] + [ into the online RFC archives by Robert Baskerville 9/98 ] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bhushan [Page 8] + |