iSCSI: current UNH Plugfest

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

Attached are some of the issues that arose during the
first day of the iSCSI plugfest at UNH on Monday 29-Oct-2001.

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

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

1. Situation: the very first command sent on a new connection is a
   login.  However, the I bit is not set.  What should the target do?

   Interpretation 1:
   According to section 8.3 page 127 of draft 8,
   "Explicit violations of the PDU layout rules stated in this document
   are format errors."
   "When a target or an initiator receives an iSCSI PDU with a format
   error, it MUST reset all transport connections in the session
   immediately ..."
   This is a format error so section 8.3 applies.  Therefore, the target
   should simply close the connection without sending anything to the
   initiator.

   Interpretation 2:
   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 the keys InitialR2T=yes and ImmediateData=no
   and the target agrees with these values.  Therefore, according to the
   table on page 182 of draft 8, both sides agree that unsolicited data
   is disallowed.  These keys are then followed, either later in the keys
   associated with this same login command or in a subsequent login command
   belonging to the same login phase, with the key FirstBurstSize=6.
   What should the target do?

   Interpretation 1:
   FirstBurstSize indicates "the maximum amount of unsolicited data an
   iSCSI initiator may send to the target during the execution of a
   single SCSI command, in units of 512 bytes."  However unsolicited data
   is now disallowed, so FirstBurstSize is irrelevant.  Therefore, no
   response is necessary -- the key is just ignored.

   Interpretation 2:
   In section 2.2.4 on page 30 of draft 8 it says "For numerical
   negotiations, the responding party MUST respond with the required key."
   Since FirstBurstSize is a numerical key, the target MUST respond with
   a numeric value ("reject" is not allowed for numerical keys), even if
   the value is irrelevant and will not be used.


3. Situation: As the first command on a new connection the initiator
   sends a valid login command with SessionType=discovery, CSG=0, NSG=3,
   and T=1.  The target responds with CSG=0, NSG=1 and T=1.  So both
   sides are now in the operational parameter negotiation stage.
   Question: what parameters can they negotiate in this stage for a
   discovery session, and what should be done if other, irrelevant,
   parameters are negotiated?

   Interpretation 1:
   The only relevant operational parameters in a discovery session seem to
   be those related to markers (FMarker, RFMarkInt, SFMarkInt), error
   recovery (ErrorRecoveryLevel) and vendor specific keys.
   If this is true, what should one side do when the other side attempts
   to negotiate other operational parameters in a discovery session?

   Interpretation 2:
   Even the relevant operational parameters in a discovery session given
   above have very marginal utility.  It would be easier to just
   disallow all operational parameter negotiation in a discovery session.


4. Contradiction in draft 8.
   In section 3.13.5 on page 92 it says that in a login response:
   "for a non-zero Status-Class the T, CSG & NSG fields MUST be 0."

   In section 5.1 on page 112 it says that in a login response with
   login reject (i.e., Status-Class non-zero): "The T bit of the
   response MUST be set to 1 and the CSG and NSG are ignored."

   One of these has to be changed.  Note also that the second statement
   just given (from page 112) is inconsistent with the statement 
   in section 3.12.4 on page 87 that for login requests:
   "the next stage value is valid only when the T bit is 1 and is
   reserved otherwise."  One would expect the standard to have the
   same rule for the way the T, NSG and CSG fields are handled in
   both login request and login response.


5. Clarification suggested:
   In section 3.13.4 on page 91 of draft 8 it says:  "For the first
   Login Response (the response to the first Login Request) this is
   the starting status Sequence Number for the connection (the next
   response of any kind will carry this number + 1)."
   If the login phase requires more than one login-request/login-response
   exchange, this rule implies that the second (third, fourth, ...)
   login-response should be incrementing StatSN.
   Nobody was doing this, although it seems clear that the standard requires
   it.  Perhaps there needs to be a slight addition to the wording of this
   section so it reads:
   "For the first Login Response (the response to the first Login Request)
   this is the starting status Sequence Number for the connection (the next
   response of any kind, including the next login response if any in the
   same login phase, will carry this number + 1)."


6. Situations where frequent errors or misunderstandings occured, although
   the draft seems clear:
   1.  - StatSN must be incremented in Login Phase (point 5 above)
   2.  - CmdSN must not be incremented CmdSN in Login Phase
   3.  - it is okay to transmit the first command of the Login Phase
         with the CSG set to 1. It is also okay for the target to reject it
         and to close the connection.  
   4.  - If the Initiator transmits its first command of the Login Phase
         with the T bit set, its okay for the target to transmit a response
         with T = 0, even though there is no example in the draft
         demonstrating it. 
   5.  - Stage Transitions from 0 to 3 are valid according to the spec
         although this is not specifically stated in the draft.