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

[Joe Touch <[e-mail]>]

Scheffenegger, Richard wrote:
...
>>> 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.

We're talking about jumbograms, which, according to other posts, is not yet
standardized. This presents a fine opportunity to standardize them with a new CRC.

That should not affect legacy MTU1500 frames.

...
> 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.

Where was the damage 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...

It provably does not help unless the errors occur at the link layer. Seeing
faulty application transfers does not indicate that a link solution 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; 

Yes, but it could easily (and silently) corrupt the data of other streams. That
does NOT seem like a reasonable trade-off for a transport protocol protection
mechanism.

> 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.

If you can't protect against faulty data going into other connections, you will
need such a forklift upgrade anyway.

...
> 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?

AFAICT, if jumbograms aren't yet standardized, it's definitely feasible.

E.g., let CRC be something that depends on the payload length; if length >1500,
use a different CRC.

Joe