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

[Joe Touch <[e-mail]>]

Fernando Gont wrote:
> 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?

To clarify, what I'm seeking is:

a TCP segment that:
	has a valid TCP checksum
	actually has been received in the lab or wild
	would have an invalid CRC-16 as proposed in the ID

i.e., this is a case where the ethernet or other link checksum would have
succeeded on all the hops, and the TCP checksum succeeds, so an error would NOT
have been caught.

That's the only case where we need to consider replacing the TCP checksum.

So far, it appears that the only reported evidence (the 2000 Sigcomm paper)
looked only for real packets where the TCP checksum already failed.

The case where both the link and TCP checks fail is in Sec 4.4 (I had mistyped
that as 5 previously), and is only a mathematical analysis of probability.

Joe