david@elroy.Jpl.Nasa.Gov (David Robinson) (12/09/87)
I frequently hear that TCP/IP is too slow of a protocol. I have seen
good ethernet boards on a Sun push packets as fast as 5Mbps and claims
of Crays pushing > 10Mbps on hyperchannels.
The throughput on most machines appears to be the speed that the
CPU can process the packets, whether the CPU is the main CPU or
an on board CPU.
To increase TCP/IP performance has anyone looked into making an IP
protocol chip or chipset? Would this be practical to do given
the complexity of IP? IP on a chip would also be interesting from
a routing point of view.
Any comments on the idea and potential problems that I may not
have thought of?
--
David Robinson elroy!david@csvax.caltech.edu ARPA
david@elroy.jpl.nasa.gov ARPA
{cit-vax,ames}!elroy!david UUCP
Disclaimer: No one listens to me anyway!fair@ucbarpa.Berkeley.EDU (Erik E. Fair) (12/09/87)
In the referenced article, david@elroy.Jpl.Nasa.Gov (David Robinson) writes: >To increase TCP/IP performance has anyone looked into making an IP >protocol chip or chipset? Greg Chesson of Silicon Graphics in Mountain View, CA has been looking into this. He gave a paper at the Summer 1987 USENIX Conference in Phoenix, entitled "Protocol Engine Design." The paper starts on page 209 in the proceedings from that conference, which are available from the USENIX Association. His design goal was to produce a chipset capable of keeping up with FDDI data rate (100Mbit/sec) by doing protocol processing in a packet-time. The technology he described was reported sold by Silicon Graphics two months ago to a company called "Protocol Engines, Inc." in Santa Barbara, CA. Greg Chesson's reply to an inquiry I made about the sale was as follows: ------------------------------------------------------------------------------- Date: 23 Oct 87 22:47:56 GMT From: sgi!greg@ucbvax.berkeley.edu (Greg Chesson) Organization: Silicon Graphics Inc, Mountain View, CA Subject: Re: Greg Chesson's Protocol Engine technology sold by SGI Message-Id: <7237@sgi.SGI.COM> References: <21255@ucbvax.BERKELEY.EDU> to: Erik Fair, Dave Farber, and others: The newspaper article quoted in this news group created some undeserved speculation and masked the enthusiastic and public spirited support that SGI has for the project and the concept. SGI has given over protocol engine technology to Protocol Engines Inc for nominal reimbursement of costs. It was not a significant financial transaction. SGI engineers and people at other companies continue to work on the project. Protocol engine details - protocol, state machines, software emulation - will be placed in the public domain as has been stated before. PEI is modeled after other multi-company consortia such as the group that standardized the SCSI bus. It is a corporate shell intended to achieve the following: 1) provide a neutral repository for P-engine technology 2) fund chip fabrication 3) focus on standards activities 4) provide multiple sources for chips 5) push the technology beyond 100 Mbit/sec Item (1) helps preserve the open nature of the design and to ensure that there exists an organization dedicated to P-engine technology. Item (2) should be obvious, since prototype production is more than I can accomplish as an internal skunkworks. Item (4) means that PEI is working with semiconductor houses to make P-engines become standard products. The other items should be self-explanatory. Greg Chesson Silicon Graphics 2011 Stierlin Road Mountain View, Ca, 94043 (415)962-3496 {sun,pyramid,adobe,allegra,decwrl}!sgi!greg ------------------------------------------------------------------------------- If you (or anyone else) knows about other efforts in this general direction, I would appreciate hearing about it. Erik E. Fair ucbvax!fair fair@ucbarpa.berkeley.edu
sra@MITRE-BEDFORD.ARPA (Stan Ames) (12/09/87)
As part of an IR&D project MITRE developed several experimental chips to see if performance improvements could be obtained several chips were developed for the TP4 protocol. The most useful was an ip checksum chip. For more information you can call Jerry Freedman at 617-271-6248 Stan Ames
hsw@TYCHO.ARPA (Howard Weiss) (12/09/87)
There was a TCP/IP 40-pin chip implementation built back in 1983 by
a company called Quanta Microtique. I actually still have the
data sheets on the chip (called the QM10 - Advanced Communications
Controller). Steve Holmgren developed the chip and ran the company -
he now runs CMC in Santa Barbara, Ca.
The "General Description" of the chip (from the QM-10 literature) says:
"The QM10 is an LSI circuit designed to support virtual connection and
packet functions previoulsy found in larger digital communications
processors. A 40-pin, dual inline form factor makes integration into
existing hardware straightforward."
The "Device Characteristics" were listed as:
* DoD Standard TCP connection protocol firmware.
* DoD Standard IP packet protocol firmware.
* Single Connection per device.
* IP address filtering for ganged device configurations.
* Flexible shared memory user interface.
* Configurable network interfaces.
- Onboard UART configuration.
- Outborrad USART configuration.
- Outboard shared memory network interface.
* Single +5 volt power supply
* 12mW stand-by power for connection state retention.
* Standard 40-pin package.
Howard Weiss
-------PULLEN@VAX.DARPA.MIL (Mark Pullen) (12/10/87)
David, Michael Foster and Yechaim Yemini and Columbia University are working on VLSI implementations of protocols. Mark Pullen DARPA Program Manager Advanced Networking -------
PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") (12/12/87)
I think that an ip-on-a-chip would have to be micro-coded (not because of complexity, it could certainly fit in random logic), because bugs would certainly be found. Also, certain parameters (such as fragmenting/reassembly philosophy) might need to be tailored to the environment (i.e. an ethernet enviroment device should not generate back to back fragments, but should space or scatter them over time). Ideas? -Philip
daveb@geac.UUCP (David Collier-Brown) (12/14/87)
In article <4994@elroy.Jpl.Nasa.Gov> david@elroy.Jpl.Nasa.Gov (David Robinson) writes: > >I frequently hear that TCP/IP is too slow of a protocol. I have seen >good ethernet boards on a Sun push packets as fast as 5Mbps and claims >of Crays pushing > 10Mbps on hyperchannels. >... >To increase TCP/IP performance has anyone looked into making an IP >protocol chip or chipset? I don't know about IP, but several protocols have been put into modem controllers. One I know of in some detail is MNP, an combined sync/async facility with Network, Host-host and Applications layers (ie, it fits the ARM). It explicitly does **not** consider routing or network management, as it is restricted to running on a circuit-switched line. Another is the telebit "UUCP emulation" facility in their high-speed modems. >... Would this be practical to do given >the complexity of IP? IP on a chip would also be interesting from >a routing point of view. Neither of the above runs on an unprogrammable chip: even the chip-level MNP being developed by two people on this net has a z80 as part of the silicon. If one restricts the chipset to doing what it is good at and passing the administrivia off to a large host to do what **it** is good at, you have a viable project. Deciding exactly what to put on the chip is a design/marketing (ie $) issue. > >Any comments on the idea and potential problems that I may not >have thought of? > David Robinson elroy!david@csvax.caltech.edu ARPA > david@elroy.jpl.nasa.gov ARPA > {cit-vax,ames}!elroy!david UUCP I think its a **good** idea. I also think it can be done "inexpensively". --dave (It's almost an old idea...) c-b -- David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
alison@TCGOULD.TN.CORNELL.EDU (Alison Brown) (12/15/87)
Chesson is indeed working on a protocol engine, but the protocol to be put into the chip is in no way IP (DoD IP as in TCP/IP), at least as I understand what they are doing. The high speeds they want to attain require a lighter weight protocol than anything defined as a standard today, from what I can gather.....
david@ms.uky.edu (David Herron -- Resident E-mail Hack) (12/19/87)
In article <1969@geac.UUCP> daveb@geac.UUCP (David Collier-Brown) writes: >In article <4994@elroy.Jpl.Nasa.Gov> david@elroy.Jpl.Nasa.Gov (David Robinson) writes: >>To increase TCP/IP performance has anyone looked into making an IP >>protocol chip or chipset? > .... One I know of in some detail is MNP, an combined >sync/async facility with Network, Host-host and Applications layers >(ie, it fits the ARM). ... > ... Another is the telebit "UUCP emulation" facility in their >high-speed modems. er.. I beg to differ ... At least in the Telebit modems there's a 68000 and a whoooole bunch of ROM That's not the same sort of thing as people are talking about with this Chesson Protocol Engine. I think (but don't know for certain) that MNP modems are in the same league. One of the lessons of recent computer history is that systems designers should, once the issues are understood, put things into hardware when there is gain to be made from doing so. For instance, you can make a machine that has a fairly "slow" processor and make it do really neat graphics with the addition of specialized hardware. (I'm talking about Amiga's here ... compare it's graphics to Mac's and realize that they're using essentially the same processors). So, to the extent that some of the gut-level things about routing and protocols and so forth are well-understood ... YES ... PLEASE PUT THESE THINGS ONTO A CHIP! For instance, one obvious thing to have is a co-processor for computing checksums. And not just one or two types of checksums, but LOTS of types of 'em. An example here is the DUP-11 we have here running our connection to BITNET. Either that board or the board from MDB (was it a DUPV-11 look-alike?) would run at some huge bit-rate like 500K baud. But it would only run at that baud rate if we were using a protocol which used the right kind of checksum. But since we're doing BISYNC to an IBM machine and the type of checksum used for BISYNC is different from those which DEC (MDB?) supplied on the board. Therefore this board we have eats up our 11/750 it's installed in because the Vax has to calculate the checksums itself. (Note, it's been awhile since I've looked at the details here ... I may have some of them wrong). > Neither of the above runs on an unprogrammable chip: even the >chip-level MNP being developed by two people on this net has a z80 >as part of the silicon. Oh sorry, you do understand ... > ... Deciding exactly what to put on >the chip is a design/marketing (ie $) issue. Yeah! -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- <---- Winter health warning: Remember, don't eat the yellow snow!