Subject: RE: new iSCSI PDU outline

From: [email-masked]
Date: Sat, 27 Jan 2001 18:37:53 +0200

Doug,

CRC is not mandatory.  If you are using a local net (real time) on a
reliable media you probably don't need
anything.  In any case a simple XOR will add nothing to what TCP already
has (checksum) in the way of protection.
And given that most of the time you have to deal with SCSI commands and
responses and data blocks a basic block that takes care of those header
types (the 48 byte) is probably optimal. The extended CDB is for those
cases in which SCSI uses a CDB longer than 16 bytes (16 bytes of CDB are
still provided for in the BHS).

Julo

"Douglas Otis" <[email-masked]> on 26/01/2001 21:23:04

Please respond to "Douglas Otis" <[email-masked]>

To:   [email-masked]
cc:
Subject:  RE: new iSCSI PDU outline

Julian,

Should there be software implementations that must deal with iSCSI on a
real-time basis, splitting the headers as I described helps in allowing the
transport to respond immediately in providing the transport related
feed-back.  The split header and simple XOR calculation was to make this
possible with software implementations where these settings are made
nano-seconds before being sent.  To require a CRC to be done could
introduce
many micro-seconds into the operation and thus make the transport less
current on its feed-back as this must be pipelined.  You have a few other
fields not defined and perhaps use those fields to expand the later
content.
I doubt there will be more than a handful of types but if you use 16 bits,
there should never be a danger of running out of options.  In addition, I
would suggest retry flags be placed in this header for the same reasons of
simplifying the transport.  Once the SCSI structure is created, it becomes
independent of the transport functions so that fiddling at the transport
will not spoil this content.  By keeping these values to but a few fields
unrelated to the payload, a simple check should be all that is needed.

Doug
> Doug,
>
> You are right and we could do it but it will reduce the number of yet
> unallocated types in WN (and T10 is adding more stuff to the SCSI!) and
> will save us several bits in the command where we have plenty. I don't
> think it is worth it.
>
> Regards,
> Julo
>
> "Douglas Otis" <[email-masked]> on 26/01/2001 00:41:02
>
> Please respond to "Douglas Otis" <[email-masked]>
>
> To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
> cc:
> Subject:  RE: new iSCSI PDU outline
>
>
>
>
> Julian,
>
> Would you consider splitting headers.  As was done with MTF,
> there was just
> a simple 32 bit simple XOR checksum for header fields.  Here is an
example
> with a CDB appended.  The WN could expand the appended type into
> SCSI_CMND,
> SCSI_RSP, SCSI_R2T, iSCSI_Specific, etc.
>
>   |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
>   +---------------+---------------+---------------+---------------+
>  0| WN            | Reserved                      | AddCDB        |
>   +---------------+---------------+---------------+---------------+
>  4| Length                                                        |
>   +---------------+---------------+---------------+---------------+
>  8| ->CmdSN or <-StatRN                                           |
>   +---------------+---------------+---------------+---------------+
> 12| ->ExpStatSN or <-ExpCmdSN                                     |
>   +---------------+---------------+---------------+---------------+
> 16| ->MaxStatRN? <-MaxCmdSN                                       |
>   +---------------+---------------+---------------+---------------+
> 20| XOR Checksum                                                  |
>   +---------------+---------------+---------------+---------------+
>   +---------------+---------------+---------------+---------------+
> 24| SCSI_CMND  ...                                                |
>   +-                                                              |
> 32|                                                               |
>   +---------------+---------------+---------------+---------------+
> 36| CDB ...                                                          |
>   +---------------+---------------+---------------+---------------+
> x | (Data ...)                                                         |
>   +---------------+---------------+---------------+---------------+
> y | CRC                                                           |
>   +---------------+---------------+---------------+---------------+
>
> Doug
>
>
>
>
>
>
>

---

From: Michael Krause <[email-masked]>
Date: Mon, 29 Jan 2001 10:13:35 -0800

At 06:37 PM 1/27/2001 +0200, [email-masked] wrote:

>reliable media you probably don't need anything.

Unclear how iSCSI will be able to determine whether the target is local or 
not given IP subnets can already span large geographic distances and the 
movement to 10 GbE translates to large Ethernet fabrics.  Also as 
transparent fail-over is delivered by multiple vendors, what started out as 
local may become remote in some way.

I strongly disagree with making CRC protection optional and I suspect 
customers will given the various studies on error rate escapes associated 
with TCP checksum already discussed on this reflector.

Mike

---

From: "Douglas Otis" <[email-masked]>
Date: Mon, 29 Jan 2001 10:13:41 -0800

Julian,

You will still have the 16-bit summation within the TCP IP providing an
effective error rate of one in 64k.  A 32-bit XOR in conjunction with this
checksum is not the same odds of missing an error.  As you add bytes covered
by this XOR (not the entire frame), the reliability is reduced.  If to
evaluate a simple scheme, the fewer words the better and if information such
as tags and static command related data can be provided better protection,
why not?

Doug

---

From: Matt Wakeley <[email-masked]>
Date: Mon, 29 Jan 2001 21:46:20 -0800

Mike,

If an iSCSI implementation is put together, without using routers or other
middle boxes that muck with the TCP checksum, then the TCP checksum should be
adequate.  The first implementations of iSCSI are going to be software based. 
In these early software based implementations, performance could probably be
increased if CRC was disabled.

-Matt