Re: iSCSI: revised error recovery hierarchy

["Mallikarjun C." <cbm@rose.hp.com>]

Hi Arpakorn,

In short, I suggest that the answer to your question 
is: initiator can choose level-0 (session recovery) and 
do what you suggest.

ErrorRecoveryLevel key value is a declaration of the
sender's capabilities.  By setting to 0 in the initial
dialogue, initiator is implying that it can't do any
recovery - so target can't send recovery R2Ts and such.
BUT, the initiator can always abort the task as section 
7.4 clearly calls out.  Target is guaranteed not to force 
session recovery since the digest error is on the 
initiator's end - so the abort is expected to work
(unless ofcourse target sees a digest failure at the
same time on a different PDU, and decides to escalate...).

Hope that answers your question.  

Regards.
-- 
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com

Arpakorn Boonkongchuen wrote:
> 
> Hi Mallikarjun,
> 
> I have been following the iSCSI error recovery discussion
> and have one question.  Is it a valid procedure for an
> initiator who doesn't implement SNACK and does not want to
> tear down the session and all connections when it gets a
> data digest error to simply aborts the task (with task
> management function request) associated with the bad
> data digest received and tries to recover by resending the
> command?
> 
> It seems to me that this would fit between the level 0 and 1
> as described in your slides.  Is this possible if you choose
> level 1?  Please let me know if I miss something.
> 
> regards,
> Arpakorn
> 
> At 12:22 PM 9/12/2001 -0700, you wrote:
> >All:
> >
> >Here's a revised error recovery layering proposal.
> >
> >http://storage-arch.hp.com/iscsi_hierarchy-2.pdf
> >
> >Please review and offer comments.  The earlier London
> >proposal slides are on the same website for your reference.
> >
> >I believe this revised proposal balances the desire
> >to reduce the # of levels with the need to ensure that
> >we don't bundle multi-connection functionality into
> >single-connection error recovery.  IOW, the revised
> >level "2" deals exclusively with connection failover
> >capabilities and implementations supporting only single
> >connection sessions do not ever have to support
> >level "2".
> >
> >Since publication of rev08 appears to be only
> >by this weekend and there seems to some preference
> >towards fewer number of levels anyway, my current
> >thinking is to incorporate this revised hierarchy
> >into rev08 for a detailed WG review and debate.
> >
> >Thanks.
> >--
> >Mallikarjun
> >
> >
> >Mallikarjun Chadalapaka
> >Networked Storage Architecture
> >Network Storage Solutions Organization
> >MS 5668 Hewlett-Packard, Roseville.
> >cbm@rose.hp.com