Re: iSCSI: plugfest4 issues

["Robert D. Russell" <rdr@io.iol.unh.edu>]

Julian:

Five issues came up today, Wednesday, 31-July-2002, at the iSCSI
plugfest.


1. We have hit a situation where a lot of people are not interoperating,
   and this has to do with the use of "Irrelevant" as a key response
   value.  In section 4.2 the standard says only: "If a specific key is
   not relevant for the current negotiation, the responder may answer
   with the constant "Irrelevant" for all types of negotiation. ...".

   The problem is that nowhere in the standard is it further defined
   when a key is relevant and when it is not.  It is left up to each
   individual implementation, and as a result, different implementers
   are coming to different conclusions in the same circumstances.  Thus,
   they do not interoperate.

   A few implementations are simply saying that all keys are always
   relevant, and never accept "Irrelevant" as an answer in any situation.
   That is the extreme, but their argument is that it requires extra
   logic to decide when a key is relevant and when it is not, and hence
   it is simpler not to do this.

   More common are implementations that have simply not thought of all
   the possible situations in which a key has become irrelevant.

   We have a choice on how to proceed.

   The simplest alternative would be to eliminate "Irrelevant" as a
   response, since it is never necessary to use this in a response,
   yet it always requires extra logic on the receiving side to deal
   with it.

   An alternative if we decide to keep "Irrelevant" as a response is to
   have the standard specify as part of the definition of each key in
   Section 11 and Appendix A those situations in which that key may be
   considered irrelevant.  This could be listed as an attribute
   "Irrelevant when:" immediately following the current "Scope:"
   attribute.  This attribute is in addition to the integrity rules
   which already exist.

   The following is a list of all the keys that I am aware of that can
   accept a response of Irrelevant, and the situations in which this
   can legitimately occur (numbers indicate the section where the key is
   defined):

   11.2  MaxConnections -- Irrelevant when: SessionType=Discovery
   11.10 InitialR2T -- Irrelevant when: SessionType=Discovery
   11.11 BidiInitialR2T -- Irrelevant when: SessionType=Discovery
   11.12 ImmediateData -- Irrelevant when: SessionType=Discovery
   11.10 MaxBurstLength -- Irrelevant when: SessionType=Discovery
   11.10 FirstBurstLength -- Irrelevant when: SessionType=Discovery
         -- also irrelevant when ( InitialR2T=Yes and ImmediateData=No )
   11.18 MaxOutstandingR2T -- Irrelevant when: SessionType=Discovery
   11.19 DataPDUInOrder -- Irrelevant when: SessionType=Discovery
   11.20 DataSequenceInOrder -- Irrelevant when: SessionType=Discovery
   A.3.2 OFMarkInt -- Irrelevant when: OFMarker=No
         IFMarkInt -- Irrelevant when: IFMarker=No


2. Section 2.2.2.1 states:
   "Commands meant for immediate delivery are marked with an immediate
   delivery flag; they also carry CmdSN.  CmdSN does not advance for
   commands marked for immediate delivery."

   and 2 paragraphs later in the same section:
   "If immediate delivery is used with task management commands, these
   commands may reach the target before the tasks on which they are sup-
   posed to act.  For this reason the task management command MUST carry
   the current CmdSN as a marker of their position in the stream of com-
   mands."

   Given the first statement quoted above, why is this last sentence
   needed?  It is causing some confusion because it makes it sound
   as if the task management command is somehow an exception because
   it MUST carry the current CmdSN (implying that maybe other
   immediate commands do not have to carry the current CmdSN).

   To eliminate the confusion, but to keep the same intention, a
   suggested rewording would be:

   To the first paragraph quoted above, change the phrase "they also
   carry CmdSN" to: "they MUST also carry the current CmdSN".

   In the second paragraph quoted above, either change the second
   sentence (the one starting "For this reason...") to: "However,
   their CmdSN is a marker of their position in the stream of
   commands." (which is the wording that was used previously in
   draft 12), or just eliminate the second sentence entirely, since
   this topic is discussed later in section 2.5.1.3 and again in
   section 9.5.1.


3. Section 9.13.3 states:
   "For a new session, the target MUST generate a non-zero TSIH and
   return it in the Login Final-Response (see Section 4.3 Login Phase).
   In all other cases, this field should be set to the TSIH provided
   by the initiator in the Login Request."

   The phrase "in all other cases" is ambiguous.  Some companies are
   interpreting it to mean "sessions other than a new session", while
   others are interpreting it to mean "Login Responses other than
   the Login Final-Response in a new session".

   So what is the intent?  On a new session, clearly the target MUST
   return the non-zero TSIH in the Login Final-Response, but can it
   also return a non-zero TSIH in the first, second, ... Login Partial
   Responses that precede the Login Final-Response?

   If the intent for new sessions is to have the TSIH set to 0 in Login
   Partial-Responses and only change to a non-zero TSIH in the Login
   Final-Response, then a suggested rewording to make this clear would be:

   "Except for the Login Final-Response in a new session, this field
   should be set to the TSIH provided by the initiator in the Login
   Request.  For a new session, the target MUST generate a non-zero
   TSIH and return it ONLY in the Login Final-Response (see Section
   4.3 Login Phase)."

   If the intent is to allow, but not require, the target to return
   the non-zero TSIH in the first, second, ... Login Partial
   Responses in a new session, then a suggested rewording to make
   this clear would be:

   "During Login Phases that do not establish a new session, this
   field should be set to the TSIH provided by the initiator in
   the Login Request.  For a new session, the target MUST generate
   a non-zero TSIH and MAY return it in a Login Partial-Response
   but MUST return it in the Login final-Response (see Section 4.3
   Login Phase)."

   This last interpretation still leaves open the question of whether
   the target is allowed to toggle back and forth between 0 and the
   newly-generated TSIH within sequences of Login Partial-Responses.


4. There has been some misunderstanding with the phrase "not advanced".
   For example, in section 9.8.2 StatSN it says:  "The StatSN field will
   contain the next StatSN.  The StatSN for this connection is not
   advanced."

   In spite of the presence of the word "next", some implementations are
   interpreting this to mean that this PDU will always contain the same
   value for StatSN as was sent in the previous response.  Perhaps it
   would help if the words "after this PDU is sent" were added to the
   last sentence quoted above so that it would read: "The StatSN for
   this connection is not advanced after this PDU is sent."

   Other examples where this wording could be added to help clarify
   when the advancing is performed (or not performed) are:

   section 2.2.2.1: "Commands meant for immediate delivery are marked with
   an immediate delivery flag; they also carry the next CmdSN.  CmdSN does
   not advance after commands marked for immediate delivery are sent."

   section 2.2.2.1: "- CmdSN - the current command Sequence Number,
   advanced by 1 after each command shipped except for commands marked
   for immediate delivery."

   section 2.2.2.3: "For input (read) data PDUs, DataSN starts with 0 for
   the first data PDU of an input command and advances by 1 after each
   data PDU is sent.  For output data PDUs, DataSN starts with 0 for the
   first data PDU of a sequence (the initial unsolicited sequence or any
   data PDU sequence issued to satisfy an R2T) and advances by 1 after
   each data PDU is sent.  R2Ts are also sequenced per command.  For
   example, the first R2T has an R2TSN of 0 and the R2TSN advances by 1
   after each R2T is sent."

   section 9.11.5: "The target StatSN register is advanced after each
   Text Response is sent."

   section 9.18.1: "However, the I bit must be set to 1 and the CmdSN
   is not advanced after this PDU is sent."

   section 9.19.2: "However, when the Initiator Task Tag is set to
   0xffffffff,  StatSN for the connection is not advanced after this
   PDU is sent."


5. There has been major disagreement about correct digest values.

   A number of implementations differ only due to a Big-Endian/
   Little-Endian problem that we hope to be able to resolve over
   the next few days.  Differences between other implementations
   show no discernible pattern.  Of course, all implementations
   claim to compute the proper answers to the test cases given in
   the standard.  The difficulty is that these test cases are not
   sample pdus and therefore never actually occur during operation.

   A recommendation would be to include in the standard a simple
   sample PDU (one that could actually be sent during a session) and
   give its correctly computed CRC value.  For example, a NOP-OUT
   PDU with I=1, DataSegmentLength=0, Lun=0, InitiatorTaskTag and
   Target Transfer Tag both = 0xffffffff, CmdSN = 1234, and
   ExpStatSN=567 could be legal, and most implementations could probably
   arrange fairly simply for such a PDU to actually be sent by an
   initiator.  By publishing the correct CRC value for such a pdu,
   all questions about who is right and who is wrong are immediately
   solved, and new implementations can be developed more accurately.


Thank you for your consideration.

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774