doc: Add RFC documents

1 files changed, 112 insertions, 0 deletions

diff --git a/doc/rfc/rfc113.txt b/doc/rfc/rfc113.txt
new file mode 100644
index 0000000..884e37b
--- /dev/null
+++ b/doc/rfc/rfc113.txt
@@ -0,0 +1,112 @@
+
+
+
+
+
+
+Network Working Group                      5 April 1971
+Request for Comments: 113                  E. F. Harslem
+NIC 5820                                   J. F. Heafner
+                                           J. E. White
+
+
+               NETWORK ACTIVITY REPORT:  UCSB <- -> RAND
+
+UCSB RJE/RJOR
+
+      The UCSB Remote Job Entry (RJE) and Remote Job Out- put
+Retrieval (RJOR) Systems described in NWG/RFC #105 have been used and
+validated from Rand.  The facility is now being used on a limited
+basis as a production tool by another research group at Rand.
+     Access to the UCSB facility from Rand is through the Network
+Service Program (NSP).  This program is driven by Rand Video-Graphic
+consoles and allows a console user access to both local file storage
+(at Rand) and to the Network. A small module (UCSBMGR) was added to
+NSP to handle the UCSB RJE and RJOR protocols and data formats.
+     In exercising the RJE/RJOR facility over the past two months,
+typical job sizes included input decks of 800 to 2800 80-character
+card images and output files of about 30 pages of printer linstings.
+
+NETWORK OBSERVATIONS
+
+     In sending files to UCSB we did a timing study over several
+transmissions of the above mentioned 2800 record file.  On the average
+this file was transmitted at a rate of 250 80-character cards per
+minute.  (Each 80-character card was a separte Network message.)  This
+is, of course, much less than the advertised 30 kilobit rate; however,
+it should be remembered that the path from Rand to UCSB is through at
+least one intermediate IMP.  On the other hand, the processes at each
+end of the connection were running at maximum priority with very small
+loads on either machine.  An obvious area for speed-up would be the
+blocking of card images for network transmission.
+     In the course of the last two months of networking, we have
+noticed approximately five serious failures in transmitted messages.
+In two instances, the RFNM on the control link from UCSB to Rand was
+lost.  Its loss was not reported via a type 9 IMP-to-Host message as
+would be expected.  We have not been able to cause the problem to
+occur; hence we are unable to ascertain whether it is an IMP problem
+or a problem with the UCSB Host Interface.
+     The other three errors were related to the garbling of a data
+message between the Rand NSP and UCSB RJE.  In all three instances, it
+was the second card image trans- ferred to RJE.  We were unable to
+cause this problem at will; hence have been unable to track it down.
+Unfortun- ately the HASP system at USCB merely ignored this image
+rather than printing it so we are not aware of the nature nor source
+
+
+
+                                                                [Page 1]
+
+of the garbling.  It could be anywhere from the disk file storage at
+Rand on down the line.  This problem was observed sporadically in our
+early trans- missions to UCSB and has disappeared.  We feel relatively
+confident, however, that our Host software on either end was not at
+fault.
+     Lest these last two figures seem too terrifying, it should be
+noted that we have run over 100 jobs at UCSB from Rand, each job
+consisting of many Network transmissions.
+
+       [ This RFC was put into machine readable form for entry ]
+         [ into the online RFC archives by Simone Demmel 4/97 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 2]
+