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

["Eddy Quicksall" <esquicksall@hotmail.com>]

Regarding number 1) which refers to section 5.5 ...

why not just change the paragraph to say:

   When an initiator receives an iSCSI data PDU with a data payload
   digest error or any other iSCSI PDU with a header or payload digest
   error it MUST discard it, and restart the task - the later provided
   header does not have a digest error. If there is a header digest
   error the initiator may need to recognize and recover using an
   implementation specific scheme such as timing the request. Schemes
   may include loging out the connection and restarting it (including
   restarting all outstanding tasks).


Eddy


----Original Message Follows----
From: julian_satran@il.ibm.com
To: ips@ece.cmu.edu
Subject: Re: iSCSI : Digest Error Problems & CmdSN/ExpCmdSN window issues
Date: Fri, 26 Jan 2001 17:50:37 +0200



Santosh,

I think that you are misreading my comments.
When I say a may in one of my answers it does not mean that it has to
appear as such in the draft.

As for the interpretation of restart - once delivered a restarted command
has to do just that restart.
If for implementation reasons you want to take the abort path and then
restart  that is an implementation issue.

In any case it is not equivalent with sending an explicit task abort then
start the command as this is not an atomic sequence and may affect the
command ordering.

Julo

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 (i.e. getting to
real problems) if you'll discuss your points with your powerful "home-team"
(Randy, Pierre etc.).

Santosh Rao <santoshr@cup.hp.com> on 25/01/2001 21:17:33

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

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  Re: iSCSI : Digest Error Problems & CmdSN/ExpCmdSN window issues




Julian,

My responses enclosed inline.

Regards,
Santosh

julian_satran@il.ibm.com wrote:

 > 1) The initiator task tag cannot be trusted when a header digest error
 > is seen. What does the phrase "provided it can recognize the initiator
 > task tag" mean ?
 > How can an initiator reliably claim that the initiator task tag is
 > trustworthy ?
 >
 > <js> an initiator may choose to provide some redundancy in the tag itself
 > </js>

All of these excessive "mays" only serve to complicate the standard and end
up
as un-used features. They are better off removed.

 >
 > 2) The use of a "discard and re-start" policy can cause some  problems.
 > The target is un-aware that the initiator has discarded the task and
 > will then receive a 2nd command with the same Initiator Task Tag and
 > CmdSN for a task already in progress, which can cause transmission of
 > duplicate sets of data on the same I.T.T.
 >
 > Any policy of "discard and re-start" must be modified to "discard, abort
 >
 > and then, re-start, and the draft MUST specify connection allegiance of
 > the command and its Abort Task".
 >
 > <js> a restart is recognized as such through the restart bit. Why would
you
 > require abort?

Where does the draft EXPLICITLY state that the "retry" bit implies an
implicit
abort of the command followed by re-start ?

In the absence of such explicit clarifications, the draft is opening up
opportunities for numerous creative mis-interpretations.

Despite this, 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.

All of this complexity is only in the case of digest error handling [and
not
in the case of connection failures]. The draft can be rid of all this
complexity if digest errors were to be recovered at a connection level,
instead of this "discard & restart" policy which adds all these
complexities.

 >
 > please explain </js>
 >
 > 3) The policy of "discard and restart" is also subject some race
 > conditions in the CmdSN sliding window. At the time the digest error was
 >
 > detected at the initiator, the ExpCmdSN may not yet have acknowledged
 > that
 > command. This causes the initiator to restart the command with the same
 > Initiator Task Tag, CmdSN and "retry" bit set.
 >
 > However, by the time the command gets to the target, the target may have
 >
 > updated its ExpCmdSN window having sent a later PDU which updated the
 > ExpCmdSN. This results in the target discarding the received CmdSN since
 >
 > <js> at command restart you never really rely on the CmdSN. you will want
 > to check
 > the Initiator Task Tag and accept it in the above case. </js>

The draft states the following on this subject :

Section 5.1
=========
-    the initiator will reissue all outstanding commands with their
       original Initiator Task Tag and their original CmdRN if they
       are not acknowledged yet or a CmdRN of 0 (not-numbered) if they
       were acknowledged; the retry (X) flag in the command PDU will
       be set

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 commands within the range that are not flagged with the retry
bit.

Can you please clarify the intent of the text ?



  - santoshr.vcf




_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com