Re: iSCSI question

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

Pat is correct, the only change from what she said is that there's only
one hierarchy, not two (the error recovery "classes" have no implied hierarchy).

Even though the text is very explicit, I agree that it may still be a good idea
to improve the table as Pat suggests.
--
Mallikarjun

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


----- Original Message -----
From: <pat_thaler@agilent.com>
To: <Shahram_Davari@pmc-sierra.com>; <pkoning@equallogic.com>
Cc: <ips@ece.cmu.edu>
Sent: Thursday, August 08, 2002 2:58 PM
Subject: RE: iSCSI question


> Shahram,
>
> There are two recovery heirarchies. You seem to be confusing error recovery level with error recovery class.
>
> One is the heirarchy for implementation requirements. With 3 forms of recovery, there are 8 possible
combinations but to simplify interoperability and to specify minimum acceptable operation, we don't want to
allow all eight. Session qualifies two ways to be level 0 of this heirarchy - it is simplest to implement and
it should be able to recover from any recoverable error.
>
> Note that these are the error recovery levels that are described in 5.15. A sessions recovery level
indicates the set of recovery classes it is capable of using. The recovery levels are defined such that a
lower recovery level includes a subset of the recovery classes available at a higher recovery level.
>
> The other heirarchy is the order in which the available classes are applied once an error occurs. This is
the subject of 5.14. The classes are disjoint.
>
> Once an error occurs, the device will choose an error recovery class from the set of recovery classes in its
recovery level. If that recovery class fails, it may try the next higher class.
>
> Error recovery level 0 includes the Session recovery class.
> Error recovery level 1 includes the two classes useful for  Digest failure recovery (Within-Command and
Within-Connection) plus the Session recovery class from level 0.
> Error recovery level 2 includes  Connection recovery class plus the classes included in level 1.
>
> I think the text already makes this clear and the pyramid correctly represents this, but perhaps the chart
below the period could add "plus the capablilities of ErrorRecoveryLevel n" to the boxes for Associated Error
recovery capablities for levels 1 and 2 ("n" = 0 and 1, respectively).
>
> I hope this helps remove some of the confusion.
>
> Pat
>
> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> Sent: Thursday, August 08, 2002 2:22 PM
> To: 'Paul Koning'
> Cc: ips@ece.cmu.edu
> Subject: RE: iSCSI question
>
>
> Paul,
>
>
> > But that's not what "hierarchy" refers to here.
> >
> > The hierarchy is one of increased capability, not increased
> > desperation.  Session recovery is the minimum required; the additional
> > levels are optional capabilities in addition to the minimum.  Each
> > higher level in the hierarchy is a superset of the one below.
>
> It all depends on the definition of these recovery classes.
>
> 1) If they are defined in a superset/subset fashion, then I agree
> that level of complexity increases as: Session->PDU->connection.
> Then I suggest changing texts in other parts of the draft such as
> section 5.14 to indicate that if you have the capabilities of
> class X, then you don't need to escalate to lower classes, because
> class X already has those capabilities itself. Also I suggest
> changing the hierarchy figure as following:
>
>
>                              +
>                             / \
>                            / 2 \
>                           +-----+
>                          /  1,2  \
>                         +---------+
>                        /   0,1,2   \
>                       +-------------+
>
>
> 2) If they are defined as disjoint classes, then the hierarchy for
> complexity makes no sense. Rather you need a hierarchy for escalation
> or transition.
>
>
> Based on the emails that I have received so far it seems that the intent is the former definition.
>
> Yours,
> -Shahram
>
>