RFC 230

RFC 230: TOWARD RELIABLE OPERATION OF MINICOMPUTER-BASED TERMINALS ON A TIP 💖🎀

• Author: T. N. Pyke, Jr., NBS
• Request for Comments: 230 (NIC 7647, Reference #203)
• Date: 24 September 1971
• Category: C5
• Obsoletes / Updates: the original doesn't list either, so there's nothing to report here ✨

okay so bestie, the TIP protocol for talking to attached terminals is character-oriented and has no error control at all 😭 The people who designed it were basically assuming that most terminals would be interactive, used one character at a time going both ways, and attached to a real human who's sitting right in the communication loop 🧚 That human would spot weird errors just by watching the characters come in, and especially by checking the computer output against what they were doing.

But that safety net is kinda not it in these cases 💀

a. At a medium or higher data rate (say 1200 bps or higher), the human is probably just skimming the computer output and is not catching errors character by character anymore 🙈 Especially when both the user's input and the computer's output have numbers in them, significant errors could slip right by undetected.

b. Terminals that are far away from the TIP, connected by a private line or the switched network, may pick up more errors than a terminal that's local to the TIP (see Note 1). This gets extra real when lots of user terminals connect through telecom facilities, whether that's inside one organization or, even more likely, when users and user groups who don't need the full TIP capability hook up to a remote TIP 🌈

c. Terminals with a lot of logic in them, possibly including a minicomputer, usually mean the human is not in the direct terminal-TIP loop at all 👑 This matters a lot because both alphanumeric and full graphics terminals containing minis are getting popular rn 🔥

d. The network could be super useful for supporting minicomputers that do process control and other lab measurement stuff ✨ When you're providing software support for these minis, or pulling data off them, there's usually no human user in the loop either 🦋

e. A bunch of sites already offer a remote job entry service 💅 Those sites assume that unit record devices like card readers and line printers are just files inside a multiprogrammed system at another site. It makes sense that remote batch terminals could be attached to the network through TIPs too, and once again there would be no human in the loop between the terminal and the TIP 😭

So yeah, some error control on these kinds of terminal loops would be lowkey necessary, and it might also be a good idea to allow block-oriented data transmission. That's especially true for terminals of types (d) and (e), and maybe (c) too 🍓 It's possible that block error control could be layered right on top of the current TIP-terminal protocol. Data blocks, including the error control and block delimiting info, could be multiples of a single character long 🎀 The channel still wouldn't be as fully used as conventional synchronous block communication, since every character would still need its start and stop bits sent. That loss isn't huge, though, and it already happens today at 2000 bps TIP-terminal communication 💜

There are at least two ways to build a protocol like this on top of the existing TIP-terminal one. In both cases, the remote terminal would have to handle both originating and receiving the error and block control procedures 🫶

a. You could add to TIP software so the controlled loop ends in the TIP. That way, error control happens only where it's most needed, between the TIP and the terminal ✨ The catch is that this means extra TIP software plus a block buffering capability, which might put too much load on the TIP 💀

b. The other end of the block transmission error control loop could sit in the serving host system, either in an applications program or in system support software 🦋

If the remote end of the block transmission error control loop is in the serving host, that same software could maybe be used for host-to-host, end-to-end error control, on top of the host-host-terminal end-to-end error control 👑 For host-to-host communication, though, there'd be a slight loss in efficiency because of the embedded character-oriented format, unless there were an option where start/stop bits weren't required 🙈

Note 1: The most recent published data on the data transmission error performance of the switched telecommunications network is in the 1969-70 Connection Survey run by Bell Laboratories 📊 The results were published in The Bell System Technical Journal, Vol. 4, No. 50, April 1971. In this survey, 12 receiving and 92 transmitting sites in the U.S. and Canada were used, with standard Bell System Dataphone datasets at both ends. At both 1200 and 2000 bps, about 82% of the calls had error rates of 1 error in 10^5 bits or better, assuming an equal number of short, medium, and long hauls 🌸

For low-speed, start/stop data transmission at rates up to 300 bps, the survey showed a character error rate of 1 error in 10^4 characters or better on 77.6% of all calls made in the survey. Also iconic: only 48.3% of the low-speed data tests were error-free 😭 These tests were nominally 40 minutes long.

For voice grade private line data channels, the Bell System technical reference, "Transmission Specifications for Voice Grade Private Line Data Channels," dated March 1969, reports "When a Bell System dataset is combined with the recommended channel, the expected long term average error rate of the system is 1 error in 10^5 bits or better during normal transmission conditions. " ✨

[ 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   ]