Re: iSCSI: burst size, response and sense data

[julian_satran@il.ibm.com]

Mallikarjun,

The way I read the burst items they apply for output mainly (both the
initial and the max burst size - the thing comes from the "connect context"
of parallel buses).

I am working now on errors. I am not convinced that we need an iSCSI status
field and that is why it is (perhaps temporarily) out.

I am looking at solving the iSCSI format errors through either "command not
understood" or an appropriate SCSI error.  But this may change after I
finish a first inventory.

Regards,
Julo

"Mallikarjun C." <cbm@rose.hp.com> on 08/12/2000 05:04:36

Please respond to cbm@rose.hp.com

To:   ips@ece.cmu.edu
cc:
Subject:  iSCSI: burst size, response and sense data




Julian,

1. The new iSCSI draft states that:
  "An initiator may send unsolicited data (immediate or in a separate
  PDU) up to the SCSI limit (initial burst size - mode page 02h)." (section
  1.2.5, para 4).

SPC-2 has the following on "FIRST BURST SIZE" in mode page 02h -
  "The FIRST BURST SIZE indicates the maximum amount of data that a
  target may transfer for a command during the same interconnect
  tenancy in which it receives the command." (Clause 8.3.7, last para)

Note that the mode page 02h is specifying the burst size in the *opposite*
direction - from target to initiator.  I would suggest that a new "iSCSI
mode page" be created to specify parameters of this nature.  Or, rely only
on what is negotiated in the iSCSI login dialogue, on a per-session basis.


2. Could you please comment on what is a valid response data format?
I expected all iSCSI protocol failures to find place in this response
data (similar to how FCP defines), but didn't find that stated in
section 2.3.7.


3. Same section 2.3.7 states that:
  "Some sense codes will relate to iSCSI check conditions (e.g. excessive
   number of outstanding commands, immediate data blocks too large etc.)."

Two concerns -

- Instead of using the SCSI application layer sense codes for denoting
  the SCSI transport layer (iSCSI)'s error conditions (and thus perhaps
  have a new set of sense codes standardized by T10), I would suggest
  that we keep off SCSI sense codes.  This provides for clean layered
  implementations as well.

- The examples given above seem like iSCSI protocol issues, and in my
  opinion, are apt to be represented in response data than in sense data.

Thanks.
--
Mallikarjun


Mallikarjun Chadalapaka
M/S 5601
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard, Roseville.
cbm@rose.hp.com