andrew@megadata.mega.oz.au (Andrew McRae) (05/02/91)
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 to achieve less host load, less network load and overall a much better protocol for connecting terminals to a host on a local net. Various analyses have been seen on the net that attempt to quantify the telnet overhead compared to LAT overhead, and it seems a valid point is made (that telnet overhead is excessive for what it does). Telnet of course is a TCP based protocol and so can be routed through gateways etc. which LAT can't be (though lots of people talk about bridging LAT). 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.). What people balk at is perhaps not the concept of LAT, but the fact that it is a proprietary protocol, and while DEC licences LAT to others, it is still not openly available i.e. lots of strings ($$) attached. 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.... Has anyone attempted to define or build a public domain LAT-style local terminal protocol? If DEC would loosen up on LAT, that would solve the problem, but is that likely? Just wondering... Andrew McRae (andrew@megadata.mega.oz.au) Megadata Pty Ltd., North Ryde, Sydney, Australia.
willis@cs.tamu.edu (Willis Marti) (05/02/91)
Andrew McRae (andrew@megadata.mega.oz.au) writes:
[summarized]
1. LAT has less overhead than TCP, and is more efficient for local terminal
traffic.
2. LAT doesn't work through routers, but so what.
3. LAT is DEC proprietary, and is not really readily available.
4. Why doesn't someone do a lightweight termianl protocol?
In response, all I'd point out is that LAT-like protocols make building
general purpose wide area networks or any size internetwork a problem.
Somewhere, we have to figure out that a user wants a distant site *and* it's
for terminal traffic *and* it has to be handled different from most all the
other site to site traffic. And when we build mixed protocol sites, we
can't just route, but have to make allowances for LAT traffic. So DEC
pushes FDDI bridges (instead of routers).
One can always make things simpler by restricting the areas your solution
covers. But the real world generally provides you with more than toy
problems.
Cheers,
-------------------------------------------------------------------------------
Willis F. Marti Internet: willis@cs.tamu.edu
Director, Computer Services Group, Dept of Computer Science, Texas A&M Univ.
---Not an official document of Texas A&M---fin@UNET.UNET.UMN.EDU ("Craig A. Finseth") (05/02/91)
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.lstowell@pyrnova.pyramid.com (Lon Stowell) (05/03/91)
In article <1991May2.012159.23962@megadata.mega.oz.au> andrew@megadata.mega.oz.au (Andrew McRae) writes: > >Has anyone attempted to define or build a public domain LAT-style >local terminal protocol? If DEC would loosen up on LAT, that would >solve the problem, but is that likely? > How about just adding a block or full screen mode option to Telnet? tn3270 is somewhat what I mean, but not quite. User input would be edited, parsed, etc. at the entry point, then forwarded into the network only when an Enter key is pressed...or a Function key. Unfortunately then you would have to teach all the Unix programmers how to deal with REAL terminals rather than keystrokes.. >:-) No real reason why this would be a local terminal only, a decent "routable" block mode terminal transport would do a lot to reduce LAN/WAN congestion. (Yeah, I know, put 3270 datastreams in IP packets....blechhh.)
jbvb@FTP.COM (James B. Van Bokkelen) (05/03/91)
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....
LAT as a protocol is really bare-bones. It uses the Ethernet FCS as
its only error control, it is absolutely dependent on the network not
re-sequencing packets, it assumes the round-trip-time is bounded at a
rather small high limit, and, like most other DECNet family protocols,
it is tied to Ethernet multicast concepts (which don't map well to 802.5,
for instance).
If you were to do a lightweight remote login protocol as "part of TCP/IP",
you'd necessarily use IP packets, and IP addresses. NETBIOS over TCP/IP
provides us with a lesson here: even though the NETBIOS namespace is
designed around "broadcast on a single LAN", people wanted the IP version
to go through routers, span the globe on lossy, badly-behaved networks
and generally leap tall buildings in a single bound. If you want flow
control, end-to-end error detection, protection against resequencing and
packet loss, and adaptive timeouts, you're going to either use TCP for
your "lightweight" protocol or re-invent it. Not very lightweight, then...
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901john@loverso.leom.ma.us (John Robert LoVerso) (05/03/91)
Don't be give in so easily to those harping LAT as the savior for terminal connectivity. The "expensive" TCP and TELNET protocols only exist in old or poor implementations. In particular, the usually sited "excessive overhead" of TELNET is nothing more than the result of user-level character swtiching in the 4BSD UNIX implemention of telnetd. Changing this design flaw drops almost all the overhead of a TELNET connection such that a typical UNIX host could have 3-4 times as many incoming TELNET connections and still end up with additional free CPU cycles. How do I know? I've tested it!!! (see below) A kludge to the telnetd socket/pty character switching problem was put together back in 1985 or so. The context diffs (from 4.2BSD) are readily available and apply to almost any 4BSD-based OS. Several UNIX vendors actually use the scheme in their product. The correct way to solve the telnetd problem is to re-architecture the means in which ptys and network connections mesh to avoid having a user-space character switch. One such approach involves having both STREAMS-based tty and network code. In this case, a psuedo-terminal STREAMS module just gets pushed on top of the STREAMS stack of the network connection. I know of at least one UNIX vendor doing so already. Mike Karels has said that such a scheme (using bstreams) is in the future for 4BSD. To see the test results yourself, ftp to xylogics.com and grab the files "news.article" and "results.ps.Z" from the directory "annex/unsupported/in-kernel". John -- John Robert LoVerso <john@loverso.leom.ma.us> John & Sue's House, Leominster MA [to reach the corporate puppet: loverso@syn.westford.ccur.com]
apb@kernel.co.uk (Andy Brown) (05/03/91)
> Date: 2 May 91 01:21:59 GMT > From: andrew%megadata%dmssyd.syd.dms.cSIRO.au%metro%munnari.oz.au%uunet.uu.net@ukc.ac.uk (Andrew McRae) > Organization: Megadata P/L, North Ryde, Sydney, Aust. > Original-Sender: tcp-ip-relay@mil.ddn.nic > Original-Sender: tcp-ip-request@uk.ac.nsfnet-relay > Sender: tcp-ip-request@ulai.uucp > Resent-Date: Fri, 03 May 91 09:35:03 +0100 > > I read in UnixWorld about various arguments concerning the > pros and cons of LAT as opposed to telnet, with the main [ stuff deleted ] > 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. [ more stuff deleted ] > Just wondering... > > Andrew McRae (andrew@megadata.mega.oz.au) > Megadata Pty Ltd., North Ryde, Sydney, Australia. > All very well. I'm not going to embark on a telnet-is-ace-LAT-is-crap type discussion. All I have to say is that to provide a "local" telnet, without the overheads of the real thing, makes the Internet Protocol redundant anyway. The IP layer is there to provide one huge worldwide (!) network, over which standard(ish) protocols can run without worrying about the underlying physical network. As soon as you try to bypass the IP layer, you start to reduce that connectivity. Extrapolated to its fullest extent, you'd end up with a Local Area FTP, Local Area SMTP....... etc. just for "efficiency"'s sake. Then to talk to the rest of us, you'd have to run the real protocols anyway. Where's the efficiency in that??? Andy Brown Kernel Technology Ltd, | email: apb@kernel.co.uk Kernel House, | janet: apb@uk.co.kernel Killingbeck Drive, | uucp: ..!ukc!kernel!apb Leeds, | LS14 6UF, | phone: (+44) 532 484844 West Yorkshire, UK | fax: (+44) 532 404164 (Did I miss something??!?)
keith@spider.co.uk (Keith Mitchell) (05/03/91)
In <1991May2.012159.23962@megadata.mega.oz.au>, Andrew McRae (andrew@megadata.mega.oz.au) writes: > 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) This has always struck me as a good idea. Some time ago there was dicussion of why rlogin was a "better" protocol than telnet. It turned out that it is no such thing, it is not the telnet *protocol* that was lacking, just most *implementations*. I believe the IETF Telnet WG has addressed most of these issues now, if not all vendors. Unfortunately, for LAT vs, Telnet, it is rather different. There are some fundamental differences in the nature of the protocols that mean LAT functionality cannot just be glued onto Telnet, as implied by lstowell@pyrnova.pyramid.com (Lon Stowell) in <154113@pyramid.pyramid.com>: > How about just adding a block or full screen mode option to > Telnet? tn3270 is somewhat what I mean, but not quite. > > User input would be edited, parsed, etc. at the entry point, > then forwarded into the network only when an Enter key is > pressed...or a Function key. I don't know much about tn3270, but I think I know enough about LAT to say you have missed the point here. It sounds to me that you are proposing something like Telnet Line Mode, i.e. buffer the input from a user up until some trigger character before forwarding it in a packet, instead of forwarding a single-charater per TCP packet. This is not really why LAT is more efficient. What makes LAT more efficient than telnet (over single LANs at least) are: - It multiplexes all the user sessions between one terminal server and host into a single virtual circuit, instead of one circuit per user. This amortises per-packet processing over many users. - There are fixed time-slots for when packets are forwarded from server to host. With Telnet these are generally variable. The other thing about LAT that is nice is the concept of "services" rather than hosts. You can have multiple services per host, or multiple hosts per service. In theory you can do this stuff using TCP/IP, in practice many implementations are not up to. To emulate this properly over TCP/IP, you would probably need to do what LAT does and multicast service advertisements. How many vendors ship IP with Multicast capability ? Other LAT pluses include service access control, and well-defined remote printing. Despite these diffculties, I still think something like this is do-able, and desirable if "we" (the Internet *open* systems people) are to fight back "them" (the properiatary DECNet, Novell, Appletalk *closed* systems people). The most common argument I hear against open systems is - "Yes, but if I buy all my kit from vendor X, it can do feature Y..." These are valid complaints, and we need to look at why our current systems can't do Y. LAT is a major case in point here. Back to <andrew@megadata.mega.oz.au>: > 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.... > > Has anyone attempted to define or build a public domain LAT-style > local terminal protocol? If DEC would loosen up on LAT, that would > solve the problem, but is that likely? I would have thought this was something our ISO friends should be looking at. I doubt that DEC are likely to put LAT into the public domain, when there are so many patents etc attached to it. I don't think VTP can do this, and I have not heard of any LAT-like open standard. The only the other procotol I know remotely like LAT is Prime's LTS, which although still proprietary, at least runs over LLC2. Keith Mitchell (postmaster) Spider Systems Ltd. Spider Systems Inc. Stanwell Street 12 New England Executive Park Edinburgh, Scotland Burlington Phone: +44 31-554 9424 MA 01803 Fax: +44 31-554 0649 +1 (617) 270-3510 keith@spider.co.uk keith%spider.co.uk@uunet.uu.net ...!uunet!ukc!spider!keith zspz01%uk.ac.ed.castle@nsfnet-relay.ac.uk
jdarcy@seqp4.ORG (Jeff d'Arcy) (05/03/91)
andrew@megadata.mega.oz.au (Andrew McRae): >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. This question probably arises from a very common misconception that LAT is part of DECnet. In fact, the DECnet equivalent of telnet is CTERM; LAT is a direct Ethernet client which just happens to coexist with DECnet but can coexist with TCP/IP just as easily. In other words, LAT is *already* a sort of local telnet protocol as much as it can be without changing its architecture in ways that would negate its advantages (such as by making it run on top of IP or any other routing protocol). -- Jeff d'Arcy, Generic MTS, Sequoia Systems Inc. <jdarcy%seqp4@m2c.org> Time flies like an arrow; fruit flies like a banana
BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) (05/04/91)
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 to achieve
less host load, less network load and overall a much better
protocol for connecting terminals to a host on a local net.
You'll be able to find many people to argue about whether the supposed
advantages of LAT actually exist. The only thing that is surely true is
that the common LAT host implementation (kernal resident in VMS) is much
more efficient than the common implementation of Telnet (process resident
in unix "telnetd"), which is not at all surprising. The implementation
details in these cases FAR outweigh the nature of the protocols. On
the other side of the connection, our experience is that terminal servers
tend to be limited by uart interrupt processing rather than by protocol
processing for either protocol.
Bill Westfield
cisco Systems.
-------lstowell@pyrnova.pyramid.com (Lon Stowell) (05/07/91)
>Andrew McRae (andrew@megadata.mega.oz.au) writes: >[summarized] >1. LAT has less overhead than TCP, and is more efficient for local terminal > traffic. Highly dependent on the implementation of IP. >2. LAT doesn't work through routers, but so what. This is a MODERN real-world protocol? Ever think about the poor guy paying the bills for the high speed links that a bridge requires compared to the savings available when routing at a higher layer? If you are rich enough to afford T-3 links, lets talk about the response time delays. Or perhaps transcontinental access, satellite circuits, etc. are not a part of modern networks? >3. LAT is DEC proprietary, and is not really readily available. Nothing wrong with a proprietary protocol...as long as it is well documented and works in a REAL network...
shane@VM.UTDALLAS.EDU (Shane Davis) (05/07/91)
Annex terminal servers can speak with Encore Multimax machines with some sort of login protocol which presumably reduces host load. This is the protocol used by the Annex "call" command. Supposedly, the Annex runs the tty drivers for the Multimax, acting as a FEP and passing data to the host only when whatever quantum of data the host desires is entirely available (e.g. a line-mode operation such as a shell command isn't passed until newline). The protocol is proprietary, like LAT, but is done via TCP/IP, unlike LAT. --Shane Davis Network Systems Software Univ. of Texas at Dallas, Academic Computer Center (214) 690-2637 shane@utdallas.edu SHANE@UTDALLAS.BITNET
mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) (05/08/91)
->Andrew McRae (andrew@megadata.mega.oz.au) writes:
->[summarized]
->2. LAT doesn't work through routers, but so what.
Works here! Must be something wrong with your router.
Merton Campbell Crockettkre@cs.mu.oz.au (Robert Elz) (05/08/91)
mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes: >->2. LAT doesn't work through routers, but so what. > Works here! Must be something wrong with your router. Are you sure? That is, are you sure you're not bridging LAT? If so, you can say 'works through a bridge' but not 'works through a router'. kre
donp@na.excelan.com (don provan) (05/08/91)
The News Manager) Nntp-Posting-Host: na Reply-To: donp@novell.com (don provan) Organization: Novell, Inc., San Jose, California References: <1991May2.012159.23962@megadata.mega.oz.au> Date: Thu, 2 May 1991 19:34:50 GMT In article <1991May2.012159.23962@megadata.mega.oz.au> andrew@megadata.mega.oz.au (Andrew McRae) writes: >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. From my point of view, networking is rapidly moving away from the primitive terminal-to-mainframe connectivity that spawned LAT. It makes little sense to develop an optimized protocol for what is now an obsolete application. When LAT was developed, DEC and its customers had a very large investment in terminal-to-mainframe technology. That made LAT economical, both finacially, because it saved money for customers by allowing them to get more mileage out of their terminals, and technologically, because there were enough terminal-to-mainframe packets flying around to allow session multiplexing optimizations. I don't think there's ever been any where near as much terminal traffic on TCP/IP networks, and there's destine to be much less in the future. Consequently, a LAT-like protocol in the TCP/IP suite wouldn't be cost effective when compared to telnet. don provan donp@novell.com
jbreeden@netcom.COM (John Breeden) (05/08/91)
In article <9105072303.AA00610@WLV.IMSD.CONTEL.COM> mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes: >->2. LAT doesn't work through routers, but so what. > > Works here! Must be something wrong with your router. > Wow, Puff The Magic Router !!! (-: I think you mean it works through a bridge (and that's prob what you've got). LAT has no network layer (it's just a MAC frame stuffed with data) and therefore has no info in the datagram that will allow routing. -- John Robert Breeden, jbreeden@netcom.com, apple!netcom!jbreeden, ATTMAIL:!jbreeden ------------------------------------------------------------------- "The nice thing about standards is that you have so many to choose from. If you don't like any of them, you just wait for next year's model."
oberman@ptavv.llnl.gov (05/08/91)
In article <9105072303.AA00610@WLV.IMSD.CONTEL.COM>, mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes: > ->Andrew McRae (andrew@megadata.mega.oz.au) writes: > ->[summarized] > > ->2. LAT doesn't work through routers, but so what. > > Works here! Must be something wrong with your router. I suspect you have one of the new generation of brouters (bridge/routers). That's what we use here. (cisco) It is configured to route selected, routable protocols like IP and DECnet and bridge any others with filters to control things in finer detail. I can state absolutely that LAT is NOT routable, but that doesn't mean that it won't work through a brouter. cisco even has special compression software just for LAT over low-speed links. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything. Especially anything gnu.
john@loverso.leom.ma.us (John Robert LoVerso) (05/10/91)
In an article, Shane Davis talks about the Annex/Encore Multimax "call/RDP"
protocol for "offloading" the host by running the UNIX tty driver on the Annex.
> The protocol is proprietary, like LAT, but is done via TCP/IP, unlike LAT.
Thankfully, this belish is all by dead and buried. Whereas the idea might
have been good, the implementation was horrible and very expensive (espeically
on the Annex end!). And, whereas cooked mode operations may have been cheaper
on the host, in cbreak/raw mode (i.e., editting, etc) the overhead was much
greater. The protocol was actually RPC based (over UDP), btw. It never
performed well and didn't provide "full UNIX tty semantics". It was an
endless source of headaches.
The only good thing was that the protocol was kept proprietary (it still is,
to Encore) and thus never spread anywhere. This means it is enjoying a
slow, easy death (too easy by my standards).
John