Comments on the RCTE Telnet option(1)

　　Network Working Group J. Davidson

　　Request for Comments: 563 University of Hawaii

　　NIC: 18775 28 August 1973

　　References: RFC357, RFC560

　　Comments on the RCTE TELNETOption

　　RFC560 describes a Remote Controlled Transmission and Echoing TELNET　option. Its authors provide a framework wherein a serving host may　control two aspects of TELNET communication over the (simplex) user-to-server path.

　　Commands are introduced which govern

　　1. when (and which) characters shall be echoed by the user, and

　　2. when (and which) characters shall be transmitted by the　user.

　　Motivation for the option was based on two considerations:

　　1. the latency between striking and printing of a character　which is to be echoed by a remote server is disconcerting to　the human typist, and

　　2. character-at-a-time transmission introduces processing　inefficiencies (for IMPS, for servers, for users) and　decreases effective channel thruputs over the net.

　　The author feels that the RCTE description is in error (or at least　unclear [1]) in its treatment of when characters are to be　transmitted. However, discussion of the subject in the RCTE　specification is incomplete, so it is difficult to point to a　statement which is "wrong." Rather, the present objections are based　on inferences drawn from the sample TENEX interaction　Perhaps there is some misunderstanding of the original issues to　which RCTE now addresses itself.

　　Original Motivation for Remote Controlled Echoing (RCE)

　　RFC357(An Echoing Strategy for Satellite Links) introduced a need　for RCE for users who are separated from a service host by a　satellite link. The motivation was to lessen human frustration and　confusion; no consideration was given to resulting processing　inefficiencies or channel thruputs.

　　(In the remainder of this RFC, we consider character transmission　apart from echoing considerations.)

　　It was recognized that the human's best interests could be served if　user-to-server transmission were performed on a character-by-character basis, (the implicit assumption being that this insured　the most rapid server response possible). This scheme allowed for　the classic overlap of (network) I/O and computation, and was thus　efficient as far as the (human) user was concerned.

　　Concessions were made in the transmission strategy when it was　accepted that the serving process could not in fact do any　significant processing until a completed command was available.

　　Ideally then, users should be able to buffer characters until they　have a completed command and then fire off the entire command in a　single "packet," with the resultant savings in channel usage and a　greater per-packet data efficiency. The characters which delimited　commands were called wakeup characters, in 357, for their effect on　the serving process. RCTE calls them transmission characters for the　effect they have at the User TELNET.

　　The key here is that it is quite possible for a human, separated by　a satellite link from his remote host, to type several completed　commands - and to therefore initiate several packet transmissions-all the while awaiting the server's response to his first command.

　　Again we see the overlap of I/O and computation, and again we　achieve maximum efficiency from the human's viewpoint.

　　The problem, however, is that wakeup (transmission) character sets　change. And there will always be a finite amount of time [the one-way transmission time] during which the set definitions will differ　between server and user. This says that during such times the user　will be sending off packets which do not contain completed commands,　(or contain more than a single completed command), or he will be　buffering characters beyond the end of a completed command. (A　fourth alternative is that he may actually still be doing the right　thing by chance). Buffering beyond the end of a command is the only　case which lessens processing efficiency for the human, however.

　　Dissatisfaction With RCTE

　　Here is the author's complaint: RCTE [at least the sample　interaction which allowed transmission (by default) only at break　characters] would have the TELNET user wait until he knows exactly　the wakeup (transmission) character set being used by the server !