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

["Scheffenegger, Richard" <[e-mail]>]

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

IETF TRILL is not a good example, as that the top side of L2 (management protocol of the topology). 
 
 
>>> 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.

I beg to differ.
 
802.3 Ethernet has no way of negotiating the type of CRC used - it's always been CRC32, and probably will always be CRC32 - for the simple fact that MTU1500 frames can potentially be bridged over legacy 10-Mbit half-duplex Hubs, even if they originated from state-of-the-art, 40G Ethernet Interfaces. 
 
In comparison to that, TCP *does have* (and always had) the ability to negotiate new features - and thereby maintain backwards compatibility.
 
My understanding from the example Anumita mentioned (the one customer copying a few TB around, only to find a few bits flipped) is, that an application level checksum (CRC32C for each 8k appliaction data block) was used to find those problems. However, the damage was already done.
 
So, to answer your question
 
> 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?
 
the answer would be in the wild. I agree with you, that there are probably many other sources of corruption (bit flip in the tcp receive / send buffer, before CRC is ever calculated; after all, ECC Memory is also not perfect (3-bit errors  can go unnoticed)... However, raising the confidence levels of the TCP layer over known problematic links (BER >> 1E-12) would help...
 
> An interesting question is why you care that the payload doesn't get
> accidentally altered, but you don't care if the port or address does (and you
> don't notice), though.

As mentioned, providing payload data integrity for the stream would be the goal. If a packet's header is corrupted (but goes undetected), that stray segment will cause no harm (or at least with many orders of magnitude lower pobability); for the stream where that packet came from, it's just look like any other dropped frame; however, if the integrity of the data (especially of jumbo (9k-16k) or giant (32k-64k) frames can not be guaranteed by L2 (ethernet) checksums under adverse conditions, and also TCP does not provide a means for it, major forklift upgrade would be required - commercial software doing L5+ checksums and retransmissions on top of TCP.
 
As Anumita pointed out, tcp segment checksums can be offloaded to hardware relatively easy (provided there is a standard for it); it might not be the perfect solution, but the most effective one to deploy incrementially. 
 
Also, from a architectural point of view, I can agree that changing the CRC32 of Ethernet to CRC32C or CRC64 might have been (!) the proper way in the time when 1 Gigabit was standardized (and with it, the support for Jumbo Frames). But we passed that milestone a decade ago, unfortunately.
 
Do we have a member here who is also active in 802.3ba (HSSG), and who could comment on the feasability of changing the CRC in Ethernet? 
 
Regards,
  Richard
________________________________

Von: Joe Touch [mailto:[e-mail]]
Gesendet: So 27.06.2010 23:00
An: Biswas, Anumita
Cc: [e-mail]; [e-mail]; [e-mail]
Betreff: Re: [tcpm] draft-eggert-tcpm-historicize-00



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