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

["Biswas, Anumita" <[e-mail]>]

Hi Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]] 
> Sent: Saturday, June 26, 2010 12:26 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; Biswas, Anumita
> Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00
> 
> 
> 
> 
> [e-mail] wrote:
> >> The do not seek, nor did they find in the wild, a single 
> packet where 
> >> the CRC was valid and the TCP checksum was valid, but the 
> packet had 
> >> changed in contents.
> > 
> > Before going any further - did you really mean to write that?
> 
> Yes. FWIW, the CRC I'm referring to above is the link CRC 
> (CRC32 for Ethernet).
> 
> The only way a packet is accepted erroneously at a receiver, 
> but would cause an problem, would be:
> 	link check OK
> 	TCP (1s compl) checksum OK
> 	new checksum FAIL
> 
> I.e., the only reason a new TCP checksum would be useful is 
> in this case. If either of the link or existing TCP checks 
> succeed, there's no new problem.
> 
> Please see draft-ietf-tcpm-anumita-tcp-stronger-checksum-00, 
> e.g., in the abstract, or Sec 1. In fact, the case they're 
> considering is where real link errors occur that are not 
> detectable - not TCP/IP implementation errors or router 
> memory errors, as were the only ones seen in the wild in the 
> Sigcomm paper.
> 
Although the draft specifically calls out link errors, the draft by no
means does not discard other sources of errors as are mentioned in those
papers and are also referenced in the draft. I think the only reason the
link errors were called out is because we *know* that is possible to
have bad cables that can have higher BER than advertised. It is very
hard to "detect" "undetectable" errors in the wild (actually by
definition itself) and that is why it is worrisome to me. Its only
possible to have a measurement like "Probability of undetected errors"
rather than "X is the number of the undetected errors" in such cases.  

I have heard only anecdotal evidence of a very large company doing very
large copies of data (about a Tera Byte) across a local network and then
finding bit corruptions in the data received on the other end - clearly
the link CRC and the TCP 1s compl summation checksum failed to catch
those errors. 
In my own company, I have seen a case where a very large block (1460
bytes - a packet size) of data was replaced and gone undetected and we
could not root cause the problem - the problem just disappeared after
showing up for a few weeks - but in this case, it is possible that the
corruption occurred before the data was sent by TCP itself. 

So to me, to hinge whether we support a new TCP CRC based checksum or
not, on practical experience in the wild, is probably not a safe
approach. Ofcourse, if we had multiple proven examples of this in the
wild, we'd feel more motivated to do this. 

Also, I am more worried about packet sizes greater than 1500 bytes -
where the Ethernet CRC checksum becomes weaker. Typical ethernet MTUs
across the internet does not exceed 1500 bytes today - so right now, the
problem scope is limited to Data Centers and other such local LANs where
the end to end PMTU is greater than 1500 bytes.

Based on comments from Richard Scheffenegger on the issue of
middleboxes, I am planning to upload a new version of the draft that
only checksums the data portion. 

I also think TCP is *the* place for a stronger checksum, so that upper
layers do not have to reinvent checksumming after rediscovering the
weaknesses of the lower layer "reliable" checksums. It also allows for
easy offloading to NICs as the TCP 16 bit checksum is offloaded today so
that software gets rid of the computational overheads of a stronger
checksum. It is much harder, almost impossible for an application layer
checksum to be offloaded off to NICs. As NIC vendors, for obvious
reasons, prefer only to offload standards based computation, and only in
case where performance matters hugely are ready to offload work like TCP
segmentation offload and receive side coalescing. 

Thanks,
Anumita

> Joe
> 
>