Re: iSCSI : Command Ordering Proposal.

[julian_satran@il.ibm.com]

I will spell-out more recovery scenarios in the next draft. Julo

Santosh Rao <santoshr@cup.hp.com> on 31/01/2001 04:11:29

Please respond to Santosh Rao <santoshr@cup.hp.com>

To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI : Command Ordering Proposal.




julian_satran@il.ibm.com wrote:

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

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