Re: iSCSI : Command Ordering Proposal.

[Santosh Rao <santoshr@cup.hp.com>]

Matt Wakeley wrote:

> Retried commands should have already been queued and/or executed.

Not necessarily. A TCP connection failure can affect the command PDU.
Similarly, the target may have detected a header or data digest error
on the SCSI Command PDU, sent a REJECT and the initiator would have
"discarded and retried" the task.

In both of the above cases, the command is not queued and/or being executed
at the target.

Such commands, when retried, need to enforce ordering. Hence, the need to
specify CmdSN in the "retry", if the CmdSN is yet to be acknowledged.
The difficulty lies in the establishment of a "sync point" with the ExpCmdSN,
prior to the initiation of these "retry" commands, so as to ensure that the "retry"

will not be discarded by the target, because the CmdSN slid behind the
(ExpCmdSN, MaxCmdSN) window.

The ExpCmdSN in the login response provides this "sync point" during connection
failure recovery. The problem is only with digest error "retries".

If one were to NOT apply the "discard and retry" policy on a header digest error,
[under the assumption that the I.T.T cannot be trusted on a header digest error],
the problem further reduces to the following cases :

a) data digest error detected by a target on a command PDU. (immediate data).
b) data digest error detected by an initiator on inbound Data PDUs of a READ
I/O, and the CmdSN for the command is yet to be acknowledged, but an ACK
may be in-flight behind the Data PDU.

Regards,
Santosh


> The goal of
> the retry is simply to replay back to the initiator the results of the
> execution. Therefore, there is no ordering requirement for "retried" commands
> and CmdSN should always be zero.
>
> -Matt
>
> Santosh Rao wrote:
>
> >
> > Accepting a command outside the (ExpCmdSN, MaxCmdSN) window with the retry
> > bit set then opens up windows for other types of stale and duplicate commands
> > to be
> > processed.
> >
> > Here's the deal (as I view it) :
> >
> > Commands are sent with the "retry" bit under 2 conditions :
> > - Connection Failures
> > - Digest Errors
> >
> > In both these cases, an explicit handshake is required regarding the
> > (ExpCmdSN, MaxCmdSN) window, prior to starting to send "retry"
> > commands. This ensures that genuine "retry" commands do not slip
> > behind the (ExpCmdSN, MaxCmdSN) window.
> >
> > In the case of a connection failure, the Logout Response provides this
> > handshake. For digest errors, there is no such hand-shake.
> > Hence, a command that encountered a digest error and was retried could
> > likely slip behind the (ExpCmdSN, MaxCmdSN) window and then be never
> > processed.
> >
> > Regards,
> > Santosh
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard