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

[Joe Touch <[e-mail]>]

Hi, Animita,

Biswas, Anumita wrote:
>> Everything so far points to the need for an application 
>> protocol check, i.e., a final, total transfer checksum on 
>> each large transaction (i.e., the whole file). That was one 
>> conclusion of the 2000 paper, FWIW.
>>
> I mentioned the advantage of being able to offload a TCP based checksum
> to the NIC. If I were to extend your argument that end system software
> is more likely the problem - a checksum over the whole file could also
> be prone to error. 

That's true too, but it would catch errors at all other places in the stack,
e.g., even errors that would not be caught by errors actually seen (e.g., in the
2000 paper).

> I think we are only trying to deploy a "stronger" checksum - we are not
> making claims that it will find all problems in end to end software -
> and as such is not the strongest checksum.

My point above is that 'stronger' won't fix the flaws actually seen thus far.

...
> Please read why the Castagnoli polynomial based CRC checksum is stronger
> than the Ethernet CRC32 checksum carried by the Ethernet frame. 

I have no question about that. This is a great argument to raise to the Ethernet
community.

> Your argument suggests 
>> that such data centers need different *ethernet* checksums, 
>> not different TCP ones. Then the data centers can leverage - 
>> and reuse - that where necessary.
>
> The ideal way to do this would be to have Ethernet frames include the
> CRC32C checksum instead of the CRC32 checksum. But changing the Ethernet
> standard across the board is impossible due to backward compatibility
> issues. 

That's no more true for ethernet than for TCP.

> But TCP options provides a much easier path to introducing a
> stronger checksum as it does not break backward compatibility and can be
> offloaded to the NIC as well. 

That may all be true, but as I've noted repeatedly, the errors *actually seen*
thus far would not be solved by a new, stronger TCP sum. Only an application sum
would have caught those errors.

> Data Centers are one place where Jumbo frames are deployed - but there
> could be others. So I don't understand what you mean by "data centers
> can leverage and reuse that where necessary".

I'm suggesting that this is a jumboframe problem. Fix it in the implementation
of jumboframes, and all users of jumboframes will eventually benefit - i.e., fix
this at the Ethernet vendor level, and it can be used in all data centers that
use jumboframes.

Note that those vendors *do* deploy new capabilities - e.g., see the IETF TRILL WG.

Joe