Subject: Re: iSCSI : Command Ordering Proposal.

From: [email-masked]
Date: Tue, 30 Jan 2001 17:58:22 +0200

Santosh,

The only puzzling question is what kind of digest error would you detect
for a command that the target has not yet started acting upon? This assumes
out of order delivery to SCSI right?  And even then if the task is
recognized you could use a CmdSN of 0 as the command is clearly active.

Only for commands that never gave a sign "of life" you have to use the
original CmdSN in case the command did not make it to the delivery queue.

Julo

Santosh Rao <[email-masked]> on 30/01/2001 09:58:47

Please respond to Santosh Rao <[email-masked]>

To:   [email-masked]
cc:   [email-masked] (IPS Reflector)
Subject:  Re: iSCSI : Command Ordering Proposal.

Matt,

Comments in-line.

Regards,
Santosh

>
> Santosh Rao wrote:
> >
> > Matt Wakeley wrote:
> >
> > > Retried commands should have already been queued and/or executed.
> >
> > Not necessarily. A TCP connection failure can affect the command PDU.
>
> In which case the target will have "silently discarded" the PDU.  Then,
it
> will not acknowledge via ExpCmdSN any commands past the err'd command, so
the
> initiator can resend the command with the same CmdSN and enabling command
> delivery to SCSI to continue.

The above was stated to explain why "retry" commands need
to use CmdSN [and cannot use a CmdSN of 0 as you were
proposing].

The problem being originally described can occur when the
initiator applies a "discard & retry" policy on detecting
a digest error at its end. In such a case, it would
"retry" the command, and if the CmdSN was not yet
acknowledged, would send the "retry" with the original
CmdSN.

Since the target continues to send PDUs to the initiator,
it can update the ExpCmdSN causing the "retry" to be
discarded by the target, because its CmdSN has slid
behind the window.

The spec does not mandate that an update to ExpCmdSN
MUST accompany the Data PDUs for a command. IOW, a target
may lag behind in updates to ExpCmdSN while continuing to
send Data PDUs for the received command.

>
> > Similarly, the target may have detected a header or data digest error
> > on the SCSI Command PDU, sent a REJECT
>
> I thought any digest errors are silently discarded - therefore, there is
no
> reject.

Not when targets detect a digest error. Section 5.5 mandates targets
to send a REJECT with a reason of digest error. The "discard & retry"
policy is for initiators.

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

--
#################################
Santosh Rao
Software Design Engineer,
HP, Cupertino.
email : [email-masked]
Phone : 408-447-3751
#################################

---

From: Santosh Rao <[email-masked]>
Date: Tue, 30 Jan 2001 18:11:29 -0800

[email-masked] wrote:

> for a command that the target has not yet started acting upon?

Julian,

The target has started acting on the command. However, there is nothing in
the standard that requires a ExpCmdSN ACK to accompany the inbound
Data PDUs for a READ command.

In the absence of this, targets are free to send in delayed ExpCmdSN updates
and can commence transmission of Data PDUs [which are not yet ACKing
the CmdSN for the command in response to which the Data PDU is being
sent.]

Either :
a) An inbound Data PDU should be considered an implicit ack of the CmdSN
which was sent.

Or :
b) When initiators detect digest errors on an inbound Data PDUs
(header or digest), they should send the "retry" with a CmdSN of 0.

>  And even then if the task is recognized you could use a CmdSN of 0

> as the command is clearly active.

The above is sufficient. The draft should state either (a) or (b) in its
policy for initializing CmdSN on "retry" commands.

Regards,
Santosh