Re: telnet SUPRESS-TELNET option...


Lon Willett (Willett@SCIENCE.UTAH.EDU)
Fri 15 Jul 88 15:37:30-MDT


William Westfield <BILLW@MATHOM.CISCO.COM> proposes a SUPPRESS-TELNET
option as follows:

> DO SUPPRESS-TELNET requests that the receiver no longer use the telnet
> protocol.
>
> WILL SUPPRESS-TELNET offers to no longer use the telnet protocol.
>
> DON'T SUPPRESS-TELNET demands that the receiver continue to use telnet.
>
> WONT SUPPRESS-TELNET demand to continue using the telnet protocol.
>
>The only strangeness is that once the option is successfully negotiated,
>there is no way for it to be turned off.

There is another strangeness here: it is (almost) impossible to turn off
TELNET protocol in both directions, since once it has been negotiated in
the one direction, negotiation can't be completed the other one (The
exception to this isn't worth mentioning). The correct strategy is to
turn it off in both directions once it has been negotiated in a single
direction.

He then makes a case for greatly improved efficiency, which I don't
quite buy. He writes:

>Admittedly, there are obvious improvements we can make to the
>telnet process, but the fact that the obvious implementation is so bad
>points strongly to a place in the protocol where improvements can be made.

Does the necessity of checking for an IAC really account for much of the
overhead? I was under the impression that the primary overhead involved
in TELNET is the amount of network servicing that must be done. For
example, on this machine, the telnet server will receive the data,
usually a single character, wrapped in a TCP packet wrapped in an IP
packet wrapped in an ethernet packet. So the steps in processing are:

        1 -- receive the ethernet packet from the ethernet interface,
        and determine that it is meant to go to the IP driver, and turn
        it over to the IP driver.

        2 -- the IP driver determines the packet is valid (destination
        host is this one, header checksum is OK, etc), and that the
        packet is meant for the TCP driver, and turns it over to the
        TCP driver.

        3 -- the TCP driver does all its processing (sequencing,
        checksum, etc.), then turns it over to the TELNET driver.

        4 -- the TELNET driver checks for IACs, etc, and (assuming it is
        not an option negotiation) passes it to the terminal driver.

        5 -- the terminal driver does its stuff.

Obviously, it is preferable to do all this with no process context
switches. But as long as the TELNET user process sends data one (or a
few) character(s) at a time, it seems like it will be very inefficient.
All the TCP sequencing, IP processing, and calculations of 2 checksums
would seem to dwarf the time spent scanning for IACs.

So yes, the protocol has flaws. The main one is that TCP/IP (or any
protocol which is based on sending fairly large, complex packets) is not
a good way to handle terminal I/O. The *right* way to deal with this is
to do the editting locally, so that the data can be sent a block at a
time, instead of a character at a time. Look at the plethora of TELNET
options designed to do just that.

Finally:
>The suggestion has nothing to do with integrating telnet into the
>local terminal driver. However, one of the spinoff features of the
>option would be that this would become much easier. (A program could
>do the initial option negotiation, and then just "attach" the tcp
>connection to the terminal driver. The terminal driver would no
>longer have to know anything about the telnet protocol.)

True, this option would make it easier to integrate the SUPPRESS-TELNET
TELNET processing into the terminal driver. This strikes me as being
the major justification which could be given for such an option. But as
long as your terminal driver is being modified to handle a TCP
connection at all, it seems that it wouldn't be difficult to also
include a simple minded TELNET implementation.

--Lon Willett (Willett@Science.Utah.Edu)
-------



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:42:51 GMT