Comments on the RCTE Telnet option (RFC0563)
Original Publication Date: 1973-Aug-28
Included in the Prior Art Database: 2001-Sep-21
Internet Society Requests For Comment (RFCs)
AbstractRFC 560 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.
Network Working Group J. Davidson Request for Comments: 563 University of Hawaii NIC: 18775 28 August 1973 References: RFC 357, RFC 560
Comments on the RCTE TELNET Option
RFC 560 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
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 ) 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)
RFC 357 (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.)
Davidson [Page 1]
RFC 563 Comments on the RCTE TELNET Option 28 August 1973
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 lin...