RE: iSCSI CRC: A CRC-checking example

["Douglas Otis" <dotis@sanlight.net>]

Vince,

The table reflection is a good thing as it actually reduces the instructions
required within the algorithm.

For the non-reflected table lookup you have:
CRC32(c,d) (c=(c<<8)^crc32tab[(c>>24)&0xFF])

For the reflected table lookup you have:
CRC32(c,d) (c=(c>>8)^crc32tab[(c^(d))&0xFF])

In addition, for storage with a little endian processor, there is no need to
exchange byte order to store in big endian order as the reflected table has
already provided that byte order.

The only thing that I think should be considered is whether the CRC is
stored inverted.

Julian has already responded to my query on this subject with this
statement:

"The 2 "additions" you will find in the CRC calculation:

   initializing the "remainder" field with all ones
   (instead of the implied shifting in of 0's) and
   XORing the result with a mask (usually "full house")

are done to improve the error correction capabilities of CRCs.
CRCs are weak in detecting the spurious addition of leading 0s (that can
result from clocking errors) and the deletion of initial 1 with spurious
insertion of a 1 at the end."

If the CRC is initialized with all one's at the beginning, I fail to see the
need to invert before storing the CRC as this ensures there will be a
pattern created even with an all zeros block.  How does inverting this
pattern aid in detecting errors?

Doug


> Julian and Mark and others,
>
> After I took into account the bit "reflection"  and the byte order (Big
> Endian on Bytes and Little Endian on bits) I did finally obtain, using
> polynomial math, the (corrected) results you show in the CRC examples. The
> results have also been confirmed independently by an implementor here at
> Agilent.
>
> I am the one who originally suggested to Julian that we specify the CRC
> algorithm the same way as in ethernet even though for iSCSI it is
> not really
> important to initialize the CRC register to all 1s and to
> complement the CRC
> before transmission since there are other means to detect extra or missing
> PDU bytes. However I had not realzied until recently that conformance with
> the ethernet algorithm implies bit reflection. I had not been
> aware that in
> ethernet the bits are sent out on the serial link with the least
> significant
> bit first AND that the corresponding message polynomial is formed from the
> bits in the sequence that they appear on the serial link; thus
> the need for
> bit "reflection".
>
> Now that I understand the need for bit reflection (taken into
> account in the
> rocksoft parameterized CRC generator by setting the in and out reflection
> flag parameters to TRUE) I am not sure I agree that we want it in
> iSCSI. The
> penalty for full conformity with ethernet seems too great. If people feel
> strongly that we must keep the bit reflection I think that to make the
> existing documentation clear and unambiguous we would need to explicitly
> show the mapping of bits in the iSCSI PDU to coefficients of the message
> polynomial that represents the iSCSI PDU. We would also need to show the
> mapping of the CRC bits to the coefficients of its representative
> polynomial.
>
> If you don't agree I will elaborate further later this week to try to
> convince you. My objective is to be able to easily and unambiguously
> describe the polynomial math behind the algorithm; right now, with the bit
> reflection and without the explicit mapping it is awkward.
>
> Vince
>
>