RE: CRC vs CHKSUM presentation slides

[Douglas Otis <dotis@sanlight.net>]

Vince,

Sorry, I had confused a comparison made by Julian with yours.  There they
compared the number of instructions without considering expense of accessing
a large lookup.  How do you view the TCP checksum related to various CRC
susceptible errors?

Doug

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