Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!gem.mps.ohio-state.edu!ctrsol!cica!iuvax!rutgers!bellcore!jupiter!karn
From: karn@jupiter..bellcore.com (Phil R. Karn)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: more on Fletcher
Message-ID: <18511@bellcore.bellcore.com>
Date: 6 Dec 89 23:35:53 GMT
References: <8912060542.AA05854@WLV.IMSD.CONTEL.COM> <1989Dec6.190415.19049@brutus.cs.uiuc.edu>
Sender: news@bellcore.bellcore.com
Reply-To: karn@jupiter.bellcore.com (Phil R. Karn)
Organization: Bell Communications Research, Inc
Lines: 27

>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...

I am a big believer in the end-to-end argument. Unfortunately, even a
TCP running in the same machine as the application isn't TRULY
end-to-end.

The problem is all that software between TCP and the application. In
particular, it is common to first retrieve a file using FTP and then
have an application read it. A lot can happen between TCP and the
application in this case. Files can get corrupted or truncated by disk
I/O errors, corrupted file system structures, full disks and buggy
buffering schemes. And then there's the #1 cause of data corruption in
FTP: transferring a binary data file in the default ASCII mode! (I've
lost track of how many times I've had to help novice network users with
this one.)

In my experience these problems have accounted for far more actual cases
of corrupted data than failures of the TCP checksum. One thing I often
do on the PC to protect myself against the aforementioned hazards is to
use file compression and archiving utilities like PKARC or ZOO. Not only
do they make it easier and faster to ship a bunch of files over a slow
network, but their built-in CRCs or checksums serve as a somewhat
higher-layer check that includes FTP and the file system as well as TCP.

Phil