Re: iSCSI : Digest Error Problems & CmdSN/ExpCmdSN window issues

[julian_satran@il.ibm.com]

Santosh,

Education was not meant to be insulting and I am sorry if did sound to you.
However you are restarting discussion threads that where long settled
without
bringing new arguments. And I am not exactly thrilled in reliving the
thread.

Regards,
Julo

Santosh Rao <santoshr@cup.hp.com> on 26/01/2001 19:29:09

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

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   Black_David@emc.com, santoshr@hpcuhe.cup.hp.com (Santosh Rao)
Subject:  Re: iSCSI : Digest Error Problems & CmdSN/ExpCmdSN window issues




>
> Santosh,
>
> As for the interpretation of restart - once delivered a restarted command
> has to do just that restart.

Julian,

I believe you are referring to the "Retry" bit , is that correct ? (There
is nothing in the draft that I can find called a Restart bit).

If you are referring to the retry bit, can you please point me to where
the draft EXPLICITLY states that a "retry" shall cause the target to
implicitly abort execution of the previous instance of that command ? In
the absence of such explicit wording in the draft, how does one derive
the conclusion you mention above ?

Also, I did'nt see your response to the below 2 issues raised :

> Section 1.2.2.1
> ===========
> - The target MUST silently ignore any command
>    outside this range or duplicates within the range not flagged with
>    the retry bit (the X bit in the opcode).
>
> This, to me, means :
> - ignore all commands outside the (ExpCmdSN, MaxCmdSN) range.
> - ignore all duplicate commands within the range that are not
>   flagged with the retry bit.
>
Can you please clarify the intent of the text ? From the above it
does'nt sound like the draft specifies that CmdSNs received out of the
window are to be accepted if the Retry bit is set.

> There is still a window b/n the command being re-started at
> the initiator and the target receiving the command with "retry"
> bit set, when stale frames continue to arrive at the initiator for
> that I.T.T. Therefore, in order to avoid stale frames from the
> previous command continuing to arrive at the initiator in this window,
> there needs to be an abort followed by a re-start.

How is the above to be avoided ?

> N.B. I really appreciate you keeping the list so alive during you
> education session but I think that you can improve your hit ratio

Anyone would appreciate comments being restricted to technical responses
instead of such remarks. Perhaps, you may want to check the threads in
the past to see how many issues have been uncovered and how many times you
stood corrected.
(ex : faking of check conditions instead of using a service response,
response data and response length, DataRN, target originated connection
level error recovery thru the use of Async Messages, Abort Task response,
retries to tapes result in possible data corruption, bridging CmdSNs,
fragmentation & re-assembly issues, etc).

Wonder who's getting educated here. (?)

--
#################################
Santosh Rao
Software Design Engineer,
HP, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
#################################