Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!SCIENCE.UTAH.EDU!Willett From: Willett@SCIENCE.UTAH.EDU (Lon Willett) Newsgroups: comp.protocols.tcp-ip Subject: Re: telnet SUPRESS-TELNET option... Message-ID: <12414589612.8.OP.WILLETT@SCIENCE.UTAH.EDU> Date: 15 Jul 88 21:37:30 GMT References: <12413914739.7.BILLW@MATHOM.CISCO.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 82 William Westfieldproposes 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) -------