Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!linac!att!ucbvax!FTP.COM!jbvb
From: jbvb@FTP.COM (James B. Van Bokkelen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: LAT vs telnet
Message-ID: <9105021840.AA06539@ftp.com>
Date: 2 May 91 18:40:47 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: jbvb@ftp.com
Organization: The Internet
Lines: 25


    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-0901