Subject: Re: Comments on iSCSI -03

From: [email-masked]
Date: Tue, 30 Jan 2001 11:44:01 +0200

Comments in text.

Thanks,
Julo

"Charles Binford" <[email-masked]> on 29/01/2001
23:09:46

Please respond to "Charles Binford" <[email-masked]>

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

---

From: "Elliott, Robert" <[email-masked]>
Date: Tue, 30 Jan 2001 09:42:06 -0600

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

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

Julian, according to your message on 4 Jan copied below, the 
SCSI Event reasons are going to be eliminated altogether.  
The sense data contains the most accurate information 
about which event occurred.

---
PC: [email-masked]
UNIX: [email-masked]

Previous message:
To: "Elliott, Robert" <[email-masked]> 
Subject: Re: iSCSI: SCSI Event Indicator 
From: [email-masked] 
Date: Thu, 4 Jan 2001 09:55:06 +0200 
cc: [email-masked] 
Sender: [email-masked] 

Will do,

Thanks,
Julo

"Elliott, Robert" <[email-masked]> on 03/01/2001 19:00:58

Please respond to "Elliott, Robert" <[email-masked]>

To:   "[email-masked]'" <[email-masked]>
cc:
Subject:  iSCSI: SCSI Event Indicator

The Asynchronous Event data structure includes an "iSCSI Event
Indicator" field and a "SCSI Event Indicator" field.  The iSCSI
field indicates iSCSI-specific causes, which is fine.  The SCSI
Event field indicates generic SCSI causes.

I suggest removing the SCSI Event Indicator values.  The
information is contained within the sense data itself.

The SEND command in SPC-2, the current mechanism to report
Asynchronous Events, does not include an Event field like this.

I suggest simplifying the field to:
    0 = not a SCSI Event
    1 = SCSI Event

This is the text in iSCSI revision 02, with comments
listing where in the sense data that information is
communicated:

      1    An error condition was encountered after command
      completion.
[Sense data RESPONSE CODE field is DEFERRED ERRORS - 71h]

      2    A newly initialized device is available to this initiator.
[Sense data ASC/ASCQ is REPORTED LUNS DATA HAS CHANGED]

      3    All Task Sets are being Reset by another Initiator
[Sense data ASC/ASCQ is COMMANDS CLEARED BY ANOTHER INITIATOR]

[where is 4?]

      5    Some other type of unit attention condition has occurred.
[Sense data SENSE KEY field is UNIT ATTENTION - 6h]

[Any other sense data]

   Sense Data accompanying the report identifies the condition.  The
   Length parameter is set to the length of the Sense Data.

   For new device identification an iSCSI target MUST support the Device
   Identification page.

The list was probably taken from this list in SAM-2; however, it's
not an exact match:

    Asynchronous Event Reporting is used to signal a device that
    one of the four events listed below has occurred:
    a) an error condition was encountered after command completion;
    b) a newly initialized device is available;
    c) some other type of unit attention condition has occurred; or
    d) an asynchronous event has occurred.

---
PC: [email-masked]
UNIX: [email-masked]

---

From: [email-masked]
Date: Wed, 31 Jan 2001 07:33:46 +0200

Elliott,

There seems to be a requirement in SAM to send the SCSI event indicator and
as you point out
a discrepancy with SPC.

I would appreciate if one of the T10 luminaries would comment.

Julo

"Elliott, Robert" <[email-masked]> on 30/01/2001 17:42:06

To:   Julian Satran/Haifa/IBM@IBMIL, Charles Binford
      <[email-masked]>, [email-masked]
cc:
Subject:  RE: Comments on iSCSI -03

---

Previous message:

Will do,

Thanks,
Julo

[where is 4?]

---

---

From: [email-masked]
Date: Wed, 31 Jan 2001 07:33:46 +0200

Elliott,

Julo

---

Previous message:

Will do,

Thanks,
Julo

[where is 4?]

---

---

From: [email-masked]
Date: Wed, 31 Jan 2001 07:28:20 +0200

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" <[email-masked]>
cc:   [email-masked]
From: Julian Satran/Haifa/IBM@Haifa/IBM@IBMIL
Subject:  Re: Comments on iSCSI -03  (Document link: Julian Satran - Mail)

Comments in text.

Thanks,
Julo

Æm fairly new to the

Æve sent this directly

Æt need any text.  I

æSee
x.y

Thanks for your time.
Charles Binford
Blue Spruce Networks

æCDB

Æ is referred to as 

æCommand Data Block

Æ.
It

1.2.1 Layers & Sessions

ætarget SCSI

Æ to 

æSCSI target

Æ.

æan

Æ to 

æand

Æ.

<js>will fix</js>

æResponse bit (bit 6)

Æ to 

æResponse bit (bit 7)

Æ.

2.2.1 Opcode

      b7   Response
      b6-0 Operation

û

æbetter

û the word 

æbut

Æ doesn

Æt fit.

                                iSCSI                January 10, 2000

<js>will fix</js>

æIF

2.13.1 P bit

û maybe

Æt
want

æfirst burst

Æ to me.

Charles Binford
Blue Spruce Networks

---

From: [email-masked]
Date: Wed, 31 Jan 2001 17:26:04 +0200

I did copy it to notepad and attach it.
Notepad said something about unicode -:)

(See attached file: binford.txt)