From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc563.txt | 283 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) create mode 100644 doc/rfc/rfc563.txt (limited to 'doc/rfc/rfc563.txt') diff --git a/doc/rfc/rfc563.txt b/doc/rfc/rfc563.txt new file mode 100644 index 0000000..1664487 --- /dev/null +++ b/doc/rfc/rfc563.txt @@ -0,0 +1,283 @@ + + + + + + +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 + eliminated, and the human has an extra round-trip time added to the + server's processing time. This is wrong. + + + + +Davidson [Page 2] + +RFC 563 Comments on the RCTE TELNET Option 28 August 1973 + + +An Alternative Implementation + + Unless a round-trip time penalty is to be paid by the human at every + break interaction, the user TELNET must transmit characters based on + the transmission character set in effect at the moment the characters + are typed. And unless the step-by-step interaction developed in the + RCTE TENEX example was not a true representation of the relative + temporal occurances of events, RCTE did not do this. + + The sample TENEX interaction showed the user typing + + (T:) LOGIN ARPA + + while the break set included and . The only + transmission characters in effect were the break characters - by + default. The RCTE example showed that the LOGIN phrase + was, properly, a completed command; it was transmitted. But + while the alternative transmission strategy of the current RFC + would "recognize" the ARPA phrase as a second completed + command, and thus initiate a second transmission, RCTE withholds + judgment until the server respecifies the transmission classes. + Response for the user suffers. + + One might also ask what transmission strategy was to be undertaken + when two users were, say, linked thru a TENEX. Transmission + should obviously be at every character. RCTE would send the first + single character packet and then wait to be sure that a single + character did in fact delimit the next command also. It would + wait a long time it would seem, since no break interaction would + occur until the end of the line (). The user would be echoing + like a champ, but no characters would be transmitted for the + linked party's inspection. + + 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 in fact look like this: + + P: TENEX 1.31.18, TENEX EXEC 1.50.2 @ + + T: LOGIN + P: LOGIN } >>>>>> NOTE: Typing and printing occurs simul- + U: LOGIN taneously up to the at + which point the human "types-ahead." + T: ARPA + + U: ARPA < <0> + + P: AR + + S: (PASSWORD): <7> + + [the server sends while text is printing] + + P: PA (PASSWORD): + + T: WASHINGTON + + U: WASHINGTON + + T: 100 + + S: <3> + + P: 100 + + T: 0 [Again printing is + simultaneous to typing] + + P: 0 + + T: + + P: + + U: 1000 + + S: JOB ... + + The interaction will not necessarily be the same each time. It + depends on the typing speed of the user and response time of the + server. 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] did not change. + +Unsolicited Output + + The question of unsolicited output arise again. The treatment in 560 + was simplified over that of 357 only because of the RCTE transmission + strategy. No output could possibly be returning for a command which + hasn't been sent yet (!), so the message must be "SYSTEM GOING + DOWN." + + + + + +Davidson [Page 4] + +RFC 563 Comments on the RCTE TELNET Option 28 August 1973 + + + 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 such interrupts; + this clarification of the unsatisfactory solution in 357 is + appreciated. + +TIP Buffering + + RCTE as defined cannot allow a user to transmit when his buffer is + full, else he might send a break character. [presumably the buffer + fills because we are waiting for break (transmission) redefinition]. + The response to the command delimited by the break character could + return before the characters, of the command were "echoed." RCTE + would thus demand that it be printed first, and the listing would be + out of order. + + The alternative transmission strategy eliminates this problem since + transmission of a full buffer is no worse than guessing incorrectly + 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 does not 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. + + + + + + + + + + + + + + + + + + +Davidson [Page 5] + -- cgit v1.2.3