RFC 355 UNKNOWN SATELLITE · DELAYS · COMMUNICATIONS

Response to NWG/RFC 346

Solutions for handling long communication delays from satellite connections.

On rfc-editor.org ↗
PUBLISHED
June 1972
AUTHORS
J. Davidson
STREAM
Legacy
SATELLITE CONNECTION
University of Hawaii to ARPANET
DELAY TYPE
Multi-second satellite round-trip
PRIOR SYSTEM
BCC 500 distributed communication system
KEY TECHNIQUE
Partitioned echoing at concentrator
DOI
10.17487/RFC0355

RFC text

Original text · RFC Editor View on rfc-editor.org ↗
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
PROBLEMThe University of Hawaii was about to join the ARPANET via satellite link, which introduces multi-second transmission delays that make interactive computing feel sluggish and require careful buffer management.
MECHANISMHawaii's BCC 500 research group adapted concepts from their earlier distributed communication system, including partitioned echoing where local concentrators provide immediate echo feedback to terminals while coordinating with the remote host.
SATELLITE NETWORKING APPROACHThe work explored how to make interactive sessions tolerable over long-delay links and discussed whether such solutions could be incorporated into TIPs and IMPs network-wide.

§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?

§4References