Response to NWG/RFC 346
A response on handling interactive sessions over long-delay satellite links.
Davidson, J., "Response to NWG/RFC 346", RFC 355, DOI 10.17487/RFC0355, June 1972, <https://www.rfc-editor.org/info/rfc355>.
@misc{rfc355,
series = {Request for Comments},
number = 355,
howpublished = {RFC 355},
publisher = {RFC Editor},
doi = {10.17487/RFC0355},
url = {https://www.rfc-editor.org/info/rfc355},
author = {J. Davidson},
title = {{Response to NWG/RFC 346}},
pagetotal = 3,
year = 1972,
month = jun,
} RFC text
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 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 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 ]
ISO Plain Language
On this page
§1The Satellite Delay Concern
The author says long transmission delays, such as those associated with satellite communication, concern users of remote interactive systems. The University of Hawaii expected to be linked to the ARPANET by satellite before the end of the year, making these consequences an immediate concern for the site.
The BCC 500 research group was studying buffer allocation, partitioned echoing and other problems raised in RFC 346.
A delayed response can make a remote interactive session difficult to use. Hawaii was preparing for a satellite connection and studying ways to handle that delay.
§2Partitioned Echoing in BCC 500
The BCC 500 served geographically scattered users through remote concentrators. Its design allowed a concentrator to provide local echoing when appropriate, so a character could be shown at the terminal without waiting for the central computer's response.
A character input/output microprocessor and the user's process helped decide when local echoing was appropriate. The report says these coordination methods were not directly transferable to asynchronous ARPANET messages, especially with satellite delays.
A local concentrator can echo a typed character before the distant computer responds. The RFC says coordinating that local response with the central system is a problem for network messages.
§3Where Echoing Might Be Handled
The author raises questions about whether local echoing should be handled by user TELNETs, by a TIP or by an IMP. If it were added at an IMP, the effect on a concentrator that already provides local echoing would need consideration.
The RFC says the effects on the existing network are not known and that the research group is seeking workable alternatives with the ILLIAC group at NASA-AMES. The author invites information about other work.
The RFC does not settle where local echoing should be implemented. It asks how that choice would interact with existing systems and says the group is still studying alternatives.