Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Comments on the RCTE Telnet option (RFC0563)

IP.com Disclosure Number: IPCOM000005394D
Original Publication Date: 1973-Aug-28
Included in the Prior Art Database: 2001-Sep-21
Document File: 6 page(s) / 11K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Davidson: AUTHOR

Abstract

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 user.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 31% of the total text.

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

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)

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 ...