Subject: RE: iSCSI: 12-97 Bit Rule

From: "CAVANNA,VICENTE V (A-Roseville,ex1)" <[email-masked]>
Date: Thu, 13 Jun 2002 17:19:09 -0600

I believe Bill is correct. The receiver, unlike the transmitter, should not complement the remainder if he expects to get 0x1c2d19ed.
I am afraid I may be reponsible for this mistake during an email exchange I and others had with Julian recently. Julian and those others must have trusted me a little too much. Sorry Julian and others.
Vince

|-----Original Message-----
|From: Bill Studenmund [mailto:[email-masked]]
|Sent: Thursday, June 13, 2002 2:36 PM
|To: Julian Satran
|Cc: [email-masked]; [email-masked]; [email-masked]
|Subject: Re: iSCSI: 12-97 Bit Rule
|
|
|On Thu, 13 Jun 2002, Julian Satran wrote:
|
|One minor question.
|
|> I took out completely the bit rule.
|> I reformulated the CRC text as:
|>
|> The CRC MUST be calculated by a method that produces the 
|same results as
|> the following process:
|>
|>  - The PDU bits are considered as the coefficients of a 
|polyno-mial M(x) of
|> degree n-1; bit 7 of the lowest numbered byte is considered the most
|> significant bit (x^n-1), followed by bit 6 of the lowest 
|numbered byte and
|> through bit 0 of the high-est numbered byte (x^0).
|>
|> - The most significant 32 bits are complemented.
|>
|> - The polynomial is multiplied by x^32 then divided by G(x). 
|The generator
|> polynomial produces a remainder R(x) of degree <= 31.
|>
|> - The coefficients of R(x) are considered a 32 bit sequence.
|>
|> - The bit sequence is complemented and the result is the CRC.
|
|Call the above step 5.
|
|> - the CRC bits are mapped into the digest word - the x^31 
|coef-ficient in
|> bit 7 of the lowest numbered byte of the digest continuing 
|to through the
|> byte up to the x^24 coefficient in bit 0 of the lowest numbered byte,
|> continuing with the x^23 coefficient in bit 7 of next byte 
|through x^0 in
|> bit 0 of the highest numbered byte.
|>
|> - Computing the CRC over any segment (data or header) 
|extended to include
|> the CRC built using the generator 0x11edc6f41 will get 
|always the value
|> 0x1c2d19ed as its final CRC. This value is given here in its 
|polynomial
|> form - i.e. not mapped as the digest word
|
|About the use of "final CRC" with respect to 0x1c2d19ed. Step 
|5 says the
|"CRC" is after the complementation, but my experiments indicate that
|0x1c2d19ed is the uncomplimented result, and that the 
|complimented result
|would be 0xe3d2e612. Thus 0xe3d2e612 would be the "CRC."
|
|> I hope you will find it less confusing
|
|I'm not sure what to do. The thoughts which come to my mind 
|take up space.
|The simplest would be to mention what coefficents one uses in 
|well-known
|crc packages. A more complex one would be to include source 
|code, as the
|sctp crc draft did.
|
|Take care,
|
|Bill
|

---

From: Bill Studenmund <[email-masked]>
Date: Thu, 13 Jun 2002 16:46:21 -0700 (PDT)

On Thu, 13 Jun 2002, CAVANNA,VICENTE V (A-Roseville,ex1) wrote:

> I believe Bill is correct. The receiver, unlike the transmitter,
> should not complement the remainder if he expects to get 0x1c2d19ed.
>
> I am afraid I may be reponsible for this mistake during an email
> exchange I and others had with Julian recently. Julian and those
> others must have trusted me a little too much. Sorry Julian and
> others.

It seems like we're changing the text to be clearer for some folks, and
unfortunately making it more confusing for others. It's like trying to
catch an eel, as soon as we get a second hand on it, it pops out of the
first.

In addition to fixing the above, to be perfectly clear, perhaps we should
mention that when calculating the CRC over a correctly recevied message +
CRC, were the receiver to append the result of this calculation to the
received message + CRC, it would always append the octed stream "c7 4b 67
48". This example is meant in the spirit of section B.4 where we have
clear octets to compare against. Actually this bit should probably go in
section B4 at the end.

Take care,

Bill

---

From: Luben Tuikov <[email-masked]>
Date: Thu, 13 Jun 2002 20:43:05 -0400

> I am afraid I may be reponsible for this mistake during an email exchange I and others had with Julian recently. Julian and those others must have trusted me a little too much. Sorry Julian and oth…

Vince, you had it right. The text was mentioning that it was the CRC that
was the magic constant, and since the CRC is complemented in the course of
computation, one more was needed to get ``back'' to the remainder.

Yes, Bill, your empirical conclusion is correct.

The magic constant _is_ the pure remainder in polynomial
form (0x1c2d19ed).

The CRC is the complemented (and byte mirrored) remainder.

That is: you have 2 algoritms, one to compute the pure
remainder, and another to complement it (and maybe byte-mirror)
and inject it at the end of the message to be sent.

The sender does both algorithms (compute and inject),
and the receiver does just the first (compute) and compares
the result with the magic value.

This has already been mentioned in a more formal (and
maybe confusing :-)) manner in an email from me at the
beginning of this thread (take a look at it, the one
with bit-sequences).

-- 
Luben