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

[<[e-mail]>]

Joe,

can you at least read the cited papers before making claims about them?

>From the abstract of Stone's SIGCOMM paper:

Traces of Internet packets from the past two years show that between 1 packet in 1,100 and 1 packet in 32,000 fails the TCP checksum, even on links where link-level CRCs should catch all but 1 in 4 billion errors. 
[..]
Much of our time has been spent negotiating access to data.

s/*can*/*was observed to over two years in the wild*.

TCP is supposed to provide a *reliable* transfer to application writers. With jumbo frames and the one's complement checksum, that is no longer true... and application writers don't necessarily have control over frame sizes.

Needs fixing imo.

On 26 Jun 2010, at 19:09, Joe Touch wrote:

> [e-mail] wrote:
>> 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
> 
> *can*. The paper below did mathematical analyses, but didn't observe them either
> in a lab or in the wild. I.e., that work didn't see places where it *did*. Thus
> my question.
> 
> I'm not asking whether this is important to address, just what the current
> motivation is. The work below suggests using application-layer checksums. That
> seems prudent for large transfers, but I don't see a motivation for needing this
> fixed at the TCP layer...
> 
> Joe
> 
>> 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?
>> 
> 

Lloyd Wood
[e-mail]
http://sat-net.com/L.Wood