RE: new iSCSI PDU outline

["Douglas Otis" <dotis@sanlight.net>]

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

> 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
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>