Re: iSCSI: plugfest4 issues

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

Julian:

Four issues came up today at the iSCSI plugfest:

1. A question about whether or not the Residual Count field and the
   appropriate O and U bits need to be computed on all SCSI Response
   PDUs, regardless of the values in the Status and/or Response fields.

   One point of view says that the Residual Count field and the O and U
   bits appear to be strictly iSCSI values that are derived by the
   iSCSI target layer from the ExpectedDataTransferLength field of the
   SCSI Command PDU and the DataSegmentLength fields of the DataIn or
   DataOut PDUs sent as part of this command.  Therefore ,the iSCSI
   target always computes a Residual Count value without regard to the
   Status and/or Response fields, since these are SCSI values.

   The other point of view says that the Residual Count field, and the
   O and U bits, need only be set when the Status and Response fields
   indicate that the command was completed at the target with a GOOD
   Status, and the target does not have to compute or set the Residual
   Count field and the O or U bits for other values of the Status and/or
   Response fields.

   Which is it?  In any case, could this be clarified somewhere in the
   standard, most likely in section 9.4.4.


2. The last paragraph of section 2.2.3 says:

   "Before the Full Feature Phase is established, only Login Request and
   Login Response PDUs are allowed. Any other PDU, when received at ini-
   tiator or target, is a protocol error and MUST result in the connec-
   tion being terminated. ..."

   The question is the following:  is this rule literally true for the
   target (i.e., can the target disconnect as soon as it receives a
   non-Login PDU from the initiator) or does the target have to first
   send a Login Response with Login reject PDU before disconnecting, as
   it does for all other errors detected by the target during Login
   Phase (according to section 4.3.1)?

   A related question is: does the target take the same action when
   the very first PDU it receives on a new TCP connection is not a
   Login Request PDU?

   If the target has to send the Login reject PDU before disconnecting,
   then the last paragraph of section 2.2.3 should be reworded along
   the following lines (modeled after the last paragraph of section 4.3):

   "Before the Full Feature Phase is established, only Login Request
   and Login Response PDUs are allowed.  If the target receives any PDU
   other than Login Request, it must send a Login reject (code 0x020b)
   and then disconnect.  If the initiator receives any PDU other than
   Login Response, it MUST drop the connection. ..."

   This wording would also appear to cover the case of when the very first
   PDU a target receives on a new TCP connection is not a Login Request.


3. Section 4.2 says:

  "All keys in Chapter 11, except for the X- extension format, MUST be
  supported by iSCSI initiators and targets and MUST NOT be answered with
  NotUnderstood."

  Two questions arose with this statement:

  1. Shouldn't it say "All keys in Chapter 11 and Appendix A, ..." in order
     to include the Marker keys within the scope of this rule?

  2. Does this literally mean that targets have to support initiator-only
     keys (and initiators support target-only keys)?
     For example, suppose a target sends an InitiatorAlias key, which is
     supposed to be sent only by Initiators.  Does the target have to
     make an extra check to recognize that this is a "key in Chapter 11"
     that is used incorrectly, (so that it does not respond with
     NotUnderstood) or can it just treat it like it would any other key
     it cannot handle, for example, X-InitiatorAlias, and respond with
     NotUnderstood?

     This last question is actually a special case of a more general
     question, and that is: "How much checking does a receiver have to
     do?" just to generate a "proper error response"?
     Section 9 explicitly says that "Any compliant receiver MUST ignore
     any bit not defined and all reserved fields unless specified
     otherwise."  This is the expression of the general philosophy
     "conservative in what you send, liberal in what you accept" and
     eliminates a lot of unnecessary checking.  A similar general
     philosophy applied to other checking would be beneficial,
     although it may be hard to formulate it.


4. This is not a question but rather an observation for implementers.

   Not setting the I bit in a NOP-Out ping request can lead to unusual
   situations.  Consider the situation where a session has multiple
   connections and the initiator periodically sends NOP-Out ping
   requests on each connection just to ensure that the target is
   still alive.  If these NOP-Out requests are not immediate, and
   one of them gets lost (due to a bad checksum, or because that
   connection really is no longer alive), then none of the following
   NOP-Out requests on the other connections can be processed by the
   target, because that would be processing them out of CmdSN order,
   and as a result it would appear to the initiator that all
   connections are bad instead of just one!

   It appears that similar situations may arise when Task Management
   Function commands are sent without setting the I bit -- the target
   would be prevented from processing any of them that follow a
   command that is lost.

Thank you for your consideration.

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