Re: iSCSI: CRC-64 a "MUST"?

[julian_satran@il.ibm.com]

Venkat,

We will discuss this at Minneapolis. The draft you are quoting is very weak
on numbers.
We don't have any good candidate for a CRC-64 but we have a (new) CRC-32
that can work up to blocks of 2^31-1 bits with the same protection level we
had with IEEE-802 or with CRC32Q up to 64kbits.
Than could satisfy the most exacting needs for a while and we can put to
rest the CRC-64 line for a while.

Julo

Venkat Rangan <venkat@rhapsodynetworks.com> on 14/03/2001 00:11:38

Please respond to Venkat Rangan <venkat@rhapsodynetworks.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  iSCSI: CRC-64 a "MUST"?




All,

I know this was discussed at length, but I tried locating an email stating
a
consensus position that supports the following paragraph on page 93.

   "The following table lists cyclic integrity checksums that can be
   negotiated for the digests and MUST be implemented by every iSCSI
   initiator and target. Note that these digest options have only error
   detection significance."

And CRC-64 is listed in the table as a "MUST" for implementation, with a
TBD
on the polynomial. Is CRC-64 required if an iSCSI session never negotiates
a
PDU size larger than 8K? Why is this requirement being imposed when it is
known to be not very useful at shorter lengths?

The draft-cavanna-iscsi-crc-vs-cksum-01.txt states that "CRC-64 is
overkill"
in Section 5.

Can we therefore not be required to implement CRC-64? Also, even if a
particular instance implements it, and always negotiates it down to CRC-32Q
(or its equivalent), what is the purpose of carrying the implementation
burden of a never-used option?

Venkat Rangan
Rhapsody Networks Inc.
http://www.rhapsodynetworks.com