Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!brutus.cs.uiuc.edu!zweig
From: zweig@brutus.cs.uiuc.edu (Johnny Zweig)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: more on Fletcher
Message-ID: <1989Dec6.190415.19049@brutus.cs.uiuc.edu>
Date: 6 Dec 89 19:04:15 GMT
References: <8912060542.AA05854@WLV.IMSD.CONTEL.COM>
Sender: news@brutus.cs.uiuc.edu
Reply-To: zweig@cs.uiuc.edu
Organization: U of Illinois, CS Dept., Systems Research Group
Lines: 51

mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes:

>I fail to see the reason why an alternative form of checksum is required for
>the TCP frame.  As I recall the original posting, the host (in this case, an
>intelligent communications processor) received the data correctly.  The error
>occurred in a subsequent transmission between the "host" and external memory.

>The problem is that the vendor of the intelligent communications processor
>did not fully understand or is not compliant with the protocol established
>by the vendor of the computer to govern DMA operations.  Or, the vendor of
>the computer did not adequately define or implement the defined DMA proto-
>col.

I have to disagree (note my biased opinion, given that I'm the one who 
proposed the option).  The TCP checksum is an end-to-end checksum.  Saying
"it's a hardware problem" is a cop-out (although I agree wholeheartedly
that nobody in their right mind would buy/use hardware known to suffer from
such bugs) -- my idea was simply to allow the possibility of specifying a
checksum that can detect these errors which ought not to happen.

>In either case, it is not TCP that is the problem.

But is _is_ TCP's job to detect the presence of the problem, rather than
get bitten by it.

> If it is, as indicated
>in an earlier message, a known problem that can occur during DMA operations,
>it is the computer manufacturer's responsibility to correct the error.  If
>it is a problem that only occurs with DMA operations from the intelligent
>communications processor, its manufacturer is responsible for correcting
>the problem.

>Merton

All I thought was "gee, why not have a standard way of doing something
that nobody ought to want to do, so that all the people who ought not to be
doing it do it in the same way?"  I am a researcher (not one of these evil
vendor type goblins that ought to solve problems rather than think them up ;-)
and I personally think playing with alternate checksums might be fun.  Further,
I am not in a position, for the most part, to say "Let's complain to Widgicorp
that the beta-test hardware they gave us is flakey and suspend research on our
latest transaction protocol for six months while they fix the problem" if I
can just say "Oh. Plug in the Fletcher-TCP module on both of the machines
in our experimental net and take a performance hit until Widgicorp gets it
fixed."

I prefer having standards that allow me to do crazy mixed-up stuff the same
way as all the other screwballs over having a non-compliant implementation
that I need to work around something.

-Johnny