Comments on the RCTE Telnet option
RFC 563

Document Type RFC - Unknown (August 1973; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 563 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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 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 !
   Ideal channel utilization might be achieved,  since no "unnecessary"
   packets are sent (and, strangely, no extra characters are allowed in
   the current packet) but the overlap of I/O and computation has been
Show full document text