Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!agate!ucbvax!eng.xyplex.com!rlstewart From: rlstewart@eng.xyplex.com (Bob Stewart) Newsgroups: comp.protocols.tcp-ip Subject: Re: TELNET versus LAT Message-ID: <9101221705.AA26081@xap.xyplex.com> Date: 22 Jan 91 17:05:27 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 29 > >But could a protocol be designed that had the advantages of LAT > >(multiple streams in one packet, rate limiting, etc.) that ran over a > >network protocol (such as DECnet routing without NSP), or had adaptive > >timeouts? > > Yes. The LAT protocol encompases a number of features, but the > session aggregation feature is independent of the LAT being built > directly on the datalink layer of Ethernet. To run LAT over a typical routing layer breaks two of LATs implicit assumptions: the consistent timing and low message loss of a LAN. LAT was carefully designed to take significant advantage of fast LAN characteristics. Specifically, it transmits data based on a collection timer, driven by the connection initiator (terminal server), and expecting a quick, reliable reply from the other end. Although lost or slow messages will not cause LAT to operate incorrectly, they will cause it to operate inefficiently. The typical example of such problems is LAT running over a remote bridge, which introduces the propagation delay, and maybe the variable timing and loss, of a network layer. LAT is a good protocol within its design constraints. When you change those constraints, you end up with something little different from Telnet over TCP. You can optimize the number of messages in the latter case, by using holddown timers, for example. Or in the case of a proprietary protocol I know, holding down level 4 messages a bit and concatenating them at level 3 if they have the same destination. Such approaches pick up some LAT efficiencies, but you can't optimize away the inherant weaknesses of the underlying layers. Bob