Re: iSCSI: plugfest4 issues

[Luben Tuikov <luben@splentec.com>]

"Robert D. Russell" wrote:
> 
> 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.

In which case if a command fails completely for whatever reason,
then you'd set the residual to equal edtl. This doesn't sound right.
 
>    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.

Shortly, both.

Residuals are sometimes set also by the low-level device drivers,
this should be reported by the target.

The target can add a residual of its own. If the device
controller doesn't support clustering of requests, then the data
to be transferred is limited by the maximum scatter-gather table
times the sector size. Then the residual added to any future
residual (say by the LLDD or the controller or the device server)
is request_size-max_sg*sector_size. This should be reported by
the target to the initiator.

As to WRITE, you could use 9.4.6.2 Sense Data.
You cannot start SCSI WRITE for 10 bytes when you have 8 bytes.

Regarding response code, I wouldn't presume that a block OS layer
(or OS SCSI layer) would use residual counts when SCSI service
response is SERVICE DELIVERY or TARGET FAILURE, since SAM-3
specifies that ``All output parameters are invalid.''

CHECK CONDITION status code is also not a good candidate, since
nothing in the sense codes table specifies that residual counts
should be valid or looked up.

It would seem appropriate to set residual counts only when
the command completed or partially so. The status codes for
this condition are unambiguous.

The initiator shouldn't be too smart with residual counts
and try to retransmit, or it would lock up OS's ULP.
 
> 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?

For security/bandwidth/DOSA reasons the target should immediately
close the connection. No explanation is due for non-complient
initiators since the target cannot establish if they are initiators
in the first case (port scanners, security breakers, etc.).

That is, before FFP, the target should be ``trigger-happy'' to close
the connection. In FFP, it depends on the Recovery Level.
 
> 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?

In login phase, I personally close the connection. (period)
This somehow simplifies the logic (or frees up more space for
other login related logic) and makes the target more secure.
 
>      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 simply means that a receiver should _only_ check the relevant
information in a complient PDU format. I.e. if a reserved bit is not
0 as it should be, it's better neglected rather than the connection
compromized.

It shouldn't be generalized, for security reasons.

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

Right!
Perfect analysis which shows that request Nop-Outs should have I=1.

The logic for TMF requests is as follows:
TMF req. always carry I=1. This basically means that all recovery
and action that could have been taken at the initiator was actually
taken and we want immediate assistance/action by the target.

That is, TMF requests should be attempted at the Initiator first,
and if not successful or the nature of the task can only be performed
at the Target, then a TMF request should be sent with I=1. This also
solves other problems...

-- 
Luben