Subject: RE: [rddp] CRC mandatory?

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

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

---

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

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.

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

---

From: Jeffrey Mogul <[email-masked]>
Date: Tue, 06 May 2003 14:05:34 -0700

Dwight Barron wrote:

    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 perfect world, I might agree.  In reality, it might be hard
to get an actual consensus about a specific threshold that everyone
would accept.  My hope/suspicion is that by getting some measurements,
we might simply avoid having a new debate over thresholds.

    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.

Which raises another point: if we can get someone to do software
CRC measurements, it would be helpful to get them from a range
of CPU speeds (e.g., different generations of the same basic
architecture) so that we can get quantitative information about
the effect of Moore's Law on the results.

In general, I agree with you (don't bet against Moore's Law) but
I can see where there might be some future debate about whether
Moore's Law really applies to a specific measurement, and having
credible experimental results for several points on the trend
line might avoid basing the discussion on hypotheticals.

-Jeff