1 files changed, 163 insertions, 0 deletions
diff --git a/doc/rfc/rfc355.txt b/doc/rfc/rfc355.txt
new file mode 100644
index 0000000..41e9a3c
--- /dev/null
+++ b/doc/rfc/rfc355.txt
@@ -0,0 +1,163 @@
+
+
+
+
+
+
+Network Working Group                                 John Davidson
+Request for Comments #355                             UH-ALOHA SYSTEM
+NIC # 10597                                           9 June 72
+Category:  Local Echoing, Remote Echoing, Satellite
+References:  RFC 346
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                        RESPONSE TO NWG/RFC 346
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                             John Davidson
+
+                              June 9, 1972
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 1]
+
+   Long transmission delays such as those inherent in satellite
+   communication are most certainly a cause for concern among users of
+   remote interactive systems.  Since the University of Hawaii will, by
+   the end of this year, be linked to the ARPANET via satellite, the
+   consequences of such delays are perhaps of more immediate concern to
+   us than to current members of the surface net.  Consequently the BCC
+   500 research group here has been studying various solutions to the
+   problems of buffer allocation, partitioned echoing, etc. re-introduced
+   in RFC 346.
+
+        Generally, the solutions come from extensions to the original
+   design concepts of the BCC 500 distributed communication system.  The
+   500 was designed to serve a large number of geographically-scattered
+   users each of whom accessed the central computing facility through one
+   of several remote concentrators.  [The concept is not too unlike that
+   of users at different TIPs all accessing a single host.] Since it was
+   felt that in full-duplex, character-by-character interaction, echo
+   delays of any noticeable length should not be tolerated, a facility
+   was provide whereby the concentrator could provide local (to the
+   terminal) echoing when deemed appropriate.  (A character input/output
+   microprocessor, the CHIO, in implicit conjunction with the terminal
+   user's process executing in the CPU dictated when it was appropriate.)
+   The problems associated with coordinating the concentrator and CHIO in
+   the partioning of echoing were solved for the BCC 500, but are not
+   immediately extensible to the asynchronous message transmissions of
+   the ARPANET - especially with the introduction of satellite delays.
+   As stated, we are working on some viable alternatives.
+
+        It is not known, at present, what effects the incorporation of
+   these partitioned echoing techniques might have on the existing net.
+   Perhaps local echoing will become a function of User TELNETs; most
+   certainly local echoing should be available in the TIP.  But could it
+   be incorporated into the IMP so that TIP and User TELNETs can be used
+   without change?  If so, what happens to the concentrator's local
+   echoing capability in a system such as the BCC 500?
+
+        These questions do not have immediate answers.  Other problems
+   obviously exist because of the differences in serving system
+   conventions for terminal control.  We, in conjunction with the ILLIAC
+   group at NASA-AMES, are seeking solutions to such problems in general,
+   with an eye toward their implementation
+
+
+
+
+
+
+
+
+                                                                [Page 2]
+
+   on the net.  I would appreciate hearing of any other research being
+   performed in this area, and will be happy to discuss the findings of
+   our group with any interested parties.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+         [ This RFC was put into machine readable form for entry ]
+         [ into the online RFC archives by BBN Corp. under the   ]
+         [ direction of Alex McKenzie.                      1/97 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 3]
+