RE: new iSCSI PDU outline

[julian_satran@il.ibm.com]

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" <dotis@sanlight.net> on 26/01/2001 21:23:04

Please respond to "Douglas Otis" <dotis@sanlight.net>

To:   ips@ece.cmu.edu
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" <dotis@sanlight.net> on 26/01/2001 00:41:02
>
> Please respond to "Douglas Otis" <dotis@sanlight.net>
>
> To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> 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
>
>
>
>
>
>
>