Response to NWG/RFC 346
Solutions for handling long communication delays from satellite connections.
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 ]
AI ELI5
On this page
§1The Satellite Delay Problem
RFC 355 is a response to RFC 346, which discussed satellite communication delays on the ARPANET. The University of Hawaii was preparing to join the network via satellite, which introduces delays of several seconds for round-trip communication—far longer than the millisecond delays of terrestrial links.
For interactive computing, such delays are a serious usability problem. When a user types a character, they expect immediate feedback (an echo) on their terminal. With a satellite link, they would see a delay of seconds between typing and feedback. The BCC 500 research group at Hawaii had been studying solutions to this problem, drawing on their experience with a distributed communication system that served geographically scattered users.
Messages sent through space satellites take a long time to go up and come back down. Users waiting for an echo of what they type will feel very frustrated, so Hawaii's team thought hard about solutions.
§2Partitioned Echoing and Buffer Allocation
The BCC 500 system, designed to serve users at remote concentrators accessing a central computer, implemented partitioned echoing. Local terminals get echo feedback from a character input/output microprocessor (CHIO) at the concentrator, making the echo appear instantaneous to the user. Meanwhile, the actual processing happens at the central CPU, which communicates asynchronously with the concentrator.
For the ARPANET, this approach means a local Telnet or TIP at Hawaii could provide immediate echo, while actual data flows to and from mainland hosts over the satellite link. The challenge is coordinating between local echoing and remote processing to avoid duplicates, garbled output, or lost commands.
The BCC 500 solved this coordination at the concentrator and CPU level, but extending the approach to the asynchronous message-based ARPANET, especially with satellite delays, requires new thinking. Hawaii was also coordinating with the ILLIAC group at NASA-AMES on how to handle differences in terminal control conventions across different systems.
Instead of waiting for an echo from far away, the local computer echoes immediately, then sends the real command later. It's like talking to a friend through a very slow echo chamber—you hear yourself right away, then later get the answer.
§3Open Questions
The response raises important architectural questions. Could partitioned echoing be a function of User TELNETs or the TIP itself, rather than a special feature of Hawaii's system? Could it even be incorporated into the IMP layer so all systems could benefit? If so, how would it interact with existing concentrator systems like the BCC 500 that already do local echoing?
Different hosts use different terminal control conventions, and resolving conflicts between these systems is another challenge. Davidson invited feedback from the ARPANET community and expressed willingness to share Hawaii's research findings with other sites and coordinate with research groups like ILLIAC on solving these broader networking problems.
Hawaii asked big questions: Should every computer do this? Can the network itself help? How do we make sure different computers all play nicely together?