Path: utzoo!mnetor!uunet!husc6!mailrus!nrl-cmf!ames!pasteur!ucbvax!petruchio.UUCP!wayne
From: wayne@petruchio.UUCP (Wayne Hathaway)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: on-/off-board protocol processing
Message-ID: <8803241647.AA03464@petruchio.sun.com>
Date: 24 Mar 88 16:47:01 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 24

One problem with offloading protocols which has not yet been mentioned
has to do with the "locked-up" nature of commercial on-board protocol
implementations.  A specific example from a place I used to be
associated with:  They used intelligent Ethernet cards (brand name
irrelevant) quite successfully -- until they extended their Ethernet
to the East Coast with a satellite link.  Needless to say, the
on-board Ethernet software was hardly tuned to the extra delay, and
the throughput was abysmal.  But since the on-board software was
proprietary there was nothing the host administrator could do, and
while the card manufacturer was sympathetic, tuning his software for
such a "strange" environment was very low priority.  The solution?
The satellite link was replaced with a slower (bandwidth) but faster
(throughput) land line!

Of course, this is nothing unique to network protocols; any
"intelligent controller" could have the same problem.  In the case of
something like a disk controller, however, one is considerably less
likely to suddenly add some 40,000 miles to the length of the cable!

      Wayne Hathaway                  ultra!wayne@Ames.ARPA
      Ultra Network Technologies
      2140 Bering drive               with a domain server:
      San Jose, CA 95131                 wayne@Ultra.COM
      408-922-0100