RE: CRC vs CHKSUM presentation slides

[Douglas Otis <dotis@sanlight.net>]

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.

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.

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.

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
>