Re: iSCSI: Nailing down CRC-32C

["Matt Wakeley" <matt_wakeley@agilent.com>]

There is a 4th option.

Mandate the implementation of iSCSI markers.  This will significantly reduce
the amount of buffering required.

I think we should just go ahead and mandate implementation of markers, for two
reasons:  1- the "ULF (or WARP)" proposal doesn't seem to be making much
headway, and 2- even if ULF did become reality, there are software
implementations today that will not have the luxury of having a "enhanced" TCP
stack that would provide the framing.

Software implementations of iSCSI MUST supply iSCSI markers (if invoked to do
so) to enable low cost, high performance 10Gig solutions.

-Matt

bj nima wrote:
> 
> Assumptions:
> 
> 1) The iSCSI DATA PDU Header and Data Integrity checks uses CRC-32
> 2) Support of Integrity check is mandatory for both header and Data
>    digest
> 3) An iSCSI PDU may span multiple TCP segments.
> 4) Any of these segments may arrive out of order at the receiver.
> 5) To regenerate the CRC for comparison with the value present in the
> PDU received, the receiver needs to keep in a temporary buffers all
> segments, waiting for the missing one, as CRC must be computed using
> the whole re-assembled PDU
> 
> Question: Does CRC-32 support partial computation and compensation
> for wrong initial values later (I guess NO!), to enable partial CRC
> calc on avail parts of PDU?
> 
> Possible answer: No
> 
> Possible Conclusion: The RCV side is further complicated b/c of this
> CRC
> 
> Possible solutions:
> 
> 1) Use CRC that allows partial calc
> 2) Limit iSCSI PDU to TCP MSS if data CRC is used (added o/h)...
> 3) Leave as it, though it has cost , performance implication and hurts
> scaling to 10G..
> 
> Nima
> 
> -----Original Message-----
> From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
> Sent: Saturday, May 05, 2001 9:21 AM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: Nailing down CRC-32C
> 
> The CRC part of the appendix (for 07) reads:
> 
>    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.
> 
>    +---------------------------------------------+
>    | Name          | Description                 |
>    +---------------------------------------------+
>    | crc-32C       | 32 bit CRC      | 11EDC6F41 |
>    +---------------------------------------------+
>    | none          | no digest                   |
>    +---------------------------------------------+
> 
>    The generator polynomials for those digests are given in hex-notation,
>    for example 3a stands for 0011 1010 - the polynomial x**5+X**4+x**3+x+1.
> 
>    The generator polynomial selected is evaluated in [Castagnioli93].
>    When using the CRC the CRC register must be initialized to all 1s
>    (0xFFFFFFFF) and the CRC bits must be complemented before transmission.
>    Padding bytes, when presents in a segment covered by a CRC, have to be
>    set to 0 and are included in the CRC.
> 
>    Regards,
>    Julo
> 
> Mark Bakke <mbakke@cisco.com> on 05-05-2001 00:13:09
> 
> Please respond to Mark Bakke <mbakke@cisco.com>
> 
> To:   IPS <ips@ece.cmu.edu>
> cc:
> Subject:  iSCSI: Nailing down CRC-32C
> 
> At the interim meeting, it was stated that iSCSI has selected
> the CRC-32C polynomial as its required iSCSI-level header and
> data CRC.  Now that we have it, it's time to move on and make
> sure we can implement it.
> 
> In the interest of interoperability, we need to not only specify
> the polynomial, but also the initial values, bit and byte
> ordering, etc.
> 
> "A Painless Guide to CRC Error Detection Algorithms"
> (http://www.ross.net/crc/crcpaper.html) specifies a
> method to unambiguously characterize these parameters
> (sections 15 and 16).  Has anyone taken a shot at defining
> these yet?  Otherwise, here is what it might look like:
> 
> Name   : "CRC-32C"
> Width  : 32
> Poly   : 1EDC6F41   (note that the leading "1" is implied)
> Init   : FFFFFFFF
> RefIn  : True
> RefOut : True
> XorOut : FFFFFFFF
> Check  : ?
> 
> I haven't attempted to create check data based on these yet.  As
> soon as the other parameters are nailed down, we need to do this.
> 
> Anyway, I am not a CRC expert, and can't make any statement about
> the above values being the "best" way to do this, but instead just
> copied them (except the polynomial itself) from the Ethernet CRC,
> since that is likely the easiest for everyone implementing hardware
> to deal with.
> 
> If someone else is already doing this, let me know; I just wanted
> to start this thread so we can get closure.
> 
> Regards,
> 
> Mark
> 
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
> 
> _______________________________________________________
> Send a cool gift with your E-Card
> http://www.bluemountain.com/giftcenter/