RFC 563

Comments on the RCTE TELNET Option 🎀

RFC 563 💖 Written by J. Davidson from the University of Hawaii, NIC 18775, dated 28 August 1973. It references RFC 357 and RFC 560. The header doesn't name a category or status, and it doesn't list anything it obsoletes or updates. Okay so, now let's get into it! ✨

RFC 560 is all about a Remote Controlled Transmission and Echoing TELNET option 🦋. Its authors set up a framework where a serving host can control two things about TELNET communication over the (simplex) user-to-server path 💅.

• Commands are introduced that govern:
  1. when (and which) characters shall be echoed by the user, and
  2. when (and which) characters shall be transmitted by the user.

The reasons for the option came down to two things 🌸:

1. The lag between hitting a key and seeing the character that's supposed to be echoed by a remote server is disconcerting to the human typist 😭, and
2. character-at-a-time transmission causes processing inefficiencies (for IMPS, for servers, for users) and lowers effective channel thruputs over the net 💀.

The author thinks the RCTE description is wrong (or at least unclear [1]) about when characters are to be transmitted 🙈. The thing is, the RCTE spec doesn't really cover this topic fully, so it's hard to point at one line and say "that's the wrong one" 🥲. So these objections are based on inferences drawn from the sample TENEX interaction. Maybe there's just some misunderstanding of the original issues that RCTE is trying to solve 🧚.

Original Motivation for Remote Controlled Echoing (RCE) 🍓

RFC 357 (An Echoing Strategy for Satellite Links) brought up the need for RCE for users who are separated from a service host by a satellite link ✨. The whole point was to lessen human frustration and confusion 😤. Processing inefficiencies and channel thruputs weren't considered at all 🤷‍♀️.

(For the rest of this RFC, we're looking at character transmission separately from echoing considerations 💜.)

Here's the vibe: the human's best interests were served if user-to-server transmission happened character by character 🫶. The assumption was that this got the server responding as fast as possible. It allowed the classic overlap of (network) I/O and computation, so it was efficient as far as the (human) user was concerned 👑.

Then they made some concessions on the transmission strategy, because the serving process can't really do any significant processing until a completed command is available 😩. Ideally, users should be able to buffer characters until they have a completed command, then fire off the entire command in one "packet," which saves channel usage and gives better per-packet data efficiency 🔥. The characters that delimit commands were called wakeup characters in 357, because of what they do for the serving process. RCTE calls them transmission characters, for the effect they have at the User TELNET 🌈.

The key here is that a human separated from their remote host by a satellite link can type several completed commands, which means several packet transmissions, all while waiting for the server's response to the first command 🏃‍♀️💨. That's the I/O and computation overlap again, and once more it's maximum efficiency from the human's viewpoint ⭐.

The problem is that wakeup (transmission) character sets change 😬. There's always going to be a finite amount of time (the one-way transmission time) when the set definitions differ between server and user ⏳. So during that window, the user will either send packets that don't contain completed commands, or contain more than one completed command, or buffer characters past the end of a completed command 🙃. (A fourth option is that they're doing the right thing by pure luck 🍀.) Buffering past the end of a command is the only case that hurts processing efficiency for the human, though 💅.

Dissatisfaction With RCTE 😤

Here's the author's complaint: RCTE, at least in the sample interaction that only allowed transmission (by default) at break characters, would have the TELNET user wait until they know exactly which wakeup (transmission) character set the server is using! 🛑 Ideal channel utilization might be achieved, since no "unnecessary" packets go out (and, strangely, no extra characters are allowed in the current packet) 🤔. But the overlap of I/O and computation is gone, and the human ends up with an extra round-trip time on top of the server's processing time. This is wrong. 💔

An Alternative Implementation 🦋

Unless the human pays a round-trip time penalty at every break interaction, the user TELNET has to transmit characters based on the transmission character set in effect at the moment the characters are typed 🎯. And unless the step-by-step interaction in the RCTE TENEX example isn't a true picture of the relative timing of events, RCTE didn't do this 🙅‍♀️.

The sample TENEX interaction showed the user typing:

(T:) LOGIN ARPA <cr>

The break set included <space> and <cr>. The only transmission characters in effect were the break characters, by default 🍓. The RCTE example showed that the LOGIN <space> phrase was, properly, a completed command, so it got transmitted ✅. But the alternative transmission strategy in the current RFC would "recognize" the ARPA <cr> phrase as a second completed command and start a second transmission right away 🏎️. RCTE holds off on judgment until the server respecifies the transmission classes, and the response for the user suffers 😢.

Also, think about what transmission strategy should happen when two users are, say, linked through a TENEX 🧑‍🤝‍🧑. Transmission should obviously be at every character 💖. RCTE would send the first single-character packet, then wait to be sure that a single character really delimits the next command too 🫠. It would wait a long time, it seems, since no break interaction happens until the end of the line (<cr>). The user would be echoing like a champ 🏆, but no characters would get transmitted for the linked party to inspect 😭.

If we adopt the convention that transmission decisions should be based on the transmission set (and by default, the break set) in effect at the time the character is typed, then the sample interaction might actually look like this 🌈:

P:  TENEX  1.31.18,   TENEX EXEC  1.50.2  <cr> <lf>@

T:  LOGIN <space>
P:  LOGIN <space> } >>>>>> NOTE: Typing and printing occurs simul-
U:  LOGIN <space>                taneously up to the <space> at
                                 which point the human "types-ahead."
T:               ARPA <cr>

U:  ARPA <cr>             <<key: the user transmits a second packet.

S:  <space> <IAC> <SB> <RCTE> <0>

P:  <space> AR

S: <cr> <lf> (PASSWORD): <IAC> <SB> <RCTE> <7>

           [the server sends while text is printing]

P:            PA <cr> <lf> (PASSWORD):

T: WASHINGTON <space>

U:  WASHINGTON <space>

T:                    100

S:  <space> <IAC> <SB> <RCTE> <3>

P:  <space> 100

T:                             0          [Again printing is
                                           simultaneous to typing]

P:                 0

T:                              <cr>

P:                  <cr>

U:  1000 <cr>

S:  <cr> <lf> JOB ...

The interaction won't necessarily look the same every time 🙃. It depends on how fast the user types and how quickly the server responds ⚡. For this example, both channel utilization and performance for the human are perfect, since the transmission set (even though it was only the default break set) didn't change 🥰.

Unsolicited Output 📢

The question of unsolicited output comes up again 🔁. The treatment in 560 was only simplified over that of 357 because of the RCTE transmission strategy 🧠. No output could possibly be coming back for a command that hasn't been sent yet (!), so the message has to be "SYSTEM GOING DOWN." 😱

RFC 357 outlines when unsolicited output can be recognized and when it should be printed, in line with the alternate transmission scheme proposed 🦋. The requirement that such system alerts be terminated by RCTE commands is, of course, the proper way to handle these interrupts 👑. The author appreciates this clarification of the unsatisfactory solution in 357 🫶.

TIP Buffering 🧃

RCTE as defined can't let a user transmit when their buffer is full, or else they might send a break character 🫣. [Presumably the buffer fills because we're waiting for break (transmission) redefinition.] The response to the command delimited by the break character could come back before the characters of the command were "echoed" 😵. RCTE would then demand that they be printed first, and the listing would come out of order 🌀.

The alternative transmission strategy gets rid of this problem, since transmitting a full buffer is no worse than guessing wrong that the last character in the buffer is a transmission character 🎯.

A further suggestion 💡

All server-to-user echoing could be eliminated if control bytes were sent to indicate which break sets should be echoed and which shouldn't 🌸.

Endnotes 📝

[1] For example: statement 2E2F doesn't properly distinguish between the "occurrence" of a break character and the "occurrence" of a Transmission character. The present RFC shows that they are fundamentally different. 🔥✨