Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!ucbvax!MATHOM.CISCO.COM!BILLW
From: BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: LAT
Message-ID: <12653518846.15.BILLW@mathom.cisco.com>
Date: 13 Jan 91 08:14:59 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 140


    Would anyone in this forum care to comment on these claims?

Yeah, I'll comment.  A word about my background first.  Around 1983,
TCP started to be implemented, and I worked in the network group at
SRI International.  We were talking about using the network to replace
our terminal port selectors.  Bridge communications built the worlds
first commercial terminal server, but it spoke XNS, and they were not
interested (at that time) in supporting TCP.  On the other hand, they
would provide documentation so we could write our own code.  TCP was
very young in those days, and we reflected that maybe a special
purpose terminal protocol would be useful.  We didn't do anything, but
were very excited when DEC announced LAT, since it incorporated many
of the ideas we had been talking about.  Unfortunately, DEC refused to
divulge a specification for their new protocol, preferring to keep it
to themselves.  Somewhat later, I moved to Stanford University, where
all terminal access to the computers was already via the network.
Initially, this was using the Xerox PUP "Chat" protocol, but
eventually software was written for our "ethertips" was written to
support TCP.  I did the monitor modifications to TOPS20 to allow it to
support 60+ incoming telnet users and still have some cycles left.
Later, cisco Systems spun out of Stanford, taking the ethertip and
router code, and making them into commercial products.  I went to work
there, doing much work on the terminal server related software,
including adding LAT support about a year ago...


    - LAT is optimized for terminal/host connectivity on a single LAN
        "For asynchronous traffic on local networks, LAT is the best
        available technology and won't easily be supplanted by OSI's
        VT or IP's TELNET [protocols]" (Donald G. Hirsh, DEC
        Professional, February 1990).

Yes, LAT is optimized for terminal host connectivity, but most of those
optimizations are sort of pointless.  The biggest "optimzation" is probably
the ability to put traffic from/to multiple users in a single packet.  In
reality, I doubt whether this happen much - for output to a terminal, a
user could really use a whole packet's worth of data, and for input from
the terminal, even the ~60 ms "slot" times used by LAT don't usually
result in data from more than one used in a packet.

The lack of a network layer might be considered an optimization, but this
"single LAN" that it allows is a fast-vanishing beast.  The fact that it
cannot operate over a complex or Wide-area network is a SERIOUS limitation
of LAT.  Cisco recently announced a "protocol translator" that can convert
between LAT and X25 PAD calls, and offered this to a customer as a solution
for getting LAT across an X.25 network (what they wanted was bridging over
X.25).  Somewhat reluctantly, the customer was willing to test an arrangement
that looked like:

	   LAT        PAD                                 PAD      LAT
  [LAT TS]=======[PT]----[X25 Sw]----[x25 Net]----[X25 Sw]----[PT]======[VMS]
	   ether     1Mb         56kb         56kb        1Mb      Ether

They measured echo delays, and watched the X.25 network loading.  They (and
even I) were surprised when this arrangment resulted in signifcantly BETTER
response times than a solution that did bridge over X.25.  Loading of the
X.25 network was also very much less.

On the other hand, the conclusion that LAT will not easilly be replaced by
Telnet or VTP is quite true.  For one thing, LAT does have several real
(as opposed to theoretical) advantages:

    1) most existing LAT implementations are more efficient that the
	existing telnet implementations.  Sad, but true.

    2) LAT was designed with a specific OS in mind, and supports the
	concepts of that OS better than telnet, which is more general.
	For example, host control of "local flow control" and data
	transparency are clearly defined in LAT, while the flow control
	option has only recently been added to telnet, and is not widely
	available to users.

    3) There is an enormous installed base of LAT.  LAT comes free with
	each DEC computer, while adding IP tends to cost someting.  DEC
	was the first company to push the network as a way of connecting
	terminals to their computers (for which they deserve quite a bit
	of credit), and is \the/ market leader in terminal server sales
	(in spite of the fact that their terminal servers are expensive
	and feature-poor compared to many of their competitors.)

On the other hand, it is equally unlikely that LAT will replace Telnet, or
prevent VTP from being deployed.  For one thing, DEC wants license fees
for LAT implementations, and royalties for each line of LAT terminal servers.


    - LAT causes less of a burden on the CPU and the network 
        "In preliminary test using KI Research's KiNet, DR Labs found
        the DEC's LAT protocol imposed lower overhead on both the host
        CPU and the network than TELNET.  For example, with 45 active
        TELNET session on a Mips M/120-5 system, the CPU had zero
        percent idle time, meaning that it was overload, and only 4.4
        percent of the network bandwidth was utilized. With 64 active
        LAT sessions to the same machine, the CPU was still 50 percent
        idle, and only 2 percent of the network bandwidth was
        utilized. This difference is due in large part to the fact
        that LAT does not use the full DECnet stack, whereas TELNET
        uses the full TCP/IP stack." (Lee Schlesinger, Digitial
        Review, August 27, 1990)

I suspect that most of this is related to the implementations, rather
than the protocols themselves.  As someone has already mentioned, the
usual unix telnetd implementation of telnet is a performance nightmare
due to its excessive context switching.  Many telnet terminal servers
negotiate very small (and non-optimal) packet and tcp window sizes in
an attempt to save memory and/or provide quicker response to interrupt
characters.  Many unix TCPs are not up to the current "state-of-the-art"
in TCP performance issues.

Of course, this is all accademic, since for the end users "the
implementation is the protocol" or some such.  On the other hand, this
is an essentially accademic forum, so we can talk theory.


    >I can't comment from a technical point of view, but from a real-world
    >user's point of view, LAT has one distinct advantage - it handles
    >buffering in a non-annoying way.  Control-C's are have very little
    >latency as compared to TELNET.

    Be careful to distinguish between the protocol and the implementations.

Henry is exactly correct.  This is entirely an implementation issue.
cisco's implementation of telnet has always been "correct", but other
implementation details caused our handling of interrupt characters to
be slower than a lot of people would like.  Under pressure from customers,
we were finally able to make our telnet flush output essentially as quickly
as desired (without using small windows or packets, and without any local
handling of interrupt characters).  It does require that the other end
also handle telnet correctly.


In summary, there is no particularly good reason why LAT should work
better or be a more popular soution for connecting terminals to
computers, but currently it does, and it is, and it's likely to remain
that way for a very long time, mostly because comercial pressures have
made it a more user-tuned product.  And that's important.

Bill Westfield
cisco Systems.
-------