Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!HOGG.CC.UOREGON.EDU!jqj From: jqj@HOGG.CC.UOREGON.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: telnet... Message-ID: <8807071618.AA07824@hogg.cc.uoregon.edu> Date: 7 Jul 88 16:18:34 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 29 >From: braden@venera.isi.edu >There are Telnet controls (eg IP, AO, AYT...) that can appear at any time >in the stream, and a correct implementation must check for them. An >implementation that does not is not implementing the Telnet protocol >(RFC-764). This is precisely Bill's point. He argues that in some applications the higher level protocol knows that it will never generate or listen to such controls after a particular point in the session, and therefore could improve efficiency by saying "don't bother to check any more", but can't unless the Telnet protocol definition were changed. This seems to me to be one of many possible negotiable "performance options". One might also have negotiations that specified typical chunk sizes for transmissions (e.g. size of the Unix write() buffer. In no way related to MSS or anything like that, obviously) -- useful in helping the receiver do buffer management, expected average data rate, expected connection lifetime, ad nauseum. I don't believe that Telnet should implement any such negotiations because I see them all as minor performance tuning that greatly complicates the protocol. But I do think they should be considered as a group since they all share the characteristic that the applications protocol knows something about the stream traffic pattern that doesn't help the TCP level very much, but might help the remote applications level. Now, a LAT-like protocol that multiplexed several virtual terminal sessions (perhaps several telnet streams?) on a single sequenced packet protocol connection. THAT would be something to more seriously investigate as a standardized performance enhancement for connecting IP terminal servers to hosts.