Re: iSCSI: current UNH Plugfest

["Julian Satran" <Julian_Satran@il.ibm.com>]

Bob,

Comments in text.

Thanks,
Julo




"Robert D. Russell" <rdr@mars.iol.unh.edu>
Sent by: owner-ips@ece.cmu.edu
31-10-01 02:06
Please respond to "Robert D. Russell"

 
        To:     ips@ece.cmu.edu
        cc: 
        Subject:        Re: iSCSI: current UNH Plugfest

 


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?
+++
1.NotUnderstood appears also in the negotiation section so it applies to 
login.
I will remove it from the text section
2.It does not apply to values
+++

   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.

+++ I think this is the correct interpretation and we will fix the wording 
in section 8 to say this. I suggest:

- During Login, any failure in negotiation MUST be considered as the login 
process failure and the login phase must be terminated. If the failure is 
detected by the target, it must reject the login with the appropriate 
code. The connection must be terminated by the initiator.

 +++

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.

+++ we are using the term offering and responding to distinguish them from 
initiator and target and explicitly say (in 2.2.4) that the target may 
offer keys
+++

   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.

+++ there is no implicit ofering of defaults. A default is accepted only 
if the two parties are silent.

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

+++ will do +++

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.

+++ Will fix the examples +++ 

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):

+++
That is not strictly correct. You may use discovery to determine the 
addresses and portal groups for a specific target - i.e. you may give a 
target-name. If you give a target name that is all you get. If don't give 
a name you get all the targets you are allowed to get to.
++++

   "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)
+++ will do +++

   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.