RE: CRC vs CHKSUM presentation slides

[vince_cavanna@agilent.com]

Hello Doug,
I have inserted my comments below.
Vince


|-----Original Message-----
|From: Douglas Otis [mailto:dotis@sanlight.net]
|Sent: Thursday, March 22, 2001 3:16 PM
|To: Mark Bakke; CAVANNA,VICENTE V (A-Roseville,ex1)
|Cc: ips@ece.cmu.edu; ipsan@rtl.rose.agilent.com
|Subject: RE: CRC vs CHKSUM presentation slides
|
|
|Mark,
|
|One small note on these slides.  Although the number of instructions
|required to implement CRC-32 with 128K table lookups compares 
|closely to
|that of Adler-32, Adler-32 is not accessing a 128K byte lookup 
|table.  These
|slides made a comparison of instructions without considering additional
|memory access required or the size of the table required.

I am not sure what comparison you are referring to since I did not compare
the cost of implementing Checksums against that of implementing CRCs. All I
compared was the cost, in gates (not table size), of a complex CRC vs that
of a simple CRC.

|
|If you were to use the same CRC-32, you will find the same levels of
|protection as this CRC is to protect against various types of equipment
|failures NOT protected by the Ethernet/FDDI/Fibre-Channel CRC, then a
|replication of this polynomial should not be a problem in that 
|sense.  For
|those that wish to include a different polynomial tend to justify this
|effort by indicating this would improve the present physical 
|layer checks.
|
|The problem that I see with that conclusion is errors seen 
|outside of any
|potential Ethernet CRC failure are of such orders of magnitude as to
|out-weight any replicate benefit derived.  In that light, even 
|Adler-32 may
|provide benefit in that case.  The next area being looked at 
|is the number
|of bits detected in a burst error.  The unprotected equipment 
|is not likely
|using a serial method of delivery, so you are again left 
|errors that may
|provide strange error patterns.  The concept supporting a different
|polynomial was its greater ability to detect burst errors.

If I understand you correctly you are saying that the ethernet polynomial is
good enough to protect against the type of errors iSCSI needs to provide
protection for. I agree. My main argument for wanting a simple (standard)
polynomial is that I would like to take advantage of the lower cost in gate
count.

|
|The large piece of information missing from this presentation was a
|characterization of the types of errors seen by intermediate equipment.
|There was a bullet that suggested this equipment will produce 
|burst errors.
|If so, what is the nature of this equipment and what are the prevalent
|errors?  From that perspective a comparisons could be made.  
|But as we are
|familiar with noise distributions of single bit errors, this became our
|focus.  It is a bit like looking for your keys under the light 
|post even
|though you dropped them in the dark.  You wish to look where 
|the light is
|better.

I give a lot more detail on small number of single bit errors and small
number of bursts because there is theory that I can use to analyze those
cases. Like you and others, I have struggled with the claims that it is
important for iSCSI to provide protection from small number of errors. I
have finally convinced myself that small number of errors are probable even
in our environment. In my slides I outlined several important error
mechanims that tend to produce few number of individual errors. Here are
some I can think of at the moment:

1. Random memory errors.
2. Marginal timing paths in the hardware.
3. Noise (crosstalk, power supply noise).
4. Leakage problems in bistable devices due to manufacturing defects.
5. Hardware degradation.


Of course there are also possible error patterns that contain lots of errors
and unfortunately I cannot say much about about them other than that 1 in
2^32 (if all errors are equiprobable) will get through both checksums and
CRCs and that those that get through the CRC are more random looking than
those that get through the Checksums.

|
|Doug
|
|> Vicente-
|>
|> I just took another look through your slides after seeing the
|> presentation on Monday.  They were very well-done.  I have
|> one question, though.  If the CCITT-CRC32 is considered "good
|> enough", then would the Ethernet CRC32 also be good enough?  The
|> reason I ask is that every hardware vendor involved in building
|> iSCSI stuff already has implementations of the Ethernet CRC,
|> which is used for both Ethernet and Fibre Channel.
|>
|> The Ethernet poly has more terms than CCITT, and perhaps is
|> not as good as CRC-32C (any thoughts?), but everyone has hardware
|> and software for this, with proven interoperability (bit and
|> byte order, etc).  Performance-wise, it will be there for
|> 10Gb Ethernet, so it should be fast enough.
|>
|> So if the Ethernet poly is deemed good enough (even if it's not
|> the best), and fast enough (even if it's not the fastest), why
|> not use it?  I think we would stand a much better chance of
|> achieving interoperability in a short time.
|>
|> Please let me know what you think of this; I realize that a few
|> of my questions were speculative.
|>
|> Regards,
|>
|> Mark
|>
|> "CAVANNA,VICENTE V (A-Roseville,ex1)" wrote:
|> >
|> > Here are the slides I presented at the IETF-50 in Minneapolis.
|> >
|> > Vicente Cavanna
|> > Agilent Technologies
|> >
|> >  <<CRCorChksm.pdf>>
|> >
|> >
|> ------------------------------------------------------------------
|> ----------------------------------
|> >                      Name: CRCorChksm.pdf
|> >    CRCorChksm.pdf    Type: Portable Document Format 
|(application/pdf)
|> >                  Encoding: base64
|>
|> --
|> Mark A. Bakke
|> Cisco Systems
|> mbakke@cisco.com
|> 763.398.1054
|>
|