Re: Comments on iSCSI -03

[julian_satran@il.ibm.com]

This is a resend - please let me know if it is still broken. Julo
---------------------- Forwarded by Julian Satran/Haifa/IBM on 31/01/2001
07:27 ---------------------------

Julian Satran
30/01/2001 11:44

To:   "Charles Binford" <Charles.Binford@BlueSpruceNet.com>
cc:   ips@ece.cmu.edu
From: Julian Satran/Haifa/IBM@Haifa/IBM@IBMIL
Subject:  Re: Comments on iSCSI -03  (Document link: Julian Satran - Mail)

Comments in text.

Thanks,
Julo


"Charles Binford" <Charles.Binford@BlueSpruceNet.com> on 29/01/2001
23:09:46

Please respond to "Charles Binford" <Charles.Binford@BlueSpruceNet.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  Comments on iSCSI -03





Julian,  Below are several comments on iSCSI-03.  I

Æm fairly new to the
iSCSI discussion (but have been involved in T10/T11 for several years) so I
apologize if I

Æm rehashing already made decisions.  I

Æve sent this directly
to you instead of the general reflector because many of the items are
trivial editing issues.  Please feel free to cut and paste to the reflector
any issue(s) you feel justify a wider discussion.  (Of course I reserve the
right to do the same if I strongly disagree with your answer :-) )

Before I get into specifics, let me start with an overall comment.  Coming
from T10/T11 work, it bothers me that many of the PDU descriptions in
section 2 are not complete.  It seems to me an attitude was taken that
unless a field has new meaning for this PDU, it doesn

Æt need any text.  I
disagree.  I believe that every field in every PDU needs a description.  In
many cases that description may only spell out the acronym and then say

æSee
x.y

Æ but at least the implementer using the spec for reference can quickly
get a pointer to the authoritative text on the given field.

Thanks for your time.
Charles Binford
Blue Spruce Networks


*************************************************
[cb-01] pages 8 and 9
In the following two places

æCDB

Æ is referred to as

æCommand Data Block

Æ.
It

Æs real definition (from SAM) is Command Descriptor Block.
*************************************************
<js> will change </js>
1. Overview
1.1 SCSI Concepts
. . .
   Command Data Blocks (CDB) are the data structures used to contain the
   ^^^^^^^^^^^^^^^^^^^^^^^^^
   command parameters to be handed by an initiator to a target. The CDB
   content and structure is defined by [SAM] and device-type specific
   SCSI standards.

1.2.1 Layers & Sessions

   The following conceptual layering model is used in this document to
   specify initiator and target actions and how those relate to
   transmitted and received Protocol Data Units:

      -the SCSI layer builds/receives SCSI CDB (Command Data Blocks)
                                                ^^^^^^^^^^^^^^^^^^^
      and relays/receives them with the remaining command execute
      parameters (cf. SAM-2) to/from the
      -the iSCSI layer that builds/receives iSCSI PDUs and
      relays/receives them to/from - one or more TCP connections that
      form an initiator-target "session".


*************************************************
[cb-02] page 11
It seems to read better if you change

ætarget SCSI

Æ to

æSCSI target

Æ.
*************************************************

1.2.2.1 Command numbering
. . .
   CmdRNs are significant only during command delivery to the target.
   Once the device serving part of the target SCSI has received a
                                       ^^^^^^^^^^^
   command, CmdRN ceases to be significant.  During command delivery to
   the target, the allocated numbers are unique session wide.
<js>will fix</js>

*************************************************
[cb-03] page 14
Change

æan

Æ to

æand

Æ.
*************************************************

1.2.5 iSCSI Full Feature Phase
 . . .
   that was used to deliver the SCSI command.  If an initiator issues a
   WRITE command, the initiator must send the data, if any, for that
   command and the target MUST return R2T, if any, an the status over
                                                   ^^^
   the same TCP connection that was used to deliver the SCSI command.


<js>will fix</js>

*************************************************
[cb-04] page 22
Change

æResponse bit (bit 6)

Æ to

æResponse bit (bit 7)

Æ.
*************************************************

2.2.1 Opcode

   The Opcode indicates what type of iSCSI PDU the header encapsulates.
   The Opcode is further encoded as follows:

      b7   Response
      b6-0 Operation

   The opcodes are divided into two categories: initiator opcodes and
   target opcodes. Initiator opcodes are in PDUs sent by the initiators,
   and target opcodes are in PDUs sent by the target. The initiator MUST
   NOT send target opcodes and the target MUST NOT send initiator
   opcodes.  Target opcodes are also called responses and are
   distinguished by having the Response bit (bit 6) set to 1.
                                                ^^^
<js>will fix</js>


*************************************************
[cb-05] page 30
Again, I

Æm having a hard time finding a concise set of rules of how this
parameter (StatRN) is used.  It is incremented by 1 for every response, but
what is the starting value; 0? 1, any non-zero?  What conditions reset it

û
any?  Does is roll over back to 0, or does it explicitly skip 0 when
rolling
over from 0xffffffff?
*************************************************

2.4.7 StatRN - Status Reference Number

   StatRN is a reference number that the target iSCSI layer generates
   per connection and that in turn enables the initiator to acknowledge
   status reception. StatRN is incremented by 1 for every
   response/status sent on a connection.

<js>There is an InitStatSN for every connection in the login response. The
value 0 has no special significance so you wrap around. As usuall if the
difference between expected and sent is larger than 2**31-1 a recovery
action MUST be taken. </js>
*************************************************
[cb-06] page 32
This section implies ACA handing is mandatory if AE reporting is supported.
This seems to be an unnecessary linking of two independent concepts.

At least part of what I think is being solved with this auto ACA
requirement
is handled better by the new Task Aborted Status described in SAM-2.
(

æbetter

Æ in my biased opinion anyway

û I was the author of the Task
Aborted
Status proposal.)  Was utilizing Task Aborted considered and rejected, or
was it not even known/understood since it is so new?
*************************************************

   For the <Clear Task Set>, if SCSI control mode enables AE reporting,
   the target MUST send an Asynchronous Event to all other attached
   initiators to inform them that all pending tasks are cancelled and
   then enter the ACA state for any initiator for which it had pending
        ^^^^^^^^^^^^^^^^^^^
   tasks.

   For the <Target Warm Reset> and <Target Cold Reset> functions, the
   target cancels all pending operations and are both equivalent to the
   Target Reset as specified by SAM-2.  Provided that SCSI control mode
   enables AE reporting, the target MUST send an Asynchronous Event to
   all attached initiators notifying them that the target is being
   reset.

   In addition, for the <Target Warm Reset> the target will enter the
   ACA state on all sessions and all LUs on which an AE was sent.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
<js> We heard about task aborted but had little understanding about how to
use it.
If like ACA it will stay on untill cleared and will thus serve us to drop
all commands in flight the we could use it. If it does not we will have to
stay with ACA. Again the issue where the commands in flight </js>


*************************************************
[cb-07] page 46
Need to reword sentence

û the word

æbut

Æ doesn

Æt fit.
*************************************************

2.11.2 Version-active/lowest

   Indicates the version supported (the highest supported by the target
   and initiator). If the target is not supporting a version within the

Satran, J.           Standards-Track, August 2001                   45

                                iSCSI                January 10, 2000

   range of the initiator it will reject the login but and this field
                                                   ^^^^
   will indicate the lowest version supported by the target.

<js>will fix</js>

*************************************************
[cb-08] page 50
Sentence organization:  In the description of the P bit, the last sentence
the

æIF

Æ is the final phrase, making it hard to understand on the first
reading.  If the sentence is turned around (IF ... THEN style) I believe it
is much clearer.
*************************************************

2.13.1 P bit

   A target may issue a NOP-In by its own to test connection and the
   state of the initiator. In this case the Initiator Task Tag MUST be 0
   and the Target Tag MUST be set (not x'ffffffff') only if the P bit is
                                                    ^^^^^^^^^^^^^^^^^^^^
   1.
   ^^
<js>will fix</js>

*************************************************
[cb-09] page 57
Two problems with the following list; 5 & 6 should be 4 & 5, and item
number
3 is not in SAM-2 r15 (the latest version I could find).  Was something
recently added?  Again, I believe the new Task Aborted Status solves the
problem.
*************************************************

2.17.2 SCSI Event Indicator

   The following values are defined.  (See [SAM2] for details):

      1    An error condition was encountered after command
      completion.
      2    A newly initialized device is available to this initiator.
      3    All Task Sets are being Reset by another Initiator
      5    Some other type of unit attention condition has occurred.
      6    An asynchronous event has occurred.


<js>numbering will be fixed. I will be glad to change/elliminate 3 to task
aborted if I get a good pointer and it is good for commands in flight -
meanwhile would it be fair to say that it is subsumed by 6 </js>


*************************************************
[cb-10] page 59
At the end of section 2, and there is no description of Markers.  I believe
the standard needs a format diagram just like any of the other PDUs

û maybe
not in section 2, but somewhere.
*************************************************
<js> markers will move to an appendix and I'll add a descriptor </js>
*************************************************
[cb-11] page 60
Why redefine the mode page???  The Max Burst Size ad First Burst Size have
been defined as 512 byte chunks for a long time.  A SCSI target doesn

Æt
want
to have to translate fields based on the particular transport.  The 512
definition give a range of up to just under 32MB

û seems like a big enough

æfirst burst

Æ to me.
*************************************************

3.1.2 Maximum Burst Size field (16 bit)

   This field is used by iSCSI to define the maximum data payload in
   iSCSI data PDUs or as immediate data in command PDUs in units of 4096
                                                          ^^^^^^^^^^^^^^
   bytes. This value can also be set by a text-mode key:value pair
   (DataPDULength).

3.1.3 First Burst Size field (16 bit)

   This field is used by iSCSI to define the maximum of unsolicited data
   an iSCSI initiator is allowed to send to the target in units of 4096
                                                          ^^^^^^^^^^^^^
   bytes. This value can also be set by a text-mode key:value pair
   (InitialBurstLength).
<js> We where  told that those fields are protocol specific and we have to
define their values.  If a multiple of 512 is more a better fit for SCSI I
will change it </js>


Charles Binford
Blue Spruce Networks
office/cell: (316) 210-6404
e-fax: (509) 756-4425