Browse Prior Art Database

Satellite Considerations (RFC0346)

IP.com Disclosure Number: IPCOM000003536D
Original Publication Date: 1972-May-30
Included in the Prior Art Database: 2000-Sep-13
Document File: 1 page(s) / 3K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Postel: AUTHOR

Abstract

Satellite Considerations

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 100% of the total 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 ]