jas@proteon.com (John A. Shriver) (01/17/91)
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? I strongly suspect that the answer would be yes. Such a protocol would eliminate the crazy jumping through hoops people are going through to try and bridge LAT across multiple media and wide area networks. I suspect at least part of the design parameters of LAT has more to do with the implementation characteristcs of DECnet under VAX/VMS than with the design of the "ultimately efficient" virtual terminal protocol. Indeed, despite implementation problems, in some ways CTERM (the DECnet virtual terminal protocol) is a better protocol, since it can dynamically switch between local and remote echo, even in a screen editor. Of course, the application has to be well written to gain the advantages of the CTERM protocol. Unfortunately, with LAT proprietary, the standards bodies won't get to learn from it in designing future protocols. It would be nice if the ISO virtual terminal protocols could have had some of these advantages.
mann@star.enet.dec.com (Bruce Mann ZK1-3/J35 DTN 381-1298 21-Jan-1991 1257) (01/22/91)
>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. >Indeed, despite implementation problems, in some ways CTERM (the >DECnet virtual terminal protocol) is a better protocol, since it can >dynamically switch between local and remote echo, even in a screen >editor. Of course, the application has to be well written to gain the >advantages of the CTERM protocol. LAT makes no such effort at these optimizations. CTERM, TELNET, and/or VTP could be run over LAT without modifications to LAT. In fact, LAT is designed to be extensible to do this. Achieving these benefits however (local echo for instance) often come at the expense of application transparency without sufficient compensation in the form of increased performance/efficiency. >Unfortunately, with LAT proprietary, the standards bodies won't get to >learn from it in designing future protocols. It would be nice if the >ISO virtual terminal protocols could have had some of these advantages. To my knowledge, all useful protocols start out being proprietary, and evolve into "open" status as they become more widely used. LAT is certainly in this transition now. By the way, while I do agree all protocols can be routed (layer 3), I do not agree all protocols should be routed. The routing layer has obvious benefits, but also introduces some obvious problems. For example, if every terminal should have its own IP address, why shouldn't every file ? Where should the line be drawn ? Bruce Mann
barmar@think.com (Barry Margolin) (01/22/91)
In article <9101211758.AA24806@decpa.pa.dec.com> mann@star.enet.dec.com (Bruce Mann ZK1-3/J35 DTN 381-1298 21-Jan-1991 1257) writes: > To my knowledge, all useful protocols start out being proprietary, >and evolve into "open" status as they become more widely used. LAT is >certainly in this transition now. The standard protocols in the TCP/IP suite have never, to my knowledge, been proprietary. Working up the protocol hierarchy, all of IP-Ethernet-encapsulation, IP, TCP, and the application protocols TELNET, FTP, SMTP, and SNMP were developed openly. The BSD R-protocols were developed privately by Berkeley, but the source has always been available, and some of them have reasonable protocol descriptions in the manual entries. Similarly for X Windows and MIT/DEC. Sun made the specification of the NFS protocol available pretty soon after their workstations that use it became popular. LAT has been around for at least five years. When will this "transition" take place, i.e. when will DEC publish the protocol specification in the open literature? > By the way, while I do agree all protocols can be routed (layer 3), >I do not agree all protocols should be routed. The routing layer has >obvious benefits, but also introduces some obvious problems. For example, >if every terminal should have its own IP address, why shouldn't every file ? >Where should the line be drawn ? It's generally not necessary to include routing in a high-level protocol when it normally uses a lower-level protocol that is already routed. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
rlstewart@eng.xyplex.com (Bob Stewart) (01/23/91)
> >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
karl@lvs.Eng.Sun.COM (Karl Auerbach) (01/23/91)
In article <9101161700.AA19338@sonny.proteon.com> jas@proteon.com (John A. Shriver) writes: >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? I strongly suspect that the answer would be yes. Yes, but -- DEC has a patent on LAT. I suspect that some of their lawyers may object to a new protocol that uses some of dally-in-hope-of-more-data techniques embedded in LAT. (Please don't flame me for DEC's patent. Personally, I think that the LAT idea wasn't novel at the time. [For example, one of the reason that municipal busses run on schedules is to get a full load of passengers. And the Nagle algorithms used in TCP/IP try to collect reasonable payloads into packets before launching them into the ether.] But I'm not at the patent office.) --karl--