From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc557.txt | 115 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 115 insertions(+)
 create mode 100644 doc/rfc/rfc557.txt

(limited to 'doc/rfc/rfc557.txt')

diff --git a/doc/rfc/rfc557.txt b/doc/rfc/rfc557.txt
new file mode 100644
index 0000000..6d8bb54
--- /dev/null
+++ b/doc/rfc/rfc557.txt
@@ -0,0 +1,115 @@
+
+
+
+
+
+
+Network Working Group                                         B. Wessler
+Request for Comments: 557                         Telenet Communications
+NIC: 18457                                                30 August 1973
+References: RFC 392, 415
+
+
+                REVELATIONS IN NETWORK HOST MEASUREMENTS
+
+   The purpose of RFC 392 was to identify a problem we had encountered
+   in using the ARPANET at Utah.  The primary thrust of the paper was
+   supposed to be: "Here is a place to make the Network better" rather
+   than: "Look, isn't the Network terrible."  The accepted use of 392
+   seems to be the latter rather than the former.  A second purpose of
+   392 was to stimulate the undertaking of measurement experiments on
+   other computers and operating systems in addition to TENEX.  Very
+   little in the way of measurements has been reported (other than Hal
+   Murray's RFC 415 measuring TENEX).
+
+   Since the Publication of RFC 392, BBN has done a considerable amount
+   of work to improve Host-Net performance on TENEX.  They reported new
+   measurement results in their April 1973 Quarterly Progress Report No.
+   10.  I feel it is important to circulate those results to the RFC
+   community.
+
+   Don Allen at BBN borrowed Greg Hicks' RJS program and 1) updated it
+   to take advantage of recent changes in TENEX, 2) improved the code
+   near the input/output JSYs and 3) used considerably faster network
+   monitor code.  The result was approximately 400% improvement from
+   75-85 seconds of CPU time per megabit (~$10) to 19 seconds per
+   megabit (~$2.50).  Of the 19 seconds, 13 were spent in the RJS
+   program and 6 in TENEX network output.  The six seconds seem to
+   relate very well to BBN FTP requirements where 8.2 cpu seconds per
+   megabit were required (~$1.08) for 8 bit byte transfers.  (Going to
+   32 or 36 bit bytes improves this figure by a factor of 4, resulting
+   in a cost of $.33 per megabit.)
+
+   Of the 13 seconds left in RJS no attempt was made to improve or even
+   discover where the time was spent.  This extra effort was not
+   expended because RJS is soon to be replaced by the RJE protocol which
+   uses FTP as its transfer mechanism.
+
+   In summary, I believe that the original RFC #392 and the recent BBN
+   results show that the Network including the Host cost, is
+   intrinsically effective.  If care is not taken in monitor and user
+   code the system may not look very attractive.  I hope everyone now
+   goes out and measures how good (or bad) they are doing vis a vis
+
+
+
+
+
+Wessler                                                         [Page 1]
+
+RFC 557         REVELATIONS IN NETWORK HOST MEASUREMENTS     August 1973
+
+
+   network transfers.  Please send me the results personally if they are
+   too embarrassing to distribute via RFC.  It would be nice to hear
+   from all systems.
+
+   All the data is courtesy of Don Allen and Jerry Burchfiel at BNN.
+
+
+         [ This RFC was put into machine readable form for entry ]
+             [ into the online RFC archives by Lorrie Shiota ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wessler                                                         [Page 2]
+
-- 
cgit v1.2.3