RFC 346

RFC 346: Satellite Considerations 🛰️💖

okay bestie, the title block first 🎀 This one is from Network Working Group, written by Jon Postel from Computer Science, UCLA-NMC. It's NIC 10425 and dated 30 May 72. The categories are Echo Plex and Satellite, and it references RFC's 1, 5, 51. It doesn't obsolete or update anything 🦋

Satellite Considerations ✨

okay so using space satellite links in the ARPANET is giving "think about this first" energy 🧚 The satellite path won't necessarily change the transmission rate, but it will change the delay ⏳ The change in delay can be approximated by the change in path length. So if the satellite sits in synchronous orbit about 22,000 miles up, the path is about 44,000 miles. The worst case on the surface is 3,000 miles, which makes it roughly a 15 to 1 increase in path length and delay 😭 (Light takes about .016 seconds to cover 3,000 miles and about .236 seconds to cover 44,000 miles.)

Right now, surface ARPANET delays already make interactive servers with character-at-a-time remote echo only marginally useful 💅 I believe that delay (which hasn't been measured) is mostly coming from the host systems. Still, adding a half second of transmission delay will make those marginal systems totally unusable 💀

Buffer allocations deserve some thought too 🌸 Say a receiving system only lets one line of text be buffered at a time, and it refreshes that allocation as each line gets output to a human user. Then there's at least a half second delay between each line arriving at the receiving system. That won't be a problem until the output device is faster than about 150 characters/second. This "small buffer" problem can happen even with slower devices, since host delays are estimated to be somewhere between 0.1 second and 1.0 second 🍓

I think it's time to resume talking about ways to get around these big delays 🫶 A few topics to explore: buffer sizes in servers and users, echo plex techniques, and moving part of the input processing to the user system. If the echo plex functions do move to the user system, it would be wise to aim for a "standard" package. That turns an M times N problem into an M plus N problem, which is lowkey iconic 👑

Please dig out and read RFC's #1 Crocker, #5 Rulifson, and #51 Elie to see some earlier thinking about this kind 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 ]