Subject: RE: [rddp] CRC mandatory?

From: "Barron, Dwight" <[email-masked]>
Date: Tue, 6 May 2003 15:14:24 -0500

I don't agree with that assessment. MPA CRC is layered above the TCP checksum/logic. The key is to have different fault behaviors, e.g. any latent faults in CRC logic are significantly different from the latent faults in the TCP protocol/checksum logic. I believe this independent fault behavior is quite achievable in both layered and roto-tilled implementations.

Regards,
Dwight

> -----Original Message-----
> From: Somesh Gupta [mailto:[email-masked]]
> Sent: Tuesday, May 06, 2003 2:34 PM
> To: Barron, Dwight; Mogul, Jeffrey (HPL Palo Alto); [email-masked]
> Subject: RE: [rddp] CRC mandatory? 
> 
> 
> The paper is an excellent arguement for not offloading
> integrity checks. A study of types of errors encountered
> is interesting. A single CRC generated at the egress point,
> and checked at the ingress point, would not catch 99% of
> the errors listed because the CRC would be added to corrupted
> data or data be corrupted after CRC check was done.
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Barron, Dwight
> > Sent: Tuesday, May 06, 2003 12:12 PM
> > To: Mogul, Jeffrey (HPL Palo Alto); [email-masked]
> > Subject: RE: [rddp] CRC mandatory? 
> > 
> > 
> > Jeff, I agree that collecting quantitative data can be useful, 
> > but also believe that when it is being used to settle qualitative 
> > arguments the thresholds of acceptability are best set before the 
> > numbers are in. In a previous posting Jim Williams had stated 
> > that something in the same order of magnitude as the TCP stack on 
> > a per byte basis was not acceptable. I have not seen any comments 
> > on what would be acceptable overhead/criteria in order to gain 
> > consensus support of a mandatory CRC, nor any guidance on the 
> > parameters or type of environment to measure (but I agree that 
> > Sparc numbers circa 1995 aren't a good candidate). While I am not 
> > volunteering to collect the data yet, this is a hint that I could 
> > be coerced into doing so if it would lead to a more rapid consensus.
> > 
> > However, determining an acceptable overhead is only one side of 
> > the equation, determining the acceptable level of reliability is 
> > the other. I continue to find the quantitative conclusions in the 
> > paper "When the CRC and TCP checksum disagree" 
> > 
> http://www.acm.org/sigcomm/sigcomm2000/conf/paper/sigcomm2000-9-1.pdf 
> > much more convincing than the qualitative arguments of "I use XYZ 
> > file servers all the time and they work just fine."
> > 
> > Finally, when making an overhead vs. reliability architectural 
> > decision, one should realize that while Moore's Law is clearly on 
> > the side of lowering overhead over time, the reliability method 
> > is fixed for a very long time, in the face of constant or ever 
> > increasing errors per unit of time. If I have to bet incorrectly 
> > on an architectural decision, I like having time on my side. 
> > 
> > Regards,
> > Dwight
> > 
> > 
> > > -----Original Message-----
> > > From: Mogul, Jeffrey (HPL Palo Alto) 
> > > Sent: Tuesday, May 06, 2003 12:58 PM
> > > To: [email-masked]
> > > Subject: Re: [rddp] CRC mandatory? 
> > > 
> > > 
> > > It seems to me that one (but NOT the only) consideration in this
> > > discussion is whether CRC calculation is really a burden for a
> > > software implementation.  I've seen qualitative assertions
> > > (some vaguer than others) on both sides, but nothing quantitative.
> > > 
> > > RFC 3309 ("Stream Control Transmission Protocol (SCTP) 
> > > Checksum Change")
> > > has an appendix about CRC implementations, and briefly discusses
> > > the issue.  It cites 
> > > 
> > > 	David C. Feldmeier
> > > 	Fast software implementation of error detection codes
> > > 	IEEE Transactions on Networking, vol 3 no 6, pp 640-651,
> > > 		December, 1995. 
> > > 
> > > Unfortunately, measurements made in 1995 on a SPARCstation LX
> > > (27 SPECint932) probably won't mean much in 2003.
> > > 
> > > I spent a little time with CiteSeer and Google trying to find
> > > a more recent study of CRC performance, but I couldn't find
> > > anything.
> > > 
> > > Perhaps someone with a good understanding of software CRC
> > > implementation could do some measurements on modern hardware
> > > that would give a solid quantitative basis for our debate?
> > > For example, one could hack the Linux or *BSD stack to
> > > do a CRC computation on each TCP segment (sent or received),
> > > then throw away the results.  Measuring the performance change
> > > on bulk throughput (say, using netperf) seems like a reasonable
> > > approximation of software CRC costs.
> > > 
> > > -Jeff
> > > 
> > > P.S.: Don't look at me!  I don't have any spare time this month,
> > > nor do I have a "good understanding of software CRC 
> implementation".
> > > _______________________________________________
> > > rddp mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/rddp
> > > 
> > _______________________________________________
> > rddp mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/rddp
> 
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: "Somesh Gupta" <[email-masked]>
Date: Tue, 6 May 2003 13:31:46 -0700

Yes, CRC32 and TCP checksum behave differently in the errors
that escape or that they catch. However, I assume the paper
was quoted to bring up the point of number of TCP checksum
errors encountered in the real world.

I have requested this information before but not had an
answer yet. A number of the participants work in large
corporations that have data centers and systems that stay
up for years. It would be useful to bring the number of
TCP checksum errors encountered in those systems (assuming
they do not have telnet access from outside). In my past
experience, it was practically nill.

Somesh

> From: Barron, Dwight [mailto:[email-masked]]
> Sent: Tuesday, May 06, 2003 1:14 PM
> To: Somesh Gupta; [email-masked]
> I don't agree with that assessment. MPA CRC is layered above the 
> TCP checksum/logic. The key is to have different fault behaviors, 
> e.g. any latent faults in CRC logic are significantly different 
> from the latent faults in the TCP protocol/checksum logic. I 
> believe this independent fault behavior is quite achievable in 
> both layered and roto-tilled implementations.
> 
> Regards,
> Dwight
>

---

From: Michael Krause <[email-masked]>
Date: Tue, 06 May 2003 15:25:10 -0700

>experience, it was practically nill.

- RDDP charter is not restricted to the data center but for all usage modes 
where IP technology may be deployed.

- Many data centers still operate using 100 Mbps links today thus any error 
rates detected may not accurately be projected to remain true when 
operating at 10 Gbps or even 100 Gbps (which are the data rates that will 
be supported during the life span of the RDDP technology).

- Many technologies are choosing to provide strong data integrity for much 
shorter distances than a data center to protect against data corruption 
causing a local DMA to target the wrong memory.  Remote DMA should provide 
similar protections as for local DMA thus providing customers with strong 
end-to-end data integrity.  Sorry to re-iterate but it is critical to 
understand that Remote DMA and local DMA are really only a change in wire 
protocol to state where data should be placed - the semantics are in 
essence the same which is why I strongly back requiring a mandatory 
end-to-end CRC.

Mike