iSCSI: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI

[Paul Koning <ni1d@arrl.net>]

>>>>> "Luben" == Luben Tuikov <ltuikov@yahoo.com> writes:

 Luben> --- Paul Koning <ni1d@arrl.net> wrote:
 >> Excerpt of message (sent 14 December 2001) by Luben > This is
 >> actually equivalent to XORing the first > 32 bits of the message
 >> with the magic constant as Vince > and I have shown.
 >> 
 >> Are you saying that you believe the intent of the current spec is
 >> NOT the same as the Ethernet CRC, i.e., complement the first 32
 >> bits, multiply by x^32, then divide by G(x)?

 Luben> In our profession we cannot talk about beliefs and intentions,
 Luben> more so for documents, rfc, etc.

 Luben> If you show the current description of the CRC of the draft to
 Luben> a mathematician, they will object to the same thing I've
 Luben> objected.

 Luben> ...
 Luben> In its current form the description of the algorithm to
 Luben> compute the CRC in the iSCSI draft is not consistent, just
 Luben> because there is an unspoken assumption that a SMD circuit
 Luben> will be used. We cannot afford to do this in a definition
 Luben> document, unless we refer explicitly to it. We cannot even
 Luben> assume that a circuit will be used...

I agree that the current description is not consistent and is
confusing.  That's why I proposed replacement text.  I'd be interested
in comments on that text.

 Luben> Please also note that the Ethernet spec CRC algorithm, is an
 Luben> optimized version of a basic prefix-postfix-initialize-the-
 Luben> CRC-register-to-some-constant algoritm.

I'm not sure what spec you're talking about.

The algorithm in the Ethernet spec (section 6.2.4) which was copied
into the 802.3 spec (section 3.2.8) pretty much verbatim except for a
typo, is not a prefix-postfix-whatever algorithm at all.  Instead, it
is a mathematical definition of the CRC value.  The phrase "initialize
the CRC register" does not occur at all in any form.

 Luben> ...
 Luben> TX: 1. Mutliply the message, M(x), by x^32.  2. Prefix the
 Luben> result of 1. with 0x2a26f826.  3. Find the remainder of the
 Luben> result of 2.  4. Complement that remainder and add it to the
 Luben> result of 1.  5. Send the result of 4. to the recipient.

 Luben> RX: (same as steps 1-3 in TX) 1. Mutliply the message by x^32.
 Luben> 2. Prefix the result of 1. with 0x2a26f826.  3. Find the
 Luben> remainder of the result of 2.

If I understand right, this is a mathematically equivalent way of
describing an Ethernet-style CRC.

Fine, no problem.  But what's the point?  All we need is a single
formal definition.  And it would make the most sense for that
definition to look like the ones found in other standards, so it will
be clear to the reader that the CRC in iSCSI is the same as the one
used in many other places except for the G(x).  The text I proposed
does that, since it uses the classic text except for G(x).  The
description you gave may be mathematically equivalent, but that is not
at all obvious unless you're fluent in abstract math.

In any case, no mathematical description by itself translates easily
to an implementation (again, unless you're fluent in abstract math).
Most specs disregard that concern and leave it up to the implementer
to search the literature.  My current proposal is to do likewise for
iSCSI.  The only exception I've seen is the Ethernet spec, which gives
a single example implementation in its appendix.  

     paul