RFC346 - Satellite Considerations

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

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 RFCwas put into machine readable form for entry ]

[ into the online RFCarchives by BBN Corp. under the ]

[ direction of Alex McKenzie. 12/96 ]

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
© 2005- 王朝網路 版權所有 導航