Subject: Re: iSCSI: plugfest4 issues

From: "Julian Satran" <[email-masked]>
Date: Thu, 1 Aug 2002 02:52:19 +0300

Bob,

Thanks - some comments in text. Julo

"Robert D. Russell" <[email-masked]>
07/31/2002 02:43 AM

        To:     Julian Satran/Haifa/IBM@IBMIL, <[email-masked]>
        cc: 
        Subject:        Re: iSCSI: plugfest4 issues

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.

+++ Residual count fields are in fact carrioed over from the SCSI layer. I 
know that none of the SCSI docs specifies exactly their behavior and it 
strikes me as a bad idea to have protocols specify them. 
The values should be valid any time the target decides to put them in. +++

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.
+++ I would suggest sticking with disconnecting. +++

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

I've made the offending paragraph read:

All keys in this document except for the X extension formats, MUST be 
supported by iSCSI initiators and targets when used as specified here. If 
used as specified those keys MUST NOT be answered with NotUnderstood.
+++

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

That is a good point.
Non-immediate NOPs are meant to be use as time measuring pings
and test the entire stack including the queuing mechanism.

+++
Bob Russell
InterOperability Lab
University of New Hampshire
[email-masked]
603-862-3774

---

From: Santosh Rao <[email-masked]>
Date: Wed, 31 Jul 2002 17:44:39 -0700

Julian & Robert [Russell],

I raised the same query regarding RESID for FCP/FCP-2 this time last
year. The response I got for FCP/FCP-2 was that RESID information shall
be valid, regardless of the scsi status returned. The RESID field, can
be checked by the scsi transport drivers independent of the SCSI STATUS.

I have enclosed the T10 response from Rob Snivelly below on that issue.
As per FC-PLDA, the RESID information is valid, regardless of the scsi
status returned by the device. 

An example of this is the case of "NO SENSE" or "RECOVERED ERROR" check
condition, when the data transfer may have taken place and a CHECK
CONDITION is returned. Also, for other CHECK CONDITION status', partial
data transfer may have taken place and hence, resid information should
be present.

It would be good to maintain consistent behaviour across the scsi
transports in this regard, since protocol bridging from iscsi to FCP
domain would expect RESID information in the FCP domain, regardless of
scsi status.

This also allows scsi transports to remain free of SCSI command set
details. (ex : the scsi transport drivers do not need to parse for CHECK
CONDITION or GOO status information.)

Thanks,
Santosh

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

Subject: Re: iSCSI: plugfest4 issues
Date:    Thu, 1 Aug 2002 02:52:19 +0300
From:   "Julian Satran" <[email-masked]>
To:     "Robert D. Russell" <[email-masked]>
CC:     [email-masked]

Bob, 

                                            
Julian:

+++ Residual count fields are in fact carrioed over from the SCSI layer.
I know that none of the SCSI docs specifies
exactly their behavior and it strikes me as a bad idea to have protocols
specify them. 
The values should be valid any time the target decides to put them in. 
+++

-------------------------------------------------------------------------
Subject: RE: FCP_RSP Residual Checking.
Date:    Thu, 5 Jul 2001 13:18:42 -0700
From:    Robert Snively <[email-masked]>
To:      "'Santosh Rao'" <[email-masked]>, 
         T10 Reflector <[email-masked]>, 
         Fibre Channel T11 reflector <[email-masked]>

Robert Snively wrote:
> 
> >  Is the target required to initialize the fields FCP_RESID_UNDER,
> >  FCP_RESID_OVER & FCP_RESID when any I/O is completed
> >  without the data phase having transferred exactly
> >  FCP_DL bytes, regardless of the SCSI Status being returned ?
> 
> >  When the target generates a CHECK CONDITION on an I/O
> >  and may have returned less than FCP_DL bytes in the data
> >  phase for that I/O, is it
> >  required to set the FCP_RESID_UNDER to 1 and indicate the number of
> >  bytes not transferred in the FCP_RESID field?
> 
> The intent is that the answer to your second question is:
> FCP_RESID should appropriately regardless of the SCSI Status
> being returned.  The classic errors of that class are those
> involving successful completion with reporting, like
> the "NO SENSE" and "RECOVERED ERROR" series of errors.
> 
> >
> >  What is the behaviour initiators can expect under the above
> >  condition ?
> 
> The intent is that there be no conflict.  I believe that FCP-2
> was a bit less bald than FC-PLDA in stating the requirement.
> 
> >  Is there a conflict in the behaviours described by FCP/FCP-2
> >  & FC-PLDA ?
> >
> 
> Bob Snively                        e-mail:    [email-masked]
> Brocade Communications Systems     phone:  408 487 8135
> 1745 Technology Drive
> San Jose, CA 95110
> 
> >  -----Original Message-----
> >  From: Santosh Rao [mailto:[email-masked]]
> >  Sent: Thursday, July 05, 2001 12:15 PM
> >  To: T10 Reflector; Fibre Channel T11 reflector
> >  Subject: FCP_RSP Residual Checking.
> >
> >
> >  All,
> >
> >  I've got a question on target behaviour while sending a
> >  CHECK CONDITION
> >  SCSI status in its FCP_RSP IU.
> >
> >  Is the target required to initialize the fields FCP_RESID_UNDER,
> >  FCP_RESID_OVER & FCP_RESID when any I/O is completed without the data
> >  phase having transferred exactly FCP_DL bytes, regardless of the SCSI
> >  Status being returned ?
> >
> >  When the target generates a CHECK CONDITION on an I/O and may have
> >  returned less than FCP_DL bytes in the data phase for that I/O, is it
> >  required to set the FCP_RESID_UNDER to 1 and indicate the number of
> >  bytes not transferred in the FCP_RESID field?
> >
> >  FC-PLDA Section 8.2.4.1 states that :
> >  "SCSI targets that transfer less than FCP_DL bytes during
> >  the FCP_DATA
> >  IUs shall set the FCP_RESID_UNDER to 1".
> >
> >  No exceptions are specified in the case of a CHECK CONDITION in the
> >  above definition, implying that FCP_RSP residual checking can be
> >  performed irrespective of the SCSI Status that was returned in the
> >  FCP_RSP.
> >
> >  However, the wording descriptions of FCP_RESID_UNDER,
> >  FCP_RESID_OVER &
> >  FCP_RESID in SCSI-FCP & FCP-2 are not as stringent as
> >  FC-PLDA and do not
> >  mandate that FCP_RESID_UNDER shall be set when the data
> >  transferred is <
> >  FCP_DL.
> >
> >  What is the behaviour initiators can expect under the above
> >  condition ?
> >  Is there a conflict in the behaviours described by FCP/FCP-2
> >  & FC-PLDA ?
> >
> >  Thanks,
> >  Santosh Rao
> >

-- 
Education is when you read the fine print. 
Experience is what you get if you don't.