Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!UNET.UNET.UMN.EDU!fin
From: fin@UNET.UNET.UMN.EDU ("Craig A. Finseth")
Newsgroups: comp.protocols.tcp-ip
Subject: LAT vs telnet
Message-ID: <9105021618.AA19055@unet.unet.umn.edu>
Date: 2 May 91 16:18:20 GMT
References: <1991May2.012159.23962@megadata.mega.oz.au>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 45


   I read in UnixWorld about various arguments concerning the
   pros and cons of LAT as opposed to telnet, with the main
   argument for LAT being it is a LOCAL transport protocol designed
	...
   It strikes me that the fundamental idea of LAT is sound, and it makes
   good sense to lower the host overhead for local terminals (especially
   when we talk about larger scale commercial sites running data entry etc.).
	...
   My real question is: If the concept of LAT is good enough, and the
   advantages great enough, why doesn't someone define a protocol that
   does the same job, but is part of TCP/IP; in other words a local telnet
   protocol. I guess the biggest problem (as with some many other protocols)
   is that LAT got there first, and no one is going to support any MORE
   terminal protocols; but if an RFC was written, and an implementation
   done, and the bugs ironed out....

Actually, I balk at the concept of LAT.  In the "olden days" (i.e.,
2-4 years ago), a campus would be a (possibly) bridged Ethernet.
These days, it may well be a heavily routed network, incorporationg
Ethernet, token ring, FDDI, and other transmission paths.

For example, there is a department on my campus that is currently
using LAT quite nicely to communicate on a single Ethernet segment.
They were just told that half of their operation would move.  The new
location is 4 router hops away from the old (yes, it is still the same
campus: total distance is about 1/2 mile).  We are trying to help the
user salvage as much equipment as possible for use in the new
environment.

The problem is that LAT are designed assuming that (1) networks are
small (tiny) and (2) host cycles are of major importance.  These days,
networks are very large and host cyles are not terribly important.

In particular, LAT gains most of its benefits only when the local
users are using terminals to local mainframes.  It is of little
benefit when the user has a computer (PC, Mac, etc.), when the user is
using non-terminal protocols (FTP, NFS, etc.), or when the user is
making remote connections ("remote" = "off the floor").

Craig A. Finseth			fin@unet.umn.edu [CAF13]
University Networking Services		+1 612 624 3375 desk
University of Minnesota			+1 612 625 0006 problems
130 Lind Hall, 207 Church St SE		+1 612 626 1002 FAX
Minneapolis MN 55455-0134, U.S.A.