Re: iSCSI: burst size, response and sense data

["Mallikarjun C." <cbm@rose.hp.com>]

Julian,

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

As you point out, data transfer could be in either direction.  I am
still not convinced that we're relying on the right mode page, since the 
iSCSI target is not doing the "transfer" as SPC-2 states.  I would 
gladly defer to SCSI experts on this list if I am reading too much 
into SPC-2.

Another problem to be addressed is the SPC-2 usage of zero to mean unlimited
burst size.  We should define a way for an iSCSI target to indicate that
it *cannot* support immediate data.

If the suggestion is to use "ImmediateDataLength" text key in those 
cases, it raises the question of why we cannot always depend on that key.  
I would also argue that the default value of ImmediateDataLength must 
not be (2**32 - 1) as it is now, but should be zero.  

All in all, having two limits IMHO is confusing and prone to errors.
I strongly advocate having one, and my preference is that it be in iSCSI.

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

Having a response to a SCSI command always arrive in the SCSI Response
PDU makes the initiator software a lot more structured, since the response
handlers can deal with all iSCSI protocol errors (using the response data)
before passing it up to SCSI.  I would like to point out that the issue 
at hand is NOT "opcode not understood" but is one of iSCSI formatting 
error for an opcode that is *understood*.
--
Mallikarjun 


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



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