Re: iSCSI Plugfest at UNH (misc issues)

[Sandeep Joshi <sandeepj@research.bell-labs.com>]

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