Subject: RE: [rddp] CRC mandatory?

From: John Hufferd <[email-masked]>
Date: Tue, 6 May 2003 17:12:17 -0700

Somesh,
You and I have had this discussion many times.  And I have said that when 
you combine the results of that paper with the increase in speed that is 
now here and coming in the future,  that it make a strong statement that 
CRC32c type checks are needed.

As you know we made CRC32c  a "MUST implement,, optional to use" in iSCSI. 
 I have found no one within my company that would ever suggest to our 
customers that they should operate with CRC32c turned off.  I have not 
heard that from our competitors either.  In other words, we made a big 
deal of making it optional in iSCSI, but the folks that focus exclusively 
on storage, have, as far as I can determine made these checks the defacto 
way things operate.

As you also know some folks are attempting to make an adaption which will 
enable iSCSI to operate with RDMA, however, without CRC32c covering the 
headers and data being a "required to implement" this would not be 
possible.

The point that Caitlin and others are making is (in my opinion) that there 
are a number of applications that feel a CRC32c digest is needed.  And we 
will have to make CRC32c at least a "required to implement (optional to 
use)", and that negotiating such an option is not worth the testing effort 
for the negation itself nor the testing that must occur at run time with 
each side having negotiated different options, etc..  Also they are 
stating that from their point of view, the requirement from customers such 
as my company, makes it a hard requirement.  And since we and our 
competitors require such capability, the RNIC vendor needs to supply it 
even if some folks, like yourself, believe it is only a need spun from an 
urban legend that is causing the perceived need.

So I think we should at least agree that it needs to be a MUST implement, 
and then focus on whether it needs to be optional to use.

I personally do not want make it  optional, and want to ensure that the 
whole packet is covered.

.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: [email-masked]

"Somesh Gupta" <[email-masked]>
Sent by: [email-masked]
05/06/2003 12:33 PM

        To:     "Barron, Dwight" <[email-masked]>, "Mogul, Jeffrey (HPL Palo Alto)" 
<[email-masked]>, <[email-masked]>
        cc: 
        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: Wed, 7 May 2003 09:50:52 -0700

John,

As far as Silverback products are concerned, header as well as data CRC is
supported at our high performance levels. (And as a IHV, it is great if
everyone
will use CRC all the time because it increases the CPU overhead and the need
for NICs). I wish we can focus on the technical debate and leave any
insinuations
about specific company products etc out of this.

However, there are a number of products out there that do not support CRC.
You may not consider them competitors, but that is not an argument I can
get into.

IPSec is also mandatory to implement and optional to use. A reasonable
section
of the community also feels that for iSCSI to have widespread deployment,
IPSec
is a more important technology than some of the other features. And if IPSec
gets deployed, an additional CRC becomes meaningless.

IPSec is also something that the RDMA community will have to deal with.
Customers
are likely to be very concerned about any security holes being exposed as a
result
of out of order placement without authentication of the sender.

My position has been of having an optional CRC - not of not having a CRC.

Somesh
  -----Original Message-----
  From: John Hufferd [mailto:[email-masked]]
  Sent: Tuesday, May 06, 2003 5:12 PM
  To: Somesh Gupta
  Cc: Barron, Dwight; Mogul, Jeffrey (HPL Palo Alto); [email-masked];
[email-masked]

  Somesh,
  You and I have had this discussion many times.  And I have said that when
you combine the results of that paper with the increase in speed that is now
here and coming in the future,  that it make a strong statement that CRC32c
type checks are needed.

  As you know we made CRC32c  a "MUST implement,, optional to use" in iSCSI.
I have found no one within my company that would ever suggest to our
customers that they should operate with CRC32c turned off.  I have not heard
that from our competitors either.  In other words, we made a big deal of
making it optional in iSCSI, but the folks that focus exclusively on
storage, have, as far as I can determine made these checks the defacto way
things operate.

  As you also know some folks are attempting to make an adaption which will
enable iSCSI to operate with RDMA, however, without CRC32c covering the
headers and data being a "required to implement" this would not be possible.

  The point that Caitlin and others are making is (in my opinion) that there
are a number of applications that feel a CRC32c digest is needed.  And we
will have to make CRC32c at least a "required to implement (optional to
use)", and that negotiating such an option is not worth the testing effort
for the negation itself nor the testing that must occur at run time with
each side having negotiated different options, etc..  Also they are stating
that from their point of view, the requirement from customers such as my
company, makes it a hard requirement.  And since we and our competitors
require such capability, the RNIC vendor needs to supply it even if some
folks, like yourself, believe it is only a need spun from an urban legend
that is causing the perceived need.

  .
  .
  John L. Hufferd

                To:        "Barron, Dwight" <[email-masked]>, "Mogul,
Jeffrey (HPL Palo Alto)" <[email-masked]>, <[email-masked]>
                cc:
                Subject:        RE: [rddp] CRC mandatory?