iSCSI: mandating markers (was Nailing down CRC-32C)

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

m nima wrote:
> 
> On the other hand, Marker is a killer for SW implementation, as it
> needs to stop and insert it (or copy the buffer to a new one and
> insert the buffer)

The point is, it only needs to insert it if communicating with a device that
requests markers.  That means for 1gig, usually no markers.  When 10gig comes
along, markers will be used, but by then, there should be few SW
implementations.

> 
> I think the key for iSCSI is to make after the exhaustive
> standardization work, we're ready for 10G, markers and the proposed
> CRC leave iSCSI far behind.

I'm sorry.  I don't understand what the above means.

> 
> Maybe we need to look again at ULF before we move along...Endorsement
> of Framing by TSVWG was a step in this direction, I'd think.

The point is, are you going to "upgrade" your software solutions to use the
new ULF or whatever when it is finally approved?  If your software iscsi is
running over a transport (tcp) that you have no control over (microsoft, etc),
then I'll bet the answer is "no, I can't".  Therefore, the only solution is to
mandate something in iSCSI that can be implemented by legacy TCP stacks to
help the performance and cost issues of 10G iSCSI.  Otherwise, Fibre Channel
will always be cheaper (less buffering) and faster (less latency) than iSCSI.

-Matt
> 
> Nima
> 
> -----Original Message-----
> From: Matt Wakeley [mailto:matt_wakeley@agilent.com]
> Sent: Tuesday, May 08, 2001 11:19 AM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: Nailing down CRC-32C
> 
> 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
> 
> 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/
> 
> Get 250 color business cards for FREE!
> http://businesscards.lycos.com/vp/fastpath/