Xref: utzoo comp.protocols.tcp-ip:2936 comp.protocols.iso:65
Path: utzoo!utgpu!water!watmath!egisin
From: egisin@watmath.waterloo.edu (Eric Gisin)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.iso
Subject: Re: SLIP working group?
Message-ID: <17950@watmath.waterloo.edu>
Date: 31 Mar 88 22:13:38 GMT
References: <1966@hou2d.UUCP> <1016@thumper.bellcore.com>
Organization: U of Waterloo, Ontario
Lines: 19

In article <1016@thumper.bellcore.com>, karn@thumper.bellcore.com (Phil R. Karn) writes:
[]
> the IP and TCP layers.  The error rate of a typical dialup link (if it
> works at all) is low enough that the extra software processing required
> to recompute a checksum over an entire packet at each hop is hard to
> justify. I keep a nailed-up 9600 bps V.32 modem link between work and
> home. In the 6 days since it was last rebooted, my machine at home has
> received 13,186 packets over the serial link. Of these, however, only 6
> had IP header checksum errors and 8 contained TCP header checksum

The overhead of a asyncronous link level checksum or CRC is very small.
On an 8MHz 68000, Fletcher's checksum takes about 3 usec per byte,
and CRC-16 takes about 8 usec per byte. This amounts to less than 1% overhead
at 9600 baud, which is less than overhead of the asyncronous device driver
(much less in the case of dumb asyncronous devices).

Both of these are better than the 16 bit ones-complement checksum TCP/IP uses.
Your example error rate is 1/1000 (high relative to LAN technologies),
and I wouldn't trust only TCP/IP checksum to detect errors.