RE: iSCSI CRC: A CRC-checking example

["CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com>]

Julian, Doug, Steve and others,

OK, I withdraw my recommendation to differ from ethernet in the bit
ordering. It will be easier (and I agree makes better sense) to document
than to convince . I will offer what is hopefully more explicit wording for
the iSCSI document in a couple of days for your consideration. 

In answer to Doug's question about the reason for using the COMPLEMENT of
the remainder of the division as the CRC ....

One reason I recall, is that this method permits the receiver to detect
extra trailing zeroes in the protected packet. If the remainder were sent
directly as the CRC, in the absence of errors the remainder of a similar
computation at the receiver would be expected to be zero. This means that
errors consisting of extra trailing zeroes would not be caught since zero
input bits would cause no changes in the CRC circuit once the CRC register
is in the so called "inaccessible state" consisting of all zeroes.  

Similarly, one reason for initializing the CRC register to 1s instead of
zeroes is to detect extra zeroes at the beginning of hte packet. Once again,
when the CRC register is in the "inaccessible" state of all zeroes it does
not begin to respond until a non-zero input is applied.

Of course this error detection enhancements are not important for iSCSI
since there are other ways to determine if the received packet is of the
expected size but we all agree there are advantages to "doing it the
ethernet way".

Vince




|-----Original Message-----
|From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
|Sent: Wednesday, August 22, 2001 1:29 PM
|To: CAVANNA,VICENTE V (A-Roseville,ex1)
|Cc: 'Mark Bakke'; CAVANNA,VICENTE V (A-Roseville,ex1);
|Pat.Thaler@d12relay01.de.ibm.com; ips@ece.cmu.edu
|Subject: RE: iSCSI CRC: A CRC-checking example
|
|
|Vince & all,
|
|I've added some statement about order (byte and bit) to the 
|draft (you have
|probably missed that piece of the mail).
|
|I could be more graphic and less explicit as in SPI but I 
|think that won't
|help too much.
|
|People did it for ethernet for years without too much ado.
|
|And don't complain to me - IBM did consistent bit ordering for years
|(Big-endian).  IBM even sent ASCII big endian (nobody else did 
|and we had
|to recode for VT100 access).
|
|As for what to choose - It seems that we are in an are where almost
|everybody does it now in this crazy way.
|I strongly suspect that this was also the reason for the way 
|SPI does it.
|They have gone all the way to acommodate
|x86 byte ordering in registers - so that the revert the bytes before
|calculating -and do this on a parallel bus!
|360 was certainly the last bastion of regularity.
|
|Regards,
|Julo
|
|
|"CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com> on
|22-08-2001 20:42:50
|
|Please respond to "CAVANNA,VICENTE V (A-Roseville,ex1)"
|      <vince_cavanna@agilent.com>
|
|To:   Julian Satran/Haifa/IBM@IBMIL, "'Mark Bakke'" <mbakke@cisco.com>
|cc:   "CAVANNA,VICENTE V (A-Roseville,ex1)" 
|<vince_cavanna@agilent.com>,
|      Pat.Thaler@d12relay01.de.ibm.com, ips@ece.cmu.edu
|Subject:  RE: iSCSI CRC: A CRC-checking example
|
|
|
|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
|
|
|
|