Satellite Considerations
A 1972 warning that satellite links would add large delay to the ARPANET and strain interactive use.
Postel, J., "Satellite Considerations", RFC 346, DOI 10.17487/RFC0346, May 1972, <https://www.rfc-editor.org/info/rfc346>.
@misc{rfc346,
series = {Request for Comments},
number = 346,
howpublished = {RFC 346},
publisher = {RFC Editor},
doi = {10.17487/RFC0346},
url = {https://www.rfc-editor.org/info/rfc346},
author = {J. Postel},
title = {{Satellite Considerations}},
pagetotal = 1,
year = 1972,
month = may,
} RFC text
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 ]
AI ELI5
On this page
§1How Much Delay a Satellite Adds
A satellite path will not necessarily change the transmission rate, but it will change the delay. The RFC approximates the change by path length. A synchronous-orbit satellite is about 22,000 miles above the earth, so the path is about 44,000 miles, compared with 3,000 miles in the worst surface case. That is about a 15 to 1 increase in path length and delay.
For light, 3,000 miles takes .016 seconds and 44,000 miles takes .236 seconds.
Going to space and back is a much longer trip than staying on the ground, so everything arrives later, even if it travels just as fast.
§2Echo and Buffer Problems
In the surface ARPANET of the time, delays already make interactive servers with character-at-a-time remote echo only marginally useful. The author believes this delay (unmeasured) is largely due to the host systems. Adding a half second of transmission delay would make these marginal systems unusable.
Buffers are the second concern. If a receiving system buffers only one line of text and refreshes the allocation as each line is output to a human user, there will be at least a half second delay between lines arriving. That need not be a problem until the output device is above about 150 characters/second, but host delays are estimated at 0.1 second to 1.0 second, so the "small buffer" problem can be expected even with slower devices.
If you must wait for a reply after every single letter you type, a long delay makes typing miserable. And a tiny mailbox that holds one letter at a time makes the sender wait too.
§3Suggested Discussion
The RFC suggests resuming discussion of ways to get around these delays. Topics could include buffer sizes in servers and users, echo plex techniques, and moving part of the input processing to the user system.
If echo functions are moved to the user system, the author advises aiming for a "standard" package, which turns an M times N problem into an M plus N problem. Readers are pointed to RFC 1 (Crocker), RFC 5 (Rulifson) and RFC 51 (Elie) for earlier thinking.
He asks everyone to think of fixes, and to agree on one shared fix so each computer does not need its own special one.