Path: utzoo!utgpu!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!gpu.utcs.utoronto!dennis
From: dennis@gpu.utcs.utoronto
Newsgroups: comp.protocols.ibm
Subject: Re: (none)
Message-ID: <8809290248.AA07802@jade.berkeley.edu>
Date: 29 Sep 88 02:42:05 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: dennis@gpu.utcs.utoronto
Organization: The Internet
Lines: 46

>>
>>The one assumption TCP *does* make is that lower layers will not deliver
>>a corrupted datagram and claim it's correct. The TCP (and IP and UDP)
>>checksum(s) are a low-cost but extrememly useful last-ditch protection
>>of this assumption, and are well worth it.
>>

>   PLEASE remember that IP is a connectionless UNRELIABLE delivery
>protocol.  There is NO checking of the data in the packet - ONLY the
>header fields!  TCP and UDP checksums are only needed if you care what
>data you will be getting...  ;-)

I think I agree with the first statement more.  In the context of
TCP/UCP/IP, "unreliable" most correctly means that you are not
guaranteed that the datagrams you send will be received at their
destination, and that you and/or the recipient must be prepared to
recover appropriately in the event of non-delivery.  It doesn't
usually mean that you must be prepared to detect bit errors in
datagrams which are received.  For example, UDP is "unreliable",
yet this doesn't require applications to implement a checksum
of their own.  The application can (and almost always does) assume
that the data in a datagram delivered by UDP is error free, it just
can't assume that all the datagrams which were sent are being received.

However, if you really do care what data you are getting, you
*will* use a link level which detects data errors and, at a minimum,
drops those frames.  The TCP checksum was chosen primarily for its
ease of computation, is not strong enough to be reliable when data
errors occur frequently and is particularly bad at detecting some
types of errors.  A year on the far end of a losy serial net link taught
me to crc any large files I tried to transfer, before and after
transmission.  It didn't happen often, but every once in a while
there'd be a string of bytes screwed up in the middle of one, let
through undetected by TCP.

The TCP checksum really is last-ditch protection, as it should be.
It's much cheaper to calculate CRCs in hardware at the link level
than it would be to do them in your host based TCP.  It's also
more efficient to catch and drop damaged datagrams early rather
than relaying them the rest of the way to their destination.  You
really want to catch link errors at the link level, but want the
transport checksum to catch the occasional bad one that will inevitably
slip through anyway.

Dennis Ferguson
University of Toronto