From: CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 16-SEP-1989 13:32 To: MRGATE::"ARISIA::EVERHART" Subj: Re: OSI speed (was Re: DECnet phase V) Received: From IU.AI.SRI.COM by CRVAX.SRI.COM with TCP; Sat, 16 SEP 89 10:01:08 PDT Date: Sat 16 Sep 89 09:59:52-PST From: David L. Kashtan Subject: Re: OSI speed (was Re: DECnet phase V) To: shlump.nac.dec.com!shodha.dec.com!devine@decwrl.dec.com Cc: info-vax@kl.sri.com Message-Id: <621968392.10000.KASHTAN@IU.AI.SRI.COM> In-Reply-To: <416@shodha.dec.com> Mail-System-Version: Postal-Address: 15139 Old Ranch Rd; Los Gatos, CA 95030 Phone: (415) 859-5830 (SRI); (408) 353-1643 (Home) > This past spring an evaluation was performed at Ultra Network > corporation (a company that does very high speed networks) between > OSI and TCP/IP at the level of transport layer. They found that > the faster is OSI because of its easier to parse headers and > a flow-control scheme based on packets instead of byte counts. Sheesh! OSI has easier to parse headers?? What are we talking about here -- CLNP, TP4 ??? I know what the headers look like and they are most definitely not easier to parse than IP or TCP headers (and I am VERY familiar with those). Even if they WERE easier to parse -- the parsing of packet headers is a VERY small part of the protocol processing. Flow-control scheme based on packets vs byte counts? That is really a load of crap -- they are 100% equivalent. It doesn't matter if you count bytes or packets, there is a one to one mapping and the results are the same! Now lets talk about what in the real world has the greatest effect on transport layer speed -- THE IMPLEMENTATION! I suggest to anybody who is even slightly inclined to accept that header parsing and packet counting vs byte counting makes OSI faster than TCP/IP find some information on Van Jacobsen's "header prediction" for TCP/IP. Essentially what it does for high-speed-pretty-much-error-free networks is says that for a given TCP connection you can predict what the next packet is going to look like. In a nutshell -- once you verify (very quickly) that the packet does indeed match your guess there is NO protocol processing left and you can just hand the data in the packet to the application. In real terms -- this means that a 68020 class machine can saturate an ethernet and still have CPU left over for the application. David -------