SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: Comments on iSCSI -03



    
    
    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
    
    
    


Home

Last updated: Tue Sep 04 01:05:38 2001
6315 messages in chronological order