Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!uunet!steinmetz!sprite!montnaro
From: montnaro@sprite.steinmetz (Skip Montanaro)
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.misc
Subject: Re: Higher speed LANs ?
Message-ID: <6434@steinmetz.steinmetz.UUCP>
Date: Wed, 24-Jun-87 12:00:20 EDT
Article-I.D.: steinmet.6434
Posted: Wed Jun 24 12:00:20 1987
Date-Received: Fri, 26-Jun-87 04:55:58 EDT
References: <541@houxa.UUCP>
Sender: root@steinmetz.steinmetz.UUCP
Reply-To: montnaro@sprite.steinmetz (Skip Montanaro)
Organization: General Electric CRD, Schenectady, NY
Lines: 27
Xref: mnetor comp.dcom.lans:579 comp.protocols.tcp-ip:451 comp.protocols.misc:95

In article <541@houxa.UUCP> mel1@houxa.UUCP (M.HAAS) writes:
>Is anyone working on higher speed LANs?
>What are the issues that keep us down at such low rates?
>Why is it such a struggle to get 200K bytes per second onto it?
>Are there fundamental problems with TCP/IP that limit its application
>to higher speed use?  Are the new ISO protocols better for high speed
>file transfer?  Or, is the problem in the operating systems or
>interface to the computer bus?  Can the high speed backbone fiber
>networks be made to handle individual computer to computer or
>computer to terminal traffic?  Or, it there some fundamental issue
>that keeps them in the LAN to LAN bridging application?

You (and others interested in such topics) may want to read Greg
Chesson's paper in the recent Summer 1987 USENIX Proceedings, entitled
"Protocol Engine Design". He discusses the reasons for the current
bottlenecks, at least as he sees them. He sees the "software and
system overheads" as a "limiting factor in the 10Mb/s case". Thus
moving to higher speed cabling (i.e., 100 Mb/s fiber optic systems)
will not provide any substantial increase in throughput, since the
software can't punch out the higher level information any faster. The
primary method for increasing throughput has got to come by placing
more and more of the networking protocols in hardware. The protocol
engine he's been working on is just such a beast. 

         Skip|  ARPA:      montanaro@ge-crd.arpa
    Montanaro|  UUCP:      montanaro@desdemona.steinmetz.ge.com
(518)387-7312|  GE DECnet: advax::"montanaro@desdemona.steinmetz.ge.com"