Re: [tcpm] draft-eggert-tcpm-historicize-00

[<[e-mail]>]

Ethernet uses CRC-32, TCP's existing 16-bit checksum
isn't a CRC. So I'm a bit puzzled by the question.

The link CRC and TCP checksum can disagree. See

Stone, J., Greenwald, M., Hughes, J., and C. Partridge,
"Performance of checksums and CRCs over real data", IEEE
Transactions on Networks vol. 6 issue 5, pp. 529-543,
October 1998.

Stone, J. and C. Partridge, "When the CRC and TCP Checksum
Disagree", Proceedings of ACM SIGCOMM , September 2000.


On 25 Jun 2010, at 19:36, Joe Touch wrote:
>> 
>> Our expirience has shown, that TCP often runs over links with much
>> higher error rates, than intended for the technology (ie. Design goal of
>> BER <= 1E-12 over Ethernet often has an actual BER >> 1E-12). If such
>> error-prone links are running at a high speed and with large segment
>> sizes (jumbo / giant frames), there exists the real problem that within
>> a short timeframe (weeks to months), TCP will deliver corrupted data, as
>> CRC-16 was not able to catch the error.
> 
> Just to confirm, is this a measured problem or a mathematical one? I.e., have
> you seen this actually occur (i.e., TCP with invalid CRC-16 but valid checksum)
> in the wild, in a lab, or have you never seen it but consider it important anyway?