Re: iSCSI Plugfest at UNH (misc issues)

[Julian_Satran/Haifa/IBM%IBMIL <julian_satran@il.ibm.com>]

The case arises with a well behaved target and the question was meant to
show only that the
test is not trivial and can't be based on numbers alone - although I
assumed that any good initiator will mark acked commands and might
show its displeasure receiving status from an unacked command (it MUST be
acked at least with the status).

I think that the clarification I sent out will solve your problem.

Julo

Sandeep Joshi <sandeepj@research.bell-labs.com> on 25-07-2001 18:07:52

Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>

To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI Plugfest at UNH (misc issues)





thanks to all for the clarifications on ITT usage.

Matt & Julian, to answer your comments on expCmdSN..

> Until you identify the problem, I don't want any more "tests" mandated.

The initiator balked somewhere in retry/timeout processing
or garbage collection or some state assertion.  I'll have to tinker
under the hood to find more, but it did not seem correct to get
status for something which had not been acknowledged as delivered.

> The iSCSI standard says that once SCSI commands get put into the task
queue,
> the CmdSN no longer associated with the command.  The initiator is NOT
> supposed to associate commands with responses based on the CmdSN or
ExpCmdSN.

Enlighten me here....to retry a command, doesnt one need to
know the original cmdSN of a command (Sec 7.1) ?  The initiator is
not associating responses with cmdSN but it does know the
original cmdSN for each task.

> +++
>
> Interesting proposal. Has some academic weaknesses however. We assume
that
> CmdSN has no significance after delivery.
> Assume that you have a good target and a very long lived command -
outlives
> a wrap around of CmdSN!
> How would you distinguish the status of this command carying a low
ExpCmdSN
> from your case?

I did not understand how this case could arise, assuming that
comparisons
occur in the sequence space (RFC1982) and (maxCmdSN-expCmdSN < 2^31)

-Sandeep


> 2) ExpCmdSN
>    What are the semantics of something like this.. the
>    target does not increase the expCmdSN but keeps sending
>    the status (SCSI response) for commands after the expCmdSN ?
>    Clearly, the target has received and executed the commands
>    (in cmdSN order).
>
>    Hence, the expCmdSN in a SCSI response must not be less
>    than the cmdSN of the original command (for which response
>    is being received).
>
>    This seems like a valid property which could be mandated
>    and checked, to allow efficient initiator implementations.
>    The target eventually suffers but the standard could
>    prevent such targets from being deployed :-)
>
> +++
>
> Interesting proposal. Has some academic weaknesses however. We assume
that
> CmdSN has no significance after delivery.
> Assume that you have a good target and a very long lived command -
outlives
> a wrap around of CmdSN!
>
> How would you distinguish the status of this command carying a low
ExpCmdSN
> from your case?
>
> I will change the following in 1.2.2.1
>
>        - CmdSN - the current command Sequence Number advanced by 1 on
each
>       command shipped except for commands marked for immediate delivery.
>        - ExpCmdSN - the next expected command by the target. The target
>       acknowledges all commands up to but not including this number and
the
>       initiator has to mark the acknowledged commands as such as soon as
a
>       PDU with the corresponding ExpCmdSN is received. The target iSCSI
>       layer sets the ExpCmdSN to the largest non-immediate CmdSN that it
is
>       able to deliver for execution plus 1 (no holes in the CmdSN
>       sequence).
>        - MaxCmdSN - the maximum number to be shipped. The queuing
capacity
>       of the receiving iSCSI layer is MaxCmdSN - ExpCmdSN + 1.
>
> And later - at the end of 1.2.2.1
>
>    A target MUST NOT issue a command response or DATA-In PDU with status
>    before acknowledging the command.
>
> As with many other initiator deteced errors - the initiator has to decide
> what to do with such an error (logout, rest etc.)
>
> ++++
>