Re: iSCSI: current UNH Plugfest

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

Attached are some new issues that arose during the iSCSI plugfest at
UNH on Tuesday 29-Oct-2001.
(Note: these issues do not take into account any modifications or
clarifications that occured in the standard due to the issues raised
on Monday.)

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

-----------------------------------------------------------------------------

1. Situation: as the first command on a new TCP connection, the initiator
   sends a login with T=1, CSG=1, NSG=3, and valid InitiatorName, TargetName,
   and SessionType keys.  However, there is also a valid key having an
   invalid value, such as MaxConnections=abcd (i.e., not a number after the
   '=') or MaxConnections4 (i.e., missing the '=').
   What should the target do?

   Interpretation 1:

   According to section 3.10.4 page 82 of draft 8 (page 83 of draft 8a),
      "Any other key not understood by the target may be ignored by the
      target without affecting basic function.  However the Text Response
      for a key that was not understood MUST be key=NotUnderstood."

   Two things have to be clarified:
   1. Does this section also apply to keys received in a login?
   2. Can "NotUnderstood" also apply to "values of keys" that are not
      understood, even if the key word itself is understood?

   If the answer to these 2 of these questions is "yes", then the appropriate
   response would seem to be for the target to just ignore the key and send
   back MaxConnections=NotUnderstood as part of its next login response.
   

   Interpratation 2:

   According to section 8.7 page 129 of draft 8 (page 130 of draft 8a),
      "A negotiation failure is considered one or both of the following:
      - None of the choices or the stated value is acceptable to one
      negotiating side. ..."
   Clearly this stated value ("abcd") is not acceptable to the target.
   Therefore, the following rule on page 129, draft 8 (page 130, draft 8a)
   applies:
      "- During Login, any failure in negotiation MUST be considered
      as the login process failure and the connection must be dropped."

   Therefore, the target should just drop the connection without sending
   any login response back to the initiator.


   Interpretation 3:

   This is a login command that contains an error caused by the
   initiator.  Therefore, the target should send back a login response
   with a status code of 0x0200 and then close the TCP connection.


2. Situation: on the first login command in operational parameter negotiation
   stage, the initiator sends no operational keys, thereby telling the target
   that it accepts all the default values for these keys.  However, the target
   wants to negotiate the value of MaxConnections, so in the login response
   it sends back "MaxConnections=3" (for example).  Should the initiator
   send a response to this key or not? 

   The statement in section 2.2.4 on page 30 of draft 8 and 8a:
   "For numerical (and single literal) negotiations, the responding party MUST
   respond with the required key.(...)"
   makes it clear that the responding party MUST respond.  However, in this
   situation, it is not clear who the responding party is.

   Interpretation 1:

   By not explicitly sending this key in the login command, the initiator
   is implicitly offering the default value and therefore is the offering
   party and the target is the responding party.  The conclusion is that
   the initiator does not have to send a response to this key from the
   target.


   Interpretation 2:

   The target is the offering party because it is the party that explicitly
   stated the key for the first time during these negotiations.  The
   conclusion is that the initiator MUST send a response to this key from the
   target.


   NOTE 1: If interpretation 1 is correct, it would seem to imply that the
   target MUST respond to every key whether or not it is present in the
   login from the initiator, even if it does not want to change the default
   value.  The reason is that a missing key is an implicit offer of the
   default value, and the responding party MUST respond.  Is this a correct
   interpretation?


   NOTE 2: The following statements in section 2.2.4 page 29 of draft 8a:

        Originator-> <key>=<valuex>
        Responder-> <key>=<valuey>|NOtUnderstood

   seem to imply that the originator is the party (initiator or target) that
   explicitly offers a key, and that omitting a key is not an implicit offer
   of that key with the default value.  However, even in the revised draft 8a
   there is no definition of "Originator" and/or "Responder" that would
   make this clear.  Adding to the standard these definitions, and an
   explicit statement that "a missing key does not constitute an implicit
   offer of the default" would help eliminate misunderstandings.  In
   addition, including an example of this situation (where an initiator
   omits a key and the target offers the key) would be a big help.


3. Some of the login phase examples given in Appendix A of both draft 8 and
   8a do not follow the rule in section 3.12.4 page 87 of draft 8 (page 88
   of draft 8a):
      "The next stage value is valid only when the T bit is 1 and is
      reserved otherwise."
   and the rule in section 3 page 48 of draft 8 (page 49 of draft 8a):
      "Any reserved fields and values MUST be 0 unless specified otherwise."

   If these rules are applied, all examples having T=0 should also
   have NSG=0.  Presently all of them with T=0 also have NSG=1 or NSG=3.
   

4. Situation: The initiator and target have successfully completed the
   login phase for a discovery session and are now in full feature phase.
   The initiator sends a text command containing the single key:
   "SendTargets=".  What response is expected from the target?


   Interpretation 1:

   According to the explanation on page 188 of draft 8 (page 189 of
   draft 8a):
   "If no target name is specified, the session should respond with
   addresses only for the target to which the session is logged in.
   This MUST be supported on operational sessions, and MAY NOT
   return targets other than the one to which the session is logged in."

   However, for a discovery session there is no target per se (the
   initiator does not specify a TargetName= during login), so the
   target therefore follows the rule on page 188 of draft 8 (page 189
   of draft 8a):
   "A SendTargets response MAY contain no target names, if there are no
   targets for the requesting initiator to access."
   and sends back a Text Response with no keys in it.


   Interpretation 2:

   In a discovery session, the key "SendTargets=" makes no sense and should
   be treated by the target in the same manner as the key "SendTargets=all".


5. Some common error situations:

   1) - when a SCSI Response contains a CHECK CONDITION (Status=0x02),
      some targets are not including the SenseLength as the first 2
      bytes in the data segment.  Although the format of the data segment
      is clear from the diagram in section 3.4.6 on page 62 of draft 8
      (page 63 of draft 8a), the last entry in the diagram for the SCSI
      Response PDU on page 58 of draft 8 (page 59 of draft 8a) is
      misleading because it mentions only the Sense Data and Response
      Data and omits the Sense Length.  It would therefore be helpful
      if the last entry in the diagram on page 58 were changed to explicitly
      reference the diagram on page 62, as in:

         Data Segment -- see section 3.4.6 (optional)


   2) - after sending a CmdSN on an initial login, some initiators are
      incrementing it before sending their first non-immediate command.
      (i.e., if the initial login contains CmdSN=123, they are sending
      CmdSN=124 on the first non-immediate command after the login phase).
      Section 3.12.10 on page 89 of draft 8 (page 90 of draft 8a) is
      clear that in this example the first non-immediate command should
      carry CmdSN=123, not 124.  This was an issue at the July plugfest
      and apparently some implementations have not been updated to conform
      to the draft 8 standard in their handling of CmdSN.