Subject: iSCSI CRC inconsistency

From: [email-masked]
Date: Tue, 4 Jun 2002 14:31:21 -0600

Julian,

There is an inconsistency in the description of the CRC32. In 11.1, the final paragraph on page 207 is incorrect. The paragraph says:
- The CRC bits appear after the message bits with x^31 first
followed by x^30 etc. (when examples are provided, the value
to be specified in the examples follows the same
ordering as the rest of this document).

At the top of the next page, it describes the magic number CRC check where one runs the CRC generator over the data or header plus the received digest and gets the magic number:
- A receiver of a "good" segment (data or header) including the
CRC built using the generator 0x11edc6f41 will get the value
0x1c2d19ed as its CRC (this is a polynomial value and not a
word as outlined in this draft).

The point of the magic number algorithm is that it uses exactly the same algorithm to check the CRC that was used to generate the CRC. When running the check, the received CRC is run through the generator with the same bit order as the covered data. Therefore, this check only works right when the CRC is appended to the data using the same bit ordering within a word as was used when sending the covered data through the CRC generator. The examples in B.4 show the bits ordered as they should be and page 207 is inconsistent with them..

Specifically, data bits go through the generator from byte 0 to byte 3 of the word with each bit going through bit 7 to bit 0. Therefore, paragraph on how the CRC bits are placed in the field should be:
- The CRC bits appear after the message bits with the x^31 coefficient in bit 7 of the first byte (byte 0) of the digest continuing to through the byte the x^24 coefficient in bit 0 of byte 0, continuing with the x^23 coefficient in bit 7 of byte 1, etc. (When examples are provided they show the CRC as it appears in the PDU with the bit significance used throughout this document. That is, bit 7 of each byte is interpreted as most significant though it is the coefficient of the lowest order CRC term in the byte.).

I have checked and this order matches the examples in B.4.

Regards,
Pat

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 5 Jun 2002 20:21:14 +0300

... and I know the examples are correct - I run them through two programs 
! - Julo

[email-masked]
06/04/2002 11:31 PM
Please respond to pat_thaler

        To:     Julian Satran/Haifa/IBM@IBMIL, [email-masked]
        cc: 
        Subject:        iSCSI CRC inconsistency

Julian,

There is an inconsistency in the description of the CRC32. In 11.1, the 
final paragraph on page 207 is incorrect. The paragraph says:
- The CRC bits appear after the message bits with x^31 first
followed by x^30 etc. (when examples are provided, the value
to be specified in the examples follows the same
ordering as the rest of this document).

At the top of the next page, it describes the magic number CRC check where 
one runs the CRC generator over the data or header plus the received 
digest and gets the magic number:
- A receiver of a "good" segment (data or header) including the
CRC built using the generator 0x11edc6f41 will get the value
0x1c2d19ed as its CRC (this is a polynomial value and not a
word as outlined in this draft).

The point of the magic number algorithm is that it uses exactly the same 
algorithm to check the CRC that was used to generate the CRC. When running 
the check, the received CRC is run through the generator with the same bit 
order as the covered data. Therefore, this check only works right when the 
CRC is appended to the data using the same bit ordering within a word as 
was used when sending the covered data through the CRC generator. The 
examples in B.4 show the bits ordered as they should be and page 207 is 
inconsistent with them..

Specifically, data bits go through the generator from byte 0 to byte 3 of 
the word with each bit going through bit 7 to bit 0. Therefore, paragraph 
on how the CRC bits are placed in the field should be:
- The CRC bits appear after the message bits with the x^31 coefficient in 
bit 7 of the first byte (byte 0) of the digest continuing to through the 
byte the x^24 coefficient in bit 0 of byte 0, continuing with the x^23 
coefficient in bit 7 of byte 1, etc. (When examples are provided they show 
the CRC as it appears in the PDU with the bit significance used throughout 
this document. That is, bit 7 of each byte is interpreted as most 
significant though it is the coefficient of the lowest order CRC term in 
the byte.).

Regards,
Pat

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 5 Jun 2002 20:21:14 +0300

Pat,

I was referring to a hypothetical wire order and that matches the order I 
stated in the first list element.
I will try to map it to the word order as the wire order is not relevant 
anyhow.
The magical number is however a polynomial and not a word mapping.

Julo

[email-masked]
06/04/2002 11:31 PM

Julian,

Regards,
Pat

---

From: [email-masked]
Date: Wed, 5 Jun 2002 11:28:46 -0600

Julian,
 
Yes, magic number is stated in polynomial order and the accompanying text says that so I have no
problem with the magic number text.
 
It is only the description of how the CRC is placed into the message that needs correction/clarification.
As you say, hypothetical wire order is not relevant. We need to specify with respect to iSCSI's defined
word order.
 
Regards,
Pat
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 10:21 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: iSCSI CRC inconsistency

Pat, 

I was referring to a hypothetical wire order and that matches the order I stated in the first list element. 
I will try to map it to the word order as the wire order is not relevant anyhow. 
The magical number is however a polynomial and not a word mapping. 

Julo 

	[email-masked] 

06/04/2002 11:31 PM 

Julian,

Regards,
Pat

---

From: "CAVANNA,VICENTE V (A-Roseville,ex1)" <[email-masked]>
Date: Thu, 6 Jun 2002 15:08:35 -0600

Julian,
I concur with Pat's request for explicit mapping of the bits of the remainder polynomial to the bits of the CRC. I had pointed out the need for such explicit mapping, to resolve ambiguity in the process, in a memo on Aug 22, 2001. In that memo I also objected to the bit reflection but I later retracted that objection. I also outlined, in a memo on Nov. 27, 2001, how I would describe the CRC process at the transmitter and receiver to resolve the ambiguity. The particular step in the process that Pat pointed out is missing from the iSCSI spec, is the reversing of bits (bit reflection) within each byte of the remainder of the modular division. As Pat pointed out, the examples shown in the spec *do* assume this bit reversal, but the process steps in the spec seem to indicate no bit reversal. The wording that Pat is recommending seems accurate to me and is a good alternative to what I had suggested.
Regards,
Vince

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 10:29 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: iSCSI CRC inconsistency

Julian,

 
Regards,
Pat
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 10:21 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: iSCSI CRC inconsistency

Pat, 

Julo 

	[email-masked] 

06/04/2002 11:31 PM 

Julian,

Regards,
Pat

Subject: RE: iSCSI CRC: A CRC-checking example
From: "CAVANNA,VICENTE V (A-Roseville,ex1)" <[email-masked]>
To: 'Julian Satran' <[email-masked]>, 'Mark Bakke' <[email-masked]>
Cc: "CAVANNA,VICENTE V (A-Roseville,ex1)" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Wed, 22 Aug 2001 11:42:50 -0600

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  

Subject: Re: iSCSI v8 CRC32c
From: "CAVANNA,VICENTE V (A-Roseville,ex1)" <[email-masked]>
To: 'Luben Tuikov' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "THALER,PAT (A-Roseville,ex1)" <[email-masked]>, "CAVANNA,VICENTE V (A-Roseville,ex1)" <[email-masked]>
Date: Tue, 27 Nov 2001 19:39:49 -0600

Luben,

Your questions may have already been answered by Paul Koning who has apparently reviewed your code in detail but attached, as I promised, is a Mathematica worksheet (pdf format) that produces results consistent with the iSCSI spec. You do not need to know the syntax of Mathematica in order to follow the process, as I have inserted lots of comments.

The example I describe uses, as data, 32 decrementing bytes. This is one of hte test cases in the iSCSI document. I have added an undetectable error pattern which does not change the results obtained at the receiver. I think it would be useful to include, in the iSCSI document, such an undetectable error pattern.

I am considering writing an informative Internet Draft describing the process. I would incorporate the contents of the attached worksheet and also explain the theory behind the process. This should answer such questions as why is the expected remainder at the receiver the constant 1c 2d 19 ed in hex.  If you or others have suggestions let me know.

For those not interested in the math I summarize the process below.

Vicente Cavanna
Agilent Technologies

The symbols I use:
------------------

G is the iSCSI CRC32c polynomial.

L32 is the order-32 poly represting all 1s.

F is the poly representing 32 decrementing bytes which I will use as my test data.

ReflectedF is the poly representing F, after reversing the order of bits within each byte.

R is the remainder of the division performed at the transmitter.

ReflectedR is the poly obtained by reversing the order of bits within each byte of R.

FCS is the complement of ReflectedR. This is the CRC that you would compare with the iSCSI document. In the case of this example of 32 decrementing bytes the FCS is a7 e4 e4 ae in hex.

M is the transmitted message before injecting errors.

Error is the error pattern that I add to M. I use G+x^5*G after applying reflection. Any linear combination of Gs will similarly be undetected.

M* is the received message.

ReflectedM* is M* with the order of bits within each byte reversed.

Rec is the computed CRC at the receiver. You would expect 1c2d19ed in the absence of errors or if error pattern is undetectable as is the case in my example.

The process, for the case of no errors, is as follows:
------------------------------------------------------

At the transmitter:
----------------------

F is the data.

Reverse bits within each byte of F to obtain ReflectedF.

Shift ReflectedF left by 32 positions.

Add 1's to most significant 32 bits of the result (implemented by initializing CRC register to 1's).

Divide by G to obtain the 32 bit remainderR. Note that R is not the CRC shown in iSCSI document!

Reverse bits within each byte of R to obtain ReflectedR.

Add 32 1's to the result to obtain the FCS (implemented by complementing). This is what is shown in the iSCSI document and, for this example, is a7 e4 e4 ae in hex.

Form the transmitted message, M, by shifting F left by 32 positions and adding FCS. Note that M is derived from F rather than from ReflectedF even though the FCS is computed from ReflectedF.

M* is hte same as M since we are not introducing errors here. See the Mathematica worksheet for the case with (undetectable) errors.

At the receiver:
----------------

Receive M*

Reverse bits within each byte of M* to obtain ReflectedM*.

Shift the result left by 32 positions.

Add 1's to most significant 32 bits of result (implemented by initializing CRc to 1's).

Divide by G to obtain the remainder, Rec. The result (for the case of no errors) is expected to be the constant 1c 2d 19 ed in hex.

In the Mathcad worksheet I actually introduce an undetectable error pattern, G+G*x^5, which I reflect and add to M to obtain M*. The rest is the same. Note that the error must also be "reflected". See the worksheet for details.

 <<TestingCRC32cDecrBytePattern.pdf>>

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 7 Jun 2002 00:49:34 +0300

I did it already for CRC - it will appear tomorrow on 12-97 - Julo

"CAVANNA,VICENTE V (A-Roseville,ex1)" <[email-masked]>
06/07/2002 12:08 AM
Please respond to "CAVANNA,VICENTE V (A-Roseville,ex1)"

        To:     "THALER,PAT (A-Roseville,ex1)" <[email-masked]>, Julian 
Satran/Haifa/IBM@IBMIL
        cc:     [email-masked], "CAVANNA,VICENTE V (A-Roseville,ex1)" 
<[email-masked]>
        Subject:        RE: iSCSI CRC inconsistency

Julian,
I concur with Pat's request for explicit mapping of the  bits of the 
remainder polynomial to the bits of the CRC. I had pointed out the  need 
for such explicit mapping, to resolve ambiguity in the process, in a memo 
on Aug 22, 2001. In that memo I also objected to the bit reflection but I 
later retracted that objection. I also outlined, in a memo on Nov. 27, 
2001, how I would describe the CRC process at the transmitter and receiver 
 to resolve the ambiguity. The particular step in the process that Pat 
pointed out is missing from the iSCSI spec, is the reversing of bits (bit 
reflection) within each byte of the remainder of the modular division. As 
Pat pointed out, the examples shown in the spec *do* assume this bit 
reversal,  but the process steps in the spec seem to indicate no bit 
reversal. The wording  that Pat is recommending seems accurate to me and 
is a good alternative to  what I had suggested.
Regards,
Vince
-----Original Message-----
From: [email-masked]  [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 10:29  AM
To: [email-masked];  [email-masked]
Cc: [email-masked]
Subject: RE:  iSCSI CRC inconsistency

Julian,
 
Yes,  magic  number is stated in polynomial order and the accompanying 
text says that so I  have no
problem with the  magic number text.
 
It is only the  description of how the CRC is placed into the message that 
needs  correction/clarification.
As you say,  hypothetical wire order is not relevant. We need to specify 
with respect to  iSCSI's defined
word  order.
 
Regards,
Pat
-----Original Message-----
From: Julian Satran  [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002  10:21 AM
To: [email-masked]
Cc:  [email-masked]
Subject: Re: iSCSI CRC  inconsistency

Pat, 

Julo 

[email-masked] 

06/04/2002 11:31 PM 

Julian,

At the top of the next page, it describes the magic number  CRC check 
where one runs the CRC generator over the data or header plus the received 
digest and gets the magic number:
- A receiver of a "good" segment  (data or header) including the
CRC built using the generator 0x11edc6f41  will get the value
0x1c2d19ed as its CRC (this is a polynomial value and  not a
word as outlined in this draft).

The point of the magic number  algorithm is that it uses exactly the same 
algorithm to check the CRC that was  used to generate the CRC. When 
running the check, the received CRC is run  through the generator with the 
same bit order as the covered data. Therefore,  this check only works 
right when the CRC is appended to the data using the  same bit ordering 
within a word as was used when sending the covered data  through the CRC 
generator. The examples in B.4 show the bits ordered as they  should be 
and page 207 is inconsistent with them..

Specifically, data  bits go through the generator from byte 0 to byte 3 of 
the word with each bit  going through bit 7 to bit 0. Therefore, paragraph 
on how the CRC bits are  placed in the field should be:
- The CRC bits appear after the message bits  with the x^31 coefficient in 
bit 7 of the first byte (byte 0) of the digest  continuing to through the 
byte the x^24 coefficient in bit 0 of byte 0,  continuing with the x^23 
coefficient in bit 7 of byte 1, etc. (When examples  are provided they 
show the CRC as it appears in the PDU with the bit  significance used 
throughout this document. That is, bit 7 of each byte is  interpreted as 
most significant though it is the coefficient of the lowest  order CRC 
term in the byte.).

Regards,
Pat

Message-ID: <[email-masked]>
From: "CAVANNA,VICENTE V (A-Roseville,ex1)" <[email-masked]>
To: 'Julian Satran' <[email-masked]>, 'Mark Bakke' 
<[email-masked]>
Cc: "CAVANNA,VICENTE V (A-Roseville,ex1)" <[email-masked]>, 
"[email-masked]'" <[email-masked]>, 
"[email-masked]'" <[email-masked]>
Subject: RE: iSCSI CRC: A CRC-checking example
Date: Wed, 22 Aug 2001 11:42:50 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; 
boundary="----_=_NextPart_003_01C20D9E.520490E0"

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  

Message-ID: 
<[email-masked]>
From: "CAVANNA,VICENTE V (A-Roseville,ex1)" <[email-masked]>
To: 'Luben Tuikov' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "THALER,PAT (A-Roseville,ex1)"  
<[email-masked]>, "CAVANNA,VICENTE V (A-Roseville,ex1)" 
<[email-masked]>
Subject: Re: iSCSI v8 CRC32c
Date: Tue, 27 Nov 2001 19:39:49 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; 
boundary="----_=_NextPart_002_01C20D9E.520490E0"

Luben, 

Your questions may have already been answered by Paul Koning who has 
apparently reviewed your code in detail but attached, as I promised, is a 
Mathematica worksheet (pdf format) that produces results consistent with 
the iSCSI spec. You do not need to know the syntax of Mathematica in order 
to follow the process, as I have inserted lots of comments.

The example I describe uses, as data, 32 decrementing bytes. This is one 
of hte test cases in the iSCSI document. I have added an undetectable 
error pattern which does not change the results obtained at the receiver. 
I think it would be useful to include, in the iSCSI document, such an 
undetectable error pattern.

I am considering writing an informative Internet Draft describing the 
process. I would incorporate the contents of the attached worksheet and 
also explain the theory behind the process. This should answer such 
questions as why is the expected remainder at the receiver the constant 1c 
2d 19 ed in hex.  If you or others have suggestions let me know.

Vicente Cavanna 
Agilent Technologies 

The symbols I use: 
------------------ 

F is the poly representing 32 decrementing bytes which I will use as my 
test data. 

ReflectedF is the poly representing F, after reversing the order of bits 
within each byte. 

ReflectedR is the poly obtained by reversing the order of bits within each 
byte of R. 

FCS is the complement of ReflectedR. This is the CRC that you would 
compare with the iSCSI document. In the case of this example of 32 
decrementing bytes the FCS is a7 e4 e4 ae in hex.

Error is the error pattern that I add to M. I use G+x^5*G after applying 
reflection. Any linear combination of Gs will similarly be undetected.

Rec is the computed CRC at the receiver. You would expect 1c2d19ed in the 
absence of errors or if error pattern is undetectable as is the case in my 
example.

At the transmitter: 
---------------------- 

F is the data. 

Add 1's to most significant 32 bits of the result (implemented by 
initializing CRC register to 1's). 

Divide by G to obtain the 32 bit remainderR. Note that R is not the CRC 
shown in iSCSI document! 

Add 32 1's to the result to obtain the FCS (implemented by complementing). 
This is what is shown in the iSCSI document and, for this example, is a7 
e4 e4 ae in hex.

Form the transmitted message, M, by shifting F left by 32 positions and 
adding FCS. Note that M is derived from F rather than from ReflectedF even 
though the FCS is computed from ReflectedF.

M* is hte same as M since we are not introducing errors here. See the 
Mathematica worksheet for the case with (undetectable) errors.

At the receiver: 
---------------- 

Receive M* 

Add 1's to most significant 32 bits of result (implemented by initializing 
CRc to 1's). 

Divide by G to obtain the remainder, Rec. The result (for the case of no 
errors) is expected to be the constant 1c 2d 19 ed in hex.

In the Mathcad worksheet I actually introduce an undetectable error 
pattern, G+G*x^5, which I reflect and add to M to obtain M*. The rest is 
the same. Note that the error must also be "reflected". See the worksheet 
for details.

#### TestingCRC32cDecrBytePattern.pdf has been removed from this note on 
June 07 2002 by Julian Satran