1 files changed, 59 insertions, 0 deletions
diff --git a/doc/rfc/rfc346.txt b/doc/rfc/rfc346.txt
new file mode 100644
index 0000000..06c4c24
--- /dev/null
+++ b/doc/rfc/rfc346.txt
@@ -0,0 +1,59 @@
+
+
+
+
+
+
+Network Working Group                           Jon Postel
+Request for Comments: 346                       Computer Science
+                                                UCLA-NMC
+NIC : 10425                                     30 May 72
+
+Categories :  Echo Plex, Satellite
+References :  RFC's 1, 5, 51
+
+                        Satellite Considerations
+
+The consideration of using space satellite transmission links in the
+ARPANET should be cause for some thought by the parties making use of
+the network.  The satellite transmission path will not necessarily affect
+the transmission rate but it will affect the delay.  The change in the
+delay characteristics can be approximated by the change in path length.
+Thus if the satellite is in synchronous orbit about 22,000 miles above
+the earth, the path length is about 44,000 miles compared to (worst
+case) 3,000 miles or about a 15 to 1 increase in path length and delay.
+(The time for light to travel 3,000 miles is .016 seconds, to travel
+44,000 miles is .236 seconds.)
+In the current (surface) ARPANET delays are such that interactive
+servers with character-at-a-time remote echo are only marginally useful.
+While I believe that this delay (unmeasured) is largely due to the host
+systems, adding a half second transmission delay will cause these
+marginal systems to become unusable.
+Thought should also be given to buffer allocations.  If a receiving
+system allows only one line of text to be buffered at a time and
+refreshes the allocation as each line is output to a human user there
+will be at least a half second delay between the arrival of each line at
+the receiving system.  This need not be a problem until the speed of the
+output device is above about 150 characters/second.  This "small buffer"
+problem can be expected to occur even with lower speed devices since
+host delays are estimated to be in the range 0.1 second to 1.0 second.
+I suggest that it is appropriate to resume a discussion of measures to
+circumvent the difficulties brought about by these large delay
+characteristics. Some areas of discussion could be: buffer sizes in
+servers and users, echo plex techniques, moving part of the input
+processing to the user system.  If it is decided to move the echo plex
+functions to the user system, it would be wise to try for a "standard"
+package, thus reducing a M times N problem to a M plus N problem.
+Please dig out and read RFC's #1 Crocker, #5 Rulifson, #51 Elie to see
+some previous thinking about this type of problem.
+
+       [ This RFC was put into machine readable form for entry ]
+       [ into the online RFC archives by BBN Corp. under the   ]
+       [ direction of Alex McKenzie.                   12/96   ]
+
+
+
+
+
+                                                                [Page 1]
+