I believe the source of these TCP checksum errors is a buggy router with
a broken VJ compressor.

The evidence:  the connection rolls along with perfectly good TCP segments
being sent until suddenly a TCP segment arrives whose TCP checksum is wrong.

Then another.

Then another.

The entire receive window, in fact, gets loaded up with curdled packets.

My system sends acknowledges for the last properly received byte several
times, and finally the sending system gets the hint and restarts the
transmission.

The previously curdled packets are resent, pretty much exactly as they were
(since the remote system is sending Dont-Fragment IP packets with one IP
packet per TCP segment), but this time the checksums are correct.  The
INTERESTING thing is this:

The incorrect checksum value for the first curdled packet turns out to be
the CORRECT checksum value for the next curdled packet, whose incorrect
checksum value was the correct checksum value for the 3rd curdled packet,
whose incorrect checksum value was the correct checksum value for the 5th
curdled packet (whoops, there goes the SIMPLE theory), and so on.  In short,
the packets' checksum fields appear to the the checksum of some *other*
packet (two bad checksums were the valid checksums of the two most recent
acknowledgements my system sent!).

OK, the *class* of the bug is pretty clear; the question is where the
checksums got corrupted.  My bet is on the router; my system would have to
be prescient to figure out what the checksum of an *unreceived* packet
is going to be (in which case, I think the received throughput ought to
be a damned sight higher than it is :-).